Atlassian Confluence and the patch-time asymmetry: who carries

Summary

CVE-2022-26134 was a critical Object-Graph Navigation Language, or OGNL, injection vulnerability in self-managed Confluence Server and Confluence Data Center. It allowed an unauthenticated remote attacker to execute arbitrary code. Atlassian Cloud was not affected. Volexity reported the zero-day to Atlassian on May 31, 2022 after investigating exploitation over the US Memorial Day weekend. Atlassian published its advisory on June 2 and listed fixed versions on June 3.
That fast vendor response did not end customer exposure. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on June 2 and required US federal civilian agencies to block internet traffic immediately and update or remove affected products by June 6. Internet measurements and responder reports then showed widespread scanning, multiple payload types, ransomware attempts, cryptomining, bot activity, in-memory implants, and web shells.
The operational burden was asymmetric. Atlassian could produce corrected software centrally, but each customer had to identify all instances and nodes, confirm versions, restrict access, back up data, test the change, accept emergency downtime, apply the fix or interim mitigation, validate it, and restore service. Atlassian's incident-specific advisory warned that clustered customers could not install the fixed versions as a rolling upgrade. Smaller organizations and single-node deployments therefore faced a direct choice between a collaboration outage and continued exposure.
Patching was necessary but not sufficient. Volexity observed a memory-only implant, disk-based web shells, database access, and attempts to alter logs. Atlassian's FAQ said the company could not determine whether a customer's instance had been compromised and advised local forensic investigation. A successful version upgrade could close the vulnerability while leaving stolen information, credentials, persistence, or destroyed evidence unresolved.
Accountability should follow control capability. Atlassian controlled secure product development, the vulnerability investigation, backported fixes, release quality, notice, and product-specific detection guidance. Customers controlled asset inventory, public exposure, operating privilege, network boundaries, logging, backup, change execution, incident response, and continuity. The record supports credit for Atlassian's rapid disclosure-to-fix response, but it does not contain a public root-cause review detailed enough to assess why such a broadly affected flaw escaped earlier. It also does not establish how many exposed systems were successfully compromised.
The durable lesson is to measure time to a trustworthy service, not merely time to a patch. For an actively exploited knowledge platform, closure requires proof that every instance is remediated or isolated, the period of exposure has been investigated, credentials and connected systems have been addressed, continuity procedures worked, and the restored platform has an accountable business owner.

One vulnerability, four clocks

The conventional vulnerability timeline has two endpoints: disclosure and patch. That is useful for measuring a vendor's response, but it compresses the customer's work into an imaginary instant. CVE-2022-26134 makes the missing time visible.

The first clock was the vendor clock. It began when Atlassian received enough information to reproduce and assess the defect. Volexity says it contacted Atlassian on May 31. Atlassian's security advisory records a June 2 release at 1 p.m. Pacific time and a June 3 update at 10 a.m. adding seven fixed versions. On the public evidence, Atlassian confirmed an actively exploited critical vulnerability, assigned a CVE, communicated the risk, prepared backports across supported branches, and released corrections quickly.

The second was the containment and change clock. It began separately at every customer. A warning had to reach someone with authority to act. That person needed an inventory of Confluence deployments, nodes, versions, external routes, owners, dependencies, and support status. Each affected instance then had to be disconnected, restricted, upgraded, mitigated, or removed. The clock did not stop because a package became available; it stopped only when the customer could demonstrate that no vulnerable instance remained reachable.

The third was the forensic clock. Active exploitation preceded public disclosure. Customers therefore had to ask whether attackers had reached them before the fix. That inquiry depended on retained web, operating-system, endpoint, identity, network, and application evidence. It could expand into memory acquisition, filesystem comparison, credential review, and examination of connected systems. A patch changed future exploitability. It could not rewrite the period before installation.

The fourth was the continuity clock. Confluence commonly holds operating procedures, project records, internal knowledge, incident runbooks, and decision history. Restricting or shutting it down could impair work even when no data had been destroyed. Restoration required more than restarting a service: users needed confidence that the platform was available, complete, and safe to use. If the wiki contained the instructions needed to recover the wiki, a security response could expose a circular dependency.

These clocks allocate different responsibilities. A vendor can shorten the time to an actionable fix for everyone. It cannot inventory a customer's shadow instance, schedule its maintenance, preserve its logs, or decide which business process can tolerate an outage. A customer can isolate and harden its deployment. It cannot inspect the vendor's private development record or independently create a supported patch at the same speed. Accountability becomes clearer when each party is assessed against the clock it can control.

The exploitation and emergency patch timeline

The sequence is unusually well documented, but the evidence has limits. Volexity's report describes two customer servers and its direct incident response. Atlassian's advisory records product scope and update times. CISA's catalog records a federal remediation deadline. Internet telemetry describes scanning or potentially exposed systems, not a verified global victim count.

Date	Event	Accountability significance
May 26, 2022	Unit 42 later reported historical scanning by IP addresses associated with the activity from as early as this date.	This is threat telemetry, not proof that every scan exploited CVE-2022-26134 or that Atlassian knew of the flaw then.
US Memorial Day weekend, May 28-30	Volexity investigated suspicious activity on two internet-facing Confluence servers, including JSP web shells written to disk.	Exploitation was occurring before public disclosure and before a customer could obtain a vendor fix.
May 31	Volexity says it reported the reproduced zero-day to Atlassian.	The vendor response clock became measurable.
June 2, 1 p.m. PDT	Atlassian released a critical advisory for active exploitation of unauthenticated remote code execution. At initial publication, fixed releases were not yet listed.	Customers received an urgent risk decision before a complete upgrade path was available. Restriction or shutdown was the defensible immediate control.
June 2	CISA added CVE-2022-26134 to the Known Exploited Vulnerabilities catalog with a June 6 due date.	US federal civilian agencies had to block internet traffic immediately and update or remove affected products. The deadline also provided a strong prioritization signal to other organizations.
June 3, 8 a.m. PDT	Atlassian updated mitigation information with replacement JAR and class files.	Customers unable to complete a full upgrade gained an interim product-specific option, but still had to change every relevant node correctly.
June 3, 10 a.m. PDT	Atlassian added fixed versions 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, and 7.18.1. CISA published a corresponding upgrade alert.	The supported remediation path became available across several maintained release branches.
June 3, 4 p.m. PDT	Atlassian clarified that customers could not use a rolling upgrade to reach the listed fixed versions.	Emergency security remediation also became an explicit availability event, including for clustered deployments.
June 3	Cisco Talos reported a public proof of concept and warned that exploitation could increase. Unit 42 measured 19,707 internet-visible Confluence servers it considered potentially affected, including 1,251 end-of-life versions.	Public exploitability and a large inferred attack surface sharply reduced any defensible delay. The figures were exposure estimates, not confirmed vulnerable organizations or breaches.
June 4	Dutch Institute for Vulnerability Disclosure, or DIVD, says it began notifying operators of about 15,000 vulnerable instances.	External notification helped owners who had not found the exposure themselves and revealed the scale of the inventory problem.
June 6	CISA's federal deadline arrived. GreyNoise reported more than 850 unique source IP addresses attempting exploitation by 7 p.m. UTC.	By the deadline, exploitation attempts were broad and diverse; waiting for evidence of targeted interest was no longer a rational control strategy.
June 6-7	DIVD recorded roughly 1,150 additional notifications on June 6 and more than 800 on June 7.	Discovery continued after patches were public. The figures should not be summed as a count of unique victims without more information about rescans and deduplication.
June 10	Atlassian expanded its mitigation section for Confluence 6.0.0 and later.	Guidance continued to evolve after the initial emergency, especially for organizations not on a straightforward supported upgrade path.
June 16	Sophos reported automated exploitation delivering bot, cryptominer, Cobalt Strike, web-shell, and ransomware payloads; two observed Windows incidents involved attempted Cerber ransomware deployment.	The vulnerability had moved beyond the initially observed actor and technique into commodity and financially motivated activity.
August 2023	A joint CISA-led advisory listed CVE-2022-26134 among the 12 vulnerabilities most routinely exploited during 2022.	The issue was not only a short-lived disclosure spike. It became part of the year's durable exploitation record.

The NVD entry gives the issue a CVSS 3.1 base score of 9.8 and identifies affected ranges from versions after 1.3.0 through each fixed branch. It also reproduces the CISA catalog action and dates. The breadth of those version ranges shows that many release lines required correction. It does not, by itself, establish when the defect was introduced, when it first became practically exploitable, when anyone first discovered it, or whether Atlassian had prior knowledge.

That distinction matters to fair accountability. A long affected-version range can indicate a large remediation burden and a deep product lineage. It is not proof of deliberate concealment or a particular secure-development failure. Those judgments would require evidence that the public record does not provide.

What CVE-2022-26134 allowed

Atlassian described CVE-2022-26134 as an OGNL injection vulnerability that allowed an unauthenticated user to execute arbitrary code on a Confluence Server or Data Center instance. In practical terms, attacker-controlled input in an HTTP request could be evaluated as an expression and used to execute commands in the security context of the Confluence process. No valid user account, stolen session, or interaction by an employee was required.

The severity therefore depended partly on deployment. Internet reachability made an instance discoverable to broad scanning. The operating account determined what commands could do on the host. Network access and stored credentials shaped lateral movement. The information in Confluence and its database shaped the confidentiality impact. Monitoring and log retention shaped whether exploitation could later be proved.

Volexity's incident response analysis illustrates that chain. Its responders found that the compromised Confluence process was running as root, which gave commands full host privilege. They identified an in-memory BEHINDER implant, a China Chopper web shell, another upload shell, reconnaissance, access to local Confluence database tables, and attempts to alter web logs. Volexity explicitly recommended against running Confluence as root. The product vulnerability enabled entry; customer-side privilege and architecture could enlarge what entry meant.

The in-memory component is particularly important for closure evidence. A responder who searched only for newly created files could miss an implant living in memory. Restarting the service might remove that component, but it would not remove a second web shell written to disk, reverse exfiltration, or prove that credentials remained secret. Volexity also noted that requests used to interact with the implant could resemble legitimate traffic in isolation. Detection required context and a sequence of evidence, not a single universal signature.

Independent observations show how quickly the exploit population diversified. GreyNoise saw payloads for reconnaissance, reverse shells, botnets, cryptomining, administrative-user creation attempts, destructive commands, and obfuscation. Cisco Talos reported continuing exploitation and published network detection coverage. Sophos observed automated follow-on payloads and ransomware attempts. Unit 42 reported successful exploitation associated with a Cerber ransomware attempt in its customer telemetry.

These observations should not be collapsed into one universal attack. Volexity's initial actor, an automated cryptomining operator, a botnet distributor, and a ransomware operator had different objectives. An organization that found no Volexity-listed IP address could still have been attacked by someone else. Blocking known source addresses was useful as a temporary friction measure, not a substitute for remediation or investigation.

Atlassian's response was fast, but the product record is incomplete

Measured from Volexity's reported May 31 notification, Atlassian published its advisory in roughly two days and fixed releases the following day. The advisory retained an update history, named affected products, separated Cloud from self-managed deployments, listed fixed versions, supplied interim file-replacement steps, warned about rolling-upgrade limits, and directed customers toward the latest long-term support release. Those are material strengths in an emergency response.

The speed matters because every hour of vendor analysis occurs while customers lack a supported correction. Producing seven releases is more than changing a line of source code. A vendor has to identify the defect, test the correction, determine affected branches, build and sign artifacts, prepare release information, coordinate support, and avoid creating a second outage or vulnerability. The public record supports the conclusion that Atlassian treated this as an emergency.

Atlassian also published a dedicated CVE-2022-26134 FAQ. It clarified that Cloud was not vulnerable, that SSO did not protect self-managed instances because exploitation was unauthenticated, that non-internet-facing systems should still be upgraded, and that only a fixed version could ensure protection. It advised customers to compare filesystem artifacts with backups and to engage local security teams or forensic specialists. That guidance correctly separated vulnerability remediation from compromise assessment.

Notification was channel-dependent. The FAQ says Atlassian sent critical advisories to the relevant product Alerts mailing list. The company's current security advisory publishing policy similarly describes public posting and mailing-list notification. A mailing list can distribute information at scale, but it cannot guarantee that the current operator receives, acknowledges, and acts on a message. Customer records may retain a purchaser or former administrator. Managed-service responsibilities may be ambiguous. An advisory is an input to customer governance, not evidence that remediation occurred.

There is, however, less public detail about prevention. Atlassian's FY2022 security incident report classifies coordination of the CVE-2022-26134 response as a Level 1 incident and notes active exploitation on internet-facing instances. The advisory and public issue describe the vulnerability and remediation. They do not provide a full root-cause analysis of the relevant code path, explain why existing development or testing controls did not detect it, identify control changes made afterward, or publish independent validation of those changes.

That absence does not prove that no internal review occurred. It means external stakeholders cannot evaluate the preventive control response with the same precision available for the patch response. A strong post-incident record would separate at least five questions: what code behavior created the injection path; when it entered maintained branches; which reviews or tests should have detected it; why they did not; and what measurable changes now test comparable expression-language paths. Without that account, the public can assess reaction speed more confidently than product-learning depth.

The responsible finding is therefore mixed. Atlassian deserves evidence-based credit for rapid triage, transparent advisory updates, broad supported fixes, and explicit customer guidance. The public record is not sufficient to decide whether the underlying secure-development controls were reasonable, deficient, or materially improved after the event. Speed after discovery is important accountability evidence; it is not a substitute for explaining prevention.

A released patch is not a remediated customer estate

Software vendors often report a fix as shipped. Customers often report a ticket as closed when installation succeeds. Neither event proves that the risk has ended across an organization.

First, a customer has to find the denominator. That includes production, disaster-recovery, staging, test, development, migration, training, acquired-company, contractor-managed, and temporarily stopped instances. It includes every Data Center node and every reverse-proxy route. The DIVD case record is revealing because notifications continued after the advisory and patch. External researchers could still identify vulnerable systems whose owners had not remediated or perhaps had not known they were exposed.

Second, the customer must establish version and support status. Atlassian's affected range extended across supported and old releases. Unit 42's estimate of 1,251 internet-exposed end-of-life servers on June 3 represented a distinct governance problem. An unsupported product may not have a direct, low-risk upgrade path. Its operating system, Java runtime, database, apps, or custom themes may also be old. What appears to be one patch can become a multi-component migration.

Third, installation must reach every relevant component. The interim mitigation required customers to stop Confluence, replace specific JAR or class files, preserve correct ownership and permissions, restart the service, and repeat the process on all cluster nodes. A copied old JAR left in the installation directory could defeat the intended change. The operational evidence therefore had to include artifact identity and node coverage, not merely an administrator's statement that the workaround was attempted.

Fourth, connectivity must be reassessed. A server believed to be internal may still be reachable through a VPN, partner route, remote-access gateway, application link, cloud load balancer, forgotten DNS record, or temporary troubleshooting rule. Atlassian's FAQ carefully said that lack of general internet access negated attacks originating from the general internet, but still recommended upgrade because access paths vary. "Internal" is a hypothesis to test, not a permanent asset property.

Fifth, remediation needs verification. NIST's Guide to Enterprise Patch Management Planning defines the process to include identifying, prioritizing, acquiring, installing, and verifying updates. Verification should be independent of the change action where possible: a fresh authenticated inventory, package or file hash inspection, application health checks, vulnerability testing that does not harm production, and network confirmation that old routes remain closed until validation finishes.

The key metric is not the percentage of discovered instances patched. It is the percentage of the accountable estate in a non-vulnerable, isolated, or removed state. If the asset inventory is incomplete, a 100 percent patch dashboard can be mathematically correct and operationally false. The denominator itself needs assurance.

The patch could stop entry without establishing trust

Atlassian's FAQ states the central forensic limit plainly: Atlassian could not confirm whether an individual customer instance had been compromised. It recommended involvement by local security personnel or a specialist firm and warned that attackers might alter system, audit, or access logs. That allocation was not evasive; the decisive evidence lived in customer environments.

A useful response therefore separated two workstreams. The remediation workstream prevented new exploitation by isolating the instance, installing a fixed version or supported mitigation, and validating the result. The incident workstream investigated the historical exposure window and dealt with any consequences. Running them in parallel avoided the dangerous assumption that forensic perfection had to precede containment, while preserving enough evidence to make later conclusions possible.

The investigation window could not begin at June 2. Volexity had already seen exploitation over the prior weekend, and Unit 42 found scanning from associated infrastructure as early as May 26. A cautious organization would start with the earliest credible evidence available to it and expand backward if indicators, missing logs, or abnormal behavior justified it. It would not treat a global research date as proof of its own compromise.

Evidence collection needed to fit the observed technique. Relevant sources included reverse-proxy and web access logs, Confluence application logs, authentication and administrative events, endpoint telemetry, process creation, memory where feasible, file integrity, scheduled tasks, service changes, outbound DNS and network traffic, cloud flow logs, identity-provider events, database access, and privileged credential use. Remote or protected logging was especially valuable because an attacker with command execution could alter local files.

CISA's logging guidance for small and medium businesses advises protecting logs from unauthorized access or deletion, retaining them according to policy, and assigning incident roles across technology, communications, legal, and continuity. CVE-2022-26134 shows why these are connected controls. Log retention is not only a security-operations expense; it determines whether management can later distinguish "no evidence found" from "no evidence retained."

If compromise was found or could not reasonably be excluded, rebuilding from trusted media could be safer than cleaning an unknown host. Credentials available to the Confluence service, stored in configuration, used for the database, held by administrators, or exposed in wiki content might require rotation. Connected systems could need review. Backups had to be checked for integrity and for the possibility that they preserved a compromised state. Data exposure analysis had to consider what the instance contained and what the service account could reach.

This is why "patched within 24 hours" and "recovered within 24 hours" are different claims. The first may be proven by software state. The second requires evidence about attacker activity, data integrity, identity, connected systems, and business operation. An organization can be securely offline, vulnerably online, patched but untrusted, or restored and trusted. A responsible dashboard preserves those states instead of reducing them to red and green.

Emergency patching was also an availability incident

The incident-specific Atlassian advisory said customers running a cluster could not upgrade to the fixed versions without downtime. That warning defeats the comforting assumption that Data Center architecture always turns a critical update into a seamless rolling change. The safer software state required an interruption.

Atlassian's general rolling-upgrade documentation explains that zero-downtime eligibility depends on the source and target versions, that it requires a multi-node Data Center cluster, and that active nodes must have enough capacity while another node is offline. It recommends backups, pre-upgrade checks, and a staging environment. Those are sound practices, but a zero-day compresses the time available to perform them.

Single-node customers had no second Confluence node to carry traffic. Some could place a static maintenance page or a read-only export in front of users; others had no prepared substitute. Organizations that had built automation, rehearsed upgrades, tested backups, and documented dependencies could move faster with less uncertainty. Organizations that treated maintenance as occasional technical work had to discover the procedure during the emergency.

The choice was not "security or availability" in the abstract. Continued exposure also threatened availability because attackers were deploying destructive commands, bot software, cryptominers, and ransomware. Planned downtime imposed a bounded and managed interruption. Uncontained compromise could create a longer and less predictable one. The control objective was to choose the least damaging route to a trustworthy service, not to keep the status page green at any cost.

Atlassian's upgrade hub and Data Center guidance emphasize backups, compatibility, configuration changes, and post-upgrade checks. The backup and restore documentation also illustrates why "take a backup" is not a complete continuity control. Different backup methods have different purposes; a backup job can fail; a restore can overwrite current data; and a restart can interrupt a task. A useful recovery plan tests restoration rather than counting files.

For a knowledge platform, the continuity design should include an offline minimum operating set: incident contacts, identity and infrastructure recovery steps, network diagrams, vendor account details, decision authorities, critical customer procedures, and the instructions for restoring Confluence itself. That copy must be protected, current, and accessible without the affected identity or application path. Exporting every page is not necessary; preserving the small set needed to operate through isolation is.

Why SMEs carry a disproportionate continuity burden

The vulnerability was technically identical for a multinational and a small company running the same affected version. The ability to absorb the response was not.

A large enterprise might have a 24-hour security operations center, a configuration database, a staging cluster, infrastructure automation, a retained incident-response firm, application owners, and executives authorized to accept downtime. It could still fail, but it had specialized capacity. A smaller organization might have one administrator, an outsourced provider, a single production node, limited log retention, no test environment, and a Confluence instance maintained mainly when something breaks.

That difference creates a response queue. The same person may need to read the advisory, verify authenticity, contact management, find the server, take a backup, test an upgrade, notify users, apply it, troubleshoot apps, inspect logs, speak with a provider, and restore access. While each step is individually reasonable, their sequence can exceed the public exploitation window. Patch-time asymmetry is partly an expertise and coordination asymmetry.

The NCSC Small Business Guide to Response and Recovery is built around preparing, identifying, resolving, reporting, and learning. Its relevance here is practical: preparation moves decisions out of the crisis. An SME can pre-authorize internet isolation for a critical exploited vulnerability, keep supplier contacts current, identify a forensic provider before an incident, maintain an offline runbook, and define who can accept a temporary outage. None of those controls requires enterprise scale.

NIST's patching practice guide acknowledges the structural conflict directly: patching is resource-intensive and can reduce system availability. It treats inventory, emergency mitigation, isolation, testing, tracking, and verification as parts of the same capability. For an SME, that suggests a modest but complete design rather than a miniature enterprise program.

A workable SME control set would include:

One accountable register. Record the instance URL, deployment location, product and version, license and support status, administrator, business owner, public routes, authentication dependency, database, backup method, and provider contact. Review it whenever the service changes.
A pre-approved emergency threshold. Active exploitation plus unauthenticated remote code execution on an exposed instance should authorize immediate restriction or shutdown without waiting for a routine change meeting.
A tested maintenance path. Keep installation media, configuration records, app compatibility information, backup instructions, and a simple validation checklist ready. Rehearse at least one upgrade and restore.
An alternate knowledge channel. Maintain protected offline or separately hosted copies of the few documents required for incident response and essential service delivery.
A provider contract with clocks. If an MSP operates the service, define who monitors advisories, who can disconnect it, response and notification times, evidence retention, after-hours coverage, and who pays for emergency work.
Remote evidence. Send important logs away from the application host and retain enough history to investigate a pre-disclosure window. Know who can retrieve them.
A restart decision. Name the person who can declare the service trustworthy, and define the evidence required: fixed version, all nodes covered, health checks passed, exposure reviewed, compromise assessment completed to an agreed level, and credentials addressed where necessary.

The current NCSC vulnerability-management guidance is addressed to SMEs as well as larger organizations. It emphasizes update by default, active-exploitation response, asset identification, senior ownership of decisions not to update, and verification. Although updated after the Confluence event, it captures the enduring governance model: a technical team can advise on risk, but a decision to remain exposed is a business decision and should be visible as such.

SME limitation should not become a blanket excuse. An internet-facing unsupported wiki running with excessive privilege is an avoidable risk regardless of headcount. But accountability should recognize capacity when allocating remedies. Vendors can reduce customer burden with clear version matrices, machine-readable advisories, verified artifact hashes, concise isolation instructions, supported hotfixes, detection packages, and provider-ready communications. Marketplaces and managed-service partners can make app compatibility and upgrade ownership explicit. Better upstream design creates more equal downstream safety.

Cloud dependency, without a Cloud breach

CVE-2022-26134 did not affect Atlassian Cloud. Both the advisory and FAQ say hosted Cloud instances were protected and required no customer action. That fact must remain central; describing the event as a generic "Confluence breach" would incorrectly include a service that Atlassian says was not vulnerable.

The event still belongs in a cloud-service dependency analysis for two reasons. First, Atlassian is a global collaboration-platform provider whose products span hosted and self-managed delivery. Organizations depend on the same vendor ecosystem, workflows, app marketplace, identity links, and knowledge practices even though operational control differs. Second, the choice between Cloud and self-management is itself an allocation of control.

In Atlassian Cloud, the vendor can patch the hosted estate centrally and customers do not schedule a product-version upgrade. The customer gives up some infrastructure control in exchange for that operational concentration. In Server and Data Center, the customer controls hosting, network exposure, maintenance timing, logging, and many integrations, but also carries the execution burden. "Shared responsibility" is not a fixed percentage; it changes with the service model.

Atlassian's current Confluence security overview says Data Center security is shared and directs customers to a security checklist. That is directionally correct, but the phrase becomes useful only when translated into named actions and evidence. The vendor fixes product code. The customer applies the fix and secures the deployment. The vendor supplies accurate compromise guidance. The customer retains and analyzes local evidence. The vendor cannot safely promise that a customer's server is clean; the customer cannot independently attest that the vendor's development controls prevented recurrence.

Migration to a hosted service can reduce emergency patch execution, but it is not a universal answer. Regulatory, residency, integration, performance, customization, or control requirements may support self-management. Cloud also creates concentration and provider-availability dependencies. The governance question is not which model is morally superior. It is whether the organization has funded the responsibilities that accompany the model it selected.

Responsibility should follow unique control and evidence

An accountability model should avoid two easy failures. The first assigns everything to the vendor because the defect was in its code. The second assigns everything after publication to the customer because a patch existed. Both erase important controls.

Control question	Atlassian responsibility	Customer responsibility	Evidence that should exist
Could the defect have been prevented or found earlier?	Secure design, code review, testing, dependency and framework expertise, vulnerability intake, and learning across similar injection flaws.	Procurement due diligence and configuration cannot repair a hidden product defect.	Vendor root-cause review, test additions, control owners, and validation results.
Was the warning actionable?	Accurate scope, severity, affected and fixed versions, safe artifacts, update history, mitigation, delivery channels, and support capacity.	Maintain current contacts, monitor advisories and KEV signals, acknowledge receipt, and open an owned emergency record.	Advisory timestamps, message delivery, acknowledgment, owner assignment, and escalation.
Was every deployment found?	Provide discoverable product identifiers and machine-readable affected-version data.	Maintain complete service, software, node, route, owner, and support inventories.	Reconciled inventory from configuration, network, cloud, licensing, DNS, and external discovery sources.
Was exposure contained?	Publish accurate restriction and mitigation options.	Block internet routes, isolate, disable, mitigate, upgrade, or remove according to risk.	Firewall and proxy changes, service state, change approvals, node-by-node timestamps.
Was the fix safe and complete?	Build, test, sign, backport, document, and support corrected releases.	Back up, test where feasible, install on all nodes, preserve configuration, and independently verify.	Artifact hashes, deployment logs, version output, health checks, vulnerability validation, and exception register.
Was compromise assessed?	Publish product-specific behaviors, indicators, log locations, known limitations, and support escalation.	Preserve local evidence, define the lookback, hunt, scope connected systems, rotate exposed credentials, rebuild where warranted, and meet reporting duties.	Evidence manifest, time sources, query results, forensic conclusions, credential actions, and legal decisions.
Did essential work continue?	Make emergency procedures concise and minimize avoidable upgrade complexity.	Maintain tested alternatives, offline runbooks, communications, recovery objectives, and restore authority.	Exercise record, fallback activation, outage duration, recovery tests, and business-owner acceptance.
Was recurrence reduced?	Publish control improvements and monitor related product paths.	Remove unsupported instances, reduce public exposure and privilege, improve logging, and fund maintenance.	Remediation plan with owners, deadlines, testing, and independent review.

This allocation also explains why customers need evidence from vendors. An advisory that says "upgrade immediately" is enough to trigger action, but not enough to evaluate product governance. Enterprise buyers and public bodies can reasonably ask for a confidential or public post-incident account, secure-development changes, independent assurance, and the time from validated report to fixed supported releases. Smaller buyers rarely have leverage individually, so standard vendor transparency has distributive value.

Vendors, in turn, need evidence from customers when support or incident analysis begins. Exact versions, node counts, topology, logs, timestamps, changes, plugins, and observed indicators can distinguish a product defect from deployment-specific impact. A vague assertion that "we patched" does not let either side reconstruct risk.

Responsibility can be shared without becoming diluted. The product flaw remains Atlassian's responsibility even where a customer ran Confluence as root. Root privilege remains the customer's responsibility even though the attacker entered through Atlassian code. Slow patching does not erase the defect; a fast fix does not erase unsafe exposure. Each control can contribute to the same loss and still have a distinct owner.

The evidence package for a trustworthy return to service

For boards and SME owners, the most useful output is not a large technical report. It is a compact evidence package that allows a skeptical reader to follow the decision from alert to closure.

The package should begin with a scope statement. It names CVE-2022-26134, the affected product families, the authoritative advisory version used, the date the organization first received notice, and the response owner. It lists all known instances and nodes, including non-production and stopped systems, and explains how the list was reconciled against DNS, load balancers, cloud accounts, licensing, external scans, configuration records, and provider data.

Next comes the containment record. For each instance, it shows whether and when internet traffic was blocked, the service was stopped, access was restricted, an interim mitigation was installed, a fixed release was deployed, or the system was removed. It records who authorized any period of continued operation and what compensating controls existed. An exception needs an expiry time and an escalation path.

The change record captures the pre-change version, target version, backup result, compatibility checks, maintenance start and end, artifact provenance, every node changed, configuration reapplied, errors, rollback decision, and post-change health checks. Because Atlassian warned that the fixed releases were not eligible for rolling upgrade, the record should also show the outage that was planned and what users were told.

The verification record should come from a method independent of the operator's memory. It can include current version output, package identity, checksums where supplied, authenticated software inventory, safe vulnerability validation, external reachability tests, and confirmation that no old node or image returned to service. The person who approves closure should be able to see the denominator and the result.

The compromise assessment states the investigated period, evidence sources, retention gaps, clock synchronization, indicators and behaviors tested, findings, and confidence. It distinguishes "no evidence of exploitation found" from "not compromised." If logs began after the plausible attack window, the limitation is a management fact, not a footnote to conceal. Where compromise is found, the package links to containment, credential rotation, connected-system review, notification, rebuild, and recovery decisions.

The continuity record identifies which business functions lost access, what alternative was activated, whether essential procedures remained available, actual downtime, data reconciliation needed after restoration, and the business owner's acceptance. Technical uptime alone is insufficient if staff could not reach the information needed to operate.

Finally, the recurrence plan assigns dated improvements. Typical actions include eliminating unsupported releases, moving the service behind controlled access, ensuring Confluence does not run with unnecessary privilege, centralizing logs, extending retention, testing restore, maintaining a staging path, updating vendor contacts, clarifying MSP duties, creating offline runbooks, and reviewing whether the chosen hosting model still fits organizational capacity.

This package is also a defense against hindsight bias. It records what was known at each decision point. On June 2, customers knew of active exploitation but did not yet have listed fixed versions. A decision to isolate immediately can be evaluated differently from a decision to wait after June 3. Good records preserve that difference.

Metrics that expose, rather than hide, the asymmetry

The common "mean time to patch" metric begins when a vulnerability record enters a tool and ends when installation is reported. It misses the part of this incident that carried the most accountability.

A better set would include:

Vendor report-to-advisory time: from a validated external report to an actionable public warning, with separate time to a supported fix.
Notice-to-owner time: from authoritative publication to acknowledgment by the technical and business owners.
Inventory reconciliation time: from notice to a defensible list of all instances, nodes, and routes.
Time to containment: from notice to isolation or effective mitigation of every known exposed instance.
Time to verified remediation: from notice to independent proof that the accountable estate is fixed, isolated, or removed.
Time to compromise decision: from notice to a documented conclusion with stated evidence limits.
Time to trusted restoration: from containment to business-owner acceptance of a secure and usable service.
Unaccounted estate: externally observed or licensed deployments that do not map to an owner and verified state.
Evidence coverage: the portion of the investigation window for which required logs and telemetry exist.
Continuity performance: actual interruption, fallback activation time, and essential functions sustained.

These measures prevent a vendor's fast release from masking downstream burden and prevent a customer's successful install from masking missing evidence. They also help procurement. A platform that can be upgraded reliably in hours, with machine-readable alerts and good detection support, imposes a different lifecycle cost from one that requires bespoke weekend work.

The metrics should not be used to punish teams for choosing safe downtime. If a performance target rewards availability while an unauthenticated RCE remains exposed, it creates the wrong behavior. Planned isolation is a control success when the alternative is uncontrolled compromise. The quality question is whether the interruption was anticipated, authorized, communicated, and recovered within tested objectives.

What the record proves, and what it does not

The public record supports several high-confidence findings. CVE-2022-26134 was critical, unauthenticated remote code execution in Confluence Server and Data Center. Atlassian Cloud was not affected. Exploitation occurred before public disclosure. Volexity notified Atlassian on May 31. Atlassian published an advisory on June 2 and fixed versions on June 3. CISA placed the vulnerability in KEV with a June 6 deadline. Public exploitation expanded quickly. The incident-specific fix required downtime rather than a rolling upgrade. A patch could not determine whether a customer had already been compromised.

Other conclusions require restraint. The record does not provide a verified worldwide count of vulnerable organizations, successful compromises, data losses, or outages. Unit 42's 19,707 figure described potentially affected internet-visible servers, not confirmed victims. DIVD's notifications described vulnerable instances it identified, not necessarily unique companies or exploited hosts. GreyNoise measured requests seen by its sensor network, not attacks against every Confluence server.

The record also does not establish when Atlassian first could reasonably have discovered the flaw, why it escaped pre-release controls, whether a particular earlier test would certainly have found it, or what internal corrective actions were completed. Affected-version history is not a substitute for a root-cause investigation. Nor does fast customer patching prove that no data was accessed before the patch.

The joint advisory on vulnerabilities routinely exploited in 2022 confirms the vulnerability's continuing threat relevance. It does not establish that every unpatched instance was compromised. Precision about these limits is not caution for its own sake. It keeps accountability attached to evidence instead of headline arithmetic.

The accountability finding

Atlassian's emergency response to CVE-2022-26134 was materially strong in the dimensions the public can measure: rapid confirmation, a prompt warning, active-exploitation language, fixed releases across maintained branches, interim mitigation, an update log, Cloud scoping, and support guidance. The most important unresolved vendor question lies earlier in the lifecycle. The public record does not explain the preventive control failure or provide enough evidence to assess the depth of post-incident secure-development change.

Customers had no control over the hidden defect, but they controlled whether a collaboration server was internet-facing, ran with excessive privilege, remained unsupported, had current owners, produced durable evidence, and could be taken down without losing essential operating knowledge. Those controls determined whether a vendor flaw became a brief managed interruption, an unprovable exposure, or a wider compromise.

For SMEs, the event exposes a market design problem as well as an internal one. The patch was available to every customer, but the capacity to consume it safely was unequal. A responsible vendor and partner ecosystem should reduce that gap through low-friction upgrades, actionable notices, supported mitigations, detection guidance, and clear service-provider duties. A responsible customer should not buy self-managed control without budgeting for the maintenance and incident work that control entails.

The final test is simple: after the patch shipped, who could prove what happened next? Atlassian could prove what it fixed and when it released the correction. Only each customer could prove which systems existed, when they were isolated, whether attackers had entered, what business functions were interrupted, and why the service was safe to restore. Risk persisted in that evidentiary gap. Closing it is the real work of accountability.