PHP2Shell Attacks Confirmed: What Website Owners Need to Know

PHP2Shell attacks have moved beyond a theoretical security concern. On October 26, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) announced that it had added two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog. For anyone responsible for a PHP website, that is a clear reason to verify protection now. 1

The immediate question is practical: does the server behind your website have the appropriate PHP security fixes? A working homepage, an updated content management system, or a strong administrator password cannot answer that question by itself.

This guide explains the PHP2Shell vulnerability, what confirmed exploitation means, and the actions website owners should take. Incident information is current as of October 30, 2026. The operational checklists below are recommendations for owners and administrators, rather than claims that every listed behavior has occurred in a PHP2Shell attack.

What Is PHP2Shell?

PHP2Shell is the name used for two serious vulnerabilities in PHP itself. PHP is the server-side runtime that executes application code for many websites. That makes the software underneath the application part of the security picture.

The vulnerabilities can enable unauthenticated remote code execution, commonly shortened to RCE. In plain language, successful exploitation can let an attacker run code on a vulnerable server without first logging into the website. The Canadian Centre for Cyber Security identifies internet-facing PHP systems as a particular concern. 2

Consider the layers involved in a typical website: the hosting environment runs PHP, PHP runs the application, and the application uses themes, plugins, or libraries. Security maintenance needs to cover each relevant layer. Updating a plugin addresses that plugin; it does not establish that the underlying PHP installation has received a runtime fix.

What Does “PHP2Shell Attacks Confirmed” Actually Mean?

CISA’s announcement names both vulnerabilities and places them in its catalog of known exploited flaws. That is stronger evidence than the publication of demonstration code or a report that scanners are sending suspicious traffic. CISA also encourages organizations outside the federal government to prioritize remediation of catalog vulnerabilities. 1

However, the announcement is not a public count of compromised websites. It does not establish that every vulnerable server has been successfully attacked, identify every victim, or show that all server configurations are equally easy to exploit.

Website owners should separate three questions:

• Exposure: Was an affected PHP installation reachable by an attacker?
• Remediation: Does the running service now contain the appropriate fixes?
• Compromise: Is there evidence that an attacker obtained access before protection was applied?

These questions require different evidence. A patch record can support remediation. It cannot, on its own, prove that nothing happened earlier. Equally, finding an outdated version establishes a problem to address, but does not automatically establish a data breach.

How Do the Two PHP Vulnerabilities Differ?

CVE-2026-109618: Memory Corruption During Error Handling

PHP’s advisory describes a problem involving out-of-memory handling. Processing may stop while internal request data is only partly initialized. Cleanup can then operate on invalid data, creating memory corruption that can lead to remote code execution. 3

The key lesson for a nontechnical owner is that a failure inside the runtime can have security consequences. An error is not necessarily limited to a failed page load.

CVE-2026-109619: Stale State Between Requests

The second advisory concerns internal state retained by a worker after the request memory it refers to has been released. A later request can encounter that stale state before normal initialization resets it. PHP describes this as a use-after-free issue with possible remote code execution. 4

Both problems are in runtime behavior. Neither should be reduced to advice about choosing better website passwords or removing a single suspicious plugin.

Which PHP Versions Have PHP2Shell Fixes?

The following releases contain the October 21 fixes for the two original PHP2Shell vulnerabilities. 2

These are incident-specific fixed releases, not a recommendation to remain on those exact builds indefinitely. Follow your provider’s supported update path and check for subsequent security releases.

PHP notes that some operating-system distributors and long-term support vendors supply backported fixes. An administrator using such packages should verify the vendor’s advisory and package revision, rather than judge patch status from the upstream version string alone. 5

For your maintenance record, request three pieces of information: the running PHP version or package revision, the advisory confirming coverage of both CVEs, and the date the update became active. Together, they provide a more useful answer than a general statement that the hosting platform is secure.

Are WordPress and Other PHP Applications at Risk?

PHP identifies web-serving environments including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed as within the risk scope. It considers mod_php the highest-risk setup and describes a demonstrated attack before application code runs. 5

For a WordPress owner, the practical implication is to ask about the PHP runtime as well as WordPress core, themes, and plugins. The same reasoning applies to other applications that rely on a PHP web runtime. This is a dependency exposure question; it does not mean each application has an independent PHP2Shell defect.

Avoid treating a framework name as a complete risk assessment. Ask which server handles public requests, which runtime it uses, and which fixes are active. A developer’s laptop configuration may differ from the production website, and a hosting account may run different PHP versions for different domains.

How to Check Your Website’s PHP2Shell Exposure

1. Identify Every Relevant Website and Service

Create a short inventory before marking the issue resolved. Include the main domain, subdomains, older websites, staging environments, customer portals, and forgotten installations that still accept traffic.

For each entry, record its owner, hosting provider, PHP deployment, public accessibility, and patch status. If a service has no clear owner, assign someone to investigate it. Uncertainty should remain visible until evidence closes it.

This can be a small spreadsheet or an existing maintenance ticket. The purpose is to prevent the main website from receiving attention while another exposed installation is overlooked.

2. Check the Web Runtime, Not Only the Terminal

If you administer your own server, the following command can help identify the command-line PHP installation:

php -v

Treat that output as one check. Ask the administrator to confirm which PHP binary and package actually serve web requests. Hosting panels, separate pools, containers, or multiple installations can complicate the answer.

Use authenticated administrative tools for verification. Avoid leaving a public diagnostic page online merely to display server details. Once verification is complete, retain the relevant evidence in your maintenance record.

3. Ask Your Hosting Provider Specific Questions

For shared or managed hosting, send a concise request:

Please confirm that the PHP runtime serving my domains includes fixes for CVE-2026-109618 and CVE-2026-109619. Please provide the running version or patched package revision, when the change became active, and whether your team found evidence of compromise affecting my account.

This request separates patch confirmation from investigation. A provider may have completed one activity while the other remains open. Keep the response and any remaining action items with the website’s maintenance records.

How to Protect Your Website From PHP2Shell

Apply the Appropriate PHP Security Update

PHP states that updating is the complete solution for the two original vulnerabilities. Configuration measures reduce particular attack paths but do not provide complete protection. 5

Plan the update with whoever operates the environment. For a business website, define a maintenance owner, a rollback approach, and a short validation checklist. If the server is managed by a vendor, use that vendor’s supported process rather than applying unrelated commands found online.

After deployment, test business functions that matter: signing in, submitting forms, uploading permitted files, placing orders, and running scheduled work. A successful homepage load is useful, but it does not test every important application path.

Verify the Fix Is Active Across the Deployment

Ask the operator to confirm that the running workers use the updated software. Where multiple instances or container images serve the website, verify each relevant deployment and update the source image used for future launches.

Record the result as a clear statement: which systems were checked, which fixed packages they run, and which systems still require work. This helps prevent an old deployment from quietly returning during a restart or later release.

Reduce Exposure When Updating Is Delayed

The Canadian advisory recommends considering isolation of internet-facing applications when immediate remediation is not feasible. 2

For an owner, that means discussing temporary access restrictions with the hosting or security team. A maintenance page helps only if the restriction actually prevents public traffic from reaching the vulnerable backend. Agree on the scope, business impact, and condition for safely restoring access.

Avoid accepting an indefinite promise to patch later. Assign an owner and a near-term completion target, with a clear record of the remaining exposure.

What About the Additional PHP Session Upload Progress Issue?

On October 23, PHP published information about CVE-2026-115560, a separate RCE vector requiring an unusual combination of configuration and application behavior. Its notice recommends disabling session upload progress with session.upload_progress.enabled=0 until the next regular bugfix release; applications that never change the serialization handler at runtime are outside that particular vector. 5

Ask your administrator to review that notice separately. Do not describe the two October 21 fixes as resolving every PHP security issue, and do not interpret the additional advisory as proof that all installations remain equally exposed after patching.

How to Investigate Possible PHP Website Compromise

Patching and investigation serve different purposes. An update closes a vulnerability; an investigation asks whether someone already used it.

As general incident-response practice, compare activity with the website’s normal behavior and approved changes. Useful questions include:

• Did files appear or change without a matching deployment?
• Did new administrator accounts or unfamiliar scheduled tasks appear?
• Did a web service launch unexpected programs?
• Did the server make unexplained outbound connections?
• Did unusual errors coincide with suspicious requests or other host activity?

These are investigation leads, not PHP2Shell-specific proof. A crash can have an ordinary cause, and a suspicious filename may turn out to be legitimate. Conversely, a website that looks normal can still warrant investigation when other evidence raises concern.

CISA’s incident-response playbook recommends combining relevant evidence sources and refining the investigation scope as new information appears. That supports examining request activity alongside host behavior, rather than deciding from one isolated log entry. 6

For a small business, the most useful first action may be to ask the provider to preserve relevant records and explain what its investigation covers. Clarify whether it reviewed only your application files or also the underlying hosting environment.

What to Do If You Suspect a Successful Attack

Treat suspected compromise as an incident with a named coordinator. Bring together the hosting provider, application maintainer, and security support needed to assess the situation.

Preserve relevant incident data and document actions taken. NIST’s Cybersecurity Framework emphasizes maintaining the integrity and provenance of incident records and verifying restoration assets before recovery. 7

Practical response planning should address containment, evidence collection, remediation, and recovery. Discuss potentially exposed credentials and tokens with the responders, and plan any replacement from a trusted environment after access paths are addressed. Changing a password while an attacker retains access may leave the underlying problem unresolved.

If rebuilding is necessary, choose a known-good starting point and validate it before returning the service to production. A recent backup should be assessed rather than automatically trusted. Define what successful recovery means for the business, including the functions to test and the monitoring to retain afterward.

Keep communications factual. Distinguish confirmed findings, reasonable concerns, and unanswered questions. Ask the appropriate organizational advisers to assess notification obligations if sensitive information may have been involved.

A PHP2Shell Action Checklist for Website Owners

• Identify all PHP-backed websites and publicly reachable installations.
• Confirm who operates each PHP runtime.
• Obtain evidence that both original CVEs are addressed.
• Verify the fixes are active throughout the running deployment.
• Review the separate session upload progress advisory.
• Preserve relevant records and investigate credible signs of compromise.
• Validate important website functions after maintenance.
• Document unresolved systems, owners, and completion targets.

Use this checklist as a work record. Each completed item should have a short explanation or supporting reference, especially when another company manages the server.

Frequently Asked Questions About PHP2Shell Attacks

Does confirmed exploitation mean my website was hacked?

No. Confirmed exploitation establishes a real threat. Your website’s status still depends on its deployment, exposure, patch history, and available evidence. Assess those facts instead of assuming either compromise or safety.

Will updating WordPress alone fix PHP2Shell?

A WordPress update does not establish that PHP itself has been patched. Ask the hosting provider or server administrator to verify the runtime separately, while continuing normal application maintenance.

Is my website safe because visitors need to log in?

Do not use a login page as patch evidence. The original vulnerabilities concern unauthenticated RCE. Have the operator evaluate the actual public request path and verify the installed fixes.

Can a firewall replace the PHP2Shell patch?

Do not treat a filtering rule as proof of complete remediation. Use it within the provider’s defense plan, and obtain confirmation that the PHP runtime itself has the required fixes.

What if my hosting company says everything is updated?

Request a specific confirmation covering your domains, the two CVE identifiers, and the active patched package. Also ask whether it assessed earlier compromise. Those details turn a reassuring message into a reviewable maintenance record.

Should I stop using PHP?

This incident calls for prompt maintenance and exposure assessment, not an automatic rewrite of every website. Make longer-term platform decisions based on supportability, maintenance resources, business needs, and the ability to deploy security fixes reliably.

Make PHP Security a Routine Responsibility

PHP2Shell shows why website security includes the software beneath the visible application. Assign responsibility for runtime updates, keep a current inventory, and agree with providers on how urgent vulnerability notices will be handled.

For this incident, begin with a concrete result: written confirmation that the active PHP deployment is protected, followed by an evidence-based assessment of any earlier exposure. That gives website owners a defensible basis for deciding what work remains.

Sources

1. CISA, October 26, 2026: CISA Adds Two Known Exploited Vulnerabilities to Catalog.
2. Canadian Centre for Cyber Security, updated October 27, 2026: AL26-026 — Critical vulnerabilities impacting PHP.
3. PHP security advisory: CVE-2026-109618 — RCE via OOM corruption.
4. PHP security advisory: CVE-2026-109619 — RCE via stale global state.
5. PHP official announcements: Critical RCE advisory and session upload progress notice.
6. CISA: Cybersecurity Incident and Vulnerability Response Playbooks.
7. NIST: Cybersecurity Framework implementation examples.