Critical PHP Patch Due Today: Get Ready Now
The PHP security team has given advance notice of an emergency release. Two critical vulnerabilities, both rated CVSS v4.0 9.2, are fixed in a release scheduled for today, 21 October 2026 at 14:00 UTC (15:00 BST).
CERT-EU has issued Security Advisory 2026-018 telling organisations to prepare for immediate patching.
What we know
- CVEs: CVE-2026-109618 and CVE-2026-109619
- Severity: CVSS v4.0 9.2 for both
- Impact: CERT-EU says the scores point to potential unauthenticated remote code execution
- Affected versions: not yet confirmed by PHP. Reports cited by CERT-EU suggest every version from PHP 5 onwards may be affected
- Fixed versions: to be published with the release
- Technical detail: none public yet
PHP has said it may release early if details leak or exploitation is seen in the wild.
What we don’t know
Which component is affected, whether default configurations are exposed, and which branches will get fixes. If the PHP 5 claim holds, a lot of end-of-life installs will have no official patch at all.
WordPress and other PHP platforms
This is a flaw in the PHP runtime, not in an application. That matters for anything built on PHP: WordPress, Drupal, Joomla, Magento/Adobe Commerce, Moodle, Nextcloud, phpMyAdmin, Laravel and Symfony apps, and plenty of vendor web consoles.
- A WordPress update won’t fix it. Core, plugin and theme updates don’t touch the PHP interpreter. The fix comes from whoever manages the server.
- Managed hosting: the provider patches PHP. Confirm they have, and when.
- Self-hosted or VPS: you patch PHP yourself, through your OS packages or container image, then restart PHP-FPM or the web server so the new binary is actually loaded.
- Distro packages: Debian, Ubuntu and RHEL often backport fixes without changing the PHP version number. Check the package changelog for the CVE IDs rather than relying on the version string.
- Old PHP branches: sites stuck on unsupported PHP versions, often because of an ageing plugin or theme, may get no upstream fix. These are the ones to isolate.
Whether a default WordPress install is exploitable is unknown until the details are out. Given how many sites run it, assume it is a likely target and plan accordingly.
What to do now
- Build your inventory. Find every PHP runtime, including the ones nobody owns: legacy intranet apps, vendor appliances, containers with pinned base images, and hosted CMS sites. Your vulnerability scanner’s software inventory is a good starting point.
- Rank by exposure. Internet-facing first. Note anything on an unsupported branch.
- Line up change approval. Get emergency change in place today so patching isn’t waiting on a CAB meeting.
- Check your supply chain. Ask hosting providers, MSPs and SaaS vendors running PHP when they will patch.
- Plan for what you can’t patch. For end-of-life or vendor-controlled systems, CERT-EU advises considering isolating internet-facing apps from public networks until a fix is applied. A WAF rule is not a fix, particularly before the bug is understood.
After the release
Patch internet-facing systems first, then everything else. Expect proof-of-concept code quickly once the diff is public; attackers will be reading it at the same time you are.
Bottom line
Details are thin, but two 9.2s in a runtime this widespread is enough to act on. Spend this morning finding your PHP, and be ready to patch this afternoon.
This post will be updated once fixed versions are published.
Sources