Magisk vs KernelSU vs APatch: Best Root Manager 2026

If you want to root an Android phone in 2026, the real decision behind magisk vs kernelsu (and the third contender, APatch) is rarely "which one is best" in the abstract. It is "which one actually works on my exact device, and what am I trading away to get it." All three are mature, actively maintained root managers, but they patch your phone in very different places, support different hardware, and behave differently when you later want to hide root from a banking app. This guide explains how each one works, where each shines, and the honest risks before you unlock anything.

A blunt warning up front, because this content can brick a device: rooting requires unlocking the bootloader, and on almost every phone that wipes all your data and is partly or wholly irreversible. Back up everything first. It also voids warranty, can break OTA updates and some banking or payment apps, and meaningfully expands your device's attack surface. Read the risks section before you act.

The short answer

• Magisk if you want the widest device support and by far the biggest module library.
• KernelSU-Next if your device runs a supported GKI or maintained custom kernel and hiding root matters most.
• APatch if you want kernel-level root on an ARM64 device without rebuilding a kernel.
• Stay unrooted if banking apps, a work profile or reliable over-the-air updates are essential to you. That is a legitimate answer, and for a lot of people it is the right one.

None of the three guarantees Play Integrity, banking-app access or a safe installation on your particular model. Your phone, your kernel and your reason for rooting matter more than any universal ranking.

What a root manager actually does

"Rooting" means giving apps (with your permission) superuser access to the Android system. A root manager is the tool that grants and controls that access, and that hosts modules — small packages that tweak the system without permanently editing it. The three managers differ mainly in where they hook into the system:

• Magisk patches the boot image in userspace. It is the classic, broadest-compatibility approach.
• KernelSU (and its forks) operates at the kernel level, giving the tightest control over which apps can even see that root exists.
• APatch sits in between: it patches the boot image like Magisk, but injects kernel patches at runtime, without rebuilding the kernel.

Every one of them needs an unlocked bootloader. None can work on a device that cannot be unlocked at all (more on Samsung below).

Magisk: the default for most people

Magisk, maintained by topjohnwu, is the long-standing standard. It works by patching your phone's boot image (or init_boot on newer devices) and running in userspace, which is why it supports the widest range of hardware regardless of kernel version. The latest stable is v30.7 (released around February 2026), which adds Android 16 QPR2 sepolicy support, Zygisk support for Android XR, and other fixes; the project has rewritten a large share of its native code in Rust over recent releases. (Note: vendor_boot partition support actually arrived back in v30.3, not v30.7 — worth knowing if you are chasing a specific feature.)

Magisk's strengths are its enormous module ecosystem (by far the largest of the three) and its built-in hiding tooling: Zygisk (its Zygote-injection framework), a DenyList, and the option to hide the Magisk app itself. Because it never rewrites the system partition, it is also the least disruptive of the three to undo. For a first-time rooter on a mainstream phone — a Pixel especially — Magisk is the path of least resistance.

The one thing Magisk structurally cannot do is add kernel features. It does not replace the kernel, so kernel-side capabilities such as native SUSFS are not something you can bolt on as an ordinary Magisk feature. It also tends to leave more userspace signals for a determined app to inspect.

Magisk Alpha: what you are actually installing

There is also Magisk Alpha, a bleeding-edge community build that ships hiding and Zygisk fixes ahead of stable. It is popular with people chasing maximum stealth, but it is unofficial: it is distributed separately from the official project and is not the same trust decision as the open-source Magisk repository. Treat it as advanced-user territory, review its source status, distribution channel and current community reports before installing it, and be aware that if something breaks you are troubleshooting a build the upstream project does not support.

Alpha makes most sense when your device has no viable KernelSU-Next route, or when you already have a Magisk module stack you do not want to rebuild. Its very large user base is a practical advantage: faults tend to be easy to research.

KernelSU and its forks: kernel-level control

KernelSU takes a fundamentally different approach: root lives in the kernel itself, which gives it a cleaner permission model and strong app isolation. Permission decisions are made in kernel space, so only the apps you have approved should ever receive root, and the userspace footprint is smaller. The trade-off is hardware support. The original KernelSU (tiann/KernelSU) dropped non-GKI support and now officially targets GKI kernels 5.10 and newer only — which in practice means phones that launched on Android 12 or later.

Most people today actually use a fork rather than the original:

• KernelSU-Next (KSUN) — the most active fork, latest v3.2.0 (April 2026). It supports GKI 5.10–6.6 and, in LTS mode, even non-GKI 4.4–5.4 kernels, and ships pre-built GKI images. It also offers an LKM mode on supported GKI devices that injects a loadable kernel module into the boot image without replacing the whole kernel — a simpler install and a much easier OTA path. (LKM mode requires a GKI kernel with LKM support; it is not available everywhere.)
• SukiSU-Ultra — another active fork that adds KPM (kernel patch module) support ported from APatch and focuses heavily on SUSFS-based stealth.

Compatibility is the constraint that catches people out, and it is stricter than the marketing suggests. A boot image or kernel built for another device can fail immediately. Even an image for the same model can be wrong if it targets a different security patch level — and when kernel modules do not match the vendor blobs, the symptoms are things like Wi-Fi, the cameras or touch input silently not working. Before you flash anything, confirm the exact kernel version, Android build number and security patch date against the project documentation and your device maintainer's notes. A matching phone name is not evidence.

One important behaviour change: KernelSU v3.0+ and the major forks removed built-in module mounting for system-file modifications. If a module needs to modify /system via overlayfs, you must install a metamodule (such as meta-overlayfs) first. Modules that only use scripts, sepolicy rules, system.prop, or service.sh do not need it — so the often-repeated "you must install a metamodule before anything works" is an overstatement.

APatch: the flexible middle ground

APatch (bmax121/APatch) patches the boot image like Magisk but injects kernel patches at runtime, so no kernel rebuild is required. It is ARM64-only and supports a very wide kernel range, currently 3.18–6.12 per the official documentation. That makes it genuinely useful for older or non-GKI devices where KernelSU's original branch will not run but you still want kernel-level capabilities. The patch its manager applies adds the KernelPatch and AndroidPatch components to your existing boot image, which is why it can work where no ready-made KernelSU-Next kernel exists for your device.

APatch supports two module types: APM (Magisk-compatible modules) and KPM (kernel-space modules). KPMs are the part to respect: they run with kernel privilege, so a faulty or hostile KPM can compromise the entire device, not just an app. Install only modules whose origin and maintenance you can actually assess, and keep a clean stock boot image ready before you experiment.

It is very much alive — the latest tagged build is from June 2026, so anyone who tells you APatch "died in 2024" is working from stale information. During install you set a SuperKey — a password you choose inside the APatch Manager (8–63 characters). There is no "SuperKey file" to download; if a guide tells you to fetch one, that guide is wrong.

PrivacyPortal verification on 12 August 2026 found APatch, KernelSU-Next and Magisk Alpha all active and maintained; none of them guaranteed Play Integrity or banking-app access.

The "APatch is an app patcher" myth

A persistent piece of misinformation — including in older guides on this site, which is why this page now replaces them — describes APatch as an app-level tool that modifies individual APKs and "does not require root". That is wrong, and it is worth being blunt about it because acting on it will waste your time.

APatch is a device-wide, kernel-level root manager. It requires an unlocked bootloader exactly like Magisk and KernelSU, it patches a boot image, and it grants superuser access system-wide through its own manager app. It is not an APK modification tool, it is not a sandbox for testing apps, and there is no configuration in which it works on a locked device. The confusion probably comes from the name resembling generic "app patcher" utilities; they are unrelated projects.

Magisk vs KernelSU vs APatch: comparison table

Aspect	Magisk	KernelSU / forks	APatch
Where it hooks	Boot image, userspace	Kernel	Boot image + runtime kernel patches
Kernel rebuild needed	No	Sometimes (GKI image / LKM mode avoids it)	No
Device support	Broadest	GKI 5.10+ (KSUN adds 4.4–5.4 LTS)	ARM64, kernel 3.18–6.12
Module ecosystem	Largest	Smaller, mostly Magisk-compatible	Smallest (APM + KPM)
Built-in Zygisk	Yes	No — needs Zygisk Next or ReZygisk	No — needs Zygisk Next or ReZygisk
Deepest hiding	Zygisk + DenyList + Shamiko	+ SUSFS (KSUN / SukiSU-Ultra)	ZygiskNext-based
Best for	Beginners, mainstream phones	Newer devices, max stealth	Older/non-GKI ARM64 devices

One thing that catches people out: you cannot run Magisk and KernelSU/APatch on the same slot at once. KernelSU's module system conflicts with Magisk's magic mount, so one will simply stop working. Pick one per device.

What you need before you start

Whichever manager you choose, the preparation is nearly identical, and skipping it is what turns a reversible mistake into a dead phone.

Prerequisite	Magisk / Alpha	KernelSU / forks	APatch
Unlockable, unlocked bootloader	Required	Required	Required
Full factory firmware for your exact build	Required	Required	Required
Stock boot/init_boot image kept off the phone	Required	Required	Required
Platform tools (adb/fastboot) and USB driver	Required	Required	Required
Knowing which partition to patch (boot vs init_boot)	Required — never guess	Route-dependent	Required — never guess
Kernel source or a prebuilt matching kernel	Not needed	Needed unless using a prebuilt GKI or LKM route	Not needed
ARM64 device	Not strictly	In practice yes	Yes — ARM64 only

Bootloader unlocking wipes user data by design. It may affect warranty support, and it genuinely weakens the device's physical security, because a modified image can then be booted on it. Those are not theoretical trade-offs — decide whether you accept them before you start, not halfway through. Our guide to why you need to unlock the bootloader when rooting with Magisk covers the process in more detail; device-specific instructions from your OEM or maintainer always take priority over any general guide, including ours.

Android's official verified boot documentation requires user-data erasure when a device moves from a locked to an unlocked bootloader state. Any guide promising an unlock "without losing data" on a mainstream phone should be treated as false.

How to install and test a root manager safely

This is a recovery-first order of operations. It does not assume every device uses the same partition layout, and it deliberately front-loads the boring steps.

1. Back up photos, messages, authenticator recovery codes and app data to a separate device. Authenticator seeds especially — losing those is worse than losing the phone.
2. Record the full model number, build number, security patch date and active slot. Download the matching factory firmware.
3. Read your manufacturer's own unlocking process. Unlock the bootloader and let the required factory reset finish completely.
4. Restore only the data you need for testing. Confirm that stock Android boots normally and that fastboot access still works.
5. Choose one root manager. Do not install Magisk, KernelSU-Next and APatch together — they conflict.
6. Extract the exact boot or init_boot image named by that project's instructions for your device. On a Pixel running Android 13 or newer, that is init_boot.img, not boot.img.
7. Patch the image with the Magisk or APatch manager app. For KernelSU-Next, use only a documented GKI, LKM or custom-kernel route for your device.
8. Test-boot the patched image first if your device supports booting an image without flashing it. Otherwise follow the device-specific flashing instructions exactly.
9. Open the manager and approve root for one harmless test app only. Reject anything you did not expect to ask.
10. Reboot twice, then test calls, mobile data, cameras, Wi-Fi, encryption and your important apps before you install a single module.

How to verify the installation

The manager app should show its installed root component and the version you expect. A root checker can confirm that a request was granted, but it cannot prove the installation is safe or complete.

After a cold start, check for Android Verified Boot warnings, confirm storage encryption is still active, then review the manager's superuser log and revoke every test grant you made. Keep automatic system updates switched off until you understand your project's OTA process — an update can replace the patched image, and on some devices it can leave the phone unable to boot.

Modules, Zygisk and the common compatibility traps

Magisk modules are not automatically safe on KernelSU-Next or APatch, even though both accept Magisk-style modules. Install only modules marked as supporting your root family, add one module at a time, and reboot after each one. That discipline is the difference between "I know which module broke my phone" and a full reflash.

Zygisk is the other trap. Magisk has it built in; KernelSU and APatch do not, so they need an add-on. Zygisk Next is the established option, and ReZygisk is a community reimplementation intended to work across several root systems. They are alternatives, not companions, and module compatibility differs between them — Shamiko in particular has historically required Zygisk Next rather than ReZygisk. Some combinations also behave differently with an enforced DenyList. Check the current release notes for every piece before you combine them, rather than copying someone else's stack from a forum post.

Never flash a bundle of "essential" modules in one pass. If the phone fails to boot afterwards you will have no idea which one did it, and your only route back is the project's safe mode or a recovery flash. Start with the manager app alone, and add a Zygisk implementation only when a module you actually need requires it.

Hiding root, banking apps and Play Integrity in 2026

This is where most readers' real question lives, so let's be precise and honest. Hiding root is an ongoing arms race; nothing here is guaranteed against any specific app, and detection logic changes server-side without warning.

The typical hiding stack is: Zygisk (built into Magisk, or ZygiskNext for KernelSU/APatch), plus a Play Integrity spoofing module, plus a hiding module such as Shamiko or the FOSS Zygisk-Assistant, plus adding sensitive apps to the DenyList or app profiles. KernelSU-Next and SukiSU-Ultra additionally support SUSFS, a kernel-level layer that hides root mount points and traces inside the kernel rather than userspace — currently the strongest stealth method available, and a genuine advantage of the kernel-based managers.

It also helps to understand that "detecting root" is not one check. An app can look at bootloader state, ROM build properties, mounted filesystems, process behaviour and hardware-backed attestation, and those are largely independent signals. Kernel-level root can remove a lot of the common userspace traces, but it cannot change the fact that your bootloader is unlocked. A custom ROM adds its own separate clues, which is why stock firmware plus root is usually easier to troubleshoot than a custom ROM plus root when an app starts refusing to run.

Google grades devices on three Play Integrity tiers. With the right stack, Basic and Device integrity are achievable on a rooted phone. Strong integrity is essentially closed to rooted devices: it requires hardware-backed key attestation, and Google completed its mandatory RKP (remote key provisioning) migration by April 2026. That made older leaked OEM keyboxes non-functional on hardware that supports RKP — which broadly means devices that shipped with Android 13 or later, not merely devices upgraded to it. A small but growing set of apps demand Strong integrity, and on those, rooted devices currently cannot pass.

Play Integrity results can also change with no local update at all, because the rules and key status live on Google's servers. Passing a test app today proves very little about whether a bank, wallet or payment app will accept the phone next month. The practical rule: never rely on root hiding for access to your money. Keep an unmodified device or a second route to anything you genuinely cannot afford to lose access to.

On keyboxes: a keybox is a device-specific key provisioned in the TEE at manufacture. It cannot be extracted from a phone, so anyone selling an "extracted keybox" is running a scam. Valid keyboxes get revoked, and we won't promise any method defeats a particular bank.

On 12 July 2026, our own guide author Yuri personally moved back to Magisk while still rating KernelSU and its forks as the stronger root-hiding path — a reminder that "best at hiding" and "best to live with" are different questions.

The real risks before you root

• Data wipe. Unlocking the bootloader factory-resets the device on all major OEMs. Back up first.
• Bricking. A wrong or mismatched boot image causes a bootloop (usually recoverable by flashing the stock image — keep it). Xiaomi's Anti-Rollback Protection can cause a permanent lockout if you downgrade firmware; check ARB before flashing anything older.
• Samsung Knox e-fuse. Unlocking any unlockable Samsung permanently trips the Knox fuse, killing Samsung Pay, Secure Folder and some enterprise features forever — even if you re-lock.
• Newer Samsung cannot be rooted at all. Devices shipped with or updated to One UI 8 (Android 16) have had bootloader unlock removed from the bootloader binary. This is a firmware-level block, not a hidden toggle. It affects new purchases in that era and older devices that update to One UI 8.
• OTA and warranty. Updates need a tool-specific procedure or your phone may not boot; rooting voids warranty on virtually every OEM.
• Security. Root means any app you grant su to has full control, and a malicious kernel module has kernel-level access. Only install modules from sources you trust.
• Certification loss. Unlocked devices may show "Device not certified" and lose some DRM content (e.g. HD streaming).

Failure modes and how to recover

Most root problems fall into a small number of shapes, and each has a standard first move:

• Boot loop. Restore the exact stock image you saved, or disable the most recently added module through the project's safe mode.
• No mobile signal or Wi-Fi. Suspect a mismatched kernel or vendor module set — the kernel booted, but it does not match the rest of your firmware.
• Manager reports no root. Check the active slot and confirm you flashed the partition the project actually named.
• OTA update fails. Restore stock images and follow your root project's documented update procedure rather than forcing the update.
• Apps suddenly stop working. Remove recently added modules first, before you start changing several hiding settings at once and lose track of the cause.
• Lost data. After an unlock or an encryption failure, recovery is often simply impossible. This is why step one is a backup.

One more, because it destroys phones regularly: do not relock the bootloader while modified images are installed. Some devices will then refuse to boot at all; others will wipe again. Return every partition to matching stock firmware first, verify it boots, and only then consider relocking.

If all you actually wanted was a more private phone, it is worth comparing this against our Android privacy guide without root — a large share of the privacy gains people root for do not need privileged access at all.

Which root manager should you choose?

Remember you are modifying your own device, and the right answer depends entirely on your hardware and goals:

• Mainstream phone, first time, want the biggest module library? Choose Magisk. On a Pixel (Android 13+), patch init_boot.img, not boot.img.
• Newer GKI device (Android 12+) wanting the cleanest model and best stealth? Choose KernelSU-Next, and add SUSFS if hiding matters. LKM mode makes OTA updates far less painful.
• Older or non-GKI ARM64 device that KernelSU original won't touch? Choose APatch — no kernel rebuild and a wide kernel range.
• Banking, a work profile or dependable OTA updates are non-negotiable? Stay unrooted. There is no configuration of any of these tools that makes that risk go away.

A note on responsibility, since these tools get used for more than customisation: root gives you full control of hardware you own, and that is entirely your right. It does not entitle you to bypass other people's systems, and modifying apps you do not control can breach their terms of service regardless of how you did it. Keep the changes on your own device, and assume anything you modify is your problem to support.

If all of this sounds like a lot of careful, device-specific work — it is. Rooting properly means matching firmware exactly, keeping recovery images, and accepting the trade-offs. If you mainly want a private, de-Googled phone without the risk of bricking your daily driver, PrivacyPortal sells phones set up for privacy out of the box, and we are happy to advise on whether rooting your specific model is even worth it before you wipe anything.

Frequently asked questions

Is KernelSU better than Magisk for hiding root?

It can be, because KernelSU-Next and SukiSU-Ultra support SUSFS, a kernel-level hiding layer Magisk cannot match in userspace. But Magisk with Zygisk + Shamiko still hides from many apps. Neither is guaranteed against a given bank, and Strong integrity is out of reach for both on RKP devices.

Can I switch from Magisk to KernelSU later?

Yes, but not on the same slot at the same time. You fully uninstall one, then install the other's patched boot/kernel image. They conflict if both are active. Remove your modules and restore the matching stock image first, and keep a backup — a failed boot can still force a reset.

Is APatch dead?

No. Despite a quiet patch in 2024, APatch received updates well into 2026 (latest build June 2026) and remains a strong option for older ARM64 and non-GKI devices.

Can I root the latest Samsung Galaxy?

No. Devices on One UI 8 (Android 16) cannot have their bootloaders unlocked at all, so no root manager can run on them. Older, already-unlocked Samsungs are unaffected but have already tripped the Knox fuse.

Will rooting break my banking app?

It might. Hiding stacks help, but app developers update detection server-side, and some apps (certain MDM, government and crypto apps) use detection current modules cannot bypass. Expect occasional breakage that needs module updates. No root method guarantees banking-app support, so never root a device you depend on for payments without another way in.

Does APatch work without root, by patching individual apps?

No — that is a widespread misunderstanding. APatch is a device-wide kernel-level root manager. It needs an unlocked bootloader, it patches a boot image, and it grants system-wide superuser access through its manager app. It is not an APK-modification tool and it does not work on a locked device.

Can Magisk modules run on KernelSU or APatch?

Often, but not automatically. KernelSU forks and APatch both accept Magisk-style modules, yet anything relying on Magisk-specific mounting or on Zygisk may need a compatible build or a Zygisk add-on. Install one module at a time and reboot between each so you can identify a bad one.

Is Magisk Alpha safe to use?

It is widely used, but it is an unofficial build distributed outside the official project, so it is a different trust decision from stable Magisk. If you use it, get it from the channel the maintainer actually publishes on, and accept that upstream will not support problems you hit with it.

How does rooting affect Android updates?

It complicates them on every manager. An OTA can overwrite the patched image and remove root, or leave the device unable to boot if applied the wrong way. KernelSU-Next's LKM mode is the least painful route on supported devices. Keep automatic updates off until you have read your project's OTA procedure for your device.

What is the safest choice for a beginner?

Staying unrooted, honestly. If you do want root, pick the best-documented route for your exact model — usually Magisk on a Pixel — download the full factory firmware first, and practise entering bootloader mode and flashing back to stock before you modify anything.

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
Magisk (GITHUB)	The original and most widely used Android root manager; systemless root via boot-image patching, with built-in Zygisk, a module system and a DenyList for hiding root. Download ONLY from the official repo github.com/topjohnwu/Magisk — its README states GitHub is the sole official source, and third-party "Magisk Manager" sites/APKs are frequently repackaged with malware. Rooting trips Play Integrity and can brick a device: back up your stock boot.img before patching/flashing, and never flash a Magisk ZIP/APK obtained from a Telegram link or random mirror.
KernelSU (GITHUB)	Kernel-based root manager that grants root from inside a kernel module rather than patching the boot image; no native Zygisk, so it pairs with a Zygisk add-on. Confirmed the official open-source repo (verified against kernelsu.org, which links to it). Kernel-based root — it requires a compatible/GKI kernel, so it is more device-specific than Magisk: back up your boot.img/stock firmware before flashing and only download the manager APK and kernel from this GitHub Releases page, never from APK mirrors or Telegram. It ships no native Zygisk, so pair it with a Zygisk add-on. Note a separate community fork, KernelSU-Next, also exists; this entry covers the original.
APatch (GITHUB)	Kernel-level root manager that patches the kernel binary directly and adds its own KPM (Kernel Patch Module) system; a third path distinct from Magisk's init-based and KernelSU's module-based root. Legitimate open-source kernel-based root manager (GPL-3.0, ~7.6k stars), distinct from Magisk/KernelSU. Only download from this official GitHub repo (or F-Droid / apatch.dev) — never third-party APK mirrors or Telegram reposts. Because it patches the kernel directly, ALWAYS back up your stock boot.img before flashing, set a strong superkey (early versions had weak superkey handling that allowed privilege escalation), and keep it updated. Rooting trips banking/Play Integrity checks and carries a real bootloop/brick risk.
SukiSU-Ultra (GITHUB)	A KernelSU fork that adds KPM (Kernel Patch Module) support and auto-updating GKI builds, blending KernelSU's model with APatch-style kernel patch modules. Real, actively maintained open-source KernelSU fork (KPM + built-in SUSFS). It is a kernel/boot-image root solution, so it requires flashing a patched kernel — always back up your stock boot.img first, match the exact build to your device/kernel, and download ONLY from the official GitHub releases page (github.com/SukiSU-Ultra/SukiSU-Ultra). Ignore any Telegram or third-party mirror links.
Zygisk Next (GITHUB)	A standalone reimplementation of Magisk's Zygisk (Zygote injection framework) packaged as a module, enabling Zygisk modules like LSPosed and Shamiko to run on KernelSU and APatch. Reputable, widely-used open-source root module (~9.8k GitHub stars, latest v1.4.0 from 2026, also listed in the official KernelSU module registry). Only download from the official GitHub Releases page and verify the published SHA256 checksum. As with any boot-time root module, back up your boot.img / take a Magisk backup before flashing so you can recover from a bootloop. Note: recent versions moved from GPL-3.0 to a more restrictive license, but it remains free to download and use.
ReZygisk (GITHUB)	A community reimplementation of the Zygisk (Zygote injection) layer, intended to work across several root managers including Magisk, KernelSU and APatch. It is an alternative to Zygisk Next, not something to run alongside it. Open-source project; download only from the official GitHub Releases page and check the release notes for the root manager and Android versions each build supports. Module compatibility differs between the two Zygisk implementations — some modules (Shamiko among them) have historically required Zygisk Next instead — so install one implementation only, add it after your root manager is confirmed working, and be ready to remove it via safe mode if the device fails to boot.
KernelSU-Next (KSUN) (GITHUB)	Actively maintained KernelSU successor/fork by RifsxD with enhanced root hiding, magic mount, manual-hook support for non-GKI kernels, and integrated SUSFS GKI image support. Legitimate open-source (GPL) KernelSU fork — the candidate link rifsxd/KernelSU-Next 301-redirects to the canonical org repo. Actively maintained (v3.2.0, April 2026). Kernel-level root is high-risk: back up your boot.img before flashing, match the manager and kernel module versions, and download ONLY from this official GitHub repo/releases page (or the official kernelsu-next.github.io docs) — never from Telegram or mirror sites. Note the wider KernelSU ecosystem had a manager-impersonation root flaw in an old version, so always run a current release.