PHP2Shell: Critical PHP Vulnerabilities Put Websites at Risk of Remote Code Execution
Posted in News, Web App Penetration Testing
PHP2Shell: Why Businesses Need to Take These PHP Vulnerabilities Seriously
A new set of PHP vulnerabilities has created a major security problem for companies running websites and web applications. Called PHP2Shell, these flaws let attackers run code on affected web servers without logging in. Researchers have also shown that attackers can expose sensitive information stored in server memory.
Wiz Research announced these findings on October 21, 2026, identifying two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. These flaws are in PHP, the language behind WordPress, Drupal, and Joomla. With a severity score of 9.2 out of 10, PHP has released security updates to fix the issues.
PHP2Shell isn’t linked to any specific WordPress plugin or website app. The vulnerabilities are in the PHP engine itself. This means updating your content management system or plugins won’t fix the problem if the PHP runtime is still at risk.
A bug in the technology behind your website can cause data leaks, website hacks, service outages, and even let attackers reach other connected systems.
Businesses should check if they use affected PHP versions, apply the right security updates, and verify the vulnerable PHP runtime is no longer running.
What Is PHP2Shell?
PHP is a programming language that allows web servers to create dynamic pages, process forms, interact with databases, manage user sessions, and support other website functions.
Think of a website as a restaurant. The website’s visible pages are the dining room, where customers interact with the business. The application code is the staff and procedures that handle orders. PHP is part of the kitchen infrastructure that processes those requests and helps deliver the result.
If there’s a bug in the application, a developer can fix that feature. But if the problem is in the PHP runtime itself, even a well-designed app stays at risk until the core component is fixed.
This is the main problem with PHP2Shell.
The researchers showed that specially crafted requests could exploit memory-safety flaws in PHP’s handling of certain errors and request-processing operations. Under the right conditions, these flaws can allow an unauthenticated attacker to execute code or disclose sensitive data from PHP worker memory.
They showed exploitation against WordPress, Drupal, and Joomla. These examples illustrate the issue’s potential reach, but the vulnerabilities are in PHP itself, not exclusively in those applications.
A business should not assume it is safe just because it uses a different content management system or a custom-built website.
How Can PHP2Shell Allow an Attacker to Compromise a Website?
The technical details involve how PHP manages memory. Business and IT teams shouldn’t be required to know all the programming details to understand why this matters.
- PHP can mishandle memory after certain errors
When a web server processes a request, PHP allocates and manages memory to hold information needed to complete the work. The PHP engine must also clean up that memory when the request finishes or fails.
The reported vulnerabilities happen when an error, like running out of memory, interrupts normal processing. In some cases, PHP can keep an internal reference to memory that has already been released or no longer has the right information.
Memory-safety flaws can cause a mismatch between what the software thinks is in memory and what is actually there. Attackers may exploit this to leak sensitive data.
- An attacker may be able to exploit the error without logging in
The demonstrated attack methods can work before an attacker logs in to the affected application. This makes the risk especially concerning for vulnerable web servers that are accessible from the internet.
Similarly, a website’s authentication controls may work as intended, but a flaw in the PHP runtime can still give attackers another way to compromise the server.
Not every PHP2Shell attack will succeed. Success depends on the PHP version, server setup, and other factors. Still, the risk is serious enough that businesses should act before an attack happens.
- Successful exploitation can lead to code execution or data exposure
Remote code execution means an attacker can make a vulnerable server run commands or code they control. Depending on the server’s permissions and setup, this could let the attacker change website files, access data, stay on the system, or try to reach other connected systems. systems.
The researchers also demonstrated memory disclosure. Server memory can contain sensitive information, including authentication tokens, passwords, API keys, and other data associated with application processing.
Think of the server as an employee’s desk. Even if an intruder can’t open every filing cabinet, papers left on the desk might reveal information that helps them access other areas.
The exact impact depends on what the compromised PHP process can access. A web server with limited permissions and strong isolation may contain the damage better than one with broad access to databases, credentials, or other internal systems.
That’s why, besides patching PHP, businesses should also review server permissions, stored secrets, monitoring, and any connected systems.
Which Systems Are Affected by PHP2Shell?
Wiz reported that the vulnerabilities affect PHP versions dating back to PHP 5.4, with the disclosed flaws present in the PHP codebase for many years. The researchers demonstrated exploitation against WordPress, Drupal, and Joomla, but the underlying exposure isn’t limited to those platforms.
Businesses should check any internet-facing or internally accessible application that uses PHP, including:
- WordPress websites and online stores. A website may use PHP through WordPress core, themes, plugins, and supporting infrastructure. Updating WordPress alone does not necessarily update the PHP runtime.
- Drupal and Joomla websites. These platforms also rely on PHP, so administrators should verify the runtime version and apply the appropriate PHP security updates.
- Custom web applications. Internally developed applications may be affected even when their own code contains no known vulnerability, because the flaw exists below the application layer.
- E-commerce platforms and business portals. Applications that process orders, customer information, authentication, or payments may create significant business exposure if their underlying PHP runtime is vulnerable.
- Hosted and cloud-based applications. PHP may run on virtual machines, containers, managed hosting, or cloud infrastructure. Businesses need to determine who manages the PHP runtime and who applies updates.
A common mistake is checking only the main production website. Businesses should also check staging environments, development systems, backup instances, older applications, and other servers that might still run vulnerable PHP versions.
Keeping an accurate inventory is crucial. You can’t patch a system if you don’t know it exists.
What Should Businesses Do to Protect Against PHP2Shell?
The PHP project released security updates on October 21, 2026. Businesses should make this a top priority and check the latest guidance from official PHP security announcements.
- Identify every affected PHP installation
Start by identifying which servers and applications use PHP and which runtime versions they are running.
Don’t just rely on the PHP version shown on your public website. Your business might have several PHP installations behind a load balancer, in containers, or on different hosts. The version you see in one place might not match every instance. Work with the IT team, hosting provider, or application vendor to confirm the runtime versions across production and nonproduction systems.
- Install the appropriate security updates
PHP’s published fixed releases for the affected maintained branches include PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Before updating, administrators should confirm the correct supported release for their environment using the official PHP website and the applicable security advisory.
Older PHP versions may require special attention because fixes and support status can differ. If a system runs an unsupported version, businesses should focus on an upgrade path rather than assume changing application code will eliminate the underlying flaw.
Be sure to patch every affected instance, not just the main web server. After updating, check that PHP processes have restarted and are using the fixed version. Sometimes, a server has the new files, but old processes are still running the outdated code.
- Use temporary protections only as a bridge to patching
Some businesses cannot update immediately because of application compatibility, vendor dependencies, or operational constraints. In those cases, temporary protections may reduce exposure while the company plans a permanent fix.
Depending on the environment, possible measures include web application firewall rules, restricting unnecessary access to exposed services, isolating vulnerable servers, and increasing monitoring for suspicious requests or unusual PHP worker behavior.
These steps have limits. A web application firewall acts like a security guard at the door. It can block some suspicious activity, but it won’t fix a broken lock inside. Attack methods can change, and no rule covers every possible exploit.
Temporary fixes don’t replace installing the PHP security update. Follow vendor advice and make sure any control you use fits your setup.
- Investigate signs of possible exploitation
Patching fixes the vulnerability, but it doesn’t tell you if someone already exploited the server before you applied the update.
Security and IT teams should review available web server, PHP, endpoint, and network logs for unusual activity. Depending on the environment, useful investigative signals may include unexpected PHP errors, unusual request patterns, unexplained process creation, unexpected file changes, suspicious outbound connections, or unusual access to sensitive application data.
Wiz also described indicators that may assist investigation, including unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, and unexpected PHP session-cookie behavior. These indicators are clues, not definitive proof of exploitation.
Since the vulnerability is in the PHP runtime, application logs might not show the whole story. Businesses should check other logs and bring in incident-response experts if they find signs of a breach.
If an attacker may have accessed server memory or executed code, consider whether application credentials, API keys, database passwords, session tokens, and other secrets require rotation. The response should account for the affected PHP process’s permissions and the systems it could reach.
- Verify remediation
After patching, make sure every affected system runs the fixed version and has the right settings. Only remove temporary fixes when it’s safe and matches your remediation plan.
Businesses should also review whether the incident exposed other weaknesses, such as excessive server permissions, unprotected credentials, unnecessary network access, or insufficient monitoring.
Remember, fixing the original vulnerability lowers immediate risk, but it doesn’t remove every threat that may have come from a past compromise.
Why PHP2Shell Matters Beyond WordPress Security
PHP2Shell shows that web application security is about more than just what you see in the app itself.
A business might use secure development, keep plugins updated, choose a trusted host, and set up a web application firewall. These are good steps, but they can’t fully protect against a major flaw in the PHP runtime.
Imagine a house with strong doors, an alarm system, and well-secured windows. If the main access-control system has a critical defect, the homeowner still has a security problem that needs attention.
The same idea applies to web apps. Security relies on the app, its libraries and runtime, server setup, identity controls, network boundaries, and monitoring all working together.
PHP2Shell also shows why businesses need a solid process for managing vulnerabilities. It’s not just about scanning systems or getting alerts. Leaders need to know if the company can find affected assets, prioritize risks, fix issues, and check results quickly.
Read more about a previous blog post that explores the broader challenge in How Long Can Your Company Afford to Leave a Critical Vulnerability Unpatched?.
What PHP2Shell Reveals About AI and Vulnerability Research
The PHP2Shell disclosure also highlights a broader development in cybersecurity: AI is helping researchers analyze complex software and develop working demonstrations of vulnerabilities that may have been difficult to exploit previously.
According to Wiz, advanced AI models played a meaningful role in identifying the flaws and helping researchers develop and validate exploit techniques. The vulnerabilities had existed in the codebase for years, but demonstrating practical exploitation required chaining several complex memory-management issues together.
This matters because finding a software flaw and actually creating a working exploit are two different challenges.
Think of a building inspector identifying a structural weakness. Knowing the weakness exists is valuable, but determining exactly how it could cause a collapse requires additional analysis. AI can help accelerate parts of that analysis, reducing the time and effort needed to move from discovery to practical exploitation.
This same capability can help defenders by letting researchers find and fix flaws before attackers use them. But it also shows why companies should not assume that a complicated vulnerability will always be hard to exploit.
I previously wrote a post that discussed this changing environment in AI Is Finding Vulnerabilities Faster Than Companies Can Patch Them.
The main point is not that AI makes every vulnerability immediately exploitable. It’s that businesses should not use complexity or the lack of known attacks as a reason to delay fixing a critical flaw.
How Penetration Testing Helps Reduce Web Application Risk
Patching known vulnerabilities is essential, but it is only one part of a mature web application security program.
A vulnerability assessment can help identify known weaknesses, outdated software, exposed services, and configuration issues. A penetration test goes further by validating whether weaknesses can be exploited and what an attacker could accomplish within an agreed scope.
For example, a test may reveal that a vulnerable web server can access a database, sensitive files, or credentials that allow further access. That information helps a business understand the potential consequences of a compromise and prioritize improvements beyond the initial patch.
But penetration testing is not a replacement for patching. When a critical security update is released, the right move is to find affected systems and fix the vulnerability, not wait for the next scheduled test.
Tanner Security provides Web Application Penetration Testing to help businesses identify and validate security weaknesses in web applications. For a broader view of network-level exposure, Tanner also offers Network Vulnerability Assessments.
These services help businesses assess their security, find weaknesses that need fixing, and ensure security controls work as intended.
What Business Leaders Should Take Away From PHP2Shell
PHP2Shell is a strong reminder that a website can still be at risk even if its application code seems secure. Since the flaws are in the PHP runtime, businesses must look beyond plugins and content management systems when checking for exposure.
Right now, top priorities include finding affected PHP installations, applying the right security updates, ensuring patched runtimes are running, and reviewing any suspicious activity if needed.
Business leaders should also ask a few practical questions: Do we know which systems run PHP? Who is responsible for patching the runtime? How quickly can we respond to a critical vulnerability? And how do we verify that the risk has actually been reduced?
These questions matter for more than just PHP2Shell. They show whether a business can turn security information into real action.
Related Tanner Security Services and Resources
Web Application Penetration Testing — Identify and validate security weaknesses in websites and web applications.
Network Vulnerability Assessments — Identify known vulnerabilities, outdated software, and configuration weaknesses across network-connected systems.
How Long Can Your Company Afford to Leave a Critical Vulnerability Unpatched? — Understand why timely, risk-based remediation matters when critical vulnerabilities become public.
AI Is Finding Vulnerabilities Faster Than Companies Can Patch Them — Explore how AI is changing vulnerability discovery and increasing pressure on security teams to remediate weaknesses quickly.
External Penetration Test vs. Vulnerability Assessment — Learn how vulnerability assessments and penetration tests answer different security questions.
Protect Your Website Beyond the Application Layer
PHP2Shell shows why website security takes more than updating plugins or checking application code. The underlying runtime, server setup, access permissions, and connected systems all add to the overall risk.
Businesses should confirm whether they run affected PHP versions, apply the appropriate security updates, verify remediation, and investigate potential compromise where warranted.
If your business relies on websites or web applications to serve customers, process transactions, or support daily operations, Tanner Security can help you evaluate your security controls and identify areas that need attention.
Contact Tanner Security to discuss web application penetration testing and vulnerability assessment services.
Schedule a Call
