Yes. CISA added CVE-2022-26134 to its Known Exploited Vulnerabilities catalogue on 2 June 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Atlassian Confluence Server and Data Center contain a remote code execution vulnerability that allows for an unauthenticated attacker to perform remote code execution.
How to interpret exploitation claims for CVE-2022-26134
The practical question is not whether the vulnerability exists, but whether there is credible evidence that attackers are using it now. For CVE-2022-26134, the key signals are CISA KEV inclusion, vendor guidance, and whether defenders are already seeing exploitation patterns consistent with unauthenticated remote code execution against exposed Confluence instances. That is what changes urgency, not the CVE label alone.
When a flaw is added to the KEV catalogue, it moves from theoretical risk to operational priority. For readers trying to decide whether the issue is active, KEV status is the fastest authoritative signal to treat the vulnerability as exploitation-relevant rather than merely patched-in-principle. CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database are the first places to validate the record and track the security context around it.
Why this matters operationally for Confluence Server and Data Center
This class of issue is especially serious because it combines internet-facing application exposure with remote code execution and no user interaction requirement. In practice, that means compromise can happen quickly once a vulnerable server is reachable, and the first observable signs may be post-exploitation activity rather than the initial exploit itself. For Atlassian environments, it is worth reviewing both the vulnerability and the deployment surface in the broader Atlassian Cloud Security Guide, because Confluence permissions, integrations and admin access often shape blast radius after exploitation.
The main security consequence is not only initial code execution, but what that execution enables next: credential access, persistence, data theft, and later movement into adjacent systems. Even when an organisation believes the application is “just internal,” exposed management interfaces, reverse proxies, or reused credentials can turn a single vulnerable server into a broader compromise path. The issue is therefore both a patching problem and a containment problem.
What defenders should do before, during, and after remediation
Start by confirming whether any Confluence Server or Data Center instance is exposed, whether it is internet-facing, and whether it is still within the vendor’s supported remediation path. If immediate patching is not possible, isolate the instance, restrict access aggressively, and treat the system as a potential compromise candidate until proven otherwise. A vulnerability-management workflow helps here because it forces scope, prioritisation, exception handling and verification into one decision path. Vulnerability Management Guide
After remediation, do not stop at “patch applied.” Look for web shell artefacts, suspicious admin actions, unusual plugin changes, unexpected outbound connections, and signs that attacker-controlled code ran before the fix. If the instance handled sensitive content or authenticated sessions, rotate any credentials, tokens or secrets that could plausibly have been exposed during compromise, especially where the server had integrations to source control, ticketing, chat, or cloud services. For attack-path thinking, MITRE ATT&CK Enterprise Matrix helps map the likely follow-on activity after initial execution.
Risk and Threat Considerations
The risk is not limited to the existence of a public exploit. Once a remote code execution flaw is known to be actively exploited, exposed systems face rapid opportunistic targeting, automated scanning, and follow-on compromise attempts that often outpace routine patch cycles. CISA’s KEV status is the strongest available signal that this is a live exploitation problem, not a hypothetical one.
Failure mechanism: An unauthenticated attacker can reach the vulnerable application path, execute code on the server, and then use that foothold to harvest data, deploy malware, or establish persistence before defenders notice.
Impact: The likely outcomes are server takeover, confidentiality loss, service disruption, and potential ransomware staging if the compromised Confluence instance has reach into shared credentials, files, or connected enterprise systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Actively exploited CVEs require prioritised remediation and verification. |
| Recommendation — Prioritise and verify remediation for KEV-listed vulnerabilities immediately. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Confluence RCE is exploitation of an exposed application service. |
| Recommendation — Hunt for exploitation of the public-facing application and review telemetry for follow-on activity. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE demands timely patching, validation, and exception handling. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and post-fix validation are central to this exploited CVE. | |
| Recommendation — Apply flaw-remediation processes and confirm the fix is deployed and effective. Scan for affected instances and reassess exposure after remediation. | ||
| OWASP ASVS | V4 — API and Web Service Security | The vulnerability is a web-exposed application execution issue. |
| Recommendation — Review exposed web-service paths and harden externally reachable application surfaces. | ||
Practitioner Guidance
What to prioritise: Treat internet-exposed Confluence Server and Data Center systems as the highest-priority assets until you confirm they are patched, isolated, and clean. If you have multiple instances, rank by exposure first, then by privilege level, then by the sensitivity of content stored on the platform.
What to verify: Confirm the vulnerable product line is present, confirm the patch or mitigation was actually applied, and confirm the server shows no post-exploitation indicators. If the application stores tokens, service credentials, or admin sessions, validate whether those should be rotated even if no clear compromise is yet visible.
Practitioner takeaway: For exploited CVEs, the right question is not “is there a patch?” but “has the system already been touched?” That determines whether you are doing routine remediation or incident response.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- How do you patch or mitigate CVE-2022-26134 (Atlassian Confluence Server and Data Center Remote Code Execution)?
- CVE-2022-26134 (Atlassian Confluence Server and Data Center Remote Code Execution)
- Is CVE-2023-22515 (Atlassian Confluence Data Center and Server Broken Access Control) being exploited in the wild?
- Is CVE-2022-41082 (Microsoft Exchange Server Remote Code Execution) being exploited in the wild?