Sources checked October 22, 2026. Practical recommendations below are editorial guidance; no hands-on product benchmark is claimed.
A security alert is useful only when it leads to a verified change on the server running your website. For owners of WordPress sites and other PHP applications, the October 2026 PHP advisory makes that distinction especially important. Updating a blog plugin and updating the server runtime are separate maintenance tasks.
What the official advisory says
CERT-EU’s October 21 advisory identifies two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. It lists fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and recommends patching affected installations promptly. It also tells users of distribution packages to consult their vendors for updated packages.
Those version numbers belong to this advisory. Do not assume that a familiar-looking version string establishes whether a hosting vendor has applied a backported fix. Ask for the vendor’s explicit confirmation.
First, identify who manages PHP
Write down your hosting provider, the application involved, and the person responsible for server updates. If you use managed hosting, send the advisory to support and ask whether the runtime serving your site is affected, what remediation has been applied, and whether you need to take further action.
If you manage the server yourself, use your approved maintenance process and the vendor’s instructions. Avoid copying an unfamiliar command from a social post into a production server simply because the headline sounds urgent.
Ask questions that produce a usable answer
A helpful support request names the domain and asks for evidence tied to that deployment. “Are you secure?” is too broad. A better question is whether the PHP runtime serving that domain has the fixes for the two named vulnerabilities, including any vendor backport.
Keep the response and change reference. A general statement on a hosting homepage may not explain what happened to your particular account or container.
Plan a focused website check
Before making changes under your control, confirm that your recovery material is usable. Know where the latest backup is, what it includes, and who can restore it. A filename alone is not a recovery plan.
After the runtime change, test the pages and functions your visitors depend on. Open the homepage and an article, submit a harmless test through your own contact form, and check any search, login, or purchasing flow that your site actually uses. Have the responsible administrator examine relevant errors.
Record the result instead of relying on “the homepage looks normal.” A short checklist helps you notice failures in less visible functions.
If you cannot confirm the fix
Escalate to the host or administrator with the advisory and your unanswered questions. CERT-EU recommends considering isolation of affected internet-facing applications where patching is not feasible until a fix is applied and verified. That decision belongs with the person who understands the deployment and service impact.
Do not present a successful patch as proof that no earlier incident occurred. If there are signs of compromise, preserve evidence and follow an incident-response process as well.
Frequently asked questions
Does this mean every PHP website was hacked?
No. A vulnerability advisory and evidence that a specific website was compromised are different things. Check exposure and remediation without inventing an incident.
Is a plugin update enough?
Ask separately about the server’s PHP runtime. Application maintenance does not by itself document that runtime’s patch status.
What should I save after the work?
Keep the vendor confirmation, change time, test results, and an owner for any remaining issue. That record makes the next urgent advisory easier to handle.
Related reading: Review AI chat sharing privacy and protect provider API keys.