lpe-toolkit bundles 29 Linux local privilege escalation techniques into a single multi-architecture Go binary for authorized penetration testers verifying kernel hardening on systems they are permitted to assess.
| Tool | portbuster1337/lpe-toolkit — multi-architecture Linux privilege escalation toolkit aggregating 29 kernel and misconfiguration exploits behind a single CLI |
| Category | Kernel exploitation / privilege escalation testing (C, Go) |
| Primary Use | Verifying whether authorized target hosts running amd64, arm64, 386, mips, mipsle, mips64, or mips64le kernels are patchable against known LPEs, in labs, CTFs, and contracted engagements |
| Safe Use | Educational and documentary analysis: run only in owned labs, CTF environments, or penetration tests with explicit written authorization; --dry-run allows audit of exposure without executing any exploit |
| Telemetry Note | Kernel exploitation of this class leaves distinctive traces — page-cache rewrites of /etc/passwd, dropped setuid helpers at paths like /var/tmp/.suid_bash, D-Bus/package-daemon anomalies, and netfilter/nftables churn — all observable by EDR, auditd, and filesystem integrity monitoring |
lpe-toolkit from portbuster1337 is a C-and-Go aggregation of 29 Linux local privilege escalation primitives, packaged behind a single CLI that detects the running kernel version, filters out exploits patched on that host, and iterates through the remainder. The project has roughly 400 stars and its README is unusually candid about scope and engineering. What distinguishes it from a loose collection of Proof-of-Concept repositories is the delivery model: pre-compiled amd64 exploits are embedded directly in the Go binary via //go:embed, so nothing needs a compiler on the target, while other architectures fall back to runtime compilation through gcc and a set of documented cross-compilers like aarch64-linux-gnu-gcc and mips64el-linux-gnuabi64-gcc.
The architecture section of the README reveals a deliberately small core. toolkit.go holds the exploit definitions, kernel-version parsing, binary resolution, a GTFOBins sudo-abuse handler, an execCommandAsRoot() routine for non-interactive command execution, and the msg()/say() verbosity helpers. main.go is a thin CLI entry point handling flags and signals, and build-exploits.sh drives cross-compilation of the C sources living under exploits/. This separation means the toolkit is essentially a dispatcher: metadata about each exploit, its affected kernel range, and its execution mode lives in tables, with the C code treated as payloads resolved at runtime.
The flag surface is compact and operator-oriented. --dry-run prints the exploitation plan — which exploits are applicable, which are skipped — without executing anything, which is exactly the right first step for an authorized assessment and the only invocation we would demonstrate here. --just-build resolves all exploits and prints paths, useful for packaging verification. --skip accepts a comma-separated list of exploit names to exclude, -c executes a command instead of spawning a shell, -q silences everything except the result, and -v exposes exploit stdout/stderr; -q and -v are mutually exclusive and the toolkit errors if both are given.
The exploit catalogue reads like a timeline of modern Linux kernel LPE research. Classic entries include Dirty Pipe (CVE-2022-0847), PwnKit (CVE-2021-4034), the OverlayFS pair (CVE-2021-3493 and CVE-2023-0386), the Polkit D-Bus race (CVE-2021-3560), and the nftables use-after-free lineage (CVE-2021-22555, CVE-2022-2586, CVE-2024-1086). Alongside these sit newer 2025–2026 research: DirtyDecrypt (CVE-2026-31635), PinTheft combining RDS zerocopy with io_uring, RefluXFS (CVE-2026-64600) racing XFS reflink copy-on-write, CrackArmor (CVE-2026-23268+) abusing an AppArmor confused-deputy against sudo, and several variants of the CVE-2026-43503 ESP page-cache corruption family.
A notable design decision, documented explicitly, is that every exploit — even leak-only or PoC-only ones — has been made end-to-end, meaning it terminates in a root shell or executes the requested command rather than stopping at a kernel information leak. The README describes how page-cache exploits support a --corrupt-only mode to skip an interactive PTY bridge, and how execCommandAsRoot() tries a chain of fallbacks: piping the command to su stdin for shellcode-patched binaries, su - -c with an empty password for passwd-clearing exploits, then setuid helper shells, then sudo -n. Understanding this chain matters to defenders as much as to operators, because the fallback artifacts are detectable.
The maintainers are equally transparent about what they excluded and why, which is a strong signal of engineering discipline rather than blind aggregation. CVE-2026-80844 and relatives were left out because only heavily groomed, target-pinned PoCs exist that demand exact kernel versions and vCPU/RAM shapes; CVE-2026-53362 was excluded because its working chain requires CAP_NET_RAW plus KVM/amdgpu stages and defaults to denial-of-service on stock Debian/Ubuntu; CVE-2026-3888 was dropped for its 10–30 day time-gated trigger. Only deterministic, non-grooming techniques made the cut, which the README advertises as a feature of the 2026 additions.
Several exploit entries carry target-specific caveats that authorized testers must internalize before use. bad_epoll.c (CVE-2026-46242) ships default offsets pinned to a specific lts-6.12.67 kernelCTF target and requires customizing OFF_* and PIVOT* defines plus readable /proc/kallsyms; the README notes the upstream fix commit a6dc643c6931 (adding ep_clear_and_put) has already been backported widely, including to Ubuntu 22.04's 6.8 HWE kernel. Similarly, snapconfine (CVE-2026-8933) needs a specific Ubuntu configuration with set-cap snap-confine, the Firefox snap, FUSE, and running udevd — a reminder that several of these are environmental races, not universal keys.
From a defensive-research standpoint, the toolkit doubles as a patch-verification harness. Running ./lpe-toolkit --dry-run on a fleet sample tells a blue team exactly which of 29 known escalation paths the host's kernel version admits, turning an otherwise scattered corpus of individual PoCs into a single auditable checklist. Conversely, the telemetry profile is rich: page-cache overwrites of /etc/passwd and /etc/shadow, dropped setuid helpers under /var/tmp, PackageKit and accounts-daemon D-Bus races, and netfilter/nftables configuration churn are all classes of event that auditd, file-integrity monitoring, and EDR agents can be tuned to catch.
Build plumbing is conventional. make produces a native statically linked Go binary with the C exploits pre-compiled and embedded; make build-all cross-compiles for every supported architecture using the C toolchain only of the native arch; make run-source runs directly from source with runtime compilation on the target; make clean removes artifacts. Requirements are Go 1.21+, gcc, and the per-architecture cross-compilers listed in the README. The release archive ships all exploits pre-compiled for all architectures, and --just-build lets a packaging engineer confirm exactly which binaries resolved before shipping anything.
The GTFOBins entry, number 29 in the table, is qualitatively different from the kernel exploits: it is a Go-side handler covering 80+ passwordless-sudo misconfiguration techniques rather than a memory-corruption payload. Its inclusion is sensible — in real engagements the boring sudo misconfiguration is a far more common root cause than a fresh kernel UAF — and it rounds out the toolkit as a general escalation audit rather than purely a kernel-exploit launcher.
Caveats worth flagging: the repository declares no license, which matters for anyone redistributing or embedding it in commercial tooling, and the mixture of bleeding-edge 2026 CVEs with target-pinned offsets means results are kernel-build-sensitive. The parseKernelVersion fix noted in the changelog — adding parseIntPrefix to handle -rcN suffixes — illustrates how subtle version-comparison bugs can silently skip applicable exploits or attempt inapplicable ones, so --dry-run output should always be sanity-checked against uname -r.
Used inside its stated lane — CTF practice, owned lab kernels, and contracted penetration tests with written authorization — lpe-toolkit is a genuinely useful consolidation of a research area that is otherwise spread across dozens of individual repositories. For defenders, it is equally valuable as a map of what a motivated low-privilege user can attempt against an unpatched host, and as a concrete prompt to verify that kernel backports landed and that the filesystem artifacts its fallback chain produces would be caught in production monitoring.
portbuster1337/lpe-toolkit.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.