PHP maintainers released emergency fixes for two critical remote code execution vulnerabilities after reports of exploitation attempts emerged before the planned disclosure window, placing web services running common PHP configurations under immediate pressure to patch or isolate exposed applications.
The flaws, CVE-2026-109618 and CVE-2026-109619, each carry a 9.2 CVSS v4 severity score. Both can allow unauthenticated attackers to execute code on a vulnerable server, potentially giving them access to application data, server files and the ability to alter websites. PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 around 14:00 UTC on October 21, minutes ahead of schedule.
The accelerated release followed a leak of vulnerability discussion on Hacker News before the embargo expired. Security firm watchTowr subsequently confirmed the flaws were genuine while technical details were still intended to be restricted. Cloudflare Chief Technology Officer John Graham-Cumming, who posts under the name Knecht, said the company had observed attack activity roughly six hours before the public patch release and deployed emergency web application firewall rules to customers.
Those firewall rules can filter known malicious request patterns, but they do not remove the underlying weakness. PHP’s security team urged administrators to upgrade immediately.
Multiple PHP server modes are affected
The vulnerabilities affect several widely used ways of running PHP, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed deployments. Mod_php was described as the highest-risk setup because demonstrated attacks can be triggered before the affected site’s own application code begins processing a request.
CVE-2026-109618 relates to PHP’s handling of request data after a memory exhaustion condition. In certain circumstances, incomplete data may be treated as though it were complete, opening a path for malicious input to reach unsafe processing stages.
CVE-2026-109619 concerns request data that remains in memory after PHP should have cleared it. A later request could be influenced by that residual content, creating another route to code execution under the right conditions.
Researchers identified PHP’s upload-progress tracking feature as a confirmed attack surface. The feature has been enabled by default for more than a decade, despite relatively limited use in many modern applications. Upload-progress tracking is designed to report the status of a file upload, but its interaction with request handling gives attackers a possible entry point in affected installations.
The technical details matter for administrators because these are server-level bugs rather than flaws limited to a particular PHP framework, plugin or website. A single vulnerable shared-hosting server can support many separate websites, so the number of potentially exposed sites may be larger than the number of internet-facing hosts identified by scans.
Governments restricted public services
Several European public-sector organizations took precautionary action before patches became widely available. Finland’s state IT centre, Valtori, began disabling public network services as a preventive measure. Government entities in the Netherlands and France also took sites offline or restricted access while awaiting updates.
France’s Interior Ministry said departmental government websites were temporarily removed from public access until relevant framework publishers made security patches available. CERT-EU advised organizations unable to patch immediately to isolate internet-facing applications from public networks. Cybersecurity authorities and relevant bodies in Australia, Japan and the United Kingdom issued similar mitigation guidance.
That response reflects the difficulty of defending against unauthenticated code execution flaws in web-facing software. A successful attack can occur without an attacker having an account on the target service, and a compromised web server can be used to steal data, install persistence tools, distribute malware or modify pages served to visitors.
Cloudflare’s emergency filtering gave some operators time to act, but PHP administrators need to treat firewall rules as temporary mitigation. Attackers commonly compare patched and unpatched source code soon after fixes are published to identify the precise vulnerable logic. Sansec said its forensic team expected large-scale exploitation attempts within 15 minutes of the release, based on that established pattern.
Akamai documented a similar race after disclosure of another PHP vulnerability in June 2024, when its honeypots detected exploit attempts within 24 hours.
Older PHP branches create a larger cleanup task
The full supported-release updates cover PHP 8.2 and newer branches. PHP’s security team also published minimal source patches for PHP 7.4, 8.0 and 8.1, allowing organizations using older environments to apply targeted fixes while they plan broader upgrades. Linux distributions began backporting the changes into their vendor-maintained PHP packages.
Sansec assessed the affected range as beginning with PHP 5.4, released in 2012. Claims that every PHP version since 2004 was affected circulated online, though CERT-EU said that broader estimate originated from social-media discussion rather than an official PHP support statement.
Internet scans by Mallory found that, as of October 20, roughly 884,000 hosts publicly exposed PHP version banners showing PHP 8.1 or earlier. That represented 59% of the 1.5 million hosts in its snapshot that disclosed a PHP version. Banner data does not capture every PHP deployment, and shared servers can host many domains behind one visible host.
PHP 8.2 also faces a looming maintenance deadline: the branch is scheduled to stop receiving maintenance on December 31, 2026. Organizations applying the current fix to 8.2 gain short-term protection but will need to move to a supported branch to continue receiving routine security updates.
Users of the volunteer-run rpms.remirepo.net repository were warned that packages would not be available on the release day. PHP advised those operators to use their Linux distribution’s maintained packages or build from source if they need the emergency update immediately.
Wallet users face indirect website risk
The vulnerabilities primarily create an operational emergency for server administrators, but cryptocurrency users can face indirect risks if a compromised server belongs to a wallet provider, trading platform, DeFi interface or project website.
An attacker controlling a web server could alter JavaScript or transaction prompts while leaving a site’s visible design largely unchanged. A user might believe they are approving a routine token swap or wallet connection while being asked to grant a malicious contract permission to move assets. Such web-layer compromises resemble the user-facing effects of previous front-end incidents involving Compound, Celer and Curve Finance, although those cases were linked to DNS-related attacks rather than PHP vulnerabilities.
Users cannot patch an operator’s server themselves, but they can reduce exposure during the remediation period by checking wallet prompts carefully before signing. The destination address, token allowance, network and transaction method should match the intended action. Hardware wallets can provide an additional independent display for transaction details, though users must still read those details rather than relying on the browser page.
Website operators running PHP should prioritize upgrading exposed systems, removing public access where an upgrade cannot be completed quickly, and reviewing logs for suspicious requests around the disclosure period. The short gap between reports of early exploitation and the patch release leaves little room for delayed maintenance on internet-facing PHP services.
Worried about PHP exploits impacting your funds? Strengthen security and trade safely with essential crypto safety standards every trader should know today.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
