What to ask your host or developer after PHP2Shell: a copy-ready email and checklist

The short answer

If someone else runs your server, don’t ask “are we OK?” Ask questions that can only be answered with specifics:

• who manages the PHP that serves your site;
• which build it runs;
• whether that build includes the fixes for CVE-2026-109618 and CVE-2026-109619, and when it was applied;
• whether PHP was restarted afterwards;
• whether PHP’s recommended setting for the related, still-unfixed CVE-2026-115560 is in place (source: php.net release archive; AlmaLinux; php.net advisory on CVE-2026-115560, October 23, 2026).

Then ask about signs of compromise since October 17, staging copies, and the plan for PHP 8.2’s end of life on December 31, 2026 (source: BleepingComputer; php.net supported versions). Ask for the answer in writing, with dates, and keep it. The email below covers all of it.

Who should you ask?

It depends on who manages the PHP runtime, and that isn’t always the company you pay for hosting.

• Shared or managed hosting: your host may have patched PHP. GoDaddy, Hostinger, SiteGround, WP Engine and WordPress.com said they did for customers on their managed plans (host notices, October 21–23, 2026). Ask for written confirmation for your account (source: GoDaddy).
• Your own VPS, cloud server or self-managed control panel: nobody patches PHP for you (source: GoDaddy). Ask whoever runs the server for you: your developer, agency or IT provider. If that’s nobody, the questions below become your own checklist.
• An agency or developer manages it: ask them, even if the hosting account is in your name.

The email

Copy it, fill in the brackets, and send one email per site. Delete question 6 if you know there’s no firewall or CDN in front of the site.

Subject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619): please confirm our PHP status in writing

Hello [name],

Following the PHP security releases of 21 October 2026, please confirm
in writing, with dates, for [your-domain.com]:

1. Is the PHP that serves our site managed by you or by us?
2. Which PHP version and build serves the site (not just the command
   line), and how does it run: PHP-FPM, Apache mod_php or LiteSpeed?
3. Does that build include the fixes for CVE-2026-109618 and
   CVE-2026-109619? If it's a backport, which vendor or package version,
   and when was it applied?
4. Were PHP's worker processes restarted after the update? When?
5. Has session upload progress been turned off at server level (php.ini,
   the PHP-FPM pool or the server configuration) for CVE-2026-115560, as
   PHP recommends?
6. Is there a firewall or CDN rule in front of the site, and can traffic
   reach the server without passing through it?
7. Have you reviewed the server for signs of compromise since
   17 October? Should we rotate passwords or API keys stored on it?
8. Are staging, development and old copies of our site covered too?
9. What is the plan and date to move us to PHP 8.4 or 8.5 before
   PHP 8.2 reaches end of life on 31 December 2026?

Thank you,
[your name]

What a good answer looks like

Red flags in the reply

• A version number offered as proof. A version number can’t prove whether PHP is patched (source: AlmaLinux).
• “WordPress and all the plugins are updated.” The flaws are in the PHP engine. WordPress updates don’t change the PHP version underneath (source: php.net security advisory, October 21, 2026; WordPress.org version statistics).
• No mention of CVE-2026-115560. The October 21 releases don’t fix it (source: php.net advisory on CVE-2026-115560, October 23, 2026).
• “PHP 7.4 is patched”, with no named source. No official PHP release fixes 8.1 or older, so the fix must come from your host, your Linux distribution or a paid extended-support provider. Ask which one (source: Beazley Security Labs).
• A blanket all-clear on compromise, with no list of what was checked.
• A reply by phone only. Ask for it in writing, or write down who said what, and when.

What to do with the answers

1. Keep the reply, dated, together with any status page you rely on. Status pages change.
2. Fill the gaps. If an answer is missing or vague, send that one question again. Don’t accept “it’s fine”.
3. Act on what you learn. If nobody manages PHP on your server, start with our guide for business owners. If you need proof you can show someone else, the guide to proving a patch explains the evidence that counts.
4. File it. If your insurer or a customer asks later, a dated written answer is the record you’ll want. What evidence to keep.

Has anyone actually been hacked through PHP2Shell? As of October 23, 2026, security firms and governments had reported widespread exploitation attempts but no publicly confirmed successful compromise. The one exception: Palo Alto Networks’ Unit 42 reported a compromise at one European government entity, which hadn’t been independently corroborated (source: Beazley Security Labs). The point of the email isn’t alarm. It’s knowing where you stand, in writing.

Sourced facts

Full wording, primary sources and dates: /sources.

Frequently asked questions

Should I send this email if I’m on managed WordPress hosting?

Yes. Many shared and managed hosts reported patching PHP on their managed plans (source: GoDaddy), and a written reply for your own account turns that general statement into a record you can keep.

My developer says everything is up to date. What should I ask next?

Ask for specifics: the build that serves the site, the package changelog or advisory that names both CVEs, the time PHP was restarted, and where the CVE-2026-115560 setting was applied (source: AlmaLinux; php.net advisory on CVE-2026-115560, October 23, 2026). “Up to date” can mean WordPress, which doesn’t change PHP (source: WordPress.org version statistics).

What if my host won’t answer in writing?

Write down who you spoke to, when, and what they said, then send a short email summarising the call and asking them to correct anything wrong. If the questions about your own server still go unanswered, that tells you something about who is responsible for patching it (source: GoDaddy).

Can my agency answer this for all of our sites at once?

Yes, as one table with a row per site and the same columns as the questions. Our agency triage guide shows a format agencies can use for every client.

Rather have us check the answers?

• Patch Verification & Compromise Review. Your developer or host gives us read-only access: a dedicated login that can look but not change anything, shared through a secure link, never by email. We change nothing on your server. We find the answers to questions 1–8 ourselves, and you get a plain-English report: where each fix stands, as of a stated time, plus a compromise review from October 17, signed by the Approver of Record. Where we find no indicators, the report says “No evidence of compromise found in the checks listed” and lists those checks. Ask for it