Confluence CVE-2022-26134: OGNL Injection RCE Under Fire

June 4, 2022: Atlassian ships patches for CVE-2022-26134, a critical remote code execution flaw in Confluence Server and Data Center, after attackers had already been exploiting it in the wild for days — the vulnerability was detected through observed exploitation on June 2 (unofficial disclosure), not through Atlassian’s own process. The bug is an OGNL injection: Confluence’s web interface passed attacker-controlled input into Object-Graph Navigation Language expressions, the expressive template-and-expression engine at the heart of several Java server products, and OGNL can invoke arbitrary Java classes and methods. The result was unauthenticated RCE on a widely deployed, internet-facing enterprise wiki — the single most dangerous vulnerability class on the single most dangerous asset position. Exploitation was fast and industrial: mass scanning and web-shell deployment within hours, coinminer payloads, and niche ransomware actor interest, with CISA adding it to the KEV catalogue and urging federal-agency patching within days. For defenders, June 2022’s Confluence crisis became the template case for why OGNL-and-expression-language injection in Java middleware keeps producing internet-scale fire drills — and why “patch within 48 hours of in-the-wild exploitation” became the de facto SLA for internet-facing Confluence fleets.

What happened

On June 2, 2022, researchers and incident responders began observing active exploitation of a previously unknown — or at least unpatched — RCE in Confluence instances, deploying web shells at scale. Atlassian’s June 3 guidance (initially without a patch) recommended a temporary mitigation and promised fixes; the official advisory and patched versions landed June 4 as CVE-2022-26134. The root cause sat in a painful lineage: Confluence (like several Java products) uses OGNL as its expression engine, and a path-traversal-shaped corner of action-mapping let attacker input reach findValue()-style OGNL evaluation, where expression injection means Java method invocation. This was not theoretical — the same product had already taken CVE-2021-26084 (August 2021, also OGNL injection, also mass-exploited), and the broader Java ecosystem had spent the previous six months re-learning that embedded expression engines (Log4j’s JNDI lookups, Spring’s property binding) are RCE-shaped when input reaches them.

The exploitation window was brutal for unpatched fleets. Attackers deployed web shells (frequently under innocuous filenames in Confluence’s attachment/temp directories), fetched coinminers (the kinsing/minerd-class payloads common to every unauthenticated Java RCE of the era), and in some cases staged for more selective intrusion. Later analysis documented reconnaissance probing against vulnerable patterns predating the June 2 burst — meaning the effective exposure window was longer than the public timeline suggested. CISA’s KEV listing formalised the federal patch mandate within days.

The patch itself worked, but fleets didn’t move at exploit speed: thousands of instances remained unpatched for weeks, and follow-up campaigns (including niche ransomware outfits scanning for the same CVE) harvested the laggards. The event’s lasting contribution to security operations was procedural: it proved that for internet-facing Java middleware, the patch clock starts at first in-the-wild signal — not at vendor advisory — and that interim mitigation (vendor shielding plugin, WAF rules matching the OGNL payload grammar) measurably blunts mass exploitation while the fleet patches.

The OGNL problem in one diagram

Why OGNL injection == RCE in Java middleware:

  ATTACKER                CONFLUENCE SERVER
     |                          |
     | HTTP request with        |
     | crafted path/param  -->  | webwork action mapping
     |                          |   input reaches OGNL
     |                          |   expression evaluation
     |                          |       |
     |                          |       v
     |                          | OGNL runtime resolves:
     |                          |   @java.lang.Runtime@getRuntime()
     |                          |   .exec("curl miner.url")
     |                          |       |
     |                          |       v
     |                          | RCE as Confluence process
     |                          |   (web shells, miners,
     |                          |    staged tooling)
     |                          |
     v                          v
  mass scanners: 1000s req/sec against
  /${ognl-payload}/ style paths

  LINEAGE (same engine, same product):
    2017 Struts2 OGNL RCEs (Equifax-class)
    2021-08 CVE-2021-26084 (Confluence OGNL)
    2022-06 CVE-2022-26134 (this event)

  DEFENCE LAYERS THAT WORKED IN JUNE 2022:
    1. patch (June 4 versions above)
    2. vendor shielding plugin / WAF virtual patch
       (payload grammar: suspicious ${}+@class@ refs)
    3. execution monitoring on Confluence host
       (unexpected child processes = IOCs)

Impact and numbers

Timeline

Why it still matters in 2026

Because the architecture that produced it is still shipping. Expression languages embed in every mature Java stack (and their analogues elsewhere — template engines, query builders, serialisation frameworks), and every one of them is an interpreter waiting for input to reach it. The 2021–2022 triplet — Log4Shell, Spring4Shell, Confluence — taught the industry the operational doctrine now considered baseline: internet-facing middleware gets 24–48-hour patch SLAs, virtual-patch coverage (WAF/CDN rules against the payload grammar) bridges the fleet-patch gap, and host-level execution monitoring treats “Confluence server spawned a shell” as a page-one alert. In 2026, Confluence-on-internet remains a top exploited product in CISA’s advisories (joined by its later sibling CVE-2023-22515 and friends — the product line’s rough decade continued), and OGNL-class bugs keep recurring across Java middleware precisely because the engine’s power makes it unremovable. The June 2022 event remains the cleanest case study of the modern exploitation-to-patch window compressed to ~48 hours by adversary speed — and the operational playbook (detect via exploitation, mitigate via grammar-filtering, patch via emergency cadence) that every Kubernetes-era SOC now runs by default.

Detection and hardening takeaways

• Class-level patch SLA for internet-facing middleware. The June 2022 window proved exploitation precedes advisories: fleets that waited for the official CVE burned days of exposure. Treat Java middleware (Confluence, Struts-lineage, anything with embedded expression engines) as tier-0 patch surface — 24–48h from first credible in-the-wild signal, not from vendor advisory.
• Virtual-patch during the gap. The June 3 mitigation pattern (vendor shielding plugin, WAF rules matching the OGNL payload grammar — ${...} with @class@method@-style references) measurably blunted mass exploitation; keep grammar-shaped rules ready to deploy at CDN/WAF level within hours.
• Monitor execution, not just requests. The clearest IOCs were host-level: Confluence’s Java process spawning shells, miners, or curl/wget children. Endpoint execution monitoring on middleware hosts catches both known and novel OGNL payloads regardless of WAF evasion.
• Hunt for pre-advisory dwell. Post-hoc analysis found March-class reconnaissance predating the June burst; any KEV-class event should trigger retrospective log hunts over the prior quarter for the payload grammar, not just forward-looking patching.
• Treat OGNL/expression-language surfaces as permanent risk. The lineage (Struts 2017, Confluence 2021 and 2022) shows recurrence, not accident. Inventory where expression engines are reachable from user input in your stack, prefer configurations/versions that sandbox or disable them where possible, and assume the next one is already being probed for.

FAQ

Was Confluence the only product with this OGNL issue?

No — and that’s the point. OGNL is used across several Java server products (it originated as a generic expression language for Java web frameworks; Struts2 made it infamous via the Equifax-class 2017 RCEs, and other Atlassian products have taken OGNL-adjacent CVEs too). June 2022’s lesson is engine-level: wherever an expression interpreter meets attacker-reachable input, RCE is one grammar away.

My Confluence is behind a VPN / not internet-facing. Am I safe?

It eliminates the mass-exploitation vector (internet scanners never see you), but not the class. Authenticated users, compromised endpoints, and pivoted intruders can still reach an OGNL surface; the June 2022 patch matters internally too. The internet-facing question changes your urgency, not your eventual patch obligation.

What did the WAF rules actually look for?

The payload grammar: OGNL expressions in paths/parameters — ${...} blocks containing Java-class references (@java.lang...@), method-invocation chains, and runtime-exec patterns. Grammar-matching caught the mass scanners (which used simple, unobfuscated payloads); determined adversaries obfuscated, which is why execution monitoring stays the backstop.

Is OGNL going away?

Not from legacy stacks. Modern Confluence development moved to restrict OGNL reachability, and the broader Java ecosystem added sandboxing around expression engines after the 2021–2022 wave — but installed bases run for decades, and CISA’s later-year advisories still list Confluence RCEs among top exploited. Treat it as permanent attack surface with recurring CVEs, and budget your defences accordingly.