Confluence OGNL Flaw: How WAF Rules Contained a Critical CVE Before the Public PoC

On August 25, 2021, Atlassian issued a security advisory for Confluence Server and Data Center concerning an Object-Graph Navigation Language (OGNL) injection vulnerability. The flaw, now tracked as CVE-2021-26084 with a base score of 9.8 (critical), allowed an unauthenticated attacker to execute arbitrary code on affected systems.

A full proof of concept (PoC) became widely available on August 31, 2021. Cloudflare reviewed the PoC and prepared an emergency mitigation rule, deploying it on September 1, 2021, at 15:32 UTC with a default action of BLOCK. The rule was issued under ID 100400 for the legacy WAF and e8c550810618437c953cf3a969e0b97a for the newer WAF.

All Cloudflare WAF customers protecting self-hosted Confluence applications were automatically shielded once the rule went live. However, the WAF had already been intercepting a significant volume of malicious requests to Confluence endpoints prior to that deployment. Additionally, organizations using Cloudflare Access in front of their Confluence instances were protected from the outset: Access validates a JSON Web Token (JWT) for every request to a protected hostname, so unauthenticated exploit attempts never reached the application server.

Despite these protections, Atlassian has emphasized that customers must update self-hosted Confluence installations to the patched versions listed in the original advisory to ensure complete remediation.

Attackers Moved Before the PoC Was Public

Analysis of sampled WAF block data—including request paths, geography, rule IDs, and timestamps—reveals that scanning for the vulnerability began up to three days before the first public PoC appeared. High WAF activity on the vulnerable endpoints started on August 28, 2021, suggesting that some attackers or researchers had successfully reverse-engineered the patch within that window.

Two endpoints were the primary targets of this early activity:

  • /pages/doenterpagevariables.action
  • /pages/createpage-entervariables.action

Even without the dedicated CVE-2021-26084 rule, Cloudflare's WAF was blocking exploit attempts. Other managed rules detected the suspicious behavior. Data from August 21 to September 5, 2021 shows blocked HTTP requests matching those paths amid a clear spike from August 28 onward, far exceeding normal background noise. On the day the PoC was published, more than 64% of the traffic increase was flagged and blocked as malicious.

What Attackers Attempted Pre-PoC

In the period before the PoC went public, the majority of blocked requests came from customer-configured IP-based rules, followed by Managed Rulesets and rate limiting. Those custom rules are typically created in response to observed malicious activity in WAF logs or as a positive security model for applications that should not be publicly reachable.

Filtering the Managed Rule matches uncovers the dominant attack vector during that pre-PoC window: command injection attempts designed to execute remote code on target servers. These attempts were frequently platform-specific, indicating partial awareness of the vulnerability's nature. Other attack classes observed, in descending order of frequency, included:

  • Request Port Anomalies — HTTP requests to uncommon ports not normally exposed for web traffic.
  • Fake Bot Signatures — user agents spoofing legitimate crawlers such as Google, Yandex, or Bing.
  • OWASP Inbound Anomaly Score Exceeded — requests flagged by Cloudflare's implementation of the OWASP ModSecurity Core Ruleset, a scoring system that identifies likely malicious patterns.
  • HTTP Request Anomalies — requests that tripped HTTP validation checks, including RFC compliance rules.

Layered Defense Matters

Rapid patching remains essential for mitigating zero-day and recently disclosed vulnerabilities, but no single control is sufficient. The traffic patterns observed around this CVE reinforce that defense-in-depth—combining vendor patches, managed WAF rules, custom access policies, and rate limiting—provides the most reliable protection for critical infrastructure. The data also shows that attackers may have been probing vulnerable Confluence endpoints as early as August 28, three days before the exploit was publicly documented.