CVE-2022-26134 was a critical unauthenticated remote code execution flaw in Atlassian Confluence Server and Data Center, caused by OGNL injection. Atlassian published its advisory on 2 June 2022 and said it was aware of active exploitation. Fixed versions followed within a day. Defenders should learn about exposure, rapid inventory and workaround discipline.
What was the flaw?
Atlassian's advisory describes an unauthenticated remote code execution vulnerability from an OGNL injection flaw, rated Critical on Atlassian's severity scale. The advisory states the company was aware of current active exploitation. It lists all supported versions of Server and Data Center as affected and also says versions after 1.3.0 are affected. Atlassian Cloud sites on atlassian.net were not vulnerable, and Atlassian reported no evidence of exploitation in Cloud. Volexity is credited with identifying the vulnerability.
What was the timeline?
All dates are from the advisory's change history.
- 2 June 2022, 1 PM PDT: advisory published.
- 3 June 2022: the advisory was updated several times through the day, adding a replacement file workaround, clarifying affected versions, adding a web application firewall rule, adding fixed versions and removing interim WAF advice, and clarifying rolling upgrade limits.
- 10 June 2022: mitigation steps were updated for versions 6.0.0 and above.
Fixed versions listed are 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 and 7.18.1. Atlassian strongly recommended upgrading to a fixed version.
What was the workaround?
For teams who could not upgrade immediately, the advisory described replacing specific library files on each node: for versions 7.15.0 to 7.18.0 a single jar replacement, and for 6.0.0 to 7.14.2 two jar replacements plus an updated class file. In a cluster, the change had to be applied on every node. End of life versions were not fully tested with the workaround.
Clustered deployments also could not move to a fixed version without downtime unless they ran a rolling upgrade. This shows how the real constraint on response is often the architecture of the deployment, not the patch itself.
What should defenders learn?
Know what faces the internet. A collaboration server holds internal knowledge and often sits where outsiders can reach it. Keep a list of internet reachable applications and who owns each.
Know your versions in minutes. The affected range was broad. A team with a current inventory can answer "are we exposed" in minutes. Without one, the first hours go to finding out.
Treat workarounds as temporary. The advisory changed several times in a day. Track the advisory, apply the workaround, then move to the fixed version and record when you did.
Assume compromise on exposed, unpatched systems. With active exploitation reported, patching alone does not tell you whether someone got in earlier. Review logs, look for unexpected processes and files, and rotate secrets the server could read. This is a general response practice, not a claim about specific intrusions.
Plan for downtime. If your upgrade needs an outage, decide in advance who authorizes one.
How would you check for it now?
Search your inventory for Confluence Server and Data Center, compare versions with the fixed list, and confirm that anything older than the fixed release for its branch is retired or patched. Make sure your scanner reads application level components, not only operating system packages, so product versions appear.
What to do
- List every internet reachable application with owner and version.
- Check Confluence instances against the fixed versions in the advisory.
- Confirm workaround files were removed once you upgraded.
- Review server logs and file changes from before the patch date for signs of misuse.
- Rotate credentials and tokens the application could access.
- Document who may approve an emergency outage.
Quick check
Was Atlassian Cloud affected?
According to the advisory, Cloud sites on atlassian.net were not vulnerable.
Was the flaw exploited in the wild?
Atlassian's advisory states it was aware of current active exploitation when it published.
Sources
- Atlassian, Confluence Security Advisory 2022-06-02, fetched 18 October 2026.
Last reviewed: 18 October 2026.
