Researchers uncovered two critical PHP2Shell flaws that let hackers run malicious code on servers. Fixes were released on October 21, 2026. Amruta Moktali said, "Initial industry reports cited millions of potentially exposed instances." Businesses must check their PHP versions and install updates to keep sensitive data safe from these attacks.
PHP, a programming language used to build websites, is at the centre of a major security concern after researchers uncovered two critical flaws that could let hackers take control of vulnerable servers.
Called PHP2Shell, the vulnerabilities could let attackers run malicious code on affected systems without needing to log in. Since the vulnerabilities lie in PHP itself rather than individual websites built on it, businesses cannot rely on website-level security measures alone to stay protected.
The vulnerabilities affect specific PHP versions, and fixes were released on October 21, 2026. Businesses must now check whether they are running affected versions, install the updates and investigate whether hackers exploited the flaws before the fixes were applied.
The discovery story involves both independent research and AI-assisted security work. Security firm Calif credited pseudonymous researcher LCFR with first discovering PHP2Shell and developing a working exploit. Separately, AI company OpenAI said security research firm Calif identified a critical flaw using its GPT-5.6 Sol model, while cybersecurity firm Wiz independently discovered and reported both vulnerabilities. OpenAI's disclosure describes the collaboration that helped prepare fixes before public disclosure.
The episode also highlights a growing cybersecurity concern: AI tools are helping researchers uncover complex security flaws, but organisations must be equally agile to fix them.
Which Businesses Face The Risk?
PHP powers around 70% of websites globally. This highlights the language's reach, but does not mean that 70% of websites are vulnerable. The actual risk depends on the PHP version, server configuration and exposure to attack. The vulnerabilities can allow attackers to run code remotely on affected servers without authentication.
Amruta Moktali, chief product officer at Skyflow, a data privacy and security platform, said initial industry reports cited millions of potentially exposed instances because PHP is widely used across websites, content management systems, hosting environments and enterprise applications.
For Indian businesses, Moktali said the immediate priority should be internet-facing PHP systems that handle sensitive information. These include systems connected to payment services, customer databases and identity and authentication tools.
Small businesses and website operators may face additional challenges if they depend on third-party hosting providers or lack dedicated security teams. They may not know which PHP version their websites use or whether their provider has installed the relevant updates.
Sooraj Sathyanarayanan, a cybersecurity researcher and program manager at privacy-focused web browser Brave, said successful exploitation could allow attackers to execute code without logging in or requiring user interaction. Depending on the server's permissions, this could expose customer data and credentials, enable website changes or allow malware to be installed.
However, the level of risk depends on the PHP build and server configuration, so not all installations are equally vulnerable.
Legacy systems are another concern, as the flaw occurs within PHP's core engine before an application's own code runs.
"One thing organisations must keep in mind with PHP2Shell is that because this flaw triggers inside the core PHP engine before any application code executes, traditional application-level safeguards won't stop it," said Niv Lanyado, security research team lead for PHP at JFrog, a software supply chain security company.
He stressed that organisations need visibility into all their systems, particularly older PHP installations that may no longer receive security updates, so they can be patched or isolated.
Fixing The Software Is Not Enough
The PHP team released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21. Its official security advisory says there are no complete mitigations and urges users to update.
Organisations should first identify where PHP is running across their servers, cloud environments and third-party hosting arrangements. They should then check which installations are affected and confirm that the updated software is active.
According to Aditya Narayana K, the cofounder of cybersecurity company Mirror Security, organisations need a repeatable process to identify vulnerabilities, fix them and verify that the fixes work. He pointed to the NIST Cybersecurity Framework 2.0 as a useful guide for managing this process.
"Organisations must confirm that patches are active and the vulnerability is no longer reproducible, rather than assuming that applying a patch resolves the risk," Narayana said.
Where immediate patching is not possible, businesses should follow official guidance from PHP and their hosting or software providers. Temporary measures may reduce exposure, but they are not a substitute for a complete fix. Unsupported installations may need to be upgraded or isolated until they can be secured.
The incident has also raised questions about whether businesses can keep pace with AI-assisted vulnerability discovery.
Sriram Krishnan, a technology investor and former general partner at venture capital firm Andreessen Horowitz (a16z), wrote on X that the PHP disclosure will make the ecosystem safer by finding long-lurking issues. "However, the entire software supply chain will need the muscles to rapidly build and deploy fixes. We might need a lot more public + private partnerships to secure infrastructure across the country."
How Can Businesses Check For A Breach?
Patching closes a known vulnerability, but it does not establish whether hackers exploited it before the update was installed. Businesses must investigate their past exposure alongside fixing their systems.
According to Narayana of Mirror Security, investigators should identify which systems were exposed and review activity from before patching. This includes checking server logs, unusual system behaviour, unauthorised file changes and suspicious network connections.
Organisations should also look for unexpected programs running on their servers or unexplained changes to files and configurations. Security teams can use monitoring tools to bring together information from different systems and identify patterns that may indicate an attack.
Sathyanarayanan recommended reviewing activity from at least a week before the October 21 patch release, given that exploitation attempts were reported before public disclosure. Businesses should not assume that installing a fix eliminates the risk of an earlier compromise.
If investigators find signs of an attack, they should preserve logs and other evidence, involve their hosting provider or an incident response specialist, and assess whether credentials need to be replaced. Patching alone may not remove malicious software or unauthorised access established before the fix.
An attempted attack does not necessarily mean hackers gained access. Equally, the absence of security alerts does not guarantee that a system is safe.
Timely patching must go hand in hand with continuous security monitoring, as attackers can move quickly once vulnerability details become public. The PHP2Shell disclosure demonstrates why cybersecurity cannot end with a software update. Businesses need to know what technology they run, fix vulnerabilities quickly and establish whether attackers gained access before the fix was applied.
As AI tools make it easier to uncover complex flaws, the ability to investigate, patch and verify systems quickly will become just as important as discovering the vulnerabilities themselves.