Your Applications Didn’t Change, So Why Are They Suddenly Vulnerable?
Two critical PHP vulnerabilities expose hidden risks in web applications and services.
Published 27 October 2026
Your website was working perfectly yesterday. Nobody installed a plugin, changed a password or touched a line of code. Yet this morning, your IT team discovers that hackers may be able to take control of the server hosting it.
What happened?
One overlooked vulnerability in server software can put an otherwise well-maintained website at risk.
On 21 October 2026, two critical security vulnerabilities were publicly disclosed in PHP (PHP: Hypertext Preprocessor), a server-side programming language used by millions of websites. According to web technology surveys from independent internet market research service W3Techs, PHP powers 69.3% of all sites whose server-side programming language is known.
Together, the vulnerabilities are known as PHP2Shell, and both carry a severity score of 9.2 out of 10. As you know, this puts them in the “critical” category and essentially means, among other things (covered below), that a hacker can potentially achieve remote code execution (RCE) on affected servers.
The additional uncomfortable part? The weaknesses weren’t introduced by a recent update. They’d been hiding in PHP for years, waiting to be discovered. And that’s a problem for anyone responsible for keeping business systems secure.
When the Problem Isn’t Your Website
Imagine you manage a WordPress website. You’ve kept the plugins updated, removed unused accounts and installed the latest security patches. Your team has done everything it’s supposed to do.
Unfortunately, WordPress relies on PHP to process requests and generate content. So do other widely used platforms, including Drupal and Joomla.
PHP2Shell exploits weaknesses in PHP itself, meaning even websites with securely written application code could be vulnerable. It’s a bit like discovering that the locks on your office doors are perfectly secure, but the manufacturer has announced a defect in the building’s main access-control system.
Even websites with securely written application code could be vulnerable.
Because PHP is so widely used, the potential exposure extends far beyond any individual website or content management system.
Two Vulnerabilities, One Serious Headache
The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, involve how PHP manages computer memory while processing web requests.
Normally, when something goes wrong during a request, PHP should handle the error and clean up the resources it was using. With these vulnerabilities, that cleanup can go wrong.
The first flaw involves PHP running out of memory while internal data is only partially initialized. When PHP attempts to clean up, it may treat corrupted data as valid.
The second flaw involves internal information remaining accessible after the memory supporting it has been released. Under certain conditions, subsequent requests can interact with that stale information.
Both problems can potentially lead to remote code execution (RCE). I don’t have to tell you that For an IT manager, that’s the phrase worth paying attention to. It means an attacker may be able to run unauthorized commands on a vulnerable server. More alarmingly, the demonstrated PHP2Shell attacks don’t necessarily require the attacker to log in first.
Depending on the server’s configuration and the privileges available to PHP, successful exploitation could allow someone to steal sensitive information, modify website files, install malware or gain further access to business systems.
The attacker doesn’t automatically acquire unrestricted control of the network, but compromising an internet-facing server is hardly a small consolation prize.
Below in this article, I cover what your IT department should do.
The Attackers Didn’t Wait for the Announcement
Here’s where the story becomes unsettling (as if it weren’t already unsettling enough).
Amazon’s threat intelligence team reported detecting a PHP2Shell exploitation attempt on 17 October, four days before the vulnerabilities were publicly disclosed. Further attempts appeared on 21 October, involving multiple sources and attack techniques. In its 21 October security report, Amazon described the exploitation activity it had observed.
Sometimes attackers are already at the door before the security team even knows there’s a problem with the lock.
That doesn’t establish how many production servers were successfully compromised. The observations included attacks against Amazon’s threat-monitoring infrastructure. But they demonstrate why organizations can’t assume that a vulnerability only becomes dangerous when its details are published. Sometimes attackers are already at the door before the security team even knows there’s a problem with the lock.
Artificial Intelligence Helped Uncover the Flaws
There’s another intriguing aspect to PHP2Shell. Artificial intelligence played an important role in discovering and investigating vulnerabilities that had escaped detection for years.
Wiz Research used AI models alongside human researchers to identify weaknesses, develop working exploits and assist with remediation. According to Wiz’s technical account, exploiting the vulnerabilities required complicated sequences of operations. AI helped make that process more practical.
Historically, some vulnerabilities were considered impractical to exploit because turning them into reliable attacks demanded specialized expertise and enormous technical effort. AI may be changing that calculation.
Security researchers can use AI to uncover weaknesses and help developers fix them. Unfortunately, attackers may also benefit from AI tools that make complex vulnerability research faster and more accessible.
For IT teams, this raises an uncomfortable question: How many other vulnerabilities have remained relatively obscure simply because nobody knew how to exploit them, or doing so was simply too difficult?
AI is helping security researchers uncover vulnerabilities that once required enormous technical effort to exploit. Attackers may benefit from the same capabilities.
When Patch Management Becomes an IT Project
Fixing a critical PHP vulnerability sounds straightforward. Install the patch. Restart the service. Get on with your day.
If only every IT department had that luxury.
An organization might operate several websites, customer portals and internal applications, each relying on a different PHP installation. Some may use managed hosting. Others run on company servers or inside containers. A legacy application might depend on a PHP version that hasn’t received regular upstream security updates for years.
Effective vulnerability management begins with knowing what's running where. Before administrators can patch anything, they need to establish exactly where PHP is installed.
Patch management becomes more complicated when multiple servers, applications and cloud services depend on different software installations.
Then they must identify vulnerable installations, determine which updates are appropriate and assess whether those updates might affect dependent applications.
For managed service providers (MSPs), multiply that exercise across dozens of customers with different hosting environments.
A simple security update can quickly become a complicated operational project.
What IT Teams Should Do Now
The PHP development team released emergency fixes on 21 October 2026.
The corrected releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older PHP branches require particular attention because they no longer receive regular upstream support, although some vendors provide backported fixes.
The official PHP security advisory recommends updating immediately.
A practical response involves five actions (not an exhaustive list):
- Identify affected installations. Inventory PHP runtimes across websites, applications, servers, containers and managed hosting environments.
- Apply verified security fixes. Install the relevant patched release or a vendor-supported package containing both fixes.
- Restart affected services. Ensure PHP workers are restarted so vulnerable code is no longer running.
- Investigate suspicious activity. Review logs for unusual requests, unexpected commands and unauthorized file modifications.
- Verify application functionality. Test critical business processes after updating, including authentication, uploads and integrations.
Web application firewalls may offer temporary protection against known attacks, but they don’t replace patching.
On 23 October, PHP also issued additional guidance concerning an unusual session upload progress vulnerability. Administrators were advised to temporarily disable session.upload_progress.enabled until the next regular bugfix release.
The Hidden Dependencies That Keep IT Managers Awake
What strikes me about PHP2Shell is how much trouble can originate in software that rarely gets a second thought until something goes wrong.
PHP2Shell exposes a blind spot in web application security: The software underneath an application can be just as important as the application itself.
An application might be fully patched while an underlying runtime remains vulnerable. Similarly, a server migration might successfully move every file while leaving outdated software behind.
These are different risks, but they share an important characteristic: What you can see isn’t necessarily everything you depend on.
That’s particularly relevant during infrastructure changes and data migrations. Moving applications and files provides an opportunity to review dependencies, update unsupported components and verify essential workflows.
What you can see isn’t necessarily everything you depend on.
It also introduces another responsibility: Preserving connections between business-critical files. For example, reorganizing file storage may change paths used by linked Excel workbooks, documents and other dependent files.
Software patching won’t repair those broken file relationships. That’s a separate migration-integrity problem that tools such as LinkFixer Advanced™ are designed to help address.
Yesterday’s Safe System Could Be Today’s Emergency
You can follow established procedures, apply updates and maintain careful security controls, yet still face an urgent threat buried inside familiar technology.
PHP2Shell is a reminder that understanding what's running beneath your applications is just as important as knowing how those applications work.
Sometimes the most dangerous change to your IT environment is one you never made.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment