{"id":1217,"date":"2026-10-24T15:36:55","date_gmt":"2026-10-24T12:36:55","guid":{"rendered":"https:\/\/john-nessime.com\/blog\/?p=1217"},"modified":"2026-10-24T15:36:58","modified_gmt":"2026-10-24T12:36:58","slug":"php2shell-vulnerability-fix","status":"publish","type":"post","link":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/","title":{"rendered":"PHP2Shell Vulnerability: What Happened, How to Patch, and How to Prove It Worked"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">On the evening of 20 October 2026, php.net posted something it almost never posts: an advance warning that an emergency security release was coming the next day, for two critical bugs it would not yet describe. By the next morning the details had leaked, a proof-of-concept video was circulating, and the same message was landing in every hosting inbox: &#8220;We updated WordPress last week. We&#8217;re fine, right?&#8221;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No. And that question is the entire problem with this one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This post is a reference for the <strong>PHP2Shell vulnerability<\/strong>: what actually broke inside PHP, which servers are exposed, how to patch each common setup, how to prove the fix is really running, and which quick fixes give you false comfort. Keep it open while you work through your servers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What happened: the PHP2Shell vulnerability in plain terms<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PHP2Shell is the nickname researchers gave to two flaws in the PHP engine itself, <strong>CVE-2026-109618<\/strong> and <strong>CVE-2026-109619<\/strong>. PHP rates both 9.2 on CVSS v4.0, and both can let an unauthenticated attacker run code on a web server. The name is the researchers&#8217;, not the PHP project&#8217;s.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The dates matter here, because they decide if you were exposed and for how long:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>20 October 2026:<\/strong> PHP announced an emergency release for two critical issues. Details leaked publicly the same day.<\/li>\n\n\n\n<li><strong>21 October 2026:<\/strong> fixed releases shipped: <strong>PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35<\/strong>, with a full advisory.<\/li>\n\n\n\n<li><strong>23 October 2026:<\/strong> PHP published an informational advisory for a third, much narrower issue, CVE-2026-115560, with a one-line mitigation and no emergency release.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The flaws were reported by Wiz Research, Calif and OpenAI&#8217;s Codex Security team, who used AI models to turn long-standing weaknesses into working exploits. The affected code goes back to PHP 5.4, so effectively every PHP version from the last decade is in scope.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The two bugs, without the jargon<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>CVE-2026-109618 (out-of-memory corruption).<\/strong> PHP enforces <code>memory_limit<\/code> by aborting a request the instant it crosses the limit. If that abort lands while PHP is still building internal request data, for example while parsing a multipart file upload, the data is left half-initialized. Request cleanup then treats it as valid and works with memory that can still hold attacker-controlled leftovers.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>CVE-2026-109619 (stale global state).<\/strong> Some state owned by one request can survive after its memory has been freed, for example after a fatal error. The next request handled by the same worker can use that stale state before normal setup resets it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Here is why this is worse than the usual plugin CVE. The bug lives in the runtime, not in your code. A site whose own code is flawless is still exposed, and updating WordPress, Laravel or Drupal changes nothing, because the PHP binary underneath comes from your OS packages, your host or your container image. The researchers also demonstrated reading memory from the PHP worker process, which can contain passwords, tokens and keys belonging to other people&#8217;s requests, without ever getting a shell.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Who is exposed, and why mod_php is the worst case<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PHP&#8217;s advisory covers every installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is not equal across them, though.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>mod_php is the highest risk.<\/strong> Apache with mod_php runs request shutdown even when request startup already failed. That means simply running out of memory while PHP parses the request body is enough, and one unauthenticated request can trigger the attack before a single line of your application runs. PHP demonstrated this with default memory and input limits.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>PHP-FPM is harder to hit, not safe.<\/strong> FPM shuts the worker down when a request fails early in setup, which blocks the cleanest path. Public reporting says one of the two bugs was still shown to reach code execution under FPM, through a path that depends on something the application does. Treat &#8220;we run FPM&#8221; as &#8220;we have slightly more time,&#8221; nothing more.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you are not sure which mode you run, these two checks answer it on most Linux servers. The first lists Apache modules and shows a PHP module only if mod_php is loaded. The second lists running FPM services.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>apachectl -M | grep -i php\nsystemctl list-units --type=service | grep -i fpm<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">How to fix PHP2Shell: it depends on where your PHP comes from<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The fix is always the same in principle: run a patched PHP build. Getting there depends entirely on who builds your PHP. And there is a trap that runs in both directions. Linux distributions and long-term-support vendors received the patch early and backported it, so a <strong>patched<\/strong> package can carry an old-looking version like 8.3.6. Meanwhile, an <strong>unpatched<\/strong> process can keep running after the package updated. The version string answers neither question reliably.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Debian and Ubuntu packages<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Debian, Ubuntu and Ond\u0159ej Sur\u00fd&#8217;s widely used repository (packages.sury.org, also published as ppa:ondrej\/php) all shipped fixed packages, including builds for some end-of-life branches. Update normally, then confirm the CVE is in the package changelog instead of reading the version number. Replace 8.3 with your branch.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo apt update &amp;&amp; sudo apt upgrade\nzgrep CVE-2026-109618 \/usr\/share\/doc\/php8.3-common\/changelog.Debian.gz\nsudo systemctl restart php8.3-fpm\nsudo systemctl restart apache2<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If <code>zgrep<\/code> prints a line, the fix is in the installed package. If it prints nothing, you are either on an older distro release that needs a paid extended-support channel, or on a repository that has not shipped the fix.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">RHEL, AlmaLinux and Rocky Linux<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Same idea with RPM. Update, then search the package changelog for the CVE. If you use Remi&#8217;s parallel packages, the package name follows its own pattern (for example <code>php83-php-common<\/code>), so query that name instead.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dnf upgrade 'php*'\nrpm -q --changelog php-common | grep CVE-2026-109618\nsudo systemctl restart php-fpm httpd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">One warning from PHP&#8217;s own advisory: the volunteer-run rpms.remirepo.net repository was not expected to have updates on release day, and PHP suggested switching to distribution packages or building from source if you depend on it. Check before assuming the update landed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">cPanel, CloudLinux and LiteSpeed<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">cPanel ships its own <code>ea-php<\/code> packages through EasyApache 4, and CloudLinux ships <code>alt-php<\/code>. CloudLinux backported the fix into supported and end-of-life branches, so most of its fixed builds keep version numbers below the php.net release. CloudLinux&#8217;s published procedure is to update both package families, then restart the services that run PHP so no worker keeps the old binary loaded.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>yum clean all &amp;&amp; yum update 'alt-php*' 'ea-php*' -y\n\/scripts\/restartsrv_httpd<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If your domains run PHP-FPM through cPanel, restart the FPM service as well. On LiteSpeed, restart the web server so every <code>lsphp<\/code> process respawns from the new build. Public analysis says LiteSpeed&#8217;s LSAPI behaves more like FPM than mod_php, which buys time but does not remove the need to patch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">DirectAdmin with CustomBuild<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">CustomBuild compiles PHP from source, so you get the fix when CustomBuild offers the patched release and you rebuild. Refresh the version list, confirm the fixed release appears for each PHP version you run, then build.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cd \/usr\/local\/directadmin\/custombuild\n.\/build update\n.\/build versions\n.\/build update_versions<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Read the <code>.\/build versions<\/code> output before running the last command. If a branch you use still shows an unpatched release, apply the mitigations below for that branch until it updates. Compiling takes a while on small servers, so plan for it rather than starting it at peak traffic.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Docker and container images<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A container never patches itself. If your image is built <code>FROM<\/code> an official <code>php<\/code> tag, rebuild with a fresh pull of the base image and redeploy. If your Dockerfile pins the base by digest, the digest has to change or nothing happens.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>docker compose build --pull\ndocker compose up -d<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then run <code>php -v<\/code> inside the running container, not on the host, to confirm the version the app actually uses.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Managed hosting versus unmanaged VPS<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">On managed hosting, the host owns the PHP runtime, and several large hosts announced they had patched their fleets. Your job there is to get written confirmation, not to assume. On an unmanaged VPS from Contabo, Interserver or any similar provider, nobody patches PHP but you. That is the trade you accepted for the lower price and full root access, and this week is when it gets collected.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">End-of-life PHP: 8.1 and older<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The PHP project released no fixed builds below 8.2. Because of the severity, its security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source. Beyond that, your options are a distribution or vendor that backports (Ubuntu&#8217;s own PHP 8.1 on 22.04, the Sur\u00fd repository, Freexian ELTS for older Debian, CloudLinux and TuxCare, HeroDevs), or upgrading. Note that PHP 8.2 itself reaches end of life on 31 December 2026, so if you are touching an 8.2 server now, plan the next upgrade at the same time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Prove the patch is actually running<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is the failure mode that will bite most people. The package manager says &#8220;upgraded,&#8221; the ticket gets closed, and the old PHP code keeps serving traffic because the processes that loaded it were never restarted. Linux happily keeps running a binary whose file has been replaced on disk.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Confirm the fix is in the package<\/strong> with the changelog check above, not the version string.<\/li>\n\n\n\n<li><strong>Restart everything that runs PHP:<\/strong> every FPM pool, Apache (for mod_php), LiteSpeed, and any long-running PHP workers such as queue consumers managed by Supervisor or systemd.<\/li>\n\n\n\n<li><strong>Check the restart time is after the upgrade.<\/strong> <code>systemctl status php8.3-fpm<\/code> shows when the service started. If that is earlier than your package install, it is still running old code.<\/li>\n\n\n\n<li><strong>Ask the system what still needs a restart.<\/strong> On Debian and Ubuntu, <code>sudo needrestart -r l<\/code> lists services still using outdated files, without restarting anything.<\/li>\n\n\n\n<li><strong>Check the right binary.<\/strong> <code>php -v<\/code> on the command line reports the CLI build, which can differ from the FPM build serving your site. On Debian and Ubuntu, <code>php-fpm8.3 -v<\/code> asks the FPM binary directly.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">Mitigations if you cannot patch today, and what they don&#8217;t do<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">PHP is blunt about this: only an update is a complete fix. The settings below reduce exposure to the specific attack paths it has confirmed. They do not make a server safe, and some of them have real costs. Use them to buy hours, not weeks.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Set them where applications cannot override them: <code>php_admin_value<\/code> or <code>php_admin_flag<\/code> in the FPM pool, or the Apache configuration for mod_php. Do not rely on <code>ini_set()<\/code> or an FPM <code>.user.ini<\/code> file, because those apply too late in the request. Here is the FPM pool version on a Debian-style path (adjust the file and branch to yours):<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>; \/etc\/php\/8.3\/fpm\/pool.d\/www.conf\nphp_admin_value[memory_limit] = -1\nphp_admin_value[post_max_size] = 8M\nphp_admin_value[upload_max_filesize] = 6M\nphp_admin_flag[session.upload_progress.enabled] = off<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And the Apache equivalent for mod_php, inside the virtual host or a <code>Directory<\/code> block:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>php_admin_value memory_limit -1\nphp_admin_value post_max_size 8M\nphp_admin_value upload_max_filesize 6M\nphp_admin_flag session.upload_progress.enabled off<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Restart every worker afterwards. Now the reasoning behind each line, because each one protects a different path:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>memory_limit = -1<\/code><\/strong> targets CVE-2026-109618. The confirmed exploit needs a predictable per-request limit to hit, so removing the limit removes the trigger. The cost: one request can now consume all available memory. A genuine allocation failure can also still reach the vulnerable code.<\/li>\n\n\n\n<li><strong>Low <code>post_max_size<\/code><\/strong> shrinks the request bodies an attacker can use. PHP suggests 8M where uploads are not needed and 32M where they are, with <code>upload_max_filesize<\/code> kept below it.<\/li>\n\n\n\n<li><strong><code>session.upload_progress.enabled = off<\/code><\/strong> targets CVE-2026-109619. It blocks the confirmed session paths but not other variants. It does nothing at all for CVE-2026-109618.<\/li>\n\n\n\n<li><strong>On PHP 8.5 only, <code>fatal_error_backtraces = off<\/code><\/strong> blocks the confirmed fatal-backtrace path for CVE-2026-109619, and nothing else.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Because removing the memory limit opens a denial-of-service risk, PHP recommends a container or cgroup memory limit as the availability boundary, ideally one that kills only the affected worker. It specifically warns against <code>RLIMIT_AS<\/code> or <code>RLIMIT_DATA<\/code>, since those make allocations fail at the limit, which is exactly the condition the bug needs. Enforcing request-size, field-count and multipart-part limits at your reverse proxy helps too.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A web application firewall is a reasonable stopgap, not a fix. Cloudflare deployed rules before the patch shipped and reported attackers changing payloads to get around them. If your site already sits behind Cloudflare, those rules help. They do not replace the update.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The third issue: CVE-2026-115560<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Two days after the release, PHP disclosed one more possible code-execution path. It needs an unusual setup: the application sets <code>session.serialize_handler<\/code> to <code>php_binary<\/code> or <code>php_serialize<\/code> in configuration, then switches it to <code>php<\/code> at runtime with <code>ini_set()<\/code> before calling <code>session_start()<\/code>, with session upload progress still enabled. The fixed releases above do not cover it. PHP&#8217;s advice is to keep <code>session.upload_progress.enabled=0<\/code> until the next regular bugfix release. If you already set it for CVE-2026-109619, leave it in place and you are done.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">After patching: assume someone tried<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Amazon reported a honeypot hit against these flaws on 17 October, four days before disclosure, and exploitation attempts climbed fast once details were public. Most reports so far describe scanning and failed attempts rather than confirmed break-ins, but &#8220;nobody has reported it&#8221; is not evidence about your server. If you ran an unpatched, internet-facing PHP site during that window, do three things.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rotate secrets a PHP worker could have held in memory:<\/strong> database passwords, API keys, payment provider keys, SMTP credentials and, for WordPress, the salts in <code>wp-config.php<\/code> (which logs every user out, so warn people first).<\/li>\n\n\n\n<li><strong>Read your logs for the patterns researchers flagged:<\/strong> unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses, oddly large <code>PHPSESSID<\/code> cookies in responses, and PHP workers restarting with no explanation.<\/li>\n\n\n\n<li><strong>Look for anything new and executable<\/strong> in your web roots and upload directories, especially PHP files that no deploy put there.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Troubleshooting<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>&#8220;<code>php -v<\/code> still shows the old version.&#8221;<\/strong> Either it is a distro backport (check the changelog for the CVE), or you are looking at the CLI binary while a different build serves the site. Check the FPM binary directly and the container, not the host.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>&#8220;The site throws 500 errors after the update.&#8221;<\/strong> The fix changes how PHP handles running out of memory. Crossing <code>memory_limit<\/code> now raises a soft error at a safe point, and a second, higher threshold ends the process outright, without running shutdown handlers. A plugin or import job that used to squeak by can now fail differently. Check the error log, then review <code>memory_limit<\/code> and <code>post_max_size<\/code> against what the application genuinely needs.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>&#8220;Cleanup or logging code stopped running on big jobs.&#8221;<\/strong> Same cause. If anything important lives in a shutdown function, it will not run when the hard limit is hit. Fix the memory usage rather than raising limits blindly.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>&#8220;The package manager says there is nothing to update.&#8221;<\/strong> You are probably on a repository that has not shipped the fix, an end-of-life distro release, or an end-of-life PHP branch with no vendor backport. That is a migration problem, not a patching problem.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>&#8220;I set the mitigation but the old value still shows.&#8221;<\/strong> Look for overrides in other pool files, per-directory configuration or application code, and make sure you used the admin variants and restarted the workers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Common mistakes<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Updating WordPress, plugins or the framework and calling it done. None of that touches the PHP runtime.<\/li>\n\n\n\n<li>Trusting the version number in either direction, and declaring a backported package &#8220;vulnerable&#8221; or a stale process &#8220;patched.&#8221;<\/li>\n\n\n\n<li>Upgrading the package and never restarting FPM, Apache or long-running workers.<\/li>\n\n\n\n<li>Treating <code>session.upload_progress.enabled=0<\/code> as the fix. It was circulated as a workaround before the release and only covers part of one CVE.<\/li>\n\n\n\n<li>Setting mitigations with <code>ini_set()<\/code>, <code>.htaccess<\/code> overrides that apps can change, or <code>.user.ini<\/code>, which take effect too late.<\/li>\n\n\n\n<li>Leaving <code>memory_limit=-1<\/code> in place long after patching, with no cgroup boundary behind it.<\/li>\n\n\n\n<li>Forgetting the boxes nobody owns: the staging server, the old client site on PHP 7.4, the forgotten container in a side project.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Best practices<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep an inventory of every PHP install, its source (distro, panel, container, source build) and its branch. This week shows why.<\/li>\n\n\n\n<li>Verify fixes by CVE in the package changelog, and verify the running process by start time.<\/li>\n\n\n\n<li>Patch mod_php servers first, then public FPM sites, then internal tools.<\/li>\n\n\n\n<li>Once patched, restore a sane <code>memory_limit<\/code>, but keep session upload progress off until PHP&#8217;s next regular release covers CVE-2026-115560.<\/li>\n\n\n\n<li>Move servers off mod_php to PHP-FPM where you can. It would not have saved you here, but it narrowed the easiest path.<\/li>\n\n\n\n<li>Stay on a supported PHP branch, or pay for a vendor that backports. An unsupported branch turns every emergency into a migration.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the PHP2Shell vulnerability?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It is the nickname for two memory-safety flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. They can allow unauthenticated remote code execution on servers that run PHP for web requests.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Which PHP versions fix PHP2Shell?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 from php.net. Distribution and vendor packages may carry the fix under different, older-looking version numbers, so check the package changelog for the CVE.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is my WordPress site affected?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If it runs on an unpatched PHP build, yes, regardless of how up to date WordPress and its plugins are. The flaw is in PHP itself, so the fix comes from your server, host or container image.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is disabling session.upload_progress enough?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">No. It blocks the confirmed session paths for one of the two bugs and covers the narrow third issue, CVE-2026-115560. It does nothing for CVE-2026-109618. Only an update is a complete fix.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">I&#8217;m on PHP 7.4 or 8.1. What now?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">php.net has no release for you, but PHP published source backports for 7.4, 8.0 and 8.1, and several vendors and distributions shipped backported packages. Use one of those immediately, then plan the upgrade to a supported branch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do I need to restart anything after updating PHP?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Yes. Restart every PHP-FPM pool, Apache if you use mod_php, LiteSpeed, and long-running PHP workers. Until they restart, they keep running the vulnerable code already loaded in memory.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should I rotate passwords and keys?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If an internet-facing server ran an unpatched build after details went public, it is a sensible precaution. Researchers showed worker memory could be read remotely, and that memory can hold credentials from other requests.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The PHP2Shell vulnerability lives below your application, so the only real fix is a patched PHP build that is actually running. Everything else in this post is either a way to get there or a way to buy time. If you remember one thing, make it this: verify the fix by CVE in the package, and verify the process by its restart time. The version string will mislead you in both directions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Need help patching PHP2Shell across your servers?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If you have more PHP servers than certainty, I can help you close this out properly:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Inventory every PHP install across your VPS, cPanel, DirectAdmin and container hosts, with branch and package source.<\/li>\n\n\n\n<li>Patch each one through the right channel and prove the fix by CVE and process restart time.<\/li>\n\n\n\n<li>Apply and later roll back the interim mitigations safely, with a memory boundary in place.<\/li>\n\n\n\n<li>Rebuild and redeploy PHP container images, including pinned-digest pipelines.<\/li>\n\n\n\n<li>Review logs for the published indicators and plan secret rotation without breaking production.<\/li>\n\n\n\n<li>Plan the move off end-of-life PHP branches and off mod_php.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Send me the output of <code>php -v<\/code>, your package changelog check, and how PHP runs on the server (FPM, mod_php or LiteSpeed), and I&#8217;ll tell you where you stand.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.upwork.com\/freelancers\/~01f15a912ad84a6620\" target=\"_blank\" rel=\"noreferrer noopener\">Work with me on Upwork<\/a><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>PHP2Shell is a pair of critical flaws inside PHP itself, so updating WordPress or your framework fixes nothing. Here is what broke, who is exposed, how to patch every common setup, and how to prove the fix is actually running.<\/p>\n","protected":false},"author":1,"featured_media":1219,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,63,31,30,28],"tags":[71,1525,1524,375,974,1520,1521,373,8,416,302,1523,47,374,1519,1522,261,139,970,607,36],"class_list":["post-1217","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-system-administration","category-troubleshooting","category-web-security","category-wordpress","tag-cloudflare","tag-cloudlinux","tag-cpanel","tag-custombuild","tag-cve-management","tag-cve-2026-109618","tag-cve-2026-109619","tag-directadmin","tag-docker","tag-incident-response","tag-mod_php","tag-patch-management","tag-php","tag-php-fpm","tag-php2shell","tag-remote-code-execution","tag-secrets-management","tag-server-hardening","tag-vulnerability-management","tag-web-application-firewall","tag-wordpress-security","entry","has-media"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.7 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>PHP2Shell Vulnerability: What Happened and How to Fix It<\/title>\n<meta name=\"description\" content=\"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"PHP2Shell Vulnerability: What Happened and How to Fix It\" \/>\n<meta property=\"og:description\" content=\"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/\" \/>\n<meta property=\"og:site_name\" content=\"John Nessime\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/J.Nessime\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/J.Nessime\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-24T12:36:55+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-24T12:36:58+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1536\" \/>\n\t<meta property=\"og:image:height\" content=\"1024\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"John Nessime\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"John Nessime\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/\"},\"author\":{\"name\":\"John Nessime\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"headline\":\"PHP2Shell Vulnerability: What Happened, How to Patch, and How to Prove It Worked\",\"datePublished\":\"2026-10-24T12:36:55+00:00\",\"dateModified\":\"2026-10-24T12:36:58+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/\"},\"wordCount\":3087,\"publisher\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"image\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/php2shell-vulnerability-featured-image.png\",\"keywords\":[\"Cloudflare\",\"CloudLinux\",\"cPanel\",\"CustomBuild\",\"CVE Management\",\"CVE-2026-109618\",\"CVE-2026-109619\",\"DirectAdmin\",\"Docker\",\"Incident Response\",\"mod_php\",\"Patch Management\",\"PHP\",\"PHP-FPM\",\"PHP2Shell\",\"Remote Code Execution\",\"Secrets Management\",\"Server Hardening\",\"Vulnerability Management\",\"Web Application Firewall\",\"WordPress Security\"],\"articleSection\":[\"Linux\",\"System Administration\",\"Troubleshooting\",\"Web Security\",\"WordPress\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/\",\"name\":\"PHP2Shell Vulnerability: What Happened and How to Fix It\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/php2shell-vulnerability-featured-image.png\",\"datePublished\":\"2026-10-24T12:36:55+00:00\",\"dateModified\":\"2026-10-24T12:36:58+00:00\",\"description\":\"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#primaryimage\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/php2shell-vulnerability-featured-image.png\",\"contentUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/10\\\/php2shell-vulnerability-featured-image.png\",\"width\":1536,\"height\":1024,\"caption\":\"PHP2Shell vulnerability illustration showing an unpatched PHP runtime, security risks, and the patch-and-restart process across PHP-FPM, mod_php, and containers.\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/system-administration\\\/php2shell-vulnerability-fix\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"PHP2Shell Vulnerability: What Happened, How to Patch, and How to Prove It Worked\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/\",\"name\":\"John Nessime\",\"description\":\"Cloud, DevOps, Data &amp; AI \u2014 Built, Tested, Explained\",\"publisher\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\",\"name\":\"John Nessime\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"contentUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"width\":512,\"height\":512,\"caption\":\"John Nessime\"},\"logo\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\"},\"description\":\"AWS Certified Solutions Architect helping businesses build reliable cloud, data, reporting, and automation solutions. I help startups, agencies, and growing businesses replace manual processes and disconnected data with practical AWS architectures, clean data pipelines, useful dashboards, and maintainable automation.\",\"sameAs\":[\"https:\\\/\\\/john-nessime.com\\\/blog\",\"https:\\\/\\\/www.facebook.com\\\/J.Nessime\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/john-m-nessime\"],\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/author\\\/johnnessime\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"PHP2Shell Vulnerability: What Happened and How to Fix It","description":"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/","og_locale":"en_US","og_type":"article","og_title":"PHP2Shell Vulnerability: What Happened and How to Fix It","og_description":"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.","og_url":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/","og_site_name":"John Nessime","article_publisher":"https:\/\/www.facebook.com\/J.Nessime","article_author":"https:\/\/www.facebook.com\/J.Nessime","article_published_time":"2026-10-24T12:36:55+00:00","article_modified_time":"2026-10-24T12:36:58+00:00","og_image":[{"width":1536,"height":1024,"url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png","type":"image\/png"}],"author":"John Nessime","twitter_card":"summary_large_image","twitter_misc":{"Written by":"John Nessime","Est. reading time":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#article","isPartOf":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/"},"author":{"name":"John Nessime","@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"headline":"PHP2Shell Vulnerability: What Happened, How to Patch, and How to Prove It Worked","datePublished":"2026-10-24T12:36:55+00:00","dateModified":"2026-10-24T12:36:58+00:00","mainEntityOfPage":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/"},"wordCount":3087,"publisher":{"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"image":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#primaryimage"},"thumbnailUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png","keywords":["Cloudflare","CloudLinux","cPanel","CustomBuild","CVE Management","CVE-2026-109618","CVE-2026-109619","DirectAdmin","Docker","Incident Response","mod_php","Patch Management","PHP","PHP-FPM","PHP2Shell","Remote Code Execution","Secrets Management","Server Hardening","Vulnerability Management","Web Application Firewall","WordPress Security"],"articleSection":["Linux","System Administration","Troubleshooting","Web Security","WordPress"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/","url":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/","name":"PHP2Shell Vulnerability: What Happened and How to Fix It","isPartOf":{"@id":"https:\/\/john-nessime.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#primaryimage"},"image":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#primaryimage"},"thumbnailUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png","datePublished":"2026-10-24T12:36:55+00:00","dateModified":"2026-10-24T12:36:58+00:00","description":"PHP2Shell vulnerability explained: what broke inside PHP, who is exposed, how to patch every common setup, and how to prove the fix is really running.","breadcrumb":{"@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#primaryimage","url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png","contentUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/10\/php2shell-vulnerability-featured-image.png","width":1536,"height":1024,"caption":"PHP2Shell vulnerability illustration showing an unpatched PHP runtime, security risks, and the patch-and-restart process across PHP-FPM, mod_php, and containers."},{"@type":"BreadcrumbList","@id":"https:\/\/john-nessime.com\/blog\/system-administration\/php2shell-vulnerability-fix\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/john-nessime.com\/blog\/"},{"@type":"ListItem","position":2,"name":"PHP2Shell Vulnerability: What Happened, How to Patch, and How to Prove It Worked"}]},{"@type":"WebSite","@id":"https:\/\/john-nessime.com\/blog\/#website","url":"https:\/\/john-nessime.com\/blog\/","name":"John Nessime","description":"Cloud, DevOps, Data &amp; AI \u2014 Built, Tested, Explained","publisher":{"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/john-nessime.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105","name":"John Nessime","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","contentUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","width":512,"height":512,"caption":"John Nessime"},"logo":{"@id":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png"},"description":"AWS Certified Solutions Architect helping businesses build reliable cloud, data, reporting, and automation solutions. I help startups, agencies, and growing businesses replace manual processes and disconnected data with practical AWS architectures, clean data pipelines, useful dashboards, and maintainable automation.","sameAs":["https:\/\/john-nessime.com\/blog","https:\/\/www.facebook.com\/J.Nessime","https:\/\/www.linkedin.com\/in\/john-m-nessime"],"url":"https:\/\/john-nessime.com\/blog\/author\/johnnessime\/"}]}},"_links":{"self":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/1217","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/comments?post=1217"}],"version-history":[{"count":1,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/1217\/revisions"}],"predecessor-version":[{"id":1218,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/1217\/revisions\/1218"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/media\/1219"}],"wp:attachment":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/media?parent=1217"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/categories?post=1217"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/tags?post=1217"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}