Amazon Warns Hackers Tried Exploiting PHP2Shell Bugs Before Disclosure

Amazon has warned that attackers attempted to exploit two critical vulnerabilities in PHP four days before the security flaws were publicly disclosed, raising concerns that vulnerable websites may have been exposed before administrators knew a fix was available. Amazon Threat Intelligence detected the early activity on October 17, 2026, through MadPot, its network of decoy systems used to monitor malicious internet activity. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, were publicly disclosed alongside security fixes on October 21.

The flaws, collectively known as PHP2Shell, could allow unauthenticated attackers to execute code remotely on affected systems. Amazon said it remains unclear how the attacker obtained information about the vulnerabilities before disclosure, and it could not confirm whether the observed attempts would have succeeded against real-world servers. After the fixes became available, security researchers observed a sharp increase in exploitation attempts, making immediate patching and retrospective security checks important for organizations running PHP.

Key Takeaways

• Early exploitation attempts: Amazon detected a PHP2Shell attack attempt on October 17, four days before public disclosure.
• Two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619 affect PHP’s core functionality and carry reported CVSS severity scores of 9.2.
• Remote code execution risk: The flaws could allow attackers to execute code on vulnerable servers without authentication.
• Attacks accelerated after disclosure: Security companies reported a rapid increase in attempts once technical details and patches became public.
• Patches are available: The PHP security team released fixed versions on October 21, 2026.
• Organizations should investigate earlier activity: Amazon recommends examining suspicious activity dating back to at least October 17, not merely from the disclosure date.

What Happened in the PHP2Shell Security Incident?

According to the AWS Security Blog, Amazon’s threat intelligence team identified an exploitation attempt against its MadPot honeypot network on October 17, 2026.

The activity originated from an IP address associated with a commercial anonymization network. Amazon said the circumstances suggested malicious activity, but investigators did not determine how the attacker obtained information about the vulnerabilities while they were still under coordinated disclosure.

The early attempt was significant because security vulnerabilities are usually disclosed through a coordinated process. Researchers report a flaw, affected developers prepare a fix, and the vulnerability becomes public when the patch is ready. The process is intended to give administrators an opportunity to update their systems before attackers can widely exploit the technical details.

PHP2Shell shows why that protection cannot be treated as a guarantee. Attackers may independently discover vulnerabilities, obtain leaked information or gain access to technical details before the planned disclosure date.

Amazon also detected multiple proof-of-concept exploits around the time the vulnerabilities became public. Further attempts arrived from additional anonymized infrastructure, with variations in payloads and infrastructure suggesting that multiple actors were involved.

What Are the PHP2Shell Vulnerabilities?

PHP is a widely used programming language for building websites, web applications and server-side services. It powers many content management systems, online stores, business applications and custom websites.

The PHP2Shell name refers to two vulnerabilities in PHP’s core implementation, identified as CVE-2026-109618 and CVE-2026-109619. Security researchers reported that the flaws could be abused to achieve remote code execution under affected configurations.

Remote code execution is a serious vulnerability because it can allow an attacker to make a target server run commands or code without legitimate access.

Vulnerability	Reported severity	Primary concern
CVE-2026-109618	CVSS 9.2, critical	Potential remote code execution through vulnerable PHP behavior
CVE-2026-109619	CVSS 9.2, critical	A second PHP core flaw that can contribute to remote code execution risk

The vulnerabilities affect PHP core rather than just one optional website plugin. This broadens the potential exposure because organizations may use PHP across multiple applications and environments.

However, the presence of PHP alone does not prove that a particular server has been compromised. Exposure depends on the PHP version, deployment and whether the affected code paths can be reached.

Why the Attacks Before Disclosure Matter

The October 17 detection changes the timeline security teams should use when investigating possible compromise.

If an organization begins reviewing its systems only from October 21, it could overlook suspicious activity that occurred while the vulnerabilities were still under embargo. Amazon therefore recommends starting investigations from at least October 17.

The incident also illustrates the shrinking gap between vulnerability disclosure and active exploitation. Once a patch becomes public, attackers can study the changes to understand what was fixed and attempt to develop an exploit. This process is commonly called patch diffing.

Security teams increasingly need to prepare for exploitation attempts within hours of disclosure, rather than assuming they have several days to update their systems.

Amazon noted that AI-assisted analysis can make it cheaper and faster for more actors to turn technical information into potential exploits. That does not mean every circulating exploit will work, but it increases the need to prioritize critical updates quickly.

PHP2Shell Exploitation Increased After the Fixes Were Released

The early October 17 attempt was followed by additional activity around October 21, when the vulnerabilities and security fixes became public.

Cloudflare reported a rapid increase in PHP2Shell-related requests around disclosure, moving from thousands of attempts before public announcement to much higher volumes afterward. Other security companies also reported widespread scanning and exploitation attempts.

The scale of activity matters because PHP is deployed across a large number of internet-facing systems. Even if many attempts fail, automated scanning can reach vulnerable servers quickly.

Not every exploit circulating online is necessarily functional. Security researchers warned that some proof-of-concept code was unreliable or did not successfully achieve remote code execution. Amazon also said it could not establish whether the attempts observed by its sensors would have succeeded against real-world targets.

Organizations should therefore distinguish between an exploitation attempt, a successful compromise and a confirmed data breach. Each requires a different level of evidence and response.

How Organizations Should Protect Their PHP Servers

The PHP security team has released fixed versions for supported branches, including PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Administrators should confirm the appropriate fixed version for their environment using the official PHP security advisories.

Security teams should prioritize the following actions:

• Update PHP immediately: Upgrade affected installations to a fixed release. Patching is the primary remediation.
• Inventory every PHP deployment: Include public websites, internal applications, containers, development systems and older services that may have been forgotten.
• Review logs from October 17 onward: Look for suspicious requests and unusual behavior around the affected PHP functionality.
• Check for signs of compromise: Investigate unexpected process execution, modified files, unfamiliar accounts or unusual outbound network connections.
• Restrict application privileges: Limit what web server processes can access, execute and communicate with. These controls reduce potential damage but do not replace patching.
• Use temporary mitigations carefully: If immediate updating is impossible, consult the official PHP advisory for version-specific measures and their limitations.
• Treat unverified exploit code cautiously: Avoid running unknown proof-of-concept tools on production systems or developer machines.

Amazon also suggested reviewing requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads as one potential indicator. This should be treated as a clue rather than definitive proof of an attack, and it should be considered alongside other telemetry and the official advisory.

Could PHP2Shell Become a Major Internet Security Incident?

PHP2Shell has characteristics that make it particularly concerning: critical severity, potential remote code execution and a large ecosystem of deployments. The fact that exploitation attempts began before public disclosure adds pressure to identify vulnerable systems and investigate historical activity.

However, comparing it with past large-scale vulnerabilities requires caution. The ultimate impact depends on the number of genuinely exposed systems, the reliability of available exploits, the effectiveness of mitigations and how quickly administrators patch their environments.

For organizations, one of the hardest tasks may be discovering every system that runs PHP. Older applications, unmanaged servers and end-of-life PHP versions can be missed by routine inventory processes. Those systems may be difficult to update and could remain exposed longer than actively maintained services.

The Bigger Picture

The PHP2Shell incident highlights a broader shift in cybersecurity: the public disclosure date is no longer a safe starting point for determining when a vulnerability may have been exploited. Threat actors may act before disclosure, and large-scale scanning can accelerate rapidly once technical information becomes available.

For defenders, the response must combine fast patching with better asset inventories, historical log reviews and monitoring that can detect suspicious behavior even when a specific exploit signature is not yet available. Coordinated disclosure remains important, but organizations also need plans for the possibility that attackers discover or obtain vulnerability details early.

FAQs

1. What is PHP2Shell?

PHP2Shell is the name used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can potentially allow remote code execution on affected systems.

2. When did hackers first try exploiting PHP2Shell?

Amazon Threat Intelligence detected an attempt against its MadPot honeypot network on October 17, 2026, four days before the vulnerabilities were publicly disclosed.

3. Were the early attacks successful?

Amazon said it could not confirm whether the observed attempts would have succeeded against real-world systems. An attempted exploit is not, by itself, proof of a successful compromise.

4. How can website owners protect themselves?

Website owners should upgrade PHP to a fixed version, check the official PHP security advisory, review suspicious activity dating back to October 17 and investigate signs of unauthorized code execution or file changes.

5. Does using WordPress mean a website is vulnerable?

Not automatically. WordPress and other content management systems can run on PHP, but exposure depends on the PHP version and server configuration. Website owners should verify the actual PHP runtime and update it rather than relying only on the CMS version.

Looking Ahead

Security teams should expect further scanning and attempted exploitation as attackers continue examining the PHP2Shell fixes and adapting their techniques. Organizations that have not yet confirmed their PHP versions should make that inventory and patching work an immediate priority, especially for internet-facing applications and unsupported installations.

The larger lesson is that vulnerability management must account for activity before formal disclosure and exploitation immediately after a fix becomes available. For PHP operators, the most effective response combines rapid updating, careful investigation of historical activity and long-term improvements to asset visibility and server access controls.