Critical PHP flaws: why a CMS update alone is not enough
Two vulnerabilities can let attackers execute code on web servers. Fixes are available. For Swiss website operators, what counts now is the runtime actually in use.
The PHP project released security updates on 21 October 2026 for two critical vulnerabilities. Under certain conditions, the flaws can allow attackers to execute code on a web server without logging in. For operators of online shops, club websites or digital services in Switzerland, the server software in use is therefore decisive, not just the visible website.
The fixes are contained in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The two gaps are tracked as CVE-2026-109618 and CVE-2026-109619. A joint warning from European cybersecurity bodies, including ENISA and CERT-EU, calls on organisations to act immediately. Publicly reachable systems take priority.
The flaw sits beneath the CMS
PHP is a programming language with a runtime environment on the server. Numerous web applications are built on it. An operator can therefore use PHP without programming the language themselves. Depending on the contract, responsibility for the technical update lies with the hosting provider, a supporting agency or the company's own IT team.
In its own security notice, WordPress makes clear that these are not WordPress-specific flaws. A WordPress update is neither intended nor required for these vulnerabilities. Instead, the PHP installation must be patched. Details of the server version can be found in the WordPress site health section; many hosting control panels also display them.
For a small business, a precise question is therefore more helpful than the blanket assurance that the website is up to date: which PHP version serves the public application, and which fix has the provider installed? Keeping extensions and the CMS current remains important, but it does not answer this different question.
Version numbers need the right context
Anyone using the PHP project's original releases can compare them with the corrected versions listed above. With Linux distributions and long-term supported vendor packages, security fixes can also be backported into existing package lines. In that case the specific supplier's security notice also counts. An older major version shown on its own is not sufficient for a final assessment.
Conversely, a missing regular update path does not mean the all-clear. PHP 8.1 and older branches no longer receive normal security releases from the PHP project. Some providers supply their own backports. Operators must clarify whether these are valid for the installation in use, or move to a supported, patched branch.
Not every exposed server has already been hacked
The flaws affect memory management and error handling. According to the PHP project, the risk is particularly high with Apache and mod_php; other common PHP operating modes must also be checked. For the public, one distinction is crucial: a demonstrated attack path shows a real security risk. It does not prove that every affected website has already been taken over.
ENISA recommends recording applications and service providers and installing the updates. Where a rapid fix is not possible, organisations should consider temporarily isolating the affected applications from the public network. The PHP project, for its part, stresses that temporary configuration measures only reduce individual attack paths and are no substitute for complete protection.
A traceable confirmation should record which system was checked and what version it was brought to. With outsourced services, no responsibility gap may remain between agency and host. The inventory recommended by the European bodies serves precisely this purpose: to find PHP in products that sound different at first glance.
AI finds the flaws, people carry out the fix
OpenAI reports that the security firm Calif used an AI model to investigate a critical flaw and that Wiz independently reported both vulnerabilities. That is the account of a company involved. It is not the same as claiming that an AI alone discovered and solved the problem.
The PHP Foundation describes a longer prehistory: the first signs of one of the problems appeared back in 2024. Compatibility, possible side effects and scarce specialist resources made the decision for a fix harder. The foundation admits structural mistakes and reports changed processes. That limits the simple success story about automatic security.
For Swiss operators this leaves a verifiable task: define responsibility, record the affected runtimes and have the installed fix confirmed. A product name that sounds secure or a successful CMS update is not enough. What matters is whether exactly the software that actually handles public requests has been fixed.
