Contents

Address the reported “php2shell” vulnerabilities with an urgent PHP update. Updating WordPress alone will not fix them. The cited report provides no basis for a universal claim that “takeovers begin at 23:15,” and examining one server’s logs cannot establish whether attacks occurred in other environments.

Key Points#

  • The report identifies CVE-2026-109618 and CVE-2026-109619 as PHP vulnerabilities that could allow unauthenticated remote code execution.
  • PHP may process request data before application code runs, so sites could be affected even without a public upload form.
  • The report states that fixes are included in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Check installed packages against advisories from PHP or your hosting provider.
  • The author observed no obvious traffic changes on one VPS, but this does not establish that the server is safe or that the vulnerabilities have not been exploited.

What Needs Fixing#

The affected component is PHP itself, which underpins WordPress, its plugins, and its themes. Even if the WordPress dashboard shows everything as up to date, the underlying PHP installation may still lack security fixes.

According to Taishi Akiyama’s October 21 report, the two vulnerabilities involve memory operations during request processing and related cleanup. The reported impact is remote code execution, not merely a memory leak. Actual exposure depends on the PHP build, configuration, and runtime environment.

Do not assume that removing upload forms solves the problem. Attackers can send requests directly, and PHP may parse their bodies before WordPress checks authentication or runs its own code.

Why the Countdown Does Not Hold Up#

According to the report, the release announcement and security advisories appeared in PHP’s website repository at 21:59 JST on October 21, earlier than the scheduled 23:00 release. Technical details were reportedly published on GitHub at 22:34. These are reported publication times and should not be treated as evidence that all download channels were updated simultaneously.

The “15-minute” claim originated in Sansec’s prediction of how quickly large-scale attacks might begin. As it was repeated, it became a precise deadline for takeovers to start. The report also states that information was circulating before the patches were released, so attackers may have begun work before publication.

AI can help analyze changes, but that alone is not evidence that working exploit code was created within 15 minutes. Understanding a flaw and reliably exploiting it across different server configurations are separate tasks. Administrators should shorten the time to update rather than schedule their response around an unsupported countdown.

Update the PHP Running Your Site#

Identify the PHP runtime handling web requests. On servers with multiple PHP installations, checking the version from the command line alone can be misleading.

1. Check your site’s PHP version and execution mode through the hosting control panel or an administrator-only diagnostic tool. 2. Compare installed packages against PHP advisories and vendor security notices. Vendors may backport fixes without adopting the upstream version number. 3. Install the applicable security updates, then reload or restart relevant services as instructed by your provider. 4. Afterward, verify the active web runtime and test logins, publishing, and any payment or upload features your site uses.

The report identifies Apache’s mod_php, where remote code execution was demonstrated, as the highest-risk configuration. PHP-FPM changes some exploitation conditions, but the report also describes paths that may work under specific application conditions. Simply “using FPM” is therefore not sufficient reason to postpone updating.

Older PHP Versions Need a Migration Plan#

For PHP 8.1 and earlier, the report states that upstream has not provided versioned security releases. It describes limited source-code backports for 7.4, 8.0, and 8.1, and notes that distributions or commercial vendors may provide fixes. A source patch offers no protection merely by existing. It must be built, deployed, and verified.

For a major upgrade, test on a copy of your site first. Update WordPress, plugins, and themes to versions compatible with the target PHP version, test critical operations, and review error logs. Older extensions and custom code may stop working after a PHP major-version change.

According to the report, security support for PHP 8.2 ends on December 31, 2026. As of October 22, little time remains to migrate. Prioritize a compatible branch with a longer support period, and check its support deadline before choosing. Treat temporary configuration changes as partial mitigations, not proof of safety.

What the VPS Logs Tell Us#

Akiyama reports examining a VPS running Apache and PHP-FPM from 21:59 to 22:55 JST, after correcting approximately 14 minutes and 40 seconds of clock skew. There were 13 probing requests to PHP-related URLs and 41 POST requests to PHP paths, with no recorded PHP-FPM crashes or out-of-memory errors.

This observation supports only the limited conclusion that the available logs showed no obvious surge during that period. It neither establishes when takeovers began nor proves that no exploitation occurred. Standard access logs generally omit request bodies, and one FPM server cannot represent other environments.

Clock skew also matters. Accurate timestamps are necessary to correlate requests, errors, and security events. Correct time synchronization, preserve relevant logs, and do not use the absence of crashes as a reason to skip patching.

Next Steps#

Use your hosting provider’s notices or OS vendor’s advisories to verify the security update status of the PHP runtime serving your production site today.

Source: https://blogs.itmedia.co.jp/agile/2026/10/php2shell_cve_2026_109618_panic.html

Contents