If your business website, online shop or customer portal runs on PHP, today matters. The PHP security team has scheduled an urgent release for Wednesday, 21 October 2026, at 14:00 UTC (3:00 p.m. in Lagos) to fix two critical remote code execution flaws in PHP core. This article is for website owners, small business IT leads, developers and anyone who manages a WordPress, Laravel or other PHP-based site, whether on shared hosting, a VPS or in containers.

Key takeaways

• PHP will ship fixes for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, on 21 October 2026 at 14:00 UTC.
• The PHP security team rated both flaws 9.2 on the CVSS v4.0 scale. Early online claims of a perfect 10.0 score were not confirmed by PHP.
• Details of the bugs leaked before the planned disclosure, which is why the release was announced at short notice.
• Fixes are expected only for supported PHP 8 branches. Sites still on PHP 5 or PHP 7 will not receive an official patch.
• No public exploit code or in-the-wild attacks had been reported at the time of the announcement, but that can change quickly once technical details become public.

What happened

On the evening of Tuesday, 20 October 2026, Jakub Zelenka posted an advance notice from the PHP security team on the official php.announce mailing list. It warned of an upcoming critical security release fixing two vulnerabilities, each scored 9.2 under CVSS version 4.0, and set the release for 14:00 UTC on Wednesday, 21 October. The notice also said the team could publish earlier if details of either flaw became public or if there was evidence of active exploitation, and it urged users to prepare so they can update as soon as the new versions are available.

The timing was not ideal. Earlier the same day, a post on the Hacker News forum claimed that a source had revealed two PHP remote code execution bugs, with an announcement expected on 22 October. That post was later removed, but screenshots spread across X and Mastodon, and some posts listed the reserved CVE numbers. Security firm watchTowr publicly confirmed that the leak related to real, embargoed PHP vulnerabilities, while making clear it had not discovered them and would not share technical details. PHP’s official schedule effectively brought the fix forward by about a day.

What we know about the flaws

Very little technical information has been published, and that is deliberate. According to security advisories from Beazley Security Labs and Threat Landscape, both CVE records are still marked as reserved. PHP has not said which function or extension is affected, which configurations are vulnerable, or whether an attacker needs to be logged in. Some advisories note that a critical rating like this could point to unauthenticated remote code execution, but PHP has not confirmed that.

Remote code execution is the most serious class of web bug because it can let an attacker run their own commands on your server. In practice that can mean defaced pages, stolen customer data, hidden malware that redirects visitors, or a foothold for wider attacks on your network.

Which versions are affected

PHP has not yet published official affected or fixed version ranges; these will come with the release. Public reporting suggests the current releases of the 8.2, 8.3, 8.4 and 8.5 branches are affected. Claims that every version back to PHP 5 is affected came from social media and have not been confirmed. What is clear is that PHP 5 and PHP 7 are end-of-life, so they will not receive official fixes regardless.

Who is affected

PHP powers a very large share of the web, including popular content management systems such as WordPress, Joomla and Drupal and many custom business applications. That makes this release relevant to:

• Small businesses and NGOs with a website on shared hosting, where the host controls the PHP installation.
• Developers and agencies managing client sites on VPS or cloud servers, where you are responsible for updates.
• Teams using containers, where old PHP base images can linger in production long after newer builds exist.
• Organisations running appliances or third-party products that bundle their own copy of PHP.

Across Nigeria and the wider continent, many SMEs rely on low-cost shared hosting and on developers who built a site years ago and have since moved on. Those sites are often running older PHP versions that nobody has checked recently. If that sounds like your organisation, treat this as the prompt to find out.

Why the leak raises the stakes

Coordinated disclosure normally gives defenders a head start: the fix and the details arrive together, and attackers have to work backwards from the patch. When details leak early, that head start shrinks. Advisories note that researchers have largely respected the remaining embargo, and at least one researcher has said they will publish a technical lab only after the embargo lifts. Even so, once patched versions are public, attackers can compare old and new code to find the bug. Sites that update within days are in a far stronger position than those that wait weeks.

What you can do before the release

1. Build an inventory

List every server, hosting account, container image and appliance that runs PHP. Record the version for each. On a server you can run php -v; on WordPress you can check under Tools > Site Health > Info > Server; in cPanel, the MultiPHP Manager shows the version for each domain.

2. Talk to your host or distribution

If you use shared or managed hosting, ask your provider when they will roll out patched PHP builds and whether you need to do anything. If you run Linux servers, watch your distribution’s security advisories, because many teams install PHP from distribution packages rather than directly from php.net.

3. Reduce exposure

Advisories recommend restricting non-public PHP applications, such as internal admin panels and staff portals, to trusted networks or VPN access. Internet-facing applications that cannot be patched quickly should be isolated where possible.

4. Plan your upgrade path off old PHP

If you find PHP 5, 7, 8.0 or 8.1 anywhere, prioritise moving it to a supported PHP 8 branch. According to php.net, the supported branches are 8.2, 8.3, 8.4 and 8.5, and PHP 8.2 itself only receives security fixes until 31 December 2026, so moving to 8.3 or newer buys more time.

What you should do

1. Today: confirm which PHP versions you run and who is responsible for updating each one.
2. After 14:00 UTC: check php.net and your host or distribution for the patched versions, then apply them as soon as they are available. Test critical functions such as checkout, contact forms and logins afterwards.
3. This week: watch for exploit reports. If public exploit code appears, treat any unpatched internet-facing site as urgent.
4. This quarter: retire any PHP version that no longer receives security updates and make PHP version checks part of your regular maintenance routine.

Sources

• php.announce: Upcoming Critical PHP Security Release
• Beazley Security Labs: Critical RCE Vulnerabilities in PHP
• Threat Landscape: PHP Core RCEs Leak Early
• PHP: Supported Versions

Featured image: Photo: “First Web Server” by User:Coolcaesar at en.wikipedia, CC BY-SA 3.0, via Openverse — source