You may have seen the alarming headlines: Artificial intelligence helped uncover two critical security vulnerabilities in PHP, the technology behind a huge portion of the web.
The vulnerabilities, now widely called PHP2Shell, could allow an attacker to execute malicious code on a vulnerable server without logging in, potentially giving them control of a website or access to sensitive information.
The PHP project is urging users to update immediately.
For business owners, the most important question isn’t how the vulnerability works. It’s much more practical:
Does this affect our website, who is responsible for fixing it and how do we know it has been handled correctly?
If You Have a Business Website, Do These Six Things Today
We are intentionally not providing command-line patching instructions in this article.
The appropriate update process depends on how your website is hosted, which operating system and web server it uses, how PHP was installed, whether the hosting company manages updates and whether the site relies on older applications that could be affected by a major PHP upgrade. Giving every reader the same set of commands would be misleading and could create additional problems.
This work should be performed by the person or company responsible for maintaining the website’s server environment. The following list is designed to help you identify that person, ask the right questions and verify that the risk has been addressed.
- Find out who actually manages your website’s hosting environment
That may be your:
- Internal IT team
- Managed IT provider
- Website developer
- Marketing agency
- Hosting company
- Cloud services provider
Do not assume the company that designed the website also maintains the server underneath it. Many web agencies manage content and design but do not manage operating systems, PHP versions or server security.
Similarly, your IT provider may support your employees, computers and Microsoft 365 environment without managing your public website.
You need to identify the party responsible for the server where the website runs, not simply the person who can update the site’s content.
- Ask whether any of your systems use PHP
PHP is often operating behind the scenes. A business owner may not think of the company website as a “PHP website,” even though the underlying content management system, e-commerce platform, customer portal or web application depends on it.
The official security advisory covers PHP installations serving web requests and says organizations should identify PHP installations generally rather than limiting their search to old versions.
Ask your website or hosting provider:
Does our public website or any other internet-facing system use PHP? If so, which PHP version is running and has it been updated to a version containing the PHP2Shell security fixes?
Do not ask only about your main website. Your company may also operate landing pages, customer portals, support systems, employee tools, older microsites or web applications that run separately.
- Confirm that the security update has been installed
The PHP project has released repaired versions of the currently supported PHP branches:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older versions no longer receive security updates directly from the PHP project. Some operating system or long-term-support vendors may provide their own patched packages, so the version number alone may not tell the entire story. Your provider should confirm that it installed a package containing the fixes for CVE-2026-109618 and CVE-2026-109619.
If you use a fully managed hosting platform, the provider may already have applied the update. That is encouraging, but “may have” is not good enough for a vulnerability this serious. Ask for confirmation.
- If the system cannot be updated immediately, reduce the exposure
Some organizations may discover that an older website or application cannot be updated quickly without disrupting its functionality. That does not make it safe to leave the system online while someone figures out what to do.
The UK’s National Cyber Security Centre advises organizations that cannot apply the update or temporary mitigations to consider taking the affected system offline until it can be secured.
Taking a website offline can be disruptive. A compromised website or server can be considerably worse.
If the system supports an important business function, your technical provider should explain:
- Why the update cannot be applied
- What temporary mitigation is being used
- How access to the system is being restricted
- When the permanent fix will be completed
- Whether taking the system offline is the safer option
“Updating might break something” is a reason to proceed carefully. It is not a reason to ignore a critical vulnerability.
- Check for evidence that the server was already compromised
Installing the patch closes the vulnerabilities, but it does not remove an attacker who may have gotten in before the update was installed.
If an internet-facing PHP system could not be updated or disabled immediately, the National Cyber Security Centre recommends assessing it for evidence of compromise and looking for backdoors that an attacker may have installed.
Ask the responsible provider whether it reviewed:
- Web server and application logs
- Unexpected administrative accounts
- Recently created or modified files
- Unfamiliar scheduled tasks or processes
- Changes to website code or configuration
- Unusual outbound network activity
- Security alerts generated before the update
The depth of that review should reflect the system’s exposure, the information it processes and the length of time it remained vulnerable.
- Get written confirmation that the work is complete
You do not need a 20-page technical report. You do need a clear answer showing that someone took ownership of the issue.
Here is a message you can send to your website developer, hosting company or IT provider:
Subject: Urgent confirmation requested regarding PHP2Shell
We understand that two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, have been disclosed.
Please confirm:
- Whether our website or any related internet-facing system uses PHP
- Which PHP version and hosting environment each system uses
- Whether the appropriate security update has been installed
- Whether any unsupported PHP versions remain in use
- Whether the systems have been reviewed for evidence of exploitation or compromise
- Whether any additional action is required from us
Please provide written confirmation when this review and any necessary remediation have been completed.
That message gives the responsible party a specific task and creates a record of the response.
Don’t Know Who Manages Your PHP? That Is a Problem Too.
Emergencies like PHP2Shell expose a common weakness, particularly among small and midsize businesses: No one is clearly responsible for the website’s underlying infrastructure and security.
Marketing assumes the web developer handles it. The web developer assumes the hosting company handles it. The hosting company provides the server but expects the customer to maintain the software. The internal IT team thinks everything related to the website belongs to the marketing agency.
Everyone is involved, but no one owns the outcome.
A public-facing website is part of your company’s technology environment. It can collect customer information, connect to databases, process payments, integrate with other systems and affect your company’s reputation. Its maintenance and security responsibilities should be documented.
At a minimum, every organization should know:
- Where its websites and web applications are hosted
- Who maintains the server and software
- Who receives security notifications
- Who is authorized to approve emergency work
- Who verifies that critical updates were completed
- How the organization responds if a website must be taken offline
If you cannot answer those questions today, PHP2Shell is not your only problem. It has simply revealed a gap that was already there.
PHP2Shell Is a Preview of AI-Era Cybersecurity
There’s an important part of this story that shouldn’t get lost: AI didn’t create these vulnerabilities. AI helped defenders discover them.
That is an enormously promising use of artificial intelligence. AI can help security researchers examine vast amounts of code, find weaknesses humans might miss and give defenders an opportunity to fix them.
But those same capabilities can help attackers analyze vulnerabilities and develop exploits more quickly.
That makes AI both an ally and a threat in cybersecurity. The lesson isn’t to fear AI. It’s to recognize that the window between discovering a serious vulnerability and needing to fix it may continue to shrink.
The Bottom Line
If your company operates a website or other internet-facing application, find out today whether it uses PHP and whether the PHP2Shell security update has been applied.
Don’t assume someone else handled it. Ask, verify and make sure someone clearly owns the responsibility.
Then take the larger lesson from this incident: Know who is responsible for maintaining and securing every public-facing system your business operates. The next critical vulnerability won’t arrive on your schedule.
