<p>Two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, became public in October 2026. We patched our hosting environments within the hour of the fixes becoming available. Our servers now run only the latest releases of PHP 8.3 and 8.4.</p>   <h2 class="wp-block-heading">What happened</h2>   <figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><th>Date (2026)</th><th>Event</th></tr><tr><td>Oct 17</td><td>Amazon's threat intelligence team records an attempt to exploit the flaws, four days before public disclosure.</td></tr><tr><td>Oct 20</td><td>The PHP Project announces two critical vulnerabilities and schedules fixes for the next day. Technical details leak ahead of the planned release.</td></tr><tr><td>Oct 21, 10:00 AM ET</td><td>PHP releases fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.</td></tr><tr><td>Oct 21</td><td>Security firms report exploitation attempts against unpatched servers. Cloudflare deploys firewall rules for all its customers.</td></tr><tr><td>Oct 21</td><td>We update and patch our hosting environments within the hour of the fixes becoming available.</td></tr></tbody></table></figure>   <h2 class="wp-block-heading">What the vulnerabilities are</h2>   <p>Both flaws are in PHP itself, the language that runs WordPress and much of the web, and both are rated critical (CVSS 9.2). One crafted request, sent without logging in, can let an attacker run their own code on the web server. That happens before the website's own code runs, so it doesn't matter how well the site is built.</p>   <ul class="wp-block-list"> <li><strong>CVE-2026-109618</strong> corrupts memory when PHP runs out of memory partway through handling a request.</li>   <li><strong>CVE-2026-109619</strong> leaves data from one request behind after its memory is released, where a later request can misuse it.</li> </ul>   <p>The flaws can also leak data from the server's memory, such as passwords and API keys. They affect nearly every PHP release back to version 5.4, and every common server setup. Settings changes reduce the risk but don't remove it. Updating PHP is the only complete fix.</p>   <figure class="wp-block-table"><table class="has-fixed-layout"><tbody><tr><th>PHP branch</th><th>Fixed in</th><th>Note</th></tr><tr><td>8.5</td><td>8.5.12</td><td></td></tr><tr><td>8.4</td><td>8.4.27</td><td></td></tr><tr><td>8.3</td><td>8.3.36</td><td></td></tr><tr><td>8.2</td><td>8.2.35</td><td>Security support ends December 31, 2026</td></tr><tr><td>8.1 and older</td><td>No official release</td><td>No longer supported. PHP published source patches for 7.4, 8.0 and 8.1; otherwise rely on a vendor backport or upgrade</td></tr></tbody></table></figure>   <h2 class="wp-block-heading">How we responded</h2>   <p>We patched every server in our hosting environments within the hour of the fixes becoming available.</p>   <ul class="wp-block-list"> <li><strong>Same-day awareness.</strong> We were tracking these vulnerabilities from the day the CVEs were published, before the fixes shipped.</li>   <li><strong>Patched within the hour.</strong> When the PHP Project published its fixes, and as patched packages reached the software repositories our servers use, we updated our hosting environments within the hour.</li>   <li><strong>Current PHP only.</strong> Our hosting environments run only the latest releases of PHP 8.3 and PHP 8.4, and we prefer PHP 8.4. We've removed every older version.</li>   <li><strong>Ongoing monitoring.</strong> We're continuing to watch for new information and attack activity, and we'll act on anything that affects the sites we host.</li> </ul>   <h2 class="wp-block-heading">What this means for you</h2>   <p><strong>If we host your site, you don't need to do anything.</strong> PHP runs on our servers, and we've already updated it. If a security scanner or platform is still flagging your site, send us the report and we'll review it.</p>   <p><strong>If your site is hosted elsewhere, ask your host which PHP version it runs.</strong> It should be one of the fixed versions in the table above, or a version your host confirms carries the patch. You can often see the version in your WordPress dashboard under Tools » Site Health » Info » Server.</p>   <p><strong>If your site runs PHP 8.2, plan an upgrade.</strong> 8.2.35 is patched, but PHP 8.2 stops receiving security fixes after December 31, 2026. Moving to PHP 8.4 before then keeps your site on a supported version.</p>   <p>Questions about your site? Contact your account executive.</p>   <h2 class="wp-block-heading">Sources</h2>   <ul class="wp-block-list"> <li><a href="https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/" target="_blank" rel="noopener">Help Net Security: PHP2Shell critical PHP vulnerabilities patched</a></li>   <li><a href="https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/" target="_blank" rel="noopener">SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors</a></li>   <li><a href="https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/" target="_blank" rel="noopener">watchTowr: PHP2Shell remote code execution</a></li>   <li><a href="https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html" target="_blank" rel="noopener">The Hacker News: someone tried to exploit PHP2Shell 4 days before disclosure</a></li>   <li><a href="https://github.com/NCSC-NL/php2shell" target="_blank" rel="noopener">NCSC-NL: PHP2Shell operational information</a></li> </ul>

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What Happened and How We Responded

< back to blog