CVE-2022-26134: Atlassian Confluence OGNL injection, unauthenticated RCE, exploited as a zero-day
The short version: CVE-2022-26134 is an OGNL injection vulnerability in Atlassian Confluence Server and Data Center that lets an unauthenticated attacker execute code on the server. It was exploited as a zero-day before Atlassian shipped a fix, it scores 9.8, and it's in CISA's KEV catalog with one of the tightest remediation windows they've issued. If you run self-hosted Confluence, 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 2022-06-06 |
| Known exploited? | Yes — exploited as a zero-day before the patch existed |
| Vulnerability type | CWE-917 expression-language (OGNL) injection → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | Confluence Server & Data Center: 1.3.0–7.4.16; 7.13.0–7.13.6; 7.14.0–7.14.2; 7.15.0–7.15.1; 7.16.0–7.16.3; 7.17.0–7.17.3; 7.18.0 |
| Fixed in | 7.4.17 · 7.13.7 · 7.14.3 · 7.15.2 · 7.16.4 · 7.17.4 · 7.18.1 (and later) |
What you need to know
Like its 2021 predecessor, this is an OGNL injection: a crafted expression in the request URL is evaluated by the server, yielding arbitrary command execution on the Confluence host. What sets it apart is the timeline.
- It was a zero-day. Attackers were using it in the wild before a patch existed — Atlassian and researchers documented active exploitation as the advisory went out.
- The affected range is enormous. Atlassian noted that all supported (and many unsupported) versions were affected, so "we're on an old build" is not a safe assumption.
- It's unauthenticated and internet-reachable. No credential, no user interaction, no chain.
How serious we see it
High — the 9.8 matches the reality.
Unauthenticated remote code execution on an internet-facing collaboration server, confirmed exploited before a fix shipped, is textbook top-of-queue. The reassuring, bounded part is that the fixes are published and exposure is quick to confirm. The catch is the zero-day window: any instance that was internet-facing before you patched should be treated as possibly touched until you've checked.
Recommendations
Straight from Atlassian's advisory and CISA:
- Patch now. Upgrade to 7.4.17 / 7.13.7 / 7.14.3 / 7.15.2 / 7.16.4 / 7.17.4 / 7.18.1 or later.
- Assume nothing given the zero-day window — hunt. Review logs for suspicious requests and check the host for web shells and other implants.
- If you find indicators, respond fully. Rebuild the host and rotate all credentials, tokens, and secrets it could reach.
- Harden exposure. Restrict internet reachability of Confluence; put it behind SSO/VPN where you can.
- Confirm your exposure first. Verify whether you run affected self-hosted Confluence (Confluence Cloud is not affected).
How BreachRisk sees it
BreachRisk answers the first question — do we have an exposed, affected Confluence instance? — from the outside in. Starting from little more than your domain, it discovers internet-facing Confluence, fingerprints the product and version, and flags exposure tied to KEV-listed, actively exploited vulnerabilities like this one, surfaced at the top because it's in KEV. We detect and flag the vulnerable version; we don't exploit it.
When a Confluence zero-day breaks, the outside-in view means the exposed server is already on your map — you go straight to patch-and-verify instead of starting from an inventory.