If One PHP Flaw Can Put 70% Of Websites At Risk, What Does That Say About The State Of Global Cybersecurity?

A critical vulnerability in PHP, a programming language used by around 70% of websites, has raised fresh questions about the security of the internet’s underlying infrastructure. Dubbed PHP2Shell, the flaws could allow attackers to execute code remotely or access sensitive information, putting vulnerable systems at serious risk.

According to The Guardian, organisations have taken websites and services offline while they assess their exposure. Patches were released on 21 October, but the incident highlights a far bigger concern and challenge. That is, how can businesses protect themselves when all it takes is just one weakness in widely used software to have such far-reaching consequences?

 

Why One Vulnerability Can Have Such A Wide Impact

 

PHP is a foundational part of the web, supporting websites and applications across industries. That widespread use means a vulnerability can affect organisations that have little in common beyond the technology they rely on. Ran Geva, CEO of Webz.io, told us that “PHP2Shell showcases the risk potential of shared software. Software vulnerabilities remain the same, regardless of the number of instances.”

The problem here is that businesses may not know where vulnerable software is running, particularly across older websites, third-party services and systems managed by external providers. Tim Williams, CEO at Quod Orbis, explained: “We are seeing the consequences across government services, banking and retail, where disruption can prevent organisations from taking or making payments and delivering the services customers rely on.”

The incident demonstrates that cybersecurity isn’t just about protecting a company’s own applications, but also about understanding the software and suppliers on which those applications depend.

 

 

Is AI Making Cybersecurity Harder To Manage?

 

AI has added another layer of complexity to cyberseucurity issues. Researchers are increasingly using AI tools to identify vulnerabilities, potentially uncovering weaknesses that might otherwise have remained hidden. But, once a flaw becomes known, attackers can also use automation to accelerate their response, and that’s the main problem.

The Guardian reported that Amazon detected an attempted exploitation of the vulnerability against a honeypot on 17 October, several days before public disclosure. According to Viktor Bulanek, founder of Penetrify, “The worrying part is not the bug itself, it is the timeline. Amazon saw the first exploitation attempt days before disclosure, and the embargo leaked before patches existed. Defenders were behind before anyone told them there was a race.”

For defenders, the shrinking window between discovering a vulnerability and seeing it exploited makes rapid patching and continuous monitoring increasingly important, but still increedibly difficult (if not more so). Mitchell Spicer, co-founder and COO of Revelion AI, argues that many businesses are still not keeping pace with the speed of change. According to Spicer, “The problem is that many businesses still test their security once a year, while the systems they rely on are changing all the time,” he says. So, how on earth can companies protect themselves when things are constantly changing in unpredictable ways?

 

The Problem With Software Nobody Maintains

 

The PHP incident also exposes the risks of technical debt. That is, older websites and applications may continue running on unsupported software long after their original developers have moved on. Niall Pritchard, founder of Secure Select, explains that “For a small business, the website is often a PHP-based platform like WordPress that someone set up years ago and nobody has touched since.”

This creates a significant visibility problem. After all, businesses can’t patch systems that they don’t even know exist, and updating a content management system doesn’t necessarily update the underlying PHP runtime. Suzy Pallett, president of Black Hat, warns us that the risk can persist long after the initial disclosure. For that reason, businesses should verify that legacy systems and third-party platforms have also been patched, rather than just assuming the issue is resolved.

 

So, What Should Businesses Do Now?

 

The immediate priority in this situation is to identify the affected systems, install the appropriate security updates and then check whether any compromise occurred before patching. Businesses that are running older, unsupported PHP versions may need to upgrade or temporarily isolate exposed services.

Joe Connolly, lead of content delivery and security at bunny.net, told us that “The dangerous assumption is that an updated website means an updated PHP runtime.” He also said that operators should check the version that’s actually serving each site, patch exposed systems and verify that the fixed version is running.

However, hatching alone isn’t enough if attackers have already gained access. If this is the case, organisations should also investigate suspicious activity, review potentially compromised credentials and monitor systems for signs of continued intrusion.

Matt Cooke, EMEA cybersecurity strategist at Proofpoint, puts the urgency quite plainly when he advisses companies to “Patch fast, know your attack surface and limit the blast radius, because that window is closing.”

PHP2Shell is a reminder that global cybersecurity depends on more than preventing attacks against individual organisations. It also requires maintaining shared infrastructure, understanding hidden dependencies and responding quickly when weaknesses emerge.

But perhaps more than any of those lessons, it also demonstrates to us that as AI accelerates both discovery and exploitation, the organisations that are best placed to withstand the next major vulnerability are most likely going to be those that already know what they’re running and who’s responsible for keeping it secure.

 

Our Experts:

 

• Matt Cooke: EMEA Cybersecurity Strategist at Proofpoint
• Viktor Bulanek: Founder at Penetrify
• Mitchell Spicer: Co-Founder and COO of Revelion AI
• Ran Geva: CEO of Webz.io
• Heath Squier: Founder of EVKII
• Niall Pritchard: Founder of Secure Select
• Gunnar Hellekson: Vice President and General Manager, Lightwell, Red Hat
• Tom Exelby: Head of Cybersecurity at Red Helix
• Spencer Starkey: Executive Vice President EMEA at SonicWall
• Perry Hughes: Deputy Managing Director at Solve
• Raghu Nandakumara: VP of Industry Strategy at Illumio
• Dor Tumarkin and oao Cunha da Silva: Director of Security Research and Security Researcher at Checkmarx
• Joe Connolly: Lead of Content Delivery and Security at bunny.net
• Evgeny Zaretskov: Chief Security Officer at SOFTSWISS
• Suzy Pallett: President of Black Hat
• Tim Williams: CEO at Quod Orbis
• Dimitrios Bougioukas: SVP, IT Security Training Services at Hack The Box
• Jeff Watkins: Chief AI Officer of NorthStar Intelligence
• Ben Large: Head of Cybersecurity at Cybit

 

Matt Cooke, EMEA Cybersecurity Strategist at Proofpoint

 

 

“This is a stake-in-the-ground moment for CISOs around the world. Organisations of every size have a finite window to shore up their cyber defences, because threats now operate at machine speed. Patch fast, know your attack surface and limit the blast radius, because that window is closing. If we don’t act now, we will see more organisations forced to take their sites offline while they scramble to fix what should have been secured long ago.”

 

Viktor Bulanek, Founder at Penetrify 

 

 

“The worrying part is not the bug itself, it is the timeline. Amazon saw the first exploitation attempt days before disclosure, and the embargo leaked before patches existed. Defenders were behind before anyone told them there was a race. That is now normal, and AI makes it faster, because turning a patch into a working exploit takes hours rather than weeks.

“The second problem is old debt. There are no fixes for PHP 5 or 7, yet plenty of businesses still run them on a forgotten marketing site or an old customer portal. Few small companies could tell you which PHP version runs where.

“So, practically: list every internet-facing system running PHP today, patch the 8.x ones now, and take PHP 5 and 7 offline or behind a firewall. If you were exposed since mid-October, check for web shells before you assume you are fine.”

 

Mitchell Spicer, Co-Founder and COO of Revelion AI 

 

 

“The PHP flaws highlight a problem that goes beyond one programming language. The internet relies on software used by millions of websites, and when a weakness is found in something so widely deployed, the window to fix it can be very short.

“AI is helping researchers find vulnerabilities that might otherwise have taken much longer to uncover. That is useful, but once a flaw becomes public, attackers can move quickly too. The problem is that many businesses still test their security once a year, while the systems they rely on are changing all the time.

“The immediate priority is to patch affected systems and check whether attackers got in before the fixes were applied. Longer term, businesses need to know what is running across their environments and test their security more regularly. Finding a weakness is only the first step. You need to know whether it can be exploited, fix it and verify that the fix works.”

 

Ran Geva, CEO of Webz.io

 

 

“PHP2Shell showcases the risk potential of shared software. Software vulnerabilities remain the same, regardless of the number of instances. Typically, the defender has to identify exposed systems first, and the software vendor has to define the threat surface. In the meantime, the attacker has ample time to exploit the vulnerability.

“Businesses should locate every affected application, patch the underlying PHP software, and confirm that hosting providers have done the same. Isolate services that cannot be updated promptly. Web application firewalls can reduce exposure while patches are applied.

“The response must also look backwards. Check for signs of compromise, including activity before public disclosure. If a server was compromised, investigate whether credentials or API keys were stolen and revoke affected access. Patching closes the vulnerability; it does not remove an attacker’s existing foothold or invalidate credentials they have already taken.”

 

Heath Squier, Founder of EVKII

 

 

“The PHP flaws show why a website is an ongoing operating responsibility, not a finished marketing asset. A business needs to know which applications depend on PHP, who maintains each runtime and who can authorize urgent changes. An update announced by a supplier is not the same as an update installed and checked on your server.

“PHP has now released fixed versions, so the immediate job is to confirm remediation with the host, including any vendor backport, and verify the application still works. For an online store, that means checking the customer journey and checkout, not just loading the homepage. Longer term, make a named maintenance owner, a supported software inventory and a tested recovery path part of the website budget. Attractive pages cannot compensate for an unowned dependency.”

 

Niall Pritchard, Founder of Secure Select

 

 

“Flaws like this show how much of the internet rests on shared building blocks that most website owners never think about. For a small business, the website is often a PHP-based platform such as WordPress that someone set up years ago and nobody has touched since. Attackers do not need to pick you out: they scan the whole internet for vulnerable versions within hours of a disclosure.

“The lesson is unglamorous but it works. Know what your site actually runs on, make sure a named person is responsible for applying security updates quickly, keep a tested backup somewhere separate, and put a web application firewall in front of the site. If an agency or host looks after it, ask them in writing who patches what, and how fast. Most small-business breaches start with something that was fixable and simply was not fixed.”

 

Gunnar Hellekson, Vice President and General Manager, Lightwell, Red Hat

 

 

“Much of the critical software running the world is also the least visible. Stable production code ‘that just works’ is now at risk due to the speed and volume of new vulnerabilities found via AI-driven discovery. The issues facing PHP are a reminder of just how deeply open source is woven into the systems that run global business.

“The ripple effects from vulnerabilities in foundational software like PHP can extend across entire industries. This makes it critical to have a trusted software source that helps manage this risk and, ideally, quickly responds to these new threats as they emerge.

“Given the potential impact of these vulnerabilities, Red Hat recommends that customers deploy validated, tested patches as soon as they are available from trusted sources, even outside of normal patching windows.”

 

Tom Exelby, Head of Cyber Security at Red Helix 

 

 

“Given how much of the internet runs on PHP, and the severity of these vulnerabilities, this is a significant concern. The technical details are now public along with the fixes which means it is only a matter of time before attackers attempt exploitation at scale.

“Organisations should act now: update their own PHP services and confirm that their web hosting and SaaS suppliers have done the same. This will close the vulnerability, but it will not establish whether attackers have already exploited it. Organisations need round-the-clock monitoring to detect and investigate signs of compromise.”

 

Spencer Starkey, Executive Vice President EMEA at SonicWall

 

 

“The worst thing organisations can do is assume they’re safe because they haven’t been hit yet. With these PHP vulnerabilities, the time to act is now. This was bad but it could get a hell of a lot worse.

“Check which PHP version your websites are running and plan your upgrade to 8.4. Patch your plugins and packages, and regularly check for outdated dependencies that could leave the door open to attackers.

“AI is accelerating the discovery and exploitation of vulnerabilities, giving defenders less time to react. You don’t need to panic, but you do need to know where you’re exposed and have a plan to fix it before attackers find it first.”

 

Perry Hughes, Deputy Managing Director at Solve 

 

 

“PHP runs around 70% of the web, so a flaw like this puts a huge share of the internet at risk overnight. With AI making it quicker for attackers to scan for weak spots and automate exploits, the gap between a vulnerability going public and attacks starting is shrinking fast.

“From an SEO point of view, the damage often outlasts the breach. Hacked sites get injected with spam pages and malicious redirects, Google flags them, and rankings that took years to build can vanish in days.

“Many business owners assume WordPress auto-updates have them covered, but this fix happens on the server, so whoever manages your hosting needs to apply it. Anyone still on PHP 8.1 or older needs a full upgrade, not just a patch. A website isn’t a one-off build. It needs regular maintenance, and if nobody’s looking after it, it’s a liability. A proper maintenance plan (like the ones offered at Solve) is the simplest way to make sure patches are applied before attackers come knocking”.

 

Raghu Nandakumara, VP of Industry Strategy at Illumio

 

 

“There’s an important paradox here. We want AI to move quickly enough to find vulnerabilities humans might miss, while also making sure that increasingly autonomous systems operate within boundaries we understand and control. The faster AI becomes at finding weaknesses, the more important it becomes to think about what happens after those weaknesses are exposed, especially when organizations can’t immediately patch every affected system. It’s that speed without control creates a new kind of security problem.”

 

Dan Andrew, Head of Security at Intruder

 

 

“Patches are only available for versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, but all prior versions are affected. So you may not even be able to patch yet, though some Linux distributions and LTS vendors will provide backported fixes.

It’s currently unclear how big the fallout is, and how many third party products use a version of PHP which have no patch available. Those that remain exposed should closely follow PHP’s advise that “only an update is a complete solution”. So any other mitigation steps are in comparison, generally weaker, and still leave the system vulnerable.”

 

Dor Tumarkin and oao Cunha da Silva, Director of Security Research and Security Researcher at Checkmarx

 

 

“Users of PHP, including frameworks that rely on PHP, are at very high risk of pre-auth Remote Code Execution and must update PHP to its latest version.

 

 

“Any version before 8.2 are EOL and no fix is forthcoming – these versions must be migrated to 8.2 or later secure versions.

“The critical vulnerabilities currently rocking the PHP world are an omen of things to come, as both the speed of exploit development and the speed of misinformation has surpassed in speed defenders’ ability to respond to imminent attacks. Always cast doubt published mitigations and exploits until official information is available.”

 

Joe Connolly, Lead of Content Delivery and Security at bunny.net

 

 

“The dangerous assumption is that an updated website means an updated PHP runtime. PHP has demonstrated a mod_php attack can be triggered before the application code runs, so a CMS update alone cannot address it. Operators should check the PHP version actually serving each site, patch every exposed origin and verify the fixed version is running. A WAF can help reduce exposure to known attack patterns during that rollout, but the PHP update closes the underlying flaws.”

 

Evgeny Zaretskov, Chief Security Officer at SOFTSWISS 

 

 

“PHP2Shell is not the first vulnerability to create internet-wide exposure, and like Log4Shell and Heartbleed previously, it once again highlighted that even though a company may have strong application security, it might still be exposed.

“What changed is that the latest automation capabilities and AI-assisted tools now make it much faster to test whether a new vulnerability is exploitable, adapt the approach and continue the attack after initial access. Attackers can move from disclosure to large-scale exploitation much faster than ever before.

“For businesses, patching is only one part of the required response. First, you need to know which internet-facing services are exposed and which of them actually use the vulnerable component. If an immediate patch is not possible, compensating controls such as WAF rules, access restrictions or isolation should reduce the attack surface.

“At SOFTSWISS, we combine perimeter visibility, vulnerability and patch management with 24/7 monitoring. Any period between exposure and remediation also becomes an investigation window. During that window, security teams should check endpoint and network telemetry for unusual process execution, outbound connections, credential access, persistence and attempts to reach other systems.

“It’s important to understand that a patch closes the vulnerability, but it does not remove access an attacker may already have gained. So after remediation, the security team should still review activity during the exposure window and hunt for signs of suspicious post-exploitation behaviour. Otherwise, the original entry point may be fixed while the compromise remains.”

 

Suzy Pallett, President of Black Hat

 

 

“This PHP vulnerability is a reminder of just how much of the modern web still runs on legacy, widely deployed scripting frameworks.

“For businesses, the real risk is not just the initial exploit, it’s the tail. Once a vulnerability like this is public, we typically see a second and third wave of attacks in the following weeks and months. These target organisations that assumed they’d already patched the issue, or didn’t realise legacy systems were still exposed.

“Businesses of all sizes should of course patch any PHP platforms immediately, but they’ll also want to verify all environments, including legacy systems and third-party platforms built on PHP, have been patched.

“Firms shouldn’t assume development teams have knowledge of every instance of their software running globally, they should treat this as a prompt to inventory all PHP-dependent assets, since shadow IT and outdated deployments are often where these flaws linger.

“It’s the real-world business response that determines whether an organisation becomes a case study in resilience or a cautionary tale, and given the severity of this flaw, its paramount businesses don’t fall prey to attacks, as the operational and reputational cost are significant.”

 

Tim Williams, CEO at Quod Orbis

 

 

“Many organisations rely on PHP to run their websites and support critical business functions but may not even be aware that it forms part of their IT infrastructure. What we are seeing play out proves organisations cannot effectively manage the risks they cannot see. Understanding what technologies, assets and controls are in place is the essential first step.

“While the disruption businesses experience when third-party technology or infrastructure fails may not be directly their fault, the impact on their operations is very real. Dependencies on external suppliers can affect an organisation’s ability to deliver essential services, process payments and maintain business continuity. We are seeing the consequences across government services, banking and retail, where disruption can prevent organisations from taking or making payments and delivering the services customers rely on.

“This is why visibility matters. Organisations need to understand not only their own technology estate, but also the dependencies that underpin their operations. Without that visibility, it becomes much harder to assess exposure, anticipate the impact of a third-party failure and respond effectively when disruption occurs.”

 

Dimitrios Bougioukas, SVP, IT Security Training Services at Hack The Box  

 

 

“PHP2Shell highlights a fundamental challenge the global cybersecurity industry is dealing with. Attackers can exploit vulnerabilities before defenders have reliable ways to identify the activity. AI-assisted research is accelerating vulnerability discovery, while attackers can adapt their techniques to evade known detection rules.

“This means organisations cannot rely on patches and indicators of compromise on their own. Behavioural monitoring helps defenders identify suspicious activity, such as a web server process launching unexpected commands or making unusual network connections, without needing to recognise the vulnerability itself. This will buy defenders valuable time when attack signatures are unavailable or changing.

“Detection of course is only part of the answer. Businesses need to understand where they are exposed, apply security updates promptly and regularly test whether security teams can recognise and respond to realistic attacks. As threats evolve, resilience will depend on how effectively security tools are used to detect, investigate and act.”

 

Jeff Watkins, Chief AI Officer of NorthStar Intelligence 

 

 

“PHP2Shell may be one of the most important security vulnerabilities of recent times, similar in breadth of impact to OpenSSL Heartbleed. It affects almost all PHP versions in use today (5.4 onwards), and with an estimated 70% of the web running PHP in some way, that’s a huge potential impact, though not every website running PHP is guaranteed to be affected. Because this is an RCE (Remote Code Execution) vulnerability (and also allows remote memory disclosure), exploitation could result in a total loss of an estate.

“Although the exploit for this vulnerability is relatively new, the vulnerability itself was logged as a memory-safety issue in core PHP two years ago. Because there was no exploit at the time and the fix was complex, it was deprioritised. This raises questions about how we manage vulnerabilities in critical parts of our software stack, and the focus on fixing what’s happening today, rather than looking ahead at the potential future risks.

“Some sources have noted that organisations detected exploits days before security researchers disclosed the vulnerability, which raises uncomfortable questions about the timing. How long has this been exploited for, and was this possibly leaked shortly before the disclosure?

“Now we have to pick up the pieces; the global cybersecurity community seems to be taking this very seriously, with many private and government organisations taking services offline to protect against exploitation. In the UK, 32 government services have reportedly been taken offline to allow remediation.

“This should also make people pause and think about how concentrated the risk is in the open-source projects that underpin much of what we release online. Shared technological dependencies create shared risks, so perhaps organisations should take a greater interest in developing and securing key components of the web.

“Businesses that are exposed and running modern versions of PHP must update immediately. Businesses running older versions of PHP without ongoing security updates will have a bumpier ride. They should isolate or take their services offline until they upgrade to a modern, patched version of PHP.

“Hopefully this will be a reminder to organisations that technical debt grows over time as systems age, and that part of the total cost of ownership should be maintaining and updating your services. If you’re up to date, patches are mostly invisible; if you’re years behind, they can mean breaking changes you’ll need to fix in a hurry. It’s better to absorb the cost of major upgrades when you have the luxury of time, without having to take your live services down.

“In closing, don’t assume you’re too small or unknown to be attacked, as modern attacks are highly automated. Patch or upgrade, and do not operate your service until you have done so. Organisations that have deprioritised technical debt: this was your warning; the next one may be worse.”

 

Ben Large, Head of Cybersecurity at Cybit  

 

 

“The attack reveals exactly how unaware most businesses are of their cybersecurity stance.

“Unfortunately, the moment this vulnerability was exposed, bad actors will have started immediately to build attacks, and the bad news is that those actors need no longer be super-smart techies – with AI they can create a lot of damage with relatively little effort.
Having said that, there is much that can be done to protect against this specific threat and reduce the risk of exposure from similar attack sources.

“Firstly, get your website patched with the PHP fix. Secondly, perform a deep audit of other potential vulnerabilities, perhaps by using specialist penetration testers. Thirdly, consider adding a Web Application Firewall (WAF), such as Cloudflare, to sanitise incoming prompts and other user data before it hits your website.”