Amazon says attempts to exploit the critical PHP flaws began October 17, four days before patches and public disclosure.
Sophos has corrected an initial report of a successful breach, saying its investigation found scanning and failed attack attempts.
PHP issued additional guidance October 23, recommending a temporary configuration change for an unusual attack path while developers prepare another fix.
The response to the critical PHP vulnerabilities uncovered by Wiz Research and other security researchers has entered a new phase, with attackers probing vulnerable systems and developers issuing additional protection advice.
Amazon Threat Intelligence says its monitoring network detected an exploitation attempt on October 17 — four days before PHP released emergency security updates. The activity targeted MadPot, Amazon’s network of decoy systems used to observe attackers. Amazon said it remains unclear how the suspected attacker obtained information about the vulnerabilities before disclosure.
Additional attempts followed early October 21, before the patches became public. Differences in the attack traffic suggest multiple actors were involved. Amazon cautioned that it could not determine whether those attempts would have succeeded against real-world systems.
The biggest threats
The two flaws, collectively called PHP2Shell, can allow attackers to execute code on affected servers without logging in. PHP is the underlying technology supporting many websites and applications, including WordPress-based sites.
Cisco Talos says most activity it has observed consists of scanning and scattered attempts to deliver malicious payloads. It expects attacks to become more sophisticated as capable groups adapt their tools.
One significant development is a correction from Sophos. The security company initially reported successful exploitation in a customer environment, but withdrew that assessment October 22 after further analysis.
Most attacks have failed
Sophos now says its observations show scanning and a small number of failed exploitation attempts, with no evidence of a successful compromise in the activity it investigated. One blocked attempt sought to deliver Potassium, a likely Mirai botnet variant capable of launching attacks that overwhelm online services with traffic.
That does not mean exploitation is impossible. VulnCheck says it developed an exploit that works against several PHP 8.4 releases with a common memory-security protection enabled and PHP’s recommended production error-display setting. Its findings demonstrate that important technical barriers can be overcome.
PHP also issued new advice on October 23 about an additional, unlikely route to remote code execution, tracked as CVE-2026-115560.
Developers recommend setting session.upload_progress.enabled=0 until the next regular bugfix release. The issue requires an unusual combination of application code and configuration involving changes to how session data is handled. Applications that never change their session serialization handler at runtime can leave the feature enabled, PHP says.
Amazon recommends that investigations look back at least to October 17 and check for unexpected file changes or programs running on web servers. Applying a patch closes vulnerabilities; operators also need to investigate whether attackers reached their systems beforehand.
Risk to consumers
A vulnerable website can put visitors at risk if attackers successfully compromise it. Simply visiting a site running unpatched PHP does not automatically infect your device or expose your information.
The main potential risks are:
Stolen information: Attackers could access information held by the website, potentially including account details, personal records, or information submitted through forms.
Compromised accounts: Exposed passwords or session tokens could allow attackers to impersonate users.
Altered pages: Attackers who gain control could potentially insert fake login forms, redirect visitors to scams, or add malicious downloads.
These are possible consequences of a server compromise, not evidence that a particular site has been attacked.
Consumers generally cannot tell whether a website’s underlying PHP software has been patched. A padlock or HTTPS connection does not establish that the website itself is secure.
For now, avoid entering sensitive information on a site that has announced it remains vulnerable or is investigating a compromise. Use unique passwords and multifactor authentication, keep your browser updated, and heed browser security warnings. If a site reports a breach, follow its instructions and change any affected or reused passwords.