LinPEAS runs a fixed sequence of read-only checks. It detects the environment, collects system, user, permission, service and file information, correlates that against known escalation patterns, and colours each result by how interesting it is. It never confirms exploitability — the final step, manual verification, is always yours.
The process, stage by stage#
- 1
LinPEAS starts
The script launches under
/bin/sh. It first checks whether you are root, which changes how deep some searches go and which escalation checks make sense. - 2
It detects the environment
OS and architecture, whether you are inside a container (Docker/LXC/containerd), and whether you are on a cloud instance. On macOS it switches to the MacPEAS check set automatically.
- 3
- 4
It checks users and groups
Your identity and groups, other accounts, UID 0 users, login history, and sudo/sudoers configuration including sudo tokens.
- 5
It examines permissions
SUID and SGID binaries, file capabilities, ACLs, ld.so configuration, and writable files — especially writable files owned by root.
- 6
It reviews scheduled work and services
Cron jobs, systemd services and timers, sockets and D-Bus. With
-ait also watches running processes for about a minute to catch frequent jobs. - 7
It searches interesting files
Configuration files, backups, databases, hidden files, logs, and (with
-r) regex searches for passwords, keys and API tokens. - 8
It correlates findings
Results are matched against known escalation techniques and, optionally, a bundled kernel-exploit registry. With
-aor-Vit can query an online service for package vulnerabilities. - 9
It applies highlighting
Each line is coloured by interest — red/yellow for the most promising, down to green for common items matched by name. See the colour guide.
- 10
You verify manually
This is the step that matters most. A highlighted line is a lead. You confirm whether it is actually exploitable in context, only where you are authorised to do so.
Enumeration, not exploitation#
LinPEAS is fundamentally an enumeration and auditing tool. A highlighted result does not prove the machine can be exploited. It tells you where to look. Confirming and abusing a finding is a separate, manual action you take only with authorisation.
This distinction matters for two reasons. First, accuracy: acting on a red line without verifying it wastes time and can break things. Second, ethics and law: enumeration on an authorised target is one thing; exploitation is a deliberate, scoped step. See our security & ethics policy and the defensive overview of Linux privilege escalation.
What it reads vs. what it changes#
| Behaviour | Default | Notes |
|---|---|---|
| Writes findings to disk | No | By default LinPEAS does not save output unless you redirect it. |
| Creates temp files | Only with -a | The 1-minute process monitor uses a temporary file it then deletes. |
| Logs in as other users | No | The su brute force runs only with -a, when not root, and when su works without a TTY. |
| Makes network connections | Yes | Connectivity probes and a host-checker request run by default. See is LinPEAS safe? |
Reviewed against LinPEAS release 20260908-dffb9496. Behaviour can change between releases; check ./linpeas.sh -h for your build.
Sources & references
- PEASS-ng official repository — project source and README
- PEASS-ng latest releases — reviewed release 20260908-dffb9496
- HackTricks: Linux privilege escalation — referenced by LinPEAS output