Skip to content
Kona Business AI
Sign inStart building free
Start building free
Menu
Start building free

PHP security · Website owners

PHP2Shell: PHP patches and a website owner’s checklist

The October PHP emergency updates need a runtime check, a separate follow-up review, and evidence that the right system was updated. Here is what to ask your host.

Kona Business AI
Published 7 min read
Read the guide Meet Aegis
White surf against black volcanic rocks under a coral sunset

Quick answer

What to know.
What to do next.

Sources reviewed October 23, 2026

PHP released emergency fixes on October 21, 2026 for PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Verify the PHP runtime actually serving your website, apply the appropriate vendor update, and review suspicious activity. A separate October 23 notice, CVE-2026-115560, requires an additional configuration check for applications that change their session serializer at runtime.[1] [2]

  • Check web-serving PHP across hosting accounts, containers, and embedded services; this is not limited to Windows or CGI.
  • Record the fixed package build and the actual running website context, including every production replica.
  • Treat attack attempts, successful compromise, and successful patch verification as separate evidence questions.

What happened, and what the attack reports establish

The October 21 advisories describe two critical remote-code-execution issues involving memory corruption and stale request state. Both carry a CVSS score of 9.2. PHP says all installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Actual exploitability depends on the build, configuration, extensions, and application.[1] [3] [4]

Amazon’s October 21 report identifies exploitation attempts against its MadPot honeypots dating to October 17. It explicitly says whether those attempts would succeed on real systems was unclear. Sophos corrected an earlier success claim on October 22: its analysis found scanning and failed attempts, with no evidence of successful compromise in that telemetry. These reports justify urgent checks without proving your website was breached.[6] [7]

Which PHP versions fix the October 21 vulnerabilities?

These are the first upstream releases fixing CVE-2026-109618 and CVE-2026-109619. Use the latest appropriate supported security build available through your provider. Distribution packages may include backported fixes while retaining an older-looking version number; confirm the vendor advisory and exact package build.[1] [3] [4]

PHP 8.1 and older are outside normal upstream support. Exceptional source backports do not restore maintenance. Ask your vendor about supported coverage and migration. PHP 8.2 security support ends December 31, 2026, so patching the immediate issue should accompany a separate compatibility-tested upgrade plan.[1] [8]

First upstream fixes for the October 21 pair; not a fix claim for the October 23 follow-up.
PHP branchEarlier branch releasesFirst fixed release
8.2Before 8.2.358.2.35
8.3Before 8.3.368.3.36
8.4Before 8.4.278.4.27
8.5Before 8.5.128.5.12

The October 23 follow-up needs a separate check

CVE-2026-115560 concerns an unusual combination: configuration starts session.serialize_handler as php_binary or php_serialize, application code switches it to php using ini_set() before session_start(), and session upload progress remains enabled. Do not assume every patched deployment meets these conditions, or that the October 21 releases resolve this separate issue.[2]

PHP recommends session.upload_progress.enabled=0 for protection until the next regular bugfix release. Keep that mitigation if already applied. Have your administrator apply configuration before request parsing and restart workers as required; runtime ini_set() is not the way to implement this mitigation. PHP says applications that never change the serializer at runtime can keep the feature enabled.[2] [1]

A practical checklist for your administrator or hosting provider

Assign one owner and request evidence for each site. CISA prioritizes internet-facing systems and advises taking unpatchable or unsupported PHP systems offline until updated. Agree on business continuity with the administrator. A WAF can add protection while patching, but neither a blocked request nor a clean dashboard establishes that the runtime is fixed.[5]

  1. Identify each website, host or container, serving method, PHP branch, vendor package build, and responsible owner. Include embedded PHP services and every production pool or replica.
  2. Ask the provider to confirm coverage for both October 21 CVEs, the deployed build, and maintenance completion. Updating a website theme or plugin alone does not update its PHP runtime.
  3. Check the October 23 serializer conditions separately. Record the configuration decision and which serving workers received it.
  4. Record the current state, approved target, backup or rollback method, maintenance window, and application smoke tests before making the change.
  5. Apply the update through the responsible administrator or hosting platform. Reload or restart serving processes as instructed, then test login, checkout, uploads, and other important workflows.
  6. Capture a fresh observation of the actual web runtime through an authorized internal diagnostic or hosting control plane. A terminal PHP version alone cannot verify the website.

Patching and investigating are different tasks

Preserve available web, application, process, file, and security-provider evidence from at least October 17. Look for unexpected PHP child processes, shell execution, downloads, file modifications, and unusual upload activity. Escalate suspicious evidence to the administrator or incident responder. A request pattern, crash, HTTP 200 response, or IP match alone does not establish successful exploitation; a patch does not remove an existing compromise.[6] [5]

Aegis in Kona Business AI

Build your PHP update and verification checklist in Aegis

Use Aegis in Kona Business AI to turn the advisory into an owned work item. Bring the hosting response and deployment details so the plan addresses your actual system.

  1. Ask Chat about the exact CVEs and review the returned sources; unavailable or incomplete records leave questions open.
  2. Add supplied asset and provider evidence in Workspace, then prepare a remediation plan with a target build, owner, and rollback notes.
  3. After your administrator acts externally, submit a newer observation for the same asset and compare it with the approved target.

A prompt to adapt in Chat

Help me review CVE-2026-109618, CVE-2026-109619, and the October 23 CVE-2026-115560 notice. Separate missing deployment evidence from known facts, and prepare questions for my host plus an update and verification checklist.

Aegis does not patch or scan your site. Its collector observes PHP CLI, which may differ from web PHP; runtime names are not automatically mapped to OSV packages. Its existing PHP-CGI log pattern is not a PHP2Shell detector. Verification compares submitted evidence with a target, not an independent attestation of safety.

Ask Aegis in Chat Open security Workspace

Chat requires a Kona account. Share only the redacted information you are authorized to use; keep passwords, tokens, and recovery codes out of prompts. How Aegis handles your evidence.

Sources

Sources and editorial review

Reviewed October 23, 2026. We distinguish publication dates, observed activity, and what the evidence establishes. Security guidance can change; consult the linked source for later updates. Kona’s editorial standards.

  1. [1]

  2. [2]

  3. [3]

  4. [4]

  5. [5]

  6. [6]

  7. [7]

  8. [8]

FAQ

Frequently asked questions

Practical answers for website owners, account administrators, and the people responsible for follow-up.

Does updating WordPress or its plugins fix PHP2Shell?
No. PHP is the runtime beneath the application. Your host or administrator must confirm the relevant PHP security build and configuration for each website. Application and plugin updates remain useful, but do not establish that the PHP runtime was patched.
Is the PHP version in my terminal enough to verify the website?
No. PHP CLI can use a different executable and configuration from PHP-FPM, Apache mod_php, or another web runtime. Verify the serving process through an authorized internal diagnostic or hosting control panel, and record the asset and observation time. Avoid publishing a phpinfo page.
Do the October 21 patches also fix CVE-2026-115560?
PHP’s October 23 notice describes a separate issue under specific runtime serializer-switching conditions. It recommends disabling session upload progress for affected configurations pending the next regular bugfix release. As reviewed October 23, the notice does not announce an already-patched release for that issue.
Can a WAF replace the PHP update?
No. CISA describes a WAF as potential protection while patching. Coverage depends on the rule and deployment. Use the vendor update path, verify the running system, and follow isolation guidance if an exposed system cannot be patched promptly.
Can Aegis prove that my website was never compromised?
No. Aegis organizes supplied evidence and remediation work. A matching new observation can support a recorded update check, but it does not prove that no intrusion occurred. Suspicious processes, file changes, or provider alerts need investigation by the responsible administrator or incident responder.

Keep reading

More security guides

View the full library