Securing Jenkins: Top Attack Flows & Misconfigurations | Wiz Blog

What it is

Wiz's risk analysis of Jenkins across cloud environments, framing which conditions actually lead to compromise rather than just cataloguing vulnerabilities. The load-bearing insight the summary omits: most Jenkins compromises exploit misconfigurations and insecure usage, not software CVEs. That reprioritizes where an engineer should spend time — hardening config beats chasing patches.

Preconditions / Affected

The page adds privilege and exposure figures the summary skips, which determine blast radius:

• 48% of Jenkins-using environments run it on compute with highly privileged service accounts; 21% on compute with administrative privileges. Jenkins also typically has admin-level local execution rights. So a single RCE frequently converts straight into cloud compromise.
• 2% expose critically-vulnerable instances directly to the internet.
• 21% run plugins with critical/high vulnerabilities that have no patch available — meaning patching is not an option; removal or isolation is.

What to do

No commands are given, but the page yields a concrete audit checklist:

Plugins to hunt for by name:

• workflow-cps-global-lib — deprecated, present in 31% of environments.
• extended-choice-parameter — deprecated with known unresolved vulnerabilities, present in 14%.
• Any plugin marked "up for adoption" (treat as effectively end-of-life) or deprecated — these are disproportionately likely to carry 0-days.

Config to enforce: remove anonymous read access, enforce RBAC, tighten service-account scope, restrict internet-facing controllers/agents by IP, stop storing secrets in plaintext or leaking them via environment variables, rotate credentials, sandbox pipeline scripts, and gate untrusted inputs (e.g. pull-request-driven builds).

Infrastructure: don't run controllers with elevated privileges, don't share host namespaces across agents, and do not mount the Docker socket into build environments — any of these lets a Jenkins compromise escape into the host.

flowchart TD
    A[Initial access] --> B{Vector?}
    B -->|Misconfig: anon access,<br/>internet-facing, secrets| C[Foothold]
    B -->|Core CVE / unpatched plugin| C
    C --> D[RCE with admin-level<br/>local execution]
    D --> E{Privileged<br/>service account?}
    E -->|48% yes| F[Cloud compromise]
    E -->|Docker socket mounted| G[Host/container escape]

Caveats

The page is explicit that Jenkins' plugin governance is genuinely strong — signed distribution, security reviews, maintainer-transfer workflows — and states there are no publicly known supply-chain attacks against legitimate Jenkins plugins to date. So the plugin risk here is stale/unmaintained components in your deployment, not a poisoned marketplace. The "Attacks and Attackers" section is cut off in the fetched text, so attacker-attribution detail is unavailable.