Critical PHP flaws: check your hosting and apply the fix

Your website can look perfectly healthy while the software behind it needs an emergency security update. Updating a page, a plugin or an AI-generated frontend does not tell you whether the PHP engine serving a different part of the site has been patched.

On 21 October 2026, PHP released security updates for CVE-2026-109618 and CVE-2026-109619. The fixes are available now. Both flaws can allow unauthenticated remote code execution: an attacker may be able to run code without logging in. Check the PHP service behind each domain and obtain proof that the fix is active.¹

Updated 21 October 2026 at 17:01 CEST after the official security release. The earlier 13:28 CEST edition described the pre-announcement. This warning does not establish a worldwide outage or that your website has been compromised.

What PHP is, and why your AI-built app may still depend on it

PHP is a programming language executed on a server. The server runs PHP code and returns a page or an API response to the visitor. WordPress uses it. A modern frontend can also call an older PHP backend, a WordPress content API or a separate administration tool. The public page does not show the full chain.⁵ ¹⁰

W3Techs measured PHP on 69.3 percent of websites whose server-side programming language it could identify on 21 October 2026. That is a large installed base. It is not 69.3 percent of all websites and it is not a count of vulnerable or compromised sites.⁴

Which PHP services need the fix?

The official advisory covers PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP identifies mod_php as the highest-risk configuration. A login page does not establish protection: the maintainers describe a demonstrated attack path before application code runs.¹

Reuters brought the warning into international news on 21 October. It reported a Cloudflare executive describing early attacks, while the Australian agency said it was not aware of active exploitation at its observation time. Those are attributed observations, not a verified worldwide attack count. Our practical advice does not depend on declaring that every site is already under attack.³

Start with the running service, not the name on your invoice

List the domains and subdomains your product uses. Include the marketing site, blog, admin area, customer portal, API and old staging sites that remain reachable. For each one, identify where requests actually go and who maintains that service. A missing result belongs under unknown, not safe.

WordPress and TransIP: the checks you can do without a terminal

In WordPress, open Tools > Site Health > Info > Server and record the PHP version shown. In a Dutch dashboard this is Gereedschap > Sitediagnose > Informatie > Server. This is a useful inventory step, not a dedicated test for these vulnerabilities. Keep the technical information private.⁵

For TransIP shared hosting, the documented route is Webhosting, your domain, Geavanceerd, then PHP-instellingen. Do not switch to a random newer branch to see what happens. Ask the provider whether the exact PHP build serving that domain contains the security fix and whether any restart or change is still pending. We checked the public documentation, not your TransIP account.⁶

Send your host: “Does the PHP build currently serving [domain] contain the fixes for CVE-2026-109618 and CVE-2026-109619? Please give the active build or package version, advisory reference, completion time and any action still required from me.”

Give Claude Code or Codex a bounded inspection task

An agent can inspect your repository and authorised deployment configuration. It cannot prove what is running on a host it cannot access. Start with an inventory and evidence request. The prompt below is a defensive workflow, not an exploit test.

Inspect this product for PHP exposure related to CVE-2026-109618 and CVE-2026-109619. Start read-only. Map our domains, subdomains, deployed runtimes, containers, reverse proxies and external CMS/API services. Check only authorised repositories and provider dashboards. For each PHP service, report its owner, the actual web-serving build, exposure, vendor advisory and confirmed patch status, with time-stamped evidence. Check TransIP, Vercel custom runtimes/rewrites and apps connected to Supabase where relevant. If you lack access, record unknown and name the exact missing evidence. Do not print secrets, create public phpinfo files, run exploit requests, contact third parties or alter production. Propose the smallest patch or containment plan, its impact, backup/rollback and verification steps. Stop for my approval before changes.

Apply a verified runtime fix, then prove it is serving traffic

Use the fixed release for your maintained branch, or a vendor package whose advisory explicitly confirms both CVE fixes. This table lists the upstream releases; a distribution can backport a fix while retaining an older version number. Ask for its package advisory and active build rather than rejecting or trusting a number alone.¹¹ ¹²

PHP 8.1 and older receive no regular upstream security releases. Arrange a tested migration or obtain vendor-confirmed maintained backports. PHP supplied minimal source backports for 7.4, 8.0 and 8.1, but source patches are not a ready-to-install managed hosting update. Have the operator assess the supported route.¹ ⁹

For a self-managed service, the operator should determine whether PHP-FPM, Apache, containers or workers need restarting or redeploying. Then verify the build in the web-serving process and test the important routes: login, forms, uploads, checkout and scheduled jobs as applicable. A local php -v result may belong to a different interpreter than the web service. A passing homepage alone is insufficient.

If you cannot patch an exposed service, contain it before PHP runs

The PHP team says temporary mitigations do not make an unpatched installation safe. CERT-EU recommends considering isolation when immediate remediation is impossible. For a critical exposed PHP service, agree targeted restrictions with its operator until the verified runtime fix is active.¹ ²

Apply a temporary access restriction at the provider, reverse proxy or network boundary before requests enter PHP. Cover direct origin access as well as the public domain. A WordPress maintenance plugin can still invoke PHP, so a maintenance page inside the application is not equivalent to isolating the runtime.

Choose the narrowest effective restriction. A separate affected blog may be isolatable without disabling an unrelated application. Preserve authorised operational access, essential service continuity and evidence. If compromise is suspected, preserve logs and engage incident response; patching does not demonstrate that an earlier intrusion has been removed.

Keep unknowns visible until there is evidence

This article does not audit your infrastructure or certify a provider. It gives you an inventory, a named owner and a way to verify the response. Neither the severity score nor a technology-detection service establishes that a particular request can exploit your product.

That is also the evidence discipline behind the Forenta Journal: record what was actually checked, what remains unknown and who owns the next action. The related article “What a Passing Build Actually Proves” explains why a successful technical check must be read within its scope. The useful result here is a dated patch or containment record for every exposed PHP service.