Security Advisory: Critical PHP Vulnerabilities, October 2026

Why this one matters

Most months, PHP security updates are routine — a memory-handling fix here, an edge case there. This batch is different in one specific way: it includes a remote code execution issue in the Zend engine, the core of PHP itself.

Remote code execution is the category that matters most. It describes a flaw where an attacker can get your server to run their instructions instead of only yours. It is the difference between someone rattling a locked door and someone standing in the hallway.

Alongside it sit two flaws in how PHP verified TLS certificates, and one in how PHP's FastCGI component enforced IP-based access restrictions. Those are quieter, but they weaken the exact controls people rely on to keep connections and servers trustworthy.

The vulnerabilities

These are the issues documented in the Ubuntu security updates for PHP 8.1 released on 19 October 2026. Equivalent fixes have been issued for other PHP versions and distributions.

Identifier	Issue	Why it matters
CVE-2026-109618 CVE-2026-109619	Remote code execution via state corruption. The engine could be left in a corrupted state when an operation bailed out mid-execution.	The most serious of the set. Touches core engine memory handling, opcache, sessions, and file-upload processing.
CVE-2026-91769	TLS verification fell back to the certificate Common Name when it should not have.	Weakens certificate validation on outbound connections — the check that confirms you're talking to who you think you are.
CVE-2026-91767	Out-of-bounds read in wildcard certificate name matching.	A second flaw in the same certificate-verification path.
CVE-2026-91768	FastCGI compared only the first 96 bits of IPv6 addresses when enforcing its allowed-clients list.	An IP allowlist that doesn't fully compare the address isn't really an allowlist. Relevant anywhere FastCGI access is IP-restricted.
CVE-2026-92842	Heap buffer over-read in stream filters handling a NUL byte in line-break characters.	Memory-safety issue in data stream processing.
CVE-2025-1218	Multiple out-of-bounds reads in the MySQL wire-protocol parser on truncated packets.	Affects applications talking to MySQL/MariaDB, particularly against an untrusted or compromised database server.

We've deliberately described these in the words of the official changelog rather than assigning our own severity scores. If you need formal ratings for a compliance process, cite your distribution's security notice directly.

Are you affected?

Probably — and that's not alarmism. PHP runs a very large portion of the web. You're likely affected if you have:

• A WordPress, Drupal, Joomla or Magento site — all built on PHP
• A customer portal, booking system, or internal tool that was custom-built or vendor-supplied
• A self-hosted application such as a helpdesk, wiki, CRM or file-sharing tool
• Any server a vendor set up years ago that nobody has logged into since

That last one deserves emphasis. The highest-risk systems in most organizations aren't the ones being actively worked on — they're the ones everyone forgot about. A marketing microsite from 2019. A forms server a departed employee configured. Those still run PHP, still face the internet, and nobody is patching them.

What about routers, cameras and other devices?

A fair question, and the answer is more specific than people expect.

Most home and small-office routers do not run PHP. Their admin pages are typically built on much lighter technology, so this particular advisory generally doesn't apply to them. That's worth saying plainly, because security coverage often implies everything with an IP address is affected by everything.

But plenty of other equipment does run PHP, usually to serve its own web admin interface. Network-attached storage appliances are the common example, and some cameras, video recorders, and on-premise phone systems fall into the same category. If a device has a browser-based admin page, it's running a web server, and that web server may well be running PHP.

This is why embedded equipment tends to be the weakest link. It's not that the devices are badly made — it's that the patching timeline isn't yours to control, and a device quietly doing its job for six years is one nobody thinks to check. Many are running versions of PHP that stopped receiving security support long before this month's advisory, which is a larger problem than the six issues described here.

Two practical consequences:

• Device admin interfaces should not be reachable from the internet. If a NAS, camera system, or phone system has its management page exposed publicly, that is worth addressing regardless of which vulnerabilities are current this month. It is the single highest-value change most organizations can make here.
• Check whether your vendors have published anything. Manufacturers issue their own advisories on their own schedule, independent of the upstream PHP release.

It's also one of the quieter arguments for cloud-delivered services. When your phone system runs on a hosted platform rather than a box in your closet, keeping the underlying software patched is the provider's responsibility and happens without you scheduling anything. An on-premise appliance makes that your problem — and in practice, it usually means waiting on a vendor who may no longer be paying attention to that model.

What to do

If someone else manages your hosting

Ask them one direct question: "Have the October 2026 PHP security updates been applied to our servers, and when?"

A good provider answers with a date and a version number. Vague reassurance — "we keep everything up to date" — is not an answer. Ask for the version string, which you can check yourself.

If you manage your own servers

Apply the PHP security updates published by your operating system vendor, then restart the PHP service so the running processes actually pick up the new code. Follow your vendor's own documented procedure — the exact steps differ between distributions and between managed-hosting platforms, and the published instructions for your platform are the ones to trust.

Afterward, confirm the installed version actually changed rather than assuming the update succeeded. Verification is the step most often skipped, and a patch you believe was applied but never confirmed offers no protection — it only removes the sense of urgency to check.

If you genuinely don't know

That's the most common and most dangerous position. Start by making a list of every system your organization runs that has a web address — including the ones nobody owns anymore. You cannot patch what you haven't inventoried, and most breaches involve systems the victim had forgotten about.

What to expect from a provider

Our systems were addressed as part of our standard security maintenance. We mention that only to make a point about what good practice looks like from the outside.

You should expect any provider handling your systems to confirm plainly that an advisory has been actioned, and to do so without you having to chase them. "We keep everything up to date" is a posture, not a confirmation. A straight answer is.

The broader lesson

The organizations that handle advisories like this well aren't the ones with the biggest security budgets. They're the ones that know what they're running.

Three questions worth being able to answer on any ordinary Tuesday:

• What internet-facing systems do we have? Including the forgotten ones.
• Who is responsible for patching each one? "The vendor, probably" is not an answer.
• When was each last updated, and how do we know? Verified, not assumed.

If those questions are difficult to answer, that's worth more of your attention than any individual CVE. There will be another advisory next month.

Sources and scope: vulnerability details are taken from the official Ubuntu security changelog for PHP 8.1 (8.1.2-1ubuntu2.27 and 8.1.2-1ubuntu2.28, published 19 October 2026). Other PHP versions and distributions have their own corresponding advisories — check your vendor's security notices for the exact versions affecting you. This advisory is informational and does not constitute a guarantee regarding any specific system.