PHP2Shell: Is Your Website Affected and What Should You Ask Your Host?

If you own a website, the useful question about PHP2Shell is: who can confirm that the PHP runtime serving your visitors has been fixed? This guide gives you a way to ask, even when somebody else manages the server. Facts checked on October 30, 2026.

A critical vulnerability is not proof of a data breach

The Canadian Cyber Centre’s October 27 update to alert AL26-026 reports exploitation in the wild of CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. These flaws can allow code execution without signing in.

That makes checking exposure urgent. It does not establish that your particular website was attacked or that its customer data was stolen. Keep those questions separate in conversations with your provider and customers.

Start with the service, not the homepage

List your main website, shop, customer portal and administration tools. For each one, record the person or company responsible for its hosting. Ask whether PHP processes its web requests. An attractive homepage, a working padlock or an up-to-date CMS dashboard does not answer that question.

Ask for a response covering the production service by name. A screenshot from an unrelated server or a command-line PHP installation is not the confirmation you requested. If a supplier manages several environments, request a separate status for production, staging and any publicly accessible administration service.

Which PHP releases contain the initial fixes?

The PHP advisory of October 21 lists these upstream releases for the two initial vulnerabilities:

A distribution may backport a fix into a package with an older base version. Ubuntu’s package advisory illustrates this and explains that applications may need restarting to load updated components. Request the exact vendor package and advisory, plus confirmation that the running service uses it.

There is also a separate follow-up. PHP’s October 23 session-upload advisory covers CVE-2026-115560, which the October 21 releases do not fix. It concerns an unusual combination of configuration and runtime serializer changes. Ask your administrator to assess that notice and its upload-progress mitigation; the table above is not a complete all-clear.

Ask for an answer you can track

• Which named services in my account use PHP, and who maintains each one?
• What installed package or release fixes the two initial CVEs? Which vendor advisory confirms it?
• When did the production service begin using the patched runtime?
• Has the separate October 23 notice been assessed, and what action was necessary?
• If anything remains open, who owns the action and when will you update me?

Keep the ticket number, date and response in your maintenance record. “Security updates are automatic” is a starting point for the conversation; ask for the status of your actual service.

A short message to adapt for your host

Hello, please confirm the PHP2Shell status of [domain/service]. Does its production web runtime have fixes for CVE-2026-109618 and CVE-2026-109619? Please provide the installed package/release, vendor advisory and the date the running service was updated. Please also confirm your assessment of the October 23 notice for CVE-2026-115560. If any action remains, who is responsible and when should we expect the next update? Thank you.

Send this through your existing hosting support portal. For an unexpected “urgent patch” call, use the verification steps in our fake IT support guide before following instructions or sharing access.

What if you suspect a compromise?

Contact your host and incident-response lead promptly. The Cyber Centre’s incident-response guidance separates detection, containment, eradication and recovery. Coordinate evidence preservation and recovery decisions with that team rather than deleting suspicious files first.

Changing a password does not patch PHP. Likewise, installing a patch does not demonstrate that a previous intrusion has been removed. Ask the responder to document both the software remediation and the investigation outcome, including which credentials or sessions need replacement and when. Close your tracking ticket only when the remaining actions have named owners.