PHP2Shell Response GuideAWS, Legacy PHP, and Vulnerability Response in the AI Era

1. Bottom line: fixes are available; identify the PHP actually running and its distributor

Information checked: October 21, 2026, 23:55 JST (14:55 UTC). This first edition uses information published after PHP released its fixes. Subsequent changes will appear in the update history below.

On October 21, 2026, PHP released fixes for two critical vulnerabilities that can enable unauthenticated remote code execution: CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2, Critical. Researchers call the issues PHP2Shell. The previously announced release time was 23:00 JST; at the time of this review, the releases were available. There is no reason to keep waiting for that announcement.^[1][2]

This table describes upstream releases. If an OS vendor has backported the fix to an older version, use that vendor's advisory and the complete package version to determine its status. PHP 8.2 upstream security support ends on December 31, 2026. Track the immediate fix separately from the decision about the next supported branch.^[3][14]

The recommendation in this article is to work on three things in parallel: restrict exposure, replace the runtime with a maintained fix, and retain evidence that the replacement is running. Systems that cannot upgrade immediately still have options. There is no universal setting that makes an unpatched public deployment safe indefinitely.

Start with seven inventory fields: service name, external entry point, SAPI (the PHP execution interface), web runtime version, OS and distributor, running image, and owner. php -v alone does not establish the state of PHP-FPM or Apache running a different binary. With multiple servers, one representative host is not evidence for the fleet.

2. What broke: cleanup or a later request uses memory left in an invalid state

Researchers report an affected path reaching back at least to PHP 5.4. This does not mean every older version has identical exploit conditions or paths. Keep old branches in the inventory and check fixes for the specific branch.^[7]

The PHP runtime receives a request and parses its input before executing application code. These vulnerabilities center on memory management inside that runtime. The component requiring repair is different from an application query affected by SQL injection.

CVE-2026-109618 concerns interruption and cleanup when memory runs out. An out-of-memory condition can interrupt initialization of internal data, after which shutdown treats incomplete state as valid. PHP's advisory describes validated unauthenticated RCE in ordinary mod_php configurations before application code executes. The fix changes OOM control flow, combining termination at a safe point with process exit if memory pressure becomes more severe.^[4]

CVE-2026-109619 concerns references that outlive a request. A request's memory is freed, but a worker retains a reference. A later request handled by that worker may consume it before ordinary initialization clears it, causing a use-after-free. Fatal errors are one route; diagnostics during shutdown can also repopulate state that should have been cleared.^[5]

The worker survives while request-owned memory changes. The obsolete key is a metaphor for a later request using a reference whose lifetime has ended.

Correct application code can still run on an affected lower layer. Researchers demonstrated RCE against several applications, including WordPress, and separately reported process-memory disclosure without first achieving RCE. These are research demonstrations, not reports that every deployment of those products has been compromised.^[6]

A CVSS score of 9.2 establishes urgency, not an attack success rate. The official vector also records high attack complexity and the presence of attack requirements. Builds, extensions, input handling, and worker behavior affect the conditions. Failure of one published reproduction in your environment therefore does not prove the runtime is unaffected.

3. Which systems are exposed: prioritize by execution interface and reachable paths

PHP asks operators to update all installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. An unpatched, internet-facing mod_php deployment deserves particular urgency. Input parsing can run before an application login check, so application authentication alone is not a boundary for that path.^[1]

The FPM distinction matters. A worker exits when request startup fails, preventing the identical mod_php startup sequence. However, a validated path leaves state behind during application processing after normal startup and consumes it in a subsequent request. Blocking one path and repairing the runtime are different conclusions.^[5][7]

Prioritize by external reachability, similarity to validated attack conditions, and the data and privileges available after compromise. Internal services still need attention when reachable from VPN users, compromised workstations, or other services. Removing public access is a strong interim measure, but record the internal paths that remain. CERT-EU also recommends considering isolation from public networks where immediate remediation is not feasible.^[8]

The useful operational comparison with Log4Shell is the difficulty of locating embedded dependencies and getting distributor fixes onto every running instance. There is no need to equate the attack mechanisms or observed damage. This article does not establish a worldwide compromise count. IPA's advance notice likewise was not a statement that it had observed exploitation at that time.^[2]

4. On AWS: separate responsibility for PHP from the privileges exposed after compromise

The following is a fictional architecture for discussion, not a description of a particular company.

Internet → CloudFront / AWS WAF → ALB → PHP-FPM / mod_php
                                           ├─ DB credentials → RDS
                                           └─ Runtime role → S3 and other services

Guest operating systems and applications on EC2 fall within the customer's management responsibilities. Protection of cloud infrastructure does not replace patching the PHP runtime you deploy.^[9]

• EC2 and Auto Scaling: update running instances and the AMI, launch template, and bootstrap process. Verify that scaling out cannot restore the old runtime.
• Containers on ECS or EKS: rebuild the image containing PHP and deploy an identified digest. Updating packages on the EC2 host does not update a container's contents. Include services, Jobs, CronJobs, and standby deployments.
• Fargate: reduced infrastructure administration does not remove the need to update PHP in the application image. Task isolation does not guarantee protection of data inside the compromised task.
• Elastic Beanstalk and hosted products: check the provider's fixed platform or product version and apply it to the environment. A separately installed PHP runtime may require separate action.
• Lambda custom runtimes and containers: if PHP is bundled, inspect its provider, layer, and image. Do not assume identical attack conditions across all Lambda functions without checking the execution model.

RCE need not provide root privileges to cause serious business damage. Configuration, environment variables, and database credentials readable by the PHP worker may become accessible after compromise. Permissions assigned to the application may also permit access to S3 or other AWS resources. This is a general post-RCE threat model, not a claim that those outcomes have been observed in this incident.

On ECS, distinguish the application's task role from the task execution role used for activities such as pulling images. Scope the former to required APIs and resources. For EC2-backed containers, inspect access boundaries around neighboring tasks and instance metadata. AWS explicitly states that containers are not security boundaries, while Fargate provides a task-level isolation boundary.^[10]

Requiring IMDSv2 is valuable, but it is not a universal barrier against an attacker who can already execute code on the host. IMDSv2 issues a token for subsequent metadata requests. The threat-model inference here is that code with the necessary reachability and permissions may perform that operation too. Combine it with blocking unused metadata paths, least privilege, database permission separation, and egress restrictions.^[11]

5. Defense while updating: restrict entry first and document configuration tradeoffs

The service owner and security team should decide whether to remain online using data sensitivity, outage impact, and the expected repair path. Where a critical service cannot obtain a fix or sufficiently restrict access, this article recommends switching to a static notice that does not invoke PHP. An application-level maintenance page may be too late: PHP can parse the request before reaching that page.

IP allowlists, VPN access, and authentication at an upstream proxy narrow the set of parties reaching PHP. Restricting CloudFront alone leaves a gap if an ALB address or alternative hostname remains directly reachable. Check origin paths, IPv6, alternative ports, and forgotten environments.

Protecting an entrance requires closing bypasses as well. Compare the architecture diagram with the paths that actually reach the application.

An AWS WAF inspection limit is not a request rejection limit

AWS WAF can inspect a fixed 8 KB of a request body on ALB. For CloudFront, the default is 16 KB and the maximum is 64 KB. Content outside the inspection window is not automatically discarded before reaching PHP. When the request is allowed, it is forwarded in full.^[12][13]

Oversize handling offers Continue, Match, and No match. To reject oversized requests, review the rule action, oversize behavior, earlier Allow rules, and exceptions together. For example, Match with a Block action rejects an oversized component, but may also block legitimate uploads. Identify affected routes and validate business impact with real requests. This is not a complete PHP2Shell-specific protection rule.

PHP's interim advice is not a one-setting fix

Current official guidance includes the following. Read the latest linked advisories when implementing it, and apply changes to and restart every worker.^[1][4][5]

• OOM paths: administratively enforcing memory_limit=-1 reduces the known path relying on PHP's finite limit, but underlying allocation failures remain possible. Removing the PHP limit increases availability risk. Do not deploy it without input limits, monitoring, and appropriate container or cgroup boundaries. Substituting RLIMIT_AS or RLIMIT_DATA can itself cause the vulnerable allocation failure.
• Session paths: set session.upload_progress.enabled=0 in server configuration effective before request parsing. Application ini_set() and FPM .user.ini are too late. This addresses confirmed session paths, not every variant.
• PHP 8.5: fatal_error_backtraces=0 reduces the confirmed backtrace path, without repairing all paths.
• Inputs and diagnostics: restrict bodies, multipart requests, headers, and nesting at the frontend, and repair invalid per-request configuration. Merely hiding errors does not prevent the problem.

Do not rely exclusively on a small post_max_size; account for differences between declared lengths and the data actually decoded. Block multipart requests upstream if they are unnecessary, after checking whether API clients or integrations use them implicitly. If restrictions break a business function, create a narrowly scoped alternative with defined users, routes, and duration rather than opening an unlimited exception.

6. If old PHP cannot be upgraded: prefer a maintained distributor fix

The hard part of legacy remediation is often the evidence that behavior remains correct, rather than the number of changed lines. Old frameworks, removed APIs, extensions, database drivers, implicit conversions, and edge cases in reports or batch processing make migration difficult. Avoid forcing emergency remediation and broad technical-debt reduction into the same release.

First choice: fixed packages from the distribution or maintenance provider already in use. Backporting applies a newer fix to an older branch and can address a particular flaw while preserving compatibility. Confirm the CVEs, architecture, extensions, distribution channel, and scope of the support agreement.^[14]

For this incident, Ubuntu's USN-8948-1 lists 8.1.2-1ubuntu2.28 as a fixed PHP 8.1 package for Ubuntu 22.04 LTS. This is a concrete example of a distributor supplying a fix after normal upstream support for 8.1 has ended. Do not apply that version to another OS, or classify it as unpatched by checking only the leading 8.1.2.^[15]

Second choice: a trustworthy extended-maintenance service. A contract alone is insufficient evidence. Ask whether both CVEs are covered, when the update is available, how artifacts are signed, what has been tested, and who owns subsequent remediation. A maintenance agreement is not an unconditional promise of every possible future fix.

Third choice: a controlled source backport. PHP has also linked minimal source backports for PHP 7.4, 8.0, and 8.1. This does not restart normal support for those branches. Consuming a maintained vendor package and assuming responsibility for building, testing, and distributing a source patch are different operational commitments.^[1]

A backport repairs a problem while preserving an existing structure. Compatibility at the joins and verification of the result determine its quality.

The following are this article's proposed minimum conditions for maintaining your own fix:

1. Cause and scope: identify applicable paths in the target version and map official commits, follow-up fixes, and tests. Blocking one reproduction is not sufficient.
2. Reproducible builds: retain source, patches, compiler, configuration, extensions, dependencies, and artifact hashes. Ensure distributed artifacts can be verified through your controlled distribution process.
3. Two kinds of testing: separate security regression tests that fail before the fix and pass afterward in isolation from compatibility tests protecting business inputs and outputs. Exercise the production SAPI, OPcache, extensions, and concurrent requests.
4. Ownership and deadline: assign reviewers, responsibility for the next CVE, the owner accepting continued exposure, and a deadline for leaving the old branch.

If these conditions cannot be met, isolation, disabling affected functions, or an alternative business process is preferable to exposing an improvised build. Even a successful custom patch does not establish the safety of the entire unsupported runtime. Keep emergency-fix completion and migration completion in separate tickets.

7. Finish deployment: verify every running instance, not just updated files

Installing a package and running the fixed service are distinct milestones. These are examples of inspection commands to adapt to the environment, not a bulk-upgrade script.

# Information about this CLI invocation; record separately from web evidence
php -v
php --ini

# Debian / Ubuntu: complete installed package versions
# Compare against the distributor advisory covering these CVEs
dpkg-query -W 'php*' 'libapache2-mod-php*'

# RPM-based example
rpm -qa 'php*'

For web execution, use existing administrative diagnostics or a temporary restricted endpoint to obtain the actual PHP_VERSION, PHP_SAPI, loaded configuration, and build identity. Do not leave a public phpinfo() page behind. For distribution packages, the package revision is needed in addition to the web runtime's version string.

A recommended deployment sequence is:

1. Define scope: inventory production, administrative interfaces, alternative domains, batch jobs, and standby systems. Shut down unused environments.
2. Validate the replacement: record vendor guidance, signatures, and image digests. Test service-critical flows such as login, payments, persistence, uploads, sessions, and asynchronous processing.
3. Roll out incrementally: begin with a canary or a subset of instances and watch error rates, latency, memory, and worker restarts. Base acceptable thresholds on the service's normal behavior.
4. Replace running processes: appropriately restart or replace FPM and Apache, checking that old workers are gone. A resident process can retain old code even after files have changed.
5. Test recreation: verify that newly launched instances and tasks are fixed too. Maintain a patched rollback target. If returning to an unpatched target is unavoidable, close public access first.
6. Keep evidence: per asset, record the complete version, distributor, digest, verification time, verifier, and remaining exceptions with deadlines.

If indicators of compromise emerge during the update, move from ordinary patching to incident response. Preserve logs and necessary evidence; isolate, investigate, and rebuild from clean artifacts. Revoke or rotate secrets and invalidate sessions according to the assessed scope. An update does not undo stolen information or remove already-installed malicious code.

Wiz identifies unusual multipart requests, memory-limit errors, repeated HTTP 500 responses, abnormal session cookies, and unexplained worker churn as investigative leads. None alone proves an attack. Some paths run before application logging, so correlate frontend access logs with OS, container, and CloudTrail records.^[6]

CloudTrail does not record arbitrary code execution inside PHP itself. Use it for the AWS API activity actually being logged, and check whether needed events, including relevant S3 data events, were enabled beforehand. The absence of an alert is not equivalent to evidence that no compromise occurred.^[17]

8. How AI helped find the bugs: test hypotheses and generalize failure patterns

AI involvement has been publicly documented. Wiz reports using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol and that Wiz independently discovered and reported the vulnerabilities. This was not a claim that a single AI autonomously performed all the work.^[6][16]

A revealing part of Calif's technical account is how the researcher used PHP's vulnerability history to ask where interruption could become dangerous. The model traced source code and examined the ordering of publishing state, performing fallible work, and completing initialization. The team then generalized the discovered structure into a SKILL.md and searched other locations for the pattern.^[7]

The valuable step is testing a hypothesis and using the reason it failed to narrow the next search, rather than accumulating plausible warnings.

For defenders, this suggests the following loop. It is a generalized operational proposal informed by the published research:

• Read: connect inputs, memory ownership, initialization, cleanup, and paths skipped by errors. Do not classify risk from a function name alone.
• Form a hypothesis: specify who consumes incomplete state if an operation fails halfway through.
• Test in isolation: use an authorized local environment, a minimal reproduction, a debugger, sanitizers, and tests to compare the claim with actual failures.
• Search for relatives: investigate the same ownership and lifetime pattern in other versions and extensions.
• Challenge the fix: after the original reproduction stops failing, test neighboring variants and normal behavior. Assign a reviewer the task of trying to disprove completeness.

AI can assist broad code exploration and repeated experimentation. Suspicious source, a crash, information disclosure, and RCE are nevertheless different milestones. Keep evidence for each instead of jumping to the final outcome because a model's explanation sounds convincing. A research success does not establish a universal percentage reduction in investigation time or cost.

For legacy maintenance, divide AI-assisted work by deliverable: advisory synthesis, old-version comparison, build definitions, regression-test proposals, and deployment-inventory reconciliation. Each task should retain source versions, reasoning, and unresolved questions so the next operator can recover context. People review the evidence and decide whether to adopt a patch, manipulate secrets, or switch production traffic.

9. Prepare for the next emergency: response speed depends on information kept beforehand

When the next runtime issue appears, reduce the chance that the response begins by asking how many installations exist. Five practices help:

Assets and dependencies. Connect services to their SAPI, OS packages, image digests, SBOMs, owners, and support deadlines. An SBOM alone cannot show which old images are still publicly exposed. Reconcile it with running inventory.

A route to fixes. Define upstream and distributor subscriptions, emergency contacts, extended-maintenance scope, and signature-verification procedures. When a CVE arrives, incorporate vendor fix status rather than relying exclusively on upstream version comparisons.

A way to stop. Prepare a PHP-independent notice, access restrictions, emergency administrative access, and alternative business processes. Every exception permitting continued operation needs an owner, reason, residual risk, deadline, and reassessment trigger.

A way to recover and verify. Exercise tests for critical business flows, patched rollback targets, secret rotation, and backup restoration. Include a test that recreating the workload cannot silently bring back an unpatched runtime.

Measurements. Track time from notification to asset identification, identification to exposure restriction, and fix availability to verification of the entire running fleet. Count unresolved exceptions as well as machines receiving a package.

A minimum completion condition is that the affected assets are known, fixed artifacts are running across scope, recreation preserves the fix, and exceptions have deadlines. Suspected compromises require their own investigation and recovery. Turn the emergency update into an operational record that can be reused next time.

Update history and items to revisit

• October 22, 2026, first edition (checked October 21 at 23:55 JST): incorporates official fixed releases, SAPI conditions, interim measures, legacy backports, Ubuntu's package example, AWS operations, and AI-assisted discovery.
• Next checks: corrections and follow-up fixes in PHP advisories; OS, hosting, and image-distributor updates; credible public-agency and research observations of exploitation; WAF-provider coverage and bypass conditions; changes to legacy source backports.
• Unresolved at this checkpoint: worldwide compromise scale, exploitability of individual customer environments, and fix availability across every distribution channel including Amazon Linux. This article does not classify all such channels as either unavailable or safe.

This article is a technical explanation based on public sources, using generalized architectures. It is not a report of reproducing attacks or measuring defenses in individual production environments. Reconcile current provider guidance with your own validation before making changes.