Remote Code Execution

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.

PHP developers have accused software supply chain security shop Chainguard of effectively revealing critical bugs in the open-source scripting language ahead of a planned official disclosure. On Wednesday, just hours after releasing emergency patches for the two bugs collectively called PHP2shell, PHP maintainers published a blog about how the vulnerabilities were found and fixed. They credited researchers at Calif, OpenAI, and Wiz with finding the security holes between August and September. All three companies have said they used AI models to find the vulnerabilities, which are now tracked as CVE-2026-109618 and CVE-2026-109619, and can allow an unauthenticated attacker to execute code on servers running PHP. This is especially serious because PHP powers huge chunks of the public web. It also adds a dose of irony to the “leak and disrupted disclosure” part of the blog, which blames Chainguard - a company that aims to secure software supply chains by hardening open source code - for the messy disclosure. The trouble, according to PHP developers, started on Tuesday around 15:00 UTC, when “two CVE IDs began circulating on online forums and social media,” along with incorrect information about the release time and CVSS severity rating. At that point, no technical details leaked. The rumors, however, prompted PHP maintainers to warn people in advance about the critical flaws, and move the planned disclosure forward a day, from Thursday to Wednesday. “Distributors were still packaging the fix, so releasing immediately would have left many users without an easy way to update,” the PHP Foundation blog says. “Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.” A couple of hours later, Calif “mistakenly” published a video showing a proof-of-concept exploit and “additional, though limited” information about the bugs, we’re told. “Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well,” the PHP blog says, but it does not name these providers. And then it throws Chainguard under the bus: “On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.” Chainguard CEO: 'We made the call' Chainguard CEO Dan Lorenc spoke with The Register on Wednesday, and while he doesn’t dispute the timeline, said his company "didn't leak." “These things are messy,” Lorenc said. Chainguard learned “something was coming in PHP” on Friday from one of the researchers that found the bugs, Lorenc told us. Later that night, using his company’s AI harness and a frontier model, the CEO and the Chainguard team independently found the same memory corruption vulnerabilities. All it took was a “basic prompt of ‘find bad vulnerabilities in PHP,’” Lorenc wrote in a subsequent LinkedIn post. On Saturday, Chainguard began working with the PHP maintainers, confirmed that some of its findings matched the bug reports, and helped test the patches. “The patches are crazy - this is not a simple vulnerability,” Lorenc told The Register. “It really did take them months to build a real, working patch for it. And then on Monday, the rumors started, and yesterday it just spiraled.” Some people published POCs on social media, other security vendors reported seeing real-world exploitation, and late Tuesday night Lorenc told us he decided to ship the fixes, and notified the PHP coordinated disclosure channel about his plans. “People were getting hit in advance” of the official PHP disclosure, “so we made the call to ship the fixes under that,” Lorenc said. “It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild.” Also on Tuesday night, Chainguard published built artifacts and made them accessible to anyone, not just customers. “And then I woke up this morning and saw that this was all our fault,” Lorenc said. When asked if he would do anything differently, given the fallout from Chainguard’s early disclosure, Lorenc said no. “This process and policy is based on trying to coordinate as much as possible until shit hits the fan and people start weaponizing things,” he said. “It sucks, because we really are all on one team, and there's bad guys over there doing stuff.” Chainguard’s honeypots trapped IPs from China and Russia targeting the vulnerabilities on Wednesday, Lorenc added. “Just being told there's a vulnerability in a piece of software - even something as big as PHP - is enough to find it,” he told us. “I did that myself without any other knowledge on Friday." "I think this is kind of the new normal. People are able to build an exploit in hours without even knowing what the vulnerability is." What we know about the CVEs and how to exploit them While we still don’t know the scope of exploitation - or what will happen to vulnerable legacy systems that don’t have security fixes - threat hunters predict it’s going to be a doozy. “Successful exploitation could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them,” Wiz researchers Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz warned on Wednesday, adding the oft-quoted stat that PHP powers 70 percent of all websites in the world. “Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4,” the Wiz kids wrote. “Attackers can exploit them remotely, in some cases fairly easily. Immediate patching is strongly advised.” Both bugs are related to how PHP handles memory management and error handling, and both lead to remote code execution (RCE). They can cause a corrupted internal PHP state when a request ends unexpectedly, and then a later request can reuse that state, leading to memory disclosure or RCE. “Both are memory corruption vulnerabilities,” VulnCheck researcher Patrick Garrity explained. “If an attacker can shape the memory PHP trusts, they can potentially hijack what it does next, and in these cases that means remote code execution.” CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) leads to RCE via out-of-memory corruption. “If a request reached PHP's memory_limit at exactly the wrong moment, PHP could leave partially initialized internal data behind and later treat it as valid, corrupting memory,” the project maintainer wrote. “On Apache with mod_php, an unauthenticated request can trigger this before any application code runs.” CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) allows RCE via stale state. “A fatal error at the wrong point could leave internal state pointing to memory that belonged to a previous request,” according to the PGP Foundation. “A later request handled by the same worker could then use that freed memory. A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php.”®

Bulletin ID: 2026-098-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/04/2026 10:30 AM PDT Description: log4j-cve-2021-44228-hotpatch is a tool which injects a Java agent into a running JVM process. The agent will attempt to patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string "Patched JndiLookup::lookup()". It is designed to address the CVE-2021-44228 remote code execution issue in Log4j without restarting the Java process. We identified CVE-2026-85656, an OS command injection issue in the log4j-cve-2021-44228-hotpatch package in Amazon Linux before 1.3-9.amzn2 might allow a local user to execute arbitrary commands with root privileges via a Java process whose executable path contains embedded newline characters. Impacted versions: <=1.3-8.amzn2 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

Bulletin ID: 2026-143-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 10/21/2026 14:30 PM PDT Summary: Two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) allow an unauthenticated remote actor to execute code, access process-accessible data, or cause denial of service on affected PHP workers. Customers running affected PHP versions (8.2–8.5 below the fixed releases, and end-of-life 5.4–8.1) should upgrade immediately to a patched release (8.5.12, 8.4.27, 8.3.36, or 8.2.35); configuration changes alone are not complete mitigations. AWS has identified a limited set of services that run affected PHP versions and is actively deploying mitigations and updates. Review the full bulletin for per-service status, mitigation guidance, and AWS WAF compensating controls. Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin. Read this article

PHP.net announced that it will release a critical update today. We decided to change the infoCon to YELLOW due to the widespread use of PHP, the expected severity of the flaw (CVSS 9.4), and the availability of early PoC exploits before the patch became available.

Bulletin ID: 2026-085-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 08/20/2026 13:30 PM PDT Description: Improper input validation in the Time Series Visual Builder (TSVB) plugin in OpenSearch Dashboards before 3.8 allows a remote authenticated user with standard data access permissions to execute arbitrary code on the server by sending a crafted JSON payload to the metrics visualization API endpoint. To mitigate this issue, users should upgrade to OpenSearch Dashboards 3.8 or later. Impacted products and versions: - OpenSearch-Dashboards (open-source, self-managed): >=3.0.0, <3.8.0 - OpenSearch-Dashboards (AWS Managed): >=3.0.0, <3.8.0 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

In a lengthy statement about two critical vulnerabilities, the PHP Foundation explained how one dated to 2024, how a recent third-party review by AI companies heightened attention on both, why it scrambled to post information earlier than planned.

On 20 October 2026, the PHP project announced an upcoming security release addressing two critical vulnerabilities in PHP. Public reports indicated that these vulnerabilities could lead to remote code execution. The PHP team released the fixes today, 21 October 2026 at 13:30 UTC, in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both vulnerabilities can allow unauthenticated remote code execution. Technical details are now being discussed publicly, and initial proofs of concept (PoCs) have begun to circulate. This raises the likelihood that attackers are already exploiting the vulnerabilities. CERT-EU advises organisations to patch affected assets immediately. Where that is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified.

Several cybersecurity companies saw exploitation attempts of CVE-2026-109618 and CVE-2026-109619 before PHP released the patches. The post PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors appeared first on SecurityWeek .

CVE-2026-109618 and CVE-2026-109619 are Critical vulnerabilities in PHP, a scripting language used globally for web servers and CMS systems. The post Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619 appeared first on Unit 42 .

Cisco ha rilasciato aggiornamenti di sicurezza per risolvere 34 vulnerabilità nei propri prodotti, di cui 5 con gravità “critica” e 17 con gravità “alta”.

ISC ha rilasciato aggiornamenti di sicurezza per BIND 9 e BIND Supported Preview Edition, software per la gestione e la risoluzione delle richieste DNS, che sanano 4 vulnerabilità con gravità "alta". Tali vulnerabilità possono permettere l'esecuzione di codice arbitrario o compromettere la disponibilità del servizio sui sistemi interessati.

Expect to see quite a few websites serving error pages today: Nearly 70 percent of websites need to update their core software to fix a pair of vulnerabilities that allow an attacker to seize full control over affected servers. Experts say there are working exploits for the flaws, and that these critical bugs are already being exploited in the wild. Image: Shutterstock.com, Sashkin. The flaws at issue are present in PHP , the programming language that powers sites running on a large number of web publishing systems, including Drupal , Magento , Joomla and WordPress . Earlier today, PHP released an emergency security update to fix two critical bugs that can allow an attacker to execute code of their choosing on a vulnerable server. Reuters reports that government websites in Europe and elsewhere went offline today after the PHP vulnerabilities were disclosed. Cloudflare said it has already detected some exploitation of the flaw, and that at 3:02 am (UTC) it implemented web application firewall rules to protect websites from attack traffic seeking to exploit the bugs, which could cause a denial of service condition, remote code execution, and data exposure. OpenAI , which was involved in the vulnerability research and outreach, said “given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory.” Censys , a company that tracks the technology used by Internet hosts, said a recent scan identified approximately 2.58 million Internet facing hosts and 54.9 million web properties running PHP. Security experts at Wiz said every PHP version released in the last decade is affected by at least one of these vulnerabilities [full disclosure: Wiz is an advertiser on this blog]. “These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history,” reads a blog post published today by a team of researchers at Wiz, which was one of several organizations credited with discovering the vulnerabilities. “The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.” The Wiz researchers say it is likely the PHP vulnerabilities will be mass-exploited to install web-based backdoors or “web shells,” which give attackers a web-based panel that allows them to remotely control infected sites. Wiz said that prior to the PHP bugs being publicly disclosed, the company worked with the PHP team, Calif and OpenAI to measure the size of the problem and coordinate patch verification and disclosure. The PHP zero-day vulnerabilities are being tracked by their CVE numbers, CVE-2026-109618 and CVE-2026-109619 , and they affect all web servers running PHP 5.4 or later. The bugs are fixed in PHP 8.5.12 , 8.4.27 , 8.3.36 , and 8.2.35 . According to Wiz, PHP is so deeply embedded in many web applications that we are likely to see organizations struggling to patch these vulnerabilities for some time to come, comparing this PHP vulnerability pair with the Log4Shell weakness that emerged in 2021 — a widespread, severe-as-it-gets security flaw in Log4j, a popular Java logging framework. “A vulnerability in core PHP reaches far beyond a single application,” the Wiz researchers wrote. “PHP runs across clouds, hosting providers, content-delivery networks and millions of independently managed servers. Reducing exposure before the technical details became public required coordinated work across that entire ecosystem.” The SANS Internet Storm Center is keeping an eye on major software platforms that are shipping updates to deal with these PHP flaws. For example, Ubuntu just released updated PHP packages. For a technical deep-dive on these vulnerabilities that tells the timeline of the discovery of these bugs in a comic book style, check out this post from Calif , another technology company credited with finding the PHP flaws. This is a fast-moving story. Updates will be noted here with timestamps. Update, 2:30 pm ET: Add figures from Censys and a link to Calif’s writeup.

Disponibile un Proof of Concept (PoC) per lo sfruttamento della CVE-2026-103663 presente in Ollama, noto motore di inferenza open source che consente di eseguire LLM in locale. Tale vulnerabilità potrebbe consentire a un utente malintenzionato remoto non autenticato di eseguire codice arbitrario sui sistemi interessati.

PHP developers have released emergency updates for two critical vulnerabilities after cybersecurity authorities warned organizations to patch immediately or consider taking exposed applications offline. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 address CVE-2026-109618 and CVE-2026-109619, which can allow unauthenticated remote code execution. The project's developers urged users to update immediately. All PHP installations serving web requests are potentially affected, including deployments using PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP, and LiteSpeed, the developers said. "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Jake Knott, head of threat intelligence at watchTowr, said: "As expected, watchTowr Intel is already observing in-the-wild exploitation of the latest PHP vulnerabilities, with a variety of vibecoded PoCs already hitting our sensors featuring a variety of 'php2shell' User-Agents. Whilst nobody has been successful to date, we don't expect that will last long." "Where immediate patching is not feasible, organizations should consider isolating internet-facing applications from public networks until a fix is available," CERT-EU said in an advisory issued ahead of the patches. The body lists both vulnerabilities with CVSS scores of 9.2. Finnish government services and websites belonging to the Dutch parliament, cybersecurity authorities, and data protection regulator were taken offline as a precaution. Privacy campaign group noyb also temporarily withdrew its website. PHP "powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn't even advertise that it runs PHP under the hood," infosec vendor Huntress noted. That makes identifying exposed installations a substantial job. "The number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast," said John Hammond, Huntress's senior principal security researcher. ®

Aggiornamenti di sicurezza sanano 2 nuove vulnerabilità con gravità "critica" in PHP, noto interprete del linguaggio di scripting per lo sviluppo web. Tali vulnerabilità interessano la componente php-src e, qualora sfruttate, potrebbero permettere a un utente malintenzionato remoto di eseguire codice arbitrario sui sistemi interessati.

The maintainers of the globally used PHP scripting language released patches for two vulnerabilities after alerting users that the bugs were severe.

The PHP security team released emergency security patches for two critical remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) tracked collectively as PHP2Shell. [...]

PHP heeft twee kritieke kwetsbaarheden verholpen. De kwetsbaarheden kunnen zonder authenticatie op afstand worden misbruikt voor het uitvoeren van willekeurige code. Alle PHP-installaties die webverzoeken verwerken zijn getroffen. De kwetsbaarheid met kenmerk CVE-2026-109618 betreft geheugenbeschadiging bij de afhandeling van een Out-of-Memory-situatie. Hierdoor kunnen interne requestgegevens slechts gedeeltelijk worden geïnitialiseerd en tijdens de verwerking als geldige gegevens worden behandeld, wat kan leiden tot Remote Code Execution. De kwetsbaarheid met kenmerk CVE-2026-109619 betreft het achterblijven van interne globale status nadat het bijbehorende geheugen is vrijgegeven. Een volgend verzoek dat door dezelfde worker wordt verwerkt, kan deze verouderde status gebruiken voordat deze opnieuw wordt geïnitialiseerd, wat eveneens kan leiden tot Remote Code Execution. Beide kwetsbaarheden kunnen zonder authenticatie via webverzoeken worden misbruikt en kunnen leiden tot het uitvoeren van willekeurige code op de getroffen server. Het PHP-team adviseert alle gebruikers dringend om onmiddellijk te updaten. Het NCSC adviseert daarom de beveiligingsupdates met spoed toe te passen.

PHP has released emergency updates that fix two critical flaws in the language itself, letting an attacker without an account run code on a web server. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP team says only updating fully protects a server. The flaws, together called PHP2Shell, sit in the PHP runtime, not in any application, so a site is exposed even when its own

Il PHP Security Team annuncia due vulnerabilità critiche, entrambe con punteggio CVSS di 9,2, e prepara un aggiornamento d'emergenza. Tra possibili attacchi RCE, mitigazioni non confermate e versioni fuori supporto, ecco come gestire il rischio sui server esposti L'articolo PHP2Shell, due vulnerabilità critiche in PHP: come proteggere i server proviene da Cyber Security 360 .

Rilasciati aggiornamenti di sicurezza che risolvono 10 vulnerabilità, di cui 4 con gravità “alta”, in Node.js, noto software open source per l’esecuzione di codice Javascript. Tali vulnerabilità, qualora sfruttate, potrebbero permettere ad un utente malintenzionato l'elusione dei meccanismi di sicurezza e/o la compromissione della disponibilità dei servizi interessati.

Oracle heeft 194 kwetsbaarheden verholpen in Oracle E-Business Suite en gerelateerde componenten, specifiek voor versies 12.2.3 tot en met 12.2.15. Afhankelijk van de specifieke kwetsbaarheid kunnen deze door een aanvaller met netwerktoegang worden misbruikt om ongeautoriseerde toegang tot gegevens te verkrijgen of om gegevens aan te maken, in te zien, te wijzigen of te verwijderen. In ernstige gevallen kan misbruik leiden tot Remote Code Execution (RCE), waardoor een aanvaller willekeurige code kan uitvoeren op het getroffen systeem. Een deel van de kwetsbaarheden kan op afstand worden misbruikt zonder authenticatie. Voor andere kwetsbaarheden zijn geldige inloggegevens, specifieke toegangsrechten of gebruikersinteractie vereist. De impact en de voorwaarden voor misbruik verschillen per kwetsbaarheid en getroffen component. De CVSS 3.1-scores lopen op tot de maximale score van 10,0.

Updated: The NCSC is encouraging UK organisations to take immediate action to mitigate a security issue affecting PHP (CVE-2026-109618 and CVE-2026-109619).

Two critical vulnerabilities in PHP were leaked one day before their scheduled disclosure and security patches

This story is developing and was written before PHP's scheduled 14:00 UTC release on October 21. Once the release is out, the affected and fixed versions below are confirmed by the official advisory. PHP will ship an out-of-cycle security release at 14:00 UTC today, October 21, for two critical vulnerabilities that its security team has rated 9.2 on the CVSS v4.0 scale but has not described. ⚡

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added four vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, including four vulnerabilities impacting Plex Media Server that's collectively called Plex2Shell. The vulnerabilities are listed below - CVE-2026-96652 (CVSS score: 5.3) - Plex Media Server Server-Side Request Forgery (SSRF) vulnerability CVE-2026-96654 (CVSS score: 6.9) - Plex Media Server improper neutralization of encoded URI schemes in a web page Vulnerability CVE-2026-96655 (CVSS score: 5.3) - Plex Media Server Server-Side Request Forgery (SSRF) vulnerability CVE-2026-96656 (CVSS score: 8.6) - Plex Media Server external control of file name or path Vulnerability According to security researcher Zach Main, who discovered and reported the vulnerabilities, a remote attacker could chain the four vulnerabilities to achieve unauthenticated remote code execution. The issues were addressed in Plex Media Server 1.43.3.10861 released on August 3, 2026. The addition of the four vulnerabilities to the KEV catalog follows a report from security researcher boredhackerblog, who found that threat actors are weaponizing the flaws to deploy cryptocurrency miners and proxy malware. CISA has also flagged two other vulnerabilities as actively exploited. One of them is a DLL sideloading vulnerability in Siemens Software Center (CVE-2026-110936, CVSS score: 8.4) that has been abused in ClickFix attacks using a platform called Romulus. The second security flaw is a command injection bug in EG Secure Solutions SiteGuard Server Edition (CVE-2026-106931, CVSS score: 8.5) that the Japanese company confirmed as being exploited. No additional details related to the exploitation activity are currently available. CISA is urging Federal Civilian Executive Branch (FCEB) agencies to apply fixes for CVE-2026-106931, CVE-2026-96656, and CVE-2026-96654 by October 23, 2026, and the rest by November 3, 2026.

Two critical memory-corruption remote code execution (RCE) vulnerabilities, collectively dubbed PHP2Shell, have been disclosed in core PHP, the underlying engine powering a vast portion of the web. The CrowdStrike Falcon® platform provides out-of-the-box visibility and detection coverage for post-exploitation activities of both vulnerabilities. Tracked as CVE-2026-109618 and CVE-2026-109619, both vulnerabilities carry a CVSS 4.0 score of 9.2 (Critical) and are classified as CWE-824: Access of Uninitialized Pointer. Both allow an unauthenticated remote attacker to execute arbitrary system commands on an affected web server over HTTP. The two issues share a single root cause. When PHP encounters a fatal condition (exhausting its configured memory_limit, exceeding the maximum execution time, or losing the client connection), it does not return an error up the call stack. It raises a fatal error and uses longjmp() to abandon the current execution context outright, aborting the request. Any C function caught midway through building a data structure is simply discarded: no destructors run, no bookkeeping is rolled back, and nothing records that the structure is incomplete. PHP then proceeds into an otherwise ordinary cleanup sequence that assumes every structure is in a consistent state. The two CVEs describe where that assumption breaks: CVE-2026-109618 (RCE via out-of-memory) covers contexts that leave request memory uninitialized. A data structure is marked as containing an entry before the memory backing that entry is allocated; when the allocation is the one that crosses the memory limit, the entry is left holding stale heap data. The failing request's own cleanup routine then reads and branches on those bytes. CVE-2026-109619 (RCE via fatal errors) covers contexts that leave global state invalid. A module-level global still points into the per-request heap that shutdown has already freed, and still reports its operation as active. A subsequent request handled by the same worker process reads or branches on that freed memory. In both cases, the attacker controls the trigger and, critically, the data that PHP ultimately misinterprets. CrowdStrike has verified end-to-end that a single anonymous POST request can cause an Apache mod_php worker to launch a shell process and execute an attacker-specified command, with no authentication, no session, and no vulnerable application code involved. What elevates these vulnerabilities is their placement in the execution stack. PHP parses incoming request data before extensions are initialized and before a single line of application code is compiled, so exploitation is independent of what the server hosts. A meticulously maintained application is exposed to precisely the same degree as a neglected one. The attack is also remarkably quiet: The worker process does not crash, the server returns a standard HTTP 200 response, and application logs record nothing unusual. In our testing, we developed an exploit code that operated consistently across x86-64 and ARM architectures, remained reliable across worker restarts, and on ARM-based hosts, which are increasingly common in cloud fleets, defeated Address Space Layout Randomization (ASLR) using only HTTP requests. Technical Details The Shared Root Cause: longjmp() Without Unwinding Both vulnerabilities live in Zend, the engine at the heart of PHP. Zend is the C implementation that compiles PHP source into bytecode, executes it in a virtual machine, and manages everything the language needs at runtime: variables, arrays, objects, reference counting, and memory allocation. Originally written by Zeev Suraski and Andi Gutmans (the name is a contraction of their first names) and introduced with PHP 4, it is not an optional component or a third-party add-on; it ships inside every PHP build, which is why its source lives in the Zend/ directory of php-src. In practice, this means a defect in Zend is a defect in the PHP engine itself, affecting every application, framework, and extension running on the interpreter, regardless of how that code is written. Two pieces of core Zend machinery are central to the issues described here: the HashTable, which backs every PHP array including the $_POST superglobal, and the Zend Memory Manager (Zend MM), PHP's own per-request allocator that sits between PHP and the operating system. PHP's fatal-error path terminates in zend_bailout(), which performs a LONGJMP out of the current C call stack: // Zend/zend.c ZEND_API ZEND_COLD ZEND_NORETURN void _zend_bailout(const char *filename, uint32_t lineno) { ... CG(unclean_shutdown) = 1; ... LONGJMP(*EG(bailout), FAILURE); } Nothing between the fatal error and the enclosing zend_catch block executes. Any caller that mutated the state and relied on reaching its own cleanup code leaves that state behind. This is safe only if every such caller is written with abrupt termination in mind, and several are not. CVE-2026-109618: Uninitialized Request Memory, Consumed During the Same Request The canonical instance is _zend_hash_str_add_or_update_i() in Zend/zend_hash.c, the helper behind every string-keyed insert into a PHP array. On the insert path, it increments both element counters, takes a pointer to the new bucket, and only then allocates a copy of the key: // Zend/zend_hash.c add_to_hash: idx = ht->nNumUsed++; ht->nNumOfElements++; p = ht->arData + idx; p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT); If zend_string_init() exceeds memory_limit, Zend MM raises a fatal error that ends in zend_bailout(). Execution never returns to complete the bucket. Now, the table reports one more entry than it actually contains, and that entry's value, hash, and key pointer are whatever bytes the allocator last left in that memory; the bucket array is allocated with an uninitialized emalloc(), with only the hash region explicitly reset. During teardown, php_request_shutdown() destroys the superglobals, and zend_array_destroy() iterates nNumUsed buckets. The stale entry is passed to i_zval_ptr_dtor(), which treats the leftover bytes as a reference-counted value: It dereferences the pointer they contain, decrements the reference count at that address, and (if it reaches zero) dispatches through a function-pointer table indexed by a type tag that also came from the leftover bytes. Triggering the condition requires nothing more than a URL-encoded POST body, because PHP populates $_POST inside php_hash_environment(), which php_request_startup() calls before zend_activate_modules() and before any script is compiled. A field with a nested name such as ZZZZ…[x]=1 causes php_register_variable_ex() to insert the outer name as a new array key, so the attacker directly controls the length of the key that must be allocated. Sizing that name to cross memory_limit places the bailout precisely on the key allocation. Control over the leftover bytes comes from the allocator's determinism. Zend MM serves small allocations from per-size free lists in strict last-in-first-out order and never zeroes reclaimed blocks. An earlier field in the same request, one whose value PHP copies, decodes, and immediately releases, can therefore be sized so that its freed contents occupy exactly the block the corrupted array subsequently claims. The stale entry becomes a fully attacker-defined value, which we used to synthesize a counterfeit array whose destructor pointer resolves to libc's system(), with the command string resident in the same block. The only server-side artifact of a successful attempt is a generic fatal error in the web server log: PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 3670048 bytes) in Unknown on line 0 The in Unknown on line 0 is the tell: It confirms that no PHP file was ever executing. CVE-2026-109619: Invalid Global State, Consumed by a Subsequent Request The second CVE follows the same mechanism but the damage lands in process-scoped state, which shifts the exploitation window to a later request. Here, the interrupted operation is one that caches state in a global variable and depends on reaching its own cleanup call to clear it. PHP caches the active serializer and unserializer contexts in module globals and reuses the cached pointer whenever the nesting level is non-zero. Only the matching destroy call decrements that level and clears the pointer, and only an extension's request-initialization routine resets it. Session handling behaves comparably, holding the session identifier, handler state, session variables, and upload-progress state in globals cleared by dedicated shutdown routines. When a fatal error interrupts one of these operations, the matching teardown is skipped. The global retains its pointer, and the nesting counter still asserts that the operation is active. Request shutdown then frees the entire per-request heap, but the global survives because it belongs to the process rather than the request. PHP is left holding a module-level pointer into memory it has already released. Two factors make this reachable and controllable: Worker reuse: In persistent-worker deployments such as Apache mod_php, the same process handles the next request. The stale global is found intact, the operation is believed to be in progress, and the freed pointer is read, written through, or branched on. Whatever occupies that memory by then is attacker-influenced, because the intervening request is also the attacker's: They choose its size and contents, and Zend MM's allocation behavior is deterministic enough to place them reliably. PHP-FPM terminates a worker whose request startup fails, which removes the reuse for interruptions in the startup phase; an interruption inside an already-running script leaves the FPM worker alive and equally exposed. Startup ordering: php_request_startup() parses request variables before running extension request-initialization callbacks. Multipart upload-progress handling therefore executes session and serialization code before the extensions that own those globals have had any opportunity to reset them, allowing a stale pointer to be consumed in the earliest phase of a request. Beyond memory exhaustion, this condition can be reached through execution timeouts and aborted client connections, each of which routes through the same zend_bailout() path. Exploitation is consequently a two-stage operation: One request poisons the worker, a second triggers the use of the freed memory. Vulnerability Impact The severity of both issues stems from their position early in request handling. Because the corruption occurs while PHP is still assembling internal request variables, before extension initialization and before any application code runs, every reachable PHP endpoint on an affected server constitutes an active attack surface, including static forms, login routes, and health checks. There is no authentication to bypass, no session to steal, and no vulnerable endpoint to discover. The exposure is independent of the CMS, framework, or plug-ins in use. The attack also leaves virtually no digital footprint. Worker processes remain stable, responses return HTTP 200, and application logs record no anomalies, because no application code ever ran. The only server-side trace is a single memory-limit fatal in the web server's error log, which is routinely dismissed as noise, leaving defenders without actionable web telemetry to identify compromised endpoints. In multi-process web servers such as Apache prefork, every worker is derived from a single parent process, so the memory layout an attacker depends on remains consistent across worker restarts. That stability allows an attacker to refine payloads at no cost; a failed attempt is absorbed by a worker respawn that monitoring treats as routine. The two CVEs differ in scope and timing in ways that matter operationally. CVE-2026-109618 is self-contained: A single request corrupts its own data, and the consequence executes during that same request's cleanup, which makes it fast, atomic, and difficult to reconstruct after the fact. CVE-2026-109619 spans requests, requiring a poison step and a trigger step against the same worker, but it reaches a broader set of internal state and can be triggered through timeouts and client disconnects as well as memory exhaustion. Persistent-worker deployments are the material exposure for this second class. Successful exploitation of either issue yields command execution in the web server user context, the standard foothold for deploying web shells, harvesting database and API credentials from configuration files, and pivoting into internal networks. Patching is the only complete remediation. Where immediate patching is not feasible, endpoint behavioral monitoring is the primary line of defense, because the exploitation is invisible at the HTTP layer while its outcome is not. Am I Impacted? Both vulnerabilities are present in every PHP release from the 7.x and 8.x series. The specific HashTable ordering behind CVE-2026-109618 was introduced by a performance optimization in October 2017 and first shipped in PHP 7.3.0 (December 2018). The serialization and session paths behind CVE-2026-109619 date back further, to PHP 7.1 and PHP 5.4, respectively. In other words, the exploitable window has existed in released PHP for more than seven years. No supported branch is unaffected. Version alone does not determine exposure. The out-of-memory trigger must be reachable while PHP is parsing request data, which requires that a request body be allowed to grow large enough to exhaust the memory limit before any script runs. In practice, this means the configuration satisfies roughly: memory_limit < 4 × post_max_size PHP's shipped defaults (post_max_size = 8M, memory_limit = 128M) do not meet this condition, so a stock installation is not reachable through the URL-encoded path we demonstrated. However, many production deployments are tuned to accept large uploads, and common pairings such as post_max_size = 64M with memory_limit = 128M, or post_max_size = 100M with memory_limit = 256M, satisfy it. Note that post_max_size can be set per directory in .htaccess or a virtual host, so on shared hosting, a single site can place itself into the vulnerable configuration without any server-wide change. CrowdStrike reproduced the issue with memory_limit lowered to 16M and post_max_size raised to 64M purely to keep the test payload small; the same bug is reached with larger payloads against the larger limits above. To see which version of PHP and configuration is running on your server, either run php --version. In order to see the values set on your server for options listed above, run the following command: php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|Loaded Configuration File)”. How CrowdStrike Falcon Protects Customers CrowdStrike employs a layered approach to detecting exploitation and post-exploitation activity, using machine learning and behavior-based detections, including indicators of attack (IOAs). The Falcon platform provides out-of-the-box visibility and detection coverage for post-exploitation activities of the PHP vulnerabilities. Existing IOAs detect and prevent common post-exploitation activity, including web shell deployment, suspicious child processes spawned by PHP or web server processes, and malicious command execution. CrowdStrike continues to research exploitation techniques associated with this vulnerability.

This post shows you how to configure an AI model to perform structured, evidence-based vulnerability triage with the consistency of a seasoned security analyst. You’ll learn the design decisions behind five configuration sections that enforce structural verification, evidence-based scoring, and infrastructure-aware prioritization across every analysis session. Our companion post— Building your AI vulnerability harness —covered the architecture; this post covers the configuration. The distinction matters because the same frontier model that produces a rigorous, evidence-grounded security assessment with one set of instructions will produce hallucinated attack chains and inflated severity ratings with another. The model’s capability is fixed. What you configure is its judgment. We learned this the hard way while building the harness. Our early iterations produced findings that sounded authoritative but crumbled under scrutiny. The model would report a SQL injection in a function that didn’t exist, claim HIGH confidence based on nothing structural, or ignore an AWS WAF in blocking mode directly in the request path. The output wouldn’t have earned engineering trust in that state. The fix wasn’t a better model. It was better steering. What a steering file is A steering file is a set of instructions that an AI coding assistant loads at the start of every session. Different tools use different conventions—Kiro reads markdown files from a .kiro/steering/ directory, Claude Code uses CLAUDE.md , Cursor uses .cursorrules , and GitHub Copilot uses .github/copilot-instructions.md —but the function is the same: persistent instructions that shape how the model approaches work in your repository. Applied to security analysis, a steering file encodes your team’s triage methodology as machine-executable instructions. Instead of relying on individual engineers to apply that methodology consistently, you encode it once and the model applies it uniformly across analyses. The steering file we’re releasing encodes the architectural principles from the harness post as operational instructions. Where the harness post says apply infrastructure-aware assessment , the steering file specifies exactly how: which controls map to which multipliers, how multipliers stack, and what floor prevents over-confidence in any single control. Why configuration outperforms prompting A single-turn prompt ( find vulnerabilities in this code ) produces whatever the model’s default behavior generates. That default is optimized for helpfulness, not rigor. The model will find things to report because you asked it to find things. A steering file changes the default. It establishes: What counts as evidence: Without explicit instructions, a model treats its own reasoning as sufficient evidence. The steering file requires structural verification—confirmed dataflow, confirmed function existence, and confirmed call path—before a finding is reported. What confidence means: On its own, a model assigns confidence based on how plausible its narrative sounds to itself. The steering file replaces self-reported confidence with a formula computed from binary structural signals. Either taint analysis confirms the flow or it doesn’t. Either a call graph connects entry point to sink or it doesn’t. How infrastructure affects priority: Left to its defaults, a model assesses vulnerabilities in isolation from their deployment context. The steering file requires parsing infrastructure as code (IaC) and applying control-specific multipliers before assigning priority. The goal is reproducibility: the same codebase should produce the same assessed findings regardless of who runs the analysis or when. Consistency is the point. The five sections that matter The full steering file is available in the companion repository. In this section, we explain the design decisions behind its five critical sections. Structural verification over LLM trust Never trust an LLM's self-reported confidence about a vulnerability. Verify claims against the code structure: 1. Do referenced files exist? 2. Do referenced functions exist? 3. Does dataflow confirm the claim? 4. Is there a call path? If a finding fails all structural checks, reject it regardless of how convincing the narrative sounds. This is the single most important instruction in the file. Without it, the model generates plausible-sounding attack chains that reference functions that were renamed three commits ago, files that exist in a different package, or dataflows that pass through sanitization that the model failed to notice. We found that approximately 30% of unsteered model findings referenced code structures that didn’t exist in the target repository. Not wrong interpretations—entirely fabricated paths. The instruction to verify before reporting produced zero fabricated paths in our testing. The key insight: hallucination in security analysis isn’t a minor annoyance. One hallucinated finding that reaches a developer destroys the can quickly erode the credibility of your entire pipeline. Engineers who encounter a fabricated vulnerability are less likely to keep reading the reports. Evidence-based confidence scoring The following formula replaces the model’s intuitive confidence with a score computed from observable signals. Each factor is binary: confirmed or not confirmed. confidence = 0.30 * taint_confirms_flow + 0.25 * no_sanitization_found + 0.20 * entry_point_is_public + 0.15 * call_graph_confirms_path + 0.10 * sink_type_matches_category We weighted taint confirmation highest (0.30) because a confirmed dataflow path—evidence that user-controlled data reaches a security-sensitive operation—is the single strongest predictor that a finding is real. In our validation against known-vulnerable applications, findings with confirmed taint and no sanitization were exploitable 89% of the time. Findings where the model reported HIGH confidence without structural confirmation were exploitable 34% of the time. The formula is a starting point, not a fixed standard. Your weights should reflect your own validation data. Run the formula against a labeled dataset of known true and false positives, then adjust until precision matches your team’s tolerance for noise. Infrastructure-aware assessment This section addresses a common category of over-prioritization: reporting a vulnerability at full severity when compensating controls are already in place. score_after_controls = max(0.15, score * block_1 * block_2 * ... * block_n) Controls are mapped to specific vulnerability classes. An AWS WAF with SQL injection rules in blocking mode is a STRONG control (0.25x multiplier) against SQL injection. It is irrelevant to deserialization attacks. The steering file specifies this mapping explicitly rather than leaving the model to guess. The multiplicative stacking of attack-blocking controls with a floor of 0.15 encodes defense-in-depth thinking. Multiple controls reduce risk more than any single control, but no combination of controls reduces risk to zero. The floor prevents the model from concluding that a vulnerability is completely mitigated and can be ignored. A subtlety we learned through validation: access controls (authentication and authorization) and attack-blocking controls (AWS WAF rules and input validation) serve different functions. Authentication limits who can attempt an exploit. It doesn’t limit what happens when an authenticated user attempts one. A command injection behind AWS Identity and Access Management (IAM) authentication is still a command injection; the attacker pool is smaller, but the impact when exploited is unchanged. The steering file accounts for this by mapping control types to specific score components rather than applying a blanket multiplier. Threat intelligence integration The steering file incorporates signals from the CISA Known Exploited Vulnerabilities (KEV) catalog and the Exploit Prediction Scoring System (EPSS) to boost priority when threat intelligence indicates active risk. The following table lists the primary signals the steering file recognizes and the boost that each signal adds to a finding’s score. Each signal answers a different question about real-world exploitation risk: CISA KEV – Indicates that attackers have exploited the vulnerability in the wild and notes whether it is tied to ransomware campaigns. EPSS – Estimates the probability that attackers will exploit a vulnerability in the next 30 days. Public proof of concept (PoC) – Indicates that working exploit code is already published, so an attacker has little work left to do. Signal Boost Actively exploited (CISA KEV) +0.30 Ransomware-associated (CISA KEV) +0.15 EPSS &gt;= 0.5 +0.20 Public PoC exists +0.10 There’s a cap at +0.50 total boost to prevent threat intelligence from dominating the score. A vulnerability isn’t more technically exploitable because attackers are targeting it, but it is more urgent because the window between theoretically exploitable and actively exploited can be very short. We separate urgency from severity deliberately. A medium-severity dependency vulnerability under active exploitation by ransomware groups demands a faster response than a critical-severity code-level finding that requires complex preconditions and has no known tooling. Priority classification Scoring produces a number and priority classification turns that number into a decision, which is what a developer on the receiving end of a finding needs. The following table shows the four action tiers that the steering file defines. The score and evidence thresholds determine which tier a finding falls into, and each tier prescribes a specific response. The steering file compares these thresholds against the final score: the base score after it applies attack-blocking multipliers and any threat-intelligence boost. That final score is not the confidence value from the formula earlier in this post, and it is not the severity that the scanner reported. Priority Criteria Action P0 Score &gt;= 0.8, no effective attack-blocking mitigation Fix immediately P1 Score &gt;= 0.6 OR active threat intel Fix this sprint P2 Score &gt;= 0.4, partial evidence Investigate when capacity P3 Score &lt; 0.4 or effectively mitigated Accept risk or backlog The most controversial instruction in the file: Do not file P3 findings as security issues. We include it because filing low-confidence or fully mitigated findings as tickets trains teams to ignore security tooling. Each false positive or irrelevant finding filed as a bug reduces engagement with the system’s output. A pipeline that produces ten confirmed findings gets more engineering attention than one that produces two hundred maybes. Validation results We tested the steering file against a purpose-built vulnerable application containing ten known vulnerabilities: eight exploitable and two mitigated by infrastructure controls. The application includes an AWS WAF with SQL injection rules in blocking mode, Amazon Virtual Private Cloud (Amazon VPC) -isolated AWS Lambda functions, and IAM authentication on each endpoint. Without the steering file , the model found all ten vulnerabilities and correctly identified both mitigated findings as lower priority. However, it assigned severity based on intuition ( this is a command injection, so it’s CRITICAL ) rather than evidence, and it produced no structural verification of its claims. With the steering file , the model found nine of ten vulnerabilities (not flagging a hardcoded credential that had been intentionally embedded in unit-testing code and was defined but never called), correctly downgraded the two mitigated findings to P3 with documented rationale, showed its confidence calculation for each finding, and verified each claimed dataflow against the actual code. The scoring calibration required one iteration. Our initial version applied authentication as a blanket multiplier that suppressed all findings behind IAM to P2 regardless of impact. We corrected this by separating access-limiting controls (which reduce the reachability score component) from attack-blocking controls (which reduce the full confidence score). The current version correctly classifies a command injection behind IAM authentication as P0: the auth limits who can reach it, but the impact when exploited is remote code execution regardless. How to use the steering file The three options that follow cover an always-on Kiro steering file, the same content as an on-demand Kiro skill, and how to carry the same content to Claude Code or another assistant. Option 1: As a Kiro steering file Drop the steering file into your repository at .kiro/steering/vuln-triage.md . Any session using Kiro’s built-in default agent loads the instructions automatically. When you or your engineers ask the model to analyze code for security issues, it applies the methodology without additional prompting. If your team uses a custom agent rather than the default, steering files aren’t loaded automatically; you have to add the file to the agent’s resources explicitly: { "resources": ["file://.kiro/steering/**/*.md"] } your-repo/ ├── .kiro/ │ └── steering/ │ └── vuln-triage.md ← steering file ├── src/ ├── cdk/ └── ... You can also place it in ~/.kiro/steering/ to apply the methodology across every workspace on your machine, rather than scoping it to a single repository. Option 2: As a Kiro skill If you want the methodology available on demand rather than consuming context window space in every turn, place it as a skill. Kiro loads only the skill’s name and description at startup and pulls in the full instructions when the skill activates. This keeps the instructions out of unrelated conversations. A skill is a folder containing a SKILL.md file. The folder name must match the name in the YAML front matter: name: vuln-triage description: Structured vulnerability triage methodology with evidence-based scoring and infrastructure-aware prioritization. Use when analyzing code for security vulnerabilities. your-repo/ ├── .kiro/ │ └── skills/ │ └── vuln-triage/ │ └── SKILL.md ← skill file ├── src/ └── ... Kiro’s default agent discovers skills in .kiro/skills/ automatically; no configuration required. The skill then activates either automatically, when Kiro matches a request against the description, or explicitly as a slash command. A skill named vuln-triage becomes /vuln-triage , so an engineer can run an assessment on demand: &gt; /vuln-triage focus on the authentication changes Place skills in ~/.kiro/skills/ to make them available across every project on your machine. If your team uses a custom agent rather than the default, skills aren’t loaded automatically, you must add them to the agent’s resources: { "resources": ["skill://.kiro/skills/*/SKILL.md"] } Option 3: Adapted for other tools The methodology isn’t specific to Kiro. The repository also ships the same content as a CLAUDE.md file for Claude Code, and the principles apply to any assistant that loads persistent instructions from your repository—consult your tool’s documentation for the filename and location it expects. What this doesn’t replace A steering file is methodology, not machinery. It tells the model how to think about findings but doesn’t provide: Programmatic taint tracking: The model approximates dataflow by reading code. A purpose-built taint tracker confirms dataflow against the abstract syntax tree (AST) deterministically. For Python codebases, static analysis tools built on parsers like Tree-Sitter provide this. For other languages, the model’s approximation is reasonable but not authoritative. Live infrastructure verification: The steering file instructs the model to parse IaC files. It can’t make API calls to verify that an AWS WAF rule is attached to the Amazon API Gateway in your deployed environment, or that a security group hasn’t been modified since deployment. Threat intelligence feeds: The file instructs the model to consider CISA Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS) data. The model’s training data includes historical KEV entries, but it can’t query live feeds. For current exploitation status, you need an API integration. Execution-based verification: The steering file produces assessed findings. Confirming exploitability by executing a proof of concept against a live environment requires additional tooling: a sandbox, request signing, and differential testing infrastructure. Each of these capabilities adds confidence to the pipeline. The steering file without them still produces measurably better results than an unsteered model: structured findings, cited evidence, and infrastructure-aware prioritization. But it represents the first layer of a mature harness, not the complete system. What comes next The steering file gives your team a structured methodology for AI-powered vulnerability triage today. It works with the tools you already have. It works without infrastructure changes, new services, or a procurement process. The steering file is available in our GitHub repository . We encourage you to use it, adapt it to your environment, and let us know what you find. The authors work on security automation at AWS. The patterns described here emerged from building and validating AI-powered vulnerability detection systems across multiple teams and deployment environments. If you have feedback about this post, leave a comment in the Comments section below. Justin Kontny Justin is a Senior Software Engineer, Security, at AWS who blends a passion for software development with deep expertise in cloud security. He focuses on building agentic security solutions using AI-Driven Development Lifecycle (AIDLC) practices, transforming security from a barrier into a business enabler. Outside of work, Justin enjoys spending time with his children and staying active outdoors. Ievgeniia Ieromenko Ievgeniia is a Software Development Engineer at AWS, where she builds tooling and agentic AI systems designed to strengthen security posture without slowing delivery. Outside of work, she enjoys traveling, volunteering, and outdoor adventures with her very good dog, Pickle. Nidhi Ramakant Nidhi is a Software Development Manager at AWS with two decades of experience in security and enterprise architecture. She’s obsessed with helping customers secure their environments and building creative solutions that make security decisions easier. She’s equally invested in developing the talent around her. Outside work, she’s either binging shows or vibe coding apps for secure local LLMs so her kids can explore and learn safely.

Cisco ha rilasciato aggiornamenti di sicurezza per risolvere 35 vulnerabilità nei propri prodotti, di cui 15 con gravità “critica” e 13 con gravità “alta”.

Google has released updates for the Chrome browser and the ChromeOS operating system. On October 6, Google released a&nbsp; Stable Channel Update for Desktop . This is the most important one for desktop users. It brings Chrome to version&nbsp; 155.0.8059.39 for Linux&nbsp; and versions&nbsp; 154.0.8037.39/.40 for Windows and Mac . The update includes 247 security fixes including four rated Critical. On the same day, Google released&nbsp;version&nbsp; 155.0.8059.39 for Android , to a small percentage of users. It may not be available on Google Play for everyone yet but keep an eye out for it. Google says it includes stability and performance improvements. How to update Chrome The easiest option is to allow Chrome to update automatically. But you can end up lagging behind on updates if you never close your browser or if something goes wrong, such as an extension preventing the update. If you don’t want to wait for the rollout to reach you, manually updating is easy. Open&nbsp; About Google Chrome &nbsp;from Chrome’s settings or Help menu. Chrome will check for updates. If one is available, click&nbsp; Relaunch &nbsp;to apply it. Version 155.0.8059.40 is up to date You can find an explanation of the version numbering system and step-by-step instructions in our guide:&nbsp; How to update Chrome on every operating system . How to update ChromeOS You can update your Chromebook’s operating system by following these steps: Connect to the internet. Your Chromebook automatically checks for updates and downloads when it connects. At the bottom right, next to the date, find the “Update device” notification. To complete the update, restart your Chromebook. Technical details In the fixed vulnerabilities, we found three that are likely high-impact flaws. CVE-2026-106197 : This is a use-after-free vulnerability in the Browser module, rated critical. This is a strong priority candidate because of its location in browser functionality rather than a specialist feature. Exploitation would allow a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. A use-after-free vulnerability occurs when a program attempts to access a memory location after it has been freed. That can cause crashes or, in some cases, allow an attacker to run their own code. Chrome vulnerabilities that enable remote code execution outside the browser sandbox are particularly valuable to attackers because they can turn a visit to a malicious or compromised website into direct code running on the underlying operating system, often without requiring additional exploitation steps. CVE-2026-106358 : Another use-after-free vulnerability, this time in Navigation, also rated critical. Navigation is central to ordinary browsing, making this a potentially broadly exposed flaw if attacker-controlled pages or redirects can reach the vulnerable path. It also provides a remote attacker with the option to execute arbitrary code outside the sandbox via a crafted HTML page.&nbsp; CVE-2026-106240 : A type confusion vulnerability in V8, Chrome’s JavaScript engine. This one is rated High but does offer a remote attacker after successful exploitation to execute arbitrary code inside the sandbox via a crafted HTML page. And a flaw in the JavaScript engine is always a plausible candidate for attacks delivered through malicious web content. Stop threats before they can do any harm. Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

SonicWall heeft meerdere kwetsbaarheden verholpen in de SonicWall SMA1000 Appliance. De kwetsbaarheden omvatten een pre-authenticatie Server-Side Request Forgery (SSRF) die ongeauthenticeerde aanvallers in staat stelt om onbevoegde interne verzoeken uit te voeren. Daarnaast is er een post-authenticatie remote code execution kwetsbaarheid via OS command injection. Verder is er een Zip Slip kwetsbaarheid in de management console die het mogelijk maakt om bestanden buiten de bedoelde directories te extraheren. Tot slot is er een stored Cross-Site Scripting (XSS) kwetsbaarheid aanwezig in de management console. Deze kwetsbaarheden beïnvloeden de kernbeveiligingsmechanismen van het apparaat en kunnen worden misbruikt om de integriteit en vertrouwelijkheid van het systeem aan te tasten. De kwetsbaarheden bevinden zich zowel in pre- als post-authenticatie contexten.

Hackers are actively scanning for a Rejetto HFS weak signing key vulnerability, tracked as CVE-2026-61500, that allows session forgery, account takeover, and remote code execution (RCE). [...]

Citrix has released emergency updates for a new NetScaler denial-of-service vulnerability tracked as CVE-2026-88779 that has been exploited in zero-day attacks, with researchers investigating whether it can also be exploited for remote code execution. [...]

The second Anthropic-linked vulnerability known to have been exploited in the wild saw initial activity from an IP address in China targeting vulnerable hosts in the US and Japan. The vuln is a critical authentication-bypass bug in Rejetto HTTP File Server (HFS) that can lead to full admin access and remote code execution. HFS is an open source web file server that previously appeared on the US Cybersecurity and Infrastructure Security Agency’s catalog of Known Exploited Vulnerabilities in 2024. On Wednesday, researcher Zach Hanley at AI pen-testing company Horizon3 said he used Mythos to uncover a new flaw in the file server, now tracked as CVE-2026-61500. If you use Rejetto HFS, be sure to update to v3.2.1 or later, which fixes this and other security flaws. Hanley also published a video showing the steps to exploit HFS and remotely execute code on the server. By the next day, the CVE was under exploitation. “We started detecting exploitation of CVE-2026-61500 in Rejetto HFS this evening,” VulnCheck security researcher Patrick Garrity posted on LinkedIn on Thursday, adding that Hanley and team reported the bug to VulnCheck for CVE assignment. “Our canaries detected an actor in China targeting real vulnerable hosts in the US,” Garrity added. Garrity has been tracking CVEs attributed to Mythos and Project Glasswing, Anthropic’s initiative to give select partners access to the bug-hunting model, since shortly after the program was announced in April. Anthropic claims that Mythos is too powerful to release to the general public (insert evil laugh). As of Friday, Mythos and Project Glasswing have uncovered 286 CVEs, according to Garrity’s tracker, and up until Thursday only one of these bugs had been exploited in real-world attacks. The Thursday night activity originated from one IP address in China and targeted vulnerable servers in the US and Japan, Garrity told The Register. “Today we have seen four hits,” he told us on Friday. These originated from two different IP addresses in the US: 173.239.211[.]248 and 173.239.211[.]249. Both are in the same subnet, and “appear to be coming from a proxy,” Garrity added. China-linked digital intruders routinely use compromised devices as proxies to route malicious traffic and disguise the attackers’ true location, and in April a 10-country security advisory warned of China-nexus cyber operatives using proxy networks “strategically, and at scale.” In his write-up, Hanley said Horizon3 has used Mythos in its vulnerability research – and discovered “many critical vulnerabilities” – ever since the security company joined Project Glasswing in July. Mythos' mad math skillz CVE-2026-61500 highlights a couple of Mythos capabilities that make it really good at uncovering vulnerabilities, according to Hanley. Namely, Mythos excels at mathematical distillations and scientific tasks, especially those relating to computer science and operating systems. Finding this CVE “speaks to Mythos’s capabilities in understanding of mathematics, how it identified an exploitable set of cryptographic missteps, and approached solving the constraints to achieve remote code execution,” Hanley wrote. The security issue stems from how HFS authenticates users. It generates a random value with Math.random() and then passes this value to Koa, the Node.js web framework foundation for HFS. Koa uses keygrip to sign all session cookies with that random value. This means that if an “attacker can derive what the session signing key is, they can forge valid session cookies,” Hanley said. This should not be possible, assuming Math.random() uses a secure pseudo random number generator (PRNG). But V8’s Math.random() did not use a secure PRNG. Mythos discovered that the output of the xorshift128+ algorithm it used was fully reversible – and the application was leaking Math.random() outputs. The model’s analysis claimed that Z3, a Microsoft-developed, publicly available Satisfiability Modulo Theories (SMT) solver, could be used to recover the PRNG seed. Hanley notes that Horizon3’s researchers could not recall seeing an SMT solver used this way to attack a cryptographic flaw in a real application and bypass authentication. “What makes this impressive is that Mythos didn’t just flag the insecure PRNG in isolation – it simultaneously identified that the application leaked raw Math.random() outputs through a separate code path, recognized those two facts as a chain, and determined the leak produced exactly the observations needed to make state recovery feasible,” he wrote.®

On September 15 this year, Google published details of patches for 110 vulnerabilities in its own Google Pixel smartphones. Among all the disclosed flaws, CVE-2026-58704 stands out the most, for it appears that this zero-day is being exploited in targeted attacks. In today’s post, we talk about what’s so special about the Google Pixel, and why these devices get security updates all of their own – separate from regular Android updates. We also cover the vulnerabilities addressed in this latest update, with a special focus on the mentioned, most dangerous one – CVE-2026-58704 – and wrap up with tips on how to both protect your device and avoid becoming a victim of cyberattack on it. Why do Google Pixel phones get security updates separate from Android? The reader might reasonably wonder: I’ve already installed this month’s Android security updates on my Google Pixel. Isn’t that the same thing? Google Pixel does run on Android and receives those security updates, which are detailed in the monthly Android Security Bulletin . However, manufacturers of Android-based devices use different sets of hardware and software components. That’s why, alongside vulnerabilities common to all Android devices, there are security issues specific to individual manufacturers’ devices. For its own smartphones, Google publishes separate security updates, covered by a dedicated Pixel Update Bulletin . Rather than replacing the Android Security Bulletin, this document complements it by detailing vulnerabilities specific to devices manufactured by Google. Other Android smartphones also receive similar updates from their manufacturers. The Pixel Update Bulletin for September 2026 clearly shows why Google needs separate updates for its smartphones in the first place. Many of the vulnerabilities it fixes affect specific Pixel hardware (or hardware-related) components: the modem, bootloader, GPU, fingerprint scanner components, and other parts of the device. On smartphones from other manufacturers, these features might rely on entirely different hardware and software components, so the fixes listed in the Pixel Update Bulletin don’t apply to those phones. That said, these vulnerabilities could still be relevant for Pixel owners who’ve flashed their devices with custom ROMs. Switching to a different OS doesn’t alter the device’s hardware components, and may not replace the firmware. Therefore, the vulnerabilities themselves may persist, but whether patches are available, and how they’re installed, depends on the specific OS. CVE-2026-58704: a zero-day vulnerability being actively exploited in the wild Now let’s look closer at the specific vulnerabilities Google fixed in September. The most significant one is the above-mentioned CVE-2026-58704 . This vulnerability affects the Cellular Modem component, which handles the smartphone’s communication with cellular networks. It stems from a logic error in the code, which, under certain conditions, allows bypassing the intended permission check. Successful exploitation of CVE-2026-58704 lets attackers escalate privileges on the smartphone to gain broader access to its functions and data. Note that the attack takes place over a cellular network and the threat actors need low-level privileges on the targeted device to start with. In practice, this means attackers can’t exploit CVE-2026-58704 to attack a Pixel from just anywhere over the internet, as they’d apparently need to either compromise the cellular network the target smartphone is already connected to or, more likely, force it to connect to a malicious base station under their control. Google hasn’t disclosed all the details of this vulnerability yet, and the related report is not publicly accessible. As a result, the technical details that would show how easy it is for attackers to exploit CVE-2026-58704 remain unknown pending installation of the patches on all devices. Nevertheless, Google claims that there are signs of limited exploitation of CVE-2026-58704. What we know about the other 109 vulnerabilities Of the remaining 109 vulnerabilities found in Google Pixel devices, only one is rated moderate; the others are either high (62) or outright critical (46). Nine of these flaws fall into the RCE (remote code execution) category. This means that if an attacker successfully exploits one of these vulnerabilities, they can remotely force the device to run malicious code. The exact conditions for the attack depend on the specific vulnerability. Another 88 vulnerabilities fall into the elevation of privilege (EoP) category. These let an attacker who’s already gained a certain level of access to the device expand their privileges. The CVE-2026-58704 vulnerability discussed above falls into this same category, which is why the September bulletin lists 89 EoP vulnerabilities in total. Finally, 10 vulnerabilities can lead to information disclosure (ID), and two more to denial of service (DoS). In short, that’s a hefty list of flaws, so Google Pixel owners shouldn’t wait around to install the patches. How to avoid becoming a victim Google Pixel owners can install the update that fixes the vulnerabilities covered in this post by following this path: Settings → Security &amp; privacy → System &amp; updates → Security update → Install . Keep in mind that the phone will automatically restart to finish installing the update. To keep your phone secure we recommend the following general measures: Install security updates on your phone regularly and promptly – whether it’s a Google Pixel, an Android smartphone from a different manufacturer, or even an iPhone. Avoid installing apps from questionable sources. Read reviews before installing apps from official stores, since malware isn’t uncommon there too . Users who have already been burned will often sound the alarm in the reviews long before store moderators get around to removing the dangerous app. Install&nbsp; a reliable security solution &nbsp;to keep you from downloading malware, and warn you about suspicious activity on your device.

AI agents hacked the hackers - the Dutch Institute for Vulnerability Disclosure (DIVD) - via two zero-day bugs in its Zammad support platform, abusing the flaws to hijack sessions, run code remotely as the local zammad user, and escalate privileges to root. The chained exploits took just seconds to move from session hijacking to root access, and on Thursday, the nonprofit bug hunting organization said the miscreants stole data belonging to its volunteer security researchers, including DIVD email addresses and potentially other contact details. “We’re still investigating exactly which data of which volunteers is affected,” DIVD said in its incident report. “For DIVD volunteers (and others) this means a higher risk of social engineering, because this makes it easier for someone to pose as a DIVD’er.” A subsequent LinkedIn post advised anyone receiving an email or contact request from someone at DIVD “that feels slightly off” to verify that it’s legit by emailing [email protected]. DIVD is also a CVE Numbering Authority (CNA), and it assigned CVE IDs to the now-public security holes in Zammad, an open-source helpdesk and customer support ticketing system. They are CVE-2026-102489 and CVE-2026-102490, and both bugs received CVSS 4.0 scores of 9.4, when assessed in the chained attack scenario. CVE-2026-102489 enables unauthenticated attackers to achieve remote code execution and leak user sessions, while CVE-2026-102490 allows a local user to elevate their privileges to root. Zammad versions 6.3.0 to 6.5.4 are vulnerable to CVE-2026-102489, and it also exists in versions 7.0.0 through 7.1.3 - but it’s not exploitable “due to environment conditions,” according to DIVD’s advisory. All Zammad versions are vulnerable to CVE-2026-102490. DIVD advises “all users of Zammad to upgrade to version 7 of Zammad or to take it offline.” What happened According to the nonprofit’s timeline, the attack happened on September 21, when "malicious actors” broke into its IT system via the two zero-days in its ticketing support software. The bug hunters discovered the attackers the following day, blocked access to all of its data center systems, and formed an incident response team with Merlon Security. On September 24, DIVD reported the Zammad vulnerability to the vendor, notified the Dutch Data Protection Authority and the National Cyber Security Centre about the incident, and discussed its options with police. It also posted its first disclosure on LinkedIn. “It took us (almost) seven years but we can now say that we're the hackers that got hacked,” the post said, adding that DIVD remained committed to handling the incident in “the way we think it should be handled. That is open, transparent and honest, even if it sucks.” 'Modus operandi' indicates agentic AI DIVD also noted that its team had never seen an attack like this before. “This is an attack we have not seen before,” according to the post. “Not because it’s our first, but because the modus operandi indicates that this is an agentic AI powered attack.” The attack was "loud and very very messy," DIVD said. "We could see the agent working automated, because after every action it decided the next step itself, at the speed of light and sloppy logic or pattern." Subsequent posts with screenshots of logs found during the investigation reveal embedded notes found in the attack script - another indication that this was an agentic operation or at least AI-enabled. “What human attacker leaves notes to themself in their scripts, explaining why what they're doing is okay and really not phishing? The AI just got a task and keeps justifying its own actions in the code as comments, a human wouldn’t care less," the post said. "Who has time for that anyway?” If only all orgs responded to hacks like this While the investigation remains ongoing, security researchers applauded DIVD for its transparency in disclosing and responding to the hack. “Kudos to DIVD for their level of honesty and transparency working through their active incident and investigation,” VulnCheck security researcher Patrick Garrity posted on LinkedIn. “It would be nice if all organizations were this transparent about their security incidents!” In a subsequent interview with The Register, Garrity said he applauded DIVD’s “brutal honesty” about the breach. “They're eating their own dog food, which is great, and getting information out quickly to other organizations that potentially use this product so they can take action before they get hit.”®

Welcome back to PWNED, the weekly column where we warn you about weak security practices. This week’s terrifying tale involves a lack of important patching and a humorously bad password belonging to the person in charge of tech security at a law firm. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Our story comes courtesy of Joe Brinkley, who is director of offensive security research and community at Cobalt, is known as “The Blind Hacker,” and has more than two decades of experience in information security. Joe was called in several years ago by a large, national law firm that wanted him to penetration test a smaller business they were about to acquire. What he discovered was a huge security hole and an even bigger embarrassment. Brinkley had audited the same law firm the previous year. At that time, he noted a number of holes and the attorneys had dutifully spent time and money on security software from the likes of Reliaquest and Dell to remediate what he found. “I shredded them. They were not in a very good security posture,” Brinkley told us. “They spent probably a half a million dollars to get patching and get through these things because they were trying to go through a merger and acquisition.” Unfortunately, even with their investment, the company failed to patch its Windows machines against BlueKeep, a major remote code execution vuln that was discovered, patched, and exploited in 2019. BlueKeep affects many versions of Windows, including Windows 2000, Windows Server 2008 R2, and Windows 7. Related vulns called DejaBlue also affected Windows 10. BlueKeep and its related security risks involve a flaw in Windows’ Remote Desktop Protocol that allows attackers to gain entry and execute remote code via port 3389. The vuln is wormable so an attacker could make it spread from one system to another. However, none of this filtered through to become a priority for the law firm. During his pentest, Brinkley used the BlueKeep vuln to get access to the org’s systems, where he found that the passwords were stored in plain text and easy to dump into a file, no decryption necessary. The usernames on the system were cleverly designed for security by obscurity. Instead of using the user’s real name or something like “admin,” they had names like “Yellow Banana” and “Red Apple” so attackers could not guess which one had the most privileges. Brinkley had no idea who Yellow Banana was, but he found that person’s password and it was perhaps the tackiest idea of a login we’ve ever heard. The password was “r3@lg00dp@$$w0rd,” which is “realgoodpassword” with some symbols and numbers substituted for letters. Not knowing who made the security faux pas, he took the password and included a screen shot of it in a presentation he delivered on system vulnerabilities that he gave to the law firm’s execs. While he was explaining that he had managed to penetrate 2,500 of the org’s computers, the CISO suddenly dropped an f-bomb. “Why the f*** is my password on the screen?” he complained, giving away the fact that he was Yellow Banana and thought that r3@lg00dp@$$w0rd was a good idea. So what can we learn from this tale of legal embarrassment? Always patch your Windows systems as soon as new patches become available and never use a cutesy password. Enabling 2FA and encrypting the passwords would probably have helped too. ®

The flaws were chained to hijack sessions, achieve remote code execution, and elevate privileges to root. The post Zammad Zero-Days Exploited in AI-Powered DIVD Hack appeared first on SecurityWeek .