Two serious security flaws in PHP prompted urgent warnings and updates on 21 October 2026. They can allow attackers to run code on vulnerable servers without logging in.
\n\n\n\nThe fixes are available. Whether your website is protected depends on whether its hosting provider or administrator has actually installed and activated them.
\n\n\n\nPHP is a programming language used behind the scenes to make websites work. It runs on the server: the computer that processes visitors’ requests and sends pages back to their browsers.
\n\n\n\nYou might never see PHP, but your website or a service you use may depend on it. The Dutch National Cyber Security Centre warns that PHP is also embedded in network devices, management interfaces and other products.
\n\n\n\nTwo vulnerabilities were disclosed: CVE-2026-109618 and CVE-2026-109619.
\n\n\n\nBoth involve mistakes in how PHP manages its working memory. One can occur when PHP runs out of memory. The other involves leftover internal information being used after its memory has already been released.
\n\n\n\nUnder certain conditions, attackers can exploit these mistakes to execute their own code. Both vulnerabilities received a severity rating of 9.2 out of 10.
\n\n\n\nYes. The official PHP security advisory confirms that exploitation can happen without authentication.
\n\n\n\nIn a demonstrated attack against one server configuration, the problem is triggered before the website’s own code starts running. That means the website’s login screen cannot stop that particular attack.
\n\n\n\nYes. PHP released four security updates on 21 October:
\n\n\n\nThese versions fix both vulnerabilities. Some suppliers also provide packages containing the fixes under different version numbers.
\n\n\n\nOlder installations need particular attention. PHP 8.1 and earlier no longer receive regular PHP-project updates, although some vendors provide extended support.
\n\n\n\nNo. A vulnerability creates an opportunity for an attack; it does not prove an attack happened.
\n\n\n\nHowever, CERT-EU reports that technical details and early demonstrations of exploitation are circulating. That makes prompt action important. Its advisory does not establish how many websites have been compromised.
\n\n\n\nAsk your hosting provider or administrator to confirm whether your website uses PHP, which security update has been applied, and whether the live service is running the updated software.
\n\n\n\nUpdating a website plug-in alone does not establish that PHP itself has been repaired.
\n\n\n\nIf patching is delayed, temporary settings can reduce some risks, but official guidance says they do not provide complete protection.
\n\n\n\nThe useful question now is: has the fix been verified on the server actually running your website? The existence of an update cannot answer that.
For broader security context, my analysis of the Bybit hack examines transaction approval risks, while my article on OpenAI’s Medicare breach looks at incident disclosure and reporting. These are separate incidents with different causes.
\n