{"answer_id": "Q01-chatgpt-1", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:15:48.327Z", "answer_text": "**Fix PHP2Shell by updating PHP itself, then restarting the services running it.** Updating WordPress, plugins, or application code alone does not fix it. PHP2Shell refers to critical PHP vulnerabilities **CVE-2026-109618 and CVE-2026-109619**. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Install a patched PHP version\nPHP released these fixes on **October 21, 2026**: ([php.net](https://www.php.net/))\n\n| Your PHP branch | Minimum patched version |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nUse your operating system’s or hosting provider’s security updates. Some vendors backport fixes without changing the upstream version number, so check their advisory for **both CVEs**. For PHP 8.1 or older, upgrade to a supported branch or obtain a confirmed vendor backport. ([php.net](https://www.php.net/))\n\n### 2. Restart and verify\nAfter installing the update, **restart the relevant PHP-FPM services, Apache if it runs PHP, and long-running PHP workers**. Update every affected runtime—not just one site or server—and confirm the running deployments use the patched build. ([php2shell.com](https://www.php2shell.com/))\n\nFor managed/shared hosting, ask support:\n> “Have you patched CVE-2026-109618 and CVE-2026-109619 on every PHP runtime serving my sites, and restarted the affected workers?”\n\n### 3. If you cannot patch immediately\n**Configuration changes are only partial mitigations.** PHP recommends disabling `session.upload_progress.enabled` in server-level configuration and restarting workers; on PHP 8.5, also disable `fatal_error_backtraces`. These block specific attack paths, not the whole vulnerability family. Don’t rely on application-level `ini_set()` changes. ([php.net](https://www.php.net/))\n\nAvoid blindly applying advice to set `memory_limit=-1`: it is not a complete fix and introduces memory-exhaustion and availability risks without appropriate operating-system containment. ([php2shell.com](https://www.php2shell.com/))\n\n**What OS or hosting provider, PHP version, and web server are you using—for example, Ubuntu with Nginx/PHP-FPM, Docker, or cPanel?** With those details, I can give you the appropriate update and restart commands.", "cited_urls": ["https://www.php2shell.com/", "https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-chatgpt-2", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Fix PHP2Shell by updating PHP itself, then restarting the services that run it.** Updating WordPress, plugins, or application code alone does not fix these vulnerabilities. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Install a patched PHP release\nPHP’s October 21, 2026 security update fixes **CVE-2026-109618 and CVE-2026-109619**. Use at least the following version for your branch: ([php.net](https://www.php.net/))\n\n| PHP branch | First fixed version |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nThese are upstream versions. If your operating-system vendor backports security fixes, check its advisory for the patched package build instead. For PHP 8.1 or older, upgrade to a supported branch or obtain a confirmed vendor fix. ([php.net](https://www.php.net/archive/2026.php))\n\n### 2. Update every deployment and restart\n- **Managed/shared hosting:** Ask your provider to confirm that the PHP runtime serving your site is patched for **both CVEs** and its workers have been restarted.\n- **Your own server:** Update all affected PHP installations, then restart PHP-FPM, Apache if it runs PHP, and any long-running PHP workers. ([php2shell.com](https://www.php2shell.com/))\n- **Containers:** Rebuild using patched PHP/base images and redeploy—not just update the host. ([access.redhat.com](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013))\n\n### 3. If you cannot patch immediately\n**There is no complete configuration-only workaround.** Temporary measures include disabling `session.upload_progress.enabled` in server-level configuration and restarting every worker; PHP 8.5 also has a `fatal_error_backtraces` setting that can be disabled. These block specific attack paths, not the entire vulnerability family. A WAF is not a substitute for patching. ([php.net](https://www.php.net/archive/2026.php))\n\n**What hosting provider or operating system are you using, and which PHP version?** Also mention whether you use Docker, Apache, or Nginx/PHP-FPM, and I can give you the appropriate update and verification commands.", "cited_urls": ["https://www.php2shell.com/", "https://www.php.net/", "https://www.php.net/archive/2026.php", "https://access.redhat.com/security/vulnerabilities/RHSB-2026-013"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-chatgpt-3", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Fix PHP2Shell by updating PHP itself, then restarting every service that runs it.** Updating WordPress, plugins, or application code alone does not fix it. PHP2Shell covers two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Install a patched PHP version\n\nPHP’s **October 21, 2026** security releases contain the fixes:\n\n| Your PHP branch | First fixed version |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nInstall that release or a newer patched release in your branch. Linux distributions may backport the fixes without changing the upstream version number—check your vendor’s security advisory. For PHP 8.1 or older, upgrade to a supported branch or obtain a vendor-confirmed backport. ([php.net](https://www.php.net/))\n\n### 2. Restart the affected services\n\nRestart PHP-FPM, Apache when using mod_php, and any long-running PHP workers. Apply the update to **every PHP runtime**, not just one installation. Verify that the services actually serving your sites are running the patched build. ([php2shell.com](https://www.php2shell.com/))\n\n**On shared hosting:** ask your provider to confirm that your site’s PHP runtime has fixes for **both CVEs**; merely selecting “PHP 8.3” or “PHP 8.4” is insufficient without the patched release or backport. ([php.net](https://www.php.net/))\n\n### 3. If you cannot patch immediately\n\nThere is **no complete configuration-only workaround**. One partial mitigation is to set this in the server’s PHP configuration, before request parsing, then restart all workers:\n\n```ini\nsession.upload_progress.enabled = 0\n```\n\nThis blocks confirmed session-related paths, **not all variants**. Do not rely on application-level `ini_set()` or FPM `.user.ini` for this mitigation. ([php.net](https://www.php.net/))\n\n**What OS or hosting provider, PHP version, and web-server setup are you using—for example, Ubuntu + Nginx/PHP-FPM, Apache, Docker, or cPanel?** With those details, I can give you the appropriate update and verification commands.", "cited_urls": ["https://www.php2shell.com/", "https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-claude-1", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:15:48.327Z", "answer_text": "Great news — there's a clear fix for PHP2Shell. Here's a comprehensive breakdown:\n\n---\n\n## What is PHP2Shell?\n\n\nPHP2Shell is the name for two critical PHP core Remote Code Execution (RCE) flaws: **CVE-2026-109618** and **CVE-2026-109619**.\n \nBoth vulnerabilities have a CVSS v4.0 score of **9.2**.\n\n\n- \n**CVE-2026-109618** involves RCE via out-of-memory corruption: when memory runs out mid-request, PHP can be interrupted while internal request data is only partly set up, and cleanup may then treat that broken data as valid.\n\n- \n**CVE-2026-109619** involves RCE via stale global state: internal state tied to a request can outlive its freed memory, and a later request on the same worker may use it before it is reset.\n\n\n---\n\n## ✅ The Primary Fix: Update PHP\n\n\n**You cannot fix PHP2Shell from within your application code.** If you do not manage your own server, ask your hosting provider to apply the update.\n\n\n\nUpdate to **PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35**, matching the branch you are currently using.\n\n\n**Step-by-step:**\n\n1. \nInventory every server and application that runs PHP, starting with internet-facing systems.\n\n2. \nUpdate each installation to the fixed release for its branch. Linux distributions were given the patches ahead of release, so look for updated packages from your distribution.\n\n3. \nRestart every PHP worker after updating so the fix takes effect.\n\n4. \nFor PHP 7.4, 8.0, and 8.1, use a distribution or LTS vendor package, or PHP's minimal source backports, or upgrade to a supported branch.\n\n5. \nRestrict internet access to any PHP system that cannot be updated immediately.\n\n\n> **Note:** \nLinux distributions and long-term-support vendors received the patches in advance, so check your vendor for updated packages.\n \nSome fixed builds did not change their PHP version number, so check the full package string your vendor uses, not just `php -v`.\n\n\n---\n\n## ⚠️ On Older / End-of-Life PHP Versions\n\n\nOn **PHP 8.1 or older**, the PHP project no longer provides updates. Upgrade to a supported version or ask your vendor for a backported fix. PHP's security team has also published minimal source backports for 7.4, 8.0, and 8.1.\n\n\n\nIf you're on PHP 8.1 or older, this is the hard case — there's no official PHP release for you, and CISA's advice is to take those systems offline until they're patched or upgraded. Move to 8.3 or 8.4.\n\n\n---\n\n## 🛡️ Temporary Mitigations (If You Cannot Update Yet)\n\n\nThese measures reduce exposure but **do not make an installation safe**.\n\n\n**For CVE-2026-109618:**\n\nSet `memory_limit=-1` so applications cannot override it, keep `post_max_size` low, and enforce request-size limits at the web server or proxy. Do **not** use `RLIMIT_AS` or `RLIMIT_DATA` as a substitute, as PHP warns they can trigger the same vulnerable path.\n\n\n**For CVE-2026-109619:**\n\nSet `session.upload_progress.enabled=0` and restart every worker, and on PHP 8.5 also set `fatal_error_backtraces=0`. Turning off session upload progress blocks the confirmed session paths but not other variants, and no configuration change fully mitigates this flaw short of updating.\n\n\n**Additionally:**\n\nIf multipart uploads are unnecessary, block `multipart/form-data` POST requests before they reach PHP. Setting a low `post_max_size` also helps.\n\n\n---\n\n## After Updating\n\n\nAfter updating, review your memory settings. The fix adds a new hard memory limit, and reaching it ends the process and stops shutdown handlers from running, so check `memory_limit` and `post_max_size` against what your application needs.\n\n\n---\n\n**Bottom line:** Update PHP to the latest patched version for your branch as soon as possible. No configuration-only workaround fully protects you.", "cited_urls": ["https://tuxcare.com/blog/php2shell-cve/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://sansec.io/research/php2shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.digitalapplied.com/blog/php2shell-fixes-by-distro-control-panel-php-version", "https://www.actuatemedia.com/blog/php2shell-server-problem/", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-claude-2", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Great, here is a comprehensive guide on how to fix **PHP2Shell** (CVE-2026-109618 & CVE-2026-109619):\n\n---\n\n## What is PHP2Shell?\n\n\nPHP2Shell is the name for two critical PHP core Remote Code Execution (RCE) flaws: **CVE-2026-109618** and **CVE-2026-109619**.\n \nBoth vulnerabilities have a CVSS v4.0 score of 9.2.\n\n\n- \n**CVE-2026-109618:** RCE via out-of-memory corruption — when memory runs out mid-request, PHP can be interrupted while internal request data is only partly set up, and cleanup may then treat that broken data as valid.\n\n- \n**CVE-2026-109619:** RCE via stale global state — internal state tied to a request can outlive its freed memory, and a later request on the same worker may use it before it is reset.\n\n\n---\n\n## ✅ The Primary Fix: Update PHP\n\n\nThe bugs are present in every unpatched PHP since 5.4. You **cannot fix PHP2Shell from within your application code** — you must update PHP on every server.\n\n\n\nUpdate to **PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35**, matching the branch you are using. PHP states that **no configuration change fully mitigates** these vulnerabilities.\n\n\n### Step-by-Step Update Process\n\n1. \n**Inventory every server and application that runs PHP**, starting with internet-facing systems.\n\n2. \n**Update each installation** to the fixed release for its branch. Linux distributions were given the patches ahead of release, so look for updated packages from your distribution.\n\n3. \n**Restart every PHP worker** after updating so the fix takes effect.\n\n4. \nIf you run your own server or VPS, install the fixed build from your Linux distribution or php.net, then **restart PHP-FPM or the web server** so it actually loads.\n\n5. \nAfter updating, **rebuild any container images** as well.\n\n\n---\n\n## ⚠️ Running PHP 8.1 or Older?\n\n\nIf you're on PHP 8.1 or older, there is no official PHP release for you. CISA's advice is to take those systems offline until they're patched or upgraded. Move to PHP 8.3 or 8.4.\n\n\n\nOn PHP 8.1 or older, the PHP project no longer provides updates. Upgrade to a supported version or ask your vendor for a backported fix. PHP's security team has also published minimal source backports for 7.4, 8.0, and 8.1.\n\n\n---\n\n## 🛡️ Temporary Mitigations (If You Cannot Update Immediately)\n\n> **Important:** These reduce exposure but do not make an installation fully safe. Apply them together.\n\n\nApply both temporary mitigations together in the effective web PHP configuration: `session.upload_progress.enabled = 0` and `memory_limit = -1`, set in a way applications can't override, then restart every PHP worker. Each setting covers a different vulnerability, so don't apply either alone.\n\n\n- \nFor **CVE-2026-109618**: Set `memory_limit=-1` so applications cannot override it, keep `post_max_size` low, and enforce request-size limits at the web server or proxy. Do **not** use `RLIMIT_AS` or `RLIMIT_DATA` as a substitute, as PHP warns they can trigger the same vulnerable path.\n\n- \nFor **CVE-2026-109619**: Set `session.upload_progress.enabled=0` and restart every worker, and on PHP 8.5 also set `fatal_error_backtraces=0`. Turning off session upload progress blocks the confirmed session paths but not other variants, and no configuration change fully mitigates this flaw short of updating.\n\n- \nIf multipart uploads are unnecessary, **block `multipart/form-data` POST requests** before they reach PHP. Setting a low `post_max_size` also helps.\n\n\n---\n\n## 📝 After Updating\n\n\nAfter updating, review your memory settings. The fix adds a new hard memory limit, and reaching it ends the process and stops shutdown handlers from running, so check `memory_limit` and `post_max_size` against what your application needs.\n\n\n\nAlso, **prioritize anything running `mod_php`**, which PHP's security team rates as the highest risk.\n\n\n---\n\n## 🏠 If You Don't Manage Your Own Server\n\n\nIf you do not manage your own server, **ask your hosting provider** to apply the update.\n \nLinux distributions and long-term-support vendors received the patches in advance, so check your vendor for updated packages.", "cited_urls": ["https://tuxcare.com/blog/php2shell-cve/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://sansec.io/research/php2shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.actuatemedia.com/blog/php2shell-server-problem/", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html", "https://www.digitalapplied.com/blog/php2shell-fixes-by-distro-control-panel-php-version"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-claude-3", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Great — here is a comprehensive guide on how to fix **PHP2Shell** (CVE-2026-109618 & CVE-2026-109619), two critical Remote Code Execution (RCE) vulnerabilities in PHP.\n\n---\n\n## What Is PHP2Shell?\n\n\nPHP2Shell is the name for two critical PHP core RCE flaws: **CVE-2026-109618** and **CVE-2026-109619**.\n\n\n- \n**CVE-2026-109618** is RCE via out-of-memory corruption: when memory runs out mid-request, PHP can be interrupted while internal request data is only partly set up, and cleanup may then treat that broken data as valid.\n\n- \n**CVE-2026-109619** is RCE via stale global state: internal state tied to a request can outlive its freed memory, and a later request on the same worker may use it before it is reset.\n\n\n\nThe bugs are present in every unpatched PHP since version 5.4.\n\n\n---\n\n## ✅ The Proper Fix: Update PHP\n\n\n**You cannot fix PHP2Shell from within your application/store code.** If you do not manage your own server, ask your hosting provider to apply the update.\n\n\n\nUpdate to **PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35**, matching the branch you are currently using.\n\n\n### Step-by-Step:\n\n1. \n**Inventory every server and application that runs PHP**, starting with internet-facing systems.\n\n2. \n**Update each installation to the fixed release for its branch.** Linux distributions were given the patches ahead of release, so look for updated packages from your distribution.\n\n3. \n**Restart every PHP worker** after updating so the fix takes effect.\n\n4. \nFor **PHP 7.4, 8.0, and 8.1**, use a distribution or LTS vendor package or PHP's minimal source backports, or upgrade to a supported branch.\n\n5. \n**Restrict internet access** to any PHP system that cannot be updated immediately.\n\n\n### If You're on PHP 8.1 or Older:\n\nThis is the hard case. There's no official PHP release for you, and CISA's advice is to take those systems offline until they're patched or upgraded. Move to PHP 8.3 or 8.4.\n\n\n### Notes for Self-Managed Servers:\n\nIf you run your own server or VPS, install the fixed build from your Linux distribution or php.net, then restart PHP-FPM or the web server so it actually loads.\n\n\n\nPrioritise anything running **mod_php**, which PHP's security team rates as the highest risk.\n\n\n---\n\n## ⚠️ Temporary Mitigations (If You Cannot Update Yet)\n\n> **Important:** \nPHP states that **no configuration change fully mitigates** these vulnerabilities.\n These are partial measures only.\n\n\nApply both temporary mitigations together in the effective web PHP configuration: `session.upload_progress.enabled = 0` and `memory_limit = -1`, set in a way applications can't override, then restart every PHP worker. Each setting covers a different vulnerability, so don't apply either alone.\n\n\n### For CVE-2026-109618:\n\nSet `memory_limit=-1` so applications cannot override it, keep `post_max_size` low, and enforce request-size limits at the web server or proxy.\n\n\n\n**Do not** use `RLIMIT_AS` or `RLIMIT_DATA` as a substitute, because PHP warns they can trigger the same vulnerable path.\n\n\n### For CVE-2026-109619:\n\nSet `session.upload_progress.enabled=0` and restart every worker, and on PHP 8.5 also set `fatal_error_backtraces=0`. Turning off session upload progress blocks the confirmed session paths but not other variants, and no configuration change fully mitigates this flaw short of updating.\n\n\n### Block Multipart Uploads (Optional):\n\nIf multipart uploads are unnecessary, block `multipart/form-data` POST requests before they reach PHP. Setting a low `post_max_size` also helps.\n\n\n---\n\n## 🔍 After Updating\n\n\nAfter updating, **review your memory settings**. The fix adds a new hard memory limit, and reaching it ends the process and stops shutdown handlers from running, so check `memory_limit` and `post_max_size` against what your application needs.\n\n\n---\n\n## Summary Table\n\n| Action | Who It's For |\n|---|---|\n| Update to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 | All supported PHP users |\n| Use distro/vendor backport | PHP 7.4, 8.0, 8.1 users |\n| Upgrade to 8.3 or 8.4 | Anyone on EOL PHP |\n| Set `memory_limit=-1` & disable session upload progress | Temporary workaround only |\n| Restart all PHP workers | Required after any change |\n\nThe bottom line: **update PHP as soon as possible** — configuration changes alone are not enough.", "cited_urls": ["https://tuxcare.com/blog/php2shell-cve/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://sansec.io/research/php2shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.actuatemedia.com/blog/php2shell-server-problem/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-perplexity-1", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:15:48.327Z", "answer_text": "To fix **PHP2Shell (CVE-2026-109618 and CVE-2026-109619)**, update the PHP runtime on every affected server, then restart all PHP workers. The fixed upstream versions are:\n\n- PHP 8.5 → **8.5.12**\n- PHP 8.4 → **8.4.27**\n- PHP 8.3 → **8.3.36**\n- PHP 8.2 → **8.2.35**[1][4]\n\n## Recommended steps\n\n1. **Patch every PHP installation**, including PHP-FPM, Apache `mod_php`, CGI binaries, containers, CI images, hosting panels, and vendor appliances.[1][3]\n\n On Debian/Ubuntu:\n\n ```bash\n sudo apt update\n sudo apt upgrade\n ```\n\n Or target PHP packages:\n\n ```bash\n sudo apt install --only-upgrade '?name(^php[0-9.]+$)'\n ```\n\n Ubuntu recommends upgrading all packages where possible.[10]\n\n2. **Restart the relevant services** so old PHP workers stop running:\n\n ```bash\n sudo systemctl restart php8.3-fpm\n sudo systemctl restart nginx\n ```\n\n For Apache:\n\n ```bash\n sudo systemctl restart apache2\n ```\n\n Replace `8.3` with the PHP branch installed on your system.[3][10]\n\n3. **Rebuild and redeploy containers** rather than only restarting them:\n\n ```bash\n docker compose build --no-cache\n docker compose up -d\n ```\n\n4. **Verify the installed package and changelog.** Distribution packages may use different version numbers while backporting the fix, so check for the PHP2Shell CVEs in your vendor’s package changelog.[1][3]\n\n5. **If you cannot patch immediately**, take the PHP service off the internet or stop PHP-FPM/Apache and serve a static maintenance page. Application-level authentication or a PHP configuration change is not a complete fix because PHP processes the request before application code runs.[3][5]\n\n6. **Investigate possible compromise.** Preserve logs and configuration snapshots, then check for unexpected web shells, modified files, cron jobs, accounts, and processes associated with PHP before or during remediation.[9]\n\nIf the server runs PHP 8.1 or older, move to a supported branch or obtain a patched package from your operating-system or long-term-support vendor; those versions are generally end-of-life upstream.[3][4]", "cited_urls": ["https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://github.com/ersinkoc/php-fix", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://sansec.io/research/php2shell", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://github.com/PasqualePillitteri/php2shell-hardening", "https://guardz.com/blog/quick-fix-guide-php2shell-vulnerability/", "https://www.uvcyber.com/resources/threat-advisories/threat-advisory-critical-php2shell-vulnerabilities", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://ubuntu.com/blog/php2shell-vulnerability-fixes-available"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-perplexity-2", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP2Shell is fixed by **updating the PHP runtime**, not by changing application code or `php.ini`. Upgrade every PHP installation to a patched release:\n\n- PHP 8.5 → **8.5.12**\n- PHP 8.4 → **8.4.27**\n- PHP 8.3 → **8.3.36**\n- PHP 8.2 → **8.2.35**[1][4]\n\nThen restart all processes that may still have the old PHP code loaded:\n\n```bash\n# PHP-FPM\nsudo systemctl restart php8.3-fpm # adjust version\n\n# Apache with mod_php\nsudo systemctl restart apache2 # use httpd on RHEL-based systems\n\n# Containers\ndocker compose up -d --build\n```\n\nAlso check PHP installations in containers, CI images, hosting panels, Windows binaries, CGI, PHP-FPM, and Apache modules—not only the PHP version used by your main website.[1][3]\n\nIf your distribution uses different package version numbers, verify its package changelog for the PHP2Shell CVEs rather than relying only on the displayed PHP version.[3] If you cannot patch immediately, take the PHP service offline or restrict access to it; WAF rules and request limits are only temporary risk reduction, not a complete fix.[3][9]\n\nAfter patching, preserve logs and inspect for web shells, unexpected cron jobs, new accounts, and suspicious files, because PHP2Shell can enable remote code execution if the system was exposed before updating.[9]", "cited_urls": ["https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://github.com/ersinkoc/php-fix", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://sansec.io/research/php2shell", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://github.com/PasqualePillitteri/php2shell-hardening", "https://guardz.com/blog/quick-fix-guide-php2shell-vulnerability/", "https://www.uvcyber.com/resources/threat-advisories/threat-advisory-critical-php2shell-vulnerabilities", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://github.com/5kr1pt/fix-to-php2shell/tree/main"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-perplexity-3", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP2Shell is fixed by **updating the PHP runtime**, not by changing your application code. Upgrade every PHP installation to a patched release: **8.2.35, 8.3.36, 8.4.27, or 8.5.12**.[1][3]\n\n1. **Find all PHP installations**, including PHP-FPM, Apache `mod_php`, CGI binaries, containers, CI images, and hosting-panel installations.\n2. **Install the vendor’s patched package.** Distribution packages may use different version numbers, so check their changelog for CVE-2026-109618 and CVE-2026-109619.[3]\n3. **Restart all PHP workers** after updating:\n ```bash\n sudo systemctl restart php8.3-fpm # adjust version\n sudo systemctl restart nginx # if applicable\n sudo systemctl restart apache2 # Apache; use httpd on RHEL-based systems\n ```\n Containers must be rebuilt or redeployed so they no longer contain the vulnerable PHP image.[1][7]\n4. **If immediate patching is impossible**, restrict public access to the PHP service or stop PHP-FPM and serve a static maintenance page. Request-size limits, WAF rules, and disabling features are only temporary risk reductions—not complete fixes.[3][4]\n5. **Check for compromise**, preserving logs first, then inspect for web shells, unexpected cron jobs, new accounts, and suspicious files created by PHP processes.[9]\n\nIf you use shared hosting, contact the provider and specifically request updates for **CVE-2026-109618 and CVE-2026-109619**. PHP 8.1 and older require a vendor backport or migration to a supported branch.[4][9]", "cited_urls": ["https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://github.com/ersinkoc/php-fix", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://sansec.io/research/php2shell", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://github.com/PasqualePillitteri/php2shell-hardening", "https://guardz.com/blog/quick-fix-guide-php2shell-vulnerability/", "https://www.uvcyber.com/resources/threat-advisories/threat-advisory-critical-php2shell-vulnerabilities", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://github.com/5kr1pt/fix-to-php2shell/tree/main"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-overviews-1", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:15:48.327Z", "answer_text": "To fix the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), update your PHP installation to the official patched release corresponding to your branch, and restart all PHP worker processes .\nFixed PHP Versions\nUpgrade your PHP version immediately:\nPHP 8.2: Upgrade to 8.2.35\nPHP 8.3: Upgrade to 8.3.36\nPHP 8.4: Upgrade to 8.4.27\nPHP 8.5: Upgrade to 8.5.12\nNote: PHP 8.1 and older are end-of-life and do not receive official updates from the PHP group. If you run older versions, use vendor backports or upgrade immediately.\nStep-by-Step Fix\n1. Update PHP via Package Manager\nIf you use a Linux distribution (such as Ubuntu, Debian, AlmaLinux, or Rocky Linux), pull the latest patched packages from your system repository:\nFor AlmaLinux / RHEL / Rocky Linux:\nFor Ubuntu / Debian:\n2. Restart PHP Workers and Web Servers\nThe fix only takes effect after you wipe the in-memory state by restarting your PHP service (like php-fpm) and web server (Nginx or Apache):\n3. Temporary Mitigations (If You Cannot Patch Immediately)\nIf you cannot upgrade right away, you can reduce exposure by disabling session upload progress in your php.ini or pool configuration:\nWarning: Maintainers state that configuration changes do not completely fix PHP2Shell. Upgrading the binary is the only complete resolution.\nReview details on WatchTowr's PHP2Shell FAQ _K6faaqbGBKmYgLQPh7j7iAk_17 or Sansec's Research Guide _K6faaqbGBKmYgLQPh7j7iAk_18 .\nIf you want to share what operating system or control panel (e.g., Ubuntu, AlmaLinux, cPanel, Docker) you are running, I can give you the exact terminal commands for your environment.", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.youtube.com/watch?v=tqksNZVWJxs", "https://www.abstract.security/blog/php2shell-critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619", "https://meta.stackoverflow.com/questions/440576/where-can-i-get-help-regarding-the-php2shell-vulnerability-patches-cve-2026-109", "https://sansec.io/research/php2shell", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-overviews-2", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To fix PHP2Shell (CVE-2026-109618 and CVE-2026-109619), you must update your PHP installation to a patched release and restart your PHP workers.\nStep-by-Step Remediation\nUpdate PHP to a Patched Release: Upgrade your PHP binaries to the official fixed versions:\nPHP 8.5: Update to 8.5.12\nPHP 8.4: Update to 8.4.27\nPHP 8.3: Update to 8.3.36\nPHP 8.2: Update to 8.2.35\nUse Distribution Packages: If you installed PHP via a Linux distribution, OS vendor, or control panel (such as Ubuntu, AlmaLinux, cPanel, or Plesk), apply the official backported packages released by your vendor. For example, on AlmaLinux you can update via:\nRestart PHP Workers: Restart your PHP-FPM, Apache, or web server services so the old vulnerable code is completely cleared from memory:\nHandle End-of-Life (EOL) Versions: PHP 8.1 and older (including PHP 7.4 and 8.0) are EOL and do not receive official binary releases from the PHP group. If you are on an EOL version, you must upgrade your application to a supported PHP branch (8.2 or newer) or isolate/take the system offline.\nTemporary Mitigations (If You Cannot Patch Immediately): While configuration changes do not fully fix the vulnerability, you can reduce risk by:\nDisabling session upload progress: set session.upload_progress.enabled=0 in your php.ini.\nRestricting internet access to vulnerable endpoints or placing a WAF/reverse proxy in front of PHP.\nFor further guidance, consult the PHP2Shell FAQ by WatchTowr or the research analysis on Sansec .\nCould you tell me:\nWhat operating system or Linux distribution you are running?\nWhat PHP version your server currently uses?\nI can provide the exact terminal commands to update your environment.", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://sansec.io/research/php2shell", "https://meta.stackoverflow.com/questions/440576/where-can-i-get-help-regarding-the-php2shell-vulnerability-patches-cve-2026-109", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://en.wikipedia.org/wiki/PHP2Shell", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-overviews-3", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To fix the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), update your PHP installations to the patched release for your active branch and restart all PHP worker processes.\nStep-by-Step Fixes\nUpdate PHP Versions: Upgrade your PHP installation to the corresponding fixed release:\nPHP 8.5 ➔ Update to 8.5.12\nPHP 8.4 ➔ Update to 8.4.27\nPHP 8.3 ➔ Update to 8.3.36\nPHP 8.2 ➔ Update to 8.2.35\nRestart Workers: Restart every PHP-FPM, Apache mod_php, or CGI worker process immediately after applying the update so the patch takes effect.\nInventory Your Infrastructure: Check all servers, Docker/container images, sidecars, and applications running PHP—especially internet-facing systems.\nHandle Older Branches (PHP 7.4, 8.0, and 8.1): These older or end-of-life branches require vendor-backported packages, long-term support (LTS) packages (such as through ), or upgrading to a currently supported PHP branch.\nRestrict Access: If a system cannot be patched immediately, restrict external or internet access to that PHP service until an update can be deployed.\nNote on Configuration: PHP maintainers state that no configuration change can fully mitigate these memory-safety/out-of-memory vulnerabilities; patching the binary is mandatory.\nFor detailed technical guidance on tracking down hidden PHP runtimes and patching procedures, you can reference the watchTowr PHP2Shell FAQ .\nThis video walks through how to identify hidden PHP instances across your infrastructure and patch your server:\nIf you'd like help, tell me:\nWhat operating system or Linux distribution you are running\nWhich PHP version is currently installed on your server", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.herodevs.com/blog-posts/php-end-of-life-dates-support-timeline-for-every-version-2026", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.herodevs.com"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-mode-1", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:15:48.327Z", "answer_text": "PHP2Shell refers to critical remote code execution (RCE) vulnerabilities (tracked as CVE-2026-109618 and CVE-2026-109619) stemming from memory-safety issues and stale global state handling during fatal out-of-memory errors. The PHP security team released emergency patches to address these core issues. According to PHP, no configuration change or workaround can fully mitigate these flaws—updating the PHP binary itself is required.\nTo properly fix and protect your environment from PHP2Shell:\nUpgrade PHP Version: Update your PHP installation to the latest patched releases corresponding to your active branch:\nUpgrade to PHP 8.5.12 (if on 8.5)\nUpgrade to PHP 8.4.27 (if on 8.4)\nUpgrade to PHP 8.3.36 (if on 8.3)\nUpgrade to PHP 8.2.35 (if on 8.2)\nNote: If you are running older, unsupported branches, you will need to backport the minimal source patches or upgrade your environment to a supported, patched version.\nUpdate Container Images / Server Packages: If you manage PHP via Docker, system package managers (apt, yum), or cloud platforms, refresh your base images and packages to pull the latest security updates.\nCheck for Indicators of Compromise: Because these vulnerabilities allow unauthenticated RCE, review your server logs, web root files, and process lists for unexpected modifications or backdoor shells deployed prior to applying the patch.\nIf you share:\nYour current operating system or environment (Docker, Ubuntu/Debian, cPanel, etc.)\nYour exact active PHP version\nI can help provide the specific terminal commands or upgrade steps for your configuration.", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.youtube.com/watch?v=BAoKuAB2h_E"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-mode-2", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The \"PHP2Shell\" vulnerability refers to critical remote code execution (RCE) flaws in the PHP core engine (tracked as CVE-2026-109618 and CVE-2026-109619) affecting unpatched PHP installations globally. According to the PHP Foundation and security advisories, no configuration workaround or web application firewall (WAF) rule can completely mitigate these vulnerabilities—the only permanent fix is updating PHP itself.\nTo fix and protect your server against PHP2Shell:\nUpdate PHP: Immediately upgrade your PHP runtime to the patched security releases corresponding to your active branch. The fixed versions are:\nPHP 8.5 branch -> 8.5.12\nPHP 8.4 branch -> 8.4.27\nPHP 8.3 branch -> 8.3.36\nPHP 8.2 branch -> 8.2.35 (or backported security packages provided by your Linux distribution/LTS vendor)\nCheck Package Manager: Run your system package manager update (e.g., apt update && apt upgrade on Ubuntu/Debian or yum update / dnf update on RHEL/Almalinux) to pull the latest backports from your repository.\nRestart Web Services: After upgrading, restart your web server and process manager (e.g., systemctl restart php-fpm and systemctl restart nginx or apache2) to ensure no old worker processes remain active in memory with the vulnerable stale state.\nAudit for Compromise: Review system access logs, process lists, and recent file changes in web roots to verify that unauthenticated RCE exploitation has not already occurred prior to patching.\nDo you need help with identifying your current PHP version or checking your distribution's specific package manager commands to complete the update?", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q01-google-ai-mode-3", "question_id": "Q01", "question": "How do I fix PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP2Shell is a pair of critical core-level remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) affecting PHP versions 5.4 through 8.5. They stem from memory-handling and state-cleanup flaws across requests in long-running worker processes (like PHP-FPM).\nBecause active exploitation is underway globally, immediate action is required. How you fix it depends on the PHP version your infrastructure is running:\n1. Upgrade Supported PHP Branches (Immediate Fix)\nIf you are running an actively supported branch of PHP, update your packages immediately to the official emergency security releases provided by PHP:\nPHP 8.5: Upgrade to 8.5.12 or later\nPHP 8.4: Upgrade to 8.4.27 or later\nPHP 8.3: Upgrade to 8.3.36 or later\nPHP 8.2: Upgrade to 8.2.35 or later\nNote: After updating the PHP binaries or packages via your system package manager (apt, yum, etc.), ensure you restart your web server and PHP-FPM services so the running worker processes drop the old memory spaces.\n2. Handle Unsupported Legacy Versions (PHP 8.1 and Below)\nThe PHP development team is not releasing upstream patches for PHP 8.1 and older versions because they have reached End-of-Life (EOL). If you have legacy apps on PHP 8.1, 8.0, 7.x, or 5.x:\nUpgrade the application stack: The safest path is refactoring or updating your application to run on a supported PHP version (8.2 through 8.5).\nIsolate or Virtualize: If upgrading code immediately is impossible, isolate the environment behind strict network boundaries, Web Application Firewalls (WAFs), or utilize secure hardened container images/patches provided by enterprise vendors to mitigate exposure.\n3. Triage Checklist for Your Servers\nTo thoroughly secure your systems, run through this quick triage:\nAudit binaries and containers: Scan your environment to list every running PHP binary, Apache libphp module, and container instance to catch hidden or forgotten legacy runtimes.\nCheck process lists: Verify that your php-fpm or web service processes have actually reloaded the new binaries and aren’t still utilizing deleted/stale binaries in memory.\nMonitor logs: Inspect access and error logs for abnormal system shell activity or outbound payload downloads originating from web workers.\nCould you share what PHP version(s) and operating system or container setup your servers are running so I can provide the exact command or upgrade path for your environment?", "cited_urls": ["https://en.wikipedia.org/wiki/PHP2Shell", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.facebook.com/100083241103501/videos/a-critical-php-vulnerability-has-triggered-a-global-cybersecurity-scramble-with-/955753340606822/", "https://aws.amazon.com/security/security-bulletins/2026-143-aws/", "https://projectdiscovery.io/research/php2shell", "https://www.youtube.com/watch?v=BAoKuAB2h_E", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-chatgpt-1", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Both CVE-2026-109618 and CVE-2026-109619 are fixed in these PHP releases**, published October 21, 2026: ([php.net](https://www.php.net/))\n\n| PHP branch | First fixed version |\n|---|---|\n| 8.5 | **8.5.12** |\n| 8.4 | **8.4.27** |\n| 8.3 | **8.3.36** |\n| 8.2 | **8.2.35** |\n\nUpgrade to the listed version or newer in your branch. PHP recommends updating immediately because both vulnerabilities can allow unauthenticated remote code execution. ([php.net](https://www.php.net/))\n\n**PHP 8.1 and older:** There are no regular upstream security releases for these end-of-life branches. Some distributions and LTS vendors provide backported fixes; check your vendor’s security advisory or upgrade to a supported branch. ([php.net](https://www.php.net/))", "cited_urls": ["https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-chatgpt-2", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Both CVE-2026-109618 and CVE-2026-109619 are fixed in these PHP releases**, according to PHP’s official security advisories: ([github.com](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w))\n\n| PHP branch | First fixed version |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nUpgrade to the listed version or a newer release in your branch. **PHP 8.1 and earlier have no upstream fixed release**; upgrade to a supported branch with the patch. ([cloud.google.com](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619?utm_source=openai))", "cited_urls": ["https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-chatgpt-3", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Both CVE-2026-109618 and CVE-2026-109619 are fixed in these PHP releases**, published on **October 21, 2026**: ([php.net](https://www.php.net/index.php))\n\n| PHP branch | First fixed version |\n|---|---|\n| 8.5 | **8.5.12** |\n| 8.4 | **8.4.27** |\n| 8.3 | **8.3.36** |\n| 8.2 | **8.2.35** |\n\nUpgrade to the listed version or a newer release in your branch. PHP’s security advisory urges users to update immediately. ([php.net](https://www.php.net/index.php))\n\n**PHP 8.1 and earlier:** No regular upstream releases are provided. Some distributions and LTS vendors offer backported fixes, so check your vendor’s security advisory or upgrade to a supported branch. PHP also supplied minimal source backports for 7.4, 8.0, and 8.1. ([php.net](https://www.php.net/index.php))", "cited_urls": ["https://www.php.net/index.php"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-claude-1", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Both **CVE-2026-109618** and **CVE-2026-109619** (collectively nicknamed **\"PHP2Shell\"**) are addressed in the same set of PHP releases. Here is a full breakdown:\n\n---\n\n### ✅ Fixed PHP Versions\n\n\nPHP released the fixes on **October 21, 2026**, in the following versions:\n\n- **PHP 8.5.12**\n- **PHP 8.4.27**\n- **PHP 8.3.36**\n- **PHP 8.2.35**\n\n\n---\n\n### 📋 Version-by-Version Summary\n\n\n| PHP Branch | Affected Versions | Fixed Version |\n|---|---|---|\n| PHP 8.5.x | < 8.5.12 | **8.5.12** |\n| PHP 8.4.x | < 8.4.27 | **8.4.27** |\n| PHP 8.3.x | < 8.3.36 | **8.3.36** |\n| PHP 8.2.x | < 8.2.35 | **8.2.35** |\n| PHP 7.4, 8.0, 8.1 | All versions | No official release — use a distribution or LTS vendor package, or PHP's minimal source backports |\n| PHP 7.3 and older (incl. PHP 5) | All versions | No fix available — upgrade to a supported branch |\n\n\n---\n\n### ⚠️ About the Vulnerabilities\n\n\nBoth CVE-2026-109618 and CVE-2026-109619 are critical, **unauthenticated remote code execution** vulnerabilities in PHP core, each rated **CVSS v4.0 9.2**.\n\n\n\nUpdating to PHP **8.5.12, 8.4.27, 8.3.36, or 8.2.35** (matching the branch in use) is the recommended fix. PHP states that **no configuration change fully mitigates** these vulnerabilities.\n\n\n### 🔧 For End-of-Life PHP Versions\n\n\nThe PHP project no longer supports PHP 8.1 and earlier. Some distributions and LTS vendors offer backported fixes, so users on these versions should contact their vendor or upgrade to a supported release.", "cited_urls": ["https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://blog.securelayer7.net/php-rce-cve-2026-109618-109619/", "https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-claude-2", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Both **CVE-2026-109618** and **CVE-2026-109619** are addressed in the same set of PHP releases. Here is a full breakdown:\n\n---\n\n## Fixed PHP Versions\n\n\nThe PHP development team released emergency security updates to fix these two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619), which could let attackers execute code remotely on web servers without logging in. The fixes are in **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35**.\n\n\n\nThese patches were released on **October 21, 2026**.\n\n\nHere is the per-branch breakdown:\n\n\n\n| Branch | Fixed Version | Support Status |\n|--------|--------------|----------------|\n| 8.5 | **8.5.12** | Active support until December 31, 2027 |\n| 8.4 | **8.4.27** | Active support until December 31, 2026 |\n| 8.3 | **8.3.36** | Security fixes only until December 31, 2027 |\n| 8.2 | **8.2.35** | Security fixes only until December 31, 2026 |\n| 8.1, 8.0, 7.4 | Minimal source backports only | End of life |\n| 7.3 and older | No fix from PHP | End of life |\n\n\n\n---\n\n## About the Vulnerabilities\n\n\nPHP's October 21, 2026 security release covers **CVE-2026-109618** (remote code execution via out-of-memory corruption) and **CVE-2026-109619** (remote code execution via stale global state).\n \nPHP rates both flaws at **9.2 on CVSS v4.0** and says updating is the only safe choice.\n\n\n---\n\n## What About End-of-Life Versions?\n\n\nPHP 8.1 and older no longer receive official updates, but given the severity, PHP's security team published **minimal source backports** for PHP 7.4, 8.0, and 8.1 for anyone building from source.\n \nFor PHP 7.3 and older, including PHP 5, no fix is available at all — users must upgrade to a supported branch.\n\n\n---\n\n## Recommendation\n\n\nUpdate to **PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35**, matching the branch in use. PHP states that **no configuration change fully mitigates** these vulnerabilities.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-claude-3", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Both CVE-2026-109618 and CVE-2026-109619 — collectively nicknamed **\"PHP2Shell\"** — are addressed in the same set of PHP releases. Here is a full breakdown:\n\n## Fixed PHP Versions\n\n\nThe PHP development team released emergency security updates to fix both vulnerabilities (CVE-2026-109618 and CVE-2026-109619), which could allow attackers to execute code remotely on web servers without logging in. The fixes are in **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35**.\n\n\n\nThese patches were released on **October 21, 2026**.\n\n\nHere is the per-branch breakdown:\n\n| PHP Branch | Fixed Version |\n|---|---|\n| 8.5.x | **8.5.12** |\n| 8.4.x | **8.4.27** |\n| 8.3.x | **8.3.36** |\n| 8.2.x | **8.2.35** |\n\n\nFor PHP 7.4, 8.0, and 8.1, there is no official release — only distribution or LTS vendor packages, or PHP's minimal source backports. For PHP 7.3 and older (including PHP 5), no fix is available at all, and upgrading to a supported branch is required.\n\n\n## About the Vulnerabilities\n\n\nCVE-2026-109618 is rooted in **out-of-memory corruption**, while CVE-2026-109619 is rooted in **stale global state** — both are rated CVSS 3.1: 9.8 and CVSS 4.0: 9.2.\n\n\n\nUpdating to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (matching the branch in use) is the recommended action. PHP states that no configuration change fully mitigates these vulnerabilities.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://scantitan.com/blog/php2shell-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-perplexity-1", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The fixes are available in:\n\n- **PHP 8.5.12**\n- **PHP 8.4.27**\n- **PHP 8.3.36**\n- **PHP 8.2.35**[1][2]\n\nPHP **8.1 and earlier have no upstream fix** because those branches are end-of-life; upgrade to a supported branch or use a vendor-provided backport.[2][9]", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://aws.amazon.com/security/security-bulletins/2026-143-aws/", "https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026", "https://kb.i-doit.com/en/maintenance-and-operation/php-security-update.html", "https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/addressing-php2shell-cve-2026-109618-and-cve-2026-109619-upgrade-guidance-and-az/4566623", "https://www.ox.security/blog/cve-2026-109618-cve-2026-109619-two-vulnerabilities-allow-unauthenticated-rce-in-php/", "https://blog.securelayer7.net/php-rce-cve-2026-109618-109619/", "https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-update-php-security-vulnerabilities.md", "https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-perplexity-2", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The vulnerabilities are fixed in these PHP releases:\n\n- **PHP 8.5.12**\n- **PHP 8.4.27**\n- **PHP 8.3.36**\n- **PHP 8.2.35**[1][2]\n\nPHP **8.1 and earlier** have no upstream fix because those branches are end-of-life; upgrade to a supported release.[2]", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://aws.amazon.com/security/security-bulletins/2026-143-aws/", "https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026", "https://kb.i-doit.com/en/maintenance-and-operation/php-security-update.html", "https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/addressing-php2shell-cve-2026-109618-and-cve-2026-109619-upgrade-guidance-and-az/4566623", "https://www.ox.security/blog/cve-2026-109618-cve-2026-109619-two-vulnerabilities-allow-unauthenticated-rce-in-php/", "https://blog.securelayer7.net/php-rce-cve-2026-109618-109619/", "https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-update-php-security-vulnerabilities.md", "https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619", "https://service.purdue.edu/TDClient/32/Purdue/KB/Article/2459/Patching-Critical-PHP-Vulnerabilites-Fall-2026"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-perplexity-3", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The fixes are:\n\n- **PHP 8.5.12**\n- **PHP 8.4.27**\n- **PHP 8.3.36**\n- **PHP 8.2.35**[1][2]\n\nPHP **8.1 and earlier** have no upstream fixes because those branches are end-of-life; upgrade to a supported release.[1][2]", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://aws.amazon.com/security/security-bulletins/2026-143-aws/", "https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026", "https://kb.i-doit.com/en/maintenance-and-operation/php-security-update.html", "https://techcommunity.microsoft.com/blog/azurenetworksecurityblog/addressing-php2shell-cve-2026-109618-and-cve-2026-109619-upgrade-guidance-and-az/4566623", "https://www.ox.security/blog/cve-2026-109618-cve-2026-109619-two-vulnerabilities-allow-unauthenticated-rce-in-php/", "https://blog.securelayer7.net/php-rce-cve-2026-109618-109619/", "https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-update-php-security-vulnerabilities.md", "https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-overviews-1", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "CVE-2026-109618 and CVE-2026-109619 are fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\nFixed PHP Versions by Branch\nPHP 8.5: Fixed in 8.5.12\nPHP 8.4: Fixed in 8.4.27\nPHP 8.3: Fixed in 8.3.36\nPHP 8.2: Fixed in 8.2.35\nImportant Details\nVulnerable Versions: All PHP versions from 5.4 through 8.5.11 are affected.\nEnd-of-Life Versions: PHP 8.1 and earlier have reached end-of-life and do not receive official upstream releases from the PHP project, though some Linux distributors and LTS vendors have provided source backports for select older branches like 7.4, 8.0, and 8.1.\nImpact: Both vulnerabilities (collectively referred to as ) are critical remote code execution (RCE) flaws rated 9.2 on CVSS v4.0.\nYou can read more about the advisory details in the Google Cloud Security Blog or the watchTowr PHP2Shell FAQ .\nIf you share your current PHP version and operating system / container environment, I can help outline the exact update commands or steps to patch your setup.", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/", "https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-overviews-2", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The critical vulnerabilities CVE-2026-109618 and CVE-2026-109619 are fixed in the following PHP versions:\nPHP 8.5.12\nPHP 8.4.27\nPHP 8.3.36\nPHP 8.2.35\nKey Details\nVulnerability Type: Unauthenticated Remote Code Execution (RCE) / PHP2Shell\nCVSS Score: 9.2 out of 10 (Critical)\nAffected Branch Status: PHP 8.1 and older are end-of-life (EOL) and will not receive official updates from the PHP project, requiring vendors or operating system maintainers to provide backports.\nWould you like assistance checking how to update PHP on your specific operating system (such as Debian, Ubuntu, or CentOS) or container setup?", "cited_urls": ["https://sforce.co/4zGCsEt", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://x.com/ishostingcom/status/2112945879602585647", "https://strobes.co/blog/php2shell-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-overviews-3", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The vulnerabilities CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell) are fixed in the following PHP versions:\nPHP 8.5.12\nPHP 8.4.27\nPHP 8.3.36\nPHP 8.2.35\nKey Details\nVulnerability Type: Remote Code Execution (RCE) via out-of-memory corruption and stale global state.\nCVSS Score: 9.2 (Critical).\nAction Required: Update each installation to the fixed release matching your active branch and restart all PHP workers.\nOlder Versions: PHP 8.1 and older are end-of-life and do not receive official releases; administrators must use LTS vendor packages, minimal source backports, or upgrade.\nMore details can be found via the watchTowr PHP2Shell FAQ .\nWhich specific PHP branch or version are you currently running on your servers?", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://tuxcare.com/blog/php-8-1-eol/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-mode-1", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP has released urgent security updates to address CVE-2026-109618 and CVE-2026-109619, two critical memory-corruption vulnerabilities involving out-of-memory (OOM) handling that can lead to unauthenticated remote code execution (RCE).\nThe vulnerabilities affect PHP versions 5.4 through 8.5.11. Depending on which active branch you are running, you must upgrade to the following patched versions:\nPHP 8.5.12\nPHP 8.4.27\nPHP 8.3.36\nPHP 8.2.35\nNote: PHP versions 8.1 and older are past their end-of-life date and will not receive official patches from the PHP project. If you are running those unsupported versions, you will need to upgrade your PHP runtime to a currently supported and patched branch. You can review the details on the Google Cloud Security Blog or track advisories via the watchTowr FAQ.\nIf you'd like, let me know:\nWhat PHP version you are currently running\nYour web server configuration (e.g., Apache mod_php, PHP-FPM)\nI can help you plan your upgrade path or mitigation steps.", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-mode-2", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The critical vulnerabilities CVE-2026-109618 and CVE-2026-109619 (commonly referred to in advisories as the \"PHP2Shell\" flaws) are patched in the following PHP releases:\nPHP 8.5: Version 8.5.12 (or later)\nPHP 8.4: Version 8.4.27 (or later)\nPHP 8.3: Version 8.3.36 (or later)\nPHP 8.2: Version 8.2.35 (or later)\nNote: The PHP project has not released official security patches for versions 8.1 or earlier, as those branches have reached end-of-life (EOL). If you are running an EOL version, you will need to upgrade to a supported active branch or rely on vendor/LTS backported packages.\nYou can review the official details on the PHP.net Security Advisory page.\nWould you like assistance checking the current PHP version in your environment or guidance on how to upgrade for your specific operating system?", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.nsa.gov/press-room/press-releases-statements/press-release-view/article/4630238/nsa-advisory-critical-patches-recommended-for-php-vulnerabilities/", "https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q02-google-ai-mode-3", "question_id": "Q02", "question": "Which PHP version fixes CVE-2026-109618 and CVE-2026-109619?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 fix the critical \"PHP2Shell\" remote code execution vulnerabilities CVE-2026-109618 and CVE-2026-109619.\nSummary of Patched Versions\nAccording to the security advisory released on October 21, 2026, you must upgrade your PHP installation to match your active branch:\nPHP 8.5.x: Upgrade to 8.5.12 (vulnerable up to 8.5.11)\nPHP 8.4.x: Upgrade to 8.4.27\nPHP 8.3.x: Upgrade to 8.3.36\nPHP 8.2.x: Upgrade to 8.2.35\nVulnerability Details\nCVE-2026-109618: Remote code execution via out-of-memory corruption (when memory exhaustion interrupts PHP mid-initialization).\nCVE-2026-109619: Remote code execution via stale global state (when request-owned internal state persists past memory freeing and impacts subsequent worker requests).\nImportant Notes for End-of-Life Versions\nPHP 8.1 and older: The official PHP project is not releasing upstream patches for versions 8.1 and earlier, as they have reached End of Life (EOL).\nIf you are running an EOL version, you will need to upgrade your codebase to a supported branch, use backported distribution packages (if provided by your OS vendor like cPanel or Linux distributions), or utilize commercial extended support (such as TuxCare ELS).\nAfter updating the PHP binaries, remember to restart your PHP-FPM, Apache, or web server workers to ensure stale processes are cleared.\nWhich PHP version is currently running in your environment, and do you need help planning an upgrade path or applying vendor backports?", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://tuxcare.com/blog/php2shell-cve/", "https://support.cpanel.net/hc/en-us/articles/44397389677335-Critical-PHP-Security-Release-CVE-2026-109618-and-CVE-2026-109619"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-chatgpt-1", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No—updating WordPress alone does not fix PHP2Shell.** The vulnerabilities are in **PHP, the server software that runs WordPress**, rather than WordPress itself. WordPress’s official advisory says no WordPress update is required or planned for these issues. ([wordpress.org](https://wordpress.org/news/2026/10/critical-php-security-release/))\n\n**What fixes it:**\n- Update the PHP runtime to **8.2.35, 8.3.36, 8.4.27, or 8.5.12** for the corresponding branch. These security releases were published on **October 21, 2026**. A vendor package containing backported fixes also qualifies, even if its displayed version looks older. ([php.net](https://www.php.net/))\n- Restart the relevant PHP services and workers after installing the update. Updating WordPress, themes, or plugins does not replace this step. ([php2shell.com](https://www.php2shell.com/))\n\n**If your site is hosted:** ask your hosting provider:\n> Has the PHP runtime serving my site been patched for CVE-2026-109618 and CVE-2026-109619, and have the relevant services and workers been restarted?\n\nYou can check your site’s reported PHP version in **Tools → Site Health → Info → Server**, but ask your host to confirm whether a backported fix is installed. ([wordpress.org](https://wordpress.org/news/2026/10/critical-php-security-release/))", "cited_urls": ["https://wordpress.org/news/2026/10/critical-php-security-release/", "https://www.php.net/", "https://www.php2shell.com/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-chatgpt-2", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No—updating WordPress alone does not fix PHP2Shell.** The vulnerabilities are in **PHP itself**, the server software that runs WordPress, rather than WordPress core, plugins, or themes. Even an up-to-date WordPress site can be affected. ([php2shell.com](https://www.php2shell.com/))\n\n**The fix is to update your server’s PHP.** The first patched releases, issued October 21, 2026, are:\n- PHP **8.2.35**\n- PHP **8.3.36**\n- PHP **8.4.27**\n- PHP **8.5.12** ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))\n\nYour host or server administrator must install the appropriate patched release and **restart the relevant PHP services/workers**. Updating WordPress or changing PHP settings is not a substitute. ([php2shell.com](https://www.php2shell.com/))\n\nYou can send your hosting provider this:\n> “Please confirm that the PHP runtime serving my WordPress site is patched against PHP2Shell—CVE-2026-109618 and CVE-2026-109619—and that the affected services have been restarted.”\n\nThose are the two vulnerabilities addressed by the emergency PHP releases. ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))", "cited_urls": ["https://www.php2shell.com/", "https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-chatgpt-3", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No—updating WordPress alone does not fix PHP2Shell.** The vulnerabilities (CVE-2026-109618 and CVE-2026-109619) are in **PHP itself**, the software that runs WordPress—not in WordPress core, themes, or plugins. ([automattic.com](https://automattic.com/2026/10/21/php2shell/?utm_source=openai))\n\nWhat you need to do:\n\n- **Ask your hosting provider to patch PHP.** The fixed releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**, or later releases in those branches. Some vendors provide backported fixes while retaining an older-looking version number. ([automattic.com](https://automattic.com/2026/10/21/php2shell/?utm_source=openai))\n- **If you manage the server yourself, update PHP and restart the relevant services and workers** so they actually run the patched software. ([php2shell.com](https://www.php2shell.com/?utm_source=openai))\n- **Don’t treat a firewall as a replacement for patching.** It can reduce exposure, but the PHP update is still required. ([blog.cloudflare.com](https://blog.cloudflare.com/php-vulnerabilities-waf-protection?utm_source=openai))\n\nIf your site is hosted on **WordPress.com**, its October 21, 2026 announcement says its sites are already protected. That does **not** automatically apply to WordPress sites hosted elsewhere. ([wordpress.com](https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/?utm_source=openai))\n\nWho hosts your site?", "cited_urls": ["https://automattic.com/2026/10/21/php2shell/?utm_source=openai", "https://www.php2shell.com/?utm_source=openai", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection?utm_source=openai", "https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-claude-1", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No, updating WordPress does NOT fix PHP2Shell.** Here's a full breakdown of what PHP2Shell is and what you actually need to do:\n\n---\n\n## What is PHP2Shell?\n\n\nOn October 21, 2026, the PHP team fixed two flaws (CVE-2026-109618 and CVE-2026-109619), both rated 9.2 out of 10. They let a stranger send a specially crafted request to your site and run their own code on your server, without any password.\n\n\n\nThe root cause is four bugs behind the two CVEs, which stem from how PHP handles fatal out-of-memory errors mid-request, which can leave stale internal state for a later request to reuse.\n\n\n---\n\n## Why Won't Updating WordPress Fix It?\n\n\nPHP2Shell is a pair of critical security flaws in PHP, the software that runs WordPress on your server. Updating WordPress or your plugins won't fix it. Your host has to update PHP, and you should check that they did.\n\n\n\nUpdating WordPress, Laravel, Drupal, Craft CMS, or any plugin does not fix this. The bug is in the PHP interpreter underneath them.\n\n\n\nA WordPress update does not establish that the underlying PHP interpreter was replaced. Confirm the runtime update separately with the host or deployment owner.\n\n\n---\n\n## What PHP Versions Fix It?\n\n\nThe PHP security team rates both flaws 9.2 out of 10 on the CVSS v4.0 scale and fixed them in PHP **8.5.12, 8.4.27, 8.3.36, and 8.2.35**.\n\n\n\nPHP 8.1 and older get no official fixed release — the team only published source-code backports for 7.4, 8.0, and 8.1, which you have to build yourself.\n\n\n---\n\n## What Should You Do?\n\n1. **Contact your host.** \nUpdating WordPress or its plugins does not fix this: your host, or whoever runs your server, has to upgrade PHP and restart it.\n\n\n2. **Upgrade PHP if you're on an old version.** \nIf you're still on PHP 8.1 or older, back up and move to 8.3 or 8.4.\n\n\n3. **Use Cloudflare as a temporary measure.** \nPut Cloudflare in front of your site. Cloudflare added protection for PHP2Shell to every plan with its firewall turned on, the free plan included.\n\n\n4. **Check your PHP version in WordPress** via \nTools → Site Health → Info → Server.\n\n\n5. **Act quickly** — \nthe PHP2Shell PHP vulnerability (CVE-2026-109618) is now being actively exploited.\n\n\n---\n\n**In summary:** PHP2Shell is a server-level vulnerability in PHP itself, not in WordPress. No WordPress update, plugin, or theme can patch it. You must ensure your hosting provider updates the PHP runtime to a fixed version.", "cited_urls": ["https://meowapps.com/php2shell-wordpress/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://www.brillmark.com/php2shell-php-vulnerability-patch/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.snazzy.solutions/blog/wordpress/php-vulnerability-php2shell", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-claude-2", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No, updating WordPress does not fix PHP2Shell.** Here's a full breakdown:\n\n---\n\n## What is PHP2Shell?\n\n\nOn October 21, 2026, the PHP team fixed two flaws (CVE-2026-109618 and CVE-2026-109619), both rated 9.2 out of 10. They let a stranger send a specially crafted request to a site and run their own code on the server, without any password.\n\n\n---\n\n## Why WordPress Updates Don't Fix It\n\n\nPHP2Shell is a critical flaw in PHP — the software *under* WordPress — and WordPress updates can't fix it. Updating WordPress or your plugins won't fix it. Your host has to update PHP, and you should check that they did.\n\n\n\nUpdating WordPress, Laravel, Drupal, Craft CMS, or any plugin does not fix this. The bug is in the PHP interpreter underneath them.\n\n\n\nThe fix must happen at the infrastructure level, by updating PHP on the server, and you cannot fix it from within your application's codebase. So the web team that owns the WordPress site cannot patch this vulnerability.\n\n\n---\n\n## What Versions of PHP Fix It?\n\n\nThe PHP security team rates both flaws 9.2 out of 10 on the CVSS v4.0 scale and fixed them in **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35**.\n\n\n\nPHP 8.1 and older get no official fixed release — the team only published source-code backports for 7.4, 8.0, and 8.1, which you have to build yourself.\n\n\n---\n\n## What You Should Do\n\n1. **Contact your host.** \nUpdating WordPress or its plugins does not fix this — your host, or whoever runs your server, has to upgrade PHP and restart it.\n\n\n2. **Check your PHP version.** \nIn WordPress, you can go to **Tools → Site Health → Info → Server** to see your current PHP version.\n\n\n3. **If you manage your own server,** \nmove to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, prioritizing internet-facing systems first, then restart the PHP FastCGI Process Manager (PHP-FPM) or web server.\n\n\n4. **As a temporary measure,** \nput Cloudflare in front of your site. Cloudflare added protection for PHP2Shell to every plan with its firewall turned on, including the free plan.\n\n\n---\n\nIn short, PHP2Shell is a **server-level vulnerability**, not a WordPress-level one. Only a PHP update — applied by your hosting provider or server administrator — can fix it.", "cited_urls": ["https://meowapps.com/php2shell-wordpress/", "https://www.brillmark.com/php2shell-php-vulnerability-patch/", "https://www.secureinseconds.com/blog/2026-10-21-php2shell-patch-window", "https://www.snazzy.solutions/blog/wordpress/php-vulnerability-php2shell", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-claude-3", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**No, updating WordPress does NOT fix PHP2Shell.** Here's a full breakdown:\n\n---\n\n## What is PHP2Shell?\n\n\nOn October 21, 2026, the PHP team fixed two flaws (CVE-2026-109618 and CVE-2026-109619), both rated 9.2 out of 10. They allow a stranger to send a specially crafted request to a site and run their own code on the server — without any password.\n\n\n\nThe PHP2Shell vulnerability (CVE-2026-109618) is now being actively exploited.\n\n\n---\n\n## Why Can't WordPress Updates Fix It?\n\n\nPHP2Shell is a pair of critical security flaws in PHP, the software that runs WordPress on your server. Updating WordPress or your plugins won't fix it. Your host has to update PHP, and you should check that they did.\n\n\n\nUpdating WordPress, Laravel, Drupal, Craft CMS, or any plugin does not fix this. The bug is in the PHP interpreter underneath them.\n\n\n\nThe fix must happen at the infrastructure level, by updating PHP on the server, and cannot be fixed from within an application's codebase. So the web team that owns the WordPress site cannot patch this vulnerability.\n\n\n---\n\n## What's the Difference Between PHP2Shell and WP2Shell?\n\n\nThey are not the same. WP2Shell was a WordPress flaw fixed in July 2026 by WordPress 6.9.5 and 7.0.2. PHP2Shell is in PHP itself, so no WordPress update can fix it.\n\n\n---\n\n## What Are the Fixed PHP Versions?\n\n\nThe PHP security team rates both flaws 9.2 out of 10 on the CVSS v4.0 scale and fixed them in PHP **8.5.12, 8.4.27, 8.3.36, and 8.2.35**.\n\n\n\nPHP 8.1 and older get no official fixed release — the team only published source-code backports for 7.4, 8.0, and 8.1, which you have to build yourself.\n\n\n---\n\n## What Should You Do?\n\n1. **Contact your host:** \nUpdating WordPress or its plugins does not fix this — your host, or whoever runs your server, has to upgrade PHP and restart it.\n\n\n2. **Check your PHP version:** \nCheck the web-facing one in your hosting panel: the PHP version setting for your domain. In WordPress, go to **Tools → Site Health → Info → Server**.\n\n\n3. **Use Cloudflare as a temporary measure:** \nPut Cloudflare in front of your site. Cloudflare added protection for PHP2Shell to every plan with its firewall turned on, including the free plan.\n\n\n4. **Upgrade old PHP versions:** \nIf you're still on PHP 8.1 or older, back up and move to 8.3 or 8.4.\n\n\nIn short, this is a **server-level vulnerability**, and the responsibility for patching it lies with your **hosting provider**, not WordPress itself.", "cited_urls": ["https://meowapps.com/php2shell-wordpress/", "https://www.snazzy.solutions/blog/wordpress/php-vulnerability-php2shell", "https://www.brillmark.com/php2shell-php-vulnerability-patch/", "https://www.secureinseconds.com/blog/2026-10-21-php2shell-patch-window", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-perplexity-1", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No. **Updating WordPress does not fix PHP2Shell** because the vulnerability is in the PHP runtime beneath WordPress, not in WordPress itself.[1][2]\n\nTo remediate it:\n\n- Update the server’s PHP to a fixed release: **8.5.12, 8.4.27, 8.3.36, or 8.2.35—or a newer patched version in the same branch**.[1]\n- Restart PHP-FPM/Apache or the relevant PHP service.\n- If the site is hosted, ask the hosting provider to confirm that the **PHP version actually serving the website** has been patched.\n- Keep WordPress, themes, and plugins updated as normal, but those updates alone do not address PHP2Shell.[3]", "cited_urls": ["https://deeprails.com/research/php2shell-php-vulnerability-fix", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.penligent.ai/hackinglabs/php2shell-what-is-confirmed-about-the-two-php-rces/", "https://www.seosavages.com/blog/php2shell-wordpress/", "https://quantical.com/en/php-vulnerability-remediation/", "https://arvion.ai/tools/php2shell", "https://www.brillmark.com/php2shell-php-vulnerability-patch/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-perplexity-2", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No. **Updating WordPress does not fix PHP2Shell** because the vulnerability is in the PHP interpreter running on your server, not in WordPress.[1][3]\n\nAsk your hosting provider or server administrator to update the PHP runtime to a fixed version—PHP **8.5.12, 8.4.27, 8.3.36, or 8.2.35—or a vendor package containing the same patches**, then restart the PHP service if required.[1][4] Updating WordPress, themes, or plugins is still recommended, but it does not address PHP2Shell.", "cited_urls": ["https://deeprails.com/research/php2shell-php-vulnerability-fix", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.penligent.ai/hackinglabs/php2shell-what-is-confirmed-about-the-two-php-rces/", "https://www.seosavages.com/blog/php2shell-wordpress/", "https://quantical.com/en/php-vulnerability-remediation/", "https://arvion.ai/tools/php2shell", "https://www.brillmark.com/php2shell-php-vulnerability-patch/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-perplexity-3", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No. **Updating WordPress does not fix PHP2Shell** because the vulnerability is in the PHP interpreter running on the server, not in WordPress.[1][2]\n\nTo address it:\n\n- Ask your hosting provider to update the **server PHP runtime** to a patched version: PHP **8.5.12, 8.4.27, 8.3.36, or 8.2.35**, or a vendor package containing the equivalent fix.[1][4]\n- Restart PHP-FPM or the relevant PHP service after updating.\n- Verify the PHP version actually serving the website—not merely the PHP version shown by a command-line installation.[5]\n- Continue updating WordPress, themes, and plugins, but those updates do not remediate PHP2Shell.[2]", "cited_urls": ["https://deeprails.com/research/php2shell-php-vulnerability-fix", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.penligent.ai/hackinglabs/php2shell-what-is-confirmed-about-the-two-php-rces/", "https://www.seosavages.com/blog/php2shell-wordpress/", "https://quantical.com/en/php-vulnerability-remediation/", "https://arvion.ai/tools/php2shell", "https://www.brillmark.com/php2shell-php-vulnerability-patch/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-overviews-1", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No, updating WordPress does not fix the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619).\nKey Details\nRoot Cause: PHP2Shell targets critical remote code execution (RCE) flaws inside the PHP language engine itself, not within WordPress core, themes, or plugins .\nWhere the Fix Happens: The fix requires updating the PHP runtime on your hosting server (or a backported patch applied by your Linux distribution/hosting provider), rather than running an update inside your WordPress dashboard.\nPatched PHP Versions: Released by PHP on October 21, 2026:\nPHP 8.2 updated to 8.2.35\nPHP 8.3 updated to 8.3.36\nPHP 8.4 updated to 8.4.27\nPHP 8.5 updated to 8.5.12\nUnsupported PHP Versions: PHP 8.1 and older no longer receive official security updates from the PHP project. If you are on PHP 8.1 or lower, you must ask your host if they have backported a fix or plan an urgent upgrade to a supported PHP version .\nHow to Check and Act\nCheck your PHP version: In your WordPress dashboard, go to Tools > Site Health > Info tab > Server section, or check your hosting control panel.\nContact your host: Ask your hosting provider or server administrator to confirm whether your server has applied the October 21, 2026 PHP security release or vendor backport for CVE-2026-109618 and CVE-2026-109619.\nIf you'd like, let me know:\nWho your hosting provider is\nWhat PHP version your Site Health screen currently shows\nI can help you figure out what specific questions to ask your host or what steps to take next.", "cited_urls": ["https://www.youtube.com/shorts/oUIPnXmdaiE", "https://www.instagram.com/reel/DexGvH-Maan/", "https://nebula.design/security/php2shell/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://www.reddit.com/r/Wordpress/comments/1xc0w1d/if_your_wordpress_site_is_on_php_81_or_older_the/", "https://www.codeable.io/blog/php-vulnerability-cve-2026-109618/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-overviews-2", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, updating WordPress core patches the underlying vulnerability, but it does not completely fix a site if it has already been compromised.\nWhat Updating WordPress Does\nSeals the vulnerability: Updating WordPress core to a patched version (such as 6.9.5, 7.0.2, or later) fixes the REST API batch flaws (CVE-2026-63030 and related core issues) that allow unauthenticated remote code execution .\nStops new entry: It prevents fresh attacks from exploiting the unpatched core flaw.\nWhy Updating Alone Is Not Enough (If Compromised)\nBackdoors remain: If an attacker already exploited the flaw before you updated, they likely planted rogue administrator accounts, hidden webshell PHP files (often in /wp-content/cache/ or /wp-content/mu-plugins/), or malicious database entries.\nFull recovery steps required: A complete cleanup requires more than just clicking \"Update Now\":\nRestore a clean, pre-compromise backup (if available) .\nScan and delete rogue PHP webshells and unauthorized files via FTP or SSH.\nRemove unknown or rogue admin users.\nChange all user passwords and third-party API keys/secrets .\nRegenerate WordPress security salts.\nEnable two-factor authentication (2FA) and a Web Application Firewall (WAF).\nIf you suspect your site was hit, tell me:\nWhat WordPress version you are currently running\nWhether you see unrecognized admin accounts or odd files in your file manager\nI can help outline a step-by-step cleanup check.", "cited_urls": ["https://www.reddit.com/r/Wordpress/comments/1v63l7b/wordpress_recent_vulnerability_of_wp2shell/", "https://itbutler.sa/blog/wp2shell-how-to-detect-and-fix-the-wordpress-core-rce/", "https://www.reddit.com/r/Wordpress/comments/1v2ifd8/guide_complete_cleanup_and_securing_of_wordpress/", "https://clickk.com.au/wp2shell-explained-the-wordpress-core-vulnerability-behind-the-july-2026-emergency-patch/", "https://matm.co.uk/security-matters/critical-wp2shell-wordpress-vulnerability-update-your-website-now/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-overviews-3", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, updating WordPress fixes the WP2Shell (or wp2shell) vulnerability suite by patching the core security flaws , though additional cleanup steps are required if your site was already compromised before the patch.\nHow the Fix Works\nPatched Core Versions: Updating to a secure WordPress release (such as WordPress 7.0.2 , WordPress 6.9.5, WordPress 6.8.6, or later versions) closes the pre-authentication remote code execution flaws (including CVE-2026-63030 and CVE-2026-60137).\nBlocking New Exploits: Once the core update is applied, unauthenticated attackers can no longer leverage the REST API batch-processing vector to inject malicious code.\nWhat Else You Must Do If Already Exploited\nUpdating alone does not remove malware or backdoors if hackers already targeted your site before you applied the patch. You should perform a full post-update audit:\nCheck User Accounts: Inspect your WordPress users list and delete any unexpected or unknown administrator accounts.\nAudit Plugins and Themes: Remove any unknown, unauthorized, or suspicious plugins and themes.\nScan for Webshells: Inspect directories like /wp-content/cache/ or core file structures for disguised PHP webshells or injected scripts .\nVerify Database Integrity: Check database credentials and look for signs of unauthorized modifications or data exfiltration.\nFurther Exploration", "cited_urls": ["https://tatua.digital/urgent-security-alert-how-to-mitigate-the-wp2shell-vulnerability-in-wordpress-websites/", "https://daily.dev/posts/critical-wp2shell-wordpress-flaws-exploited-to-install-webshells-vrhg7ga8o", "https://www.techrepublic.com/article/news-wordpress-core-vulnerabilities-active-exploitation/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-mode-1", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No, updating WordPress does not fix PHP2Shell.\nPHP2Shell is not a vulnerability in WordPress core, themes, or plugins. Instead, it refers to a pair of critical remote code execution and memory disclosure vulnerabilities (CVE-2026-109618 and CVE-2026-109619) residing within the core PHP language engine itself. Because the flaw is in the underlying PHP runtime that processes web requests, even a blank page or a simple script running on an affected PHP version remains completely vulnerable—independent of any application layer like WordPress, Drupal, or Joomla.\nTo properly mitigate PHP2Shell, you must update the PHP runtime environment on your server, not WordPress.\nApply PHP Patches: Update your PHP installation immediately to the secure patched versions released by the PHP security team: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (and restart your PHP worker processes/services like PHP-FPM or Apache).\nIncompatible/End-of-Life PHP: If your environment is running unsupported versions of PHP (such as PHP 8.1 or older) where official patches may not be readily available, you should temporarily take the affected systems offline or place a strict Web Application Firewall (WAF) rule in front of them until you can upgrade the PHP version.\nWould you like assistance checking what specific version of PHP your server is currently running, or do you need guidance on how to coordinate the PHP update with your hosting provider?", "cited_urls": ["https://www.wiz.io/blog/php2shell-php-rce", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/", "https://www.reddit.com/r/programming/comments/1xbo19y/php2shell_critical_vulnerabilities_in_the/", "https://www.linkedin.com/posts/cisagov_alert-organizations-should-immediately-activity-7518713616154472448-X6iQ", "https://www.instagram.com/reel/Dezex5eNh3L/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-mode-2", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No, updating WordPress will not fix PHP2Shell.\nPHP2Shell is not a vulnerability in WordPress, its themes, or its plugins. Instead, it stems from critical security flaws (CVE-2026-109618 and CVE-2026-109619) located directly inside PHP, the underlying programming language that executes WordPress on your server. Because PHP processes requests before WordPress even loads, application-layer updates, security plugins, and firewalls cannot block or patch the issue.\nHow to Actually Fix PHP2Shell\nTo resolve the vulnerability, the fix must be applied at the server and PHP level:\nIf you use shared or managed hosting: Contact your hosting provider immediately. Ask them to confirm whether the PHP2Shell security patches have been installed and whether the PHP service (such as Apache or PHP-FPM) has been restarted. Many major hosts are backporting fixes or rolling out updates independently.\nIf you manage your own server: Update PHP to a patched release and restart your web server or PHP-FPM service.\nOfficial Patched PHP Versions:\nPHP 8.5: Update to 8.5.12 (or later)\nPHP 8.4: Update to 8.4.27 (or later)\nPHP 8.3: Update to 8.3.36 (or later)\nPHP 8.2: Update to 8.2.35 (or later)\nIf you are on PHP 8.1 or older: Official support for these versions has ended, and the PHP group did not issue official releases for them. You must work with your host or urgently upgrade/migrate your site environment to PHP 8.2 or newer, as unpatched legacy versions face severe exposure.\nIf you'd like, let me know:\nWho your hosting provider is\nWhat PHP version your site is currently running (found under Tools > Site Health > Info > Server in WordPress)\nI can help you figure out the right next steps to verify or address your setup.", "cited_urls": ["https://meowapps.com/php2shell-wordpress/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://www.reddit.com/r/Wordpress/comments/1xc0w1d/if_your_wordpress_site_is_on_php_81_or_older_the/", "https://www.wordfence.com/blog/2026/10/critical-php-update-wordpress-vulnerabilities-testing/", "https://note.com/kotobetech/n/nad3ff11af9c3?hl=en"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q03-google-ai-mode-3", "question_id": "Q03", "question": "Does updating WordPress fix PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No, updating WordPress does not fix PHP2Shell.\nPHP2Shell refers to two critical remote code execution vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that reside inside the PHP programming language itself, not within the WordPress core, themes, or plugins. Because PHP runs before WordPress even loads a request, standard WordPress updates, security plugins, and firewalls cannot block or patch the flaw.\nWhat You Need to Do Instead\nCheck your PHP version: In your WordPress dashboard, go to Tools > Site Health > Info tab > Server to see which PHP version your server is running.\nContact your hosting provider: Ask your host if they have applied the official PHP patch (available for PHP 8.2 through 8.5) or backported a security fix for older versions.\nUpgrade out of End-of-Life PHP: If your site is running PHP 8.1 or older, official PHP releases will not receive a fix. You must work with your host to upgrade your environment to PHP 8.2, 8.3, or 8.4 (making sure to test your plugins on a staging site first).\nWould you like me to guide you on how to check your current PHP version or draft a message you can send to your hosting provider?", "cited_urls": ["https://meowapps.com/php2shell-wordpress/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://nebula.design/security/php2shell/", "https://www.reddit.com/r/Wordpress/comments/1xc0w1d/if_your_wordpress_site_is_on_php_81_or_older_the/", "https://www.youtube.com/shorts/oUIPnXmdaiE"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-chatgpt-1", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**A PHP 7.4 source backport is available, but an existing PHP 7.4 installation is not automatically patched.** On **October 21, 2026**, the PHP security team published an exceptional minimal source backport for PHP 7.4 addressing the PHP2Shell vulnerabilities, **CVE-2026-109618 and CVE-2026-109619**. ([php.net](https://www.php.net/archive/2026.php))\n\nThe distinction is important:\n- **Official PHP 7.4 release:** No new regular release; the branch is end-of-life.\n- **Source build:** The PHP team’s minimal backport is available for rebuilding.\n- **Hosting-provider or distribution package:** It depends on whether your vendor incorporated the backport. “PHP 7.4” alone doesn’t establish that it’s patched—ask for confirmation covering **both CVEs** and your exact package build. ([php.net](https://www.php.net/archive/2026.php))\n\n**The recommended path is to upgrade to a supported, fixed release:** PHP **8.2.35, 8.3.36, 8.4.27, or 8.5.12**, or a later release on those branches. Configuration-only mitigations are not a complete solution. ([php.net](https://www.php.net/archive/2026.php))\n\nWhat OS, hosting provider/package repository, and exact PHP package version are you using? I can help check your specific build.", "cited_urls": ["https://www.php.net/archive/2026.php"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-chatgpt-2", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**A PHP 7.4 patch exists, but your installation is not necessarily patched.** On **October 21, 2026**, the PHP security team published an exceptional **minimal source backport** for PHP 7.4 addressing the PHP2Shell vulnerabilities, **CVE-2026-109618 and CVE-2026-109619**. ([php.net](https://www.php.net/archive/2026.php))\n\nThe distinction is:\n- **No new standard PHP 7.4 release:** the branch remains end-of-life.\n- **A patched build is possible:** you need a build incorporating the source backport, or a patched package from your distribution/hosting provider. Simply being on “PHP 7.4” does not establish that the fixes are installed. ([php.net](https://www.php.net/))\n\nThe preferred path is to upgrade to a supported, fixed release: **8.2.35, 8.3.36, 8.4.27, or 8.5.12**, or a newer release on those branches. ([php.net](https://www.php.net/archive/2026.php))\n\n**What OS or hosting provider are you using, and what is your full PHP package version?** With those details, I can check whether your particular build includes the fixes.", "cited_urls": ["https://www.php.net/archive/2026.php", "https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-chatgpt-3", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**A patch exists for PHP 7.4, but your installation is not necessarily patched.** As of **October 22, 2026**, PHP’s security team has published a **minimal source backport** for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), despite PHP 7.4 being end-of-life. This is not a new regular PHP 7.4 release. ([php.net](https://www.php.net/archive/2026.php))\n\n- **Stock PHP 7.4 releases, including 7.4.33:** vulnerable unless a backported fix has been applied. ([github.com](https://github.com/openai/php2shell-checker/blob/main/skills/phpcheck-server/SKILL.md?utm_source=openai))\n- **Vendor-packaged PHP 7.4:** may be patched. For example, Ubuntu 20.04’s fixed package is **`7.4.3-4ubuntu2.29+esm5`**, available through Ubuntu Pro/ESM. ([ubuntu.com](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available))\n- **Self-built PHP 7.4:** the official source backport is available through the PHP security advisory; you must incorporate it and rebuild. ([php.net](https://www.php.net/archive/2026.php))\n\n**The `7.4.x` version alone cannot establish patch status**—you need the full package revision and its vendor’s advisory, or confirmation that your build includes the backport. Check the PHP installation actually serving your website, not just the command-line version. ([github.com](https://github.com/openai/php2shell-checker/blob/main/skills/phpcheck-server/SKILL.md?utm_source=openai))\n\nWhat OS or hosting provider are you using, and what is your full PHP package version?", "cited_urls": ["https://www.php.net/archive/2026.php", "https://github.com/openai/php2shell-checker/blob/main/skills/phpcheck-server/SKILL.md?utm_source=openai", "https://ubuntu.com/blog/php2shell-vulnerability-fixes-available"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-claude-1", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Great question. The answer is: **it depends on where you get PHP 7.4 from.** Here's the full picture:\n\n---\n\n## PHP2Shell (CVE-2026-109618 & CVE-2026-109619) and PHP 7.4\n\n### What is PHP2Shell?\n\nPHP2Shell refers to two critical security vulnerabilities affecting PHP that result in unauthenticated remote code execution (RCE) for any PHP application.\n \nEither one can let an unauthenticated attacker run code on a web server, as the account PHP runs under, by sending it crafted HTTP requests.\n\n\n---\n\n### Is PHP 7.4 officially patched by PHP.net?\n\n**No.** \nOn October 21, 2026, PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. End-of-life branches will not receive official releases, but the PHP security team published minimal source backports for PHP 7.4 through 8.1.\n\n\nIn short: \nupstream only patches 8.2 through 8.5, so PHP 8.1, 8.0, 7.x and 5.x get nothing from php.net.\n\n\n---\n\n### So what are the options for PHP 7.4?\n\n\nPHP released no update for 8.1 and older. Its security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and LTS vendors ship backported fixes, so ask your host or vendor.\n\n\nHere are known sources of patched PHP 7.4 packages:\n\n- **Red Hat / AlmaLinux:** \nThe php:7.4 stream on AlmaLinux 8 went directly to production, since its fix is a rebuild of Red Hat's update. The patched package version is `php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb`.\n\n\n- **Ubuntu (via ESM/Ubuntu Pro):** \nFocal (20.04) ships PHP 7.4, fixed in version `7.4.3-4ubuntu2.29+esm5`.\n\n\n- **TuxCare ELS:** \nPHP 7.4 builds are already out on nearly every supported Linux platform.\n\n\n- **cPanel:** \nGoDaddy also says cPanel backported the fix to its PHP 7.4, 8.0, and 8.1 packages.\n\n\n- **Debian/Ubuntu (Ondřej Surý PPA):** \nFor Debian and Ubuntu, deb.sury.org and `ppa:ondrej/php` by Ondřej Surý (free) provide fixed versions for PHP 5.6, 7.4, 8.0, and 8.1.\n\n\n---\n\n### Bottom Line\n\n| PHP 7.4 Source | Patched? |\n|---|---|\n| php.net official release | ❌ No official release |\n| Source backport (build yourself) | ✅ Minimal source patch available |\n| RHEL 8 / AlmaLinux 8 php:7.4 stream | ✅ Yes |\n| Ubuntu 20.04 via Ubuntu Pro (ESM) | ✅ Yes |\n| cPanel | ✅ Yes |\n| TuxCare ELS | ✅ Yes |\n| Ondřej Surý PPA (Debian/Ubuntu) | ✅ Yes |\n\nIf you are running PHP 7.4 and **cannot upgrade**, \nuse a distribution or LTS vendor package or PHP's minimal source backports, or upgrade to a supported branch. Restrict internet access to any PHP system that cannot be updated immediately.", "cited_urls": ["https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/", "https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote", "https://tuxcare.com/blog/php2shell-cve/", "https://arvion.ai/tools/php2shell", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://sansec.io/research/php2shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-claude-2", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Great question! The answer is nuanced — PHP 7.4 is **not** patched by PHP.net directly, but patches **are available** through other channels. Here's a full breakdown:\n\n---\n\n## PHP 7.4 and PHP2Shell (CVE-2026-109618 & CVE-2026-109619)\n\n### What is PHP2Shell?\n\nPHP2Shell refers to two critical security vulnerabilities affecting PHP that result in unauthenticated remote code execution (RCE) for any PHP application.\n \nThe two CVEs are CVE-2026-109618 (remote code execution via out-of-memory corruption) and CVE-2026-109619 (remote code execution via stale global state).\n\n\n---\n\n### Is PHP 7.4 Patched by PHP.net?\n\n**No.** \nOn October 21, 2026, PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\n \nUpstream only patches 8.2 through 8.5, so PHP 8.1, 8.0, 7.x and 5.x get nothing from php.net.\n\n\n---\n\n### What About Source Backports?\n\n\nEnd-of-life branches will not receive official releases, but the PHP security team published minimal source backports for PHP 7.4 through 8.1.\n \nIts security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and LTS vendors ship backported fixes, so ask your host or vendor.\n\n\n---\n\n### Where Can You Get a Patched PHP 7.4 Build?\n\nSeveral vendors and distributions have backported the fix for PHP 7.4:\n\n- **Red Hat / AlmaLinux:** \nThe php:7.4 stream on AlmaLinux 8 went directly to production, since its fix is a rebuild of Red Hat's update. The patched package version is `php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb`.\n\n- **Ubuntu (via Ubuntu Pro/ESM):** \nUbuntu 20.04 (Focal) ships a fix for php7.4 in version `7.4.3-4ubuntu2.29+esm5`.\n\n- **Debian/Ubuntu (via Ondřej Surý):** \nFor Debian and Ubuntu, Ondřej Surý's deb.sury.org and ppa:ondrej/php (free) provide fixed PHP versions including 7.4.\n\n- **TuxCare ELS:** \nPHP 7.4 builds are already out on nearly every supported Linux platform\n via TuxCare's Extended Lifecycle Support for Runtimes.\n- **cPanel:** \nGoDaddy also says cPanel backported the fix to its PHP 7.4, 8.0 and 8.1 packages.\n\n\n---\n\n### Bottom Line\n\n| PHP Version | Official php.net Release | Source Backport | Vendor/Distro Fix |\n|---|---|---|---|\n| 8.2–8.5 | ✅ Yes | N/A | Yes |\n| 7.4, 8.0, 8.1 | ❌ No | ✅ Minimal | ✅ (varies by distro/vendor) |\n| 5.x–7.3 | ❌ No | ❌ No | Limited |\n\n**If you are running PHP 7.4, you should update via your Linux distribution, hosting vendor, or LTS provider.** \nRestrict internet access to any PHP system that cannot be updated immediately.", "cited_urls": ["https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote", "https://tuxcare.com/blog/php2shell-cve/", "https://arvion.ai/tools/php2shell", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/", "https://sansec.io/research/php2shell", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-claude-3", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Great question — this is a very recent and actively evolving situation. Here's a summary of where PHP 7.4 stands with regard to the **PHP2Shell** vulnerabilities:\n\n---\n\n## PHP2Shell (CVE-2026-109618 & CVE-2026-109619) — PHP 7.4 Status\n\n### What is PHP2Shell?\n\nPHP2Shell refers to two critical security vulnerabilities affecting PHP that result in unauthenticated remote code execution (RCE) for any PHP application.\n Specifically:\n- \n**CVE-2026-109618** is remote code execution via out-of-memory corruption, and **CVE-2026-109619** is remote code execution via stale global state.\n\n- \nEither one can let an unauthenticated attacker run code on a web server, as the account PHP runs under, by sending it crafted HTTP requests.\n\n\n---\n\n### Is PHP 7.4 Officially Patched?\n\n**No — not with an official PHP release.** \nOn October 21, 2026, PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. End-of-life branches will not receive official releases, but the PHP security team published minimal source backports for PHP 7.4 through 8.1.\n\n\nIn short: \nupstream only patches 8.2 through 8.5, so PHP 8.1, 8.0, 7.x and 5.x get nothing from php.net.\n\n\n---\n\n### What Options Exist for PHP 7.4?\n\nEven though there's no official PHP 7.4 release, patches are available from several sources:\n\n1. **PHP Security Team Source Backport:** \nPHP released no update for 8.1 and older. Its security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux distributions and LTS vendors ship backported fixes.\n\n\n2. **Red Hat / AlmaLinux:** \nThe php:7.4 stream on AlmaLinux 8 went directly to production, since its fix is a rebuild of Red Hat's update. The patched package version is `php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb`.\n\n\n3. **Ubuntu (via Ubuntu Pro / ESM):** \nUbuntu 20.04 (Focal) ships PHP 7.4 fixed in version `7.4.3-4ubuntu2.29+esm5`.\n\n\n4. **TuxCare ELS:** \nPHP 7.4 builds are already out on nearly every supported Linux platform\n via TuxCare's Extended Lifecycle Support for Runtimes.\n\n5. **Ondřej Surý (Debian/Ubuntu):** \nFor Debian and Ubuntu, Ondřej Surý's `deb.sury.org` and `ppa:ondrej/php` repositories provide fixes for PHP 5.6, 7.4, 8.0, and 8.1.\n\n\n6. **cPanel:** \nGoDaddy also says cPanel backported the fix to its PHP 7.4, 8.0 and 8.1 packages.\n\n\n---\n\n### Bottom Line\n\nPHP 7.4 is **end-of-life** and will **not** receive an official patch from php.net, but **vendor/distribution backports do exist**. You should:\n- Check with your Linux distribution or hosting provider for a backported package.\n- Apply the PHP security team's **minimal source backport** if you build PHP yourself.\n- \nRestrict internet access to any PHP system that cannot be updated immediately.\n\n- Consider upgrading to a supported PHP branch (8.2+) as a longer-term solution.", "cited_urls": ["https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/", "https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote", "https://tuxcare.com/blog/php2shell-cve/", "https://arvion.ai/tools/php2shell", "https://sansec.io/research/php2shell", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-perplexity-1", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**PHP 7.4 has an official source-level backport for PHP2Shell, but no official patched PHP 7.4 binary release.** PHP 7.4 is end-of-life, so you must either:\n\n- Rebuild PHP 7.4 using PHP’s minimal backport patch.\n- Install a patched PHP 7.4 package from a distribution or long-term-support vendor.\n- Upgrade to a supported branch—PHP 8.2.35 or later, as applicable.[1][2]\n\nAn unpatched PHP 7.4 installation remains vulnerable; merely running the latest standard 7.4.x release does not guarantee protection.[2][3] After patching, restart PHP-FPM or Apache and verify the package/vendor changelog.", "cited_urls": ["https://github.com/NCSC-NL/php2shell", "https://sansec.io/research/php2shell", "https://www.pwc.de/de/cyber-security/php2shell.html", "https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/", "https://en.wikipedia.org/wiki/PHP2Shell", "https://builder.aws.com/content/3L1O3OGdUB5loyuR2tCQKI9E3Yu/find-it-patch-it-watch-it-a-community-checklist-for-php2shell-on-aws", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.greenbone.net/en/blog/php2shell-remote-code-execution-cve-2026-109618-cve-2026-109619/", "https://github.com/Is4yev/php2shell-poc", "https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-perplexity-2", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**PHP 7.4 has a source-level patch for PHP2Shell, but there is no official patched PHP 7.4 binary release.** PHP’s security team published minimal backports for PHP 7.4; distributions and long-term-support vendors may provide patched packages under their own version numbers.[1][2]\n\nIf you run PHP 7.4:\n\n- Install a vendor package explicitly marked as fixing CVE-2026-109618 and CVE-2026-109619.\n- If you build PHP yourself, apply PHP’s 7.4 backport and rebuild.\n- Otherwise, upgrade to a supported PHP release—PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12—which contain the official fixes.[1][3]\n\nDo not assume that merely running the latest `7.4.x` package means it is patched; verify your OS or LTS vendor’s security advisory.", "cited_urls": ["https://github.com/NCSC-NL/php2shell", "https://sansec.io/research/php2shell", "https://www.pwc.de/de/cyber-security/php2shell.html", "https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/", "https://en.wikipedia.org/wiki/PHP2Shell", "https://builder.aws.com/content/3L1O3OGdUB5loyuR2tCQKI9E3Yu/find-it-patch-it-watch-it-a-community-checklist-for-php2shell-on-aws", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.greenbone.net/en/blog/php2shell-remote-code-execution-cve-2026-109618-cve-2026-109619/", "https://github.com/Is4yev/php2shell-poc", "https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-perplexity-3", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**PHP 7.4 has a source-level backport for PHP2Shell, but no official PHP 7.4 binary release.** PHP published minimal patches for PHP 7.4, while some Linux distributions and LTS vendors have backported them into their own packages.[1][2]\n\nIf you run PHP 7.4:\n\n- Check your OS or vendor package changelog for fixes to **CVE-2026-109618** and **CVE-2026-109619**.\n- If you build PHP from source, apply PHP’s 7.4 backport and rebuild.\n- Otherwise, upgrade to a supported PHP branch—official fixed releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**.[1][3]\n\nDo not assume that merely running the latest `7.4.x` package means it is patched; verify the vendor’s security advisory or package revision.", "cited_urls": ["https://github.com/NCSC-NL/php2shell", "https://sansec.io/research/php2shell", "https://www.pwc.de/de/cyber-security/php2shell.html", "https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/", "https://en.wikipedia.org/wiki/PHP2Shell", "https://builder.aws.com/content/3L1O3OGdUB5loyuR2tCQKI9E3Yu/find-it-patch-it-watch-it-a-community-checklist-for-php2shell-on-aws", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.greenbone.net/en/blog/php2shell-remote-code-execution-cve-2026-109618-cve-2026-109619/", "https://github.com/Is4yev/php2shell-poc", "https://cybelangel.com/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-google-ai-overviews-1", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, PHP 7.4 has official minimal source backports available for the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), though it is an end-of-life (EOL) branch that does not receive standard updates.\nKey Details for PHP 7.4\nSource Backports: Because of the severity of the flaws, the PHP security team released minimal source-level backports for PHP 7.4, 8.0, and 8.1.\nHow to Apply: These patches are intended for developers and administrators who build PHP from source.\nVendor & Distribution Packages: Many Linux distributions, LTS vendors, or control panels (such as select backports or third-party repositories like Ondřej Surý's PPA for Debian/Ubuntu) may provide updated packages. You should check your specific package manager or vendor advisory rather than relying solely on the version string .\nRisk and Mitigation: PHP 7.4 is long past official support. If you cannot build the source backport or obtain a verified vendor patch immediately, you should restrict public access, isolate the server, or use WAF (Web Application Firewall) rules (such as those deployed by ) as a temporary stopgap until you can upgrade to a actively supported PHP version.\nIf you share your operating system or server environment (e.g., Ubuntu, Debian, cPanel, or custom Docker container), I can help you find the right path or command to verify your installation.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://www.youtube.com/watch?v=ST8bY4N6CMU", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html", "https://www.reddit.com/r/drupal/comments/1xc6wmc/running_php_749_on_legacy_drupal_7_any_advice_for/", "https://www.cloudflare.com"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-google-ai-overviews-2", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "PHP 7.4 is not officially binary-patched, as it is long-term end-of-life, but the PHP security team has released minimal source code backports for it.\nKey Details for PHP 7.4\nNo Official Binary Releases: Because PHP 7.4 is past official support, the PHP project did not release a compiled binary update for it (unlike supported branches like PHP 8.2, 8.3, 8.4, and 8.5).\nMinimal Source Backports: The PHP security team published limited, minimal source code backports for PHP 7.4 (along with 8.0 and 8.1) for people who build PHP from source or do not have access to a vendor or LTS provider.\nVendor Packages: Some Linux distributions or commercial LTS support vendors may supply backported package fixes. Check your specific package manager's changelog rather than the version string itself.\nRecommended Action: PHP and security agencies (such as the NSA) strongly advise upgrading PHP 7.4 installations to a currently supported, actively patched release (such as PHP 8.2, 8.3, 8.4, or 8.5) rather than relying on source backports.\nIf you'd like, let me know:\nWhat Operating System or Linux distribution you are running\nWhether you are managing compiled-from-source binaries or package manager builds\nI can help you look up specific vendor advisory steps or migration paths.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://en.wikipedia.org/wiki/PHP2Shell", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html", "https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/", "https://www.secureworld.io/industry-news/patch-php-now-php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-google-ai-overviews-3", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "", "cited_urls": [], "excluded": true, "exclusion_reason": "no AI Overview returned for this query", "redacted": false} {"answer_id": "Q04-google-ai-mode-1", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The PHP security team issued emergency patches for PHP2Shell (critical RCE vulnerabilities CVE-2026-109618 and CVE-2026-109619, carrying a CVSS 9.2 rating). Official patches are limited to actively supported active branches, meaning older, end-of-life versions—including PHP 7.4—do not receive official updates from the core PHP group.\nOfficial Status for PHP 7.4: No. PHP 7.4 reached its end-of-life (EOL) well before these vulnerabilities were disclosed, so the official PHP development team is not releasing an official security update for it.\nOfficial Patched Versions: The official security releases are only available for supported branches: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\nRisk to PHP 7.4: Because PHP 7.4 contains the underlying memory-corruption and use-after-free flaws, any deployment running PHP 7.4 remains exposed to unauthenticated remote code execution unless managed via alternative mitigation strategies.\nIf you are running PHP 7.4, would you like guidance on:\nUpgrading to a supported branch (like PHP 8.2+)?\nCommercial long-term support (LTS) vendors offering backported patches for PHP 7.4?\nWAF or server-level mitigations to reduce exposure?", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.wiz.io/blog/php2shell-php-rce"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-google-ai-mode-2", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "No, standard PHP 7.4 is not automatically patched by the official PHP group because it is long past its end-of-life (EOL) and no longer receives regular upstream security support.\nHowever, you are not entirely out of options. The PHP security team has provided minimal source-backports for PHP 7.4 (along with 8.0 and 8.1) for those building from source, and many enterprise vendors, Linux distributions, or long-term support (LTS) providers (such as TuxCare) have backported the fixes for CVE-2026-109618 and CVE-2026-109619 into their own PHP 7.4 packages.\nWhat you need to do:\nCheck your package manager or vendor: Look at your OS or container provider’s security advisories (e.g., Debian, Ubuntu, Red Hat, or specialized EOL maintainers) to see if a patched PHP 7.4 package has been made available. Do not rely on the version number string alone; check the package changelogs for CVE-2026-109618 and CVE-2026-109619.\nApply source backports if compiling manually: If you compile PHP 7.4 from source, you will need to manually pull and apply the minimal source backport provided by the PHP Security Advisory or upgrade.\nRestart your workers: Remember that updating packages or applying a source patch requires a full restart of your PHP workers (Apache, PHP-FPM, etc.) for the mitigation to take effect.\nConsider upgrading: Because PHP 7.4 is deeply legacy, migrating to a actively supported branch (such as PHP 8.2, 8.3, 8.4, or 8.5) is the safest long-term remedy.\nIf you share your operating system or environment (e.g., Ubuntu 20.04, custom Docker image, cPanel), I can help you figure out if a backported package is available for your setup.", "cited_urls": ["https://tuxcare.com/blog/php2shell-cve/", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://success.trendmicro.com/en-US/solution/KA-0024789", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q04-google-ai-mode-3", "question_id": "Q04", "question": "Is PHP 7.4 patched for PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Officially, no. PHP 7.4 reached its end-of-life (EOL) in late 2022, and the official upstream PHP project does not backport security fixes to unsupported, legacy branches.\nHowever, unofficial and third-party options exist depending on your provider or infrastructure:\nThird-Party Extended Support: Commercial long-term support vendors (such as TuxCare ELS for Runtimes) have rolled out backported patches for PHP 7.4 to address the critical PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619).\nSource Backports / Manual Patches: Some security advisories noted that minimal source backports for EOL versions like PHP 7.4 were made available for manual compilation by specific maintainers or enterprise environments, though official distribution packages from standard EOL repositories are generally absent.\nWorkarounds are Incomplete: Temporary mitigations—such as disabling session upload progress—do not fully protect against all vectors of these memory-corruption/RCE flaws. Upgrading to a actively supported PHP branch (PHP 8.2 or newer) remains the definitive recommendation.\nIf you're managing a PHP 7.4 environment, let me know:\nHow you deploy PHP (custom builds, a specific Linux distro, or a commercial long-term support provider like TuxCare)\nWhether you have access to a WAF/Cloudflare layer for temporary mitigation\nI can help you figure out your best path for remediation or upgrading.", "cited_urls": ["https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://tuxcare.com/blog/php2shell-cve/", "https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-chatgpt-1", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**As of October 22, 2026, these hosts have publicly confirmed PHP2Shell patches** for the services listed below. I checked the providers’ own announcements; this is not an exhaustive list or an independent test of their servers.\n\n### Confirmed patched\n\n| Web host | Confirmed coverage / caveats |\n|---|---|\n| **Hostinger** | Agency hosting, plus PHP 5.2–8.5 on Web, Cloud, and cPanel hosting. Self-managed VPS customers must update separately. ([hostinger.com](https://www.hostinger.com/blog/protecting-php2shell/)) |\n| **GoDaddy** | All PHP versions on Web Hosting, Windows Hosting, and Managed Hosting for WordPress. VPS owners must update themselves. ([godaddy.com](https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do)) |\n| **SiteGround** | Says it applied PHP’s released fixes across **all SiteGround servers**, in addition to earlier mitigations. ([siteground.com](https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026)) |\n| **Namecheap** | Its shared/reseller-server rollout is marked completed. Customers managing their own VPS or dedicated server must update PHP themselves. ([namecheap.com](https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/)) |\n| **Kinsta** | Confirms PHP security updates have rolled out across its platform; the rollout included PHP 7.4 and 8.0–8.5. ([status.kinsta.com](https://status.kinsta.com/)) |\n| **Cloudways** | Confirms completion on Autonomous and Flexible, with all active servers updated. Support is contacting a small subset of customers needing additional assistance. ([status.cloudways.com](https://status.cloudways.com/)) |\n| **Flywheel** | Confirms patch deployment is finished; no customer action required. ([status.getflywheel.com](https://status.getflywheel.com/)) |\n| **IONOS** | Official updates deployed across platforms it operates itself, including Web Hosting and Managed WordPress. Self-managed servers are excluded. ([ionos-status.com](https://www.ionos-status.com/)) |\n\n### Patched, but with scope limitations\n\n- **OVHcloud Web Hosting:** PHP **7.4–8.5** patched on all clusters; its announcement says work continues on older versions. This is a Web Hosting announcement, not blanket coverage for VPS/Public Cloud. ([web-cloud.status-ovhcloud.com](https://web-cloud.status-ovhcloud.com/incidents/6ct3ggp512xk))\n- **Pantheon:** Customer environments, including production, pre-production, and LTS PHP versions, are patched. Its earlier update placed free/sandbox environments on a separate 24–48-hour rollout; the completion notice does not explicitly clarify those. ([status.pantheon.io](https://status.pantheon.io/))\n\n### Still rolling out in the announcements I checked\n\n- **Bluehost and HostGator:** Majority of servers patched; remaining updates underway. ([bluehost.com](https://www.bluehost.com/status/announcement/271))\n- **DreamHost:** Updates applied across most of its network; remaining server groups undergoing final testing before deployment. ([dreamhoststatus.com](https://www.dreamhoststatus.com/))\n\n**Important:** An old-looking PHP version does not necessarily mean “unpatched”—some hosts backported the fixes without changing the displayed version number. Ask your host to confirm that **your specific server and PHP build cover both CVE-2026-109618 and CVE-2026-109619**, rather than relying solely on the version shown in WordPress. ([godaddy.com](https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do))", "cited_urls": ["https://www.hostinger.com/blog/protecting-php2shell/", "https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do", "https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026", "https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/", "https://status.kinsta.com/", "https://status.cloudways.com/", "https://status.getflywheel.com/", "https://www.ionos-status.com/", "https://web-cloud.status-ovhcloud.com/incidents/6ct3ggp512xk", "https://status.pantheon.io/", "https://www.bluehost.com/status/announcement/271", "https://www.dreamhoststatus.com/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-chatgpt-2", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**As of October 22, 2026, these hosts have publicly confirmed PHP2Shell patch deployment** for the services listed below. I checked their own announcements—not just third-party trackers. This is provider-reported status, not an independent test of individual servers.\n\n| Host | Confirmed patch coverage |\n|---|---|\n| **Hostinger** | All hosting plans **except self-managed VPS**. Includes backported fixes for older PHP versions. ([hostinger.com](https://www.hostinger.com/blog/protecting-php2shell/)) |\n| **GoDaddy** | Web Hosting, Windows Hosting, and Managed Hosting for WordPress. **VPS customers must update PHP themselves.** ([godaddy.com](https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do)) |\n| **Kinsta** | Platform-wide rollout complete, including offered PHP versions from 7.4 through 8.5. Completion announced October 22 at 08:26 UTC. ([status.kinsta.com](https://status.kinsta.com/incidents/c0c6xl1ghpb2)) |\n| **Cloudways** | Autonomous and Flexible; says all active servers are updated. Support is contacting a small subset of customers needing additional assistance. ([status.cloudways.com](https://status.cloudways.com/incidents/xxjt802wwhpk)) |\n| **SiteGround** | Says official PHP fixes were applied across all its servers on October 21—not just temporary mitigations. ([siteground.com](https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026)) |\n| **DreamHost** | Says official security updates have been applied across its entire network. Completion announced October 22 at 11:12 a.m. PDT. ([dreamhoststatus.com](https://www.dreamhoststatus.com/pages/incident/575f0f606826303142000510/6ad8c218a7031204d4ca2981)) |\n| **Namecheap** | Shared/reseller hosting rollout marked complete October 22 at 16:50 UTC. Self-managed VPS and dedicated servers require customer updates. ([namecheap.com](https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/)) |\n| **Flywheel** | Platform-wide patch deployment completed October 21; no customer action required. ([status.getflywheel.com](https://status.getflywheel.com/2026/10/21/php-security-update/)) |\n| **Hetzner** | Webhosting and Managed Servers patched, including legacy PHP 5.6 and 7.3. This confirmation does **not** cover customer-managed cloud/dedicated servers. ([status.hetzner.com](https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7)) |\n| **Pantheon** | Production and paid pre-production environments patched, including LTS PHP. Its earlier notice gave free/sandbox environments a separate 24–48-hour rollout window; confirm those specifically. ([status.pantheon.io](https://status.pantheon.io/incidents/x7h8z1yhgvml)) |\n\n**Not yet confirmed fully complete:** Bluehost’s latest announcement still says patching is continuing on remaining infrastructure, with the majority updated. ([bluehost.com](https://www.bluehost.com/status/announcement/271))\n\n**Check your particular plan, not just the host’s name.** Also, an older-looking PHP version does not necessarily mean it is unpatched: some hosts backported the fixes without changing the upstream version number. Ask support to confirm that your server’s PHP build fixes **CVE-2026-109618 and CVE-2026-109619** and that the running PHP services were restarted. ([godaddy.com](https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do))\n\nWhich host and plan are you using?", "cited_urls": ["https://www.hostinger.com/blog/protecting-php2shell/", "https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do", "https://status.kinsta.com/incidents/c0c6xl1ghpb2", "https://status.cloudways.com/incidents/xxjt802wwhpk", "https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026", "https://www.dreamhoststatus.com/pages/incident/575f0f606826303142000510/6ad8c218a7031204d4ca2981", "https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/", "https://status.getflywheel.com/2026/10/21/php-security-update/", "https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7", "https://status.pantheon.io/incidents/x7h8z1yhgvml", "https://www.bluehost.com/status/announcement/271"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-chatgpt-3", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**As of October 22, 2026**, these hosts have publicly confirmed deploying PHP2Shell patches. I checked their own announcements; these are provider-reported statuses, not independent tests of individual servers.\n\n### Confirmed patched—with plan-specific limits\n\n| Host | Confirmed coverage |\n|---|---|\n| **Hostinger** | All hosting servers **except customer-managed VPS**. Includes patched older PHP builds on Web, Cloud, cPanel and Agency hosting. ([hostinger.com](https://www.hostinger.com/blog/protecting-php2shell/)) |\n| **GoDaddy** | All PHP versions on **Web Hosting, Windows Hosting and Managed Hosting for WordPress**. VPS customers must update PHP themselves. ([godaddy.com](https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do)) |\n| **Kinsta** | Platform-wide rollout completed October 22, including PHP 7.4 and 8.0–8.5. ([status.kinsta.com](https://status.kinsta.com/incidents/c0c6xl1ghpb2)) |\n| **Cloudways** | **Autonomous and Flexible**: reports all active servers updated. Support is contacting a small subset of customers requiring additional assistance. ([status.cloudways.com](https://status.cloudways.com/incidents/xxjt802wwhpk)) |\n| **SiteGround** | Says official fixes were applied across **all SiteGround servers**, following its initial mitigations. ([siteground.com](https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026)) |\n| **DreamHost** | October 22 update confirms security updates applied across its entire network; the incident covers Web Hosting, Managed VPS, DreamPress and Dedicated Server Hosting. ([dreamhoststatus.com](https://www.dreamhoststatus.com/pages/incident/575f0f606826303142000510/6ad8c218a7031204d4ca2981)) |\n| **Flywheel** | Completed patch deployment October 21; no customer action required. ([status.getflywheel.com](https://status.getflywheel.com/2026/10/21/php-security-update/)) |\n| **Namecheap** | Shared/reseller rollout marked complete October 22. Customers managing their own VPS or dedicated servers must update themselves. ([namecheap.com](https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/)) |\n| **Hetzner** | **Webhosting and Managed Servers**, including PHP 5.6, 7.3, 7.4 and 8.0–8.5. This is not blanket confirmation for self-managed cloud/dedicated servers. ([status.hetzner.com](https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7)) |\n\n### Partial coverage or remaining caveats\n\n- **Pantheon:** Production and pre-production environments, including legacy/LTS PHP, are confirmed patched. Its closing update says customer-environment rollout is complete, but an earlier notice gave **free/sandbox environments an additional 24–48 hours**; confirm those specifically. ([status.pantheon.io](https://status.pantheon.io/incidents/x7h8z1yhgvml))\n- **OVHcloud:** PHP **7.4–8.5 patched across all Web Hosting clusters**. Older releases remain in progress, with maintenance extended to October 26. ([web-cloud.status-ovhcloud.com](https://web-cloud.status-ovhcloud.com/incidents/6ct3ggp512xk))\n- **Bluehost:** Most infrastructure patched, but its latest announcement still reports deployment to remaining systems—not full completion. ([bluehost.com](https://www.bluehost.com/status/announcement/271))\n- **Black Label Hosting:** Shared hosting on PHP **8.2 and 8.3** patched; managed VPS rollout and older-version upgrades remain in progress. ([blacklabel.hosting](https://blacklabel.hosting/php2shell-security-update/))\n\n**Check your exact plan, not just the host’s name.** Also, an older-looking PHP version number does not necessarily mean it is unpatched: some hosts backported the fix without changing that number. Ask support to confirm the patched build serving your site. ([hostinger.com](https://www.hostinger.com/blog/protecting-php2shell/))\n\nWhich host and hosting plan are you using?", "cited_urls": ["https://www.hostinger.com/blog/protecting-php2shell/", "https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do", "https://status.kinsta.com/incidents/c0c6xl1ghpb2", "https://status.cloudways.com/incidents/xxjt802wwhpk", "https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026", "https://www.dreamhoststatus.com/pages/incident/575f0f606826303142000510/6ad8c218a7031204d4ca2981", "https://status.getflywheel.com/2026/10/21/php-security-update/", "https://www.namecheap.com/status-updates/ongoing-php-security-vulnerability-affecting-hosting-services-october-21-2026/", "https://status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7", "https://status.pantheon.io/incidents/x7h8z1yhgvml", "https://web-cloud.status-ovhcloud.com/incidents/6ct3ggp512xk", "https://www.bluehost.com/status/announcement/271", "https://blacklabel.hosting/php2shell-security-update/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-claude-1", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a summary of what is known about which web hosts have patched PHP2Shell (CVE-2026-109618 and CVE-2026-109619) as of October 22–23, 2026:\n\n---\n\n## Background\n\n\nThe PHP development team released emergency security updates to fix PHP2Shell, two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that could let attackers execute code remotely on web servers without logging in.\n \nThe fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\n\n\n\nUpdating WordPress or its plugins does not fix this — your host, or whoever runs your server, has to upgrade PHP and restart it.\n\n\n---\n\n## Hosts That Have Patched\n\n\nAccording to a tracker of 35 hosting providers:\n\n- **WP Engine** – Finished deploying patches at 01:19 UTC on Thursday, October 22.\n- **Flywheel** – Patched; WP Engine confirmed the deployment of security patches on the Flywheel platform.\n- **Kinsta** – Fully patched, including older PHP builds for versions 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, and 8.5; Cloudflare WAF rules remain in place.\n- **SiteGround** – Mitigation only (as of October 21); disabled the affected functionalities on all supported PHP versions.\n- **Cloudways** – Patched on both Autonomous and Flexible plans.\n\n\n- \n**Automattic** (WordPress.com, WordPress VIP, WP Cloud, and Pressable) – Sites on these platforms are already protected.\n\n\n- \n**Cloudways** – The rollout is complete; all active servers run the fixed PHP on Autonomous and Flexible plans, with support contacting the few customers whose setups need extra help.\n\n\n- \n**GoDaddy** – Patched all PHP versions on Managed Hosting for WordPress, but is waiting for its vendor's packages for Web Hosting and Windows Hosting; VPS customers must update PHP themselves.\n\n\n- \n**CloudLinux** – Its first alt-php packages with the fix came out at 19:00 UTC on October 21.\n\n\n- \n**cPanel's EasyApache 4** – Had fixed builds within minutes of the advisories being published.\n\n\n- \n**cPanel** – Released patched builds of its own PHP, from 7.4 through 8.5, on October 21.\n\n\n- \n**Pantheon** – Web hosting is patched on all clusters, for PHP 7.4 to 8.5.\n\n\n- \n**InMotion Hosting** – Said its shared and WordPress servers were waiting on CloudLinux's builds (as of October 21).\n\n\n---\n\n## Important Caveats\n\n\nA running table tracking what 35 hosting providers and platforms have said about PHP2Shell patch status — including status, time, PHP builds, excluded plans, and sources — was last updated on October 22, 2026.\n Given how rapidly this is evolving, you should check your host's status page or contact their support directly for the most up-to-date information.\n\n\nHosts are moving at different speeds, and several have not said anything. A PHP2Shell host patch status tracker lists what 35 hosts and platforms have published, when, which PHP builds, and which plans were left out (VPS and self-managed plans usually are).\n\n\nFor the most complete and current tracker, visit **activeset.co/blog/php2shell-host-status**.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://cybersecuritynews.com/php-releases-emergency-patches/", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check", "https://www.activeset.co/blog/php2shell-host-status", "https://nebula.design/security/php2shell/", "https://meowapps.com/php2shell-wordpress/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://www.martincid.com/technology-sv/php2shell-php-patch-wordpress-sites-host/", "https://tjrobertson.com/php-security-update-wordpress/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-claude-2", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a summary of the current PHP2Shell patch status across major web hosts, based on the latest available information (as of October 22–23, 2026):\n\n---\n\n## Background\n\n\nThe PHP development team released emergency security updates to fix PHP2Shell — two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that could let attackers execute code remotely on web servers without logging in.\n \nThe fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\n\n\n---\n\n## ✅ Fully Patched Hosts\n\n- **Cloudways** — \n\"The PHP security patch rollout is complete, and all active servers have been successfully updated,\" covering Autonomous and Flexible plans, including deprecated older PHP versions.\n\n\n- **Flywheel** — \nThe fix is deployed on the whole platform, with nothing for customers to do.\n\n\n- **Kinsta** — \nThe PHP security updates have been rolled out across the platform, with patched builds for PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, and 8.5.\n\n\n- **WP Engine** — \nFinished deploying patches at 01:19 UTC on Thursday (October 22).\n\n\n- **OVHcloud** — \nWeb hosting is patched on all clusters, for PHP 7.4 to 8.5, with every live site on PHP 8.2 to 8.5 confirmed patched.\n\n\n- **Pantheon** — \nEvery live site on PHP 8.2 to 8.5 is patched; older PHP versions are waiting for fixes from its vendors.\n\n\n- **GoDaddy** — \nGoDaddy says it patched all PHP versions on Managed Hosting for WordPress, though it is waiting for its vendor's packages for Web Hosting and Windows Hosting, and leaves VPS customers to update PHP themselves.\n\n\n- **Hostinger** — \nPatched builds are now deployed for every version from 5.2 to 8.5 on Web, Cloud, and cPanel hosting (VPS plans may be excluded).\n\n\n- **Bluehost / HostGator** — \n\"The majority of servers are now updated,\" with the rest still rolling out.\n\n\n---\n\n## 🔄 Patching In Progress / Partially Protected\n\n- **DreamHost** — \nThe fixed PHP is on the bulk of its network; the last server groups are in final testing, and sites on PHP 8.1 and older remain protected by mitigations meanwhile.\n\n\n- **Namecheap** — \nAll public services are protected and the fixed PHP is on every server except a short list it publishes; customers with their own VPS or dedicated server need to update themselves.\n\n\n- **InMotion Hosting** — \nDedicated servers are patched; VPS updates are in progress; shared, reseller, and WordPress hosting are protected and waiting on CloudLinux's fixed builds.\n\n\n- **IONOS** — \nInstalling the update across its systems, expected to finish within 24 hours.\n\n\n- **Kinsta** (earlier state) — \nA support lead said its engineers were working on applying the patch\n (now confirmed fully patched per the later update above).\n\n---\n\n## 🛡️ Mitigation Only (Patch Pending)\n\n- **SiteGround** — \nSiteGround disabled the affected functionalities on all supported PHP versions as a mitigation, but has not yet deployed the full patched PHP build.\n\n\n- **Pressable** — \nSays every PHP version it offers is protected against both flaws via server-level protection.\n\n\n---\n\n## Infrastructure Providers\n\n- **CloudLinux** — \nCloudLinux's first alt-php packages with the fix came out at 19:00 UTC on October 21\n, which many shared hosting providers (like InMotion) depend on for their own rollout.\n\n---\n\n## Key Notes\n\n- \nUpdating WordPress, Laravel, Drupal, Craft CMS, or any plugin does **not** fix this — the bug is in the PHP interpreter underneath them.\n\n- \nSome hosts backport the fix into their existing PHP builds, so the version number may stay the same.\n If in doubt, ask your host to confirm in writing that both CVE-2026-109618 and CVE-2026-109619 are patched.\n- \n35.1% of WordPress sites run PHP versions the project no longer patches, though given the severity, the PHP security team has published minimal source backports for PHP 7.4, 8.0, and 8.1.\n\n\nFor the most up-to-date status, check your host's status page directly, as the situation is changing rapidly.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://cybersecuritynews.com/php-releases-emergency-patches/", "https://www.activeset.co/blog/php2shell-host-status", "https://meowapps.com/php2shell-wordpress/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://tjrobertson.com/php-security-update-wordpress/", "https://dev.to/arifulislamat/php2shell-is-your-wordpress-laravel-or-php-site-affected-how-to-patch-today-3jla", "https://nebula.design/security/php2shell/", "https://www.therepository.email/php-patches-critical-php2shell-vulnerabilities-as-hosts-across-the-wordpress-ecosystem-race-to-protect-customers"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-claude-3", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a summary of what is known about PHP2Shell and which web hosts have patched it, based on the latest reporting:\n\n---\n\n## Background: What Is PHP2Shell?\n\n\nTracked as CVE-2026-109618 and CVE-2026-109619, and collectively called PHP2Shell, the flaws affect PHP's handling of memory during web requests.\n \nThey could let attackers execute code remotely on web servers without logging in.\n \nThe PHP project rates both vulnerabilities 9.2 out of 10 under CVSS 4.0, and the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\n\n\n---\n\n## Hosts That Have Patched (as of October 22, 2026)\n\n\nThe largest hosts in the WordPress space followed a similar playbook, putting firewall and configuration mitigations in place first, then rolling out patched PHP versions across their fleets through the day.\n\n\nHere is a breakdown by host:\n\n### ✅ Fully Patched\n- **WordPress.com / WordPress VIP / WP Cloud / Pressable (Automattic):** \nSites on WordPress.com, WordPress VIP, WP Cloud and Pressable were already protected, and the company had worked closely with the PHP Security team ahead of the release.\n\n\n- **WP Engine:** \nWP Engine put mitigations in place at the CDN layer via Cloudflare and Fastly shortly before the release, and finished deploying patches at 01:19 UTC on Thursday.\n\n\n- **Flywheel:** \nThe fix is deployed on the whole platform — nothing for customers to do. Patched as of October 21.\n\n\n- **Cloudways:** \nPatched on Autonomous and Flexible; all active servers have been successfully updated (as of October 22, 10:20 UTC).\n\n\n- **Kinsta:** \nKinsta used Cloudflare rules to block attacks while it validated patches version by version, and had them rolling out for every PHP version by 23:25 UTC.\n \nKinsta's patched builds cover PHP versions 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, and 8.5.\n\n\n- **Hostinger:** \nHostinger blocked circulating exploit attempts before rolling out patches, which was completed at 06:44 UTC Thursday.\n \nPatched builds are deployed for every version from 5.2 to 8.5 on Web, Cloud, and cPanel hosting (VPS excluded).\n\n\n- **20i:** \n20i completed its rollout, including backported fixes for older PHP versions, by 20:01 UTC.\n\n\n- **GoDaddy (Managed WordPress):** \nGoDaddy patched all PHP versions on Managed Hosting for WordPress. It is waiting for its vendor's packages for Web Hosting and Windows Hosting, and it leaves VPS customers to update PHP themselves.\n\n\n- **Pantheon:** \nPantheon is listed as patched.\n\n\n### ⚠️ Mitigation Only (Not Fully Patched as of Oct 22)\n- **SiteGround:** \nSiteGround applied mitigations by disabling affected functions on all supported PHP versions, but as of October 21 had not yet deployed the full patched builds.\n\n\n### 🔄 Partially Patched / In Progress (as of Oct 21)\n- **DreamHost:** \nThe fixed PHP is on the bulk of its network; the last server groups are in final testing. Sites on PHP 8.1 and older stay protected by mitigations meanwhile.\n\n\n- **Bluehost / HostGator:** \nThe majority of servers are now updated, with the rest still rolling out.\n\n\n- **InMotion Hosting:** \nDedicated servers are patched; VPS updates are in progress; shared, reseller and WordPress hosting are protected and waiting on CloudLinux's fixed builds.\n\n\n- **IONOS:** \nInstalling the update across its systems, expected to finish within 24 hours.\n\n\n- **Namecheap:** \nAll affected services have temporary protections, and final patches are in progress.\n\n\n- **Liquid Web / Nexcess:** \nAs of early October 21, no patches or modifications had been rolled out to production systems.\n\n\n---\n\n## Underlying Patch Infrastructure\n\n\nCloudLinux released its first alt-php packages with the fix at 19:00 UTC on October 21.\n \ncPanel released patched builds of its own PHP, from 7.4 through 8.5, on October 21.\n Many shared hosts depend on these upstream providers.\n\n---\n\n> **Note:** The situation is still evolving. \nHosts are moving at different speeds, and several have not said anything. A PHP2Shell host patch status tracker covering 35 hosts and platforms has been published at activeset.co.\n If you are unsure whether your host has patched, it is best to contact your host directly and ask for confirmation.", "cited_urls": ["https://cybersecuritynews.com/php-releases-emergency-patches/", "https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://www.therepository.email/php-patches-critical-php2shell-vulnerabilities-as-hosts-across-the-wordpress-ecosystem-race-to-protect-customers", "https://meowapps.com/php2shell-wordpress/", "https://www.activeset.co/blog/php2shell-host-status", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://tjrobertson.com/php-security-update-wordpress/", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-perplexity-1", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Web hosts that have publicly reported patching or deploying protections for **PHP2Shell** include:\n\n- **Hostinger** — patched all managed hosting servers except customer-managed VPS; agency, web, cloud, and cPanel plans were covered.[1]\n- **OVHcloud** — began rolling out PHP security patches to its hosting infrastructure.[2]\n- **WP Engine** — reported deploying the fixes across relevant infrastructure.[2]\n- **xCloud** — applied mitigations and rolled out official patched PHP builds to managed and self-managed servers.[3]\n- **SmartHost** — fully patched every supported PHP version across its servers, including CloudLinux packages.[4]\n- **Unlimited Web Hosting** — patched all PHP versions on shared/reseller cPanel servers and PHP 7.4+ on Plesk servers.[5]\n\n**Cloudflare** also deployed WAF protections for customers on its free and paid WAF plans, though this protects traffic at the edge and does not replace patching the underlying PHP installation.[6] Vendor-specific status can vary by plan, PHP version, and whether the server is customer-managed.", "cited_urls": ["https://en.wikipedia.org/wiki/PHP2Shell", "https://mallory.ai/stories/01a15af8-3940-7c21-ac01-1dad5de4bd91", "https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://xcloud.host/php2shell-vulnerability/", "https://smarthost.ie/php-security-alert-21-10-26/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.hostinger.com/blog/protecting-php2shell/", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-perplexity-2", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "As of October 23, 2026, publicly reported hosts with PHP2Shell protections or patches include:\n\n- **Hostinger** — patched all managed hosting servers except customer-managed VPS; agency, Web, Cloud, and cPanel hosting were covered.[1]\n- **OVHcloud** — began rolling out PHP patches across its hosting services.[2]\n- **WP Engine** — reported deploying fixes across relevant infrastructure.[2]\n- **xCloud** — applied mitigations before the official fix and deployed patched PHP builds to managed and self-managed servers.[3]\n- **SmartHost** — reported fully patching every supported PHP version on all servers, including CloudLinux packages.[4]\n- **Unlimited Web Hosting** — patched all PHP versions on shared/reseller cPanel servers and PHP 7.4+ on Plesk servers.[5]\n- **Cloudflare** — deployed WAF protections for customers on plans with its WAF, though it advises hosts to patch the underlying PHP installation as well.[6]\n\nFor VPS or self-managed servers, the hosting company’s general patch announcement may not apply; the administrator must verify that the active PHP runtime is patched. The upstream fixed versions are PHP **8.2.35, 8.3.36, 8.4.27, and 8.5.12**.[2]", "cited_urls": ["https://en.wikipedia.org/wiki/PHP2Shell", "https://mallory.ai/stories/01a15af8-3940-7c21-ac01-1dad5de4bd91", "https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://xcloud.host/php2shell-vulnerability/", "https://smarthost.ie/php-security-alert-21-10-26/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.hostinger.com/blog/protecting-php2shell/", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-perplexity-3", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The following web hosts publicly reported patching or mitigating PHP2Shell:\n\n- **Hostinger** — patched all hosting servers except customer-managed VPS instances.[1]\n- **OVHcloud** — began rolling out PHP patches to its hosting services.[2]\n- **WP Engine** — reported deploying fixes across relevant infrastructure.[2]\n- **xCloud** — applied mitigations and rolled out official patched PHP builds across managed and self-managed servers.[3]\n- **SmartHost** — fully patched all supported PHP versions on its servers.[4]\n- **Unlimited Web Hosting** — patched all PHP versions on shared/reseller cPanel servers, including PHP 5.6; Plesk servers running PHP 7.4+ were patched.[5]\n- **CloudLinux-based hosts** — CloudLinux released patched packages covering EA-PHP 5.2–8.5 and all Alt-PHP versions, but each host still needed to install them.[2][4]\n\n**Cloudflare** also deployed WAF protections for customers, but that is mitigation rather than a replacement for patching the underlying PHP installation.[6] VPS, dedicated-server, and self-managed customers should verify their own PHP version and update to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, as applicable.[1][3]", "cited_urls": ["https://en.wikipedia.org/wiki/PHP2Shell", "https://mallory.ai/stories/01a15af8-3940-7c21-ac01-1dad5de4bd91", "https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://xcloud.host/php2shell-vulnerability/", "https://smarthost.ie/php-security-alert-21-10-26/", "https://www.penligent.ai/hackinglabs/php2shell/", "https://www.hostinger.com/blog/protecting-php2shell/", "https://github.com/Anton-Barinov/php2shell-patches", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-overviews-1", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Managed hosting platforms like WP Engine _O6jaaqvHO8S8p84P4PDM0Aw_18 and SiteGround have rolled out patches and server-level mitigations for the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), while other providers and shared hosting setups remain in varying stages of vendor package updates.\nHosting Provider Status & Patching Stages\n: Applied network and server-level mitigations and notified customers that patches were in place.\n: Deployed interim server-level mitigations following initial alerts and updated PHP to the official patched releases (such as PHP 8.2.35) on October 21, 2026.\n: Reported that Managed WordPress environments are patched, while regular shared web hosting and Windows hosting environments have been awaiting final vendor-supplied PHP package builds while running temporary platform mitigations.\ncPanel & CloudLinux (EasyApache 4): Released updated PHP RPM packages across supported branches (ea-php74 through ea-php85) for server administrators and hosting providers utilizing their stacks.\nIf you want to check your specific host, let me know:\nWho your hosting provider is\nWhat hosting tier you use (Shared, Managed, VPS)\nI can help you verify your status or find out how to check your active PHP environment.", "cited_urls": ["https://www.reddit.com/r/webhosting/comments/1xc4wzj/php2shell_some_shared_hosts_still_havent_patched/", "https://dev.to/cseeman/patch-your-php-what-php2shell-means-for-wordpress-sites-2akn", "https://support.cpanel.net/hc/en-us/articles/44397389677335-Critical-PHP-Security-Release-CVE-2026-109618-and-CVE-2026-109619"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-overviews-2", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several major web hosts and managed platforms have confirmed or reported patching the PHP2Shell vulnerabilities (CVE-2026-109618 and ), which target core PHP runtimes across shared hosting, cloud, and VPS environments:\nDreamHost: Confirmed patches deployed for managed and shared hosting (utilizing updated official PHP releases or backported security patches for older versions).\nFlywheel: Reported patching and rolling out updates across hosted WordPress environments.\nLiquid Web: Reported completing/deploying fixes for affected customer environments.\nLaravel Cloud: Temporarily halted cloud deployments to rebuild and refresh infrastructure on patched images.\nNexcess: Experienced slower rollout timelines and lagged behind other major hosts in providing clear status updates.\nInfrastructure & Cloud Ecosystem Partners\nCoordinated mitigations, out-of-the-box WAF protections, or platform updates were deployed in collaboration with Wiz Research and PHP maintainers by major cloud providers and CDNs, including Cloudflare, AWS, Google Cloud, Microsoft Azure , Fastly, Akamai, and Vercel.\nNote: Shared hosts and custom VPS providers handle version updates differently—some upgrade the PHP runtime version directly (e.g., to 8.5.12, 8.4.27, 8.3.36, or 8.2.35), while others apply backported security patches to older builds without altering the visible version string.\nIf you share your specific hosting provider or control panel (such as cPanel, Plesk, or a managed cloud host), I can help you find out how to verify your patch status or switch to a safe PHP version.", "cited_urls": ["https://www.reddit.com/r/webhosting/comments/1xc4wzj/php2shell_some_shared_hosts_still_havent_patched/", "https://dev.to/cseeman/patch-your-php-what-php2shell-means-for-wordpress-sites-2akn", "https://thenextweb.com/news/php2shell-php-rce-ai-openai-wiz", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-overviews-3", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Automattic / WordPress Hosting: Sites hosted on WordPress.com, WordPress VIP, WP Cloud , and Pressable are already protected and patched against PHP2Shell.\nGoDaddy: Managed WordPress is patched; regular Web Hosting and Windows Hosting are still waiting on vendor-supplied PHP package updates (with temporary mitigations active), while VPS customers must update PHP manually.\nDigitalOcean: One-click WordPress, LAMP, LEMP, and Laravel images have been temporarily suspended until patched, with traffic restrictions possible for compromised instances.\nIf you are using a specific hosting provider or control panel (such as cPanel, Plesk, or a custom VPS ), share its name to see if official patched PHP packages (8.5.12, 8.4.27, 8.3.36, or 8.2.35) are available yet.", "cited_urls": ["https://www.newsweek.com/php-vunerability-php2shell-issue-websites-hack-server-12601225", "https://www.reddit.com/r/webhosting/comments/1xc4wzj/php2shell_some_shared_hosts_still_havent_patched/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-mode-1", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Following the emergency release of patched PHP versions (8.5.12, 8.4.27, 8.3.36, and 8.2.35) to address the critical PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), web hosting providers and infrastructure platforms have been rolling out updates at varying speeds.\nBecause PHP2Shell exists in the core language engine rather than individual website code or plugins, remediation depends heavily on your hosting environment type:\nManaged/Platform Hosting: Major managed environments (such as GoDaddy Managed WordPress) have expedited patches across their managed stacks, though standard shared and Windows hosting tiers on various legacy infrastructure have experienced staggered rollouts depending on upstream vendor packages.\nControl Panel & Enterprise Environments: Platforms providing distinct PHP ecosystems—such as CloudLinux (with ea-php and alt-php lines)—have released emergency updated packages for system administrators to pull.\nCloud & VPS Providers: Unmanaged VPS, cloud compute instances (e.g., DigitalOcean, AWS), or self-hosted environments require administrators to manually update their local PHP binaries and restart PHP-FPM/web server services, as host platforms generally do not push OS-level language updates to unmanaged root environments.\nIf you'd like, let me know:\nWho your specific web host is or the type of hosting you use (shared, managed WordPress, VPS, cPanel)\nWhat PHP version your site is currently running\nI can help you figure out if your environment is covered or what steps you need to take to verify and secure it.", "cited_urls": ["https://www.reddit.com/r/webhosting/comments/1xc4wzj/php2shell_some_shared_hosts_still_havent_patched/", "https://x.com/JamalCheaib/status/2113039505481519465", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.facebook.com/groups/brownhillsbob/posts/28772531429052727/", "https://www.godaddy.com/resources/news/important-php-security-update-what-website-owners-need-to-do", "https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html", "https://cloudlinux.zendesk.com/hc/en-us/articles/31194180517916", "https://www.reddit.com/r/sysadmin/comments/1xc0t7g/patched_php_for_php2shell_check_every_php_version/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-mode-2", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The critical PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) were publicly disclosed and patched in core PHP on October 21, 2026. Because the official core fixes (PHP versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12) are very new, rollout status across commercial web hosts varies widely depending on the hosting tier and management type:\nManaged WordPress Hosts: Major specialized or managed platforms (such as GoDaddy's Managed WordPress tier) have rushed out environment updates or integrated temporary Web Application Firewall (WAF) mitigations.\nShared & Standard Web Hosting: Many standard shared hosting environments and traditional cPanel configurations are still in the process of rolling out upstream package updates from their OS vendors, meaning regular shared and Windows hosting tiers may still be pending full core package upgrades.\nCloud & VPS Providers (Self-Managed): Providers like DigitalOcean have communicated active platform alerts—in some cases temporarily restricting or suspending unpatched automated stack images (like one-click LAMP/LEMP/WordPress droplets) until administrators or automated mechanisms apply the core updates. VPS and dedicated server customers are generally responsible for updating their own PHP binaries directly to the fixed versions ( $8.2.35, 8.3.36, 8.4.27, 8.5.12$ or later).\nIf you are on a specific web host, let me know which provider and hosting plan you use (e.g., shared cPanel, managed WordPress, or VPS), and I can help you check their latest official advisory status or advise on how to verify your active PHP version.", "cited_urls": ["https://www.wiz.io/blog/php2shell-php-rce", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/", "https://www.youtube.com/watch?v=ST8bY4N6CMU", "https://www.reddit.com/r/webhosting/comments/1xc4wzj/php2shell_some_shared_hosts_still_havent_patched/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q05-google-ai-mode-3", "question_id": "Q05", "question": "Which web hosts have patched PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Hostinger and Cloudflare are among the first major hosting and infrastructure providers to publicly announce and deploy emergency patches or mitigations for the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619).\nThe PHP group officially released core engine fixes on October 21, 2026 (versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35), and individual managed hosting platforms and security vendors are rolling out updates or edge protections at varying paces:\nHostinger: Has deployed the official PHP security fixes across all of its managed hosting servers (excluding unmanaged VPS instances, which require manual user updates). You can check live maintenance and patch updates via the Hostinger Status Page.\nCloudflare: Has deployed global Web Application Firewall (WAF) mitigations and edge protections across its network to block exploit attempts targeting the unauthenticated remote code execution flaws. Details are outlined on the Cloudflare Blog.\nOther Managed Hosts, VPS, and Cloud Providers (Bluehost, SiteGround, AWS, DigitalOcean, cPanel servers, etc.): Most shared and managed WordPress hosts are actively rolling out the updated PHP runtime versions or applying server-level filtering. However, because patch rollouts happen progressively, administrators of VPS, dedicated servers, or self-hosted environments must manually upgrade their PHP packages or coordinate with their specific provider.\nRecommended Action for Site Owners\nCheck your PHP version in your hosting control panel (cPanel, hPanel, etc.) or via phpinfo().\nConfirm if your provider has updated to the patched PHP releases (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher).\nIf you manage a VPS or cloud server yourself, update your system packages immediately through your package manager (apt, yum, etc.) to the latest PHP patch.\nIf you let me know who your hosting provider is or how your server is set up (shared hosting vs. VPS), I can help you find out what steps you need to take to verify if your site is protected.", "cited_urls": ["https://blog.cloudflare.com/php-vulnerabilities-waf-protection/", "https://www.hostinger.com/blog/protecting-php2shell/", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://www.cloudflare.com/", "https://blog.cloudflare.com/", "https://www.cpanel.net/", "https://www.php.net/manual/en/function.phpinfo.php"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-chatgpt-1", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**I can’t confirm your site is safe without checking its PHP patch status. Updating WordPress or its plugins alone does not fix PHP2Shell—it affects PHP itself.** WordPress sites were among the researchers’ demonstrated targets. ([php2shell.com](https://www.php2shell.com/?utm_source=openai))\n\nAs of **October 22, 2026**, fixes are available for the two vulnerabilities, **CVE-2026-109618 and CVE-2026-109619**, which can let attackers execute code without logging in. ([php.net](https://www.php.net/archive/2026.php))\n\n### How to check your site\n\n1. **Find your PHP version:** In your WordPress dashboard, go to **Tools → Site Health → Info → Server** and look for **PHP version**. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/))\n\n2. **Compare it with the patched releases:**\n\n | PHP branch | First patched release |\n |---|---|\n | 8.2 | **8.2.35** |\n | 8.3 | **8.3.36** |\n | 8.4 | **8.4.27** |\n | 8.5 | **8.5.12** |\n\n Earlier releases need an update **unless your hosting provider has applied a vendor backported fix**. PHP 8.1 and older require particular attention: they no longer receive normal upstream updates, although some vendors provide patched packages. ([php.net](https://www.php.net/archive/2026.php))\n\n3. **Ask your host to confirm the fix is actually running.** Installing updated packages may not be enough; the services using PHP also need restarting. You can send:\n > Has the PHP runtime serving my website been patched for CVE-2026-109618 and CVE-2026-109619, and have all affected PHP workers/services been restarted? Please confirm the patched version or vendor package revision. \n \n This matters even where automatic package updates are enabled. ([ubuntu.com](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available))\n\n**Don’t treat a firewall as a substitute for patching.** Cloudflare has deployed PHP2Shell protections, but still instructs customers to update PHP. ([blog.cloudflare.com](https://blog.cloudflare.com/php-vulnerabilities-waf-protection?utm_source=openai))\n\n**Who is your hosting provider, and what exact PHP version does Site Health show?** Share just those details—no passwords or full diagnostic export—and I can help you interpret them.", "cited_urls": ["https://www.php2shell.com/?utm_source=openai", "https://www.php.net/archive/2026.php", "https://wordpress.org/documentation/article/site-health-screen/", "https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-chatgpt-2", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Possibly—but I can’t confirm without knowing your hosting provider and PHP version.** Updating WordPress alone does **not** protect against PHP2Shell: these vulnerabilities affect PHP itself, underneath WordPress. ([automattic.com](https://automattic.com/2026/10/21/php2shell/))\n\nAs of **October 22, 2026**, here’s how to check:\n\n### If your site is hosted by WordPress.com\nAutomattic says sites on **WordPress.com, WordPress VIP, WP Cloud, and Pressable are already protected**, with no action required from site owners. This does **not** automatically cover WordPress sites hosted elsewhere. ([automattic.com](https://automattic.com/2026/10/21/php2shell/))\n\n### If you use another host or manage your own server\nThe PHP security updates released on October 21 fix the two vulnerabilities, **CVE-2026-109618 and CVE-2026-109619**. You need one of these versions—or a later release in the same branch: ([php.net](https://www.php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000&utm_source=openai))\n\n| PHP branch | Fixed version |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nSome vendors backport fixes into older-looking versions, so an older version number needs confirmation from your host rather than an automatic verdict. ([automattic.com](https://automattic.com/2026/10/21/php2shell/))\n\n**What to do now:**\n\n1. In your WordPress dashboard, open **Tools → Site Health → Info → Server** and find your PHP version. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai))\n2. Ask your host: \n > “Has the PHP runtime serving my site been patched for CVE-2026-109618 and CVE-2026-109619, and have the relevant PHP services/workers been restarted?”\n \n Both applying the update and restarting the affected services matter. ([php2shell.com](https://www.php2shell.com/))\n3. Don’t treat a firewall or security plugin as a substitute for patching PHP; PHP’s advisory says there are no complete mitigations short of updating. ([php.net](https://www.php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000&utm_source=openai))\n\n**Who hosts your site, and what PHP version does Site Health show?** Share just those details—no passwords or full diagnostic report needed.", "cited_urls": ["https://automattic.com/2026/10/21/php2shell/", "https://www.php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000&utm_source=openai", "https://wordpress.org/documentation/article/site-health-screen/?utm_source=openai", "https://www.php2shell.com/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-chatgpt-3", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Possibly—but I can’t confirm without knowing your hosting provider and PHP version.** Being up to date on WordPress alone does **not** protect you: PHP2Shell affects PHP itself, the software running WordPress. ([php2shell.com](https://www.php2shell.com/))\n\n### If you use WordPress.com\nAutomattic’s **October 21, 2026** announcement says sites hosted on **WordPress.com, WordPress VIP, WP Cloud, and Pressable are already protected**, with no action required from site owners for these vulnerabilities. This does not extend to every site using WordPress at another host. ([automattic.com](https://automattic.com/2026/10/21/php2shell/))\n\n### If you use another host or manage your own server\nCheck that the PHP runtime serving your site has been patched. The fixes released October 21 are: ([php.net](https://www.php.net/archive/2026.php))\n\n| PHP branch | Minimum patched release |\n|---|---|\n| 8.2 | **8.2.35** |\n| 8.3 | **8.3.36** |\n| 8.4 | **8.4.27** |\n| 8.5 | **8.5.12** |\n\nAn older version number can still have a vendor-provided *backported fix*, but your host must confirm that. PHP 8.1 and older no longer receive normal upstream releases; upgrade to a supported branch or confirm a vendor patch. ([php.net](https://www.php.net/archive/2026.php))\n\n**Here’s what to do now:**\n\n1. In your WordPress dashboard, open **Tools → Site Health → Info → Server** and find **PHP version**. ([wordpress.org](https://wordpress.org/documentation/article/site-health-screen/))\n2. Ask your host:\n > “Has the PHP runtime serving my site been patched for both PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and have the relevant PHP services/workers been restarted?”\n \n Applying the PHP update and restarting the relevant services is the recommended fix. ([php2shell.com](https://www.php2shell.com/))\n3. **Don’t treat a firewall or configuration workaround as a substitute for patching.** PHP’s advisory says these measures can reduce exposure but do not make an unpatched installation safe. ([php.net](https://www.php.net/archive/2026.php))\n\n**Who hosts your site, and what PHP version does Site Health show?** Share just those details—not passwords or the full diagnostic report—and I can help assess your status.", "cited_urls": ["https://www.php2shell.com/", "https://automattic.com/2026/10/21/php2shell/", "https://www.php.net/archive/2026.php", "https://wordpress.org/documentation/article/site-health-screen/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-claude-1", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very serious and **actively exploited** vulnerability. Here's everything you need to know:\n\n---\n\n## ⚠️ PHP2Shell: What It Is and Why WordPress Sites Are at Risk\n\n### What Is PHP2Shell?\n\n\nPHP2Shell is the name for two critical flaws in PHP itself — **CVE-2026-109618** and **CVE-2026-109619** — that can let an attacker run code on a web server **without logging in**.\n\n\n\n\n- **CVE-2026-109618** (*OOM corruption*): When a server runs out of memory at the wrong moment, PHP can leave half-initialized data behind and treat it as valid.\n- **CVE-2026-109619** (*stale global state*): Data from one request can survive after its memory has been freed and be reused by the next request on the same worker.\n\n\n\n\nBoth are rated **9.2 under CVSS v4.0**, and the PHP security team advised that **every PHP installation serving web requests** was at risk.\n\n\n---\n\n### Is WordPress Specifically Affected?\n\nYes. \nBecause the flaws affect PHP itself rather than a specific application, websites running vulnerable PHP versions may be exposed, **including those built on WordPress, Drupal, and Joomla**.\n\n\n\nSecurity researchers combined these vulnerabilities into a single exploit script, php2shell, and demonstrated that it could execute code remotely **without authentication** on deployments of WordPress, Drupal, and Joomla using their latest container images at the time of testing.\n\n\n---\n\n### Is It Being Actively Exploited?\n\nYes — and exploitation started **before** the patch was released. \nAmazon Threat Intelligence says it saw an exploitation attempt against its honeypots on **October 17**, four days before disclosure, and that PHP2Shell is now being **broadly exploited**. Cloudflare also says it observed attack traffic targeting its customers.\n\n\n---\n\n### What's the Fix?\n\n\nPHP released fixed versions on **October 21, 2026**: **PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12**.\n\n\n---\n\n## ✅ What You Need to Do Right Now\n\n### Step 1: Understand That Updating WordPress Won't Help\n\n\nPHP2Shell is a pair of critical security flaws in PHP, the software that runs WordPress on your server. **Updating WordPress or your plugins won't fix it.** Your host has to update PHP, and you should check that they did.\n\n\n---\n\n### Step 2: Check Your Current PHP Version\n\n\nIn WordPress, log in to the WordPress administration dashboard and open: **Tools → Site Health → Info → Server**. Find the **PHP version** field and note the complete value.\n\n\n⚠️ \nHosting panels usually show the **branch** (e.g., 8.3), not the **build** (e.g., 8.3.36). Picking \"8.3\" in a dropdown does not tell you the host installed the fixed build.\n\n\n---\n\n### Step 3: Know the Target Versions\n\nHere are the versions that contain the fix:\n\n| Your PHP Branch | Fixed Version |\n|---|---|\n| PHP 8.2 | 8.2.35 or later |\n| PHP 8.3 | 8.3.36 or later |\n| PHP 8.4 | 8.4.27 or later |\n| PHP 8.5 | 8.5.12 or later |\n| PHP 8.1 or older | No official patch — upgrade to 8.3+ |\n\n\nAccording to WordPress.org statistics on October 22, **35.8% of WordPress sites run PHP 8.1 or older**, with no official patched release available for those versions.\n\n\n---\n\n### Step 4: Watch Out for Backported Fixes\n\n\nLinux distributions often add the fix to their existing package **without changing the PHP version number**. If you install PHP from Debian, Ubuntu, or RHEL packages, check the package changelog for the CVE IDs.\n\n\n---\n\n### Step 5: Contact Your Host\n\n\nUpdating WordPress or its plugins does not fix this — **your host, or whoever runs your server, has to upgrade PHP and restart it.**\n\n\nAsk your host:\n- \nWhich PHP build serves your site? The full version, or the distribution package plus confirmation its changelog includes both CVEs.\n\n- \nWhen was it deployed, and were workers restarted? A fixed file on disk does not protect a worker that started before the update.\n\n- \nDoes the fix cover every PHP version they offer? Some hosts patch only the newest.\n\n\n---\n\n### Step 6: Check for Signs of Compromise\n\nSince exploitation began before the patch, check your site for these warning signs:\n\n\n\n- New WordPress admin users nobody on your team created\n- Unfamiliar PHP files, especially in the uploads folder, or core files changed recently\n- Unexpected redirects, spam pages, or strange links showing up for your domain in search results\n- Spikes in PHP worker crashes, errors, or memory use since October 17\n- New scheduled tasks or outbound connections that nobody can explain\n\n\n\n---\n\n## 🔑 Bottom Line\n\n**Your WordPress site is safe only if your host has updated the server's PHP** to one of the patched versions above (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12). Check your PHP version in **Tools → Site Health → Info → Server**, confirm with your host, and treat your site as potentially at risk until you have written confirmation that the patch is in place and PHP workers have been restarted.", "cited_urls": ["https://www.activeset.co/blog/php2shell-wordpress-what-to-check", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://www.therepository.email/php-patches-critical-php2shell-vulnerabilities-as-hosts-across-the-wordpress-ecosystem-race-to-protect-customers", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.wiz.io/blog/php2shell-php-rce", "https://meowapps.com/php2shell-wordpress/", "https://kodekloud.com/blog/php2shell-check-fix-php-website/", "https://safeguard.sh/resources/blog/php2shell-wordpress-sites-what-to-do", "https://dev.to/cseeman/patch-your-php-what-php2shell-means-for-wordpress-sites-2akn"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-claude-2", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very serious and actively evolving security issue. Here's everything you need to know about PHP2Shell and your WordPress site:\n\n---\n\n## ⚠️ What is PHP2Shell?\n\n\nPHP2Shell refers to two critical remote code execution vulnerabilities in the PHP engine — **CVE-2026-109618** and **CVE-2026-109619** — which are being actively targeted following the leak of technical details ahead of PHP's October 21, 2026 security release.\n\n\n\nRated **9.2 out of 10** on CVSS v4.0, they let an attacker run their own code on a server, remotely, **with no account and no password.**\n\n\nThe two flaws work like this:\n- \n**CVE-2026-109618** (*OOM corruption*): When a server runs out of memory at the wrong moment, PHP can leave half-initialized data behind and later treat it as valid.\n\n- \n**CVE-2026-109619** (*stale global state*): Data from one request can survive after its memory has been freed, and be reused by the next request on the same worker.\n\n\n---\n\n## 🎯 Is My WordPress Site Affected?\n\n\nBecause the flaws affect **PHP itself** rather than a specific application, websites running vulnerable PHP versions may be exposed, **including those built on WordPress, Drupal, and Joomla.**\n\n\n\nThey affect \"all PHP installations serving web requests\": PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.\n\n\n\nIf your site runs on PHP, assume yes until your host confirms it's patched. The NCSC says every version of PHP is affected, and PHP says that's true however the server is set up.\n\n\n---\n\n## 🚨 Is It Being Actively Exploited?\n\nYes. \nAmazon Threat Intelligence says it saw an exploitation attempt against its honeypots on **October 17** — four days before disclosure — and that PHP2Shell is now being broadly exploited. Cloudflare says it observed attack traffic targeting its customers.\n\n\n\nAccording to WordPress.org statistics on October 22, **35.8% of WordPress sites run PHP 8.1 or older**, with no official patched release.\n\n\n---\n\n## ✅ What Are the Fixed PHP Versions?\n\n\nPHP released fixed versions on **October 21, 2026**: **PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.**\n\n\n\nPHP 8.1 and older are outside normal upstream support. If you still use one of these branches, confirm whether your vendor provides a patched package or arrange an upgrade to a supported version.\n\n\n---\n\n## 🔍 How to Check If Your WordPress Site Is Patched\n\n**Important:** \nUpdating WordPress or your plugins **won't fix it**. Your host has to update PHP, and you should check that they did.\n\n\nTo find your PHP version in WordPress:\n\nGo to **Tools → Site Health**, open the **Info** tab, expand **Server**, and find your **PHP version**.\n\n\nThen compare against this table:\n\n| Your PHP Branch | You Need At Least |\n|---|---|\n| PHP 8.5 | 8.5.12 |\n| PHP 8.4 | 8.4.27 |\n| PHP 8.3 | 8.3.36 |\n| PHP 8.2 | 8.2.35 |\n| PHP 8.1 or older | Ask your host — no official upstream fix |\n\n\nOne catch: a version number alone doesn't always tell you whether you're patched. Some Linux distributions backport security fixes into older version numbers, so if your host uses distribution packages, ask them directly whether the fix for CVE-2026-109618 and CVE-2026-109619 is installed.\n\n\n---\n\n## 🕵️ Signs Your Site May Already Be Compromised\n\n\nWatch out for: new WordPress admin users nobody on your team created; unfamiliar PHP files, especially in the uploads folder, or core files changed recently; unexpected redirects, spam pages or strange links showing up for your domain in search results; spikes in PHP worker crashes, errors or memory use since October 17; and new scheduled tasks or outbound connections that nobody can explain.\n\n\n---\n\n## 🛠️ What To Do Right Now\n\n1. **Check your PHP version** via Tools → Site Health → Info → Server.\n2. **Contact your hosting provider** immediately and ask them to confirm that PHP has been updated to a patched build and that PHP workers have been restarted.\n3. **If you manage your own server**, run `php -v` and `php-fpm -v`, update PHP, and restart your web server.\n4. \nPHP 8.1 and older are affected and no longer get official updates. The safest move is **upgrading to PHP 8.3 or newer** and testing your site afterwards.\n\n5. \nIf you find suspicious activity, preserve the relevant evidence and involve your hosting provider or incident-response team. They can help contain the system and determine what needs to be restored or replaced.\n\n\nThe bottom line: **your WordPress site is at risk unless your host has already deployed the patched PHP version.** Contact them today if you haven't already.", "cited_urls": ["https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://nebula.design/security/php2shell/", "https://www.activeset.co/blog/php2shell-wordpress-what-to-check", "https://kodekloud.com/blog/php2shell-check-fix-php-website/", "https://meowapps.com/php2shell-wordpress/", "https://wordify.com/blog/php-security-vulnerability-wordpress-october-2026/", "https://www.snazzy.solutions/blog/wordpress/php-vulnerability-php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-claude-3", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very important and active security situation. Here's a full breakdown of what PHP2Shell is and what you need to do to protect your WordPress site:\n\n---\n\n## ⚠️ PHP2Shell: What WordPress Site Owners Need to Know\n\n### What Is PHP2Shell?\n\n\nPHP2Shell is the name for two critical flaws in PHP itself — **CVE-2026-109618** and **CVE-2026-109619** — that can let an attacker run code on a web server **without logging in**.\n\n\n\nOn October 21, 2026, the PHP team fixed both flaws, and they are rated **9.2 out of 10** in severity.\n\n\n---\n\n### How Do the Vulnerabilities Work?\n\n- \n**CVE-2026-109618 (OOM Corruption):** When memory allocation fails during certain initialization stages, PHP's OOM handling could abandon a context while internal request memory was not fully initialized. Cleanup could then access corrupt state. Researchers demonstrated unauthenticated RCE through Apache mod_php before application code runs; PHP-FPM remains a concern through other paths.\n\n\n- \n**CVE-2026-109619 (Stale Global State):** A request can leave a globally reachable reference to freed, request-owned memory. A later request in the same worker can access that stale reference.\n\n\n---\n\n### Is WordPress Specifically at Risk?\n\n**Yes.** \nBecause the flaws affect PHP itself rather than a specific application, websites running vulnerable PHP versions may be exposed, including those built on **WordPress, Drupal, and Joomla**.\n\n\n\nResearchers combined these vulnerabilities into a single exploit script, *php2shell*, and demonstrated that it could execute code remotely **without authentication** on deployments of WordPress, Drupal, and Joomla.\n\n\n---\n\n### Is It Being Actively Exploited?\n\n**Yes.** \nAmazon Threat Intelligence says it saw an exploitation attempt against its honeypots on October 17 — four days before disclosure — and that PHP2Shell is now being **broadly exploited**. Cloudflare says it observed attack traffic targeting its customers.\n\n\n\nIndia's CERT-In advisory, issued the same day, says multiple reports confirm **large-scale exploitation in the wild** and advises patching urgently.\n\n\n---\n\n### What PHP Versions Are Affected?\n\n\nThe vulnerabilities affect **all PHP installations serving web requests**: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.\n\n\n\nAccording to WordPress.org statistics on October 22, **35.8% of WordPress sites run PHP 8.1 or older**, with no official patched release available for those versions.\n\n\n---\n\n### What Are the Fixed PHP Versions?\n\n\nPHP released fixed versions on **October 21, 2026**: **PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12**.\n\n\n---\n\n### ✅ What You Need to Do\n\n1. **Do NOT just update WordPress or plugins.** \nUpdating WordPress or your plugins won't fix it. Your host has to update PHP, and you should check that they did.\n\n\n2. **Check your PHP version.** Log in to your hosting control panel (cPanel, Plesk, etc.) and verify which PHP version is running. It must be one of the patched versions listed above.\n\n3. **Contact your host immediately** if you are unsure. \nHosting companies in the WordPress space have been blocking attacks with mitigations and rolling out patched versions of PHP, with some still patching well into Thursday.\n\n\n4. **Watch for signs of compromise.** \nLook for new WordPress admin users nobody on your team created, unfamiliar PHP files (especially in the uploads folder), unexpected redirects or spam pages, spikes in PHP worker crashes since October 17, and new scheduled tasks or outbound connections nobody can explain.\n\n\n---\n\n### Bottom Line\n\nYour WordPress site is **NOT safe** unless your server is running one of the patched PHP versions (8.2.35, 8.3.36, 8.4.27, or 8.5.12). This is a **PHP-level vulnerability**, so no WordPress plugin or update will protect you — only a PHP upgrade by your host will. Check with your hosting provider **today**.", "cited_urls": ["https://www.activeset.co/blog/php2shell-wordpress-what-to-check", "https://meowapps.com/php2shell-wordpress/", "https://aiidelist.com/blog/php2shell-critical-php-rce-vulnerabilities-wordpress", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.wiz.io/blog/php2shell-php-rce", "https://www.digidop.com/blog/php2shell-php-vulnerability-wordpress-webflow", "https://www.therepository.email/php-patches-critical-php2shell-vulnerabilities-as-hosts-across-the-wordpress-ecosystem-race-to-protect-customers"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-perplexity-1", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is safe from PHP2Shell **only if its server is running a patched PHP release**:\n\n- PHP **8.5.12 or newer**\n- PHP **8.4.27 or newer**\n- PHP **8.3.36 or newer**\n- PHP **8.2.35 or newer**\n- Or a Linux-distribution package containing the equivalent security fixes[2][3]\n\nUpdating WordPress, plugins, themes, or security software does **not** fix PHP2Shell because the vulnerability is in PHP itself and can be triggered before WordPress loads.[2][3]\n\nTo check:\n\n1. In WordPress, open **Tools → Site Health → Info → Server**.\n2. Find the **PHP version**.\n3. If it is older than the patched version for its branch, contact your hosting provider immediately and ask whether PHP2Shell has been patched.\n4. If your site is hosted on **WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr**, the provider says it is already protected.[1][2]\n\nUntil the host confirms a patched PHP runtime, treat the site as vulnerable. A firewall or CDN may reduce exposure, but updating PHP is the required fix.[2][9]", "cited_urls": ["https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://automattic.com/2026/10/21/php2shell/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://straffesites.com/en/blog/php-vulnerability-wordpress", "https://arvindkumar.ca/blog/php2shell-wordpress/", "https://www.malcare.com/blog/php2shell-php-vulnerability/", "https://stackharbor.com/en/blog/php2shell-cve-2026-109618-109619-what-we-know/", "https://technext24.com/reviews/php2shell-security-flaws-websites-how-to-fix/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-perplexity-2", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is safe from PHP2Shell **only if its server runs a patched PHP version**—updating WordPress, themes, or plugins alone does not fix the vulnerability.[2][3]\n\nCheck **WordPress → Tools → Site Health → Info → Server** and inspect the PHP version. It should be at least:\n\n- PHP **8.5.12**\n- PHP **8.4.27**\n- PHP **8.3.36**\n- PHP **8.2.35**\n- Or a patched equivalent supplied by your Linux distribution[2][3]\n\nIf your site is hosted on **WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr**, the provider says it has already been protected.[1][2]\n\nIf you use another host:\n\n1. Ask the host whether PHP2Shell has been patched.\n2. Confirm the active PHP version in Site Health—not merely the version shown in a hosting panel.\n3. If it is older than the versions above, request an immediate PHP runtime update.\n4. Treat the site as vulnerable until the host confirms the fix; security plugins and Cloudflare rules may reduce exposure but are not a substitute for updating PHP.[5][9]", "cited_urls": ["https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://automattic.com/2026/10/21/php2shell/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://straffesites.com/en/blog/php-vulnerability-wordpress", "https://technext24.com/reviews/php2shell-security-flaws-websites-how-to-fix/", "https://arvindkumar.ca/blog/php2shell-wordpress/", "https://www.malcare.com/blog/php2shell-php-vulnerability/", "https://stackharbor.com/en/blog/php2shell-cve-2026-109618-109619-what-we-know/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-perplexity-3", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your site is safe from PHP2Shell **only if its server runs a patched PHP release**:\n\n- PHP 8.5.12 or newer\n- PHP 8.4.27 or newer\n- PHP 8.3.36 or newer\n- PHP 8.2.35 or newer\n- A Linux-distribution package containing the equivalent security fixes[2][3]\n\nCheck **WordPress → Tools → Site Health → Info → Server → PHP version**. Updating WordPress, plugins, themes, or security plugins alone does **not** fix PHP2Shell; the PHP runtime must be updated by your hosting provider.[3][4]\n\nIf your site is hosted on **WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr**, the provider says it is already protected.[1][2] If you use another host and the PHP version is older—or you cannot confirm that the host applied the patch—ask support specifically whether PHP2Shell has been fixed and avoid treating the site as safe until they confirm it.", "cited_urls": ["https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://automattic.com/2026/10/21/php2shell/", "https://wppoland.com/en/php2shell-wordpress-what-to-do/", "https://www.zarla.com/guides/php2shell", "https://meowapps.com/php2shell-wordpress/", "https://straffesites.com/en/blog/php-vulnerability-wordpress", "https://arvindkumar.ca/blog/php2shell-wordpress/", "https://www.malcare.com/blog/php2shell-php-vulnerability/", "https://stackharbor.com/en/blog/php2shell-cve-2026-109618-109619-what-we-know/", "https://technext24.com/reviews/php2shell-security-flaws-websites-how-to-fix/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-overviews-1", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is only safe if your server's underlying PHP version has been updated to fix CVE-2026-109618 and CVE-2026-109619 (known as PHP2Shell).\nUpdating WordPress core, themes, or plugins will not protect you, and standard WordPress security plugins (like Wordfence or Sucuri) cannot block the exploit because the vulnerability sits inside PHP itself before WordPress even loads.\nHow to Check If You Are Safe\nCheck Your PHP Version:\nIn your WordPress dashboard, go to Tools → Site Health → Info → Server, or ask your hosting provider what PHP version and patch level you are running.\nVerify Against Patched PHP Releases:\nPHP released official security patches on October 21, 2026. Your server must be running at least :\nPHP 8.5.12 (or newer)\nPHP 8.4.27 (or newer)\nPHP 8.3.36 (or newer)\nPHP 8.2.35 (or newer)\nNote: If your site runs PHP 8.1 or older, no official security patch is coming from PHP. You must upgrade your PHP version immediately.\nCheck Your Host:\nIf you use managed hosting (such as WordPress.com or Automattic-managed platforms), the host may have already patched the environment for you. If you manage a VPS, dedicated server, or standard shared host, you need to contact your host or update PHP through your control panel/server package manager.\nEmergency Steps If You Cannot Patch Right Away\nIf you cannot immediately update PHP, apply these temporary mitigations (though none of these replace a real PHP patch):\nDisable Session Upload Progress: Add session.upload_progress.enabled = Off to your php.ini or .user.ini file and restart PHP.\nWeb Application Firewall (WAF): Enable emergency WAF rules from providers like to help filter malicious file-upload attempts.\nCheck for Compromise: If your server was exposed before patching, inspect your site for unknown administrator accounts, suspicious .php files inside /wp-content/uploads/ , or modified core files.\nIf you'd like, let me know:\nWho your hosting provider is\nWhat PHP version your Site Health screen currently shows\nI can help you figure out the exact next step to lock down your site.", "cited_urls": ["https://xcloud.host/php2shell-wordpress/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://www.youtube.com/watch?v=bARTSb94a3A", "https://www.youtube.com/shorts/oUIPnXmdaiE", "https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://blog.cloudflare.com"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-overviews-2", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is not safe from PHP2Shell unless your server's underlying PHP version has been updated to a patched release (or your managed host has updated it for you).\nWhy Standard WordPress Updates Won’t Help\nThe bug is in PHP, not WordPress: PHP2Shell targets critical vulnerabilities in the PHP programming language itself (CVE-2026-109618 and CVE-2026-109619), rather than WordPress core, themes, or plugins.\nFirewalls won’t catch it: Security plugins and firewalls that run inside WordPress start after PHP processes the request, meaning they cannot block this unauthenticated remote code execution (RCE) attack.\nUpdating WordPress is not enough: Updating your WordPress version or your plugins will not patch this vulnerability.\nHow to Check and Fix It\nCheck your PHP version:\nIn your WordPress dashboard, go to Tools → Site Health → Server, or check your hosting control panel (cPanel, Plesk, etc.) to see what PHP version is running.\nUpdate PHP to a patched release:\nYou need to update your server to one of the officially patched PHP versions: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or newer).\nIf you are still running PHP 8.1 or older, those versions have reached end-of-life and will receive no official security patches; you must upgrade your PHP branch immediately.\nCheck with your hosting provider:\nIf you use managed hosting (such as WordPress.com ), the host may have already patched the environment at the server level.\nIf you manage your own server or traditional shared hosting, contact your host or update your PHP interpreter via your hosting panel straight away.\nIf you tell me who your hosting provider is or what PHP version is listed under your Site Health screen, I can help you figure out your next steps.", "cited_urls": ["https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://www.instagram.com/p/Deym53fEy4G/", "https://tutorlms.com/blog/php2shell-security-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-overviews-3", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is not automatically safe from the PHP2Shell vulnerabilities unless your server's underlying PHP installation has been patched. WordPress.com +1\nWhy WordPress Updates Won’t Save You\nThe flaw is in PHP, not WordPress: PHP2Shell targets critical remote code execution vulnerabilities in the PHP programming language itself (CVE-2026-109618 and CVE-2026-109619), rather than WordPress core, themes, or plugins . WP Umbrella\nBypasses WordPress defenses: Standard WordPress security plugins and firewalls run after PHP handles an incoming request, meaning they cannot block these unauthenticated exploit requests. WP Umbrella\nUpdating WordPress or plugins is not enough: You must update the actual PHP version running on your web server. WP Umbrella\nHow to Check and Protect Your Site\nHosting Type | Who Applies the Fix | Action Required\nManaged Hosting (e.g., WordPress.com , WP Cloud, Pressable) | The hosting provider patches PHP at the infrastructure level. | Verify with your host that they have applied the October 21, 2026 PHP security fixes.\nSelf-Hosted / VPS / Dedicated Servers (e.g., AWS, DigitalOcean, cPanel/WHM) | You are responsible for server-level updates. | Update PHP immediately to the patched releases (such as PHP 8.3/8.4 or supported versions with the security backports applied).\nIf you tell me who your hosting provider is (e.g., Bluehost, SiteGround, AWS, DigitalOcean) or what PHP version your server is currently running, I can guide you on how to check your status or apply the proper patch.", "cited_urls": ["https://wordpress.com/blog/2026/10/21/php2shell-vulnerabilities/", "https://wp-umbrella.com/blog/php2shell-what-the-critical-php-vulnerabilities-mean-for-wordpress-sites/", "https://www.youtube.com/shorts/oUIPnXmdaiE"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-mode-1", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Not automatically. Your WordPress site is only safe if the underlying PHP environment running on your web server has been updated with the emergency security patches released by the PHP team.\nThe PHP2Shell vulnerability involves two critical, unauthenticated remote code execution (RCE) flaws in the core PHP engine (CVE-2026-109618 and CVE-2026-109619, CVSS score 9.2). Because WordPress is built on PHP, every WordPress site running on an unpatched PHP version is at immediate risk. Crucially, standard WordPress security plugins or a Web Application Firewall (WAF) alone cannot completely block this exploit chain because the flaw exists in how the server processes raw PHP requests before WordPress code even executes.\nWhat you need to check and do right now:\nCheck your PHP version: Log into your WordPress dashboard, navigate to Tools > Site Health > Info, and look for the Server section to see what PHP version you are running. Alternatively, check your web hosting control panel (cPanel, Plesk, etc.).\nVerify the patch status: Ensure your server is running a actively supported and fully updated version of PHP (8.2, 8.3, 8.4, or 8.5) containing the official security fixes. If you are running an end-of-life version like 8.1 or older, it will not receive an official security patch—you must upgrade your PHP version immediately.\nContact your host: If you use managed hosting or a shared server, your hosting provider is responsible for applying the core PHP security update. Check your host's status page or reach out to their support team to confirm whether the server-level PHP patches have been deployed.\nIf you tell me who your hosting provider is or what PHP version your Site Health screen displays, I can help you figure out the exact next steps to secure your site.", "cited_urls": ["https://www.wiz.io/blog/php2shell-php-rce", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://www.facebook.com/groups/451021396991307/posts/1450983630328407/", "https://www.reddit.com/r/Wordpress/comments/1xbmw05/php_cve_notice/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-mode-2", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Whether your WordPress site is safe from the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) depends entirely on the PHP version running on your server, not your WordPress core, theme, or plugin versions.\nPHP2Shell targets the underlying PHP language engine itself rather than WordPress code. Unauthenticated attackers can leverage these critical remote code execution (RCE) and memory disclosure flaws on unsupported or unpatched PHP configurations.\n1. Check Your PHP Version\nYour site is vulnerable if your server is running any of the following unpatched PHP versions:\nAny version prior to PHP 8.2.35\nAny version in the PHP 8.3 branch prior to 8.3.36\nAny version in the PHP 8.4 branch prior to 8.4.27\nAny version in the PHP 8.5 branch prior to 8.5.12\nOlder, end-of-life/unsupported branches (including PHP 5.x and 7.x) are entirely unpatched and critically vulnerable.\nYour site is safe only if your hosting provider has already updated your server environment to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12, or higher.\n2. Immediate Action Steps\nBecause this is a server-side core PHP flaw, standard WordPress security plugins cannot patch it by themselves.\nContact Your Hosting Provider: Check your hosting dashboard or reach out to your host's support immediately to verify if they have applied the official PHP.net Security Advisories.\nTemporarily Take the Site Offline: If your host has not yet patched the environment and you are running an exposed configuration (especially high-risk setups like Apache mod_php or unmitigated PHP worker interfaces), government advisories from agencies like the NSA Advisory on PHP Vulnerabilities recommend taking public-facing systems offline until updates are live.\nIf you'd like, let me know:\nYour current PHP version (visible in your WordPress Tools > Site Health > Info > Server, or your host's control panel)\nWho your hosting provider is\nI can help you determine your risk level and what steps to take next.", "cited_urls": ["https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://www.wiz.io/blog/php2shell-php-rce", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/", "https://www.nsa.gov/press-room/press-releases-statements/press-release-view/article/4630238/nsa-advisory-critical-patches-recommended-for-php-vulnerabilities/", "https://www.hurriyet.com.tr/dunya/dunya-genelinde-siber-guvenlik-acigi-php-programlama-dilinde-sorunlar-tespit-edildi-kuresel-capta-devlet-siteleri-gecici-olarak-kapatildi-43350466", "https://www.php.net/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q06-google-ai-mode-3", "question_id": "Q06", "question": "Is my WordPress site safe from PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Your WordPress site is only safe if your server's underlying PHP installation has been updated to the newly released security patch versions (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12, or later).\nThe \"PHP2Shell\" threat (tracked as CVE-2026-109618 and CVE-2026-109619) is a critical remote code execution flaw residing in the PHP language engine itself rather than in WordPress core, themes, or plugins. Because it affects how the server processes web requests, simply updating your WordPress plugins or dashboard will not protect you.\nKey Details to Check\nYour PHP Version: Check your hosting control panel (cPanel, Plesk) or run a WordPress site health check to see what version of PHP your server is running. Versions prior to the October 21, 2026 emergency patches are vulnerable.\nEnd-of-Life PHP Risk: If your host is still running PHP 8.1 or older, no official patches will be released by the PHP team because those versions are end-of-life. You must upgrade your PHP runtime environment immediately.\nServer Configuration: Configurations utilizing Apache mod_php, PHP-FPM, or unpatched container environments are actively targeted, and active exploitation attempts have been observed in the wild.\nIf you want to check your status, reply with:\nYour current PHP version (found in your WordPress Site Health screen or host dashboard)\nYour hosting provider or server environment type\nI can help you determine if you need to contact your host or upgrade your environment right away.", "cited_urls": ["https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.wiz.io/blog/php2shell-php-rce", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-chatgpt-1", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Check both for exploitation attempts and for what an attacker may have left behind. A clean scan—or installing the patch—does not prove the server was never compromised.** PHP2Shell covers CVE-2026-109618 and CVE-2026-109619; some exploitation paths can leak PHP process memory without leaving a web shell. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Preserve evidence before cleaning up\n\nIf you see signs of an active intrusion, isolate the server using your firewall or cloud security controls while retaining a trusted administrative path. Before rebooting, deleting files, or rebuilding:\n\n- Preserve web access/error logs, PHP-FPM logs, system/authentication logs, and CDN/WAF logs—including rotated logs.\n- Take a disk snapshot or forensic image.\n- If incident-response support is available, capture memory and running-process/network information before restarting anything.\n- Store evidence off the affected host and record your actions and timestamps. ([cisa.gov](https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai))\n\n### 2. Establish your exposure window\n\nDetermine **which PHP runtime actually served requests**, its installed package version, and when patched workers started. Check every container, virtual host, and PHP-FPM pool—not just command-line PHP.\n\nThe upstream fixes released on **October 21, 2026** are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**; distribution packages may contain backported fixes. Installing a package is insufficient until the relevant workers restart. ([security.utoronto.ca](https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/))\n\nPrioritize logs around **October 20, 2026 onward**, when disclosure began, but review earlier retained logs too; disclosure is not proof of when an intrusion could first have occurred. ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))\n\n### 3. Look for PHP2Shell-related request and crash patterns\n\nCorrelate these by timestamp, URL, client, and worker:\n\n| Signal | What to investigate |\n|---|---|\n| Memory errors | Bursts of `Allowed memory size … exhausted` |\n| Worker crashes | PHP-FPM/Apache segmentation faults, aborted workers, unexplained restarts |\n| Request anomalies | Unusual multipart POSTs, excessive parts/headers, deeply nested fields |\n| HTTP errors | Repeated HTTP 500 responses associated with suspicious requests |\n| Response cookies | Unexpectedly large or malformed `PHPSESSID` values in `Set-Cookie`, **if captured** |\n\nThese are investigation leads, **not proof of successful exploitation**. Their absence also does not clear a server; application logs may miss activity occurring below the application layer. ([php2shell.com](https://www.php2shell.com/))\n\nFor a **Linux/systemd** server, this is an initial journal search—not a complete detector:\n\n```bash\nsudo journalctl --since \"2026-10-01\" --no-pager |\n grep -Ei 'Allowed memory size|segfault|segmentation fault|exited on signal|core dumped'\n```\n\nSearch your preserved PHP and web-server error logs for the same patterns, including compressed rotations.\n\n### 4. Hunt for successful compromise and persistence\n\nCheck for:\n\n- **Unexpected processes:** PHP/Apache spawning shells, interpreters, or download tools.\n- **Unexpected files:** new or changed PHP files, unfamiliar plugins/themes, and scripts in upload directories.\n- **Persistence:** unauthorized accounts, cron jobs, or scheduled tasks.\n- **Unexpected network activity:** investigate connections associated with suspicious processes.\n\nA PHP web shell can operate without creating child processes, so clean process monitoring is not enough. ([security.utoronto.ca](https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/))\n\nUseful initial Linux triage commands, after evidence preservation:\n\n```bash\n# Current processes and network connections\nsudo ps -eo user,pid,ppid,lstart,args --forest\nsudo ss -plant\n\n# Recently modified files; replace /var/www with your actual web roots\nsudo find /var/www -type f -newermt '2026-10-01' -ls\n```\n\nCompare findings against trusted deployment artifacts and known-good backups rather than treating unfamiliar names or recent timestamps alone as malicious. Preserve suspicious files for analysis instead of immediately deleting them. ([content.govdelivery.com](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/29cbfc6?utm_source=openai))\n\n### 5. Respond according to the evidence\n\n- **Suspicious requests/crashes only:** investigate further; they do not establish compromise.\n- **Unauthorized code, accounts, or persistence:** treat the server as compromised, although that alone does not establish PHP2Shell as the entry point.\n- **Confirmed compromise:** preserve evidence, rebuild from a trusted image, patch before reconnecting, and rotate potentially exposed credentials from a clean system. Include database credentials, API/cloud keys, and session secrets accessible to PHP. ([php2shell.com](https://www.php2shell.com/))\n\n**What OS, web server, PHP version, and hosting setup are you using—Apache/mod_php, Nginx/PHP-FPM, containers, or shared hosting?** I can tailor the commands and log locations to your server.", "cited_urls": ["https://www.php2shell.com/", "https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai", "https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/", "https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/", "https://content.govdelivery.com/accounts/USDHSCISA/bulletins/29cbfc6?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-chatgpt-2", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Check both exposure and evidence of intrusion—those are different questions.** PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. There is no single log entry or scanner result that can prove a server is clean: exploitation can disclose PHP process memory without installing a web shell or executing visible commands. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Preserve evidence before cleaning up\n\nIf you suspect active compromise, isolate the server using your firewall, cloud security controls, or EDR while retaining trusted administrative access. Preserve web/PHP logs, system journals, CDN/WAF logs, and disk snapshots; have your incident-response team capture memory if possible. **Avoid rebooting, deleting suspicious files, or running cleanup tools before evidence collection.** Don’t leave an actively compromised server exposed just to finish investigating. ([cisa.gov](https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai))\n\n### 2. Establish whether the web-facing PHP runtime was vulnerable\n\nThe first fixed upstream releases, issued **October 21, 2026**, are:\n\n| Branch | First fixed release |\n|---|---|\n| PHP 8.2 | 8.2.35 |\n| PHP 8.3 | 8.3.36 |\n| PHP 8.4 | 8.4.27 |\n| PHP 8.5 | 8.5.12 |\n\nCheck every application runtime, container, and PHP worker—not just the default installation. Distribution packages may contain backported fixes with older-looking version numbers, so compare the **full package version** against your OS vendor’s advisory. Updating PHP also requires restarting affected services/workers after evidence preservation. ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))\n\n### 3. Look for PHP2Shell-related request and crash patterns\n\nCorrelate these signals by timestamp, client, requested URL, and worker where available:\n\n- Unusual multipart requests followed by PHP memory-limit errors.\n- Bursts of HTTP 500 responses.\n- Unexplained PHP worker crashes or restarts.\n- Unexpectedly large or malformed **`PHPSESSID` response cookies**, if your telemetry recorded them.\n\nThese are investigation leads, **not proof of successful exploitation**. Application logs alone may miss the activity. Review the entire retained exposure period, not just the disclosure date. ([php2shell.com](https://www.php2shell.com/))\n\nFor a Linux/systemd server, this is a starting journal search; adjust the date to your investigation window:\n\n```bash\nsudo journalctl --since \"2026-10-01\" --no-pager |\n grep -Ei 'Allowed memory size|PHP Fatal error|segfault|SIGSEGV|SIGABRT|exited on signal'\n```\n\nSearch preserved PHP-FPM and Apache/Nginx error logs for the same patterns, including rotated logs. Correlate matches with access and WAF logs rather than treating isolated errors as attacks. ([php2shell.com](https://www.php2shell.com/))\n\n### 4. Hunt for successful compromise and persistence\n\nReview:\n\n- **Processes and connections:** unexpected shells, download utilities, or outbound connections associated with PHP/Apache.\n- **Files:** unexpected executable files or modifications to application code; compare against trusted deployment artifacts.\n- **Persistence:** unfamiliar cron jobs, systemd services, accounts, and SSH `authorized_keys`.\n- **Credential activity:** unusual database, cloud, or administrative logins following suspicious requests.\n\nUse historical EDR/audit/network records as well as the current system state. These are general compromise indicators; finding one does not by itself attribute the intrusion to PHP2Shell. ([content.govdelivery.com](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/29cbfc6))\n\nUseful current-state Linux commands:\n\n```bash\n# Process ancestry and command lines\nsudo ps -eo user,pid,ppid,lstart,args --forest\n\n# Current network connections and associated processes\nsudo ss -tunap\n\n# System-level scheduled timers\nsudo systemctl list-timers --all\n```\n\nThese support process, connection, and scheduled-task review; they are not a comprehensive forensic examination. ([content.govdelivery.com](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/29cbfc6))\n\n### 5. Act on the findings\n\nIf compromise is confirmed or strongly suspected, preserve evidence, rebuild from a trusted image, patch before returning to service, and revoke/rotate potentially exposed credentials from a clean system. Include secrets accessible to PHP and affected sessions—not just the administrator password. **Patching prevents further exploitation; it is not a substitute for removing existing persistence.** ([cisa.gov](https://www.cisa.gov/sites/default/files/publications/Cybersecurity_Incident_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai))\n\n**What OS or hosting platform are you using, and is it Apache/mod_php or PHP-FPM?** Share the PHP package version and any suspicious log excerpts—with secrets redacted—and I can tailor the checks.", "cited_urls": ["https://www.php2shell.com/", "https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai", "https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/", "https://content.govdelivery.com/accounts/USDHSCISA/bulletins/29cbfc6", "https://www.cisa.gov/sites/default/files/publications/Cybersecurity_Incident_Vulnerability_Response_Playbooks_508C.pdf?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-chatgpt-3", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Check for both exploitation attempts and what happened afterward—not just whether PHP is patched.** PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. There is no single reliable “compromised/not compromised” test: attackers may disclose PHP process memory without installing a web shell, and clean application logs do not rule that out. ([php2shell.com](https://www.php2shell.com/))\n\n### 1. Preserve evidence before cleaning up\n\nIf you suspect active compromise, isolate the server using your firewall, cloud security group, or endpoint security tool. Before restarting, deleting files, or rebuilding, preserve:\n- A disk/volume snapshot and, if your incident-response team can collect it, memory.\n- Web access/error logs, PHP/PHP-FPM logs, system and authentication logs—including rotated files.\n- CDN/WAF logs and available process/network telemetry.\n\nKeep copies off the affected host. Avoid powering it off unnecessarily, because that loses volatile evidence. ([cisa.gov](https://www.cisa.gov/stopransomware/ransomware-guide?utm_source=openai))\n\n### 2. Look for PHP2Shell-related signals\n\nCorrelate these by timestamp, requested URL, client, and worker/process where possible:\n\n| Signal | Where to look |\n|---|---|\n| Unusual multipart requests followed by memory-limit errors | WAF/request telemetry and PHP error logs |\n| Bursts of HTTP 500 responses | Web server/CDN logs |\n| Unexplained PHP worker crashes or frequent restarts | PHP-FPM, Apache, system journal |\n| Unexpectedly large or malformed `PHPSESSID` **response** cookies | Captured response headers or suitable proxy/security telemetry |\n\nThese are investigation leads, **not proof of successful exploitation**. Their absence also does not establish safety. ([wiz.io](https://www.wiz.io/blog/php2shell-php-rce))\n\nFor a Linux server, this is a starting search of **uncompressed** logs; adjust paths and also examine archived `.gz` logs:\n\n```bash\nsudo grep -RniE \\\n 'Allowed memory size|Out of memory|segfault|segmentation fault|exited on signal' \\\n /var/log/apache2 /var/log/httpd /var/log/nginx \\\n /var/log/php* 2>/dev/null\n```\n\nReview all available history covering your exposure—not only events after the October 21, 2026 patch release. That release date does not establish when any particular server was first attacked. ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))\n\n### 3. Hunt for evidence of actual compromise\n\nCompare against trusted deployment artifacts or a known-good baseline, looking for:\n\n- New or modified web-accessible files, especially unexpected executable files in upload/cache directories.\n- Requests to unfamiliar scripts, followed by unusual outbound connections.\n- Unexpected shell commands or processes launched by the web server.\n- Unauthorized accounts, scheduled tasks, services, or other persistence.\n\nInvestigate suspicious files in context rather than assuming every unfamiliar file is malicious. A confirmed web shell establishes compromise, but does **not by itself identify PHP2Shell as the entry point**. ([media.defense.gov](https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF?utm_source=openai))\n\nUseful live Linux triage commands include:\n\n```bash\n# Current processes, including parent PIDs\nsudo ps -eo user,pid,ppid,lstart,args --forest\n\n# Current TCP/UDP sockets and associated processes\nsudo ss -tunap\n```\n\nPreserve the output alongside historical telemetry; a current process listing is only a snapshot, not a record of earlier activity. ([cisa.gov](https://www.cisa.gov/stopransomware/ransomware-guide?utm_source=openai))\n\n### 4. Verify remediation separately\n\nThe first upstream fixed releases were **8.2.35, 8.3.36, 8.4.27, and 8.5.12**, released October 21, 2026. Check your distribution/vendor’s package advisory as well. Update every affected runtime and restart the relevant PHP-FPM/Apache services and long-running workers after evidence collection. Application updates alone are insufficient. ([thephp.foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/))\n\n### 5. If you find convincing evidence\n\nTreat it as an incident: isolate, preserve evidence, investigate the scope, and recover onto a clean, patched system rather than merely deleting a suspicious file. Revoke or rotate potentially exposed credentials and investigate their use elsewhere; PHP memory can contain passwords, tokens, and API keys. ([ncsc.gov.uk](https://www.ncsc.gov.uk/collection/vulnerability-management/guidance/responding-to-active-exploitation?utm_source=openai))\n\n**What OS/hosting platform, web server, and PHP version are you running—and do you have SSH access?** I can tailor the log paths and checks to your setup.", "cited_urls": ["https://www.php2shell.com/", "https://www.cisa.gov/stopransomware/ransomware-guide?utm_source=openai", "https://www.wiz.io/blog/php2shell-php-rce", "https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/", "https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF?utm_source=openai", "https://www.ncsc.gov.uk/collection/vulnerability-management/guidance/responding-to-active-exploitation?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-claude-1", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a comprehensive guide on how to check if your server was compromised by **PHP2Shell** (CVE-2026-109618 and CVE-2026-109619):\n\n---\n\n## 🔍 What is PHP2Shell?\n\n\nPHP2Shell is the name researchers gave CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP interpreter that can let an unauthenticated web request run code as the web worker account.\n \nBoth carry a CVSS v4.0 severity score of 9.2.\n\n\n\nExploitation happens below the application layer, so application logs may record limited context.\n This makes detection more challenging than typical attacks.\n\n---\n\n## ✅ Step 1: Check If Your PHP Version Is Vulnerable\n\n\nThe affected and first fixed releases by branch are:\n- **8.2**: Before 8.2.35 → Fixed in 8.2.35\n- **8.3**: Before 8.3.36 → Fixed in 8.3.36\n- **8.4**: Before 8.4.27 → Fixed in 8.4.27\n- **8.5**: Before 8.5.12 → Fixed in 8.5.12\n\n\n\nPHP 8.1 and earlier are end-of-life and remain vulnerable. The PHP Project has published source-only backports for 7.4, 8.0, and 8.1; no binary releases will be provided, and systems on these versions should be upgraded to a supported branch.\n\n\nYou can audit your PHP version with these commands:\n\n\n\n- **Ubuntu/Debian**: `dpkg -l | grep php`\n- **Ubuntu/Debian (CVE check)**: `apt changelog php8.3-cli | grep -E \"CVE-2026-109618|CVE-2026-109619\"`\n- **RHEL/Rocky/AlmaLinux/CentOS**: `rpm -qa | grep php`\n- **RHEL/Rocky/AlmaLinux (CVE check)**: `rpm -q php-cli --changelog | grep -E \"CVE-2026-109618|CVE-2026-109619\"`\n\n\n\n\nThe PHP Project considers **Apache mod_php** deployments to be at highest risk; PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also affected.\n\n\n---\n\n## ✅ Step 2: Inspect Web Server & PHP Logs\n\n\nBoth vulnerabilities are triggered by errors inside a request, so PHP and web server logs are a useful starting point. Look for unusually large or deeply nested multipart requests, PHP workers that crashed or hit their memory limit, and files written to web roots or outbound connections from PHP processes that you cannot explain.\n\n\nSpecifically look for:\n\n- \nMultipart POST requests to endpoints that don't normally process uploads, repeated requests with unusually large bodies, abnormal request sizes or missing usable content-length information, excessive multipart field or header structures, multiple suspicious requests targeting the same application within a short period, and requests followed by PHP errors, HTTP 500 responses, or unusual worker behavior.\n\n\n- \n[Redacted: exploit mechanics omitted from this public research copy.]\n\n\n---\n\n## ✅ Step 3: Monitor Process Activity\n\n\nLook for PHP or web server workers — including `apache2`, `httpd`, `php-cgi`, `php-fpm`, and `lsphp` — spawning unexpected shells (e.g., `sh`, `bash`, `dash`), scripting interpreters (e.g., `python`, `perl`), download utilities (e.g., `curl`, `wget`), reconnaissance commands (e.g., `id`, `whoami`, `uname`), or other unusual child processes.\n\n\n---\n\n## ✅ Step 4: Look for Post-Exploitation Artifacts\n\n\nEvidence of unauthorized command execution, web-shell activity, unexplained outbound connections, or suspicious persistence should trigger a formal incident investigation.\n\n\nAlso, \nthe same flaws can also disclose live worker memory, which may hold passwords, tokens, and keys, without executing code.\n So you should:\n\n- \nIdentify credentials and secrets accessible to the affected PHP worker, which may include database passwords, cloud credentials, application tokens, API keys, and other sensitive configuration data.\n\n\n---\n\n## ✅ Step 5: Preserve Evidence Before Patching\n\n\nCapture volatile evidence **before** patching on any suspected host. Restarting workers wipes the in-memory state that CVE-2026-109619 abuses. Collect memory from the PHP worker processes and the web server, plus the process tree, network connections, and open files — then patch.\n\n\n---\n\n## ✅ Step 6: Determine the Level of Compromise\n\nIt is important to differentiate between scanning, attempted exploitation, and full compromise:\n\n- \n**Scanning**: Someone is probing the application or looking for vulnerable behavior.\n\n- \n**Attempted exploitation**: The activity resembles a known exploitation technique but success hasn't been established.\n\n- \n**Confirmed compromise**: There is evidence of unauthorized execution, access, disclosure, persistence, or another security impact.\n\n\n\nAn attacker sending a malicious HTTP request doesn't necessarily mean the server was compromised. Likewise, a lack of obvious post-exploitation artifacts doesn't automatically mean exploitation failed.\n\n\n---\n\n## 🛠️ Remediation\n\n1. \nThe only complete fix is updating to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, matching the branch in use. PHP states no configuration change fully closes the vulnerability.\n\n2. \nRotate or revoke potentially exposed secrets as part of coordinated containment and recovery.\n\n3. \nPreserve relevant evidence and determine whether attackers gained access to application data, credentials, or connected internal systems.\n\n4. \nNote that compromise can spread past the web server — for example, PHP hosts that also expose SSH, MySQL, or RDP present additional lateral movement risk.\n\n\n---\n\n**Bottom line**: Start with your PHP version, comb through web server and PHP error logs for memory exhaustion and large multipart POSTs, check for unexpected child processes from web workers, and patch immediately to the fixed PHP versions.", "cited_urls": ["https://www.prophetsecurity.ai/blog/php2shell", "https://www.sygnia.co/threat-reports-and-advisories/php2shell-two-critical-php-vulnerabilities-expose-web-servers-to-remote-code-execution/", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/", "https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell", "https://arcticwolf.com/resources/blog/arctic-wolf-labs-finding-prioritizing-and-patching-php2shell-exposure/", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://medium.com/@seiferboado101/hunting-php2shell-a-practical-guide-for-soc-and-dfir-teams-e092c540afa1", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-claude-2", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a comprehensive guide on how to check if your server was compromised by **PHP2Shell** (CVE-2026-109618 & CVE-2026-109619):\n\n---\n\n## 🔍 What is PHP2Shell?\n\n\nPHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP that can allow unauthenticated remote code execution.\n \nNotably, application-level authentication **cannot** block an attack — PHP processes the malicious request before any application code runs.\n\n\n---\n\n## ⚠️ Important Note on Log Visibility\n\n\nExploitation happens below the application layer, so application logs may record **limited context**.\n This means you must look at multiple data sources, not just application logs.\n\n---\n\n## Step 1: Check Your PHP Version\n\n\nThe affected and fixed versions are:\n| Branch | Affected | Fixed |\n|--------|----------|-------|\n| PHP 8.2.x | < 8.2.35 | 8.2.35 |\n| PHP 8.3.x | < 8.3.36 | 8.3.36 |\n| PHP 8.4.x | < 8.4.27 | 8.4.27 |\n| PHP 8.5.x | < 8.5.12 | 8.5.12 |\n| PHP 7.4, 8.0, 8.1 | All versions | No official release — use a distribution or LTS vendor package |\n| PHP 7.3 and older | All versions | No fix — upgrade to a supported branch |\n\n\nRun `php -v` to check your current version.\n\n---\n\n## Step 2: Hunt for Suspicious HTTP Requests in Web Logs\n\n\nLook for patterns such as:\n- Multipart POST requests to endpoints that don't normally process uploads\n- Repeated requests with unusually large bodies\n- Abnormal request sizes or missing usable content-length information\n- Excessive multipart field or header structures (where body inspection is available)\n- Multiple suspicious requests targeting the same application within a short period\n- Requests followed by PHP errors, HTTP 500 responses, or unusual worker behavior\n\n\n\n[Redacted: exploit mechanics omitted from this public research copy.]\n\n\n\nAdditionally, look for **malformed PHPSESSID cookies** as part of these signals.\n\n\n---\n\n## Step 3: Check for Suspicious Process Activity\n\n\nLook for PHP or web-server workers — including `apache2`, `httpd`, `php-cgi`, `php-fpm`, and `lsphp` — **spawning unexpected shells** (e.g., `sh`, `bash`, `dash`), scripting interpreters (e.g., `python`, `perl`), download utilities (e.g., `curl`, `wget`), reconnaissance commands (e.g., `id`, `whoami`, `uname`), or other unusual child processes.\n\n\n\nOn Windows, watch for PHP worker processes starting shells such as `cmd.exe` or `powershell.exe`.\n\n\n---\n\n## Step 4: Look for Post-Exploitation Artifacts\n\n\nIf an alert fires, **isolate the server**, preserve web server and PHP logs, and hunt for:\n- Web shells\n- New files in the web root\n- New cron jobs or scheduled tasks\n- Unexpected user accounts\n\n\n\nMore broadly, evidence of unauthorized command execution, web-shell activity, unexplained outbound connections, or suspicious persistence should trigger a formal incident investigation.\n\n\n---\n\n## Step 5: Check for Exposed Credentials\n\n\nIf compromise is suspected, identify credentials and secrets accessible to the affected PHP worker. This may include **database passwords**, **cloud credentials**, **application tokens**, **API keys**, and other sensitive configuration data. Rotate or revoke potentially exposed secrets** as part of coordinated containment and recovery.\n\n\n---\n\n## Step 6: Correlate Signals — Don't Rely on a Single Indicator\n\n\nAn attacker sending a malicious HTTP request doesn't necessarily mean the server was compromised. Likewise, a lack of obvious post-exploitation artifacts doesn't automatically mean exploitation failed.\n \nCorrelate these signals with process activity, since individual errors do not establish exploitation.\n\n\n---\n\n## ✅ Remediation\n\n1. **Patch immediately:** \nUpgrade to the fixed PHP versions. Upgrading is the only complete remediation for both CVE-2026-109618 and CVE-2026-109619. There are no configuration-only workarounds that fully address both issues.\n\n\n2. **Partial mitigations if you can't patch yet:**\n - \nFor CVE-2026-109618: set `memory_limit=-1` in a way applications cannot override (e.g., `php_admin_value` in the FPM pool or Apache config), keep `post_max_size` low, and enforce a container or cgroup limit.\n\n - \nFor CVE-2026-109619: set `session.upload_progress.enabled=0` and restart every worker, which blocks the confirmed session paths but not all variants. On PHP 8.5, also set `fatal_error_backtraces=0`.\n\n\n3. \nConsider **blocking multipart file uploads** in PHP deployments that cannot be patched immediately, but determine how this would affect your application prior to deploying.\n\n\n---\n\n> **Summary:** Check your PHP version, audit web server logs for large/malformed POST requests, inspect process trees for unexpected shell children of PHP workers, look for new files/cron jobs/accounts, and rotate any potentially exposed credentials. Then patch to the fixed PHP version as soon as possible.", "cited_urls": ["https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://medium.com/@seiferboado101/hunting-php2shell-a-practical-guide-for-soc-and-dfir-teams-e092c540afa1", "https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/", "https://www.sygnia.co/threat-reports-and-advisories/php2shell-two-critical-php-vulnerabilities-expose-web-servers-to-remote-code-execution/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://www.elastic.co/security-labs/threat-command/php2shell-php-rce-detection"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-claude-3", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a comprehensive guide on how to check if your server was compromised by **PHP2Shell** (CVE-2026-109618 & CVE-2026-109619):\n\n---\n\n## 🔍 What Is PHP2Shell?\n\n\nPHP2Shell is the name researchers use for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 on CVSS v4.0.\n \nThese vulnerabilities can allow unauthenticated remote code execution (RCE).\n\n\n> ⚠️ **Important note:** \nExploitation happens below the application layer, so application logs may record limited context.\n Also, \nan attacker sending a malicious HTTP request doesn't necessarily mean the server was compromised. Likewise, a lack of obvious post-exploitation artifacts doesn't automatically mean exploitation failed.\n\n\n---\n\n## 🧪 Step 1: Check Your PHP Version (Exposure Check)\n\n\nRun `php -v`. The command-line binary can differ from the one your web server uses, so also check `php-fpm -v` or the Apache module. Compare with patched versions: 8.5.12, 8.4.27, 8.3.36, or 8.2.35.\n\n\nYou can also check your session upload progress setting, which is a relevant attack surface:\n\n```bash\nphp -v\nphp -i | grep -i session.upload_progress\nphp-fpm -v\ncurl -sI https://www.example.com/ | grep -iE \"^(server|x-powered-by):\"\n```\n\n---\n\n## 📋 Step 2: Review Your Logs\n\n\nBoth vulnerabilities are triggered by errors inside a request, so PHP and web server logs are a useful starting point. Look for unusually large or deeply nested multipart requests, PHP workers that crashed or hit their memory limit, and files written to web roots or outbound connections from PHP processes that you cannot explain.\n\n\n\nReview web server, application, and endpoint telemetry for anomalous HTTP requests, PHP process failures, unexpected command execution, and other indicators of malicious activity. Prioritize reviewing activity beginning October 20, 2026.\n\n\n**Key log signals to look for:**\n\n- \nUnusual multipart requests followed by memory limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies, and unexplained PHP worker churn.\n\n- \nOdd multipart POSTs, fatal errors, `Maximum execution time exceeded`, and unexpected PHP-FPM child exits.\n\n\n---\n\n## ⚙️ Step 3: Hunt for Suspicious Process Activity\n\n\nThis is where you should start looking for evidence of actual compromise. If a PHP worker suddenly launches a shell, downloader, or unexpected interpreter, you want to know why.\n\n\nSpecifically, \nwatch for PHP or web-server workers — including `apache2`, `httpd`, `php-cgi`, `php-fpm`, and `lsphp` — spawning unexpected shells (e.g., `sh`, `bash`, `dash`), scripting interpreters (e.g., `python`, `perl`), download utilities (e.g., `curl`, `wget`), reconnaissance commands (e.g., `id`, `whoami`, `uname`), or other unusual child processes.\n\n\nAlso watch for: \ncommand-line strings with `/dev/tcp/`, `fsockopen` or `mkfifo`, and reconnaissance commands such as `whoami`, `id`, `uname -a` and `ipconfig` run by the web server.\n\n\n---\n\n## 🗂️ Step 4: Scan the File System for Web Shells & New Files\n\n\nCheck for signs of compromise: unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, oversized or malformed PHPSESSID cookies, unexplained PHP worker restarts, web shells, unexpected files, new admin users, modified PHP files and odd outbound connections.\n\n\nUse these commands to find suspicious PHP files:\n\n```bash\n# Look for dangerous function usage (potential web shells)\ngrep -rnE \"eval|assert|system|exec|shell_exec|passthru|popen|proc_open\" /var/www --include=\"*.php\"\n\n# Hunt for obfuscation\ngrep -rlnE \"base64_decode|gzinflate|str_rot13\" /var/www --include=\"*.php\"\n```\n\n\nLook for PHP files in upload or cache directories, recently modified scripts that do not match a deploy, heavy base64 or `gzinflate` obfuscation, and web server logs showing repeated POST requests to a single unusual file.\n\n\n---\n\n## 🔎 Step 5: Check for Persistence Mechanisms\n\n\nCheck the web root for new files, look for odd processes, cron jobs, accounts and outbound connections, and review logs from 20 October onward.\n\n\n\nAlso check outbound connections from PHP workers, new cron jobs, users, and SSH keys.\n\n\n---\n\n## 🚨 Step 6: If You Find Signs of Compromise\n\n\nHuntress advises you to isolate the server and keep the web server and PHP logs. Then look for web shells, new files in the web root, cron jobs, scheduled tasks, and new accounts.\n\n\n\nIdentify credentials and secrets accessible to the affected PHP worker — this may include database passwords, cloud credentials, application tokens, API keys, and other sensitive configuration data. Rotate or revoke potentially exposed secrets as part of coordinated containment and recovery.\n\n\n---\n\n## 🛡️ Quick Reference Checklist\n\n| Area | What to Check |\n|---|---|\n| **PHP Version** | Compare to patched versions (8.5.12, 8.4.27, 8.3.36, 8.2.35) |\n| **Web Server Logs** | Oversized POSTs, memory errors, HTTP 500s, malformed PHPSESSID |\n| **Process Lineage** | PHP workers spawning shells, `curl`, `wget`, `python`, `perl` |\n| **File System** | New `.php` files, modified scripts, files in upload/cache dirs |\n| **Persistence** | New cron jobs, accounts, SSH keys |\n| **Network** | Unexplained outbound connections from PHP processes |\n| **Credentials** | Rotate DB passwords, API keys, cloud credentials if suspected |\n\n---\n\n> 💡 **Tip:** \nThere is a free checker script (`check-php2shell.sh`) that reports key ini values and partial mitigations, then hunts PHP-FPM, Apache, nginx, PHP, syslog, and journald logs for memory exhaustion and worker crashes.\n Look for it from security vendors like Cybaverse or Brandefense.", "cited_urls": ["https://www.cybaverse.co.uk/en/php2shell-checker", "https://www.sygnia.co/threat-reports-and-advisories/php2shell-two-critical-php-vulnerabilities-expose-web-servers-to-remote-code-execution/", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://medium.com/@seiferboado101/hunting-php2shell-a-practical-guide-for-soc-and-dfir-teams-e092c540afa1", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://safeguard.sh/resources/blog/php-webshell", "https://safeguard.sh/resources/blog/php2shell-after-patching-check-for-compromise"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-perplexity-1", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Treat PHP2Shell as a potential **full server compromise**, not merely a PHP-version issue. First preserve evidence, then isolate the host if you find suspicious activity.\n\n## 1. Check whether the running PHP is patched\n\nCheck both CLI PHP and the PHP runtime used by the web server—these can differ:\n\n```bash\nphp -v\nphp-fpm8.3 -v # adjust version as needed\nsystemctl list-units --type=service | grep -i php\nps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp'\n```\n\nCompare the installed package with your operating system’s security advisory and the vendor’s fixed release. Do not rely solely on `php -v`; confirm the PHP-FPM/CGI version actually serving requests.[1][4]\n\nAlso check the relevant configuration:\n\n```bash\nphp -i | grep session.upload_progress.enabled\nphp-fpm8.3 -i | grep session.upload_progress.enabled\n```\n\nDo **not** send exploit traffic to test the server; safe checks are version/configuration checks and passive investigation.[6]\n\n## 2. Preserve evidence before restarting or cleaning\n\nSave logs, process lists, configuration, and suspicious files before rebooting or restarting PHP-FPM:\n\n```bash\nmkdir -p /root/php2shell-evidence\ncp -a /var/log /root/php2shell-evidence/logs\nps auxwwf > /root/php2shell-evidence/processes.txt\nss -plant > /root/php2shell-evidence/network.txt\n```\n\nRestarting services can erase useful in-memory evidence, and log rotation may remove relevant requests.[7]\n\n## 3. Search logs for exploitation indicators\n\nReview PHP-FPM, Apache, Nginx, WAF, CDN, and IDS logs, especially from the date the vulnerability became known:\n\n```bash\ngrep -RniE \\\n[Redacted: exploit mechanics omitted from this public research copy.]\n/var/log/php* /var/log/apache2 /var/log/nginx 2>/dev/null\n```\n\n[Redacted: exploit mechanics omitted from this public research copy.]\n\nA clean access log does **not** rule out compromise: successful exploitation may return HTTP 200 and leave the worker running.[7]\n\n## 4. Hunt for post-exploitation activity\n\nCheck for shells or downloaders launched by PHP, Apache, or the web account:\n\n```bash\nps -eo user,pid,ppid,lstart,cmd --forest\nps -u www-data -o pid,ppid,lstart,cmd\n```\n\nInvestigate unexpected processes such as `sh`, `bash`, `curl`, `wget`, `python`, `perl`, or `nc` whose parent is PHP-FPM or the web server.[3]\n\nFind recently created or modified PHP-related files:\n\n```bash\nfind /var/www -type f \\\n\\( -name '*.php' -o -name '.user.ini' -o -name '.htaccess' \\) \\\n-newermt '2026-10-17' -ls\n```\n\nPay particular attention to upload, cache, temporary, and writable directories. Also inspect cron jobs, system/application accounts, SSH keys, and outbound connections to unfamiliar hosts.[3][5]\n\n## 5. Use a read-only checker, cautiously\n\nA community checker can automate vulnerability and compromise indicators:\n\n```bash\ncurl -fsSLO https://raw.githubusercontent.com/SPOTWHALE/php2shell-check/main/check-php2shell.sh\nsudo bash check-php2shell.sh --hunt\n```\n\nTreat its result as a triage aid, not proof that the server is clean; independent forensic review is still needed.[2]\n\n## If you find evidence of compromise\n\n- Isolate the server from the internet while preserving disk and memory evidence.\n- Do not simply delete webshells or reinstall PHP.\n- Rotate all credentials accessible from the host: SSH keys, API tokens, database passwords, cloud credentials, and application secrets.\n- Rebuild from a known-clean image or verified backup.\n- Review adjacent systems for reused credentials and suspicious outbound activity.\n- Have an incident-response professional examine the host if it handles sensitive data.\n\nPatch or update PHP through your operating-system/vendor channel, verify the web-facing runtime afterward, and continue monitoring for new files, child processes, accounts, cron entries, and outbound connections.", "cited_urls": ["https://help.defense.com/en/articles/17703746-how-to-check-if-you-re-affected-by-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/SPOTWHALE/php2shell-check", "https://php2shell.eu/guides/php2shell-detection-incident-response/", "https://www.reflectiz.com/blog/php2shell-cve-2026-109618-109619/", "https://cve.tools/blog/php2shell-cve-2026-109618-cve-2026-109619", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://github.com/ersinkoc/php-fix", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-perplexity-2", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Treat this as a potential incident: **do not send exploit payloads to test the server**. First preserve evidence, then check patch status and indicators of compromise.\n\n## 1. Preserve evidence and contain the host\n\n- Save PHP-FPM, web-server, WAF/CDN, authentication, and EDR logs before restarting or cleaning anything; a restart can erase in-memory evidence and log rotation can remove relevant records.[1]\n- If compromise is plausible, isolate the server from the network while preserving management access, or place it behind a maintenance page/WAF.\n- Do not delete suspicious files or reboot until logs, timestamps, and forensic images are preserved.\n\n## 2. Confirm the PHP version actually serving requests\n\nThe command-line PHP version may differ from PHP-FPM, Apache, LiteSpeed, or FrankenPHP.[2]\n\n```bash\nphp -v\nphp-fpm -v 2>/dev/null\nsystemctl list-units --type=service | grep -i php\nps -ef | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]itespeed'\napachectl -M 2>/dev/null | grep -i php\n```\n\nCheck your distribution’s security notice or package changelog for fixes to **CVE-2026-109618** and **CVE-2026-109619**; vendor backports may show a patched package even when the version number looks older.[1][6]\n\nAlso inspect the configuration used by the web-serving PHP runtime:\n\n```bash\nphp -i | grep session.upload_progress.enabled\nphp-fpm8.3 -i | grep session.upload_progress.enabled # adjust version\n```\n\n## 3. Search logs for exploitation attempts\n\nLook in web-server, PHP-FPM, and WAF/CDN logs for:\n\n[Redacted: exploit mechanics omitted from this public research copy.]\n- Multipart POST requests containing unusual file uploads\n- Bursts of HTTP 500 responses\n- Memory-limit errors\n- PHP-FPM worker crashes, `SIGSEGV`, `SIGBUS`, or unexplained restarts\n\nExamples:\n\n```bash\n[Redacted: exploit mechanics omitted from this public research copy.]\n /var/log/php* /var/log/apache2 /var/log/nginx 2>/dev/null\n\njournalctl -u 'php*-fpm*' --since '2026-10-17' |\n grep -Ei 'segfault|signal|restart|memory'\n```\n\nA clean access log does **not** rule out compromise: successful exploitation may return a normal HTTP 200, and request bodies are often absent from ordinary web logs.[3][7]\n\n## 4. Hunt for post-exploitation activity\n\nCheck for web workers launching commands or download tools:\n\n```bash\nps -eo pid,ppid,user,lstart,cmd --forest |\n grep -B1 -E '\\b(sh|bash|curl|wget|python[0-9]?|perl|nc)\\b'\n```\n\nFind recently created or modified PHP-related files:\n\n```bash\nfind /var/www -type f \\\n \\( -name '*.php' -o -name '.user.ini' -o -name '.htaccess' \\) \\\n -newermt '2026-10-17' -ls\n```\n\nAlso inspect:\n\n- Upload, cache, temporary, and web-root directories for unfamiliar `.php` files or obfuscated webshells\n- Cron jobs and systemd timers\n- New local accounts and SSH keys\n- PHP/web-user command history and process activity\n- Unexpected outbound connections from PHP-FPM or the web server\n- Application, database, and API credentials that may have been readable by the web user\n\nThese are stronger compromise indicators than the initial crash or request itself.[3][10]\n\n## 5. Use scanners carefully\n\nA read-only checker can help automate version and host-hunting checks, but review its script before running it and treat results as leads—not proof. For example, the `php2shell-check` project provides a `--hunt` mode for suspicious files, processes, cron jobs, and related indicators.[2]\n\nIf you find evidence of command execution, persistence, modified application files, or stolen credentials, treat the host as compromised: rebuild from a known-clean image, rotate all secrets reachable from it, invalidate sessions/tokens, and investigate neighboring systems.", "cited_urls": ["https://help.defense.com/en/articles/17703746-how-to-check-if-you-re-affected-by-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/SPOTWHALE/php2shell-check", "https://php2shell.eu/guides/php2shell-detection-incident-response/", "https://www.reflectiz.com/blog/php2shell-cve-2026-109618-109619/", "https://cve.tools/blog/php2shell-cve-2026-109618-cve-2026-109619", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://github.com/ersinkoc/php-fix", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-perplexity-3", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Treat PHP2Shell as a possible **server compromise**, not merely a vulnerable-version check. Do not send exploit traffic to the server; no safe public exploit test is currently established.[6]\n\n1. **Preserve evidence first**\n - Restrict the server’s outbound network access or isolate it, while preserving forensic access.\n - Save PHP-FPM, web-server, WAF/CDN, authentication, and system logs before restarting services or cleaning files; restarts and log rotation can destroy useful evidence.[7][10]\n\n2. **Verify the PHP version actually serving requests**\n ```bash\n php -v\n php-fpm8.3 -v # adjust version\n ps -ef | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]itespeed'\n ```\n Check every FPM/CGI version and compare against your operating system vendor’s patched package or security advisory. The CLI version may differ from the web server’s PHP version.[1][4] Also check whether `session.upload_progress.enabled` is enabled in the FPM configuration.[6]\n\n3. **Search logs for likely attack indicators**\n ```bash\n[Redacted: exploit mechanics omitted from this public research copy.]\n /var/log/nginx /var/log/apache2 /var/log/httpd 2>/dev/null\n\n grep -hE 'SIGSEGV|signal 11|SIGBUS|Segmentation fault|exited on signal|in Unknown on line 0' \\\n /var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log 2>/dev/null\n ```\n[Redacted: exploit mechanics omitted from this public research copy.]\n\n4. **Hunt for post-exploitation activity**\n ```bash\n find /var/www -type f \\( -name '*.php' -o -name '.user.ini' -o -name '.htaccess' \\) \\\n -newermt '2026-10-17' -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\\n'\n\n ps -eo pid,ppid,user,lstart,cmd --forest | \\\n grep -E '\\b(sh|bash|curl|wget|python3?|perl|nc)\\b'\n\n find /var/spool/cron /etc/cron* -type f -ls 2>/dev/null\n ```\n Investigate new or modified PHP files—especially under upload, cache, and temporary directories—plus shells or download tools spawned by PHP/web-server workers, new cron jobs, accounts, SSH keys, and unfamiliar outbound connections.[3][5][10]\n\n5. **Use a read-only checker as a second opinion**\n ```bash\n curl -fsSLO https://raw.githubusercontent.com/SPOTWHALE/php2shell-check/main/check-php2shell.sh\n sudo bash check-php2shell.sh --hunt\n ```\n Review the script before executing it and treat its result as a lead, not proof; it checks common indicators but cannot establish that a clean server was never compromised.[2]\n\nIf you find a suspicious webshell, unauthorized account, command execution, or unexplained outbound traffic, keep the host isolated, preserve a disk image and logs, rotate credentials from a separate trusted machine, patch or replace the server, and have an incident-response professional examine it. Do not simply delete suspicious files and continue operating the host.", "cited_urls": ["https://help.defense.com/en/articles/17703746-how-to-check-if-you-re-affected-by-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/SPOTWHALE/php2shell-check", "https://php2shell.eu/guides/php2shell-detection-incident-response/", "https://www.reflectiz.com/blog/php2shell-cve-2026-109618-109619/", "https://cve.tools/blog/php2shell-cve-2026-109618-cve-2026-109619", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://github.com/ersinkoc/php-fix", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-google-ai-overviews-1", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check if your server was compromised by the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), inspect your server for unauthorized processes, modified files, and persistence mechanisms . Because PHP2Shell exploits occur below the application layer, standard application logs may show very little evidence.\n1. Check for Suspicious Process Spawns\nPHP2Shell allows unauthenticated remote code execution as the web worker account (such as www-data, apache, or nginx). Look for PHP workers spawning shell interpreters or download tools:\nReview running processes for unexpected shell commands or scripts:\nCheck if php-fpm, php-cgi, or your web server (httpd, apache2 ) has spawned interactive shells or external binaries.\nUse process monitoring tools or audit logs to see if PHP worker processes have executed child commands.\n2. Hunt for Web Shells and New Files\nAttackers often drop web shells or payload scripts into the web root to maintain access:\nSearch for recently created or modified files in your web document roots (e.g., /var/www/, /usr/share/nginx/html/):\nLook for hidden files (.php files starting with a dot) or obfuscated PHP code inside uploads or cache directories.\n3. Check for Persistence Mechanisms\nIf an attacker gained code execution, they may have established persistence:\nCron jobs: Inspect system and user crontabs for unauthorized scheduled tasks:\nSystem accounts: Check /etc/passwd for newly created or modified user accounts or unexpected SSH authorized keys (~/.ssh/authorized_keys ).\n4. Verify Your PHP and Vulnerability Exposure\nBefore hunting for compromise, verify whether your server was actually running a vulnerable version and check if it is patched:\nCheck the real PHP runtime version used by your web server (not just the CLI version, as they may differ):\nCompare your version against the fixed releases shipped on October 21, 2026:\nPHP 8.5: Fixed in 8.5.12\nPHP 8.4: Fixed in 8.4.27\nPHP 8.3: Fixed in 8.3.36\nPHP 8.2: Fixed in 8.2.35\nIf you use Linux distribution packages (Ubuntu, Debian, Red Hat, etc.), check your vendor's security advisory changelog, as packages often include backported fixes without changing the upstream version number. End-of-life versions (PHP 8.1 and older) do not receive upstream security patches.\nSummary of PHP2Shell Indicators & Checks\nInspection Area | What to Look For | Recommended Command / Action\nProcesses | PHP workers spawning shells (sh , bash) or download tools (curl, wget) | ps aux | grep -E \"sh|bash|curl|wget\"\nWeb Root Files | Newly dropped web shells or obfuscated .php files | find /var/www -type f -mtime -7\nUnauthorized cron jobs or modified SSH keys | Check /etc/cron* and ~/.ssh/authorized_keys\nRuntime Version | Unpatched PHP engines vulnerable to CVE-2026-109618 / CVE-2026-109619 | Run php -v and check vendor changelogs\nIf you'd like, let me know:\nWhat Linux distribution or hosting environment you are running\nYour current PHP version (php -v output)\nI can help you look up the exact fixed package version or mitigation steps for your setup.", "cited_urls": ["https://www.prophetsecurity.ai/blog/php2shell", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://www.ionix.io/writing-center/php2shell-cve-2026-109618-cve-2026-109619-find-every-exposed-php-app/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q07-google-ai-overviews-2", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "", "cited_urls": [], "excluded": true, "exclusion_reason": "no AI Overview returned for this query", "redacted": false} {"answer_id": "Q07-google-ai-overviews-3", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check if your server was compromised by the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), inspect your web server and PHP logs, running processes, and file system for indicators of exploitation .\n1. Check Web Server and PHP Logs\nHunt for exploitation indicators in your access and error logs (dating back before the disclosure window):\n[Redacted: exploit mechanics omitted from this public research copy.]\nAnomalous PHPSESSID Cookies: Check for high-entropy, heap-like encoded data, or unexpected values in session cookies.\nMemory Exhaustion & Fatals: Look for repeated \"Allowed memory size exhausted\" fatal errors, execution timeouts, early diagnostic warnings (\"in Unknown on line 0\" ), or sudden spikes in 500 server error responses correlating with upload or import paths.\nWorker Crashes: Look for worker segfaults, sudden process respawn bursts, or worker pool exhaustion in your Apache (mod_php) or PHP-FPM error logs.\n2. Inspect Running Processes and Memory\nCheck Active PHP Binaries: Confirm which PHP binaries and modules are loaded in memory (not just what is installed on disk). A patched file on disk does not help if an unpatched process is still running .\nUnexpected Shell Spawns: Audit active and recent processes. Alert on or search for PHP worker processes spawning system shells (/bin/sh, /bin/bash ), command interpreters, or outbound download tools (curl, wget).\nWorker Hangs: Look for persistent file locks (flock) on session files located under session.save_path (e.g., sess_* ) by checking /proc/locks.\n3. Inspect the Web Root and System for Artifacts\nNew or Modified Files: Scan your web roots (/var/www/, etc.) for newly dropped webshells, obfuscated PHP backdoor scripts, or unexpected files created around the time of suspicious requests .\nPersistence Mechanisms: Check for unauthorized cron jobs, scheduled tasks (crontab -l), or newly created local system user accounts.\nVerify Package Changelogs: If using a Linux distribution (Debian, Ubuntu, RHEL) that backports security fixes, do not rely on the version number alone. Run apt changelog php8.3-cli (Debian/Ubuntu) or rpm -q --changelog php (Red Hat) to verify whether CVE-2026-109618 or CVE-2026-109619 is explicitly listed in the changelog.\nWhat to Do If You Suspect Compromise\nIsolate the Server: Immediately take the machine off the network or block external traffic to prevent lateral movement or data exfiltration.\nPreserve Evidence: Copy out and preserve your web server logs, PHP logs, and memory dumps before attempting cleanup.\nRebuild / Restore: A compromised server should ideally be wiped and restored from a clean, pre-compromise backup, then updated to fixed PHP versions (8.5.12 , 8.4.27, 8.3.36, or 8.2.35) before reconnecting.\nIf you'd like, share:\nYour operating system and PHP version/setup (e.g., Ubuntu with PHP-FPM 8.2 vs. Apache mod_php)\nWhether you are seeing suspicious entries in your access or error logs\nI can help you pinpoint specific log commands or remediation steps.", "cited_urls": ["https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.youtube.com/watch?v=f-Vmxz3Zwro", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities", "https://www.facebook.com/ethical.hack.group/posts/php2shell-two-critical-php-flaws-leave-millions-of-servers-exposedmore-than-22-m/1413459377431557/", "https://www.youtube.com/watch?v=ST8bY4N6CMU"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-google-ai-mode-1", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check if your server has been compromised via the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), you need to perform a multi-layered forensic check. Because these vulnerabilities allow unauthenticated remote code execution (RCE) at the PHP runtime level before reaching typical application logs, attackers may drop web shells or spawn interactive command processes.\nReview the following structured steps to inspect your server:\nInspect Web Server and Access Logs\nReview access logs (access.log, Nginx/Apache logs) for unusual, malformed, or repeated POST, PUT, or PATCH requests.\n[Redacted: exploit mechanics omitted from this public research copy.]\nCheck for requests targeting non-existent scripts or repeatedly hitting endpoints with abnormally long execution times or large payload sizes.\nAudit Process and Network Activity\nMonitor for PHP worker processes (php-fpm, apache2, nginx) spawning unexpected child processes like shell interpreters (/bin/sh, /bin/bash), system utilities, or outbound download tools (wget, curl).\nRun network connection checks (ss -tulpn or netstat) to look for unexpected outbound connections initiated from web server user accounts (e.g., www-data, apache) pointing to unfamiliar external IP addresses or ports (indicative of reverse shells).\nHunt for Web Shells and Dropped Files\nScan your web root directories and common writable upload folders (such as wp-content/uploads, temporary directories like /tmp or /var/tmp) for newly created or modified PHP files.\nLook for hidden files, files with double extensions (e.g., .php.jpg), or files containing obfuscated code (such as heavy usage of eval(), base64_decode(), assert(), or system()).\nUse file integrity monitoring or scanner tools (like aide, tripwire, or clamav with web-shell signature databases) to flag unauthorized modifications.\nCheck Persistence Mechanisms\nAudit system and user cron jobs (/etc/crontab, /var/spool/cron/, /etc/cron.d/) for unauthorized scheduled tasks.\nCheck /etc/passwd and authorized SSH keys (~/.ssh/authorized_keys) for newly added user accounts or rogue backdoors.\nVerify Patch and Environment Status\nConfirm whether your PHP installation has actually received the official security patch from your vendor or distribution, keeping in mind that package version strings can sometimes be misleading if backports aren't clearly documented in the changelog.\nInventory all PHP runtimes on your network, including hidden or bundled binaries in control panels (cPanel/Plesk), legacy paths, or vendor appliances.\nIf you suspect an active compromise or find suspicious indicators, do you need help isolating the server safely or analyzing specific log snippets or file hashes?", "cited_urls": ["https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://www.fortiguard.com/outbreak-alert/php2shell", "https://www.servicenow.com/community/armis-articles/php2shell-how-to-find-prioritize-and-patch-affected-systems/ta-p/3612792", "https://www.youtube.com/watch?v=f-Vmxz3Zwro"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-google-ai-mode-2", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check if your server has been compromised via the PHP2Shell RCE vulnerabilities (associated with leaked details regarding CVE-2026-109618 and CVE-2026-109619), you need to hunt for specific forensic indicators in your web server logs, process trees, and file system.\n[Redacted: exploit mechanics omitted from this public research copy.]\n[Redacted: exploit mechanics omitted from this public research copy.]\nInspect Process Execution Trees: Investigate whether your web server or PHP processes (php-fpm, httpd, nginx, www-data) have spawned unexpected child processes or external utility shells like sh, bash, nc, curl, wget, or python.\nScan for New or Modified Files in Webroots: Run integrity checks or find commands in your web directories, specifically scanning upload directories, cache folders, and temporary directories (/tmp, /var/tmp) for newly dropped backdoor .php files.\nMonitor for Outbound Network Egress: Review network connection history or active sockets for reverse shells or unusual outbound connections initiated from the web server process to unfamiliar external IP addresses or non-standard ports.\nCheck PHP Worker Stability: Look through your system logs, PHP-FPM logs, or error logs for sudden segmentation faults, crashes, or abrupt restarts of PHP worker processes, which often precede or accompany memory-corruption exploitation attempts.\nIf you'd like, let me know:\nWhat web server and OS you are running (e.g., Nginx with PHP-FPM on Ubuntu)\nWhether you have access to terminal commands or log analysis tools (like grep/Elastic/Datadog)\nI can give you specific one-liner commands or a step-by-step shell script to query your logs and process lists for these indicators.", "cited_urls": ["https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://blog.checkpoint.com/security/php2shell-what-we-know-about-the-leaked-critical-php-vulnerabilities-cve-2026-109618-cve-2026-109619/", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q07-google-ai-mode-3", "question_id": "Q07", "question": "How do I check if my server was compromised by PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check if your server was compromised by PHP2Shell (CVE-2026-109618 and CVE-2026-109619), you must inspect volatile memory evidence (before restarting services), examine web server and PHP-FPM access logs, and audit the file system for dropped backdoors or suspicious processes. Because these vulnerabilities allow unauthenticated remote code execution (RCE) via memory disclosure and malformed multipart/session requests, attackers frequently deploy web shells, pivot to system binaries, or spawn reverse shells.\n1. Capture Volatile Evidence (Before Restarting)\nPreserve Memory State: Restarting PHP-FPM, Apache, or containers wipes out the in-memory state that the vulnerability abuses. If you haven't restarted yet, dump memory of running PHP-FPM worker processes or take a snapshot.\nCheck Active Processes: Look for unusual child processes spawned by your web server or PHP worker user (e.g., www-data, apache, or the respective pool user):\nCheck Active Network Connections: Identify outbound connections or listening ports bound to unexpected IP addresses:\n2. Review Web Server and Access Logs\nBecause the vulnerability leverages malformed multipart/form-data or session upload-progress routines, look back through your access logs (dating back to when exploitation activity picked up) for anomalous patterns:\nUnusual Request Payloads: Search for abnormally large POST requests, repeated requests hitting endpoints without a valid script, or malformed PHPSESSID cookies containing URL-encoded or binary garbage.\nCheck Access Log Timestamps: Cross-reference unexpected IP addresses hitting your web server right before unknown files were created.\nApache / Nginx / PHP-FPM Error Logs: Look for segmentation faults (sigsegv), out-of-memory errors, or sudden crashes in the PHP worker pool corresponding to weird request strings.\n3. Audit the Filesystem for Dropped Web Shells\nAttackers who achieve RCE via PHP2Shell typically drop a lightweight web shell or staging script to gain persistent access.\nRecently Modified Files: Scan your web root directories for PHP files modified or created around the time of the suspected compromise:\nSuspicious Functions: Search for obfuscated PHP code or dangerous execution functions (eval, assert, system, passthru, shell_exec, base64_decode) inside web directories:\nCheck Temp Directories: Inspect /tmp, /var/tmp, and user upload directories for hidden scripts, binaries, or ELF files (ls -la /tmp).\n4. Verify Patch Status and Inventory\nConfirm that you are no longer running an unpatched or vulnerable build:\nCheck Web-Serving PHP Version: Run a phpinfo() script or check the headers of your actual web server response, rather than just relying on CLI output (php -v), because servers frequently run multiple or isolated PHP runtimes.\nApply Official Updates: Ensure you have updated to the patched PHP releases provided by your Linux distribution, LTS vendor, or the PHP Downloads Page.\nRestart Services: Force a full restart of php-fpm, apache2, httpd, or rebuild your container images so the patched binaries take effect.\nIf you suspect an active breach, let me know:\nWhat web server and PHP-FPM/mod_php setup you are running (e.g., Ubuntu/Debian, Apache, Nginx)\nWhether you have already restarted your PHP/web services\nI can help guide you through deeper log analysis or incident containment steps.", "cited_urls": ["https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.wiz.io/blog/php2shell-php-rce", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/", "https://www.youtube.com/watch?v=mJlCb70MBpg", "https://www.youtube.com/watch?v=ST8bY4N6CMU", "https://www.php.net/downloads"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-chatgpt-1", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "For **PHP2Shell (CVE-2026-109618 and CVE-2026-109619)**, these tools offer checks. The key distinction is **finding vulnerable PHP installations versus detecting attack traffic**. ([php2shell.com](https://www.php2shell.com/?utm_source=openai))\n\n| Tool | What it checks |\n|---|---|\n| **Tenable Nessus** | Plugin **369483** checks for PHP versions affected by both CVEs. Useful for existing vulnerability-scanning workflows. ([tenable.com](https://www.tenable.com/plugins/nessus/369483?utm_source=openai)) |\n| **Pentest-Tools.com PHP2Shell Scanner** | Free online scanner for exposure to both PHP2Shell CVEs. ([pentest-tools.com](https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner)) |\n| **Imperva PHP2Shell Checker** | Checks a website’s publicly visible signals for potential exposure; does **not** attempt exploitation. ([php2shell.imperva.com](https://php2shell.imperva.com/)) |\n| **SOCRadar php2shell Checker** | Free PHP fingerprinting and version comparison, without exploitation. ([socradar.io](https://socradar.io/free-tools/php2shell-checker?utm_source=openai)) |\n| **Corelight’s Zeek package and Suricata rules** | Detect suspicious network activity and advertised vulnerable PHP versions. Require visibility into HTTP traffic, including decrypted HTTPS where applicable. ([corelight.com](https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai)) |\n\n**Important:** A clean remote check is not proof that you’re patched—PHP version information can be hidden or misleading. Confirm the actual web-serving PHP runtime, configuration, and vendor patch status on the server. ([php2shell.imperva.com](https://php2shell.imperva.com/))\n\nAre you looking to **scan for vulnerable servers** or **detect exploitation attempts**?", "cited_urls": ["https://www.php2shell.com/?utm_source=openai", "https://www.tenable.com/plugins/nessus/369483?utm_source=openai", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://php2shell.imperva.com/", "https://socradar.io/free-tools/php2shell-checker?utm_source=openai", "https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-chatgpt-2", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "For **PHP2Shell (CVE-2026-109618 and CVE-2026-109619)**, these tools offer checks or detections as of **October 22, 2026**:\n\n| Tool | What it checks |\n|---|---|\n| **Tenable Nessus** | Plugin **369483** checks for PHP versions affected by both CVEs. Useful for vulnerability scanning across servers. ([tenable.com](https://www.tenable.com/plugins/nessus/369483?utm_source=openai)) |\n| **Imperva PHP2Shell Checker** | Checks a website URL for publicly visible signs of exposure. It does **not** attempt exploitation or conclusively establish vulnerability. ([php2shell.sh](https://www.php2shell.sh/?utm_source=openai)) |\n| **SOCRadar PHP2Shell Checker** | Free domain-based check that fingerprints PHP and compares its version against fixed releases; no account or agent required. ([socradar.io](https://socradar.io/free-tools/php2shell-checker?utm_source=openai)) |\n| **Zeek + Corelight’s `php2shell-detect` package** | Monitors network traffic for suspicious PHP2Shell-related HTTP behavior and potentially affected PHP versions. ([corelight.com](https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai)) |\n| **Suricata + Corelight’s PHP2Shell rules** | Detects suspicious request markers and advertised vulnerable PHP versions. Requires visibility into unencrypted or decrypted HTTP. ([corelight.com](https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai)) |\n\n**Key distinction:** exposure checkers help answer “might this server be vulnerable?” Network detections help identify suspicious activity—not prove that exploitation succeeded. A clean website check is not an all-clear: PHP versions may be hidden, so verify the actual server runtime and patch status. ([corelight.com](https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai))", "cited_urls": ["https://www.tenable.com/plugins/nessus/369483?utm_source=openai", "https://www.php2shell.sh/?utm_source=openai", "https://socradar.io/free-tools/php2shell-checker?utm_source=openai", "https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-chatgpt-3", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "For **PHP2Shell (CVE-2026-109618 and CVE-2026-109619)**, tools fall into two categories: checking for vulnerable installations and detecting attempted exploitation. As of **October 22, 2026**, these options have published coverage. ([it.tenable.com](https://it.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote?utm_source=openai))\n\n| Tool | What it checks |\n|---|---|\n| **Tenable Nessus** | PHP2Shell vulnerability coverage through **plugin 369483**, covering both CVEs. ([tenable.com](https://www.tenable.com/plugins/nessus/369483?utm_source=openai)) |\n| **Tenable Web App Scanning** | PHP version-based checks through **plugins 115719–115722**, covering PHP 8.5, 8.4, 8.3, and 8.2 respectively. ([it.tenable.com](https://it.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote?utm_source=openai)) |\n| **Imperva PHP2Shell Checker** | A website-URL check for publicly visible signs of exposure. It does **not** attempt exploitation; results are indicative rather than definitive. ([php2shell.sh](https://www.php2shell.sh/?utm_source=openai)) |\n| **SOCRadar PHP2Shell Checker** | A free check that identifies the reported PHP version and compares it against the affected versions. ([socradar.io](https://socradar.io/free-tools/php2shell-checker?utm_source=openai)) |\n| **Wiz** | Agentless and runtime vulnerability detection, plus exploitation detection through **Wiz Defend and Sensor**, according to the disclosure guidance. ([php2shell.com](https://www.php2shell.com/?utm_source=openai)) |\n| **Zeek / Suricata with Corelight’s `php2shell-detect`** | Open-source network detections for suspicious HTTP activity and potentially vulnerable PHP version banners. Requires visibility into HTTP traffic—not just encrypted HTTPS. ([corelight.com](https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai)) |\n\n**Important:** A clean URL or banner scan does not establish that you’re safe: PHP versions can be hidden, rewritten, or include vendor-backported fixes. Confirm the installed runtime and vendor patch status; network alerts indicate suspicious activity, not necessarily successful compromise. ([php2shell.sh](https://www.php2shell.sh/?utm_source=openai))\n\nAre you looking to **scan for vulnerable servers** or **detect exploitation in your logs/network traffic**?", "cited_urls": ["https://it.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote?utm_source=openai", "https://www.tenable.com/plugins/nessus/369483?utm_source=openai", "https://www.php2shell.sh/?utm_source=openai", "https://socradar.io/free-tools/php2shell-checker?utm_source=openai", "https://www.php2shell.com/?utm_source=openai", "https://corelight.com/blog/php2shell-detection-before-disclosure?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-claude-1", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a summary of the tools currently available that check for **PHP2Shell** (CVE-2026-109618 and CVE-2026-109619), a pair of critical PHP remote code execution vulnerabilities rated CVSS v4.0 9.2:\n\n---\n\n## 🔍 Scanners & Detection Tools for PHP2Shell\n\n### 1. **php2shell-scanner** (by Assetnote / Searchlight Cyber)\n- \nThe research team released an open-source tool, **php2shell-scanner**, which contains a high-fidelity scanning mechanism to check for CVE-2026-109618 and CVE-2026-109619 across hosts.\n\n- \nThe scanner sends a minimal multipart control request followed by up to three crafted multipart probes. The probes use PHP array keys nested 62 levels deep and increase from 1 MiB to 20 MiB, matching the detection logic used by Assetnote's internal scanner.\n\n- \nIt follows a progressive nature that first attempts to produce a PHP memory-exhaustion error, then attempts to observe a differential empty HTTP 500 (a PHP-FPM worker failure), and finally falls back to whether or not the target advertises a known unpatched PHP version.\n\n- 📦 Available on GitHub: [assetnote/php2shell-scanner](https://github.com/assetnote/php2shell-scanner)\n\n---\n\n### 2. **php2shell-detect** (by Corelight — Zeek & Suricata)\n- \nCorelight developed network detections for **Zeek®** and **Suricata®** for php2shell.\n\n- \nTheir Zeek detections are based on behavioral analysis, not pattern matching.\n\n- \nThe package inspects POST field-name lengths, selected serialized-data structures, and repeated MIME headers. It also correlates related suspicious transactions using configured session cookies. Response headers provide separate PHP version inventory.\n\n- The Zeek package supports five notice types, including `PHP_Crash_Sequence`, `Multipart_Header_Flood`, `Large_Form_Key`, `Serialized_Integer_Overflow`, and `Serialized_Integer_Collisions`. \nIt requires Zeek 7.0.0 or later.\n\n- 📦 Available on GitHub: [corelight/php2shell-detect](https://github.com/corelight/php2shell-detect)\n\n---\n\n### 3. **php2shell-scan** (by 0xrsydn)\n- \n**php2shell-scan** is a reachability and change detector for the php2shell PHP RCEs (CVE-2026-109618 / CVE-2026-109619). It is agent-ready, stdlib only, and read-only by default.\n\n- \nIt is built for agents and humans who need a defensible answer without a public exploit, since the bug sits in PHP's RFC1867 multipart/upload-progress handling, below the application, so the reachable code path can be measured anonymously — no credentials, no CSRF token, no framework knowledge.\n\n- 📦 Available on GitHub: [0xrsydn/php2shell-scan](https://github.com/0xrsydn/php2shell-scan)\n\n---\n\n### 4. **php2shell Checker** (by SOCRadar)\n- \nSOCRadar's free checker reads `X-Powered-By`, the `Server` header, a 404 page's headers, the PHP session cookie, and the PHP easter-egg URL for PHP version fingerprinting, then compares the version against PHP's fixed releases and flags branches (8.1 and older) that get no fix.\n\n- \nIt makes nothing beyond what a browser sends, and the tool never attempts the RCE, so it never claims a confirmed hit.\n\n- 🌐 Available at: [socradar.io/free-tools/php2shell-checker](https://socradar.io/free-tools/php2shell-checker)\n\n---\n\n### 5. **Free PHP2Shell Scanner** (by Pentest-Tools)\n- \nPentest-Tools offers a free PHP2Shell scanner for CVE-2026-109618 and CVE-2026-109619 — the critical RCE flaws in PHP core — where you can check your targets and get a PDF scan report.\n\n- 🌐 Available at: [pentest-tools.com/network-vulnerability-scanning/php2shell-scanner](https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner)\n\n---\n\n## Summary Table\n\n| Tool | Type | By | Open Source |\n|---|---|---|---|\n| php2shell-scanner | Active scanner (CLI) | Assetnote / Searchlight | ✅ Yes |\n| php2shell-detect | Network IDS rules | Corelight | ✅ Yes |\n| php2shell-scan | Reachability prober (CLI) | 0xrsydn | ✅ Yes |\n| php2shell Checker | Passive version checker | SOCRadar | 🌐 Free web tool |\n| PHP2Shell Scanner | Active scanner | Pentest-Tools | 🌐 Free web tool |", "cited_urls": ["https://www.slcyber.io/research/high-fidelity-detection-mechanism-for-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/assetnote/php2shell-scanner", "https://corelight.com/blog/php2shell-detection-before-disclosure", "https://github.com/corelight/php2shell-detect", "https://github.com/0xrsydn/php2shell-scan", "https://socradar.io/free-tools/php2shell-checker", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-claude-2", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Here is a summary of the tools currently available to check for **PHP2Shell** (CVE-2026-109618 and CVE-2026-109619), a pair of critical PHP remote code execution vulnerabilities rated CVSS v4.0 9.2:\n\n---\n\n## 🔍 Tools That Check for PHP2Shell\n\n### 1. **php2shell-scanner** (by Assetnote / Searchlight Cyber)\n- **GitHub:** [assetnote/php2shell-scanner](https://github.com/assetnote/php2shell-scanner)\n- \nThe research team released an open-source tool, **php2shell-scanner**, which contains a high-fidelity scanning mechanism to check for CVE-2026-109618 and CVE-2026-109619 across hosts.\n\n- \nThe detection mechanism follows a progressive approach that first attempts to produce a PHP memory-exhaustion error, then attempts to observe a differential empty HTTP 500 (a PHP-FPM worker failure), and finally falls back to whether or not the target advertises a known unpatched PHP version.\n\n- \nThe scanner sends a minimal multipart control request followed by up to three crafted multipart probes. The probes use PHP array keys nested 62 levels deep and increase from 1 MiB to 20 MiB.\n\n\n---\n\n### 2. **php2shell-detect** (by Corelight — Zeek & Suricata)\n- **GitHub:** [corelight/php2shell-detect](https://github.com/corelight/php2shell-detect)\n- \nCorelight developed network detections for **Zeek®** and **Suricata®**, and released them as open-source repositories alongside the coordinated disclosure.\n\n- \nThe Zeek detections are based on behavioral analysis, not pattern matching.\n\n- \nThe package inspects POST field-name lengths, selected serialized-data structures, and repeated MIME headers. It also correlates related suspicious transactions using configured session cookies. Response headers provide separate PHP version inventory.\n\n- \nZeek notice types include: `PHP_Crash_Sequence`, `Multipart_Header_Flood`, `Large_Form_Key`, `Serialized_Integer_Overflow`, and `Serialized_Integer_Collisions`.\n\n\n---\n\n### 3. **php2shell Checker** (by SOCRadar)\n- **URL:** [socradar.io/free-tools/php2shell-checker](https://socradar.io/free-tools/php2shell-checker)\n- \nThis tool reads `X-Powered-By`, the `Server` header, a 404 page's headers, the PHP session cookie, and the PHP easter-egg URL for version fingerprinting — then compares the version against PHP's fixed releases and flags branches (8.1 and older) that receive no fix.\n\n- \nThe tool only sends what a normal browser would send — it never attempts the RCE, so it never claims a confirmed hit.\n\n\n---\n\n### 4. **Free PHP2Shell Scanner** (by Pentest-Tools)\n- **URL:** [pentest-tools.com/network-vulnerability-scanning/php2shell-scanner](https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner)\n- \nThis free scanner checks targets for CVE-2026-109618 and CVE-2026-109619 and generates a PDF scan report.\n\n\n---\n\n### 5. **php2shell-scan** (by 0xrsydn)\n- **GitHub:** [0xrsydn/php2shell-scan](https://github.com/0xrsydn/php2shell-scan)\n- \nA reachability and change detector for the php2shell PHP RCEs (CVE-2026-109618 / CVE-2026-109619) that is agent-ready, uses only the standard library, and is read-only by default.\n\n- \nThe tool is built for agents and humans who need a defensible answer without a public exploit, since the bug sits in PHP's RFC1867 multipart/upload-progress handling, below the application layer.\n\n\n---\n\n### Summary Table\n\n| Tool | Type | Source |\n|---|---|---|\n| **php2shell-scanner** (Assetnote) | CLI Scanner | GitHub (Open Source) |\n| **php2shell-detect** (Corelight) | Network Detection (Zeek/Suricata) | GitHub (Open Source) |\n| **php2shell Checker** (SOCRadar) | Web-based (version fingerprint) | Free Online Tool |\n| **PHP2Shell Scanner** (Pentest-Tools) | Web-based Scanner | Free Online Tool |\n| **php2shell-scan** (0xrsydn) | CLI Reachability Detector | GitHub (Open Source) |", "cited_urls": ["https://www.slcyber.io/research/high-fidelity-detection-mechanism-for-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/assetnote/php2shell-scanner", "https://corelight.com/blog/php2shell-detection-before-disclosure", "https://github.com/corelight/php2shell-detect", "https://socradar.io/free-tools/php2shell-checker", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://github.com/0xrsydn/php2shell-scan"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-claude-3", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several tools have been released to check for **PHP2Shell** (CVE-2026-109618 and CVE-2026-109619), a pair of critical PHP remote code execution vulnerabilities rated CVSS v4.0 9.2. Here is a summary of the known tools:\n\n---\n\n### 1. 🔍 **php2shell-scanner** by Assetnote (Searchlight Cyber)\n- \nThe research team released an open-source tool, **php2shell-scanner**, which contains a high-fidelity scanning mechanism to check for CVE-2026-109618 and CVE-2026-109619 across hosts.\n\n- \nThe detection mechanism follows a progressive nature: it first attempts to produce a PHP memory-exhaustion error, then attempts to observe a differential empty HTTP 500 (a PHP-FPM worker failure), and finally falls back to whether or not the target advertises a known unpatched PHP version.\n\n- \nThe scanner sends a minimal multipart control request followed by up to three crafted multipart probes. The probes use PHP array keys nested 62 levels deep and increase from 1 MiB to 20 MiB.\n\n- 📦 GitHub: [assetnote/php2shell-scanner](https://github.com/assetnote/php2shell-scanner)\n\n---\n\n### 2. 🌐 **Zeek & Suricata Detections** by Corelight\n- \nCorelight's contribution was developing network detections for **Zeek®** and **Suricata®** for php2shell.\n\n- \nThe Zeek detections are based on behavioral analysis, not pattern matching.\n\n- \nThe package inspects POST field-name lengths, selected serialized-data structures, and repeated MIME headers. It also correlates related suspicious transactions using configured session cookies. Response headers provide separate PHP version inventory.\n\n- \nThe Zeek notices include types such as `PHP_Crash_Sequence`, `Multipart_Header_Flood`, `Large_Form_Key`, `Serialized_Integer_Overflow`, and `Serialized_Integer_Collisions`.\n\n- 📦 GitHub: [corelight/php2shell-detect](https://github.com/corelight/php2shell-detect)\n\n---\n\n### 3. 🛡️ **Free PHP2Shell Scanner** by Pentest-Tools\n- \nPentest-Tools offers a free PHP2Shell scanner for CVE-2026-109618 and CVE-2026-109619, allowing users to check targets and get a PDF scan report.\n\n- 🔗 Available at: [pentest-tools.com/network-vulnerability-scanning/php2shell-scanner](https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner)\n\n---\n\n### 4. 🔎 **php2shell Checker** by SOCRadar\n- \nSOCRadar's checker performs **PHP Version Fingerprinting** by reading `X-Powered-By`, the `Server` header, a 404 page's headers, PHP session cookies, and the PHP easter-egg URL. It then compares the version against PHP's fixed releases and flags vulnerable branches.\n\n- \nThe tool only sends requests that an ordinary browser already makes and never attempts the RCE, so it never claims a confirmed hit.\n\n- 🔗 Available at: [socradar.io/free-tools/php2shell-checker](https://socradar.io/free-tools/php2shell-checker)\n\n---\n\n### 5. 🧪 **php2shell-scan** by 0xrsydn\n- \n**php2shell-scan** is a reachability and change detection tool for the php2shell PHP core RCEs. The bug sits in PHP's RFC1867 multipart/upload-progress handling, and the reachable code path can be measured anonymously — no credentials, no CSRF token, and no framework knowledge required.\n\n- \nBecause no PoC existed when this was written, the tool records a **failure profile** and later diffs it.\n\n- 📦 GitHub: [0xrsydn/php2shell-scan](https://github.com/0xrsydn/php2shell-scan)\n\n---\n\n### Summary Table\n\n| Tool | Type | By |\n|---|---|---|\n| php2shell-scanner | CLI Scanner | Assetnote / Searchlight Cyber |\n| php2shell-detect | Network Detection (Zeek + Suricata) | Corelight |\n| PHP2Shell Scanner | Web-based Scanner | Pentest-Tools |\n| php2shell Checker | Web-based Version Checker | SOCRadar |\n| php2shell-scan | Reachability + Change Detector | 0xrsydn |", "cited_urls": ["https://www.slcyber.io/research/high-fidelity-detection-mechanism-for-php2shell-cve-2026-109618-and-cve-2026-109619", "https://github.com/assetnote/php2shell-scanner", "https://corelight.com/blog/php2shell-detection-before-disclosure", "https://github.com/corelight/php2shell-detect", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://socradar.io/free-tools/php2shell-checker", "https://github.com/0xrsydn/php2shell-scan"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-perplexity-1", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Tools that can check for **PHP2Shell** include:\n\n- **OpenAI `php2shell-checker`** — checks a local PHP installation or a website’s advertised PHP version through response headers.[1]\n- **Searchlight Cyber `php2shell-scanner`** — performs active, authorized probes for the reported vulnerabilities, with version checking as a fallback.[9]\n- **`php2shell-check`** — read-only checks for local binaries, Docker images, containers, URLs, and asset inventories.[4]\n- **RFF PHP Exposure Check** — inventories PHP installations on Windows and Linux, including IIS, containers, and package versions.[3]\n- **`php2shell-validation-toolkit`** — offers local audits, passive fleet scans, and more active remote checks.[2]\n- **Eye Security browser extension** — passively reads the PHP version exposed in a website’s response headers.[8]\n- **Manual checks** — `php -v`, hosting dashboards, WordPress Site Health, and server-side runtime checks can identify the PHP version, but should be verified against the actual web-serving PHP runtime.[1][7]\n\nUse active scanners only on systems you own or are explicitly authorized to test. A version-only check can miss distribution backports, hidden or falsified headers, and differences between CLI PHP and PHP-FPM/mod_php.[5][8]", "cited_urls": ["https://kingy.ai/blog/php2shell-website-security-guide/", "https://github.com/euriconicacio/php2shell-validation-toolkit/blob/main/exposure/README.md", "https://getrff.com/blog/php2shell-find-every-php/", "https://github.com/adityaaravind/php2shell-check", "https://tentenai.com/en/php2shell", "https://github.com/kometsoft/php2shell-check", "https://arvion.ai/tools/php2shell", "https://eye.security/blog/php2shell-explained-what-the-critical-php-vulnerabilities-mean-for-you/", "https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://gist.github.com/iSaluki/48a779baeaccb69ae2aa45adf7294aba"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-perplexity-2", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Tools that can check for **PHP2Shell** include:\n\n- **OpenAI `php2shell-checker`** — checks a URL’s advertised PHP version or performs a local check; read-only. [1]\n- **Searchlight Cyber `php2shell-scanner`** — performs more active, authorized probes for CVE-2026-109618 and CVE-2026-109619, with version fallback. [9]\n- **`php2shell-validation-toolkit`** — offers local audits, passive fleet scans, and an optional active remote scanner. [2]\n- **`php2shell-check`** — inventories local PHP binaries, containers, Docker images, URLs, and asset lists without exploit traffic. [4]\n- **Eye Security PHP2Shell Checker** — a Chrome/Edge extension that passively reads the PHP version exposed in response headers. [8]\n- **RFF PHP Exposure Check** — Windows and Linux scripts that locate PHP installations and assess their versions, including containers. [3]\n\nFor a safe first check, use a **local version audit** such as `php -v` or the OpenAI checker’s local mode. Active scanners should only be run against systems you own or are explicitly authorized to test. [1][7]", "cited_urls": ["https://kingy.ai/blog/php2shell-website-security-guide/", "https://github.com/euriconicacio/php2shell-validation-toolkit/blob/main/exposure/README.md", "https://getrff.com/blog/php2shell-find-every-php/", "https://github.com/adityaaravind/php2shell-check", "https://tentenai.com/en/php2shell", "https://github.com/kometsoft/php2shell-check", "https://arvion.ai/tools/php2shell", "https://eye.security/blog/php2shell-explained-what-the-critical-php-vulnerabilities-mean-for-you/", "https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://gist.github.com/iSaluki/48a779baeaccb69ae2aa45adf7294aba"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-perplexity-3", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Tools that can check for **PHP2Shell** include:\n\n- **OpenAI `php2shell-checker`** — checks a URL’s advertised PHP version or local PHP installations; read-only. [1]\n- **Searchlight Cyber `php2shell-scanner`** — performs active, authorized probes for the reported vulnerabilities, with version fallback. [9]\n- **`php2shell-validation-toolkit`** — offers local audits, passive fleet scans, and more active remote checks. [2]\n- **`php2shell-check`** — scans local binaries, containers, Docker images, URLs, and asset inventories without exploit traffic. [4]\n- **Eye Security browser extension** — passively checks PHP versions exposed in Chrome/Edge response headers. [8]\n- **RFF PHP Exposure Check** — read-only Windows and Linux scripts that locate PHP installations and assess their versions. [3]\n\nFor a safe first check, use a **local/version-based scanner** and verify the PHP version actually used by the web server—not just the CLI binary. Only run active scanners against systems you own or are explicitly authorized to test.", "cited_urls": ["https://kingy.ai/blog/php2shell-website-security-guide/", "https://github.com/euriconicacio/php2shell-validation-toolkit/blob/main/exposure/README.md", "https://getrff.com/blog/php2shell-find-every-php/", "https://github.com/adityaaravind/php2shell-check", "https://tentenai.com/en/php2shell", "https://github.com/kometsoft/php2shell-check", "https://arvion.ai/tools/php2shell", "https://eye.security/blog/php2shell-explained-what-the-critical-php-vulnerabilities-mean-for-you/", "https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://gist.github.com/iSaluki/48a779baeaccb69ae2aa45adf7294aba"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-google-ai-overviews-1", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several specialized open-source tools, commercial scanners, and detection utilities check for or detect exposure to the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619):\nOfficial Checker & Scanners\nOpenAI php2shell-checker : The official checker from OpenAI's California team to test a public URL or a local PHP binary (returns OK, VULNERABLE, or UNKNOWN).\nAssetnote php2shell-scanner : A high-fidelity scanner that sends a minimal control request followed by up to three crafted probes, flagging targets only on strong signals like memory exhaustion or differential 500 errors.\nImperva php2shell.sh: A script provided by Imperva to quickly check if websites are vulnerable.\nPentest-Tools PHP2Shell Scanner : A free laser scanner designed to detect CVE-2026-109618 and CVE-2026-109619.\nInventory & Asset Discovery Tools\n: Rapidly inventories PHP installations across containers, CI runners, control panels (cPanel, Plesk), CMS platforms, and bundled appliances.\nBlack Duck SCA / Binary Analysis: Finds PHP packages and components across container image layers, binaries, and firmware.\nOutpost24 EASM & Outscan : Discovers exposed PHP assets and maps vulnerability status across external attack surfaces.\nOsquery: Uses SQL queries against package managers (deb_packages, rpm_packages) and system paths to locate installed or running PHP binaries and Apache modules.\nRuntime Detection & Monitoring Tools\nFlorian Roth process-watcher : A Linux-based process monitoring tool that alerts on suspicious child processes spawned by PHP workers (php-fpm, httpd, apache2 launching shells like sh, bash, cmd.exe, or download tools like curl and wget).\nSweet Security: Uses eBPF-based sensors to monitor runtime execution, detect post-exploitation shell activity, and contain compromised workloads.\nElastic SIEM / EDR Detection Rules : Pre-built detection rules monitoring web server payload execution, unusual child processes, and high-entropy file creation.\nIf you'd like, let me know:\nAre you looking to scan a live public URL or inventory internal servers?\nWhat operating system or container stack are you running?", "cited_urls": ["https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://www.youtube.com/watch?v=5xJzZb3z29I", "https://www.reddit.com/r/cybersecurity/comments/1xbxz0z/check_if_youre_vulnerable_to_php2shell/", "https://www.blackduck.com/blog/php2shell-find-fix-exposure-sca.html", "https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities", "https://outpost24.com/blog/patching-php2shell-find-fix-exposure/", "https://www.elastic.co/security-labs/threat-command/php2shell-php-rce-detection", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities", "https://www.sweet.security/blog/php2shell-critical-php-vulnerabilities-expose-millions-of-applications-to-remote-code-execution"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-google-ai-overviews-2", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several specialized open-source tools, commercial scanners, and scripts check for PHP2Shell ( and CVE-2026-109619):\nOpen-Source & Script-Based Tools\nphp2shell-scanner (Searchlight Cyber): An open-source scanner released on GitHub that tests hosts for CVE-2026-109618 and CVE-2026-109619 by sending controlled probes (note that active probing can trigger memory-limit conditions in PHP workers).\nPhp2ShellCheck (Community / GitHub via jgatka): An asynchronous Python script shared on Hacker News that inspects HTTP response headers to fingerprint the PHP version and compare it against vulnerable release ranges.\nZeek and Suricata Detections ( ): Open-source network detection scripts designed to spot PHP2Shell exploit signatures and traffic patterns on the wire.\nCommercial & Online Scanners\nPentest-Tools.com PHP2Shell Scanner: A free online scanner that checks whether a target domain or server runs a vulnerable PHP version without needing an installed agent.\nSOCRadar PHP2Shell Checker: A free web-based checker that evaluates exposed domain headers against fixed PHP versions (8.5.12, 8.4.27 , 8.3.36, and 8.2.35).\nFlawfence PHP2Shell Scanner: An online analysis tool that reads advertised server PHP versions to check for exposure safely.\nQualys (VMDR & ETM / CSAM / TruConfirm): Offers QIDs (QID 45110 for discovery, QID 389102 for PHP2Shell assessment) and deep-scan features to locate PHP binaries across cloud images, containers, and web apps .\nIntruder PHP Vulnerability Scanner: Continuous vulnerability scanning platform tracking PHP2Shell (cvemon.intruder.io).\nBlack Duck SCA / Binary Analysis: Scans container images and compiled binaries for vulnerable OS packages like php8.3-fpm or bundled PHP cores.\nTenable Security Center & Enclave Security: Issued standalone security patches (SC-202610.1) and detection rules to identify PHP2Shell exposure.\nLocal CLI & Inventory Checks\nCommand-Line Version Check: Running php -v directly on a Linux or Windows server.\nPackage Manager Changelog Inspection: Checking package history on Debian/Ubuntu (zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz) or RHEL/AlmaLinux/Rocky (rpm -q --changelog php-common | grep CVE-2026-109618 ) to see if backported patches are present even if the version string hasn't bumped.\nOsquery: Running SQL queries against deb_packages or rpm_packages tables to catalog installed PHP modules and binaries.\nIf you'd like, let me know:\nWhether you need to scan public-facing domains or internal Linux/Docker servers\nWhat operating system or container stack you use\nI can give you the exact command or method to verify your setup.", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/", "https://news.ycombinator.com/item?id=50195180", "https://corelight.com/blog/php2shell-detection-before-disclosure", "https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://www.reddit.com/r/pentest_tools_com/comments/1xbw8ji/we_just_launched_a_free_php2shell_scanner/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://flawfence.com/en/tools/php2shell/", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://www.intruder.io/product/php-vulnerability-scanner", "https://www.blackduck.com/blog/php2shell-find-fix-exposure-sca.html", "https://sansec.io/research/php2shell", "https://arvion.ai/tools/php2shell", "https://www.elastic.co/security-labs/threat-command/php2shell-php-rce-detection"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-google-ai-overviews-3", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several tools and scanners are available to check for PHP2Shell (CVE-2026-109618 and CVE-2026-109619 ):\nSearchlight Cyber php2shell-scanner\nAn open-source testing tool released on GitHub that actively checks whether a host or target (defaulting to /index.php and phpMyAdmin paths) is exposed to the PHP2Shell vulnerabilities. It includes a --sapi flag to restrict tests to mod_php or PHP-FPM.\nSOCRadar PHP2Shell Checker\nA free online checker tool that inspects the PHP version exposed by a domain or web target against the patched upstream releases (8.5.12 , 8.4.27, 8.3.36, and 8.2.35). It uses passive signals and headers without attempting exploitation.\nArvion PHP2Shell Checker\nA browser-based verification tool that helps administrators and site owners evaluate whether their active PHP runtime is running a vulnerable version .\nMakFly php2shell-check (watch.sh)\nA process-monitoring bash script (watch.sh ) designed for Linux servers to observe and alert on real-time behavior, such as web server or PHP worker processes (apache2, php-fpm, etc.) unexpectedly spawning shells (sh, bash) or download tools (curl, wget).\nCybeats SBOM / Software Bill of Materials Tools\nSoftware supply chain analysis tools that parse Software Bills of Materials (SBOMs) to locate where PHP and dependent libraries are installed across organizational environments and container workloads .\nWould you like assistance running a specific local command to verify your server's PHP version, or do you need guidance on patching a particular distribution (like Ubuntu, Debian, or Docker)?", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://arvion.ai/tools/php2shell", "https://github.com/MakFly/php2shell-check/blob/main/watch.sh", "https://www.youtube.com/watch?v=5-7lG36lUZE"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-google-ai-mode-1", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "To check for and detect vulnerabilities related to PHP2Shell (covering critical RCE flaws CVE-2026-109618 and CVE-2026-109619), a few specialized tools and monitoring utilities have been released:\nphp2shell-scanner by Assetnote / Searchlight Cyber: An open-source command-line scanning tool designed to test hosts and PHP applications (such as WordPress, Drupal, Joomla, and phpMyAdmin) for exposure to the PHP2Shell vulnerabilities by sending controlled, nested multipart probes. An online/hosted variant is also referenced via Pentest-Tools.com PHP2Shell Scanner.\nprocess-watcher by Florian Roth: A free Linux-based process monitoring and detection utility aimed at runtime observation. Rather than probing for the vulnerability, it monitors process behavior to alert you if a PHP worker process (php-fpm, php-cgi, httpd, apache2) abnormally spawns child processes like shells (sh, bash), interpreters, or download tools (curl, wget).\nWould you like help with running the command-line scanner or configuring runtime detection rules for your specific server setup?", "cited_urls": ["https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://github.com/assetnote/php2shell-scanner", "https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q08-google-ai-mode-2", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Several specialized online scanners and local audit tools have been released to detect PHP2Shell (the community-designated name for critical PHP remote code execution flaws CVE-2026-109618 and CVE-2026-109619).\nDedicated PHP2Shell Checkers & Scanners\n[Redacted: exploit mechanics omitted from this public research copy.]\n[Redacted: exploit mechanics omitted from this public research copy.]\n[Redacted: exploit mechanics omitted from this public research copy.]\nLocal / Server-Side Verification Methods\nBecause external network scanners only test public-facing behavior and may produce false negatives or miss internal CLI/non-routed binaries, security advisories from Armis and Arctic Wolf recommend direct local checks:\nVersion & Binary Inspection: Verify that your installed PHP interpreter has been updated to patched baseline releases (PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12), or check for official distribution/vendor backports for older versions. Note that you must check the version loaded in active memory (such as PHP-FPM or Apache mod_php), not just binaries sitting idle on the disk.\nLog Analysis Tools: Review web server and process manager error logs (php-fpm, apache2, httpd) for recurring worker segfaults, sudden child process respawns, or repeated “allowed memory size exhausted” fatal entries tied to malformed multipart requests.\nIf you want to check a specific environment, let me know:\nWhat operating system or Linux distribution you are running\nHow PHP is deployed (e.g., PHP-FPM, Apache mod_php, FrankenPHP, Docker)\nI can help you look up the exact command-line steps to inspect your loaded PHP version or apply the patches.", "cited_urls": ["https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://www.youtube.com/watch?v=mJlCb70MBpg", "https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/", "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell", "https://www.helpnetsecurity.com/2026/10/22/php2shell-scanner-tool/", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://www.recordedfuture.com/blog/php2shell-vulnerability-exploitation"], "excluded": false, "exclusion_reason": null, "redacted": true} {"answer_id": "Q08-google-ai-mode-3", "question_id": "Q08", "question": "Which tools check for PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Pentest-Tools.com provides a dedicated Free PHP2Shell Scanner to check target web servers for CVE-2026-109618 and CVE-2026-109619.\nSeveral security organizations and research groups are tracking and offering guidance, detection, or scanning advice regarding PHP2Shell:\nPentest-Tools.com: Offers an online remote scanner designed to check web endpoints for exposure to the PHP core RCE flaws.\nSansec: Provides e-commerce and PHP security research, indicators of compromise, and server-side analysis for PHP core vulnerabilities.\nHuntress: Published rapid response intelligence, telemetry monitoring, and analysis tracking the proof-of-concept (PoC) and exploitation status of PHP2Shell.\nwatchTowr: Conducted technical reproduction and FAQ breakdowns regarding the unauthenticated remote code execution mechanisms.\nCERT-EU: Issued official security advisories (CERT-EU Security Advisory 2026-018) evaluating the scope and CVSS severity of the flaws.", "cited_urls": ["https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner", "https://pentest-tools.com/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-chatgpt-1", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes—restart the processes running PHP after installing the PHP2Shell patch.** Updating packages on disk can leave existing processes running the old, vulnerable code. A full server reboot isn’t necessary if you restart the relevant services. ([digitalocean.com](https://www.digitalocean.com/blog/critical-php-rce-vulnerabilities-patch-now))\n\nWhat to restart depends on your setup:\n\n- **PHP-FPM:** restart the PHP-FPM service.\n- **Apache with mod_php:** restart Apache. ([digitalocean.com](https://www.digitalocean.com/blog/critical-php-rce-vulnerabilities-patch-now))\n- **Long-running PHP workers:** restart those too, so every affected runtime loads the patched code. ([php2shell.com](https://www.php2shell.com/?utm_source=openai))\n- **Containers:** rebuild or pull a patched image and redeploy—not merely restart the old container. ([digitalocean.com](https://www.digitalocean.com/blog/critical-php-rce-vulnerabilities-patch-now))\n\nThe fixed upstream releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**; your OS vendor may instead provide a backported fix. ([php.net](https://www.php.net/index.php))\n\nWhat OS and PHP setup are you using? I can give you the exact restart command.", "cited_urls": ["https://www.digitalocean.com/blog/critical-php-rce-vulnerabilities-patch-now", "https://www.php2shell.com/?utm_source=openai", "https://www.php.net/index.php"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-chatgpt-2", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes—restart the services and workers running PHP after installing the PHP2Shell patch.** Updating files on disk alone can leave existing processes running the vulnerable version. ([php2shell.com](https://www.php2shell.com/))\n\nWhat to restart depends on your setup:\n- **PHP-FPM:** restart each affected PHP-FPM service.\n- **Apache with mod_php:** restart Apache.\n- **Long-running PHP workers:** restart these too, including background workers.\n- **Containers:** rebuild or pull a patched image and redeploy; restarting an unchanged image does not install the fix. ([php2shell.com](https://www.php2shell.com/))\n\nAfterward, **verify the PHP runtime actually serving web requests**, not just `php -v`, which checks the command-line installation. The fixed upstream releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**; your OS vendor may instead supply a backported fix. ([xint.io](https://xint.io/blog/php2shell-emergency-response))\n\nWhat OS and PHP setup are you using? I can give you the exact restart command.", "cited_urls": ["https://www.php2shell.com/", "https://xint.io/blog/php2shell-emergency-response"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-chatgpt-3", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes—restart the processes running PHP after installing the PHP2Shell patch.** Otherwise, they can continue using the old, vulnerable code already loaded in memory. ([xint.io](https://xint.io/blog/php2shell-emergency-response))\n\nWhat to restart depends on your setup:\n\n- **PHP-FPM:** Restart the relevant PHP-FPM service.\n- **Apache with mod_php:** Restart Apache.\n- **Containers:** Rebuild or pull an image containing patched PHP, then redeploy the containers. Simply restarting an old image does not install the patch. ([xint.io](https://xint.io/blog/php2shell-emergency-response))\n- **Other long-running PHP workers:** Restart those too so every running PHP process uses the updated runtime. ([php2shell.com](https://www.php2shell.com/?utm_source=openai))\n\nAfterward, **verify the PHP runtime actually serving your website**, not just `php -v`, which checks the command-line installation and may differ from your web environment. ([xint.io](https://xint.io/blog/php2shell-emergency-response))\n\nWhat OS and setup are you using—PHP-FPM, Apache/mod_php, Docker, or managed hosting?", "cited_urls": ["https://xint.io/blog/php2shell-emergency-response", "https://www.php2shell.com/?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-claude-1", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes, restarting PHP is absolutely required after patching PHP2Shell** — and this is one of the most critical steps not to skip. Here's why and what to do:\n\n---\n\n## Why You Must Restart\n\n\nInstalling the fixed package isn't enough while workers still run the old code. A running PHP-FPM master, or mod_php loaded inside Apache, keeps the old code in memory until it's restarted, and a container keeps it until it's replaced.\n\n\nIn other words, \na patched package on disk does nothing while the old worker processes are still running.\n\n\n---\n\n## What to Restart\n\n\nPatching the binary on disk doesn't protect running processes. Restart PHP-FPM, Apache modules, and every long-running PHP process. This includes queue workers, schedulers, and daemons. Without a restart, these processes continue running the old, vulnerable binary.\n\n\n\nYou should also restart long-running PHP workers that are not web servers: queue workers, Laravel Octane, RoadRunner, Swoole, and supervisor-managed daemons.\n\n\n---\n\n## How to Restart (Common Commands)\n\n\nFor PHP-FPM, run `sudo systemctl restart php-fpm`. If you use mod_php on Apache, restart Apache with `sudo systemctl restart httpd` instead.\n\n\n\nIn containers, a rebuilt image only helps after the pods or containers are replaced, for example with `kubectl rollout restart deployment/`.\n\n\n---\n\n## The Only Complete Fix\n\n\nInstall a fixed PHP release (or your vendor's patched package) on every runtime, then restart PHP-FPM, Apache, and any long-running PHP processes. That is the only complete remediation. Application updates and config changes do not replace it.\n\n\nThe patched versions are: \nPHP 8.5.12, PHP 8.4.27, PHP 8.3.36, and PHP 8.2.35.\n\n\n**Bottom line:** Patch + restart are both required. Neither step alone is sufficient.", "cited_urls": ["https://tuxcare.com/blog/php2shell-cve/", "https://patchmon.net/blog/php2shell-cve-2026-109618-cve-2026-109619-php-rce-patch", "https://www.guidepointsecurity.com/blog/how-to-patch-php2shell/", "https://safeguard.sh/resources/blog/find-and-patch-every-php-runtime-after-php2shell", "https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/", "https://php2shell.uk/faq"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-claude-2", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes, restarting PHP is absolutely required** after patching PHP2Shell. Simply installing the patched package is not enough. Here's why and what to do:\n\n---\n\n## Why You Must Restart\n\n\nWhen you update a Linux server, the new PHP binaries and libraries are written to disk. However, active processes in RAM continue to execute the old code. Only when the process manager controlling PHP restarts will the server load the patched version.\n\n\nIn other words, \na patched package on disk does nothing while the old worker processes are still running.\n\n\n---\n\n## What Needs to Be Restarted\n\n\nPatching the binary on disk doesn't protect running processes. Restart PHP-FPM, Apache modules, and every long-running PHP process. This includes queue workers, schedulers, and daemons. Without a restart, these processes continue running the old, vulnerable binary.\n\n\n\nAlso restart long-running PHP workers that are not web servers: queue workers, Laravel Octane, RoadRunner, Swoole, and supervisor-managed daemons.\n\n\n\nIn containers, a rebuilt image only helps after the pods or containers are replaced (e.g., with `kubectl rollout restart deployment/`).\n\n\n---\n\n## Use a Full Restart, Not Just a Reload\n\n\nA package upgrade replaces files, but the running PHP-FPM master and the Apache parent with mod_php keep the old code until they restart. Use a **full restart**, not a reload, and restart every pool.\n\n\n---\n\n## Urgency\n\n\nPHP2Shell is the name for two critical PHP core RCE flaws, CVE-2026-109618 and CVE-2026-109619. Attack attempts were reported before the release, so patch now and restart every PHP worker.\n\n\n\nPHP has released the following versions that address the vulnerabilities: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36, and PHP 8.2.35.\n\n\n**Bottom line:** Patch + restart are both mandatory steps. One without the other leaves your systems vulnerable.", "cited_urls": ["https://www.techzine.eu/blogs/security/145168/php-shuts-the-internet-why-php2shell-affects-every-company/", "https://patchmon.net/blog/php2shell-cve-2026-109618-cve-2026-109619-php-rce-patch", "https://www.guidepointsecurity.com/blog/how-to-patch-php2shell/", "https://safeguard.sh/resources/blog/find-and-patch-every-php-runtime-after-php2shell", "https://tuxcare.com/blog/php2shell-cve/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-claude-3", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes, restarting PHP is absolutely required after patching PHP2Shell.** Simply installing the updated package is not enough. Here's what you need to know:\n\n---\n\n### Why a Restart Is Mandatory\n\n\nInstalling the fixed package doesn't change a worker that is already running — the old binary keeps serving until the restart.\n More specifically, \na package upgrade replaces files on disk, but the running PHP-FPM master and the Apache parent with mod_php keep the old code in memory until they restart.\n\n\n---\n\n### What to Restart\n\n\nPatching the binary on disk doesn't protect running processes. Restart PHP-FPM, Apache modules, and every long-running PHP process — this includes queue workers, schedulers, and daemons. Without a restart, these processes continue running the old, vulnerable binary.\n\n\nUse a **full restart, not just a reload**, and restart every pool. Example commands:\n\n\n\n```bash\n# Debian / Ubuntu\nsudo systemctl restart php8.4-fpm\nsudo systemctl restart apache2\n\n# RHEL family\nsudo systemctl restart php-fpm\nsudo systemctl restart httpd\n```\nAlso restart long-running PHP workers that are not web servers: queue workers, Laravel Octane, RoadRunner, Swoole, and supervisor-managed daemons.\n\n\n\nIn containers, a rebuilt image only helps after the pods or containers are replaced (e.g., with `kubectl rollout restart deployment/`).\n\n\n---\n\n### What Version to Patch To\n\n\nPHP has released the following versions that address the vulnerabilities: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36, and PHP 8.2.35.\n\n\n---\n\n### After Restarting, Verify\n\n\nInstall your patched version, then confirm the processes serving requests actually run it.\n You can check for any processes still using replaced/old files:\n\n```bash\nfor p in $(pgrep -f 'php-fpm|apache2|httpd|lsphp'); do\n grep -q '(deleted)' /proc/$p/maps 2>/dev/null && echo \"PID $p still maps a replaced file\"\ndone\n```\n\nIn short: **patch + restart** are both required steps — one without the other leaves you vulnerable.", "cited_urls": ["https://projectdiscovery.io/research/php2shell", "https://safeguard.sh/resources/blog/find-and-patch-every-php-runtime-after-php2shell", "https://www.guidepointsecurity.com/blog/how-to-patch-php2shell/", "https://tuxcare.com/blog/php2shell-cve/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-perplexity-1", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes. After applying the PHP2Shell fix, restart every process that runs PHP so it loads the patched runtime: **PHP-FPM, Apache if using mod_php, and long-running PHP workers** such as queue workers or schedulers.[1][3][4]\n\nExamples:\n\n```bash\nsudo systemctl restart php8.3-fpm\n# or\nsudo systemctl restart apache2\n```\n\nReplace the service name with your installed PHP version. For Docker, recreate the container from the patched image rather than merely restarting it.[5] Managed hosting panels may restart PHP automatically, but verify that the running PHP version/processes use the patched build.[2]", "cited_urls": ["https://lilting.ch/en/articles/php2shell-official-patch", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://www.criticalstart.com/resources/php2shell-rce-vulnerabilities", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://securityboulevard.com/2026/10/keep-calm-and-patch-php2shell/", "https://github.com/ersinkoc/php-fix", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.martincid.com/technology-sv/php2shell-php-patch-wordpress-sites-host/", "https://securityboulevard.com/2026/10/php2shell-the-fix-is-a-runtime-upgrade-not-a-code-change/", "https://sansec.io/research/php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-perplexity-2", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes—**restart PHP after applying the PHP2Shell patch** so running processes load the fixed code. Restart:\n\n- **PHP-FPM:** `sudo systemctl restart php8.3-fpm` (adjust the version/service name)\n- **Apache with mod_php:** restart Apache\n- **Long-running workers:** restart queue workers, schedulers, and other PHP daemons\n- **Docker:** recreate containers from the patched image; merely restarting may retain the old image\n\nSome hosting panels restart PHP automatically, but verify that all PHP workers started after the update. Patching files without restarting can leave the vulnerable runtime active.[1][3][4]", "cited_urls": ["https://lilting.ch/en/articles/php2shell-official-patch", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://www.criticalstart.com/resources/php2shell-rce-vulnerabilities", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://securityboulevard.com/2026/10/keep-calm-and-patch-php2shell/", "https://github.com/ersinkoc/php-fix", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.martincid.com/technology-sv/php2shell-php-patch-wordpress-sites-host/", "https://securityboulevard.com/2026/10/php2shell-the-fix-is-a-runtime-upgrade-not-a-code-change/", "https://sansec.io/research/php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-perplexity-3", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes. After applying the PHP2Shell patch, restart **every process that runs PHP** so it loads the patched runtime:\n\n- **PHP-FPM:** `sudo systemctl restart php8.3-fpm` — replace `8.3` with your installed version.\n- **Apache with mod_php:** restart Apache, preferably a full restart rather than only a graceful reload.\n- **Long-running workers:** restart queue workers, schedulers, daemons, and similar PHP processes.\n- **Docker:** recreate containers from the patched image; restarting a container alone may keep the old image.\n\nSome hosting panels automatically restart PHP-FPM during the update, but verify that all running workers started after the patch. Updating files on disk without restarting leaves existing PHP processes using the vulnerable code.[1][3][4]", "cited_urls": ["https://lilting.ch/en/articles/php2shell-official-patch", "https://panelica.com/blog/php2shell-explained-root-cause-fixed-versions-and-php-81-patch", "https://www.criticalstart.com/resources/php2shell-rce-vulnerabilities", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://securityboulevard.com/2026/10/keep-calm-and-patch-php2shell/", "https://github.com/ersinkoc/php-fix", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.martincid.com/technology-sv/php2shell-php-patch-wordpress-sites-host/", "https://securityboulevard.com/2026/10/php2shell-the-fix-is-a-runtime-upgrade-not-a-code-change/", "https://sansec.io/research/php2shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-overviews-1", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you must restart your PHP worker services immediately after applying the patch.\nInstalling the updated package only replaces the files on your disk. The active, vulnerable PHP code remains loaded in your server's memory until the process is completely flushed. If you do not restart, your server remains fully exposed to the critical PHP2Shell remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619).\nHow to Apply the Restart\nDepending on your server architecture, run the appropriate command to load the patched version:\nFor Nginx / PHP-FPM setups:\nFor Apache (mod_php) setups:\nFor Containerized Environments (Docker/Kubernetes):\nYou must rebuild your container images using the patched PHP base image and redeploy your pods/containers.\nVerify the Restart\nTo ensure no stale, vulnerable processes are still lurking in memory, check the start times of your PHP processes:\nAny process with a start time preceding your patch installation is still running the vulnerable code and must be killed or restarted.\n⚠️ Post-Patch Security Step\nBecause exploit attempts for PHP2Shell began circulating prior to the public disclosure on October 21, 2026, patching only prevents future attacks. It will not kick out an attacker who has already compromised the machine. You should immediately audit your system for unauthorized sh, bash, curl , or wget processes running under the web server user, and scan your web directories for newly created malicious PHP files.\nFurther Exploration\nIf you'd like, let me know:\nYour current operating system and PHP version\nYour web server software (Nginx, Apache, etc.)\nWhether you are using a managed hosting provider or running your own infrastructure/containers\nI can give you the exact, copy-pasteable commands required to securely cycle your environment.", "cited_urls": ["https://projectdiscovery.io/research/php2shell", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://en.wikipedia.org/wiki/PHP2Shell", "https://guardz.com/blog/quick-fix-guide-php2shell-vulnerability/", "https://www.servicenow.com/community/armis-articles/php2shell-how-to-find-prioritize-and-patch-affected-systems/ta-p/3612792", "https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-overviews-2", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you must absolutely restart your PHP processes or your web server after patching PHP2Shell. Updating the package files on your disk does not protect your server because active, running processes keep the old, vulnerable code loaded into memory .\nThe PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) are critical unauthenticated remote code execution (RCE) flaws, and restarting ensures the fixed code actually takes effect.\nWhat to Restart Based on Your Setup\nDepending on how your web server communicates with PHP, run the appropriate command:\nIf you use PHP-FPM (most common, e.g., Nginx + PHP):\nYou need to restart the PHP FastCGI Process Manager. Replace 8.4 with your active PHP version:\nIf you use Apache with mod_php (PHP embedded inside Apache):\nYou must restart the Apache web server itself to clear its memory:\nIf you use Containers (Docker, Kubernetes):\nSimply updating the host is not enough. You must rebuild your container images using the patched base image and redeploy them so the old containers are completely replaced .\nVerify That It Worked\nAfter restarting, it is highly recommended to verify that no legacy, vulnerable processes were left stranded in memory. You can check the start times of your active workers by running:\n(Any process showing a start time from before your patch application is still running the old, vulnerable binary and must be killed/restarted.)\nWhat environment are you currently patching? If you tell me your Operating System (e.g., Ubuntu, RHEL) and your web server type (Nginx, Apache), I can give you the exact verification and restart commands for your setup.", "cited_urls": ["https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://www.youtube.com/shorts/__XojZz3OtI", "https://securityboulevard.com/2026/10/keep-calm-and-patch-php2shell/", "https://stackoverflow.com/questions/12892331/do-i-need-to-restart-apache-after-changing-the-php-ini-file", "https://levelup.gitconnected.com/php2shell-two-critical-php-flaws-are-being-exploited-heres-how-to-patch-today-add61aa15d10", "https://www.youtube.com/watch?v=ST8bY4N6CMU"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-overviews-3", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you need to restart PHP or your web server after applying the emergency patches for PHP2Shell (CVE-2026-109618 and CVE-2026-109619).\nUpdating the binary package alone is not enough because active worker processes and memory-resident modules continue running old code until restarted.\nWhat You Need to Restart\nPHP-FPM: Restart the PHP-FPM service so every worker process loads the updated runtime code (e.g., using sudo systemctl restart php-fpm or your specific version/service name) .\nApache with mod_php: If your web server runs PHP directly via mod_php, restart Apache as well (e.g., using sudo systemctl restart apache2 or httpd).\nOther Runtimes: Restart any other affected serving processes or web servers (such as FrankenPHP, LiteSpeed, or php-cgi).\nVerification Steps\nCheck the active version: Run php -v or inspect your application info page to confirm the updated engine version is loaded.\nVerify serving processes: Ensure that old, unpatched worker processes have terminated and new ones have spawned.\nCheck logs: Inspect your system and web server logs for any signs of prior compromise, as patching closes the vulnerability but does not retroactively clean up an earlier intrusion.\nIf you'd like, let me know:\nWhat operating system or Linux distribution you are using?\nWhich web server/SAPI (PHP-FPM, Apache mod_php, Nginx, etc.) your stack relies on?\nI can provide the exact restart command for your environment.", "cited_urls": ["https://www.youtube.com/watch?v=5qsHV5oE0SY", "https://www.youtube.com/shorts/__XojZz3OtI", "https://www.youtube.com/watch?v=B-QEMiu5omI", "https://wavect.io/blog/php2shell-legacy-php-upgrade-migration/", "https://www.infomaniak.com/en/support/faq/2108/change-the-php-version-in-cli"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-mode-1", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you do need to restart PHP (and your web server integration) after applying the PHP2Shell (CVE-2026-109618 and CVE-2026-109619) security patches.\nWhy it's necessary: Because PHP binaries, modules, and worker memory stay loaded in active processes, simply updating the package files on disk leaves the already-running processes vulnerable and retaining old memory states. Restarting clears active workers and forces the system to load the newly patched core engine.\nWhat to restart: Depending on your stack, you must restart your PHP process manager and web server (e.g., php-fpm, apache2, nginx, or rebuild your container images if running Docker/Kubernetes).\nWould you like the specific restart commands for your particular environment (e.g., PHP-FPM with Nginx on Ubuntu, Apache, or Docker)?", "cited_urls": ["https://projectdiscovery.io/research/php2shell", "https://www.servicenow.com/community/armis-articles/php2shell-how-to-find-prioritize-and-patch-affected-systems/ta-p/3612792", "https://en.wikipedia.org/wiki/PHP2Shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-mode-2", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, absolutely. You must restart PHP (such as PHP-FPM or your web server integration like Apache with mod_php) after applying a PHP2Shell patch.\nWhy a restart is required:\nIn-Memory Code: PHP worker processes keep the PHP binary and runtime code loaded in memory. Upgrading the package updates the files on disk, but already-running worker processes will continue running the old, vulnerable code in memory until they are recycled or restarted.\nClearing State: One of the core vulnerabilities exploited in PHP2Shell (CVE-2026-109619) can abuse or leak data from worker memory. Restarting the workers wipes the existing in-memory state.\nHow to restart your services:\nDepending on your stack, use the appropriate command to restart the PHP processes:\nPHP-FPM (most common):\nsudo systemctl restart php8.3-fpm (adjust version number as needed)\nApache (if using mod_php):\nsudo systemctl restart apache2 or sudo systemctl restart httpd\nContainers/Rebuilds: If running containerized environments (Docker/Kubernetes), rebuild and redeploy your container images to ensure fresh runtimes.\nYou can verify that your workers have been restarted by checking the process start times using a command like ps -eo pid,lstart,cmd | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd' to ensure no old processes from before the patch window remain active.\nIf you'd like, tell me:\nWhat operating system or Linux distribution you are using (e.g., Ubuntu, RHEL)\nYour web server configuration (Nginx with PHP-FPM, Apache, etc.)\nI can provide the exact restart commands and a quick verification check for your specific setup.", "cited_urls": ["https://www.automox.com/blog/php2shell-what-you-need-to-know-and-how-to-respond", "https://projectdiscovery.io/research/php2shell", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q09-google-ai-mode-3", "question_id": "Q09", "question": "Do I need to restart PHP after patching PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you do need to restart PHP (and your web server integration) after applying the PHP2Shell patches for CVE-2026-109618 and CVE-2026-109619.\nWhy it's necessary: The vulnerabilities (including the memory-disclosure component in CVE-2026-109619) reside in the active PHP runtime and worker memory. Upgrading the binary packages updates the files on disk, but already-running processes or worker pools will still hold the old, vulnerable code and potentially compromised in-memory state until they are completely recycled.\nWhat to restart: Depending on your stack, you should restart your PHP-FPM service, your web server (such as Apache with mod_php or Nginx if handling fastcgi processes), and rebuild any affected container images (Docker/Kubernetes) to ensure fresh binaries and clean process memory are loaded.\nIf you'd like, let me know:\nYour operating system or Linux distribution (Ubuntu, RHEL, Alpine, etc.)\nYour web server / application stack (Nginx with PHP-FPM, Apache, Docker, etc.)\nI can provide the exact restart commands you need to run.", "cited_urls": ["https://projectdiscovery.io/research/php2shell", "https://www.servicenow.com/community/armis-articles/php2shell-how-to-find-prioritize-and-patch-affected-systems/ta-p/3612792"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-chatgpt-1", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "ChatGPT", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**If your website runs vulnerable PHP and you cannot patch it immediately, yes—I recommend temporarily taking the PHP service out of public reach.** If it is already patched, or does not expose PHP at all, there is no reason to take it offline solely because of PHP2Shell. Official guidance recommends considering isolation when immediate patching is not possible. ([digital.nhs.uk](https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai))\n\nAs of **October 22, 2026, patches are available**. PHP2Shell refers to two critical vulnerabilities—CVE-2026-109618 and CVE-2026-109619—that can allow attackers to execute code without logging in. PHP’s advisory covers PHP-FPM, Apache/mod_php, CGI, FrankenPHP and LiteSpeed—not just one server configuration. ([php.net](https://www.php.net/archive/2026.php))\n\n### What to do now\n\n1. **Confirm your host has patched the PHP runtime serving your website.** The fixed upstream releases are **8.2.35, 8.3.36, 8.4.27 and 8.5.12**. Older-looking distribution packages can also be safe if the vendor has backported both fixes; check the full package version against its advisory. Restart the affected services after updating. ([php.net](https://www.php.net/archive/2026.php))\n\n2. **If patching cannot happen immediately, block public access before requests reach PHP.** My recommendation is to have your host serve a static maintenance page while isolating the PHP backend. **A WordPress maintenance-mode plugin is not an adequate substitute:** PHP documents an attack path that runs before application code executes. ([digital.nhs.uk](https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai))\n\n3. **Do not treat a WAF as the fix.** Cloudflare has deployed protections, but explicitly still recommends patching PHP. Configuration workarounds likewise do not completely resolve the vulnerabilities. ([blog.cloudflare.com](https://blog.cloudflare.com/php-vulnerabilities-waf-protection))\n\n4. **If the site was exposed while unpatched, check for compromise.** Patching does not remove an existing intrusion. Ask your host to review logs, unexpected PHP files and unusual processes; if compromise is suspected, isolate the server and preserve evidence. ([security.utoronto.ca](https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/?utm_source=openai))\n\n**Who hosts your site, what platform does it use, and what PHP version does the hosting panel show?** With those details, I can help you decide whether downtime is necessary.", "cited_urls": ["https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai", "https://www.php.net/archive/2026.php", "https://blog.cloudflare.com/php-vulnerabilities-waf-protection", "https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-chatgpt-2", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "ChatGPT", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Not automatically—but if your website runs unpatched PHP and you cannot patch promptly, I recommend temporarily blocking public access to its PHP backend.** Taking vulnerable systems offline is consistent with official guidance when updates or temporary mitigations cannot be applied quickly. ([ncsc.gov.uk](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php))\n\nPHP2Shell refers to **CVE-2026-109618 and CVE-2026-109619**, which can allow attackers to execute code without logging in. **Patches were released on October 21, 2026.** PHP’s advisory covers all PHP installations serving web requests, not just Windows or Apache; it identifies Apache `mod_php` as the highest-risk configuration. ([php.net](https://www.php.net/archive/2026.php))\n\n### How to decide\n\n- **Already patched:** You generally do not need downtime solely because of PHP2Shell. The fixed upstream releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**, or later releases in those branches. Distribution vendors may backport fixes without changing to those version numbers, so check the full package version against your vendor’s advisory. ([php.net](https://www.php.net/archive/2026.php))\n- **Unpatched, but you can update now:** Apply the PHP update and restart the affected PHP/web-server processes so they actually use the fixed code. Updating your CMS or plugins alone does not replace the PHP runtime fix. ([ubuntu.com](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available))\n- **Unpatched and cannot update promptly:** My recommendation is to isolate the vulnerable backend until patched. PHP says its temporary configuration mitigations reduce particular attack paths but **do not make an installation safe**. ([php.net](https://www.php.net/archive/2026.php))\n- **No PHP handling web requests anywhere in your site’s infrastructure:** There is no reason to take it offline specifically for these PHP vulnerabilities. Confirm that includes backend services, not just the visible frontend. ([php.net](https://www.php.net/archive/2026.php))\n\n**A maintenance-mode plugin is not sufficient protection:** the demonstrated `mod_php` attack can run before application code. If you need a maintenance page, serve static HTML at the proxy/CDN or web-server layer while blocking requests to the vulnerable PHP backend. This recommendation follows from where the vulnerability executes. ([github.com](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w))\n\nIf you use managed hosting, ask support: **“Have you patched both PHP2Shell CVEs on the PHP runtime serving my site, and restarted the affected services?”**\n\n**Who hosts your site, what platform does it use, and what PHP version is it running?** With those details, I can help you determine whether downtime is necessary.", "cited_urls": ["https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php", "https://www.php.net/archive/2026.php", "https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-chatgpt-3", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "ChatGPT", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Yes—temporarily, if your website runs vulnerable PHP and you cannot patch it immediately. If it is already patched, you do not need to take it offline solely because of PHP2Shell.** Official guidance recommends considering taking affected systems offline when immediate patching is not possible. ([digital.nhs.uk](https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai))\n\nI checked the PHP project’s advisory: patches were released on **October 21, 2026**. PHP2Shell refers to two critical vulnerabilities that can let an attacker execute code without logging in. They affect PHP installations serving web requests—not just a particular CMS or plugin. ([php.net](https://www.php.net/archive/2026.php))\n\n### What to do now\n\n1. **Confirm your hosting provider has patched the PHP runtime serving your website.** The fixed upstream releases are **8.2.35, 8.3.36, 8.4.27, and 8.5.12**, or later releases in those branches. Older-looking version numbers can still be safe if your operating-system vendor has backported the fixes; get confirmation for **both CVE-2026-109618 and CVE-2026-109619**. ([php.net](https://www.php.net/archive/2026.php))\n\n2. **If it is unpatched—or your host cannot promptly confirm—my recommendation is to temporarily block public access to PHP.** A static maintenance page served without invoking PHP is an option. **Do not rely on a WordPress maintenance-mode plugin:** PHP’s advisory says some attacks execute before application code runs, so application-level maintenance mode is not a reliable barrier. ([digital.nhs.uk](https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai))\n\n3. **After updating, restart the affected PHP/web-server services** so running processes actually use the patched software. Installing updated packages alone may not be sufficient. ([ubuntu.com](https://ubuntu.com/blog/php2shell-vulnerability-fixes-available))\n\n4. **Do not treat configuration changes as a complete fix.** PHP explicitly says its temporary mitigations reduce exposure but do not make an installation safe. ([php.net](https://www.php.net/archive/2026.php))\n\nIf the server was exposed while vulnerable, also have your host check for compromise; patching does not remove an existing intrusion. ([security.utoronto.ca](https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/?utm_source=openai))\n\n**Who hosts your site, what platform does it use, and what PHP version does your hosting panel show?** Those details will help determine whether you need downtime.", "cited_urls": ["https://digital.nhs.uk/cyber-alerts/2026/cc-4875?utm_source=openai", "https://www.php.net/archive/2026.php", "https://ubuntu.com/blog/php2shell-vulnerability-fixes-available", "https://security.utoronto.ca/advisories/security-advisory-critical-unauthenticated-rce-in-php-php2shell/?utm_source=openai"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-claude-1", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Claude", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very serious and active threat. Here's a comprehensive breakdown to help you decide what to do:\n\n---\n\n## ⚠️ PHP2Shell — What You Need to Know\n\n### What Is It?\n\nCVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell, are two Remote Code Execution vulnerabilities in PHP, the scripting language many web servers use to run applications.\n \nBoth can allow **unauthenticated remote code execution** with the privileges of the web server account, and are rated **CVSS v4.0 9.2 (Critical)**.\n\n\n### Who Is Affected?\n\nAll PHP versions prior to the fixed releases are affected. The PHP Project considers **Apache mod_php** deployments to be at highest risk; **PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed** are also affected.\n\n\n\nPHP lists every release before **8.5.12, 8.4.27, 8.3.36, and 8.2.35** as vulnerable, and watchTowr has confirmed that older unsupported branches, including PHP 5, are also affected.\n\n\n### Is It Being Actively Exploited?\nYes. \nBoth CVE-2026-109618 and CVE-2026-109619 have been marked as **exploited in the wild**, and watchTowr has observed exploitation of both vulnerabilities.\n\n\n\nAmazon Threat Intelligence has reported an exploitation attempt on October 17, 2026, **before public disclosure**, and other security vendors have since reported further exploitation attempts.\n\n\n\nResearchers have also demonstrated **unauthenticated disclosure of PHP worker memory**, which can expose passwords, authentication tokens, and API keys.\n\n\n---\n\n## ✅ Should You Take Your Site Offline?\n\n**Not necessarily — but you must act immediately.** Here's the recommended path:\n\n### 1. 🔧 Patch First (Preferred Option)\n\nOn October 21, 2026, the PHP Project released **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35** to address both vulnerabilities. These updates are **not installed automatically** — organizations running PHP must apply them, or the equivalent packages from their Linux distribution, hosting provider, or appliance vendor.\n\n\n\nThe maintainers said there were **no complete mitigations** and that **updating was the only safe choice.**\n\n\n### 2. 🛡️ Consider Temporary Mitigations (Partial Only)\n\nIn-process protections, such as RASP or application-embedded WAF agents, **may not prevent exploitation**: on Apache mod_php, CVE-2026-109618 can be triggered by an unauthenticated request **before any application code runs.**\n\n\n\nCloudflare deployed temporary WAF rules as an attempted stopgap mitigation.\n If you use a WAF like Cloudflare, check if these rules are active for your account — but do not rely on them alone.\n\n### 3. 🔍 Check for Signs of Compromise\n\nThe PHP Project received the first reports of these issues on August 11, 2026, and exploitation attempts have been observed since at least October 17, 2026. Sophos recommends reviewing activity on exposed systems **from August 1, 2026 onwards.**\n\n\n### 4. 🔴 Take Offline Only If You Cannot Patch Immediately\nIf your site is running an **unsupported PHP version** (e.g., PHP 5, 7, or 8.0/8.1) and you cannot quickly patch or migrate, **taking it offline temporarily is a reasonable precaution** given active exploitation in the wild.\n\n---\n\n## Summary Table\n\n| Action | Priority |\n|---|---|\n| Upgrade to PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 | 🔴 Immediate |\n| Enable WAF rules (Cloudflare, etc.) | 🟡 Helpful but not sufficient |\n| Review server logs from August 1, 2026+ | 🟡 High |\n| Take offline if patch is impossible | 🟡 Situational |\n\n**Bottom line:** Patch your PHP installation **right now**. Taking your site offline is only necessary if patching is not immediately possible and your site handles sensitive data.", "cited_urls": ["https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://en.wikipedia.org/wiki/PHP2Shell"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-claude-2", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Claude", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very serious and active threat. Here's a comprehensive breakdown to help you decide:\n\n---\n\n## ⚠️ What is PHP2Shell?\n\n\nOn October 20, 2026, two vulnerabilities in the PHP interpreter — CVE-2026-109618 and CVE-2026-109619 (\"PHP2Shell\") — became public ahead of coordinated disclosure. Both can allow **unauthenticated remote code execution** with the privileges of the web server account, and are rated **CVSS v4.0 9.2 (Critical)**.\n\n\n\nResearchers have also demonstrated **unauthenticated disclosure of PHP worker memory**, which can expose passwords, authentication tokens, and API keys.\n\n\n---\n\n## 🚨 Is It Being Actively Exploited?\n\nYes. \nBoth CVE-2026-109618 and CVE-2026-109619 have been **exploited in the wild**, confirmed by watchTowr.\n\n\n\nAmazon Threat Intelligence identified a PHP2Shell exploitation attempt dating back to **October 17, 2026** — four days before public disclosure.\n\n\n\nCloudflare also reported signs of early exploitation prior to the public patch release, and deployed temporary WAF rules as an attempted stopgap mitigation.\n\n\n---\n\n## 🛠️ Is There a Fix?\n\n**Yes — patches are available.**\n\n\nOn October 21, 2026, the PHP Project released **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35** to address both vulnerabilities. These updates are **not installed automatically** — organizations running PHP must apply them, or the equivalent packages from their Linux distribution, hosting provider, or appliance vendor.\n\n\n\nThe maintainers stated there are **no complete mitigations** and that **updating is the only safe choice**.\n\n\n---\n\n## 🖥️ Who Is Affected?\n\n\nAll PHP versions prior to the fixed releases are affected. The PHP Project considers **Apache mod_php** deployments to be at highest risk; **PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed** are also affected.\n\n\n\nPHP lists every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable, and older unsupported branches — including PHP 5 — are also affected.\n\n\n\nIn-process protections such as RASP or application-embedded WAF agents **may not prevent exploitation**: on Apache mod_php, CVE-2026-109618 can be triggered by an unauthenticated request before any application code runs.\n\n\n---\n\n## ✅ Should You Take Your Site Offline?\n\n**Not necessarily — but you must act immediately.** Here's what to do:\n\n1. **Update PHP right now** to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (whichever branch you use). This is the #1 priority.\n2. **Check for signs of compromise** — \nthe PHP Project received first reports of these issues on August 11, 2026, and exploitation attempts have been observed since at least October 17, 2026. Sophos recommends reviewing activity on exposed systems from **August 1, 2026 onwards**.\n\n3. **If you cannot patch immediately**, taking your site offline temporarily is a reasonable precaution given that active exploitation is occurring and there are no complete workarounds.\n4. **Contact your hosting provider** — they may already have patches or mitigations deployed at the infrastructure level.\n\nThe bottom line: **patching is urgent**, but you only need to take your site offline if you truly cannot patch quickly and want to avoid being compromised in the interim.", "cited_urls": ["https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://en.wikipedia.org/wiki/PHP2Shell", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-claude-3", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Claude", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "This is a very serious and actively developing security situation. Here's a comprehensive breakdown to help you decide what to do:\n\n---\n\n## ⚠️ What is PHP2Shell?\n\n\nOn October 20, 2026, two vulnerabilities in the PHP interpreter — CVE-2026-109618 and CVE-2026-109619 (\"PHP2Shell\") — became public ahead of coordinated disclosure. Both can allow **unauthenticated remote code execution** with the privileges of the web server account, and are rated **CVSS v4.0 9.2 (Critical)**.\n\n\n\nSuccessful exploitation could let an attacker run malicious code on an affected server **without logging in**. That code would run with the permissions available to the PHP process, potentially allowing attackers to steal application data, alter website content, or establish a backdoor.\n\n\n\nResearchers have also demonstrated unauthenticated disclosure of PHP worker memory, which can expose passwords, authentication tokens, and API keys.\n\n\n---\n\n## 🔴 Is It Being Actively Exploited?\n\nYes. \nBoth CVE-2026-109618 and CVE-2026-109619 have been confirmed as **exploited in the wild** by watchTowr.\n\n\n\nAmazon Threat Intelligence has reported an exploitation attempt on October 17, 2026, before public disclosure, and other security vendors have since reported further exploitation attempts.\n\n\n---\n\n## ✅ Patches Are Available — Update NOW\n\n\nOn October 21, 2026, the PHP Project released **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35** to address both vulnerabilities. These updates are **not installed automatically**. Organizations running PHP must apply them, or the equivalent packages from their Linux distribution, hosting provider, or appliance vendor.\n\n\n**This is your #1 priority.** \nUpdating to a PHP release containing the patch to these vulnerabilities is the **only complete mitigation**.\n\n\n---\n\n## ❓ Should You Take Your Site Offline?\n\nIt depends on whether you can patch immediately:\n\n### If you CAN patch right now:\n**Patch and stay online.** \nAsk your hosting or IT provider to confirm PHP fixes are installed, not just scheduled, across all your websites and applications.\n\n\n### If you CANNOT patch immediately (or run PHP 8.1 or older):\n\nCISA's advice is blunt: organizations that can't update immediately, or still run PHP 8.1 or older, **should take PHP systems offline** until they are patched.\n\n\n\nThe UK National Cyber Security Centre (NCSC) has also warned UK organizations to **immediately update systems using PHP or take them offline** until they can be patched.\n\n\n\nPHP core developer Gina Peter Banyard wrote that the only mitigation is patching or upgrading PHP, and added that **taking a server offline for a day is the most sensible option** for anyone who can afford it.\n\n\n---\n\n## 🛡️ Temporary Mitigations (If You Can't Patch Yet)\n\nThese are **stopgaps only** — not full fixes:\n\n- \nIn-process protections, such as RASP or application-embedded WAF agents, may not prevent exploitation: on Apache mod_php, CVE-2026-109618 **can be triggered by an unauthenticated request before any application code runs.**\n\n- \nReview and tune web application firewall (WAF) rules to cover newly disclosed exploit patterns. **If you cannot patch quickly, take systems offline or restrict to GET/HEAD requests.**\n\n- \nIf you can go further, allow only GET and HEAD requests, which leaves the site readable and closes every write path. If you can go further still, stop PHP-FPM and serve a static maintenance page.\n\n\n---\n\n## 🧩 What PHP Versions Are Affected?\n\n\nPHP lists every release before 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as vulnerable, and watchTowr has confirmed that **older unsupported branches, including PHP 5, are also affected.**\n\n\n\nThe PHP Project considers **Apache mod_php** deployments to be at highest risk; **PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed** are also affected.\n\n\n---\n\n## ✅ Summary: What Should You Do?\n\n| Situation | Action |\n|---|---|\n| Running PHP 8.2–8.5 | **Patch immediately** to the latest fixed release |\n| Running PHP 8.1 or older | **Take offline immediately**, then upgrade to a supported version and patch |\n| Can't patch right now | **Take offline or apply WAF rules as a stopgap**, patch ASAP |\n| Hosted on WordPress.com, WP Cloud, etc. | \nAutomattic said sites on WordPress.com, WordPress VIP, WP Cloud, and Pressable are **already protected** — customers on those services do not need to take action.\n |\n\n**Bottom line:** Don't stay online unpatched and unprotected. Either patch immediately or take your site offline until you can. \nTaking a website offline might be inconvenient, but a compromised production environment is significantly worse.", "cited_urls": ["https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell", "https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities", "https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/", "https://www.newsweek.com/php-vunerability-php2shell-issue-websites-hack-server-12601225", "https://computingforgeeks.com/php2shell-mitigation-without-patching/", "https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/", "https://www.flyingpenguin.com/php2shell-ini-wont-save-you/", "https://www.armis.com/blog/php2shell-how-to-find-prioritize-and-patch-affected-systems/", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://dev.to/opctim/php2shell-mitigating-the-critical-php-rce-before-the-patch-2i0e"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-perplexity-1", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Perplexity", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Not necessarily—patch it immediately first.** Take the site offline if you cannot quickly verify that PHP is patched or otherwise isolate the vulnerable service.\n\n- Ask your host or IT provider to confirm the fix is **installed**, not merely scheduled.\n- Upgrade to a fixed PHP release: **8.2.35, 8.3.36, 8.4.27, or 8.5.12**, or use a vendor package with a confirmed backport.[3]\n- If you cannot patch promptly, take the PHP application offline or isolate it from the public internet, as security agencies recommend.[1][3]\n- A WordPress “maintenance mode” page alone is insufficient if PHP still processes requests; use a server-level shutdown or a static, non-PHP holding page.[5]\n- If taking it offline, return **HTTP 503** rather than allowing timeouts or serving 404/500 responses, to reduce SEO impact during the maintenance window.[7]\n- After patching, review logs, authentication activity, file changes, and backups for signs of compromise; patching does not undo an earlier breach.\n\nIf you do not know which PHP version your site uses, assume it may be affected until your hosting provider confirms otherwise.", "cited_urls": ["https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://safeguard.sh/resources/blog/php2shell-end-of-life-php-7-4-8-0-8-1-options", "https://nebula.design/security/php2shell/", "https://uptimerobot.com/knowledge-hub/reports-research/inside-php2shell-why-websites-took-themselves-offline/", "https://www.seroundtable.com/google-php2shell-42353.html", "https://www.bostonglobe.com/2026/10/21/business/website-vulnerabilities-php-update-php2shell/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://www.endorlabs.com/learn/php2shell-critical-vulnerabilities-in-php-cve-2026-109618-cve-2026-109619"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-perplexity-2", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Perplexity", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Only if you cannot promptly verify that PHP is patched.** PHP2Shell reportedly enables unauthenticated remote code execution, and security agencies advise taking affected internet-facing systems offline—or isolating them—when immediate patching is not possible.[1][3]\n\nDo this now:\n\n1. **Ask your hosting provider to confirm that the server is patched**, not merely that an update is planned.\n2. If you manage PHP yourself, update to the fixed branch release: **PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12**, or install a vendor package with a confirmed backport.[3]\n3. If you use an unsupported PHP version and cannot obtain a verified fix, **take the site offline or isolate it from the public internet** until you can upgrade.[4]\n4. If downtime is necessary, use a server-level static maintenance page and return **HTTP 503**, rather than relying only on a WordPress maintenance plugin; PHP may still execute behind that plugin.[5][7]\n5. After patching, review logs, administrator accounts, files, scheduled tasks, and backups for signs of compromise. Rotate credentials if the site was exposed while vulnerable.\n\nA simple brochure site can often remain available as a **static, non-PHP copy**. For an e-commerce, login, or admin-heavy site, prioritize isolation and patching over keeping it online.[4]", "cited_urls": ["https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://safeguard.sh/resources/blog/php2shell-end-of-life-php-7-4-8-0-8-1-options", "https://nebula.design/security/php2shell/", "https://uptimerobot.com/knowledge-hub/reports-research/inside-php2shell-why-websites-took-themselves-offline/", "https://www.seroundtable.com/google-php2shell-42353.html", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://www.endorlabs.com/learn/php2shell-critical-vulnerabilities-in-php-cve-2026-109618-cve-2026-109619", "https://www.bostonglobe.com/2026/10/21/business/website-vulnerabilities-php-update-php2shell/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-perplexity-3", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Perplexity", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "**Take it offline only if you cannot verify that PHP has been patched immediately.** If your site runs PHP and your host cannot confirm an installed fix, temporarily disable public access or serve a static, non-PHP maintenance page. Security agencies have recommended taking unpatchable internet-facing systems offline because PHP2Shell may enable unauthenticated remote code execution.[1][3]\n\nDo this now:\n\n1. Ask your hosting provider whether your server is patched—not merely scheduled for an update.\n2. Upgrade to a fixed PHP release: **8.2.35, 8.3.36, 8.4.27, or 8.5.12**, or a vendor package with the fix.[3]\n3. If patching is unavailable, isolate or disable the site at the web-server, firewall, hosting, or CDN level. A WordPress “maintenance mode” plugin is insufficient because PHP still executes.[5]\n4. Take an off-server backup, then inspect logs, accounts, files, and databases for compromise before bringing the site back.\n5. If taking it offline, return **HTTP 503** rather than allowing timeouts, 404s, or 500s, which is better for search visibility during temporary maintenance.[7]\n\nIf the site is already on a confirmed patched PHP package, it generally does **not** need to go offline; still update vulnerable applications and plugins and investigate any suspicious activity. Unsupported PHP versions require a confirmed backport or isolation/offline treatment.[4]", "cited_urls": ["https://www.usatoday.com/story/news/nation/2026/10/21/php-vulnerability-php2shell-updates--live/92362348007/", "https://www.unlimitedwebhosting.co.uk/blog/php2shell-critical-php-vulnerabilities/", "https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://safeguard.sh/resources/blog/php2shell-end-of-life-php-7-4-8-0-8-1-options", "https://nebula.design/security/php2shell/", "https://uptimerobot.com/knowledge-hub/reports-research/inside-php2shell-why-websites-took-themselves-offline/", "https://www.seroundtable.com/google-php2shell-42353.html", "https://www.bostonglobe.com/2026/10/21/business/website-vulnerabilities-php-update-php2shell/", "https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/", "https://www.endorlabs.com/learn/php2shell-critical-vulnerabilities-in-php-cve-2026-109618-cve-2026-109619"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-overviews-1", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Overviews", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you should temporarily take your website offline or isolate it from the public network if you cannot immediately patch your PHP runtime, because the PHP2Shell vulnerabilities allow unauthenticated attackers to execute remote code on your server.\nThe Risk (PHP2Shell)\nThe Vulnerabilities: Tracked as CVE-2026-109618 and CVE-2026-109619 , these are critical remote code execution (RCE) flaws with a CVSS severity score of 9.2.\nHow it works: Attackers can send specially crafted requests to trigger memory management and error-handling flaws in PHP without needing login credentials .\nActive exploitation: Exploitation attempts have been observed in the wild.\nWhat You Should Do Instead of Just Pulling the Plug\nUpdate PHP Immediately\nThe PHP project released emergency security patches on October 21, 2026. Update your server to the fixed versions:\nPHP 8.5.12\nPHP 8.4.27\nPHP 8.3.36\nPHP 8.2.35\n(Note: Updating WordPress, Drupal, or plugins alone is not enough; you must update the core PHP runtime itself.)\nCheck Unsupported Versions\nIf you are running PHP 8.1 or older, official security updates may not be available for your version. In this case, you should migrate to a supported version immediately or keep the site offline/isolated.\nUse a Web Application Firewall (WAF)\nIf you use a WAF like Cloudflare, , or Akamai, check that their virtual patching or anomaly rules against suspicious multipart/form-data payloads are active and set to block. However, a WAF is a temporary buffer, not a permanent substitute for patching.\nIsolate or Take Offline\nIf you cannot patch right away and lack an enterprise WAF layer, agencies like CERT-EU and the ACSC recommend pulling the application offline or isolating it from public networks until the update is applied.\nIf you'd like, tell me:\nWhat version of PHP your server is currently running\nWho your hosting provider or operating system vendor is\nI can help guide you on how to check or apply the right fix.", "cited_urls": ["https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://www.reddit.com/r/selfhosted/comments/1xbcbty/php_warns_it_plans_to_release_2_emergency_patches/", "https://www.sentinelone.com/blog/stopping-php2shell-how-sentinelone-protects-customers-from-this-attack-technique/", "https://www.bluewin.ch/en/digital/security-vulnerability-threatens-millions-of-websites-what-does-that-mean-li.3643831", "https://www.action1.com/blog/php2shell-the-biggest-risk-is-the-php-you-dont-know-youre-running/", "https://www.youtube.com/watch?v=Zm2GQv8yp3s", "https://www.youtube.com/watch?v=kWJr35Mil3U", "https://www.techzine.eu/blogs/security/145168/php-shuts-the-internet-why-php2shell-affects-every-company/", "https://thenextweb.com/news/php-vulnerability-cert-eu-websites-offline"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-overviews-2", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Overviews", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "You do not need to keep your website permanently offline if you can apply the official security patches immediately.\nThe critical vulnerabilities known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10) allow unauthenticated remote code execution. Official fixes were released on October 21, 2026:\nFixed PHP versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35\nUnsupported/vulnerable versions: If you are running older, end-of-life versions (such as PHP 5.x, 7.x, or 8.1), updating to a supported version is required because no patch will be issued for them.\nWhat You Should Do Instead of Staying Offline\nUpdate PHP: Upgrade your server environment to one of the patched versions (8.5.12, 8.4.27, 8.3.36, or 8.2.35).\nKeep the site offline only temporarily: If you cannot patch or upgrade immediately and your site is high-risk or publicly exposed, keeping it temporarily offline is a safe short-term precaution.\nCheck older versions: If your application relies on an unsupported PHP version (like 7.4 or 8.1), you must plan a migration to a supported branch, or deploy strict Web Application Firewall (WAF) rules/network segmentation until you can upgrade.\nInspect for compromise: Review your server logs for unusual activity, unexpected file modifications, or unauthorized access attempts that may have occurred before the patch was applied.\nIf you'd like, tell me:\nWhat version of PHP your server is currently running\nWhat hosting environment or CMS (e.g., WordPress, custom app) you use\nI can help you outline the exact steps to patch or secure your setup.", "cited_urls": ["https://sliplane.io/blog/php2shell-php-vulnerability-what-you-need-to-do", "https://c360red.com/php2shell-no-need-to-panic-heres-your-plan/", "https://watchtowr.com/intelligence/php-cve-2026-109618-faq/", "https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619", "https://www.facebook.com/truecitizennews/posts/-noticeattention-customerswe-want-to-make-you-aware-of-a-critical-security-vulne/1761464398784403/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-overviews-3", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Overviews", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "You should not need to take your website offline permanently, provided you immediately update PHP to a patched version released on October 21, 2026.\nThe PHP Foundation released emergency security updates (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35) to fix the PHP2Shell vulnerabilities ( and CVE-2026-109619), which allow unauthenticated remote code execution with a CVSS severity score of 9.2 .\nWhat You Should Do Instead of Staying Offline\nUpdate PHP Immediately: Contact your hosting provider or check your server configuration to upgrade your PHP runtime to the latest patched releases (8.5.12, 8.4.27, 8.3.36, or 8.2.35). (Note: Updating your CMS like WordPress alone is not enough; the underlying PHP language runtime on the server must be updated .)\nIsolate or Go Offline Temporarily (If You Can’t Patch): If you are running an older or unsupported version of PHP that will not receive an official patch, or if you cannot apply the update right away, and security agencies strongly recommend taking the site offline or isolating it from the public internet until it can be secured.\nUse a Web Application Firewall (WAF): If you use a service like Cloudflare, AWS, or Akamai, verify that virtual patching and rules blocking anomalous multipart/form-data payloads are active. This provides a temporary shield while you schedule a full update.\nCheck for Compromise: Because exploitation attempts were observed prior to the public patch release, review your server access and error logs for suspicious activity or indicators of compromise (IoCs).\nIf you'd like, let me know:\nWhat version of PHP your server is currently running\nWho your hosting provider is\nI can help you figure out your next steps to safely bring your site back up.", "cited_urls": ["https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://addy.io/blog/addy-io-went-offline-for-the-php2shell-vulnerability/", "https://www.reddit.com/r/selfhosted/comments/1xbcbty/php_warns_it_plans_to_release_2_emergency_patches/", "https://www.sentinelone.com/blog/stopping-php2shell-how-sentinelone-protects-customers-from-this-attack-technique/", "https://www.youtube.com/watch?v=kWJr35Mil3U", "https://www.techzine.eu/blogs/security/145168/php-shuts-the-internet-why-php2shell-affects-every-company/", "https://www.action1.com/blog/php2shell-the-biggest-risk-is-the-php-you-dont-know-youre-running/", "https://cert.europa.eu/publications/security-advisories/2026-018/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-mode-1", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Mode", "run": 1, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "The PHP2Shell vulnerability (CVE-2026-109618 and CVE-2026-109619) is a severe remote code execution (RCE) flaw discovered in core PHP affecting versions spanning the last decade. Because it allows unauthenticated attackers to execute commands directly on vulnerable servers, it has triggered millions of automated exploit attempts globally and prompted some organizations and government entities to temporarily pull services offline.\nWhether you should take your website offline depends entirely on your current action plan and whether you have already secured your server environment.\nWhen you should take your website offline temporarily:\nYou cannot patch immediately: If your hosting provider or server infrastructure does not yet have the updated PHP packages available and you are seeing suspicious traffic or cannot implement a Web Application Firewall (WAF) rule to block exploit payloads, taking it offline is a valid defensive precaution.\nYou suspect prior compromise: Cloudflare and Amazon Threat Intelligence noted widespread scanning and early exploitation attempts even prior to public disclosure. If your server logs show anomalous behavior, CPU spikes, or unknown processes running, taking the site offline to audit and clean the system is critical.\nWhen you don't need to stay offline (or go offline):\nYou have already patched: Emergency security patches have been released by PHP. If you have updated your PHP runtime to the fixed versions (such as 8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher depending on your branch) and restarted your web services/workers, your immediate risk is mitigated.\nYou are protected via WAF/Edge filters: If your site sits behind a robust cloud security provider (like Cloudflare) that has deployed virtual patches or firewall rules blocking the exploit signatures, you are heavily insulated while you schedule your core updates.\nRecommended Action Plan\nCheck your PHP version: Log into your server or control panel to see what PHP version your application is running.\nUpdate immediately: Coordinate with your host or system administrator to apply the latest PHP security release.\nInspect logs: Check your access and error logs for signs of strange requests or unauthorized execution before assuming everything is clean.\nIf you'd like, let me know:\nWhat PHP version your server is currently running\nWhether you have root/admin access to update it or rely on a managed host\nI can help you determine the best immediate steps to secure your setup.", "cited_urls": ["https://www.wiz.io/blog/php2shell-php-rce", "https://en.wikipedia.org/wiki/PHP2Shell", "https://www.youtube.com/watch?v=nsPd83hc8hA", "https://www.instagram.com/reel/Dezex5eNh3L/", "https://x.com/MarioNawfal/status/2113306889408893183", "https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-mode-2", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Mode", "run": 2, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, taking your website offline—or at least isolating it from the public internet—is a valid and heavily recommended temporary precaution if you are running an unpatched version of PHP and cannot update immediately.\nPHP2Shell consists of critical remote code execution (RCE) vulnerabilities (CVE-2026-109618 and CVE-2026-109619) affecting PHP versions 5.4 through 8.5. Because active exploitation in the wild has been detected and public proof-of-concept exploits are widely available, unauthenticated attackers can potentially execute system commands or read sensitive process memory (such as database credentials and API keys).\nInstead of keeping the site blindly running at high risk, use this comparative guide to decide your immediate next steps:\nOption A: Take Offline / Isolate\nPros: Immediate 100% protection against active exploitation attempts while you work on the server.\nCons: Downtime for your users/business.\nWhen to choose: If you cannot verify your PHP version right now, cannot update immediately, or suspect you may already be compromised.\nOption B: Patch Immediately (Recommended)\nPros: Fixes the underlying vulnerability without needing prolonged downtime.\nCons: Requires administrative access and coordination with your host.\nWhen to choose: If emergency patches (PHP versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later) are available via your operating system vendor or hosting provider.\nOption C: WAF / Temporary Mitigations\nPros: Keeps the site online while filtering malicious traffic patterns.\nCons: Web Application Firewalls (WAFs) might not catch every novel variant of an RCE exploit chain.\nWhen to choose: Only as a short-term stopgap if patching or taking offline is completely unfeasible, and you are actively monitoring logs.\nIf you are using an official release, check the Malwarebytes Security Advisory or consult your hosting provider's emergency update channels to apply the patch.\nIf you'd like to proceed, tell me:\nWhat PHP version your server is currently running\nWhether you have SSH/admin access to update it or are using a managed host\nI can help you determine the fastest way to secure your specific setup.", "cited_urls": ["https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://www.wiz.io/blog/php2shell-php-rce", "https://en.wikipedia.org/wiki/PHP2Shell", "https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/", "https://www.cnbc.com/2026/10/22/php2shell-vulnerability-what-is-it-and-is-your-data-at-risk.html"], "excluded": false, "exclusion_reason": null, "redacted": false} {"answer_id": "Q10-google-ai-mode-3", "question_id": "Q10", "question": "Should I take my website offline because of PHP2Shell?", "engine": "Google AI Mode", "run": 3, "captured_at_utc": "2026-10-23T00:20:55.813Z", "answer_text": "Yes, you should temporarily take your website offline if it runs an unpatched version of PHP and you cannot apply the official security updates immediately.\nCybersecurity agencies and the PHP development team issued urgent warnings regarding PHP2Shell—a pair of critical remote code execution vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619 (with severity scores of 9.2/10). Because automated tools and malicious actors can exploit these flaws to take over affected servers, taking your site offline is the safest emergency stopgap if patching is not yet complete.\nImmediate Action Plan\nCheck Your PHP Version\nThe PHP project has released emergency security patches in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.\nNote that older versions like PHP 8.1 and earlier are no longer supported and will not receive official patches from the PHP project. If you are on an end-of-life version, you must upgrade your PHP version or isolate the site.\nUpdate Immediately\nContact your web hosting provider, system administrator, or check your server control panel to see if the patched PHP package is already available to install.\nIf your host has already pushed the update or you can upgrade right away, apply the patch immediately and verify your site is running a secure build.\nWhen to Take the Site Offline\nTake it offline if you use an affected PHP version and your hosting provider hasn't patched it yet, or if you cannot verify your security status right now.\nKeep it offline (or isolate it from public networks) until the update is deployed, as leaving an unpatched public-facing PHP application online leaves it wide open to remote code execution.\nTo help you figure out the exact next step, tell me:\nWhat PHP version is your server currently running?\nAre you on a managed host (like cPanel, WordPress-managed, etc.) or a self-hosted VPS / dedicated server?", "cited_urls": ["https://www.malwarebytes.com/blog/bugs/2026/10/php2shell-why-websites-are-going-offline-for-emergency-security-updates", "https://indianexpress.com/article/explained/explained-sci-tech/php2shell-php-security-flaws-websites-offline-explained-10931935/lite/", "https://therecord.media/php-script-vulnerabilities-warnings", "https://www.youtube.com/watch?v=_QHA5wzEMvQ", "https://addy.io/blog/addy-io-went-offline-for-the-php2shell-vulnerability/"], "excluded": false, "exclusion_reason": null, "redacted": false}