Home / Critical PHP vulnerabilities

Security alert · October 2026

Critical PHP vulnerabilities allow unauthenticated remote code execution

· Last updated

PHP has released emergency security updates for two critical vulnerabilities affecting PHP installations that serve web requests. Organizations running PHP should identify affected systems and update them immediately.

  • Severity Critical CVSS 9.2
  • CVE CVE-2026-109618 CVE-2026-109619
  • Action Update immediately No complete workaround
  • Affected PHP serving the web FPM, mod_php, cgi, and others
Check Your PHP Exposure Read the Technical Details

What should I do right now?

Work through the systems that answer HTTP requests. A PHP version reported by a laptop or a staging server can be different from production.

  1. Determine which PHP version your public-facing systems use.
  2. Determine how PHP is being served: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed, or FrankenPHP.
  3. Update to the patched release for that branch, or to the vendor package that contains the backported fix.
  4. Restart or redeploy the affected PHP workers and services, as the update requires.
  5. Validate that the patched build is the one actually running in production.
  6. If the system was exposed, or something looks wrong, decide whether incident investigation is warranted. Patching alone does not answer that.

Patched upstream versions

Branch Install
PHP 8.5 8.5.12 or later
PHP 8.4 8.4.27 or later
PHP 8.3 8.3.36 or later
PHP 8.2 8.2.35 or later

PHP 8.2.35 fixes these two issues. PHP also says 8.2 security support ends on December 31, 2026, so an upgrade to a newer supported branch should already be planned.

PHP 8.1 and older no longer receive normal security updates from the PHP project. Some Linux distributions and LTS vendors ship backported fixes. The PHP security team also published minimal source backports for PHP 7.4, 8.0, and 8.1 for people building from source or without an LTS vendor. If you are not building from those backports, confirm the vendor advisory or move to a supported release.

Version numbers alone can be misleading when operating-system vendors backport security fixes. Verify the package and security advisory from the vendor managing your PHP distribution.

Why this vulnerability matters

Exploitation can result in code running on a vulnerable server without a username or password. What that means depends on the server. A public website, a membership application, a store, or an internal tool exposed to the internet can each put different things in reach: the application, credentials stored on that host, a database, customer information, or other systems that trust the server.

PHP’s position is direct. Installations that serve web requests are at risk, there is no complete mitigation short of the update, and the risk is highest where Apache runs PHP as mod_php. A temporary configuration change can reduce some attack paths. It does not make the installation safe.

You should check your environment if...

  • Your website or web application runs PHP.
  • You host WordPress, WooCommerce, Drupal, Laravel, Magento or Adobe Commerce, or another PHP application.
  • PHP-FPM sits behind nginx or Apache.
  • Apache runs PHP through mod_php.
  • You operate php-cgi, LiteSpeed, or FrankenPHP.
  • A hosting provider manages PHP and you do not know whether the October 21 update is in the running package.
  • An MSP or developer manages the server and has not confirmed the deployed security update.
  • You are running PHP 8.1 or an older release.

Using WordPress or another PHP application does not mean the application itself contains these CVEs. The issue is the PHP runtime underneath it. Updating the application is not the same task as updating PHP.

How do I know if we're vulnerable?

A domain name is not enough to answer that, and neither is the name of the application. Exposure depends on the pieces below. Several of them are invisible from the public website.

  • PHP version and package
  • Vendor or LTS backports
  • Web-server architecture
  • Whether PHP serves web requests
  • Deployment configuration
  • Whether the patched build is actually running

A control panel can show one version while an old PHP-FPM pool still answers traffic. A distribution can ship a fix inside a package whose version number does not match 8.3.36 or 8.2.35. The check is the package advisory plus the process that is running.

Not sure what your environment is running? Mojave can help verify it.

Request a PHP Exposure Review

Have Mojave review your exposure

If your organization uses PHP and you are unsure whether affected systems have been patched, send the basic environment details below. Do not send passwords, source code, customer records, or other sensitive information.

The review is about this PHP issue. It is a way to start the conversation. It is not automatically Mojave’s broader Security Baseline & Resilience Assessment, and not every inquiry needs the same follow-up. After the environment is clear, the useful next step may be limited remediation support, a vulnerability review, incident investigation, a broader assessment, or ongoing advisory. Your existing IT provider can stay in the work.

A PHP exposure review can help determine:

  • Whether PHP is present in the environment you are asking about
  • What PHP version is running
  • How PHP is being served
  • Whether the relevant systems are internet-facing
  • Whether the installed packages contain the security fixes
  • Whether a vendor or LTS backport applies
  • Whether the upgrade has actually been completed in production
  • What to remediate first
  • Whether there are indicators that further incident investigation is warranted

Mojave cannot determine compromise from a domain name alone, and completing this review does not guarantee the environment is secure.

Use your company address.

We use this information only to respond about this PHP issue. Submitting the form does not book a meeting or start an assessment.

Independent cybersecurity help when the issue is outside day-to-day IT

Mojave is an independent cybersecurity firm that works alongside internal IT teams and managed service providers. We assess security issues, determine what matters, and help organizations establish a clear remediation path.

Your existing IT provider can remain involved. This is not a request to replace the MSP, the host, or the developer who runs the server. They often have the access the review needs. Mojave’s role is to sort the PHP exposure, say what is confirmed, and name the next action.

Technical details

The summary below follows the PHP Security Team advisory of October 21, 2026, and the GitHub security advisories PHP linked from it. It is not an exploit write-up. PHP rated both issues CVSS v4.0 9.2 (Critical). CISA’s alert refers to the pair as php2shell.

CVE-2026-109618

Remote code execution via out-of-memory corruption. GHSA-w8hw-w9fx-j79w.

PHP uses longjmp() when a request hits an out-of-memory condition, so it can leave the current context before request data is fully initialized. If an allocation fails in that window, request cleanup can treat the incomplete data as valid. The GitHub advisory describes this as a use-after-free during exception and memory-limit handling. PHP says the failed allocation does not have to be the same allocation as the uninitialized data.

CVE-2026-109619

Remote code execution involving stale global state. GHSA-6wmf-4rv5-p3rp.

A PHP worker keeps global state — error, session, object, and extension state — that must be reset before the memory for a request is released. PHP says some of that state can still point at freed request memory. A later request on the same worker may use it before normal initialization replaces it. A fatal error, including memory exhaustion, can skip the reset. A warning during shutdown can also refill error state after it was cleared.

PHP says every installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The demonstrated case PHP highlights is mod_php, where one unauthenticated request can trigger the issue before application code runs.

October 23 update · a separate issue

On October 23, PHP published an informational note about session upload progress, tracked as CVE-2026-115560. It is not CVE-2026-109618 or CVE-2026-109619, and the October 21 releases do not fix it.

PHP says it can occur only in an unusual combination: the application sets session.serialize_handler to php_binary or php_serialize, then switches it to php with ini_set() before session_start(), while session upload progress is still enabled. Applications that never change the serialize handler at runtime can leave the feature enabled. PHP is handling the fix in the normal release cycle rather than an emergency release.

Until that release, PHP suggests session.upload_progress.enabled=0 in php.ini, an FPM pool, or other server configuration that applies before the request is parsed, then a restart of every worker. Do not rely on ini_set() or .user.ini for that setting. If you already applied it as a temporary measure for CVE-2026-109619, PHP says to leave it in place. It does not close the two critical vulnerabilities.

PHP’s October 23 note

Can't update immediately?

Updating is the only complete solution. PHP says there are no complete mitigations.

PHP has published temporary exposure-reduction measures for specific attack paths, but explicitly states that these do not make a vulnerable installation safe. Organizations should treat them only as temporary measures while completing the security update.

Those measures are specific to the build and the SAPI. They cover how PHP applies its memory limit, how large requests are accepted, and whether session upload progress and, on PHP 8.5, fatal-error backtraces run before a request is initialized. PHP says they block only some confirmed paths. An underlying allocation failure can still reach CVE-2026-109618, and the session setting does not cover every variant of CVE-2026-109619. Follow the advisory for the exact settings. Do not treat a shortened checklist as a patch.

Read the PHP security advisory

Questions

What are CVE-2026-109618 and CVE-2026-109619?
They are two critical vulnerabilities disclosed by the PHP Security Team on October 21, 2026. PHP says both can allow unauthenticated remote code execution on installations that serve web requests. CVE-2026-109618 is an out-of-memory handling flaw (GHSA-w8hw-w9fx-j79w). CVE-2026-109619 involves request state that can remain after its memory has been freed (GHSA-6wmf-4rv5-p3rp). The PHP security team rated each CVSS v4.0 9.2. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
How serious are the October 2026 PHP vulnerabilities?
PHP calls them critical and says there are no complete mitigations. Updating is the only complete solution. Installations that serve web requests are in scope. PHP considers the risk highest for Apache with mod_php, where a demonstrated exploit can trigger before application code runs. CISA’s alert refers to the pair as php2shell and urges organizations to patch immediately.
Can these PHP vulnerabilities be exploited remotely?
Yes. PHP says an unauthenticated remote attacker can reach the vulnerable code when PHP is serving web requests. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. A PHP build that does not serve web requests is outside the scope PHP described.
Can the attack occur without authentication?
Yes. PHP’s advisory describes unauthenticated remote code execution. For mod_php, PHP says a demonstrated exploit can trigger before any application code runs, so an application login page is not a barrier.
Which PHP versions fix the vulnerabilities?
PHP 8.5.12, PHP 8.4.27, PHP 8.3.36, and PHP 8.2.35, or a later release in the same branch. A Linux or LTS package can also contain the fix without showing those exact upstream version numbers. Confirm the vendor security advisory for the package that is actually running. PHP 8.6.0 RC4 includes the same fixes, and PHP says not to use that release candidate in production.
Is PHP 8.1 vulnerable?
PHP 8.1 and older no longer receive normal security updates from the PHP project. The security team published minimal source backports for PHP 7.4, 8.0, and 8.1 for people building from source or without an LTS vendor. If a distribution or LTS vendor manages the package, confirm that vendor’s advisory. Otherwise, move to a supported branch and install the patched release. PHP 8.2.35 fixes these two issues, and PHP 8.2 security support ends on December 31, 2026.
Does this affect WordPress?
These CVEs are in PHP, not in WordPress. A WordPress site needs attention when the PHP runtime serving it is unpatched. Updating WordPress core, plugins, or themes does not replace the PHP security update. WordPress on a patched PHP package is not, by itself, exposed to CVE-2026-109618 or CVE-2026-109619.
Does this affect WooCommerce?
WooCommerce is a PHP application. It does not contain these CVEs. The question is whether the PHP version serving that store includes the October 21 fixes and whether those workers have been restarted. Updating WooCommerce is a separate maintenance task.
Does this affect Laravel?
Laravel is not the vulnerable component. A Laravel application is exposed when the PHP runtime serving it — often PHP-FPM — is an affected build. Update that PHP package, restart the workers, and confirm the version answering production requests.
Does this affect PHP-FPM?
Yes. PHP lists PHP-FPM among the installations that serve web requests and are at risk, including FPM behind nginx or Apache. After the package update, restart every FPM worker and confirm the pool is running the patched build.
Does this affect Apache mod_php?
Yes. PHP says the risk is highest for Apache with mod_php. A demonstrated exploit can trigger from an unauthenticated request before application code runs. Update PHP and restart Apache so the new module is loaded.
Does this affect nginx?
nginx itself is not the vulnerable software. If nginx passes requests to PHP-FPM, php-cgi, or another PHP SAPI, that PHP service may be affected. Patch and restart PHP. Reloading nginx alone does not update PHP.
Does this affect shared web hosting?
It can. On shared hosting you often cannot see the PHP package. Ask the provider whether the PHP build serving your account includes the October 21 fixes, which version is running, and whether workers were restarted after the update. A panel label is not enough if the old workers are still answering requests.
How can I tell which PHP version my website uses?
Ask the administrator or host for the PHP version of the website, how it is served (PHP-FPM, mod_php, php-cgi, LiteSpeed, or FrankenPHP), and which package or image was deployed. On a machine you administer, the web server’s PHP configuration is the check that matters. The command-line php binary is often a different build from the one serving the site. Do not publish a phpinfo page or other debug output on the public internet.
Is updating PHP enough?
The patched package has to be the one serving production traffic. Restart or redeploy PHP workers so older processes are gone, then confirm the running version. If a vulnerable, internet-facing service may already have handled untrusted requests, the update does not show whether anything else occurred. That question is a separate investigation. A temporary configuration change is not a substitute for the update.
Has this vulnerability been exploited in the wild?
On October 20, 2026, the PHP security team said it would publish the fixes earlier if details became public or if it saw evidence of active exploitation. The updates shipped on the announced schedule, October 21. CISA’s alert, revised October 23, 2026, says CISA had not observed successful exploitation in the wild as of publication, and it still tells organizations to patch immediately. CERT-EU reported that technical details and early proof-of-concept code were being discussed publicly, which raises the chance of exploitation attempts. That is not a confirmed list of compromised organizations. This page does not claim that exploitation is widespread, or that it is not occurring, beyond those statements.
Can Mojave check whether my organization is exposed?
Mojave can help determine whether PHP is present, which version and package are in use, how PHP is served, whether the systems are internet-facing, whether the October 21 fixes or a vendor backport are actually running, and what to do next. That review does not prove a server was or was not compromised, and it is not automatically a full security assessment. Send the environment details in the form on this page. Do not include passwords, source code, or customer records. Your existing IT provider can remain involved.

Sources

Primary source: PHP Security Team, October 21, 2026, with the October 23 informational note on CVE-2026-115560. Last updated October 23, 2026.