linux-exploit-suggester: Auditing a Linux Kernel for Known Privilege Escalation Exploits

What LES actually answers, and what it refuses to do

The question LES answers is narrow: given this kernel, which publicly known Linux privilege escalation exploits are worth looking at first? The README frames the tool as assisting in detecting security deficiencies on a Linux kernel or Linux-based machine, and the output is a ranked list of CVEs with an exposure judgement attached to each. It does not compile exploits, does not deliver a payload, and does not touch the target beyond reading local state. The audience is a penetration tester or a sysadmin who already has a shell and needs to decide where to spend the next hour, not someone looking for a one-command root.

That restraint is the point. A tool that both identifies and exploits would be far harder to justify running on a production host. LES stays on the identification side, which is why a single shell script is a defensible delivery format for it.

How the exposure heuristic and the Tags field work

The mechanism is a database baked into the script plus a comparison against the running kernel. Each exploit entry carries a Details link, an Exposure state, a Tags string, a Download URL, and a Comments field. The Tags string is where the real logic lives. The README gives this example: `ubuntu=12.04{kernel:3.(2|5).0-(23|29)-generic}`, which it says means the tagged exploit was verified to work on Ubuntu 12.04 with kernels 3.2.0-23-generic, 3.2.0-29-generic, 3.5.0-23-generic and 3.5.0-29-generic. When the current distribution and kernel match a tag, the tool highlights the exploit and bumps its dynamic Rank.

That design has a direct consequence. Coverage is exactly as wide as the tag set contributors have submitted, so an unlisted distribution or a vendor kernel string degrades the ranking rather than producing a false negative you would notice. The four exposure states are the tool's own vocabulary: highly probable means the kernel is most probably affected and the PoC has a good chance of working without major modification, probable means customization is likely needed, less probable means manual analysis is required, and unprobable entries are not displayed at all. The Comments field carries prerequisites, for example that CONFIG_BPF_SYSCALL must be set and kernel.unprivileged_bpf_disabled must not be 1, or that CAP_NET_RAW or CONFIG_USER_NS=y is needed. Those comments are the part of the output most worth reading carefully, because they are the difference between a plausible exploit and a usable one.

Installing LES and running a first audit

There is no package and no build step. The README's quick download is a single wget that writes the script into the current directory under the name les.sh. Nothing is installed system-wide and nothing is compiled.

wget https://raw.githubusercontent.com/mzet-/linux-exploit-suggester/master/linux-exploit-suggester.sh -O les.sh

Make it executable and run it with no arguments to get the exploit exposure list. The README shows the script invoked as `./linux-exploit-suggester.sh`, so rename or invoke accordingly; the output is a sequence of blocks, one per exploit, each with a CVE identifier, a short name, a Details URL, an Exposure line, Tags, a Download URL and Comments.

chmod +x les.sh
./les.sh

The second mode is the hardening audit. Passing --checksec prints kernel protection mechanisms with an Enabled or Disabled marker and a link to a write-up for each feature, covering both compile-time CONFIG options and run-time sysctl settings.

./les.sh --checksec

A third mode takes a uname string instead of inspecting the local host, which is useful when you have the output of `uname -a` from a machine you cannot run the script on. The README shows the form `./linux-exploit-suggester.sh --uname <uname-string>`.

The Tag database is the ceiling on accuracy

The most honest limitation is stated by the project itself. Tags exist because contributors tested an exploit on specific distributions and kernel versions and recorded the result. Where nobody has tested, there is no tag, and the ranking falls back to whatever the entry's other metadata supports. A kernel that is genuinely vulnerable but sits outside every tag will rank lower than it deserves, and the reader has no automatic signal that this happened.

There is a second limitation in the same area. The Download URL often points at an exploit-db entry or a raw PoC from a personal repository, and the README notes that published exploits are frequently written for one or two specific distributions or kernel versions only. A highly probable rating is a statement about the kernel, not about the PoC's portability. The ext-url field exists precisely because someone had to adapt a PoC for additional targets, and the README points to an article on adapting CVE-2017-1000112 as an example of that work.

Finally, LES is the wrong tool outside its scope. It says nothing about userspace misconfiguration, sudo rules, SUID binaries, cron, or container escape. A host with a fully patched kernel and a careless sudoers file will look clean here. It is also not a scanner to run against a fleet on a schedule; it reads local kernel state, so it has to run on each host.

LES compared with a general vulnerability scanner

The nearest alternative category is a host vulnerability scanner such as OpenVAS or a configuration-compliance agent, and the difference is in the data model rather than the interface. A general scanner matches installed package versions against distribution advisories and reports CVEs by package. LES matches a kernel version and distribution string against a curated list of public privilege escalation exploits, and its judgement is about exploitability, not about whether a patch exists.

That produces different answers to different questions. A scanner will tell you that your kernel package is one revision behind and name the advisory. LES will tell you that this kernel matches the tag set for CVE-2016-8655 and that the exploit needs CAP_NET_RAW or CONFIG_USER_NS=y. For a penetration test, the second is more actionable. For patch compliance reporting, the first is the one an auditor wants, and LES has no concept of a patch level. Running both is reasonable; substituting one for the other is not.

checksec.sh is the closer relative for the hardening half. The README describes LES's checksec functionality as a modern continuation of the --kernel switch in Tobias Klein's checksec.sh, extended to cover run-time sysctl settings as well as compile-time CONFIG options.

Maintenance, licence and the cost of keeping LES current

The repository is not archived and the last push was on 2026-03-20. The upgrade model is unusual: because the script is fetched over wget rather than installed from a package manager, there is no version to pin and no upgrade command. Re-running the wget overwrites les.sh with whatever is on master. The practical cost is that you should record which revision you used in a report, since the exploit list and tag set change between fetches.

The larger maintenance cost is not yours, it is the project's, and it is explicitly crowdsourced. The README's contribution section asks readers to add newly published Linux privilege escalation exploits, to test existing exploits across distributions and kernels and document the results as Tags, to adapt PoCs to additional kernel versions and add them as ext-url entries, and to write analyses of kernel hardening features into the FEATURES array with a published write-up under les-res. bcoles is credited for frequent contributions. If nobody does that work, the tool's accuracy decays as new exploits appear and old tags go stale.

On licensing, the repository carries GPL-3.0. The script is redistributed as source, so embedding it in a commercial product or shipping a modified copy brings the usual GPL-3.0 obligations into play. That is a description of the licence file, not legal advice; if you plan to redistribute LES or a derivative, have counsel read the licence.

Editorial conclusion

Adopt LES when you have a shell on a Linux host and need a fast, offline read on which published kernel exploits plausibly apply, or when you want a single command that lists disabled hardening features. Do not adopt it as an exploitation framework or as a substitute for patch management: it downloads nothing and runs nothing. Before trusting the output, confirm the script's Tag heuristic against your exact distribution and kernel string, since the README states that Tags encode only the combinations contributors verified, and check whether the exploit's stated prerequisites (for example CONFIG_BPF_SYSCALL or CAP_NET_RAW) hold on the target.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. The-Z-Labs/linux-exploit-suggester on GitHub