You would have caught CVE-2022-26134 if you knew every internet-facing Confluence instance you ran, could read its exact version in minutes, and could apply a vendor workaround the same day. Those three abilities mattered more than any single tool. This checklist turns the advisory into questions you can answer today.
What did the advisory actually say?
Atlassian published its advisory on 2 June 2022. It described an OGNL injection vulnerability that let an unauthenticated user run arbitrary code on a Confluence Server or Data Center instance. Atlassian reported active exploitation at the time of disclosure, so there was no quiet window to patch in.
The fixed versions were 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4 and 7.18.1. Atlassian-hosted Cloud sites were not affected. Self-managed teams carried the risk, and the advisory was updated several times over the following week as the workaround and the clustering guidance changed.
Nobody on a defending team did anything wrong by running Confluence. The question is how fast a normal team can move when a vendor says "exploited now." That is a process question, and processes can be tested.
Which controls would have shortened the exposure?
Think in four layers: knowing what you run, learning about the problem, reducing exposure while you fix it, and noticing if someone got in first.
Know what you run. If the answer to "which Confluence versions are exposed to the internet" takes a day of emails, you lose the day that matters. Keep an inventory that includes the version, the owner and whether the host is reachable from outside.
Learn fast. Someone must be named to read vendor advisories for every self-hosted product on that inventory. A shared mailbox nobody owns does not count.
Reduce exposure. The advisory offered a temporary workaround: stop Confluence, swap specific JAR files, and restart. A team that has practiced a maintenance window can do that in an hour. A team that needs change board approval for every restart cannot. Decide in advance what counts as an emergency change.
Notice compromise. A patch does not remove an attacker who already ran code. Keep web server and application logs long enough to look back to the advisory date, and watch for unexpected child processes spawned by the Confluence service account.
What to do
- List every self-hosted collaboration and developer tool (wiki, ticketing, CI, source hosting) with its version and whether it faces the internet.
- Assign one owner per product to monitor its vendor advisories.
- Write an "exploited now" rule: critical flaw plus reported active exploitation means emergency change, patch or workaround within one working day.
- Rehearse the vendor workaround steps on a staging copy so the first run is not during an incident.
- Check that clustered deployments have a documented upgrade path, since the advisory noted that moving to a fixed version in a cluster required downtime.
- Put internet-facing admin tools behind a VPN or an identity-aware proxy where the product allows it.
- Run Confluence under a least-privilege service account so code execution does not equal full host control.
- Restrict outbound traffic from the server to what it needs, so a shell cannot easily call home.
- Retain application and proxy logs for at least 90 days and test that you can search them.
- After any fix, assume possible prior access: review accounts, tokens and scheduled tasks created since the advisory date.
Where does software inventory help?
An SBOM and a dependency inventory answer the "what do we run" question for code you build. For packaged products like a wiki, you need a plain asset list. Both are the same discipline: a current list you trust. Our free scan covers up to 100 dependencies in the browser if you want to see what a dependency inventory looks like for a project.
Quick check
Was Confluence Cloud affected by CVE-2022-26134?
No. Atlassian stated that Atlassian-hosted atlassian.net sites were not vulnerable and that it found no evidence of exploitation of Cloud. The risk applied to Confluence Server and Data Center that customers ran themselves.
Is patching enough after an exploited vulnerability?
Not by itself. If the flaw was exploited before you patched, an attacker may have left accounts, tokens or scheduled tasks. Review logs and credentials back to the advisory date.
Sources
- Atlassian: Confluence Security Advisory 2022-06-02 (CVE-2022-26134), fetched 18 October 2026.
Last reviewed: 18 October 2026.
