Quick answer

LinPEAS output is organised into coloured sections. Colour marks how interesting a line is, not whether it is exploitable: red/yellow is highest interest, green is common items matched by name. Start with the brightest highlights, confirm each one manually, and treat everything as a lead until you have verified it.

How the output is structured#

Every run follows the same top-level order, each section framed by a box-drawn title. Understanding the shape helps you jump to what matters.

  • Section title (box with double lines) — a major area such as System Information or Users Information.
  • Sub-section (╔══════════╣) — a specific check, often tagged with MITRE ATT&CK technique IDs in grey.
  • Info line (, italic) — a reference URL explaining the check.
  • Result lines — the actual findings, coloured by interest.

The order and full section list are on the how it works page. You can jump straight to a section by scrolling to its title or by limiting the run with -o.

Why findings are highlighted#

LinPEAS colours lines to tell you where to spend attention. The highlight is a heuristic match against patterns that often indicate an escalation path — not a confirmation. Read the full breakdown on the colour codes page; the short version:

ColourRuntime legendHow to read it
Red/Yellow95% a privilege-escalation vector (runtime legend). The README phrases this as 99%.Highest-interest finding. Investigate first, then manually verify.
RedYou should take a look into it.Suspicious configuration that may lead to escalation. Needs manual review.
GreenCommon things (users, groups, SUID/SGID, mounts, .sh scripts, cronjobs).Matched as commonly-seen BY NAME, not verified as safe by content. Green does not mean secure.
Light CyanUsers with console (shell).Accounts that can log in interactively.
BlueUsers without console and mounted devices.Informational grouping.
Light MagentaYour username.Highlights the current user in the output.
Colour is priority, not proof

Do not read colour as a verdict. Red does not mean “vulnerable” and green does not mean “safe.” Green marks items that are commonly present, matched by name rather than verified by content. A green line can still be part of a real issue; a red line can be a false positive.

Prioritising what to check#

  1. 1

    Start with red/yellow

    These are the highest-confidence leads. Common wins live here: exploitable sudo rules, dangerous SUID binaries, writable root-owned files, and abusable capabilities.

  2. 2

    Then scan red

    Suspicious configurations worth a look. Slower to pay off, but often where real findings hide once the obvious ones are gone.

  3. 3

    Cross-reference the concept

    For each lead, open the matching concept guide (e.g. SUID, sudo, capabilities) to understand whether it is actually abusable here.

  4. 4

    Verify manually

    Reproduce the condition yourself. Only then do you know whether the lead is real — and only act on it where authorised. The privilege-escalation checklist is a good companion here.

False positives and how to spot them#

Because highlighting is pattern-based, expect some noise:

  • A SUID binary that is standard and not abusable in your context (e.g. a patched passwd).
  • A “writable” file that is writable only by root, or in a location that doesn't help you.
  • A sudo rule that looks permissive but is constrained by other settings.
  • A kernel flagged against an exploit registry that is actually patched via backported fixes (common on enterprise distros).
Kernel version ≠ patch level

Enterprise distributions backport security fixes without changing the kernel version string. A version-based kernel-exploit flag can therefore be a false positive. Confirm the actual patch level before trusting it.

Saving and sharing output safely#

Output can contain sensitive data — hostnames, usernames, and (with -r) snippets of credentials. Treat saved output as sensitive.

Save output
./linpeas.sh | tee linpeas.out   # keep colours
less -r linpeas.out
./linpeas.sh -N > linpeas.txt     # plain text for reports
  • Store output only where your engagement rules allow.
  • Redact credentials before sharing in a report.
  • Delete output from the target when the authorised audit ends.

PEASS-ng also ships parsers to convert saved output into JSON, HTML or PDF (peas2json.py, json2html.py, json2pdf.py), which is handy for reporting.

Does red always mean the system is vulnerable?

No. Red and red/yellow indicate high interest, not confirmed exploitability. Every finding needs manual verification.

What does green mean in LinPEAS?

Green marks common items (users, groups, SUID/SGID, mounts, .sh scripts, cron jobs) matched by name. It means 'commonly seen', not 'confirmed safe'.

Why is the output so long?

LinPEAS is thorough by default. Limit it with -o to specific sections, or use -s for a shorter run, and save to a file you can search.

How do I read the colours in a saved file?

Use less -r on a file saved with colours, or save plain text with -N.

Sources & references

  1. linPEAS README (Colors section) — colour legend
  2. PEASS-ng release — runtime legend verified against 20260908-dffb9496
  3. PEASS-ng parsers — JSON/HTML/PDF output tooling