PHP releases emergency fixes as some of the world's biggest websites say they were targeted by hackers

PHP identified two critical memory-handling vulnerabilities: CVE-2026-109618, an out-of-memory handling bug, and CVE-2026-109619, a use-after-free memory error. Both were rated 9.2 out of 10. They matter because attackers can send remote requests that exploit these errors and run code on affected systems, rather than merely causing a harmless application problem.

The article highlights the greatest danger for mod_php. It reports a demonstrated exploit in which an unauthenticated request can trigger an attack before application code runs. That means an attacker may not need an account or a vulnerable website feature to begin the attack. PHP installations serving web requests, including PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed, are considered at risk.

PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Security researchers and Cloudflare reported early exploitation attempts before the patches became available. PHP strongly urged users to update immediately, especially because unsupported older versions will not receive normal fixes.

PHP addressed the vulnerabilities in four released versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Users can obtain them through PHP’s downloads pages, while Linux users should check their distribution or long-term-support vendor for updated packages. Windows source and binaries are provided on the same downloads page.

The important dividing line is support status. PHP 8.1 and older will not receive the standard fixes. PHP also supplied minimal source backports for PHP 7.4, 8.0, and 8.1, but these are intended for people building from source or lacking access to an LTS vendor. They do not change the broader warning about unsupported installations.

This creates a serious exposure problem because many websites still use end-of-life PHP versions. Administrators should update to a fixed release as soon as possible. If they cannot, PHP lists temporary mitigations, but explicitly says those measures are not a complete solution.

The article reports that more than 5.1 million PHP hosts are currently exposed online. Of those, approximately 3.8 million reportedly have at least one port open. The figures are attributed to BleepingComputer, which cited VirusTotal data. They show the potential reach of the incident, although they do not mean every listed host is running a vulnerable or unsupported PHP release.

An internet-facing host is reachable from outside its network. An open port can provide an accessible entry point for a service, depending on what runs behind it and how that service is configured. The vulnerabilities affect PHP installations serving web requests, so exposed web infrastructure is especially important in this case.

The scale makes rapid patching difficult and urgent. Millions of hosts may need version checks, vendor updates, or emergency safeguards. Organizations using end-of-life PHP face the hardest situation because normal security fixes are unavailable. The article recommends updating PHP and treating mitigations only as temporary protection.

Remote code execution means an attacker may cause a vulnerable system to run the attacker’s instructions from a distance. In this incident, the two PHP memory flaws were severe because exploitation could affect systems serving web requests. The article says an unauthenticated request can trigger the demonstrated mod_php exploit before application code runs.

The danger became more immediate when information about the vulnerabilities leaked two days before PHP’s planned fixes. Security researchers and Cloudflare reported early exploitation attempts, and Cloudflare said attacks were emerging as new vectors appeared. The leak gave attackers useful information before administrators could reliably patch their systems.

Reuters reported that multiple government, healthcare, and education websites across Europe temporarily shut down to avoid being targeted. Their shutdowns were a defensive response to the combination of critical flaws, early attack activity, and delayed patch availability. PHP later released fixes and urged all users to apply them immediately.

mod_php is a way of serving PHP web requests through Apache. In this incident, PHP specifically considers the risk highest for mod_php because researchers demonstrated an exploit that starts with an unauthenticated request. The attacker therefore may not need to log in or reach a particular application feature first.

The key mechanism is the vulnerable PHP processing path itself. A request reaches the server, PHP handles it, and the memory flaw can be triggered before the website’s application code begins. That gives the attacker an earlier opportunity to affect the process and potentially execute code remotely. The article does not say every mod_php installation is exploitable in the same way, but it identifies this setup as the greatest risk.

Other PHP web-serving arrangements are also at risk. PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed among affected installations. Administrators should install the fixed releases rather than rely on configuration changes alone.

Memory limits, smaller uploads, and disabled session upload progress target particular ways the vulnerabilities might be triggered. For the out-of-memory flaw, PHP recommends appropriate memory limits and restricting incoming request sizes, including file uploads. For the use-after-free flaw, it recommends disabling session upload progress tracking. These steps can reduce exposure while administrators prepare updates.

They cannot replace a patch because the vulnerable PHP code remains installed. Other request patterns or exploitation paths may still reach the memory errors. PHP also suggests container limits to stop a vulnerable worker from affecting the wider system, plus fixes for application errors that cause crashes or timeouts. These controls limit damage or reduce triggers; they do not remove the defects.

PHP therefore describes the measures as mitigations, not a complete solution. The safest action is installing a fixed release. Organizations unable to update immediately should apply the recommended controls, monitor systems, and obtain packages from their Linux distribution or LTS vendor as soon as possible.

PHP is a programming language used to build and run websites and web applications. The article describes it as one of the world’s most popular languages for that purpose. PHP installations serve web requests through systems such as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

Its importance comes from its broad deployment. When a core PHP component contains a remotely exploitable memory flaw, attackers may target the infrastructure beneath many different websites and applications. The article reports more than 5.1 million PHP hosts exposed online, with about 3.8 million having at least one open port. That creates a large potential target population.

The risk is especially serious for unsupported legacy versions. PHP 8.1 and older will not receive standard fixes, and millions of websites may still run them. Current administrators should move to fixed releases, while those delayed should use PHP’s temporary mitigations and seek vendor-supported packages.