PHP releases urgent patches for two critical vulnerabilities

PHP has already released the patches. What's still missing is confirmation that they reached your business's server.

Picture this hypothetical scene: it's 9:10, an order comes in, and the team keeps working. You open the store from your phone, see the catalog, and assume everything is fine. That check leaves out something you can't see: whether the server received the security fix.

On October 21, 2026, PHP released urgent updates for two critical vulnerabilities. PHP is the engine that runs many websites; you can change what the customer sees without having updated that engine. If your business uses that technology, it's worth confirming with your provider what was fixed.

What happened and why it deserves attention today

The vulnerabilities are identified as CVE-2026-109618 and CVE-2026-109619. Both received a severity rating of 9.2 out of 10. They can allow someone to execute instructions on the server without having an account.

Official reports describe issues with memory handling, the engine's temporary workspace. One occurs when that memory runs out; the other, when references remain to information that has already been freed. You don't need to master those details to request the fix.

It is worth understanding the scope, though: the PHP advisory includes installations that handle web requests. It flags greater risk in a way of running Apache called mod_php, where an attack was demonstrated before the application even started running.

That doesn't prove anyone got into your server. The news justifies an urgent review; claiming there was an intrusion requires evidence from your installation.

Updating WordPress leaves another task pending

In a store you can have several layers of maintenance. One person handles WordPress content and extensions; another manages the hosting where PHP runs.

WordPress's own documentation on updating PHP directs users to their hosting provider. These are tasks that must be coordinated.

Think about a storefront: renovating the counter doesn't prove the lock was fixed. Something similar happens with a website. A report saying "we updated the plugins" can describe work that was done well and still not answer whether PHP was patched.

That's why I'd ask the provider to identify the fix applied to the engine that serves the site. That precision keeps you from closing the item based on a message that was about something else.

Which versions include the patches

The project's security advisories list these first fixed versions within the supported branches:

The table is useful for talking with the provider. Some distributions and providers incorporate the fix while keeping an earlier version number, as the PHP notice explains. In that case, ask for the provider's notice confirming that their package covers both flaws.

Don't order a version jump blindly. Ask the technical lead for a corrected option that's compatible with your application.

There's another pending item for the budget: PHP 8.2 ends its security support on December 31, 2026. If your system depends on that branch, it's worth setting a date and an owner for the migration. Fixing this emergency and preparing for that change are two different scopes of work.

What I would ask the vendor

I would open a single ticket so the answers stay together. I'd include these points:

1. Scope. Which of my business's sites and services use PHP, including portals that don't show up in the main menu.
2. Fix. Which version or package was installed and where the coverage of both vulnerabilities is documented.
3. Effective application. Confirmation that the processes serving the website are now using the fix.
4. Validation. Which business flow was tested afterward and who reviewed the result.

I would also ask for a time for the next update if they're still working. "We're looking into it" leaves the business waiting without knowing when there will be a useful answer.

The message can be simple: we need to confirm whether our services are affected and, if so, when the fix will be applied. The response should let us close out the open item with evidence.

Test what your team actually uses

After the change, my recommendation is to choose a journey that represents real work. In a store, a test order should show up where the person preparing the shipment processes it. In an office, the form should deliver the request to the correct inbox.

The homepage alone doesn't verify any of those steps.

Before making changes, agree with the provider on how they'll restore service if an incompatibility comes up and what backup they have available. The WordPress guide also recommends preparing the site and having a backup before updating PHP.

If the provider proposes temporarily reverting to a vulnerable version because of a flaw, ask them to explain how they'll limit exposure while they fix compatibility. Leaving it open as a permanent solution keeps the original problem in place.

If they still can't install the patch

The report on the second vulnerability warns that the configuration changes don't cover every possible path. A temporary measure needs a clear scope.

Ask the technical lead to document what that measure reduces and when the full fix will be applied. According to the service, they should also assess whether it makes sense to restrict it while the work is being completed.

On the business side, prepare how you'll receive requests during an outage if one becomes necessary. Having an alternate channel on hand keeps you from improvising with a client waiting. The technical decision and customer service need to be coordinated.

My takeaways

My read on this news is operational: maintenance should produce a verifiable response. If you pay a monthly fee, it's worth knowing who handles server alerts and how they confirm the work is done.

In this case, a useful close includes the fix applied and a test of the flow your team needs. Keep that response in the service follow-up. It will help you for the next review and to spot responsibilities that were left unassigned.

Conclusion

The PHP patches have already been released. The immediate task is to locate the services that use it and confirm the fix with the provider. Then, verify that the business can keep running.

An available page answers the question of whether it loads. To know if it received the patch, you need to check what was actually installed.

References

• PHP: security notice and releases from October 21, 2026
• PHP: RCE via OOM corruption, CVE-2026-109618
• PHP: RCE via stale global state, CVE-2026-109619
• PHP: supported versions
• WordPress: guide to updating PHP