The Confluence Data Center and Server vulnerability tracked as CVE-2023-22515 was disclosed in October 2023 as an actively exploited zero-day with a CVSS 10.0 score. The flaw allowed an unauthenticated attacker to create administrator accounts on exposed Confluence instances, granting full takeover with a single HTTP request. The incident exposed a pattern that has become common: on-premises versions of products whose SaaS sibling is the primary investment focus often have weaker security maintenance, and customers running them frequently underestimate their exposure.
This retrospective examines the technical details, the exploitation timeline, the response challenges, and the lessons that apply to any organization running self-hosted versions of products from vendors whose attention is mostly elsewhere.
What was the underlying flaw?
CVE-2023-22515 was a broken access control issue in the Confluence setup workflow. The setup endpoint, intended to be used once during initial provisioning to configure the system, did not enforce a check that setup was incomplete. An attacker could send a crafted POST request to a setup-related URL on a fully provisioned Confluence instance and bypass authentication entirely, creating a new administrator account with attacker-chosen credentials. From that point, the attacker had administrative control of the Confluence instance, including access to all pages, the ability to install plugins, and the ability to execute server-side code through plugin abuse. The flaw was trivial to exploit, requiring no special knowledge, no chained primitives, and no authentication. The fix involved enforcing the setup-complete check that should have been present all along, and reissuing a patched build.
How was it exploited and by whom?
Exploitation predated public disclosure. Microsoft Threat Intelligence attributed early exploitation to a Chinese-linked group tracked as Storm-0062, which they observed using the vulnerability against unspecified targets starting in mid-September 2023. After Atlassian's public advisory on October 4, exploitation broadened immediately. Within 72 hours, mass scanning campaigns by multiple criminal groups were attempting to compromise every internet-exposed Confluence instance. Ransomware groups including Cerber and a faction of the Akira operation incorporated the exploit into their access broker workflows. CISA reported confirmed compromises at multiple federal civilian agencies by mid-October. Public scan data showed approximately 24,000 internet-exposed Confluence Data Center and Server instances at the time of disclosure, with roughly 4,000 confirmed compromised in the first month based on indicator-of-compromise sharing.
Why was the response so messy?
The response was messy for several reasons that have become depressingly familiar. Atlassian's initial advisory was unclear about which versions were affected, and the version list was expanded twice in the first week as additional impacted releases were identified. Customer-managed Confluence instances varied enormously in patch cadence, with many organizations running versions years behind the current release and lacking the maintenance windows to apply a fix immediately. The product was often deployed by individual teams rather than central IT, meaning many organizations did not have a complete inventory of their own Confluence instances. Atlassian's eventual decision to end Server product support in early 2024 added urgency but also confusion: organizations had to decide between an urgent patch on a deprecated product or an accelerated migration to Cloud or Data Center, neither of which is trivial.
What did the long tail look like?
The long tail of CVE-2023-22515 has been longer than expected because Confluence Server hung on past its end-of-support date in many environments. Scan data from mid-2024 showed roughly 30% of internet-exposed Confluence Server instances still unpatched, and a depressing 15% still unpatched in scan data from early 2026. The unpatched instances cluster at small organizations and at large enterprises with shadow IT deployments outside central management. Notable post-disclosure compromises have continued: a US state agency reported a 2024 ransomware incident traced to an unpatched Confluence Server, and a healthcare network in 2025 disclosed a data breach involving the same root cause more than eighteen months after Atlassian's patch shipped. The product is firmly in zombie territory now, with installations that nobody is actively maintaining but nobody is decommissioning either.
What are the broader patterns?
The broader pattern is that on-premises versions of products whose vendors are focused on SaaS migrations tend to accumulate security debt. The SaaS version gets the engineering attention, the threat modeling work, and the security feature investment, while the on-prem version receives back-ported patches and minimal new defensive work. Customers who run the on-prem version are often doing so because of data residency, compliance, or cost reasons, none of which reduce their threat exposure. The Confluence case echoes patterns seen with Exchange Server, GitLab CE, and several other products. The decision to run on-prem should include an honest accounting of the vendor's commitment to the product, the staffing levels of the team maintaining it, and the customer's own capacity to patch quickly when the next zero-day inevitably surfaces.
How Safeguard Helps
Safeguard's approach to on-prem-adjacent CVEs like the Confluence zero-day starts with inventory accuracy. Our agent-collected data captures self-hosted application versions across hybrid environments, surfacing shadow IT Confluence, Jira, and similar deployments that central inventory tools miss. Griffin AI prioritizes findings by internet exposure, authentication configuration, and known exploitation status, surfacing the small set of instances that actually need urgent patching. Policy gates can block builds and deployments that reference end-of-life self-hosted products without explicit risk acceptance. TPRM scoring evaluates SaaS-versus-on-prem product investment patterns and flags vendors whose on-prem versions are likely to accumulate security debt. Our zero-CVE base images and hardened deployment templates reduce the attack surface for the on-prem applications you do continue to run.