PHP2Shell Scanning Began Before the Patch. Are You Safe?

October 24, 2026

PHP2Shell scanning began before public fixes. Check affected PHP versions, patched releases, exposure conditions, and what AI did—and did not—prove.

If an internet-facing system runs PHP, identify its effective runtime version and patch source now. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the official fixes for two critical PHP-core flaws called PHP2Shell. Older branches need a vendor backport or an upgrade to a supported release. Temporary mitigations reduce selected attack paths, but the PHP project says updating is the only complete solution.

The urgency is real, but so is the uncertainty. AWS, F5, and other defenders observed requests consistent with PHP2Shell exploitation before or soon after public disclosure. That proves attackers were testing the path quickly. It does not prove that every request succeeded, that every PHP site is equally exploitable, or that a mass wave of confirmed compromises has occurred.

PHP2Shell also has an unusual AI story. Security researchers say frontier models helped turn long-lived memory-safety bugs into working exploit chains. That is evidence that AI can lower the cost of defensive vulnerability research—and a warning that exploit-development timelines may shrink. It is not evidence that a chatbot autonomously attacked the internet or that every AI-assisted security claim is trustworthy.

What Is Confirmed

The PHP project's October 21 security advisory identifies two critical vulnerabilities, both rated CVSS 4.0 9.2:

CVE-2026-109618 involves out-of-memory handling that can interrupt request processing while internal data is only partly initialized. Cleanup can then treat invalid state as valid.
CVE-2026-109619 involves request-owned internal state that can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Both conditions can lead to memory corruption and unauthenticated remote code execution. The PHP team says the exposure includes installations serving web requests through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers the risk highest for mod_php, where researchers demonstrated an attack that can trigger before application code runs.

The official fixed releases are:

PHP 8.5.12;
PHP 8.4.27;
PHP 8.3.36; and
PHP 8.2.35.

PHP 8.1 and older are no longer supported by the PHP project. Some operating-system and long-term-support vendors provide backported fixes, and the PHP security team published minimal source backports for PHP 7.4, 8.0, and 8.1. A matching old version number therefore does not settle the question by itself: you must check the package vendor's advisory and build identifier.

Researchers demonstrated real exploit chains

Wiz Research's technical report says its team demonstrated pre-authentication remote code execution against representative WordPress, Drupal, and Joomla deployments. The vulnerable behavior is in PHP core, not in those content-management systems, so an application does not become safe merely because it is not one of those three products.

Wiz also demonstrated a separate process-memory disclosure path. In its testing, an unauthenticated attacker could retrieve live PHP worker memory that might contain passwords, tokens, API keys, or other data. A possible impact is not proof that a particular server disclosed those items; it describes what a successful exploit can expose when the data is present in reachable process memory.

Scanning and exploit attempts started quickly

F5 Labs says its sensors saw PHP2Shell scanning on October 21 before the official disclosure and patch release. Its report describes exploit-attempt patterns and indicators from the first 24 hours rather than claiming that every request gained code execution.

Amazon Threat Intelligence says its MadPot honeypot network recorded an attempted exploit on October 17—four days before public disclosure. Amazon also observed additional activity after release. Honeypot telemetry is valuable evidence that someone possessed or guessed a relevant technique early, but Amazon cannot use a honeypot request alone to prove that the same request would have succeeded against an arbitrary production server.

That distinction matters. Attempted exploitation is confirmed; widespread successful exploitation is not.

The patch release followed a disclosure leak

PHP initially announced a critical security release for October 21 without technical details. Public discussion leaked enough information to accelerate the timetable and narrow the window defenders expected to have. The official releases still arrived on October 21, but early scanning shows why an embargo or advance notice cannot be treated as a guaranteed quiet period.

OpenAI's Patch the Planet response report says it worked with PHP maintainers, researchers, infrastructure providers, and government partners to test fixes and prepare guidance. The project illustrates the useful side of coordinated AI-assisted research: models can help find variants and test repairs while responsible disclosure gives defenders a chance to act.

Are You Affected?

Do not answer this question from the website footer, the application version, or a package name in a stale inventory. Use the PATCH test.

P — Pin down the runtime that actually serves requests

Inventory every place PHP can execute, including:

production and staging web servers;
PHP-FPM pools behind Nginx or Apache;
Apache deployments using mod_php;
php-cgi, LiteSpeed, and FrankenPHP services;
container images and serverless images with bundled PHP;
scheduled workers and queue consumers that also accept or process untrusted input; and
managed hosting where the provider owns the runtime.

Record the effective binary version and vendor package release inside the running environment. A rebuilt image in a registry does not prove that the old containers stopped. A patched command-line binary does not prove that long-lived FPM or Apache workers use the same build.

A — Assess whether untrusted web requests reach PHP

The PHP advisory treats all PHP installations serving web requests as at risk. Internet exposure raises urgency, but internal services are not automatically safe: reverse proxies, partner networks, compromised internal systems, and request-forwarding features can make an apparently private runtime reachable.

Check whether uploads, large request bodies, session upload progress, error paths, and long-lived worker processes are present. These details affect exploitability and mitigation choices. They do not replace patching.

T — Trace the package source and backport status

For official PHP releases, compare against 8.5.12, 8.4.27, 8.3.36, or 8.2.35. For Linux distribution packages, managed hosts, appliances, or commercial LTS builds, read the vendor's own advisory. Vendors often keep an older upstream version string while applying a security backport.

Ask a managed provider for a specific confirmation: the patched package identifier, deployment time, worker-restart status, and whether all customer tiers received the update. “We monitor security” is not version evidence.

C — Confirm the patched code is running

After deployment:

Rebuild immutable images from a patched base rather than layering an update onto a running container.
Replace old containers and restart every Apache and PHP-FPM worker.
Verify the runtime version from inside the new process or container.
Confirm that load balancers no longer send traffic to old instances.
Recheck autoscaling templates, warm pools, disaster-recovery images, and developer environments.

The restart matters because these bugs involve request and worker state. A package installation without process replacement is not complete operational proof.

H — Hunt from at least October 17

Because Amazon observed an attempt on October 17, use that as a reasonable minimum look-back date unless your own telemetry supports an earlier start. Review:

web and reverse-proxy logs for unusual multipart requests, repeated memory-pressure patterns, and known indicators from trusted vendor reports;
PHP, FPM, Apache, and container logs for out-of-memory failures, worker crashes, restarts, fatal errors, and unexpected session-upload activity;
child processes, outbound connections, new scheduled tasks, web-shell artifacts, altered application files, and unexpected privileged actions; and
secret access and use after suspicious requests, especially database, cloud, deployment, and application credentials available to the PHP worker.

An absence of one published user-agent or payload string is not proof of safety. Attackers can change superficial indicators, and exploitation may leave incomplete application-level traces.

What Should You Do Now?

1. Patch first, then prove the rollout

Move supported installations to the fixed releases or install your vendor's confirmed backport. Prioritize internet-facing systems, then complete the inventory rather than stopping after the most visible website.

If a system is on PHP 8.1 or older, decide whether a trusted vendor backport exists. If it does not, upgrade to a supported branch. A source backport can help specialized operators, but it shifts build, test, and lifecycle responsibility onto your team.

2. Use mitigations only as a temporary bridge

The PHP advisory lists measures that reduce specific paths, including removing a controllable PHP memory-limit failure, limiting decoded request sizes, disabling session upload progress, and addressing attacker-reachable fatal errors. The exact advice differs between the two CVEs and can affect uploads, availability, or application behavior.

The advisory is explicit: there are no complete mitigations other than updating. Do not turn a WAF rule, proxy limit, container cap, or configuration change into a claim that the vulnerability is fixed.

PHP added a follow-up advisory on October 23 for an unusual session-upload-progress configuration. Operators using php_binary or php_serialize and then switching to php at runtime before session_start() should keep session.upload_progress.enabled=0 until the next regular bug-fix release. This edge case is another reason to follow the current PHP advisory instead of relying on a screenshot or summary copied on disclosure day.

3. Preserve evidence before rebuilding suspected hosts

If logs or endpoint telemetry show suspicious activity, isolate the system according to your incident-response plan. Capture volatile evidence when qualified responders can do so safely, identify accessible secrets, and preserve relevant logs before destroying the workload.

Then rebuild from known-clean media and rotate exposed credentials from a separate clean environment. Patching a compromised server closes the original vulnerability; it does not remove a web shell, revoke a stolen token, or reverse an attacker-created account.

4. Ask providers for evidence, not reassurance

For managed WordPress, shared hosting, SaaS, and platform services, customers may not control PHP directly. Ask the provider:

which CVEs and packages its response covers;
whether it patched or applied a temporary mitigation;
when all serving workers were restarted or replaced;
whether it reviewed activity back to October 17; and
what customers must rotate or inspect if suspicious activity is found.

You do not need exploit details to ask for those operational facts.

What AI Actually Did

Wiz says its researchers used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during the investigation. According to Wiz, frontier models helped reason across complex PHP memory behavior, develop and adapt exploit chains, and reduce work that previously would have demanded a larger specialist team.

That is a consequential result, but it needs careful framing.

First, people directed the research, validated the findings, coordinated disclosure, and worked with maintainers. The report does not describe an unsupervised chatbot randomly discovering a production target and attacking it.

Second, the models helped defenders expose bugs that had survived years of scrutiny. The outcome included official patches and coordinated protection. AI capability is not inherently offensive; incentives, access, tooling, and governance shape the result.

Third, the same reduction in research cost can benefit attackers once details leak or a patch reveals the vulnerable code path. Amazon's analysis argues that AI-assisted review can make it cheaper to turn advisories and patch differences into working attempts. PHP2Shell therefore compresses both clocks: defenders can find and fix deeper bugs, while adversaries may move faster after clues appear.

The practical lesson is not “AI found it, so AI is dangerous.” It is that vulnerability programs can no longer assume a technically difficult flaw will remain impractical for long. Patch readiness, asset inventory, restart proof, and look-back hunting must keep pace with faster analysis.

What Is Still Unclear

How many real systems were successfully compromised?

Public telemetry confirms scanning and exploit attempts. It does not establish a reliable count of successful intrusions. CrowdStrike's October 23 assessment says it had not observed successful exploitation in the wild or a fully weaponized exploit capable of broad, reliable compromise.

CrowdStrike notes that exploit developers must adapt memory-corruption chains to particular PHP, application, container, and package layouts. Those constraints are meaningful. They are not a reason to delay the official patch: a difficult exploit can still work against selected targets, and a more portable implementation may appear later.

Did the October 17 request come from the original research?

Amazon says it is unclear how the actor obtained relevant knowledge before disclosure. Possibilities include an independent discovery, leaked information, a similar probe that matched the technique, or access to private details. Public evidence does not settle attribution.

Which older vendor packages are safe?

That depends on the vendor and exact package build. The upstream version alone may understate a backported fix or overstate safety when an old image remains deployed. Consult the operating-system, hosting, appliance, or LTS vendor's current advisory.

Will the fixed releases end every related PHP memory-safety issue?

The released changes address the disclosed vulnerability class and documented variants. No security patch can prove that an entire mature runtime contains no undiscovered bugs. PHP's October 23 follow-up also shows that edge configurations can warrant additional hardening even after the main release.

Where OpenVeil Fits—and Where It Does Not

PHP2Shell is partly an infrastructure-ownership story. Self-hosting an AI gateway, custom chatbot, or internal web application can provide control, but it also makes your team responsible for runtime inventory, patching, reverse proxies, containers, workers, logs, and incident response.

OpenVeil is a hosted AI workspace for adults who want access to multiple AI models without operating that application stack themselves. Normal chat history is stored in the user's browser rather than as a normal server-side chat-history account record, and documented content is not used to train foundation models.

That is a different product boundary, not immunity from infrastructure risk. OpenVeil does not patch PHP websites, scan systems for CVE-2026-109618 or CVE-2026-109619, supply WAF rules, inspect logs, remove malware, rotate credentials, or guarantee that providers and dependencies cannot be compromised. Active requests still require processing by OpenVeil and necessary model providers. OpenVeil is not fully offline, anonymous, zero-log, or a substitute for an incident-response team.

If you are comparing hosted and local AI because of operational responsibility, read Private AI Chat vs. Local AI: Which Is More Private? and What to Check Before Trusting Any AI Privacy Claim. The useful question is not which label sounds safest; it is which risks you can verify and which systems you are prepared to operate.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the informal name for CVE-2026-109618 and CVE-2026-109619, two critical memory-safety flaws in PHP core. Researchers demonstrated paths from unauthenticated web requests to memory disclosure and remote code execution.

Which PHP versions fix PHP2Shell?

The upstream fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Older versions need a confirmed vendor backport or an upgrade. Verify the package build and running worker, not only the version displayed by an application.

Is WordPress itself vulnerable?

The disclosed flaws are in PHP, not WordPress. Wiz used WordPress as one representative environment for a working exploit chain. A WordPress site is affected when its underlying PHP runtime is affected; updating WordPress alone does not patch PHP.

Has PHP2Shell been exploited in the wild?

Defenders have confirmed scanning and exploit attempts, including AWS telemetry from October 17. Public sources disagree on whether successful in-the-wild compromise has been proven at scale. CrowdStrike said on October 23 that it had observed attempts but no successful exploitation. Treat attempts as a reason to patch and hunt, not as proof that every target was breached.

Can a WAF or configuration change fully fix it?

No. Controls can reduce selected paths or buy time, but PHP says updating is the only complete solution. Keep temporary protections in place while validating the patch, and understand their operational limits.

Did AI create PHP2Shell?

The underlying bugs existed in PHP for years. Researchers report that frontier models helped discover, understand, and turn them into working exploit chains. Humans directed and validated the work and coordinated the repair. AI changed the research economics; it did not create the original code defects.

Does using OpenVeil protect my website from PHP2Shell?

No. OpenVeil is an AI workspace, not a web-runtime security product. Patch affected PHP systems, validate the running release, review telemetry, and engage your hosting provider or incident-response team where needed.

Bottom Line

PHP2Shell is serious because the flaws sit in a widely deployed runtime, can be reached before application logic in some configurations, and have demonstrated paths to unauthenticated code execution. The response should still be evidence-led.

Patch to an official fixed release or confirmed vendor backport. Restart or replace every serving worker. Verify the running build. Hunt from at least October 17. Preserve and investigate suspicious evidence. Separate confirmed attempts from confirmed compromises, and do not treat exploit difficulty as a durable security control.

The AI lesson is equally concrete: frontier models can help defenders find deep bugs and test fixes, but they may also shorten the time between disclosure and usable attack attempts. Organizations need faster, verifiable patch operations—not louder claims about either AI salvation or AI doom.

Sources

Research cutoff: October 24, 2026.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.