Update

PHP2Shell Attacks Escalate: Malware Deployed, US Banks Targeted and a Third PHP Flaw Emerges

PHP2Shell has moved from emergency patching to active threat response. Exploitation began before disclosure, malware has been deployed, and a suspected North Korean campaign is prioritising banks, governments and high-value infrastructure.

26 Oct 2026Security Team#Security #DevOps

US Banks Targeted and a Third PHP Flaw Emerges

Four days after PHP released emergency fixes for PHP2Shell, the incident has changed shape. What began as two critical vulnerabilities and a leaked proof of concept is now a live threat with broad scanning, multiple exploitation attempts and at least one successful malware deployment documented by a major security vendor.

At the same time, researchers are tracking a suspected North Korean state-linked operation that explicitly prioritises banks and financial institutions in the United States and other countries. A third related PHP vulnerability has also emerged and does not yet have a full patch.

The important distinction is this: US banks and major technology companies are being scanned, targeted or mobilised in response, but no named American bank or big-tech company has publicly confirmed a PHP2Shell compromise at the time of writing. Targeting is not the same as a breach, and attack traffic is not proof that an exploit succeeded.

What changed since the PHP2Shell disclosure?

PHP disclosed CVE-2026-109618 and CVE-2026-109619 on 21 October and released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both vulnerabilities can lead to unauthenticated remote code execution in the PHP worker process.

Amazon Threat Intelligence found an exploitation attempt dated 17 October, four days before public disclosure.
Cloudflare and Imperva observed rapidly growing, automated attack traffic across many countries and industries.
Sophos documented multiple attempts and one successful exploitation that wrote and executed an apparent Mirai-family payload.
CYFIRMA reported a suspected DPRK state-nexus campaign preparing to target governments, banks, financial institutions and other high-value sectors.
PHP disclosed a third related issue, CVE-2026-115560, and advised administrators to disable session upload progress until a full fix arrives.

Exploitation started before defenders had a patch

Amazon's MadPot honeypot network recorded a PHP2Shell exploitation attempt on 17 October. The request came from commercial anonymisation infrastructure while the vulnerabilities were still under embargo.

Amazon later identified different proofs of concept and additional attempts from multiple sources in the hours before the coordinated release. After the patch became public, attack code appeared within hours and was used against sensors almost immediately.

That timeline matters for incident response. Organisations should not begin their threat hunt on 21 October, when the advisory became public. Logs and endpoint telemetry should be reviewed from at least 17 October 2026.

A successful attack deployed Mirai-family malware

Sophos says its threat hunters identified multiple requests consistent with PHP2Shell and one successful exploitation. The activity wrote a payload to and executed it. Analysis linked the payload to an apparent Mirai variant called Potassium.

Sophos had not observed ransomware, data theft or supply-chain compromise resulting from this activity when it published its update. Nevertheless, the case establishes that PHP2Shell is not merely a laboratory exploit.

Exploit reliability still varies significantly by PHP version, server architecture, memory allocator, configuration and traffic patterns. Apache with remains the highest-risk configuration. PHP-FPM is generally harder to exploit reliably, but it is not considered safe when unpatched.

Are American banks being attacked?

Banks and financial services are clearly in the targeting picture, but public reporting needs careful wording.

Imperva observed financial services among the leading sectors receiving early PHP2Shell traffic. CYFIRMA separately reported that a Korean-speaking threat actor was coordinating reconnaissance and attack planning against vulnerable PHP systems. The reported tasking prioritised national government agencies, banks, financial institutions and online transaction platforms across the United States, Japan, South Korea, India, Singapore, Australia, the UAE, Saudi Arabia and the European Union.

CYFIRMA assesses with high confidence that the campaign intent and activity are real, and with moderate confidence that the operator is linked to the North Korean Lazarus Group ecosystem, also tracked as APT38, Hidden Cobra or ZINC. The suspected objectives include credential theft, cryptocurrency theft, ransomware preparation, espionage and the resale of initial access.

However, no named US bank or credit union has publicly confirmed that PHP2Shell was used to breach it. The evidence currently supports active targeting and reconnaissance—not a claim that American banking systems have been successfully compromised.

What about Amazon, Cloudflare and other big-tech companies?

Major technology providers are deeply involved, but mostly as defenders, telemetry providers and infrastructure operators:

Amazon Web Services detected pre-disclosure activity through its MadPot honeypots and published indicators for investigation. This does not mean AWS itself was breached.
Cloudflare deployed WAF protections across free and paid plans before public disclosure and observed attackers mutating payloads to bypass defences. Cloudflare still advises customers to patch their PHP runtimes.
Google Cloud, Microsoft, Akamai, Fastly, Imperva, Vercel and Automattic participated in preparedness, mitigation or runtime-update efforts around the disclosure.
Technology, hosting and cloud environments are natural targets because a vulnerable shared service or appliance can provide access to many downstream systems.

As of 27 October, we found no public confirmation that Amazon, Google, Microsoft, Cloudflare, Meta or another named global technology company suffered a corporate breach through PHP2Shell. Their reports describe customer-facing attack traffic, vulnerable workloads and defensive response—not confirmed compromise of the companies themselves.

The third issue: CVE-2026-115560

On 23 October, PHP published an informational advisory for CVE-2026-115560, another potential remote-code-execution path involving session upload progress.

The issue requires an unusual combination: an application configured with the or session handler must switch to the handler at runtime before starting the session, while session upload progress remains enabled. PHP considers this scenario unlikely and plans to address it in the next regular bug-fix release.

Until that release is installed, PHP recommends:

session.upload_progress.enabled = 0

Apply the setting administratively so an application cannot override it, and restart every PHP worker. Disabling the feature also blocks a confirmed path associated with CVE-2026-109619, although it does not fully mitigate the original two vulnerabilities.

What defenders should do now

1. Patch every web-serving PHP runtime

Run PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35—or a vendor package that explicitly backports both CVE fixes. Check the runtime used by the web server, not only the command-line binary.

2. Disable session upload progress

Keep in place until PHP ships and you install the next release containing the CVE-2026-115560 fix.

3. Restart and rebuild

Restart Apache, PHP-FPM or LiteSpeed workers after patching. Rebuild container images without relying on a cached vulnerable base layer, then replace running containers and pods.

4. Hunt from 17 October

Review web, WAF, EDR and process telemetry from at least 17 October. Look for unusual multipart POST requests, , PHP memory failures, worker crashes, PHP processes spawning shells, writes into , new PHP files, unexpected scheduled jobs and unexplained outbound connections.

5. Treat evidence of execution as an incident

If a PHP worker executed a command or wrote an unexpected payload, isolate the system, preserve evidence, rebuild it from a trusted image and rotate credentials that may have been present in process memory. That includes database passwords, API keys, session secrets, WordPress salts and Laravel application keys.

The bottom line

PHP2Shell is now an active operational threat, but the public evidence is more precise than some headlines suggest. Successful exploitation has been documented and malware has been deployed. Financial institutions, including those in the United States, are being prioritised by at least one suspected state-linked campaign. Broad automated targeting is occurring across the internet.

What has not been publicly established is a PHP2Shell breach of a named American bank or major technology company.

Patch first, investigate from 17 October, disable session upload progress and keep watching the vendor advisories. The absence of a public victim name is not evidence that unpatched systems are safe.

Need help confirming exposure? Peham's Cloud & DevOps team can inventory your PHP estate, apply and verify patches, rebuild containers and perform a focused compromise assessment.