CVE-2021-26084: Atlassian Confluence OGNL injection, unauthenticated RCE, actively exploited
The short version: CVE-2021-26084 is an OGNL injection vulnerability in Atlassian Confluence Server and Data Center. An unauthenticated attacker sends a crafted request and executes arbitrary code on the server — no login required. It scores 9.8, it's in CISA's KEV catalog, and it was exploited at scale within days of disclosure. If you run self-hosted Confluence, this is patch-and-verify. Steady hands, but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~99.99% · 99.99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2021-11-17 |
| Known exploited? | Yes — mass exploitation (coin miners, then ransomware) |
| Vulnerability type | CWE-917 expression-language (OGNL) injection → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | Confluence Server & Data Center: before 6.13.23; 6.14.0–7.4.10; 7.5.0–7.11.5; 7.12.0–7.12.4 |
| Fixed in | 6.13.23 · 7.4.11 · 7.11.6 · 7.12.5 · 7.13.0 (and later) |
What you need to know
Confluence's Webwork engine mishandled a crafted OGNL (Object-Graph Navigation Language) expression, letting an attacker inject code that the server then evaluates. The result is arbitrary code execution on the Confluence host, reachable by anyone who can send it an HTTP request.
Two things make this one a top-of-queue item:
- It's unauthenticated and trivially reachable. Confluence is a collaboration server, usually internet-facing for remote staff — no credential, no chain.
- It went from advisory to mass exploitation in days. Public proof-of-concept code appeared almost immediately; early campaigns dropped coin miners, and ransomware operators followed. CISA issued its own alert within a week.
How serious we see it
High — the 9.8 is earned here.
Unauthenticated, network-reachable code execution on a server that typically holds internal documentation, credentials, and project data is as bad as external exposure gets. The bounded, reassuring part: it affects specific Confluence builds, the fixes are published, and you can tell quickly whether you're exposed. The catch is the usual one for a mass-exploited flaw — an appliance that sat unpatched during the exploitation window may already have been touched, so patched and clean are separate questions.
Recommendations
Straight from Atlassian's advisory and CISA:
- Patch now. Upgrade to 6.13.23 / 7.4.11 / 7.11.6 / 7.12.5 / 7.13.0 or later. Atlassian recommends moving to the latest 7.13.x long-term-support line.
- Hunt for prior use. Review access and application logs for anomalous requests to Confluence endpoints and for coin-miner or web-shell artifacts on the host.
- If you find indicators, respond fully. Rebuild the host and rotate credentials, tokens, and secrets that lived on or were reachable from it.
- Harden exposure. Restrict who can reach Confluence from the internet; keep it behind SSO/VPN where feasible.
- Confirm your exposure first. Verify whether you run an affected self-hosted Confluence build (Confluence Cloud is not affected).
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing Confluence instances, fingerprints the product and version, and flags exposure tied to KEV-listed, actively exploited vulnerabilities like this one — pushed to the top of your results because it's in KEV. We identify and flag the affected version; we don't exploit it.
That continuous, attacker's-eye view is the point: when a Confluence server is standing on the internet at a vulnerable build, it's already mapped, so you can go straight to patch-and-verify instead of hunting through an asset inventory.