linux-exploit-suggester (LES) does one thing: match your kernel version against known CVEs and suggest exploits. LinPEAS does that too — as a small part of a full-system enumeration. Use LES/LES2 when you want a focused kernel-CVE second opinion; use LinPEAS when you want breadth. And treat every suggestion as a lead to validate, never as a green light — kernel exploits can crash the target.
What linux-exploit-suggester does#
LES takes the output of uname -r (and distro details) and compares it against a database of known kernel CVEs with public exploits, printing the ones that plausibly apply. LES2 is a Perl rewrite of the same idea with its own CVE database. Both are narrow, single-purpose tools: kernel version in, candidate exploits out.
What LinPEAS does about kernels#
LinPEAS includes kernel and software-version checks as one section of a much larger scan (see our kernel checks guide). It flags the kernel version and highlights CVEs it recognises — but it does not try to be an exhaustive exploit database the way LES does.
At a glance#
| LinPEAS | linux-exploit-suggester | LES2 | |
|---|---|---|---|
| Scope | Full system enumeration | Kernel CVEs only | Kernel CVEs only |
| Language | Bash | Bash | Perl |
| CVE database | Built-in, partial | Built-in list | Built-in list (own format) |
| Also finds misconfigs | Yes — its main job | No | No |
| Best for | First-pass breadth | Quick kernel-CVE check | Second opinion on kernels |
A safe workflow for kernel CVEs#
- 1
- 2
- 3
- 4
Version-number matching produces false positives: a kernel can report a "vulnerable" version string while carrying the distro's backported fix. Always validate against the vendor's security tracker before running anything.
One more habit worth building: write down every kernel lead, even the ones you dismiss. Note the CVE, why you ruled it out (backported fix, wrong architecture, needs a config your target lacks), and move on. In longer assessments that log stops you from re-investigating the same dead end twice — and in reports it shows rigorous methodology.
LES2 in practice#
LES2 is a Perl rewrite of the same version-matching idea, with its own CVE database. Usage follows the same shape: make it executable and run it against the target's kernel. Because it is a single Perl script, it runs anywhere Perl exists — handy on minimal targets where you do not want the full LinPEAS run just for a kernel question.
chmod +x linux-exploit-suggester-2.pl
./linux-exploit-suggester-2.plWhat a suggestion looks like#
A LES/LES2 hit typically lists a CVE identifier, the kernel version range it applies to, and any known public exploit references. Read it as a candidate list: it tells you what to research next, not what to run. For each candidate, check whether your distro has already backported the fix, look for the actual vulnerable code path on your kernel, and weigh the crash risk before even downloading an exploit.
Pairing LES with a focused LinPEAS run#
Once LES gives you a kernel lead, you do not need another full LinPEAS run to dig deeper. Re-run just the software and kernel sections:
./linpeas.sh -o software_information,system_information 2>&1 | tee /tmp/kernel2.txtThis keeps the second pass fast and gives you fresh, greppable output for the exact area LES flagged — the same tune-down philosophy behind -s, applied surgically.
Should I run LES instead of LinPEAS?
No — run LinPEAS first for breadth, then LES/LES2 as a focused kernel-CVE cross-check. They answer different questions.
LES says my kernel is vulnerable. Is it?
Maybe. Confirm the distro hasn't backported the fix, reproduce the vulnerable code path if you can, and remember kernel exploits are destabilising — last resort only.
LES vs LES2 — which one?
Both do version-to-CVE matching; LES2 is the Perl rewrite. Running both costs little and a second opinion is useful precisely because each database has gaps.
Sources & references
- PEASS-ng (official) — LinPEAS kernel checks; reviewed 20260908-dffb9496.
- HackTricks: Linux privesc