What Should Startups Know About Critical PHP Vulnerabilities And Their Business Risks?

PHP2Shell sounds like something a villain would name their laptop, but it’s the label attached to two vulnerabilities in PHP, the programming language doing the behind-the-scenes work on a huge number of websites. It can sit underneath a WordPress site, an online booking system or a customer portal without anyone on a startup’s team having thought about it since the day it was installed.

Because the flaws live in PHP itself rather than in a company’s own code, tidying up the website doesn’t make them go away. The first steps are finding out whether PHP is being used, who’s responsible for updating it and how to check that the fix is actually working

 

PHP Is Probably Hiding Somewhere In Your Business

 

Simon Hughes, Chief Commercial Officer at Cowbell, thinks small businesses are starting from the wrong question. “For most UK small businesses, the first question isn’t ‘have we patched PHP?’ It’s ‘do we use PHP?’ Many won’t know. It sits underneath the WordPress site, the online booking system and the customer portal a web agency built years ago.” Anyone with a website built by an agency that has since changed its name, its staff or its entire business model will recognise the feeling.

J. Paul Haynes, CEO at Cinchy, reckons the odds are not in a founder’s favour. “Startups and small businesses should take particular notice as there are better odds than not that there is PHP somewhere in their technology stack.” Having found it, the natural instinct is to update the website, which turns out not to reach far enough.

Mudita Khurana, Staff Security Engineer at Airbnb, explains why. “These two PHP vulnerabilities are pretty dangerous for startups because they exist in the PHP runtime itself. Which means that updating WordPress, Laravel or the company’s own application doesn’t fix an outdated PHP installation.” It’s a bit like redecorating a rented flat when the faulty boiler is the landlord’s responsibility; the hosting provider is often the landlord here, as Khurana points out. “A startup may own the application but its hosting provider may control the PHP runtime.”

 

 

What Could These Flaws Actually Do To A Startup?

 

Khurana is direct about the downside. “If these vulnerabilities get exploited they will allow an attacker to run code without logging in and potentially reach customer data.” That’s about as welcome as a guest who lets themselves in and starts rearranging the kitchen.

Eugene Teplitsky, CTO and Chairman of WishKnish Corp, says this is why the runtime deserves attention. “PHP2Shell is a reminder that the most dangerous bugs often live in the runtime, not in anyone’s application code.” He adds that both flaws come down to memory. “One in how PHP behaves when it runs out, the other in memory from one request being reused by the next after it’s been freed.” Because the flaws sit in PHP itself, reviewing a website’s application code alone won’t fix the underlying vulnerability. The team needs to check the PHP runtime as well.

Zach Lewis, Chief Information Officer at University of Health Sciences and Pharmacy in St. Louis, says the quietness makes it worse. “For startups and small businesses, the biggest concern with these PHP vulnerabilities is how easily they can go unnoticed. A lot of smaller companies rely on websites, applications and third-party tools that were built years ago. They work fine, so nobody thinks much about what’s happening behind the scenes.”

A vulnerability is not the same as a break-in, and Kara Sprague, CEO of HackerOne, offers some perspective. “Not all remote code execution vulnerabilities carry the same risk in every environment.” The potential impact depends on the affected system and its exposure, so businesses need to establish which installations are vulnerable instead of assuming every website faces exactly the same risk.

 

Getting Your PHP Security Update in Place

 

The checklist starts with the least technical task of the lot, which is asking someone. Lewis puts it like this: “Know which systems you’re running, make sure PHP and related software are supported and updated and ask your hosting provider or development team what they’re doing to address the latest vulnerabilities. Don’t assume someone else is handling it.”

Eylam Milner, Co-Founder and CTO at Echo, describes the stumbling block. “The problem for most companies is they don’t know where they’re running PHP.” That makes a quick question to the host a better use of a morning than a guess. A yes is a good start, although a patched package that nobody has restarted can still leave vulnerable processes running.

Milner explains why. “Teams need to redeploy affected workloads and restart Apache, PHP-FPM and any other long-running PHP workers, otherwise existing processes may continue running vulnerable code.” His tip for anyone relying on a provider is to get confirmation that the fix is live. “If a hosting provider manages PHP for you, ask them to confirm it’s done. The clock stops when the fix is running in production.”

Once that’s confirmed, the next step is to identify every internet-facing PHP service and check the version running in production. The PHP project released fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older PHP branches need separate attention, as some no longer receive updates from the PHP project. Ask the hosting provider or software vendor which patched version or security update applies to your installation.

Then confirm that the fix is live, rebuild affected images where necessary, restart the relevant workers and review server logs for suspicious activity. If there are signs of compromise, the team may need to investigate further and rotate credentials or secrets that could have been exposed.

 

Fixing It Without Breaking Everything Else

 

Roman Martynenko, Founding Full-Stack Engineer at Henry AI, knows the squeeze a small team faces when an upgrade might upset a plugin nobody has tested it against. “Patch fast and risk breaking a customer-facing service, or patch carefully and stay exposed for longer. Larger firms can stage, test and roll back with a team on call. A founder often has one engineer doing all three.”

His way through is a short routine. “Keep an inventory of public-facing systems, prioritise anything that handles logins or payments, take backups before upgrading and use staged releases with a rollback plan. Boring hygiene beats panic.” It may not make for a thrilling stand-up, but it’s the sort of routine that keeps a Friday afternoon free.

Where possible, test the update before deploying it to production and make sure there’s a rollback plan if something breaks. The exact process depends on how the application is hosted, so startups should ask their technical team or provider what needs to be updated, restarted or redeployed.

Switching a system off until it can be secured is another option, but it comes with its own small print. Hughes has a warning about it. “Businesses that switch off as a precaution, and the brokers advising them, should check now how their cyber policy treats a voluntary shutdown and what waiting period applies, rather than finding out at claim stage.”

The UK’s National Cyber Security Centre (NCSC) advises organisations to consider taking affected systems offline if they can’t apply an update or effective temporary mitigations quickly enough, until the systems can be fully secured. That’s a serious precaution, not an automatic instruction to shut down every website running PHP. Businesses should seek technical advice on the options available and weigh the operational consequences of taking a service offline.

 

An Update Can’t Tell You What Happened Before It Arrived

 

Teplitsky puts the limit of a patch clearly. “Patching closes the hole, but it doesn’t tell you what happened while it was open.” The patch closes these known vulnerabilities, but it can’t tell you whether anyone accessed the system before the fix was installed.

Hughes agrees, with a UK twist. “Patching isn’t a ‘silver bullet’ either. These flaws can expose data quietly, so businesses should check for signs of compromise and change passwords on affected systems. A personal data breach may need reporting to the ICO within 72 hours.”

That deadline applies to personal data breaches that meet the legal reporting threshold. Where a breach is reportable, the organisation must notify the Information Commissioner’s Office (ICO) without undue delay and, where feasible, within 72 hours of becoming aware of it.

Even larger companies miss things, according to Sprague. “Large enterprises may have overlooked PHP installations that remain vulnerable after the first round of remediation.” If firms with whole security departments are finding stray installations, a startup that turns one up under the stairs shouldn’t feel singled out; it should just make sure someone is named as the person who hears first about the next one.

Sprague also warns against treating the first round of updates as the finish line. Checking for PHP installations that were missed during the initial response should remain part of the process, especially when a business relies on multiple providers or services.

 

Know Who To Ring Before The Next Patch Notice Arrives

 

None of this asks a founder to become a security engineer overnight; it asks for a name next to the words “looks after our website”, a version number written down somewhere other than someone’s memory and a rough idea of how an urgent update would reach the team.

PHP2Shell will be old news soon, but the questions it raised will still be waiting when the next flaw turns up with its own nickname. The aim is to make sure someone knows what’s running behind the website and who needs to deal with it, before another security notice lands in the inbox.

 

Our Experts:

 

• Simon Hughes: Chief Commercial Officer at Cowbell
• Kara Sprague: CEO of HackerOne
• Eylam Milner: Co-Founder and CTO at Echo
• Roman Martynenko: Founding Full-Stack Engineer at Henry AI
• Mudita Khurana: Staff Security Engineer at Airbnb
• Eugene Teplitsky: CTO and Chairman of WishKnish Corp
• J. Paul Haynes: CEO at Cinchy
• Zach Lewis: Chief Information Officer at University of Health Sciences and Pharmacy in St. Louis

 

Simon Hughes, Chief Commercial Officer at Cowbell

 

 

“For most UK small businesses, the first question isn’t ‘have we patched PHP?’ It’s ‘do we use PHP?’ Many won’t know. It sits underneath the WordPress site, the online booking system and the customer portal a web agency built years ago. So today’s first call should be to whoever hosts your website: are we running PHP, has it been updated, and if not, when?”

“The NCSC has advised organisations that can’t patch to consider taking systems offline. That’s sound advice, but it has a commercial cost. Businesses that switch off as a precaution, and the brokers advising them, should check now how their cyber policy treats a voluntary shutdown and what waiting period applies, rather than finding out at claim stage.”

“Patching isn’t a ‘silver bullet’ either. These flaws can expose data quietly, so businesses should check for signs of compromise and change passwords on affected systems. A personal data breach may need reporting to the ICO within 72 hours.”

“AI helped find these flaws, and attackers have access to the same tools. The gap between a fix being published and being exploited is now measured in hours, not weeks. That’s why continuous monitoring of a business’s exposure matters more than a once-a-year questionnaire.”

 

Kara Sprague, CEO of HackerOne

 

 

“Finding vulnerabilities before adversaries do is only an advantage if we can coordinate and deploy fixes quickly enough to stay ahead. The PHP discoveries are also a reminder that open-source security is everyone’s responsibility. Software that supports millions of websites cannot depend on a handful of maintainers to manage increasingly sophisticated threats alone.”

“Strengthen your vulnerability disclosure process. Closely monitor incoming reports and use automation to deduplicate, validate, and prioritise findings based on asset criticality and demonstrated impact. Not all remote code execution vulnerabilities carry the same risk in every environment.”

“Use researcher findings to inform patching priorities. Apply patches as quickly as possible, but when resources are constrained, externally reported vulnerabilities specific to your environment can help identify the most urgent exposures.”

“Look beyond the initial patching window. Large enterprises may have overlooked PHP installations that remain vulnerable after the first round of remediation. Once initial patching is complete, consider incentivising researchers through existing bug bounty programs to identify remaining exposures.”

 

Eylam Milner, Co-Founder and CTO at Echo

 

 

“Something nobody was worried about yesterday became an emergency overnight. Companies can’t assume the clock starts when a vulnerability appears in the database they monitor.”

“The problem for most companies is they don’t know where they’re running PHP. It’s in base images and in components that bundle their own runtime, and a lot of it is on versions older than 8.2 that are past end of life.”

“We rebuilt our production base image with the patched PHP runtime and verified the fix the day it was released. But rebuilding an image is only the start.”

“Teams need to redeploy affected workloads and restart Apache, PHP-FPM and any other long-running PHP workers, otherwise existing processes may continue running vulnerable code. Then check the patched runtime is actually serving traffic.”

“If a hosting provider manages PHP for you, ask them to confirm it’s done. The clock stops when the fix is running in production.”

 

Roman Martynenko, Founding Full-Stack Engineer at Henry AI

 

 

“For a startup, the hard part is rarely the patch itself. It is everything around it. A small team often has no dedicated security engineer, no complete inventory of where PHP still runs, and no spare capacity to test an upgrade against production data and third-party plugins before shipping it.”

“That creates a bad choice. Patch fast and risk breaking a customer-facing service, or patch carefully and stay exposed for longer. Larger firms can stage, test and roll back with a team on call. A founder often has one engineer doing all three.”

“The practical response is simple. Keep an inventory of public-facing systems, prioritise anything that handles logins or payments, take backups before upgrading, and use staged releases with a rollback plan. Boring hygiene beats panic.”

 

Mudita Khurana, Staff Security Engineer at Airbnb

 

 

“These two PHP vulnerabilities are pretty dangerous for startups because they exist in the PHP runtime itself. Which means that updating WordPress, Laravel or the company’s own application doesn’t fix an outdated PHP installation. If these vulnerabilities get exploited they will allow an attacker to run code without logging in & potentially reach customer data.”

“The biggest problem for small companies is ownership of the underlying server where the vulnerability exists. A startup may own the application but its hosting provider may control the PHP runtime.”

“And so the founders should identify every internet facing PHP service, confirm the version of PHP that is running on it & update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12.”

“They should then rebuild affected images, restart every PHP worker & review server logs for suspicious requests. If compromise is suspected, incident cleanup processes should be followed and any secrets/credentials that were available to that infected server should also be rotated.”

 

Eugene Teplitsky, CTO and Chairman of WishKnish Corp

 

 

“PHP2Shell is a reminder that the most dangerous bugs often live in the runtime, not in anyone’s application code. Both flaws come down to memory: one in how PHP behaves when it runs out, the other in memory from one request being reused by the next after it’s been freed.”

“The Knish.IO validator built into every Securaion appliance is written in memory-safe Rust, which is designed to rule out exactly this class of error. That’s an architectural choice, not a patch.”

“For anyone running PHP today, though, the first step is simple: update now.”

“Patching closes the hole, but it doesn’t tell you what happened while it was open. Attackers were probing these flaws days before disclosure, and anyone who gets code execution can rewrite the logs on the machine they’ve compromised.”

“Securaion keeps the evidence somewhere they can’t reach. Software bills of materials flag vulnerable components for everyone downstream. Exploit and fix events are signed the moment they happen. And post-quantum-signed hashes of critical files mean both the damage and the recovery can be proven, not just claimed.”

 

J. Paul Haynes, CEO at Cinchy

 

 

“Start ups and small businesses should take particular notice as there are better odds than not that there is PHP somewhere in their technology stack.”

“With AI being the newest threat surface it’s still relatively immature in monitoring and security controls.”

“If I were a threat actor I would look to utilize any available AI infrastructure to exploit these newly revealed PHP vulnerabilities. They could mount attacks on your business or launch AI attacks on other targets.”

“Both scenarios are bad and suggest an emerging requirement for AI estate monitoring at the company level versus any specific tool.”

 

Zach Lewis, Chief Information Officer at University of Health Sciences and Pharmacy in St. Louis

 

 

“For startups and small businesses, the biggest concern with these PHP vulnerabilities is how easily they can go unnoticed. A lot of smaller companies rely on websites, applications and third-party tools that were built years ago. They work fine, so nobody thinks much about what’s happening behind the scenes.”

“The challenge is that most startups don’t have a dedicated security team watching for vulnerabilities or managing updates. They’re focused on customers, growth and keeping the business running. Unfortunately, attackers know that.”

“My advice is to start with the basics. Know which systems you’re running, make sure PHP and related software are supported and updated, and ask your hosting provider or development team what they’re doing to address the latest vulnerabilities. Don’t assume someone else is handling it.”

“A security incident can be expensive for any company. For a startup, it can threaten the entire business.”