How to Report a KernelSU Security Vulnerability Responsibly

TL;DR: To report KernelSU vulnerability findings responsibly, send a confidential, reproducible report through KernelSU’s GitHub Security Advisories page or email maintainer weishu at twsxtd@gmail.com. Do not open a public issue or publish exploit details before a fix is ready. Include affected versions, impact, prerequisites, logs and a minimal proof of concept.

By the PrivacyPortal team

Last updated July 2026

A useful KernelSU security report gives the maintainer enough evidence to reproduce and repair the problem without exposing users prematurely. Use the project’s private reporting channels, distinguish a genuine security boundary failure from an ordinary bug, and state exactly what an attacker needs. If testing requires unlocking, flashing or modifying your own Android device, back up first: unlocking the bootloader wipes user data, and a bad image can cause a bootloop or brick the device.

How to report a KernelSU vulnerability responsibly

The preferred route is KernelSU’s official security policy and private reporting process. Select Report a vulnerability in GitHub Security Advisories, complete the private advisory form, and retain the advisory URL for later correspondence.

If GitHub reporting is unavailable, send the report directly to KernelSU maintainer weishu at twsxtd@gmail.com. Use a clear subject such as “Private security report: KernelSU privilege-boundary bypass”. Ordinary email is not inherently end-to-end encrypted, so avoid attaching unnecessary personal information, device identifiers, credentials or private signing material.

Do not start with a public GitHub issue, discussion, social-media post or rooting-community message. Even a vague public teaser can reveal enough information to direct attackers towards the vulnerable component. Private reporting gives the maintainer time to validate the finding, develop a patch and plan a coordinated disclosure.

KernelSU’s official security policy directs vulnerability reports to private GitHub Security Advisories or maintainer weishu at twsxtd@gmail.com.

A private GitHub advisory keeps the technical report and maintainer discussion out of the public issue tracker.

Confirm that the finding is a security issue

A security vulnerability crosses an intended trust boundary. Examples include an untrusted application obtaining root privileges, a non-root process controlling KernelSU policy, authentication being bypassed, unsafe kernel memory access, or confidential data becoming accessible outside its intended permissions.

A crash, unsupported kernel, failed module installation or Manager interface problem is not automatically a vulnerability. It becomes security-relevant when an attacker can use it to affect confidentiality, integrity or availability.

Observation	Likely classification	Best reporting route
An unapproved application gains root access	Security vulnerability	Private security advisory
A crafted request corrupts kernel memory	Potential security vulnerability	Private security advisory
KernelSU Manager crashes on one screen	Ordinary bug unless exploitation is demonstrated	Public issue with sensitive details removed
A module causes a bootloop after an incompatible update	Compatibility or module bug in most cases	Relevant module or kernel project
A downstream fork contains code absent from upstream KernelSU	Fork-specific until proven otherwise	Fork maintainer, with private upstream notice if shared code may be affected

When uncertain, report privately and explain the uncertainty. A maintainer can downgrade a confidential report safely; reversing an accidental public disclosure is much harder.

Back up before attempting reproduction

Security research does not remove the normal risks of Android modification. Back up photographs, messages, authenticator recovery codes, app data and any files that exist only on the phone. Verify that the backup can actually be restored before changing the boot state.

Unlocking the bootloader performs a factory reset on supported Android devices. Flashing the wrong boot, init_boot, vendor_boot or kernel image may cause a bootloop, disable touch or radio functions, or leave the device unable to start normally. Recovery procedures differ by manufacturer, and some devices have limited or irreversible rollback protections.

Rooting can affect warranty handling, over-the-air updates and device security. Banking, streaming, workplace and identity applications may use Play Integrity or their own checks; no KernelSU configuration can be promised to work with a particular application. Never test a suspected vulnerability against somebody else’s device, account or service.

Use a spare device or emulator when the flaw can be reproduced there. Keep the matching stock images and documented recovery procedure available before flashing anything. PrivacyPortal readers who are still preparing a test handset may find our bootloader unlocking safety guide useful.

Record the exact affected environment

“KernelSU is vulnerable” is not reproducible enough. KernelSU can be integrated into different kernels, while forks and downstream patches may change the affected code. Record the smallest accurate set of environmental details:

• KernelSU version, release tag and, for source builds, the full Git commit identifier.
• Whether the build is official upstream KernelSU, a fork or a device-kernel integration.
• Kernel version, Android version, security patch level and device model.
• KernelSU Manager version and installation source.
• GKI or device-specific kernel status and the image that was modified.
• Relevant modules, their versions and whether the problem remains after disabling them.
• SELinux state, especially if testing changed it from enforcing to permissive.
• Every prerequisite available to the attacker, including local app access, ADB access or prior root.

Run adb version to record the Android Debug Bridge version used. Commands such as adb shell uname -a and adb shell getprop ro.build.fingerprint can capture useful build context, but inspect their output before sharing because fingerprints and logs may reveal device or build information.

KernelSU v3.2.5, released on 23 June 2026, was the latest official upstream release when this article was verified on 21 July 2026.

A strong report identifies the precise KernelSU build, kernel integration and Android environment involved.

How to submit a reproducible KernelSU security report

Use the following workflow on a device you own and are authorised to modify. Stop if reproduction threatens important data, hardware recovery or another person’s systems.

1. Back up and prepare recovery. Copy important data away from the device, confirm the bootloader state, obtain the correct stock images, and document how to return the exact model to a working state. Remember that unlocking the bootloader wipes data.
2. Identify the affected project. Confirm whether the code comes from upstream KernelSU, KernelSU Next, SukiSU Ultra, RKSU or another fork. Capture the release tag and full source commit rather than relying only on a Manager version label.
3. Reproduce from a controlled baseline. Where practical, start from the stock ROM plus the affected KernelSU build. Disable unrelated modules one at a time. Record whether the behaviour persists without SUSFS, Zygisk implementations or root-hiding modules.
4. Write the attack preconditions. State whether the attacker needs physical access, USB debugging, an unlocked bootloader, installation permission, shell access, an already-rooted process or user interaction. A weakness requiring existing root has a different impact from one reachable by any untrusted app.
5. Create minimal reproduction steps. Number every action from a clean boot to the security impact. Include commands as text, expected output and actual output. Remove steps that do not influence the result.
6. Collect focused evidence. Attach the smallest relevant log excerpt, crash trace or source diff. Note timestamps and explain which process produced each log. Redact serial numbers, email addresses, tokens, account data, Wi-Fi details and unrelated application information.
7. Build a safe proof of concept. If code is necessary, make it demonstrate only the minimum impact. Avoid persistence, destructive payloads, credential access or automatic scanning. State the compiler, build options and SHA-256 hash of every attachment.
8. Assess scope and impact. Explain what an attacker can gain, which versions appear affected, and what you tested as unaffected. Separate verified results from hypotheses. Do not inflate severity or claim remote exploitation when local access is required.
9. Submit privately. Use KernelSU’s Report a vulnerability form, or email the maintainer if the GitHub route cannot be used. Ask before sending a large attachment or sensitive full-device dump.
10. Verify the submission. Confirm that the report appears in a private advisory rather than a public issue. Reopen the advisory to check that formatting, reproduction steps and attachments survived submission. Save a local copy and record the submission date.

What a high-quality report contains

A maintainer should be able to understand the result without guessing what the reporter means by “bypass” or “root detected”. Use a compact report structure:

• Summary: one sentence naming the failed security boundary.
• Affected component: repository, path, function, release and commit.
• Environment: device, Android build, kernel and Manager details.
• Preconditions: the access and user actions an attacker requires.
• Reproduction: deterministic numbered steps and success rate.
• Impact: what becomes possible and whose data or control is affected.
• Evidence: minimal logs, traces, proof-of-concept code or patch analysis.
• Suggested remediation: optional and clearly separated from confirmed facts.
• Disclosure status: who else received the report and whether anything is public.
• Contact: a reliable address for follow-up questions.

Include a short negative test when possible. For example, show that the same proof of concept fails on the stock kernel or a candidate patched build. This comparison often saves more investigation time than a large unfiltered log.

Common reporting pitfalls

• Publishing first: a public issue can expose unpatched users even if exploit code is omitted.
• Testing only a fork: fork-specific patches may make an upstream attribution incorrect.
• Using a heavily modified daily driver: modules and custom kernels create confounding variables.
• Calling root detection a vulnerability: an app detecting a modified device is not itself a KernelSU security failure.
• Hiding prerequisites: existing root, permissive SELinux or ADB authorisation materially changes severity.
• Uploading complete logs: system logs may contain personal data, application names, network information and tokens.
• Sending secrets as evidence: never include private signing keys, passwords, recovery codes or live credentials.
• Demanding an arbitrary deadline: propose a disclosure date, but allow the maintainer to explain the engineering and release constraints.

In practice, intermittent findings are still reportable. State the number of successful attempts, total attempts, reboot conditions and timing sensitivity rather than presenting a one-in-ten result as deterministic.

What happens after submission

A reporter should expect an initial acknowledgement, requests for missing technical information and progress updates while the issue is reproduced and fixed. Kernel-level behaviour can vary across device kernels, so validation may require testing more than one integration.

Respond through the same private channel. Test proposed patches only on hardware you can recover, back up again before flashing, and verify both outcomes: the exploit no longer works, and legitimate KernelSU permission handling still works. Record the exact patched commit used.

Agree on disclosure timing rather than assuming it. A coordinated publication may include affected versions, remediation, credit and a CVE identifier if the project decides one is appropriate. Do not assign your own unofficial CVE number. If active exploitation appears likely, tell the maintainer privately and clearly mark the urgency.

A KernelSU report should remain confidential until users have a practical fix or the reporter and maintainer agree on a coordinated disclosure.

Patch validation should confirm both that the security boundary is restored and that normal permission controls still function.

Frequently asked questions

Where should I report a KernelSU vulnerability?

Use the private Report a vulnerability option under KernelSU’s GitHub Security Advisories. If that route is unavailable, email maintainer weishu at twsxtd@gmail.com. Do not place exploit details in a public GitHub issue.

Can I report a vulnerability without a working exploit?

Yes. A strong source-code analysis, crash trace or boundary-bypass hypothesis can be valuable even without a weaponised exploit. Label unverified conclusions honestly and provide enough information for the maintainer to investigate safely.

Should I publish my proof of concept immediately?

No. Keep proof-of-concept code private while a fix and disclosure plan are being prepared. A minimal public demonstration may be appropriate after coordination, but it should not unnecessarily enable harm to users who have not updated.

What if the problem only affects KernelSU Next or another fork?

Report it privately to the affected fork’s maintainer. Notify upstream KernelSU privately only when shared or inherited code may also be vulnerable. Name the exact repository and commit so maintainers do not waste time investigating the wrong codebase.

Will reporting or fixing the issue restore banking-app compatibility?

Not necessarily. Banking and other sensitive apps use Play Integrity plus their own detection and risk controls. A KernelSU security fix is not a promise that any specific app will accept a rooted or bootloader-unlocked device.

Do I need to flash KernelSU to make a report?

No. Static source analysis may be sufficient, and dangerous reproduction should not be attempted merely to make a report look complete. If device testing is essential, use your own recoverable test hardware, back up first and document every modification.

How long should I wait before disclosing the vulnerability?

KernelSU’s verified reporting information does not establish a universal public deadline. Propose a reasonable date, consider exploitability and patch availability, and coordinate with the maintainer. If communication stops, send a concise private follow-up before changing the disclosure plan.

Modules, apps & files to try

Here are the actual tools the rooting community uses for this, each linked to its official source. They're third-party community projects, so download only from the official page below, back up your boot.img first, and follow each project's own instructions. PrivacyPortal isn't affiliated with these projects and can't guarantee third-party files — flash at your own risk.

File	What it is & how to use it safely
KernelSU (GITHUB)	The original kernel-based root manager — implements root as a kernel module rather than patching the boot ramdisk like Magisk; needs a GKI 2.0 or KernelSU-supported kernel. Official open-source (GPL) project, actively maintained — latest KernelSU v3.2.4 (Apr 2026). Kernel-level root requires a GKI 2.0 / kernel 5.10+ device (older 4.14+ kernels need a manually built kernel). Only download from the official GitHub Releases page (github.com/tiann/KernelSU/releases), never a Telegram link or mirror; verify the .apk/kernel matches your exact device and back up your boot.img before flashing, as a bad kernel image can bootloop the device. The companion KernelSU-Next fork (github.com/KernelSU-Next/KernelSU-Next) is also legitimate and supports wider kernel ranges (4.4–6.6).
SUSFS (GITLAB)	Kernel-level filesystem-hiding patch (VFS layer) that hides root-related files and mounts from apps; requires kernel support and is applied via the patched kernel. SUSFS is a kernel-level patch, not a one-click app — it requires a SUSFS-patched kernel, so back up your boot.img/stock kernel before flashing and only use the official simonpunk GitLab repo or a reputable pre-patched kernel. Upstream calls it experimental; a bad flash can bootloop your device.