PHP Security Updates: What Local Businesses Need to Check Now

If your business runs a website, the recent PHP security alerts are worth a conversation with whoever maintains it. You do not need to become a programmer. You need a clear answer about the software serving your site, evidence that the right fixes are installed, and a check that the business functions still work.

This guide was checked on October 26, 2026. It includes follow-up advice published after the initial emergency releases. Security guidance can change, so ask your provider to check the linked advisories again when they act.

What is PHP, and why might your business use it?

PHP is an open-source programming language commonly used on a web server. It can help generate pages and process requests before the result reaches a visitor’s browser. Think of it as part of the engine behind a website, rather than something a customer needs to install. See PHP’s introduction.

WordPress, Drupal and Joomla are familiar examples of software that uses PHP. A booking portal, customer account area or older custom application may use it too. The name of your website platform alone does not establish which PHP build is running or whether a particular vulnerability can be exploited.

What happened in October?

On October 21, PHP published emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both official advisories rate severity at 9.2 using CVSS 4.0. That score describes the flaws, not the probability that your particular business has been attacked.

CVE-2026-109618 concerns cleanup after PHP runs out of memory: PHP may use internal data that was not fully initialized. The researchers demonstrated unauthenticated code execution with Apache’s mod_php, including a path before application code runs. The advisory considers PHP-FPM susceptible through application-dependent paths, but does not demonstrate a complete FPM exploit for this specific flaw. Details: PHP’s out-of-memory advisory.

CVE-2026-109619 concerns stale memory references retained between requests handled by a server worker. The official advisory describes memory disclosure and code execution; a session-related path was validated with mod_php and PHP-FPM, with the FPM route dependent on application behavior. Successful code execution uses the web worker’s privileges, not automatically administrator or root access. Details: PHP’s stale-state advisory.

The upstream fixes for those two flaws are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Earlier releases in these maintained branches need the fixes. Older unsupported branches should not be assumed safe because they are missing from this release list: ask the vendor about coverage and a supported migration path. PHP advises checking all installations serving web requests, including CGI, FrankenPHP and LiteSpeed, not only Apache and PHP-FPM.

Two follow-up updates matter

The PHP project’s announcements also cover later findings. On October 23 it warned about CVE-2026-115560, an unusual session-upload-progress scenario involving a change of session serializer at runtime. Ask your maintainer whether it applies and whether session.upload_progress.enabled must be disabled until the next regular bugfix release. Applications that never switch serializer at runtime can keep it enabled, according to PHP. On October 26, rebuilt official Windows packages, 8.2.35-1, 8.3.36-1, 8.4.27-1 and 8.5.12-1, updated bundled Brotli for CVE-2026-111497. This separate issue concerns cURL automatic response decompression, which is disabled by default but can be enabled by applications or HTTP client libraries. The rebuild suffix does not change the PHP runtime version number. Check the dated PHP announcements.

These are checks for the person operating your server. Do not paste configuration changes into a production site without confirming applicability and testing the result.

How large was the impact?

The potential reach is substantial because PHP underpins many websites. That is different from knowing how many businesses were successfully compromised. Depending on the web worker’s access, successful exploitation could expose information, change site content or interrupt enquiries, bookings and sales. Those are possible consequences, not a claim that they happened to your site.

CloudLinux reported requests matching a circulating exploit pattern on October 21. That supports treating attempts as real, but does not establish how many compromises succeeded. Its protective firewall rules are partial protection rather than a substitute for the software update. See CloudLinux’s advisory.

The Dutch NCSC’s October 23 update said it knew of one report of possible abuse abroad, with success unconfirmed. It also judged exploitation more complex and large-scale exploitation less likely than initially thought, while continuing to recommend immediate patching. That is a dated assessment, not proof that no successful attacks exist anywhere. See the Dutch NCSC update.

What to ask your hosting company or website maintainer

1. Where do we run PHP? Include our main site, subdomains, staging sites, customer portals, webmail and administrative tools. Identify who maintains each one.
2. What exact PHP package and build serves each application, and does it contain fixes for CVE-2026-109618 and CVE-2026-109619? Please provide the relevant vendor advisory or package changelog, plus the installation date.
3. Have the updated services and workers been restarted where required? Please also check the October 23 session guidance and October 26 Windows rebuild advice if applicable.
4. What evidence supports our exposure assessment? Record relevant configuration, the period before patching, and whether you found signs that require further investigation. “The homepage loads” is not a security assessment.
5. Can we verify the important customer journeys after the update? Test contact forms, bookings, checkout, login and uploads that our site actually uses.
6. If you cannot patch promptly, what temporary restrictions or isolation do you recommend, who will complete the update, and when will you confirm it is live?

A version number by itself can mislead. Hosting vendors may backport a fix to an older-looking version, and control-panel software may need a separate update from the website’s PHP installation. Ask for the vendor’s package-level evidence. cPanel’s advisory.

If you use a fully managed website service and cannot inspect its servers, ask its support team for confirmation rather than assuming you need to install PHP yourself. Do not upload a public diagnostic page, share credentials, or run exploit demonstrations against your live website to find out whether it is affected.

Patch the runtime, then verify the business still works

Updating WordPress, a theme or a plugin alone does not replace an update to the PHP runtime underneath it. A web application firewall can reduce some attack traffic but does not remove vulnerable server code. Cloudflare’s technical analysis.

Have your maintainer take an appropriate backup, check application compatibility, apply the vendor-supported fixes and restart affected services where required. Confirm the deployed build rather than only a completed download. Then test the customer journeys and keep a short record of what was changed and who verified it.

If an exposed system cannot be updated immediately, discuss temporary isolation with the provider. ENISA recommends prioritizing internet-facing systems and considering isolation where prompt remediation is infeasible. ENISA’s joint statement.

Patching prevents the fixed vulnerability from being used again; it does not establish whether someone already gained access. If the provider finds suspicious activity, preserve relevant logs and use an incident-response process rather than deleting evidence or declaring the site clean. The UK NCSC advises checking for compromise and backdoors where affected systems cannot promptly be updated or disabled. UK NCSC guidance.

Make the next update less of a scramble

Once the immediate work is done, agree who owns PHP updates, how you will receive security notices and how quickly important fixes will be tested. PHP 8.2’s security support ends on December 31, 2026, so businesses still on that branch also need a supported-version plan. PHP’s support calendar.

The useful outcome is a documented answer: which systems use PHP, which fixed vendor builds are deployed, what follow-up guidance applies, and whether the website’s important functions have been checked. If any of those answers is missing, keep it as an open task with an owner rather than treating silence as confirmation that everything is safe.