Critical PHP Vulnerabilities October 2026: 7 Urgent Steps to Protect Your Servers

Two critical PHP vulnerabilities disclosed in October 2026 could let an attacker run code on a vulnerable server without logging in first. If your business runs a website, online store, customer portal or API on PHP, this affects you, even if nobody on your team writes PHP code. The PHP security team released fixes on October 21, 2026, and a further related issue was reported two days later.

This guide explains what happened in plain terms, who is affected, which versions fix the problem, and the steps to take right now. At D2i Technology, our engineers work with PHP applications every day, and we have put together the answers to the questions clients ask most when an advisory like this lands.

Official references: PHP security advisories and the UK National Cyber Security Centre advisory.

What Are the Critical PHP Vulnerabilities?

PHP is one of the most widely used server-side languages on the web. It runs content management systems, ecommerce platforms, APIs and a huge number of custom business applications.

The two critical PHP vulnerabilities are:

• CVE-2026-109618: a memory-management flaw in how PHP handles out-of-memory conditions.
• CVE-2026-109619: a use-after-free flaw involving stale internal request state.

Both critical PHP vulnerabilities can potentially lead to remote code execution (RCE). In simple terms, an attacker may be able to make your server run their code, and they would not need an account to try. Public technical details and proof-of-concept activity have made patching more urgent.

One point is easy to miss: these are flaws in PHP itself. They are not bugs in a particular framework, theme or plugin, so updating your CMS alone will not fix them.

CVE-2026-109618: Out-of-Memory Handling

PHP manages memory as it processes each incoming request. Under certain conditions, running out of memory can interrupt processing while internal data is only partly set up. The cleanup that follows may then treat that half-finished data as valid. If an attacker can trigger this reliably, it may lead to memory corruption and, potentially, code execution.

CVE-2026-109619: Use-After-Free

A use-after-free happens when software keeps using memory after it has been released. Here, request-related state can survive after its memory is freed, and the next request handled by the same worker may use that stale state before it is reset. Under the wrong conditions, an attacker may be able to turn that into code execution on the server.

A Further PHP Vulnerability: CVE-2026-115560

On October 23, 2026, a related issue, CVE-2026-115560, was reported. According to the Canadian Centre for Cyber Security, it needs an uncommon mix of PHP configuration and application behavior. Applications that do not change the session serialization handler at runtime are not exposed to this particular attack path.

The October 21 updates do not fix this issue. As an interim measure, administrators can disable session upload progress where it is not needed:

session.upload_progress.enabled=0

Apply this in server-level configuration and restart the affected PHP workers. Then keep an eye on the official PHP advisory for a follow-up patch before you treat the issue as closed.

Keep in mind that this setting is a mitigation for one specific attack path. It does not fix the two critical PHP vulnerabilities above.

Which PHP Versions Fix the Critical PHP Vulnerabilities?

The PHP project has published fixes for the following supported branches:

These releases fix CVE-2026-109618 and CVE-2026-109619. They do not, on their own, resolve CVE-2026-115560.

PHP 8.1 and older no longer receive regular security updates from the PHP project. Some operating system vendors and long-term-support providers do backport fixes, so check the status of your specific distribution and package rather than assuming either way.

If you are on PHP 8.2, note that upstream security support ends on December 31, 2026. Patch now, but plan an upgrade to a newer branch soon. Always confirm your target version against the official PHP security archive.

Who Is Affected?

You do not have to develop PHP applications to be at risk from critical PHP vulnerabilities. Any organization running a vulnerable PHP installation that handles web requests should check its exposure.

Websites, Portals and Online Stores

Business websites, customer dashboards, ecommerce stores and custom web applications are all exposed if the PHP runtime underneath them is vulnerable. For CMS and ecommerce platforms, check both the PHP version and your software vendor’s own advisories. Updating WordPress or a plugin does not update PHP.

Frameworks Like Laravel, Symfony and WordPress

Applications built on these frameworks depend on the PHP runtime, so they inherit the risk. A framework patch is not necessarily needed for a PHP-core flaw, but the runtime itself must be updated.

Hosting Providers and Managed Infrastructure

Shared hosting, dedicated servers, cloud instances and managed PHP platforms should identify every affected runtime and coordinate updates with their customers.

Containers, Appliances and Third-Party Products

Some products bundle PHP inside them. You may be exposed through a container image, network appliance or commercial application without ever seeing a “PHP server” on your asset list. Review vendor advisories and your software inventory carefully.

Which Systems to Fix First

The UK NCSC and CERT-EU both point to internet-facing PHP systems as the top priority. The PHP project has flagged Apache deployments using mod_php as particularly high risk, because a demonstrated attack can reach the vulnerable code before your application code even runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed setups should be assessed and updated too.

7 Steps to Protect Your Servers From Critical PHP Vulnerabilities

Step 1: Find Every PHP Installation

Build a list of PHP versions across production, staging, development, containers and third-party products. On a server you manage, start with:

php -v

Be careful here. That command shows the command-line PHP version, which is often different from the version your web server or PHP-FPM pool actually uses. A common example: the CLI reports 8.4.27, but the website is still served by an older 8.3 FPM pool. Check the real runtime through your hosting control panel, container image or web server configuration.

Step 2: Update to a Fixed Release

Upgrade each installation to the patched version for its branch, or a later supported release. Use trusted operating system repositories, official packages or your hosting provider’s update process. Back up critical systems and test compatibility, but keep the timeline short; this is not a change to leave for next month’s maintenance window.

Afterwards, confirm the version your application is actually running and make sure the services and workers restarted.

Step 3: Handle CVE-2026-115560

Review the latest advisory. Where it applies, disable session upload progress in configuration that takes effect before request parsing. An ini_set() call in application code or a per-directory .user.ini file is not enough for this. Check for a follow-up PHP release before closing the incident.

Step 4: Restrict Exposure if You Cannot Patch Yet

If an internet-facing system cannot be updated promptly, limit who can reach it. Network controls, a reverse proxy or temporary isolation can reduce risk, but none of them replace the update. If you cannot patch or isolate a public system, taking it offline may be the safer choice.

Step 5: Look for Signs of Compromise

Patching critical PHP vulnerabilities closes the hole. It does not remove anything an attacker may have already left behind. Review:

• Web server and application logs
• Login and admin activity
• Unexpected processes and outbound connections
• Unfamiliar files, scheduled jobs, user accounts or code changes
• Container and endpoint security alerts

If something looks wrong, follow your incident response process: preserve logs, contain affected systems, investigate the scope and restore from trusted sources. A successful patch does not mean the server is clean.

Step 6: Check With Vendors and Partners

Ask your hosting provider, software vendors and managed service partners whether their PHP runtimes or bundled products are affected. Track open items and get confirmation when fixes are deployed, especially for appliances where your team cannot see the PHP version directly.

Step 7: Set Up Ongoing Monitoring

Critical PHP vulnerabilities will not be the last runtime issue you face, so create a simple, repeatable process: watch PHP and vendor security advisories, keep a runtime inventory, verify patches, and scan internet-facing applications on a regular schedule. Our SecOps services help teams build exactly this kind of routine.

What If You Cannot Patch Immediately?

Temporary mitigations can buy time, but they are not the same as updating PHP. CERT-EU describes server-level measures for the first two critical PHP vulnerabilities, including memory-limit restrictions, request-size limits and disabling session upload progress.

Each of these can affect availability or memory use, so review the official guidance and test before applying them. In particular, avoid setting memory_limit=-1 across a whole environment. CERT-EU mentions it only for one specific failure path when enforced correctly, and an unlimited memory limit brings its own risk of resource exhaustion.

If a public server cannot be mitigated with confidence, isolate it until a verified fix is in place.

An Action Plan for Business Owners

You do not need to understand PHP memory management to respond well. You do need someone accountable and evidence that systems have been checked.

Right away: assign an owner, list internet-facing and PHP-based systems, notify your hosting or infrastructure team, and rank systems by business impact.

As soon as possible: deploy the updates, apply and verify the interim mitigation for CVE-2026-115560 where needed, test that applications still work, and investigate anything suspicious.

After remediation: confirm patched versions and restarts, document affected assets, dates and exceptions, review what you learned, and plan upgrades for any unsupported PHP branches.

How D2i Technology Can Help

If you are unsure how the critical PHP vulnerabilities affect your systems, our development, QA and security teams can help you review PHP-based applications and prioritize remediation. Depending on your environment, that can include a PHP runtime and dependency inventory, an exposure assessment, coordination with your hosting provider, patch planning, compatibility and regression testing, and configuration review.

We also offer broader security testing and penetration testing to confirm your applications are secure once the urgent work is done, while our automation testing team can make sure the update has not broken anything important. If your stack needs a longer-term upgrade path, our DevOps services and web application development teams can plan it with you.

One caution: an assessment should never delay patching a known critical issue. Update first, then review.

Do Not Wait on Critical PHP Vulnerabilities

These disclosures are a reminder of why a current runtime and a reliable patching process matter. The priorities are clear: find every PHP installation, apply the right updates, deal with CVE-2026-115560, and check for signs of compromise where systems were exposed.

For customer-facing applications, the risk goes beyond downtime. Critical PHP vulnerabilities like these can put application integrity, customer data and your wider hosting environment at stake. Inventory your PHP environments, apply the fixes and verify the results before an incident forces the issue.