Two critical PHP vulnerabilities: what website owners need to do

On 21 October 2026, the PHP team announced two critical security vulnerabilities that, under certain conditions, allow an unauthenticated attacker to execute code remotely on a server. Both vulnerabilities have a CVSS v4.0 severity score of 9.2 out of 10. Website owners should urgently check their hosting environment and install the PHP security fixes. Official PHP advisory.

What has been discovered in PHP?

PHP is a server-side runtime used by WordPress, WooCommerce and many custom websites and business applications. These fixes are needed in PHP itself. Updating a content management system or its plugins alone does not resolve these two PHP vulnerabilities.

CVE-2026-109618 — memory state corruption when memory runs out. If request processing is interrupted, PHP may attempt to handle internal data that has not been fully initialised. Specially crafted requests can turn this error into remote code execution. The PHP security team confirmed exploitation in Apache mod_php before any website application code starts running. Technical details of CVE-2026-109618.

CVE-2026-109619 — stale state between requests. A PHP worker can retain references to memory that has already been freed after an earlier request. Under certain conditions, a later request handled by the same worker uses this invalid state. This can also enable an attacker to execute code. Technical details of CVE-2026-109619.

For website owners, the practical concern is that an attacker may not need an administrator password or a visitor to click anything. This announcement should therefore be passed to the person responsible for the server immediately.

Which websites could be affected?

The PHP team urges updates for all PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest confirmed risk is associated with mod_php, but using PHP-FPM does not provide immunity. PHP’s explanation of the risk.

The second advisory describes a validated PHP-FPM scenario that depends on a suitable application operation and a subsequent request handled by the same worker. Exploitation conditions nevertheless vary between environments: a PHP version number alone does not prove that a particular website has already been compromised. Analysis of PHP-FPM and other scenarios.

Owners of company websites, online shops and customer portals should all arrange a check. Even a simple contact form operates within a broader server environment. An HTTPS certificate does not fix these PHP errors. A firewall can provide an additional layer of protection, but does not replace a patched runtime.

What could this mean for your website and business?

In the confirmed exploitation case, code runs with the permissions of the web worker account. This does not automatically grant administrator access to the entire server: the actual impact depends on file permissions, accessible data and isolation between environments. Impact confirmed by the PHP team.

Depending on the permissions available, potential business consequences include:

• Changes to website content. Modified files or database records could introduce unauthorised pages, deceptive messages or redirects that send visitors elsewhere.
• Loss of data confidentiality. If the process can access configuration files or the database, the information and credentials stored there could be at risk.
• Disruption to business operations. A website outage can interrupt enquiries, registrations or purchases. For an online shop, this may mean lost orders and additional customer support work.
• Recovery costs and reputational damage. An incident may require investigation, system recovery, replacement of access credentials and communication with affected customers.

These are possible consequences, not a claim that a specific website has been breached. The presence of a vulnerability and a confirmed security incident are separate findings.

Which PHP versions should you install?

PHP identifies the following patched versions. Install at least the relevant release, or a later release in the same branch containing these fixes. Official update guidance.

Linux distributions and long-term support vendors may backport fixes to packages carrying an earlier version number. In that case, obtain confirmation from the vendor that the installed package fixes both CVEs. PHP 8.1 and older branches no longer receive regular support from the PHP project. Vendor patches and older branches.

Security support for PHP 8.2 ends on 31 December 2026. If your website still uses it, plan a move to a branch with a longer remaining support period alongside the immediate security update. PHP support timelines.

What to do now: an update action plan

We recommend treating this update as a short maintenance task with verifiable results. Changing a version number in the hosting control panel is insufficient if some processes continue to use the old runtime.

1. Identify the actual environment. Establish which PHP version serves the domain, its separate worker pools and containers. Command-line PHP may differ from the version handling browser requests. Check background jobs separately.
2. Verify your backup. Keep a consistent copy of the files and database, with a clear recovery procedure. When planning a brief maintenance window, account for orders and form submissions received during that period.
3. Install a confirmed fix. Work with your hosting provider or server administrator to update the PHP branch in use. If moving to another branch, assess compatibility with the website’s code and extensions beforehand.
4. Restart workers and verify the result. Confirm that all PHP workers serving the website are running the patched package. Check the active environment, not just whether a package has been downloaded.
5. Test essential functions. Open internal pages, send a controlled form test, and check sign-in, file uploads, scheduled jobs and relevant integrations. For an online shop, test the checkout flow and payment callbacks.

The work should leave a clear record of what was updated, how the fix was verified and which website functions were tested. A working homepage alone does not confirm that ordering or email delivery processes work.

Can temporary settings provide protection?

The temporary measures described by PHP block only some exploitation paths. For the second vulnerability, these include setting session.upload_progress.enabled=0 administratively and, on PHP 8.5, also setting fatal_error_backtraces=0, then restarting every worker. These measures do not provide complete protection and must be assessed by an administrator. Limits of temporary measures.

The memory vulnerability guidance also discusses removing PHP’s memory limit. Blindly applying memory_limit=-1 on shared hosting creates resource exhaustion risks. Appropriate resource boundaries and request controls are needed; even then, other memory allocation failures remain possible. A patched PHP package is the complete solution. Memory vulnerability mitigation guidance.

What if you suspect a compromise?

If you notice unfamiliar content, unexplained file changes or unusual system behaviour, do not stop at a PHP update. We recommend preserving logs and other evidence, working with your administrator to assess the need for isolation, and determining the scope of the changes. Coordinate credential replacement and recovery from a verified backup with remediation of the environment, so that new credentials are not exposed to a system that is still compromised.

The absence of errors in logs alone does not establish safety. The PHP team stresses that logs should complement configuration and application flow analysis. Limitations of log analysis.

How can Dev4you.lt help?

The Dev4you.lt team can turn this announcement into a practical plan for your website: identify the environment in use, coordinate the update, test website functionality and document the result. The scope depends on available access, the hosting model and the complexity of the system.

• Server administration — review PHP packages, extensions and worker configuration, coordinate updates and verify the running version.
• Website maintenance — assess compatibility, test critical functions and resolve errors that emerge after an update.
• Website security testing — review configuration, access permissions and possible signs of compromise within an agreed scope.
• Backups and recovery — check backup readiness and prepare a recovery plan.

Unsure who maintains PHP for your website? Contact Dev4you.lt with your website address, hosting provider and content management system. Please leave passwords out of the initial enquiry; we will arrange access separately.

Sources and information date

Information checked on 22 October 2026 against primary PHP project sources. The discussion of potential business consequences and the proposed action plan are the Dev4you.lt team’s explanation.

• PHP: critical vulnerability advisory of 21 October 2026.
• PHP security team: CVE-2026-109618.
• PHP security team: CVE-2026-109619.
• PHP branch support timelines.

Check your website’s PHP version

Use the Dev4you.lt PHP2Shell tool to assess the PHP version evidence and receive a PDF with recommended next steps by email. If the version is hidden, the result will clearly say that more information is needed.

PHP security check →