PHP Security Alert 2026: Critical PHP2Shell Vulnerabilities, Affected Versions and How to Protect Your Website

Security alert at a glance

On October 21, 2026, the PHP project released fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution in affected PHP runtimes. The initial upstream fixed releases were PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Check the current vendor build as well as the version string: distributions and hosting companies may backport a fix without using the identical upstream version.

As of October 26, 2026, the CERT-EU update advises disabling session.upload_progress.enabled and restarting workers as a mitigation for the separately disclosed CVE-2026-115560. The issue is limited to unusual request/session configurations involving upload progress; further technical details were still pending an official PHP advisory at the time of review. It is not one of the two PHP2Shell vulnerabilities. A mitigation is not a substitute for an applicable runtime update.

What happened, and what is PHP2Shell?

The PHP project announced a security release on October 20 and published the fixes the next day. The Dutch National Cyber Security Centre uses PHP2Shell as the operational name for CVE-2026-109618 and CVE-2026-109619. PHP's own advisories describe two different runtime defects; the name does not mean every PHP website was breached.

CVE-2026-109618 involves memory corruption when PHP handles an out-of-memory condition during request processing and cleanup. CVE-2026-109619 involves stale request-related global state that can survive in a worker and be used before the next request is fully initialized. Under vulnerable conditions, each can permit remote code execution (RCE).

Remote code execution means an attacker may cause a server to run code of the attacker's choosing. “Unauthenticated” means the vulnerable request path does not necessarily require a valid account first. It does not prove that an attack succeeded: a vulnerability is a defect, an exploit attempt is an attacker's request, a compromise is unauthorized access, and a confirmed breach means evidence supports that data or systems were accessed. Keep those terms separate when assessing an incident.

PHP says web-serving installations are in scope across configurations including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Risk and exploitability can differ by SAPI, worker lifecycle, version, and configuration; a framework does not remove a flaw in the runtime that executes it.

Which PHP versions are affected?

The table summarizes the initial upstream fixes released on October 21, not a promise that those point versions are the latest available forever. Verify the current PHP security advisories and your operating-system, container, appliance, or hosting vendor's package status before scheduling an upgrade.

PHP 8.1 and older no longer receive normal upstream security fixes. That does not mean every provider handles them identically: some operating-system vendors offer backported patches, and PHP published limited source backports for selected older branches. Ask for the exact package/build and advisory coverage; do not infer that an old version is patched—or vulnerable—solely from its upstream number.

What could a PHP runtime vulnerability mean for a business?

If a vulnerable path is successfully exploited, possible outcomes include server-side code execution, access to data readable by the web process, unauthorized file changes, exposure of application or customer information, theft of credentials or sessions, service disruption, or use of the server to attack other systems. These are potential impacts, not evidence that a particular site or every affected installation has experienced them.

The risk is greater when the web process can read sensitive backups or environment files, write executable code into public directories, or use credentials with broad permissions. Runtime patching reduces exposure to the specific defect, but investigation is still necessary if logs or other evidence suggest an earlier compromise.

Are Laravel, WordPress, and WooCommerce affected?

Laravel, WordPress, WooCommerce, and custom PHP applications run on PHP, so their exposure depends in part on the PHP runtime serving requests. Updating the runtime addresses the runtime flaw; it does not automatically update Laravel, plugins, themes, Composer packages, or custom code. Nor does it inspect a website for files or accounts added before the patch.

For a Laravel site, check the production PHP version and SAPI, the Laravel release's PHP compatibility, Composer dependencies, deployment configuration, workers, and logs. For WordPress or WooCommerce, confirm the PHP version used by the actual site and update WordPress core, supported plugins, themes, and extensions through a tested process. A separate CMS vulnerability or plugin issue is not the same thing as these PHP runtime CVEs.

Does PHP2Shell affect JavaScript, Node.js, Python, Java, or .NET?

No evidence in the cited advisories establishes that these PHP flaws are shared by other language runtimes or that websites written in those languages were breached because of PHP2Shell. Each ecosystem has its own security defects, supported-version policy, package advisories, and vendor updates. Assess those systems independently rather than treating different vulnerabilities as one incident.

For any technology stack, identify the exact runtime and dependency versions, use official project security advisories and vendor bulletins, check whether the installed branch is supported, and review the provider's package notes for backports. Then test and deploy relevant fixes under your normal change process.

Website protection checklist

1. Identify the production runtime. Check the PHP version and SAPI actually assigned to the public website, not only a local command-line installation or a control-panel default.
2. Confirm the fix. Ask your host or package vendor whether the exact runtime build includes the fixes for CVE-2026-109618 and CVE-2026-109619, and whether CVE-2026-115560 applies to your configuration.
3. Upgrade a supported branch. Use the newest applicable security release for your branch, or a documented vendor backport. Plan to leave an unsupported branch.
4. Test the application stack. Check framework compatibility, plugins, themes, PHP extensions, and Composer dependencies in a staging or otherwise controlled environment.
5. Back up before planned changes. Keep recent database and file backups, and verify that restoration works.
6. Deploy deliberately. Apply the runtime and application updates in a controlled release, then test sign-in, forms, checkout, API calls, uploads, scheduled tasks, and other critical workflows.
7. Review for suspicious activity. Look for unexpected PHP files, file changes, processes, requests, new accounts, authentication anomalies, and unusual outbound traffic. Compare against known-good files and logs.
8. Rotate exposed credentials when warranted. If compromise is suspected, use a clean device and rotate application, database, deployment, API, and session secrets that may have been accessible.
9. Respond to confirmed compromise. Isolate the affected service where practical, preserve evidence, restore from a verified clean backup, and investigate the original access path before returning to service. Coordinate with your provider and incident-response professionals as appropriate.
10. Keep improving. Maintain patch monitoring, least-privilege access, tested backups, logging, and a recovery plan. A web application firewall can add a layer of defense, but it does not replace the PHP fix.

For CVE-2026-115560, the published interim mitigation is to set session.upload_progress.enabled=0 in configuration that applies before request parsing and restart every relevant worker. Do not rely on an application-level ini_set() or .user.ini for this mitigation. CERT-EU notes that this issue has configuration-specific requirements; follow the current official advisory for scope and changes rather than assuming every PHP site is affected. For the first two CVEs, PHP also documents temporary mitigations, but explicitly says only an update fully fixes them. Configuration workarounds can have operational trade-offs and should be reviewed by the system administrator.

What should Hostinger and shared-hosting customers do?

Shared-hosting customers may not have root access and may be unable to change the server's PHP build themselves. In the hosting panel, check the PHP version assigned to the specific production domain. Then review official provider announcements or contact support and ask whether the assigned build includes the two October 21 fixes and what mitigation is in place for CVE-2026-115560.

Also ask whether that PHP branch is still supported by the upstream project or the provider, and whether the provider's statement refers to the server runtime, your application code, or both. A provider patch can protect the runtime path it covers; it does not prove that application files and accounts are clean. This is general guidance and does not assert that Hostinger or any other named provider is vulnerable.

Laravel-specific security checks

• Confirm the installed Laravel version supports the PHP branch you plan to use. Upgrade framework and PHP versions in a tested order when compatibility requires it.
• Review composer.json, composer.lock, and Composer security advisories. Do not run composer update blindly on production; review the dependency changes, test them, and deploy a controlled lockfile.
• Keep APP_DEBUG=false in production and avoid exposing .env, database dumps, logs, or backup archives through the public web root.
• Use restrictive file and directory permissions. Give the web process only the access it needs, and do not make application code broadly writable.
• Protect authentication, sessions, database credentials, and API keys. Rotate secrets if evidence suggests they may have been read.
• Restart PHP-FPM, queue workers, and other long-lived processes after runtime or relevant configuration changes. Confirm the new workers use the expected build and settings.
• Inspect application and server logs, unexpected file changes, scheduled tasks, and outbound connections. Compare changed files with a known-good deployment.
• Back up, stage, test, deploy, and verify key application journeys. Keep a recovery procedure for rollback and incident response.

The PHP runtime and the Laravel application are separate security layers. A runtime update does not replace framework, dependency, configuration, or incident-response maintenance.

Security maintenance mistakes to avoid

Do not leave a business website on an unsupported runtime without checking vendor support. Do not keep abandoned plugins or extensions simply because the site still loads. Do not assume an untested backup can be restored, or leave .env files and database archives web-accessible. Avoid hardcoded credentials, over-permissive filesystem access, and ignoring unexplained log events.

An SSL/TLS certificate protects data in transit between a browser and a server; it does not patch vulnerable server software, prevent every application attack, or prove a site is uncompromised. Security is a set of maintained controls, not a single certificate or one-time update.

Frequently asked questions

What is the PHP2Shell vulnerability?

PHP2Shell is the name used by the Dutch NCSC for two critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Under affected conditions, they can permit unauthenticated remote code execution.

Which PHP versions are affected?

Upstream PHP 8.5 versions before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, and 8.2 before 8.2.35 were affected by the two October 21 vulnerabilities. PHP 8.1 and older are end-of-life upstream; check separately for a vendor backport.

Which PHP versions contain the initial security fixes?

The initial fixed upstream releases were 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Use the latest applicable release and verify your provider's exact build.

Is PHP 8.1 safe after the recent PHP incident?

PHP 8.1 is end-of-life upstream and does not receive normal PHP project security updates. Some vendors may provide backports. Ask your provider to confirm the specific package and fixes, and plan to move to a supported runtime.

Is Laravel affected by PHP runtime vulnerabilities?

Laravel applications execute on PHP, so a vulnerable production runtime can affect the application. A runtime patch does not automatically patch Laravel itself or its dependencies.

Can WordPress or WooCommerce be affected?

Yes, a WordPress or WooCommerce site using an affected PHP runtime can be exposed to the runtime flaw. CMS core, plugins, themes, and hosting configuration also need separate review.

If my hosting company patched PHP, must I still update my website?

Yes. Confirm the runtime patch, then continue updating application code, plugins, themes, extensions, and Composer dependencies. A runtime patch does not inspect for prior compromise.

How do I check which PHP version my website uses?

Check the hosting control panel's version assignment for the actual domain, or ask support to confirm the version, SAPI, and build serving production traffic. A CLI php -v may report a different installation.

Can a PHP vulnerability lead to data theft?

Successful exploitation of a remote-code-execution flaw may give an attacker access to data available to the affected process. That is a possible impact, not proof that data was taken from every vulnerable site.

Does this incident mean Python, Node.js, Java, or other languages were breached?

No. The PHP advisories do not establish a shared flaw or breaches in those ecosystems. Check each language's official advisories and vendor updates independently.

What should I do if I suspect my website was compromised?

Contact your hosting provider, preserve relevant logs and evidence, restrict access where safe, and involve qualified incident responders if needed. Rotate potentially exposed secrets, restore only from a verified clean backup, and investigate how access occurred before reopening the service.

How often should a business website receive security updates?

Monitor vendor advisories continuously and apply security fixes promptly according to risk and availability. Routine maintenance should also include dependency review, backups, restore checks, log review, and compatibility testing; a fixed calendar alone is not enough for critical advisories.

Sources and review notes

This article was checked on October 26, 2026. The technical summary and initial fixed releases were verified against the PHP project security advisories, the PHP 8.5.12 release announcement, the PHP 8.4.27 announcement, the PHP 8.3.36 announcement, the PHP 8.2.35 announcement, CERT-EU advisory 2026-018, and the NCSC-NL PHP2Shell operational information. Google's security analysis provides additional response guidance. PHP's supported versions page describes branch support. Recommendations are general and do not establish the state of any individual website or hosting provider.

Need help reviewing a PHP or Laravel site?

If you need help confirming a runtime, planning a tested PHP upgrade, or maintaining a Laravel or WordPress application, see Laravel development, website maintenance, or request a website review. Coded Views can discuss the application and its maintenance needs; this is not a claim of emergency response or a guarantee that a site is secure.