Is My Website Affected by the PHP Vulnerability? A Small Business Checklist and the Exact Questions to Ask Your Host

Short answer: if your website runs on PHP (and most small business sites, including WordPress sites, do), it is potentially affected until your host confirms it is running a patched PHP build. You usually cannot fix this yourself, but you can ask the right people the right questions, get the answers in writing, and make sure no forgotten site is left behind. As of 2026-10-25, the PHP project says all PHP users should update immediately.

What happened, in plain language

PHP is the programming language that powers a very large share of websites, including WordPress, WooCommerce, many custom sites and a lot of booking and quoting tools. It runs on the server, not in your visitors' browsers.

On 2026-10-20 the PHP project pre-announced a critical security release. On 2026-10-21 it published an advisory titled "Security advisory: Critical remote code execution vulnerabilities, update now" on php.net. According to that advisory, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. In plain terms, someone with no password could potentially make the server run code of their choosing.

The two issues are tracked as CVE-2026-109618 (described as related to out-of-memory handling leaving internal request data partly initialized) and CVE-2026-109619 (described as stale request state surviving after its memory is freed and being reused by a later request). You do not need to understand the internals to act on this. Check php.net directly for the current wording and status, because details and third-party reporting can change.

A few things worth knowing:

• The PHP project did not name a narrow affected range. It says installations serving web requests are at risk.
• PHP 8.1 and older no longer receive official releases from the project. Minimal source backports for some older branches were published on GitHub, and some Linux vendors may issue their own patches.
• This is a flaw in PHP itself, not in WordPress or any plugin. Updating WordPress does not fix it, although you should keep it updated anyway.

This is not a reason to panic. It is a reason to spend an hour this week getting clear answers.

Step 1: Inventory every site you own

You cannot ask about a site you forgot you have. Before emailing anyone, build a simple list. Forgotten sites are the real risk because nobody is watching them and nobody will think to patch them.

Where to look

• Your domain registrar account. List every domain, including ones you registered for a campaign years ago.
• DNS records. Look for A records and CNAMEs for subdomains such as staging., dev., test., old., shop., blog. and booking.. Each one may point to a separate server.
• Hosting invoices and card statements. Search for hosting, "website", "domain" and agency names over the last five years.
• Your host's control panel. Look for addon domains, subdomains and extra installs inside the same account.
• Email. Search your inbox for "welcome to your hosting account", "your site is ready" and "WordPress installation".
• Your web agency or freelancer. Ask them for a list of every environment they built for you, including staging and test copies.

Record it in a table

A spreadsheet is enough. Use these columns:

Site or subdomain	Who hosts it	Who manages it	Uses PHP? (WordPress, custom, unknown)	Still needed?	Date asked	Answer received
www.example.com	Host A	Agency B	Yes, WordPress	Yes	2026-10-26	Pending
staging.example.com	Host A	Agency B	Yes, WordPress	Unknown	2026-10-26	Pending
oldshop.example.net	Unknown	Unknown	Unknown	Probably not

Any row with "Unknown" is your first priority. If a site is no longer needed, the safest fix is often to take it offline after making a backup, not to patch it.

Step 2: Find out how each site is hosted

The right question depends on the kind of hosting. Check which of these applies to each row in your table.

Hosting type	Who patches PHP	What you do
Shared hosting (cPanel, hPanel and similar)	The host	Ask the host for a written statement. Check the PHP version selector in the control panel and choose a currently supported branch if offered.
Managed WordPress hosting	The host	Ask for written confirmation of the patched build and the date it was applied.
VPS or dedicated server managed by an agency	The agency or sysadmin	Ask them for the PHP package version, the date updated, and whether PHP-FPM or Apache was restarted.

On shared hosting, you cannot install PHP yourself. What you can do is pick the PHP branch in your control panel and ask when the patched build is available. Also be aware that Linux vendors sometimes fix a flaw without changing the upstream version number, so a version string like "8.3.30" may or may not be safe. That is why a written statement from the host matters more than a number you read off a screen.

Step 3: Questions to send to your web host

Keep these short and numbered so they are easy to answer. Here is what to ask and how to read the response.

Question	A good answer	A red flag
1. Are my servers affected by CVE-2026-109618 and CVE-2026-109619?	A direct yes or no, with a link to their own security bulletin.	"We take security seriously" with no reference to the CVEs.
2. Which PHP versions do you offer, and which builds contain the fixes?	Names the specific patched builds or says fixes were backported, with a date.	"Just use the latest" with no detail.
3. When were the patched builds installed on my server?	A specific date and time.	"Soon" or "we are working on it" with no date.
4. Which PHP branch is my site on, and does it still get security fixes?	States the branch and its support status.	Silence about older branches like 8.1 or 7.4.
5. Do I need to change anything, such as switching the PHP version in the panel?	Clear steps, or "nothing required".	Vague answers that push the work back to you without instructions.
6. Do you take backups, and where are they stored?	Frequency, retention and a note on whether backups are stored off the server.	Backups only on the same server.

A good host will answer most of this in one reply, often with a copy of a customer notice. Slow or vague replies are not proof of a problem, but they are a signal to follow up and, if needed, to ask whether this is the right host for a business that depends on its website.

Step 4: Questions for your web agency or freelancer

Your developer knows things your host does not: what is installed, what is custom, and what else runs on the server. Ask these:

1. Which of my sites and environments did you build or manage, including staging and test copies?
2. Which hosting accounts and servers do they sit on, and who has the logins?
3. Which PHP version does each site run, and does the code work on a currently supported branch?
4. Did you confirm with the host that the patched build is installed? Please send the host's reply.
5. Are there any custom scripts, old upload folders, or unmaintained tools on the server that we no longer need?
6. When was the last full backup taken and have you tested a restore?
7. Who is notified if the site goes down or behaves strangely?

Good signs: a written list of environments, a named person responsible, a stated date for checking, and honesty about anything they do not control. Red flags: they cannot list what they manage, they say "it is only a PHP thing, nothing to do", or they have no copy of your site that they can restore.

Step 5: Plugin and theme vendors

A PHP engine flaw is separate from plugin bugs, so no emergency is needed. For anything handling payments, bookings or logins, ask whether it is still maintained and supports the PHP branch your host is moving you to. An abandoned plugin is a risk on its own: replace or remove it. A web application firewall (WAF) adds a layer but is not a substitute for the patched PHP build.

Backup and monitoring basics

None of this is specific to one flaw, and all of it helps when something goes wrong.

Backups

• Keep at least one backup that is not stored on the same server as the site.
• Keep several dated copies, not just the latest one, so you can go back before a problem began.
• Test a restore at least once. A backup you have never restored is a guess. See our guides on automated backups for small businesses and cloud backup for business.

Monitoring

• Set up an uptime monitor that emails you if the site goes down.
• Turn on login alerts for your host, registrar and WordPress admin accounts.
• Use unique passwords and two-factor authentication on the host, the registrar, and every admin account.

If something looks wrong, do not delete anything. Take a copy, note the time, and ask your host or a technician to look at the logs first.

Keep dated written answers (records and insurance)

Whatever the outcome, build a paper trail. It costs nothing and it helps in several situations.

• Save every reply from your host and developer as a PDF or keep the email thread, with dates visible.
• Update the "date asked" and "answer received" columns in your inventory table.
• Keep a single folder called something like "Website security 2026-10".
• If you carry cyber insurance, read the policy for security and patching conditions, and keep your records ready. Our overview of cyber insurance for small businesses explains what insurers commonly ask about. Policies differ, so check yours or ask your broker.

Written records also help if a customer or partner asks what you did, because you can answer with dates instead of memory.

Email template for your web host

Copy, paste, and fill in the brackets.

Subject: Written confirmation needed: PHP security release (CVE-2026-109618 and CVE-2026-109619)

Hello,

I am the owner of [Business name], account [account number or primary domain].
My account includes these sites: [list domains and subdomains].

The PHP project published a critical security advisory on 2026-10-21 about
CVE-2026-109618 and CVE-2026-109619. Could you please reply in writing to the
following:

1. Are the servers hosting my account affected, and have patched PHP builds
   been installed? If yes, on what date and time?
2. Which PHP version/branch is each of my sites currently using?
3. Do I need to change anything in my control panel?
4. Do any of my sites run an older PHP branch that no longer gets official
   security releases? If so, what are my options?
5. Please link or attach your security bulletin or customer notice.
6. How long do you retain server logs, and what backups do you keep of my account?

I would appreciate a reply by [date]. I am keeping this email for my records.

Thank you,
[Name]
[Business name] | [phone]

Email template for your web developer or agency

Subject: PHP security release: please confirm status of our websites

Hello [Name],

The PHP project announced two critical remote code execution fixes on
2026-10-21 (CVE-2026-109618 and CVE-2026-109619). Could you please confirm
in writing:

1. A full list of sites, subdomains and staging/test copies you built or
   manage for [Business name], with the hosting account for each.
2. The PHP version each one runs, and whether the host has confirmed the
   patched build is installed (please forward their reply).
3. Whether any site depends on an older PHP branch, and a plan and quote to
   move it if so.
4. The date of the last backup and the last restore test.
5. Any plugins, themes or scripts that are unmaintained or no longer needed.
6. Who should I contact if the site goes down or behaves strangely?

Please reply by [date]. I am keeping your answers on file.

Thanks,
[Name]

What a 60 minute remote consult can cover

If you would rather not chase this alone, a technician can work through the checklist with you on a screen share. A 60 minute session can cover things like building the site and subdomain inventory, reading your control panel to see which PHP branch each site uses, reviewing your host's and developer's replies, checking that backups exist and can be restored, setting up uptime monitoring and account protection, and writing a short follow-up list. It is not a guarantee that a site is secure, and it does not replace the host's own patching, but it turns a vague worry into a clear list of next steps. You can learn more about remote help, our support for businesses, or book a session. If your own computers also need attention, see our Windows support page.

FAQ

Is my website affected by the PHP vulnerability?

If your site runs on PHP, which includes most WordPress sites, it can be affected until the server it runs on has a patched PHP build. Ask your host to confirm in writing. Static sites and hosted builders that do not use PHP are less likely to be involved, but ask the vendor.

Can I fix this myself on shared hosting?

Usually not. The host installs PHP. You can select a supported PHP branch in your control panel if the host offers that and ask when the patched build is available.

Does updating WordPress fix it?

No. This is a flaw in PHP itself, not in WordPress. Keep WordPress, themes and plugins updated for other reasons, but the fix has to come from the patched PHP build.

How do I know which PHP version my site uses?

Look in your hosting control panel for a PHP version or "Select PHP" tool, or in WordPress under Tools, then Site Health, then Info, then Server. Remember that a version number alone does not prove a vendor has applied a backported fix.

What if my site uses PHP 8.1 or older?

The PHP project does not release official updates for 8.1 and older, although it published minimal source backports for some old branches on GitHub, and some vendors may offer their own patches. Ask your host what they provide, and plan a move to a supported branch. Check php.net for current support dates.

What about forgotten staging sites and old subdomains?

Include them in your inventory. If a site is no longer needed, back it up and take it offline. If it is needed, treat it like any other site and ask the host about it.

Is a web application firewall enough?

A WAF can reduce exposure and is worth having, but it is not a fix. The patched PHP build is the fix.

Should I keep records of the replies?

Yes. Save dated written answers from your host and developer. They help for your own planning, for client questions, and in conversations with an insurer.