>> All posts

CVE-2023-22515: Atlassian Confluence broken access control, unauthenticated admin creation, actively exploited

The short version: CVE-2023-22515 is a broken-access-control flaw in internet-facing Atlassian Confluence Data Center and Server that lets a remote attacker create unauthorized administrator accounts and take over the instance. It was exploited as a zero-day by a nation-state actor before the patch, it scores 9.8, and it's in CISA's KEV catalog. Critically, patching does not undo a compromise that already happened. Steady hands — patch and check.

At a glance

FactDetail
Our severity takeHigh — 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
CVSS (Atlassian, CNA)10.0 — Critical
EPSS99.16% · 99.93rd percentile (2026-07-17)
In CISA KEV?Yes — remediation was due 2023-10-13
Known exploited?Yes — zero-day exploited by a nation-state actor (Storm-0062)
Vulnerability typeBroken access control (CWE-20 improper input validation per CISA-ADP) → unauthenticated admin-account creation
Requires authenticated session?No — pre-authentication
AffectedConfluence Data Center & Server: 8.0.0–8.3.2; 8.4.0–8.4.2; 8.5.0–8.5.1
Fixed in8.3.3 · 8.4.3 · 8.5.2 (and later)

What you need to know

A broken-access-control condition let an unauthenticated attacker reach setup functionality they should never have been able to reach, and create a new Confluence administrator account. From there they hold full administrative control of the instance.

  • It's unauthenticated and internet-reachable. Publicly accessible Confluence Data Center and Server instances are the target; Atlassian Cloud is not affected.
  • It was a nation-state zero-day. Atlassian attributed pre-patch exploitation to a known state actor, so affected instances may have been compromised before a fix existed.
  • Patching alone is not enough. An attacker who already created an admin account keeps that access after you upgrade — you have to find and remove it.

How serious we see it

High — the base score and Atlassian's own 10.0 both land here, and the real world agreed.

Unauthenticated administrative takeover of an internet-facing collaboration server, confirmed exploited by a capable actor before disclosure, is as urgent as it gets. The bounded, reassuring part is that the affected versions are specific and the fix is published. The catch — the one people miss — is that being patched and being clean are separate questions: with full admin, an attacker can exfiltrate content and credentials and plant malicious plugins, and the upgrade won't reverse that.

Recommendations

Straight from Atlassian's advisory and CISA:

  1. Patch now. Upgrade to 8.3.3 / 8.4.3 / 8.5.2 or later.
  2. Check for compromise — this is the step people miss. Look for unexpected members of the confluence-administrators group and for /setup/setupadministrator.action in exception messages in the Confluence security log.
  3. If compromised, respond fully. Remove rogue admin accounts, investigate for exfiltration and malicious plugins, and rotate credentials and secrets.
  4. Harden exposure. Restrict who can reach Confluence from the internet.
  5. Confirm your exposure first. Verify whether you run affected self-hosted Confluence.

How BreachRisk sees it

BreachRisk discovers internet-facing Confluence from little more than your domain, 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 is being used for admin takeover, the outside-in view means your exposed instance is already mapped, so you can move immediately to patch, and then to the compromise check that patching doesn't replace.

References

See your cyber risk, proven.