{"id":355,"date":"2026-11-01T07:41:00","date_gmt":"2026-11-01T07:41:00","guid":{"rendered":"https:\/\/www.webfort.co.uk\/blog\/?p=355"},"modified":"2026-11-01T07:41:00","modified_gmt":"2026-11-01T07:41:00","slug":"php2shell-php-vulnerabilities-webfort-response","status":"publish","type":"post","link":"https:\/\/www.webfort.co.uk\/blog\/php2shell-php-vulnerabilities-webfort-response\/","title":{"rendered":"PHP2Shell: Critical PHP CVEs and How Webfort Responded"},"content":{"rendered":"<p>In October 2026, the PHP project disclosed two critical security flaws, now widely known as the <strong>PHP2Shell PHP vulnerabilities<\/strong>. They affect the language that runs a very large share of the web, including WordPress, Magento, Laravel and many bespoke business sites. Because the flaws allowed unauthenticated remote code execution, they drew urgent alerts from the UK National Cyber Security Centre (NCSC) and the US Cybersecurity and Infrastructure Security Agency (CISA).<\/p>\n<p>If you run a website on PHP, you have probably seen headlines, vendor emails or questions from clients about it. This post explains what happened, why it mattered, which versions were affected and fixed, and exactly what we did at Webfort to protect the servers we manage.<\/p>\n<p>The short version for Webfort customers: every Webfort server is patched, the incident on our status page is resolved, and you did not need to take any action for services we host. The rest of this post explains why we treated it as urgent, and what you should still check on sites and servers you manage yourself.<\/p>\n<h2 id=\"whats-in-this-post\">What&#8217;s in This Post<\/h2>\n<ul>\n<li><a href=\"#what-happened\">What happened with PHP2Shell<\/a><\/li>\n<li><a href=\"#who-found-the-php-vulnerabilities\">Who found the PHP vulnerabilities<\/a><\/li>\n<li><a href=\"#why-these-php-cves-were-dangerous\">Why these PHP CVEs were dangerous<\/a><\/li>\n<li><a href=\"#affected-versions-and-fixes\">Affected versions and fixes<\/a><\/li>\n<li><a href=\"#how-webfort-responded\">How Webfort responded<\/a><\/li>\n<li><a href=\"#what-mitigations-did-and-did-not-do\">What mitigations did and did not do<\/a><\/li>\n<li><a href=\"#what-site-owners-should-check-now\">What site owners should check now<\/a><\/li>\n<li><a href=\"#what-this-means-for-older-php-sites\">What this means for older PHP sites<\/a><\/li>\n<\/ul>\n<h2 id=\"what-happened\">What Happened With the PHP2Shell PHP Vulnerabilities<\/h2>\n<p>The PHP project published fixes for two related flaws, tracked as <strong>CVE-2026-109618<\/strong> and <strong>CVE-2026-109619<\/strong>. A CVE (Common Vulnerabilities and Exposures) number is simply a unique reference used across the security industry, so everyone can talk about the same issue without confusion.<\/p>\n<p>Together, the two flaws became known as &#8220;PHP2Shell&#8221;. The name refers to the outcome an attacker could achieve: getting from an ordinary web request to a &#8220;shell&#8221;, meaning the ability to run commands on the server.<\/p>\n<p>The key phrase in the <a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener nofollow\">official PHP advisory<\/a> is <strong>unauthenticated remote code execution<\/strong>. In plain English:<\/p>\n<ul>\n<li><strong>Unauthenticated<\/strong> means the attacker does not need a username, password or any account on the site.<\/li>\n<li><strong>Remote<\/strong> means they can attempt it over the internet, from anywhere.<\/li>\n<li><strong>Code execution<\/strong> means they can make the server run instructions of their choosing.<\/li>\n<\/ul>\n<p>The issues were rated <strong>9.2 on the CVSS v4.0 scale<\/strong>. CVSS (Common Vulnerability Scoring System) is the standard way of scoring how severe a flaw is, from 0 to 10. Anything above 9.0 counts as &#8220;critical&#8221;, the highest band.<\/p>\n<p>The UK NCSC published an <a href=\"https:\/\/www.ncsc.gov.uk\/news\/critical-security-issue-affecting-php\" target=\"_blank\" rel=\"noopener nofollow\">alert on the critical PHP security issue<\/a> urging organisations to update. When the national cyber security authority issues public guidance about a single programming language runtime, it is a clear sign the risk is broad and serious.<\/p>\n    <aside class=\"wf-blog-cta wf-blog-cta--check\">\n      <div class=\"wf-blog-cta__inner\">\n        <span class=\"wf-blog-cta__kicker\">Free Tool<\/span>\n                <p class=\"wf-blog-cta__title\">Is your website holding your business back?<\/p>\n        <p class=\"wf-blog-cta__body\">Run our free 30-second health check - no signup required. Check speed, security, and SEO issues instantly.<\/p>\n        <a class=\"wf-blog-cta__btn\" href=\"https:\/\/www.webfort.co.uk\/free-website-check\/\">\n          Check My Website          <svg class=\"wf-blog-cta__arrow\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.5\" stroke-linecap=\"round\" stroke-linejoin=\"round\" aria-hidden=\"true\"><path d=\"M5 12h14M13 6l6 6-6 6\"\/><\/svg>\n        <\/a>\n      <\/div>\n    <\/aside>\n    \n<h2 id=\"who-found-the-php-vulnerabilities\">Who Found the PHP Vulnerabilities<\/h2>\n<p>The vulnerabilities were discovered by researchers at <a href=\"https:\/\/calif.io\/php2shell\/\" target=\"_blank\" rel=\"noopener nofollow\">Calif<\/a>, who reported them to the PHP project through coordinated disclosure. Coordinated disclosure means researchers privately tell the software maintainers about a flaw and give them time to prepare fixes before the details go public. It is the responsible way to handle serious security findings.<\/p>\n<p>The PHP advisory also credits researchers from Wiz. We have not tried to split credit for each individual issue between the two teams here. The advisory is the authoritative record of who is acknowledged for what.<\/p>\n<p>The disclosure did not go entirely to plan. Details leaked before the coordinated timeline had fully played out. Security firm <a href=\"https:\/\/watchtowr.com\/intelligence\/php-cve-2026-109618-faq\/\" target=\"_blank\" rel=\"noopener nofollow\">watchTowr<\/a> was the first to publicly confirm that the leaked details were genuine. watchTowr later reported seeing exploitation attempts against its honeypot network. A honeypot is a deliberately exposed decoy system that researchers use to watch what attackers are doing in the real world.<\/p>\n<p>That sequence matters. Once details are circulating and attackers are actively trying them, the time available to patch shrinks from weeks to hours.<\/p>\n<h2 id=\"why-these-php-cves-were-dangerous\">Why These PHP CVEs Were Dangerous<\/h2>\n<p>Both flaws involve the way PHP manages memory while it handles web requests. We are deliberately keeping this explanation high level and leaving out anything that would help someone attack a server.<\/p>\n<p><strong>CVE-2026-109618<\/strong> is an out-of-memory corruption issue. When PHP runs into memory limits in certain circumstances, it can end up in an inconsistent internal state, where data in memory is no longer what PHP expects it to be.<\/p>\n<p><strong>CVE-2026-109619<\/strong> involves stale global state and a use-after-free condition. &#8220;Global state&#8221; is information PHP keeps around while it works. &#8220;Use-after-free&#8221; means the software keeps using a piece of memory after it has already been released and possibly reused for something else. This is a well-known class of bug, and in skilled hands it can give an attacker control over what the program does next.<\/p>\n<p>According to the <a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener nofollow\">PHP advisory<\/a>, every PHP installation serving web requests was in scope. PHP said the demonstrated risk was highest for Apache with mod_php, a setup where PHP runs directly inside the Apache web server process. It is still common on older or simpler hosting stacks.<\/p>\n<p>For a hosting environment, unauthenticated RCE is about as serious as it gets. If an attacker can run code on a web server, they may be able to:<\/p>\n<ul>\n<li>Read or change website files and databases<\/li>\n<li>Plant a &#8220;web shell&#8221;, a hidden script that gives them ongoing access<\/li>\n<li>Steal customer data, payment details or stored credentials<\/li>\n<li>Use the server to send spam, host phishing pages or attack other systems<\/li>\n<li>Try to move from one compromised site to others on the same machine<\/li>\n<\/ul>\n<p>Because no login is needed, strong passwords and two-factor authentication offer no protection against this type of flaw. The only real answer is to fix the underlying software.<\/p>\n<figure style=\"max-width:100%\"><img decoding=\"async\" src=\"https:\/\/images.pexels.com\/photos\/1181354\/pexels-photo-1181354.jpeg?auto=compress&#038;cs=tinysrgb&#038;fit=crop&#038;h=627&#038;w=1200\" alt=\"PHP2Shell PHP vulnerabilities and server security monitoring\" style=\"max-width:100%;height:auto\" \/><figcaption>Security monitoring and careful patching are part of running reliable web infrastructure.<\/figcaption><\/figure>\n<h2 id=\"affected-versions-and-fixes\">Affected Versions and Fixes<\/h2>\n<p>The PHP project released fixed versions for every branch it currently supports. Older branches are a more complicated picture, so we have set it out branch by branch below.<\/p>\n<table>\n<thead>\n<tr>\n<th>PHP branch<\/th>\n<th>Affected?<\/th>\n<th>Fixed release or action<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>PHP 8.5<\/td>\n<td>Yes<\/td>\n<td>Update to PHP 8.5.12<\/td>\n<\/tr>\n<tr>\n<td>PHP 8.4<\/td>\n<td>Yes<\/td>\n<td>Update to PHP 8.4.27<\/td>\n<\/tr>\n<tr>\n<td>PHP 8.3<\/td>\n<td>Yes<\/td>\n<td>Update to PHP 8.3.36<\/td>\n<\/tr>\n<tr>\n<td>PHP 8.2<\/td>\n<td>Yes<\/td>\n<td>Update to PHP 8.2.35<\/td>\n<\/tr>\n<tr>\n<td>PHP 8.1<\/td>\n<td>Yes<\/td>\n<td>No normal official release. Apply minimal source backports or vendor\/LTS packages, or upgrade.<\/td>\n<\/tr>\n<tr>\n<td>PHP 8.0<\/td>\n<td>Yes<\/td>\n<td>No normal official release. Apply minimal source backports or vendor\/LTS packages, or upgrade.<\/td>\n<\/tr>\n<tr>\n<td>PHP 7.4<\/td>\n<td>Yes<\/td>\n<td>No normal official release. Apply minimal source backports or vendor\/LTS packages, or upgrade.<\/td>\n<\/tr>\n<tr>\n<td>PHP 7.3 and older, including PHP 5<\/td>\n<td>Treat as affected<\/td>\n<td>No upstream fixed release. Requires a vendor backport or an upgrade to a supported branch.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>A &#8220;backport&#8221; means taking a fix written for a newer version and carefully adapting it so it works on an older one. It takes real engineering effort, because the surrounding code in older branches can be quite different.<\/p>\n<p>To be precise: the PHP project does not support PHP 5.6, and it has not released a fixed PHP 5.6 version. At Webfort, we backported the fixes ourselves for the older PHP versions we still run for customers, going all the way back to PHP 5.6. That covers our own environment only. It does not mean PHP 5.6 is supported upstream, or that other hosts&#8217; PHP 5.6 builds are patched.<\/p>\n<h2 id=\"how-webfort-responded\">How Webfort Responded<\/h2>\n<p>We took this incident seriously from the start. Here is what we did, in order.<\/p>\n<p><strong>We monitored the announcement.<\/strong> We followed the PHP project, NCSC and security research channels closely from the moment the issue began circulating, so we could act on reliable information rather than rumour.<\/p>\n<p><strong>We added mitigations as soon as the news broke.<\/strong> Before fixed releases were available, we put protective measures in place across our platform to reduce exposure. We explain below what those measures could and could not do.<\/p>\n<p><strong>We deployed the available fixes as soon as releases were available.<\/strong> When the PHP project published 8.2.35, 8.3.36, 8.4.27 and 8.5.12, we rolled them out across our hosts.<\/p>\n<p><strong>We applied backported fixes across older branches.<\/strong> Many customers still run older PHP versions for compatibility reasons, so we applied backported fixes to the older branches we host as well.<\/p>\n<p><strong>We completed the rollout through PHP 5.6.<\/strong> Every PHP version we offer, from current releases down to PHP 5.6, now includes the fixes.<\/p>\n<p>All Webfort servers are patched and the incident on our <a href=\"https:\/\/www.webfort.co.uk\/system-status\/\">Webfort system status page<\/a> is resolved. No customer action was required for Webfort-hosted services.<\/p>\n<p>Patching PHP closes these particular flaws, but it does not replace good maintenance of the application itself. Please keep your CMS, plugins, themes and frameworks up to date, along with any servers you manage outside Webfort.<\/p>\n<h2 id=\"what-mitigations-did-and-did-not-do\">What Mitigations Did and Did Not Do<\/h2>\n<p>There is often confusion about the difference between a mitigation and a fix, so it is worth being clear.<\/p>\n<p>A <strong>mitigation<\/strong> is a temporary protective measure. It makes an attack harder or less likely to succeed while the real fix is being prepared or rolled out. A <strong>fix<\/strong> (or patch) changes the faulty code so the flaw no longer exists.<\/p>\n<p>Our mitigations reduced exposure during the window between the news breaking and the patched and backported builds being in place. They were never a substitute for updating, and we did not treat them as one. Mitigations can be bypassed, may not cover every possible route to a flaw, and can sometimes affect legitimate traffic.<\/p>\n<p>We are deliberately not publishing the specific configuration changes or request filtering we used. Detailed mitigation steps can give attackers a roadmap of what defenders are looking for, and that helps no one.<\/p>\n<p>The PHP project itself states in its <a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener nofollow\">advisory<\/a> that updating is the only complete solution. CISA&#8217;s <a href=\"https:\/\/www.cisa.gov\/news-events\/alerts\/2026\/10\/21\/critical-vulnerabilities-php-require-immediate-patching\" target=\"_blank\" rel=\"noopener nofollow\">alert on critical PHP vulnerabilities<\/a> gives the same message: patch immediately. If you run your own servers and have only applied a workaround, please treat updating as urgent.<\/p>\n<h2 id=\"what-site-owners-should-check-now\">What Site Owners Should Check Now<\/h2>\n<p>If you host with Webfort, the PHP side is handled. If you manage other servers, look after client sites across several providers, or just want peace of mind, here is a sensible checklist.<\/p>\n<ul>\n<li><strong>Inventory your PHP versions.<\/strong> List every site and server you are responsible for and which PHP version each one uses. Agencies in particular often find forgotten staging sites or old client projects.<\/li>\n<li><strong>Confirm the running version after updates.<\/strong> Installing a patched package is not always enough. The web server or PHP worker processes may need restarting before the new version is actually serving requests. Check what is really running, not just what is installed.<\/li>\n<li><strong>Update your CMS, plugins and frameworks.<\/strong> Use this as a prompt to bring WordPress, themes, plugins and frameworks such as Laravel or Symfony up to date. Our guide on <a href=\"https:\/\/www.webfort.co.uk\/blog\/how-to-secure-your-wordpress\/\">how to secure your WordPress site<\/a> covers the basics.<\/li>\n<li><strong>Review your logs.<\/strong> Look for unusual PHP worker crashes or restarts, unexpected errors, or traffic patterns that do not fit normal use. If you are not sure where to start, our article on <a href=\"https:\/\/www.webfort.co.uk\/blog\/website-error-logs-hosting-problems\/\">using website error logs to diagnose hosting problems<\/a> explains what to look for.<\/li>\n<li><strong>Look for signs of compromise.<\/strong> Check for unfamiliar PHP files (possible web shells), recently changed files you did not edit, unexpected cron jobs (scheduled tasks), and new admin or system accounts you do not recognise.<\/li>\n<li><strong>Check your backups.<\/strong> Make sure recent backups exist, are stored away from the live server, and can actually be restored. If you ever find a compromise, a clean backup from before the incident is invaluable.<\/li>\n<li><strong>Contact your host if unsure.<\/strong> If something looks wrong, or you cannot tell whether your PHP version is patched, ask. A good host should give you a clear answer.<\/li>\n<\/ul>\n<h2 id=\"what-this-means-for-older-php-sites\">What This Means for Older PHP Sites<\/h2>\n<p>We backported fixes all the way to PHP 5.6 because we did not want any customer left exposed during a critical incident. That was the right call for this emergency. It should not be read as a sign that PHP 5.6, or any other unsupported version, is a safe long-term choice.<\/p>\n<p>PHP 5.6 reached end of life years ago. It no longer gets regular security fixes from the PHP project, and every future flaw will need someone to backport a fix, if one can be backported at all. Older versions also lack performance improvements and modern security features, and current plugins and libraries increasingly refuse to run on them.<\/p>\n<p>The same applies, to a lesser degree, to PHP 7.4, 8.0 and 8.1. They can be kept patched through backports or vendor packages, but they are no longer on the main supported track.<\/p>\n<p>If your site runs on an older PHP version, now is a good time to plan an upgrade to a supported branch. A sensible approach is:<\/p>\n<ul>\n<li>Check which PHP versions your CMS, theme, plugins or framework officially support<\/li>\n<li>Set up a staging copy of the site and test it on the newer PHP version<\/li>\n<li>Fix any compatibility warnings or errors before switching the live site<\/li>\n<li>Schedule the change for a quiet period and keep a fresh backup ready<\/li>\n<\/ul>\n<p>If you are moving an older site from another provider as part of that work, our post on <a href=\"https:\/\/www.webfort.co.uk\/blog\/cpanel-to-enhance-hosting-platform-migration\/\">our cPanel-to-Enhance hosting migration<\/a> explains how we make the move smoother.<\/p>\n    <aside class=\"wf-blog-cta wf-blog-cta--hosting\">\n      <div class=\"wf-blog-cta__inner\">\n        <span class=\"wf-blog-cta__kicker\">Webfort Hosting<\/span>\n                <p class=\"wf-blog-cta__title\">Looking for fast, reliable UK hosting?<\/p>\n        <p class=\"wf-blog-cta__body\">Our plans start from <strong>\u00a34.99\/month<\/strong> with everything included: SSL, backups, email, and 24\/7 support.<\/p>\n        <a class=\"wf-blog-cta__btn\" href=\"https:\/\/www.webfort.co.uk\/web-hosting\/\">\n          View Hosting Plans          <svg class=\"wf-blog-cta__arrow\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.5\" stroke-linecap=\"round\" stroke-linejoin=\"round\" aria-hidden=\"true\"><path d=\"M5 12h14M13 6l6 6-6 6\"\/><\/svg>\n        <\/a>\n      <\/div>\n    <\/aside>\n    \n<h2 id=\"final-thoughts\">Final Thoughts<\/h2>\n<p>PHP2Shell was a serious incident. Two critical flaws allowed unauthenticated remote code execution, details leaked early, and exploitation attempts followed. For hosting providers, the job was to reduce exposure quickly, get real fixes in place as soon as possible and keep customers informed.<\/p>\n<p>At Webfort, we added mitigations as soon as the news broke, deployed the official fixes when they were released and backported them across older branches down to PHP 5.6. Every Webfort server is now patched and the status incident is resolved.<\/p>\n<p>Security is a shared effort, though. Keep your applications and plugins updated, keep an eye on your logs and backups, and plan ahead for PHP upgrades rather than waiting for the next emergency. If you would like a hosting partner that handles this kind of work for you, take a look at our <a href=\"https:\/\/www.webfort.co.uk\/web-hosting\/\">UK web hosting plans<\/a> or get in touch with our team for a chat.<\/p>\n<h2 id=\"sources\">Sources and further reading<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.php.net\/archive\/2026.php\" target=\"_blank\" rel=\"noopener nofollow\">PHP official advisory and fixed versions<\/a><\/li>\n<li><a href=\"https:\/\/www.ncsc.gov.uk\/news\/critical-security-issue-affecting-php\" target=\"_blank\" rel=\"noopener nofollow\">UK NCSC alert: critical security issue affecting PHP<\/a><\/li>\n<li><a href=\"https:\/\/www.cisa.gov\/news-events\/alerts\/2026\/10\/21\/critical-vulnerabilities-php-require-immediate-patching\" target=\"_blank\" rel=\"noopener nofollow\">CISA alert: critical vulnerabilities in PHP require immediate patching<\/a><\/li>\n<li><a href=\"https:\/\/watchtowr.com\/intelligence\/php-cve-2026-109618-faq\/\" target=\"_blank\" rel=\"noopener nofollow\">watchTowr: independent timeline and discovery context<\/a><\/li>\n<li><a href=\"https:\/\/calif.io\/php2shell\/\" target=\"_blank\" rel=\"noopener nofollow\">Calif: PHP2Shell research disclosure<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>What the critical PHP2Shell vulnerabilities meant, who discovered them, and how Webfort mitigated and patched every hosted PHP branch through PHP 5.6.<\/p>\n","protected":false},"author":1,"featured_media":354,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,13],"tags":[130,132,128,129,131],"class_list":["post-355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","category-security","tag-cybersecurity","tag-patching","tag-php","tag-php2shell","tag-server-security"],"_links":{"self":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=355"}],"version-history":[{"count":2,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/355\/revisions"}],"predecessor-version":[{"id":358,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/355\/revisions\/358"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/media\/354"}],"wp:attachment":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}