Rogue ransomware affiliate poses as recovery firm to steal payments

FBI, UK gov’t urge orgs to patch Oracle E-Business vuln after alleged Clop campaign Oracle issued a security alert this weekend urging customers to patch a vulnerability currently being exploited by cybercriminals. Oracle’s security alert said CVE-2025-61882 impacts the Oracle E-Business Suite — a widely-used business platform containing several applications that manage finance, human resources and supply chain functions. Oracle explained that the vulnerability, which carries a severity score of 9.8 out of 10, could be exploited remotely “without the need for a username and password.” Customers need to install patches from an October 2023 update before installing the new patch issued on Saturday. Oracle also shared indicators of compromise that organizations can use to support their efforts to detect and contain potential breaches. FBI Assistant Director Brett Leatherman said “this is ‘stop-what-you’re-doing and patch immediately’ vulnerability.” “The bad guys are likely already exploiting in the wild, and the race is on before others identify and target vulnerable systems,” he said in a Sunday evening post on LinkedIn. “In plain terms: if your [E-Business Suite] environment is reachable on the network, and especially if it’s internet facing, it’s at risk for full compromise.” Leatherman added that Oracle E-Business Suite customers should isolate potentially affected servers and monitor threat intelligence channels because “exploit activity could escalate quickly.” “Oracle EBS remains a backbone ERP system for major enterprises and public-sector environments, which means attackers have every incentive to weaponize this one fast,” he explained. “If you suspect compromise - please connect with us.” Cybersecurity agencies in the U.K. and Singapore published their own advisories with similar guidance. The U.S. Cybersecurity and Infrastructure Security Agency added the bug to its Known Exploited Vulnerabilities catalog and ordered all federal civilian agencies to patch it by October 28. Mandiant chief technology officer Charles Carmakal tied CVE-2025-61882 to a campaign unveiled last week by the cybercriminal group Clop. The group is currently attempting to extort corporate executives by threatening to leak sensitive information they claim was stolen through the Oracle E-Business Suite. Oracle confirmed the campaign but initially said the hackers were exploiting bugs that had been addressed in a July update, without specifying which vulnerabilities were being used. On Sunday, Carmakal said Clop “exploited multiple vulnerabilities in Oracle [E-Business Suite] which enabled them to steal large amounts of data from several victims in August 2025.” “Clop has been sending extortion emails to several victims since last Monday. However, please note they may not have attempted to reach out to all victims yet,” he said. “Multiple vulnerabilities were exploited including vulnerabilities that were patched in Oracle's July 2025 update as well as one that was patched this weekend (CVE-2025-61882).” He added that organizations should “examine whether they were already compromised.” Several other cybersecurity experts confirmed that Clop has been exploiting multiple vulnerabilities in Oracle E-Business Suite since August. Jake Knott, principal security researcher at cybersecurity firm watchTowr, said exploit code for CVE-2025-61882 became public by Monday. Jonathan Greig is a Breaking News Reporter at Recorded Future News. Jonathan has worked across the globe as a journalist since 2014. Before moving back to New York City, he worked for news outlets in South Africa, Jordan and Cambodia. He previously covered cybersecurity at ZDNet and TechRepublic.

Researchers found a way to bypass recent mitigations for Spectre v2 speculative execution side-channel attacks and developed an exploit to leak secrets from Linux machines. The method works against Spectre v2 defenses on AMD and Intel processors that rely on sanitizing or isolating branch predictors, which researchers generically refer to as neutralization-based mitigations. Spectre v2 is also known as Branch Target Injection (BTI) and is a variant of the Spectre class of vulnerabilities. It exploits a processor's indirect branch predictor and causes it to mispredict the target of an indirect branch, leading to speculative execution along an attacker-influenced code path. Modern processors use branch prediction to guess the most likely execution path and speculative execution to run instructions along that predicted path before the branch outcome is known. Spectre v2 allows an attacker to manipulate the CPU's indirect branch predictor so that the processor speculatively executes instructions at an attacker-chosen location, which could expose sensitive data. With neutralization-based mitigations (eIBRS on Intel and Safe RET on AMD), there is a gap between the time the branch predictor is isolated and when it is used by the victim branch. Active Spectre v2 mitigations assume that an attacker cannot use to their advantage the time between cleaning the branch predictor state and using it. However, the researchers introduced a primitive that enables re-poisoning the CPU’s state after the cleaning but before it is used. Daniël Trujillo, a PhD student, and associate professor Mengjia Yan of the MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) discovered a technique for exploiting this Time-of-Neutralization to Time-of-Use (TONTOU) window to extract sensitive data. “An attacker without any special access to read arbitrary memory from the system, including sensitive data such as hashed passwords,” Trujillo told BleepingComputer. The researchers developed an Interrupt Injection attack, where “unprivileged user programs can schedule timer interrupts to occur during kernel execution.” “Therefore, we can force the kernel to be redirected to the interrupt handler and use this handler to poison microarchitectural states within the post-neutralization window,” the researchers explain. The researchers found that interrupts occurring during the post-neutralization window can be used to poison the processor's indirect branch predictor, enabling attacks against all types of indirect branches. Mengjia and Trujillo tested the attack starting from the assumption that an attacker can run arbitrary, unprivileged code on a Linux target machine to leak data from the kernel. On an AMD Zen 2 host with the latest Spectre v2 mitigations, the two researchers successfully ran through all the stages of a TONTOU attack: neutralization, redirection, poisoning, and the use of the poisoned branch predictors. Successfully exploiting the issue requires overcoming several obstacles, including redirecting kernel control flow, precisely aligning interrupts with the post-neutralization window, and using the interrupt handler to poison the branch predictor entry associated with the target indirect branch. The researchers address these challenges through installing ‘timers’ to trigger hardware interrupts, frequent injection of interrupts, and via active and passive poisoning methods. The attack was tested on both Intel and AMD processors. On an AMD Zen 2 system running Linux version 6.14.0-37-generic with 16GB of RAM, the researchers showed it could leak arbitrary kernel memory at a rate of 5.47 bytes/s and 91.97% accuracy, including the contents of /etc/shadow, which stores password hashes. Across 10 test runs, the attack successfully located and extracted the file in five cases, with each attempt taking an average of 18 minutes. While the attack is also possible on Intel machines, they noted that additional software requirements make the task more complex. The researchers note that interrupt injection enables attacker-controlled poisoning of the Return Stack Buffer (RSB), causing speculative mispredictions of return targets. Because passive RSB pollution is less reliable, they combined interrupt injection with Inception, a previously disclosed attack that Daniël Trujillo helped develop. AMD has published an advisory today noting that the interrupt inject issue "appears to be associated" with how implementation on Linux of the Safe RET mitigation against potential information disclosure attacks. Daniël Trujillo and Mengjia Yan presented their findings today at the Black Hat USA security conference. They will also share the details at the USENIX Security 2026 between October 27 and 29. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Mandiant and Google are tracking a new extortion campaign where executives at multiple companies received emails claiming that sensitive data was stolen from their Oracle E-Business Suite systems. According to Genevieve Stark, Head of Cybercrime and Information Operations Intelligence Analysis at GTIG, the campaign began in late September. "This activity began on or before September 29, 2025, but Mandiant's experts are still in the early stages of multiple investigations, and have not yet substantiated the claims made by this group," Stark said. Charles Carmakal, CTO of Mandiant – Google Cloud, stated that the extortion emails are being sent from a large number of compromised email accounts. "We are currently observing a high-volume email campaign being launched from hundreds of compromised accounts and our initial analysis confirms that at least one of these accounts has been previously associated with activity from FIN11, a long-running financially motivated threat group known for deploying ransomware and engaging in extortion," Carmakal explained. In an example of the extortion email shared with BleepingComputer, Clop says they breached the company's Oracle E-Business Suite in a data theft attack. "We are CL0P team. If you haven't heard about us, you can google about us on internet," reads the extortion email shared with BleepingComputer. "We have recently breached your Oracle E-Business Suite application and copied a lot of documents. All the private files and other information are now held on our systems." "But, don't worry. You can always save your data for payment. We do not seek political power or care about any business. So, your only option to protect your business reputation is to discuss conditions and pay claimed sum." "In case you refuse, you will lose all abovementioned data: some of it will be sold to the black actors, the rest will be published on our blog and shared on torrent trackers." Mandiant and GTIG report, and BleepingComputer has confirmed, that the email addresses listed in the extortion email are the same as those on the Clop ransomware gang's data leak site, indicating a possible link to the extortion group. However, Carmakal says that while the tactics are similar to Clop's previous extortion campaigns and the email addresses indicate a potential link, there is not enough evidence to determine if data has actually been stolen. Mandiant and GTIG recommend that organizations receiving these emails investigate their environments for unusual access or compromise in their Oracle E-Business Suite platforms. After publishing this story, Clop claimed to BleepingComputer that they are involved in the extortion email, indicating a bug in Oracle's product was exploited in the attacks. However, the threat actors would not share more detailed information about the alleged attacks. "We not prepared to discuss details at this time," Clop told BleepingComputer. "Soon all will become obvious that Oracle bugged up their core product and once again, the task is on clop to save the day. We do not damage to systems and only expect payment for services we provide to protect hundreds of biggest companies in world." Oracle also published a brief post today by Rob Duhart, Chief Security Officer, Oracle Security, who said that they believe the threat actors exploited vulnerabilities patched in the July 2025 security updates. "Our ongoing investigation has found the potential use of previously identified vulnerabilities that are addressed in the July 2025 Critical Patch Update," explained Duhart. "Oracle reaffirms its strong recommendation that customers apply the latest Critical Patch Updates." If you have any information regarding this incident or any other undisclosed attacks, you can contact us confidentially via Signal at 646-961-3731 or at [email protected]. Who is the Clop extortion gang? The Clop ransomware operation, also tracked as TA505, Cl0p, and FIN11, launched in March 2019 when it began targeting enterprise networks with a variant of the CryptoMix ransomware. Like other ransomware gangs, Clop members breach corporate networks, steal data, and then deploy ransomware to encrypt systems. The stolen data and encrypted files are then used as leverage to force companies to pay a ransom demand in exchange for a decryptor and to prevent the leaking of the stolen data. While the group is still known to deploy ransomware, since 2020, they have shifted to exploiting zero-day vulnerabilities in secure file transfer platforms to steal data. Some of their most notable attacks include: 2020: Exploiting a zero-day in the Accellion FTA platform, affecting nearly 100 organizations. 2021: Exploiting a zero-day in SolarWinds Serv-U FTP software. 2023: Exploiting a zero-day in the GoAnywhere MFT platform, breaching over 100 companies. 2023: Exploiting a zero-day in MOVEit Transfer was Clop's most extensive campaign to date, where a zero-day exploit allowed data theft from 2,773 organizations worldwide. The most recent campaign associated with Clop was in October 2024, when the threat actors exploited two Cleo file transfer zero-days (CVE-2024-50623 and CVE-2024-55956) to steal data and extort companies. The U.S. State Department currently offers a $10 million reward through its Rewards for Justice program for information linking Clop's ransomware activities to a foreign government. Update 10/2/25: Added sample of Clop extortion email being sent to companies. Update 10/2/25 07:42 PM ET: Added statement from the Clop ransomware gang and further info from Oracle. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A vulnerability in Google’s Brotli data compression library, tracked as CVE-2026-111497 and dubbed Node2Shell, has led to security updates from Microsoft, the Node.js project and the maintainers of two Python packages. Node.js and the Python packages were patched last week, and Microsoft followed on October 25 with fixes for .NET, Visual Studio and PowerShell. Bun, Envoy and Istio have also been updated. Brotli is a popular choice for compressing data sent over the web, and its decoder is embedded in a long list of applications and libraries. Described as an out-of-bounds write, the bug impacts Brotli 1.0.3 through 1.2.0. Google gave it a CVSS v4 score of 9.2, which puts it in the critical category. Brotli versions 1.0.10, 1.1.1 and 1.2.1 contain the fix. The Node.js project said specially crafted input can push data beyond the limits of a buffer used by the decoder. The resulting memory corruption could cause the process to crash or leak memory contents, and could also allow an unauthenticated attacker to run arbitrary code. Node.js credited the discovery to members of OpenAI Codex Security. According to OpenAI, the issue was uncovered during red-teaming work, after which the company notified the Brotli developers and the projects that rely on the library. OpenAI noted that the fix predates the disclosure. “This root cause issue was actually fixed in the Brotli source code in February, but it wasn’t known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli,” the AI company said. Code execution demonstrated on official Node.js image Imperva has shown that it can be exploited for code execution on the official Node.js 24.22.0 image for Linux arm64. Its researchers sent the malicious data both in a server response retrieved by the targeted application and in a request body processed by Express 5 or body-parser 2. “The proof did not succeed on every attempt. Our results establish code execution for the tested Linux arm64 build and application setups, and show how the fixed build handled the same inputs,” Imperva said. The security firm has not made its exploit public. Attacks only work if malicious Brotli data reaches the decoder, for instance through a library that unpacks compressed content on the application’s behalf. “Any application that passes attacker-controlled data to an affected Google Brotli decoder may be exposed. This includes compressed HTTP request bodies, responses fetched from untrusted servers, and compressed files,” OpenAI’s Patch the Planet initiative said in its advisory. No exploitation in the wild has been reported so far. A proof-of-concept exploit published on GitHub reportedly achieves code execution only against an intentionally weakened build, and some researchers argued the bug can only be used for denial-of-service (DoS) attacks. Microsoft products and Python packages affected Microsoft’s October 25 updates include .NET runtime versions 8.0.33, 9.0.22 and 10.0.14, along with .NET 11 Release Candidate 3. Visual Studio 2019, 2022 and 2026, as well as PowerShell 7.4, 7.5 and 7.6, have also been updated. Microsoft has categorized CVE-2026-111497 as an elevation of privilege issue with a CVSS v3.1 base score of 8.1. It rates the flaw critical for .NET and Visual Studio and important for PowerShell, and its exploitability assessment is “Exploitation More Likely.” In Python’s case, the vulnerable decoder is built into two PyPI packages, Brotli and brotlicffi. They have been patched with the release of versions 1.2.1 and 1.2.1.0, respectively. As more affected software emerged, researchers began referring to the flaw as HTTP2Shell and Broccoli2Shell. A public tracker of software that bundles its own copy of the Brotli decoder lists several projects that are still unpatched, including DuckDB, Apache Arrow, 7-Zip-zstd, p7zip and EDK II. Its maintainers say the list is incomplete, and that not every configuration of these projects necessarily exposes the vulnerable code. Applying the updates also requires restarting affected services and rebuilding container images on top of a patched base, since processes that are already running keep using the vulnerable code. Related: Mirai Botnet Operators Join PHP2Shell Attacks as ASLR Bypass Exploits Emerge Related: Attackers Exploit Third Arista VCO Zero-Day in Four Months Related: LiteLLM Compromised in Fresh Supply Chain Attack

On October 21, 2026, the PHP project released emergency fixes for two critical remote code execution (RCE) vulnerabilities in the PHP core runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell. Both are rated 9.2 (Critical) under CVSS v4.0, and both allow an unauthenticated attacker to run code on a vulnerable server. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Patching is the only complete fix, and you should upgrade PHP as your first priority. But patching a fleet takes time: you need to inventory where PHP runs, schedule maintenance windows and test applications against the new builds. This post shows you how to use AWS Web Application Firewall ( AWS WAF ) to help reduce exposure to the confirmed attack paths during that window. You’ll learn which request patterns to block, how to write the rules in AWS WAFv2, how to deploy them without breaking legitimate traffic and where its protection ends, so you don’t develop a false sense of safety. For how Amazon threat intelligence detected PHP2Shell exploitation before public disclosure, see Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot . For AWS service status and the AWS WAF rule that AWS recommends, see AWS Security Bulletin 2026-143-AWS . IMPORTANT: Patching is the only complete fix, and you should upgrade PHP as your first priority. The vulnerabilities in brief Both PHP2Shell vulnerabilities are unauthenticated RCE issues rooted in how PHP handles multipart/form-data request processing (the request format browsers use for file uploads) before your application code runs, which is why the AWS WAF rules in this post focus on multipart traffic, request body size, and the session upload progress field. At a high level, CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request, and CVE-2026-109619 lets one request leave behind stale data that a later request on the same worker process reuses. For the root-cause analysis, affected versions, and PHP’s own guidance, see the official PHP advisories and release announcement: CVE-2026-109618 (out-of-memory corruption) – PHP advisory GHSA-w8hw-w9fx-j79w CVE-2026-109619 (stale global state) – PHP advisory GHSA-6wmf-4rv5-p3rp PHP security release announcement, October 21, 2026 Where AWS WAF fits in your response AWS WAF is a defense-in-depth control in this situation, not a replacement for the PHP upgrade. The PHP advisories are explicit: updating to a patched release is the only complete mitigation. One of the two vulnerabilities is largely outside the reach of any web application firewall, as explained later. Treat the rules in this post as mitigating controls that help reduce exposure while you patch, then remove them or keep them as supporting controls after you’ve patched. AWS WAF inspects HTTP requests at the edge. It doesn’t parse the internal structure of a multipart body, and it has no visibility into PHP worker memory or server-side configuration. The following table maps each attack element to whether AWS WAF can help mitigate it. Attack element AWS WAF coverage Session upload progress field in a multipart POST ( PHP_SESSION_UPLOAD_PROGRESS , the form field that turns on PHP’s upload-tracking feature) Yes. A targeted rule can block requests carrying that field. Multipart upload path ( multipart/form-data , the request type used for file uploads and the entry point for both vulnerabilities) Yes, if the application has no legitimate multipart uploads. Block multipart/form-data. Out-of-memory condition from an oversized body Partial. Cap the request body size. Doesn’t catch header amplification (many small part headers that cost far more memory to represent than their size on the wire) that stays under the cap. Repeated attempts against the same worker (the reused PHP process that handles many requests) Yes. A rate-based rule blunts the volume an exploit needs. fatal_error_backtraces producer (a PHP 8.5 setting that stores crash-trace state across a request) No. This is a server configuration setting ( fatal_error_backtraces=0 ). Invalid or deprecated INI diagnostics as a consumer (warnings PHP raises when applying bad configuration settings) No. This path runs server-side, not over client HTTP. Where an application does not accept multipart uploads, an edge rule that blocks multipart/form-data removes the multipart out-of-memory path that works against any application, plus the session-upload-progress trigger, which is a defense-in-depth control during the patch window. If your application does use multipart uploads, AWS WAF reduces risk but does not close the vulnerability, because header amplification (a few kilobytes of part headers that expand into far more memory inside PHP) stays within size limits and the firewall cannot parse the headers inside individual body parts. In that case, prioritize the PHP upgrade and apply the server-side mitigations described later. Implementing the AWS WAF rules The rules below are AWS WAFv2 JSON, deploy each of them on the WAF protection pack (web ACL) associated with the Amazon CloudFront distribution, Application Load Balancer, or Amazon API Gateway stage in front of your PHP workloads. IMPORTANT: Before implementing any changes, ensure that your WAFv2 logging is setup in line with AWS WAF Logging guidance. Start every rule in Count mode, confirm it does not match legitimate traffic, then switch to Block. Request body inspection limits AWS WAF inspects a bounded portion of the request body. On Application Load Balancer and AWS AppSync the limit is a fixed 8 KB. For AWS services such as CloudFront and API Gateway, the default is 16 KB and you can raise it to 32, 48, or 64 KB through the web ACL AssociationConfig as seen below. Any part of the body beyond the inspection limit counts as oversize. Choose the limit that fits the rules you deploy, because a body-size rule can only enforce a cap up to the inspected size. aws wafv2 update-web-acl ... --association-config \ 'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}' AWS WAF Rule This rule targets both CVEs by blocking a request only when all three conditions in its AndStatement are true at once: The method is exactly POST – matched on the HTTP method, no transformation. A PHP session identifier is present (the nested OrStatement , so either sub-condition satisfies this leg): PHPSESSID appears as a cookie key (exact match on the key, scanning all cookies), or PHPSESSID appears anywhere in the request body (contains match). The body contains PHP_SESSION_UPLOAD_PROGRESS – the form field that activates PHP’s session upload progress feature. Pair the rule with session.upload_progress.enabled=0 on the server, which turns the feature off. { "Name": "PHP2Shell", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, { "ByteMatchStatement": { "SearchString": "PHP_SESSION_UPLOAD_PROGRESS", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2Shell" } } Additional WAF Rules to consider Block multipart requests when the application has no uploads NOTE: This rule, if implemented in Block mode, will break applications that require file uploads. If your application does not require file uploads, then blocking multipart/form-data removes the multipart out-of-memory path that works against any application for both CVEs at the edge. A single named header is inspected in full, with no 8 KB header cap, so matching the Content-Type header is reliable. { "Name": "Block-Multipart-FormData", "Priority": 1, "Action": { "Count": {} }, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "content-type" } }, "PositionalConstraint": "CONTAINS", "SearchString": "multipart/form-data", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockMultipart" } } Cap the request body size Capping body size reduces the out-of-memory condition behind CVE-2026-109618 and the stale state it can leave behind. Use OversizeHandling: MATCH with a size constraint so that any body larger than the threshold is blocked, including bodies that exceed the inspection limit. To enforce a cap of N bytes, the web ACL body inspection limit must be at least N. Note that you can’t cap the numeric Content-Length with a size constraint, because the constraint measures the length of the header value string, not the number it contains. If your application has legitimate large uploads, scope this rule to non-upload paths with an AndStatement on the URI path, or it will break those uploads. { "Name": "Block-Oversize-Body", "Priority": 3, "Action": { "Count": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 8192, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockOversizeBody" } } NOTE: if you already have the AWSManagedRulesCommonRuleSet managed rule group, the SizeRestrictions_BODY rule blocks bodies larger than 8 KB by default. If a specific managed rule breaks legitimate traffic, override that rule to Count rather than disabling the whole group. Rate-limit repeated attempts A rate-based rule on POST requests can reduce the volume an attacker can send, lowering the possibility that the vulnerabilities can be triggered by overloading the worker, while the stale-state path needs a producer request and a consumer request to land on the same worker. This rule complements a server setting of pm.max_requests=1 , which recycles the worker on each request. { "Name": "RateLimit-Posts", "Priority": 4, "Action": { "Count": {} }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "Method": {} }, "PositionalConstraint": "EXACTLY", "SearchString": "POST", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellRateLimitPosts" } } Server-side mitigations that complement AWS WAF These host and runtime changes address the parts of CVE-2026-109619 that sit below the HTTP layer a WAF inspects, so they fall outside its scope by design. Apply them alongside the AWS WAF rules as the host and runtime layer of your defense. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. This is the only complete fix. PHP 8.1 and earlier are no longer supported upstream, so check with your distribution or long-term support vendor for a backported fix, or plan a move to a supported branch. Address CVE-2026-109618 at the PHP level. Set memory_limit=-1 so applications cannot override it, and keep post_max_size low (8M where the application accepts no uploads, 32M where it does). Enforce memory bounds through container or cgroup limits, never through RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable out-of-memory path. Set fatal_error_backtraces=0 on PHP 8.5 and restart every worker. This disables the setting that stores crash-trace state across a request, one of the confirmed ways the vulnerability is triggered. Set session.upload_progress.enabled=0 and restart every worker. This turns off the upload-tracking feature that’s the other confirmed trigger, and is prudent to keep off even after patching. Prefer php.ini , FPM pool, or server startup configuration over per-request INI overrides (settings applied per request through .htaccess , php_value , or FastCGI PHP_VALUE) . Remove obsolete directives so they don’t raise diagnostic warnings. Eliminate fatal errors and execution timeouts on attacker-reachable routes, including upload, import, error-page, shutdown, serialization, and extension paths. Set pm.max_requests=1 if performance allows , so each worker process is recycled after one request, which breaks the link between the request that plants stale data and a later request that would reuse it. Turn on error logging ( log_errors=On , a working error_log , error_reporting=E_ALL ) and review your Apache, FPM, or proxy logs for repeated warnings, deprecations, fatal errors, and timeouts on attacker-controlled routes. The absence of errors is not proof of safety. Getting started Complete the following steps to get started: Inventory where PHP runs and which versions and server APIs (mod_php, FPM, FrankenPHP, LSAPI) are in use. Identify any public endpoint that accepts a request body. Decide whether each application uses multipart uploads. This determines whether you can deploy the WAF rule to block multipart requests. Create or update the web ACL in front of each PHP workload and add the applicable rules in Count mode. Raise the body inspection limit on CloudFront or API Gateway if a rule needs it. Watch the sampled requests and Amazon CloudWatch metrics for each rule. Confirm that legitimate uploads and large JSON POSTs aren’t matched. Switch the rules to Block after the metrics are clean. Order the priorities so the session upload progress and multipart rules run before the size and rate rules. Test with a benign multipart/form-data POST, an oversized body, and a request carrying PHP_SESSION_UPLOAD_PROGRESS . Expect a 403 response and the matching rule metric. In parallel, apply the PHP upgrade and the configuration mitigations. Remove or retain the AWS WAF rules as supporting controls after your fleet is patched. Conclusion The PHP2Shell vulnerabilities—CVE-2026-109618 and CVE-2026-109619—are unauthenticated RCE vulnerabilities that reach PHP before your application code runs. AWS WAF gives you a way to help narrow the attack surface during the patch window: block the session upload progress field, block multipart requests where no uploads are expected, cap request body size, and rate-limit repeated attempts. These mitigating controls can help reduce exposure, but they don’t close the vulnerabilities. Upgrade PHP to a fixed release, apply the server configuration changes, and treat the AWS WAF rules as the edge layer that supports those fixes rather than the fix itself. To learn more about the rule types used here, see the AWS WAF documentation on the web ACL body inspection limit , oversize request component handling , and handling oversize HTTP request bodies . For the vulnerability details, see the PHP advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp , and the PHP session upload progress manual . Alex Waddell Alex Waddell is a Principal Solutions Architect at AWS specializing in security within the Worldwide Specialist Organization, based in Scotland. Alex has been working in the security domain since 1999 and joined AWS in 2021 to work with customers across EMEA on cloud security architecture, identity, threat detection and application security. When he is not working, Alex enjoys spending time sampling rum from around the world (Alex is one of those rarely found Scottish people that doesn’t like whisky), walking his dogs in the local forest trails and traveling. Lawton Pittenger Lawton is a Worldwide Security Specialist Solutions Architect at AWS, based in New York City. He specializes in helping customers design and implement effective network security controls. At AWS, he works with customers at scale and collaborates closely with service teams to drive continuous improvement in security services based on customer needs and feedback. Outside of work, his interests include skateboarding, snowboarding, and spending time in nature. Ian Olson Ian is a Senior Security Specialist Solutions Architect at AWS. He helps customers automate security services to safeguard against threats like DDoS and web exploitations. Through intelligent automation, he delivers security solutions tailored to organizations of any scale. When he’s not working, Ian enjoys spending quality time with his two young children.

GTIG highlighted indicators that Clop is behind the extortion campaign targeting Oracle EBS instances, with its activity likely beginning as early as August 9