Critical PHP Vulnerabilities: What to Do Today

Update, 23 October 2026: the official PHP security update is installed on all Datahubb servers.

The short version

On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities that can let attackers run code on a server without logging in. If you run PHP, update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today. PHP states that updating is the only complete fix.

At Datahubb, we put protective measures in place on all our servers, and as of 21 October our monitoring had found no sign of exploitation. This post explains what happened, who is affected and what we recommend, including what it means for Datahubb customers.

What happened

The PHP security team announced two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and rated both 9.2 on the CVSS v4.0 scale. After advance notice on October 20, fixed releases followed on October 21. Both flaws can allow remote code execution without authentication. Security researchers refer to them as PHP2Shell.

CVE-2026-109618: when PHP runs out of memory, it can be interrupted while internal request data is only partly set up. Cleanup may then treat that invalid data as valid.
CVE-2026-109619: internal state that belongs to one request can survive after its memory has been freed. A later request handled by the same worker may then use that stale state.

The full technical details are in the official PHP security advisory.

Who is affected

PHP says all installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, where a demonstrated attack lets an unauthenticated request trigger the flaw before any application code runs.

The problem sits in the PHP runtime itself. Updating your framework, your CMS or its plugins does not fix it. The runtime on your server or in your container image has to be updated.

PHP 8.1 and older no longer receive updates from the PHP project. Some Linux distributions and long term support vendors provide backported fixes. For teams that build PHP from source, the PHP security team published minimal backports for 7.4, 8.0 and 8.1. PHP 8.2 reaches the end of its support on December 31, 2026, so plan your move to a newer version now.

What to do now

Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Use your operating system’s packages or the source and Windows builds on php.net. If your host manages PHP for you, ask them to confirm the patch is installed.
Rebuild and redeploy your Docker images. Restarting a container that still uses the old image does not patch anything.
Check your distribution packages. Some vendors backport fixes without changing the version number, so look for both CVE IDs in the package changelog instead of relying on php -v alone.
Replace PHP 8.1 or older. Ask your vendor for a backported fix in the short term and upgrade to a supported version as soon as you can.
Keep a firewall or WAF in front of your app, and make sure traffic cannot reach your servers directly and bypass it. It adds a layer of protection but does not replace the patch.
Check for signs of compromise after patching. A patch does not remove an attacker who is already inside. Look for unknown PHP files in upload and storage folders, unexpected admin accounts, recently changed files and unfamiliar scheduled tasks.
Using the volunteer maintained Remi repository? PHP reports that it will not have updates today and advises switching to distribution packages or building from source.

If you truly cannot update right away, the advisory lists settings that reduce exposure to specific attack paths. These do not make an installation safe. Consider taking exposed systems offline until they are patched.

What we did at Datahubb

Datahubb’s web services run on PHP, so this affects us as well. Here is what we have done:

We hardened PHP on all Datahubb servers and switched off the features linked to the attack.
We added a filter that blocks the request format the attack relies on before it reaches our application.
We added real time monitoring that alerts our team immediately if our servers start any unexpected process.
By 23 October we had installed the official PHP security update on all Datahubb servers.

As of 21 October, our monitoring had found no sign that Datahubb has been exploited, and Datahubb stayed fully available throughout.

These measures reduce exposure, but PHP states that only the update itself is a complete fix. That is why we installed it on all our servers by 23 October.

What this means for you

Using the Datahubb dashboard: nothing changes. Logging in, managing campaigns, uploading logos, importing leads and every other feature work as before.

Sending leads to Datahubb through the API: send leads as JSON (Content-Type: application/json) or as a standard form post (application/x-www-form-urlencoded). Both are what our API documentation describes, and almost every integration already uses one of them.

Leads sent as multipart/form-data are now rejected with HTTP 403 and the response "status": "MULTIPART_BLOCKED". This can happen without anyone choosing it. For example, PHP code that passes an array to CURLOPT_POSTFIELDS instead of a JSON string sends multipart. If you or your suppliers see this error, send the same fields as JSON and the leads will be accepted again.

Pixels, tracking links, offer walls and embedded pages are not affected.

If you see the 403 error, or anything else unexpected, contact our support team. We will help you or your supplier adjust the integration.

Be ready for the next one

Attack tools for flaws like these can circulate before a fix is even available, so speed matters. Keep an inventory of every place PHP runs, agree in advance who applies emergency patches, and track end of support dates so no system is left on a version that no longer gets fixes. The sooner we all update, the safer the internet is for everyone.

Questions about how this affects your Datahubb setup? Contact our support team.

Source: PHP security advisory, October 21, 2026