SUDO_KILLER: Auditing sudo Misconfigurations Before You Exploit Them

What SUDO_KILLER Is Actually For

The README frames the audience narrowly: pentesters, security auditors, system admins, CTF players and Infosec students. The problem it addresses is that sudo misconfiguration is diffuse. A host may be vulnerable through a bad rule in /etc/sudoers, through the sudo version itself, through a third-party application that sudo can launch, or through a binary listed in GTFOBINS. Checking those by hand is slow and inconsistent, and the failure mode is a missed path rather than a crash.

SUDO_KILLER's stated checks cover misconfigurations, dangerous binaries from GTFOBINS, vulnerable sudo versions with associated CVEs, sudo issues tied to third-party apps, dangerous environment variables, credential harvesting, writable directories where scripts reside, binaries that might be replaced, and missing scripts referenced by sudo rules. The README explicitly warns that this list is not exhaustive, which is the honest framing: it is a catalogue, not a completeness proof.

The design decision worth noting is the refusal to exploit. The README says the tool "refrains from automated exploitation, requiring users to carry out the exploitation process themselves." For an auditor that is a feature. For someone hoping to run one command and get a root shell, it is a disappointment, and the README does not pretend otherwise.

How the Checks Map to Real sudo Weaknesses

The tool is a Shell script, SUDO_KILLERv3.sh at the repository root, so there is no daemon, no agent and no compiled artefact. Everything runs from the host being audited, which matters because the checks are local by nature: sudo rules, environment variables and filesystem permissions are only visible from inside the machine.

The CVE logic carries a distinction the README spells out. When the -c argument is used, two kinds of check are produced. One flags a CVE based solely on the sudo version in use. The other additionally verifies the requirements needed for exploitation. The README is direct about why that matters: "Very often, a sudo version might be vulnerable but some pre-requisites might be needed for a successful exploitation." A version-only hit is a lead, not a finding, and treating it as a finding is the most common way to waste an engagement.

The repository layout reflects the split. There is a CVE/ directory, a dbins/ directory that presumably holds binary data for the GTFOBINS-style checks, and SK-Tools/ alongside notes/ and res/. The README does not document the internal structure of those directories, so anyone wanting to extend the checks will be reading the script rather than a specification.

Installing SUDO_KILLER and Running a First Audit

The README gives two acquisition routes: git clone or download the zip. There is no package manager entry, no install script and no dependency list documented, so the practical requirement is a Unix-like host with sudo present and a shell to run the script in.

The documented invocation combines several flags. The -c flag adds CVE checks, -a adds CVEs related to third-party apps and devices, -e exports sudo rules and the sudoers file, -r names the report, and -p sets the path where the export and report are written.

./SUDO_KILLERv<version>.sh -c -a -e -r report.txt -p /tmp

After it finishes, the report named report.txt should be present under /tmp along with the exported sudo rules, assuming the export succeeded. The README does not state what the report format looks like or which fields it contains.

If sudo -l prompts for a password, the script needs that password supplied up front. The README is unambiguous: "If a password is needed to run sudo -l then the script will not work if you don't provide a password with the argument -s."

./SUDO_KILLERv<version>.sh -c -e -r report.txt -p /tmp -s

For anyone who wants to try the checks without pointing them at production, the README documents Docker images built for that purpose. The main demo image is pulled and run interactively:

service docker start
docker pull th3xace/sudo_killer_demo3
docker run --rm -it th3xace/sudo_killer_demo3

Inside that container, the README describes a switchScenario command taking a scenario number from 0 to 10, with each number mapping to a different weakness such as excessive permissions, user impersonation, wildcard misconfiguration, dangerous environment variables, dangerous binaries, environment path hijacking, or credential capture. Scenario 0 is flagged as potentially conflicting. Two narrower images exist as well: sudo_killer_demo2 for CVE-2019-18634 (pwfeedback), run with --user 1000, and a separate repository, pr0v3rbs/CVE-2025-32463_chwoot, whose run.sh builds a container for the chwoot vulnerability. The README also mentions an offline mode, -i, which imports from extract.sh, though it does not document extract.sh itself.

Where SUDO_KILLER Stops Being the Right Tool

The password dependency is the sharpest limitation. The README notes that by default, if the NOPASSWD tag applies to any entry for a user on a host, sudo -l runs without a password, and that this can be overridden through the verifypw and listpw options. It also notes that sometimes /etc/sudoers can be read even when sudo -l is not accessible without a password. Those are the favourable cases. In the unfavourable case, an operator who cannot supply -s gets a degraded run, and the README says the script simply will not work.

The second boundary is scope. SUDO_KILLER is about sudo. A host where privilege escalation runs through a SUID binary, a cron job, a writable systemd unit or a kernel bug is outside what the README claims to cover, and the non-exhaustive warning on the check list should be read literally. Running it and finding nothing is not evidence that a host is clean.

The third is that it does not exploit. On a time-boxed engagement where the deliverable is a shell, the tool produces a reading list. That is the intended usage, but it means the effort of turning a hit into access falls entirely on the operator, and the README offers no walkthroughs beyond the Docker scenarios.

SUDO_KILLER Versus linpeas and Manual sudo -l Review

The obvious comparison is linpeas, the enumeration script that many testers run first on a Linux target. The difference is breadth against depth. linpeas sweeps a wide range of local privilege escalation vectors across the whole system. SUDO_KILLER concentrates on sudo and goes deeper inside that one area, with version-specific CVE logic that separates a bare version match from a version match with the prerequisites confirmed. If sudo is the suspected path, the second is more useful. If you do not yet know where the path is, the first covers more ground.

The other alternative is doing it by hand: read sudo -l, cross-reference each permitted command against GTFOBINS, check the sudo version against published CVEs, and inspect environment variables that sudo preserves. That is exactly the checklist SUDO_KILLER automates, and the argument for the tool is consistency rather than capability. A careful operator will reach the same conclusions on a simple host. On a host with a dozen sudo rules and a third-party application in the mix, the script will not forget an entry at the end of a long day.

One more difference is worth stating plainly. Both linpeas and manual review leave exploitation to the operator as well, so SUDO_KILLER's no-automation stance is not unusual in this category. It is the norm, and the README treats it as a deliberate design choice rather than a missing feature.

Maintenance, Licence and the Cost of Keeping Up

The repository is not archived, and the last push to the V3 branch was on 2026-03-11. The README carries a badge reading "Maintain-Yes" and a version badge of 3.0.2, and there is a CHANGELOG.md at the root for anyone who wants the history rather than the claim. There are no retrieved releases, so the changelog and the branch itself are the record.

The upgrade cost is shaped by what the tool depends on. CVE coverage has to be refreshed as new sudo vulnerabilities are published, and the README's own example set spans CVE-2019-18634 through CVE-2025-32463, which shows the maintenance burden is continuous rather than occasional. GTFOBINS entries change too, and the dbins/ directory is where that data appears to live. Because the project is a single Shell script plus data directories, pulling a newer revision is cheap; the expensive part is trusting that the data is current.

The licence is MIT, stated in the README badge and present as a LICENSE file at the repository root. In practical terms that is a permissive licence, and the README adds a Disclaimer section that anyone planning to run this against systems they do not own should read before the licence question even arises. Nothing here is legal advice; read the LICENSE and the Disclaimer yourself.

Editorial conclusion

Adopt SUDO_KILLER if you are doing authorised Linux privilege escalation work and want a structured starting point instead of reading sudo -l output by hand. Do not adopt it if you need automated exploitation, if you cannot pass a password with -s, or if the target is not a Unix-like host with sudo in play. Before running it anywhere, verify that /etc/sudoers is readable or that you hold credentials for the -s argument, because the README states the script will not work when sudo -l demands a password you have not supplied.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. TH3xACE/SUDO_KILLER on GitHub