Cloudflare observations of Confluence zero day (CVE-2022-26134)

Atlassian Confluence Zero-Day: What Cloudflare Saw

On June 2, 2022, Atlassian disclosed a remote code execution (RCE) vulnerability affecting Confluence Server and Confluence Data Center. Cloudflare's security and WAF teams responded immediately, deploying initial mitigation rules for all customers within hours of the advisory. Internal reviews of Cloudflare's own Confluence instances found no signs of compromise.

Vulnerability Impact and Exploitation

According to Volexity's analysis, the flaw allows full unauthenticated RCE, effectively giving an attacker complete control over the target application. Observed attacks use command injection with specially crafted strings to load malicious classes in memory, followed by the deployment of webshells for persistent access.

Post-exploitation activity seen in the wild includes the implantation of:

• Behinder, a known malicious tool
• noop.jsp, a custom webshell that overwrites the legitimate file at <Confluence root>/confluence/noop.jsp
• Chopper, an open-source webshell

Attack Timeline and Observations

Cloudflare's review of WAF data identified requests matching potentially malicious payloads as early as May 26, 2022 at 00:33 UTC — roughly a week before the public advisory. This suggests that some attackers had prior knowledge of the exploit.

After Cloudflare's mitigation rules went live, a large spike in activity began on June 3 at 10:30 UTC, just over ten hours after deployment. This surge aligns with public release of proof-of-concept code and widespread awareness of the vulnerability. Attackers were actively scanning for vulnerable applications at the time of writing.

Cloudflare observed that many payloads matching the initial WAF rules after the advisory were invalid against this specific vulnerability. This suggests that scanning tools were being used to probe for attack vectors, and that precise exploitation knowledge was likely held by a limited set of actors. The subsequent decline in rule matches after June 3 at 23:00 UTC reflects the release of improved WAF rules that significantly reduced false positives.

A valid malicious URL targeting a vulnerable Confluence application appears below, where $HOSTNAME is the target application's host:

This URL executes the contents of the HTTP POST body, eval(#parameters.data[0]). In practice, this is typically a script that downloads a webshell to the server, enabling the attacker to run arbitrary commands on demand.

Other observed example URLs, omitting schema and hostname, include:

Some observed activity points to malware campaigns and botnet behavior. Due to the payload structure, other WAF rules — specifically PHP100011 and PLONE0002 — have also proven effective at mitigating certain attack variations.

Cloudflare's Internal Response

Cloudflare applies a defense-in-depth strategy, using its own products to protect its infrastructure. Given the security controls in place, there was high confidence that the vulnerability did not impact internal systems — a finding confirmed through comprehensive sweeps of internal assets and logs.

The key actions taken included:

1. Collecting intelligence about the attack.
2. Engaging the WAF team to develop mitigation rules.
3. Searching all logs for compromise indicators.
4. Reviewing internal Confluence logs for exploit attempts, using Atlassian's pattern strings of "${" as a filter.
5. Investigating any matches to determine whether they were genuine exploits (none were found).
6. Deploying WAF rules to all servers once quality was confirmed, protecting both customers and internal systems.
7. Inspecting Confluence servers for malicious implants — no signs of compromise were detected.
8. Adding detection rules to SIEM and monitoring systems for future exploitation attempts.

How Cloudflare Uses Confluence

Confluence serves as Cloudflare's primary internal wiki, used widely across teams for knowledge sharing. All internal instances are protected by Cloudflare Access, which requires every request to be authenticated and validated against Access policies. No unauthenticated requests reach Confluence servers, significantly reducing the risk of external exploitation attempts.

Recommendations for On-Premises Confluence Users

Atlassian customers running on-premises products should patch to the latest fixed versions immediately. Cloudflare additionally advises:

1. Deploy Cloudflare Access as an extra authentication layer in front of your applications.
2. Enable a WAF with coverage for CVE-2022-26134 in front of Confluence instances.
3. Review Confluence logs for signs of exploitation, searching for requests containing both /wiki/ and ${.
4. Use forensic tools to check for webshells or other post-exploitation indicators.

Indicators of Compromise and Attack

The following indicators relate to activity observed by Cloudflare in the wild. Searching logs for these can help determine if an environment has been compromised.

Indicators of Compromise (IOC)

Indicators of Attack (IOA)