PHP Remote Code Execution Vulnerabilities: Forminit Is Patched

TL;DR: On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that allow unauthenticated remote code execution. Forminit’s infrastructure is updated to the patched releases. No action is needed on your side for Forminit. If you run PHP on your own servers, update now.

What was disclosed

The PHP security advisory covers two bugs. Both sit in PHP’s request lifecycle, not in any framework or library, so every PHP installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

CVE-2026-109618: RCE via out-of-memory corruption (GHSA-w8hw-w9fx-j79w)

When PHP runs out of memory, the failure can interrupt it halfway through setting up internal request data. Request cleanup then runs over that partially initialized data as if it were valid. Freeing or walking a structure that was never fully built is a classic route to memory corruption, and from there to code execution.

The attacker’s job is to make the out-of-memory error happen at the right moment. The advisory’s mitigations (lower post_max_size, limits on input field count, multipart part count, header count and nesting depth) tell you where that pressure comes from: request parsing. A large or deeply structured request body can be enough.

CVE-2026-109619: RCE via stale global state (GHSA-6wmf-4rv5-p3rp)

PHP workers are long-lived. One FPM or mod_php process handles many requests in sequence, and PHP resets its per-request state at the start of each one. This bug lets request-owned state survive after its memory has been freed. If the next request handled by the same worker touches that state before initialization resets it, it is working with a dangling pointer: a use-after-free across request boundaries.

The confirmed trigger paths include session upload progress tracking, fatal error backtraces on PHP 8.5, and diagnostics emitted by invalid per-request settings before initialization finishes.

Why this one is serious

Most PHP vulnerabilities need a bug in your application code to reach. These don’t. The PHP team rates mod_php as the highest risk and has a working exploit where an unauthenticated request triggers the attack before any application code runs. Your framework’s routing, validation, authentication and rate limiting never get a say.

Form endpoints are a direct fit for this attack surface. They are public by design, accept POST bodies from anyone, and often parse multipart uploads, which is exactly the input path both bugs depend on.

What we did

• Updated every PHP runtime in Forminit’s infrastructure to the patched release for its branch
• Restarted all PHP workers after the update. This matters for CVE-2026-109619: the bug lives in long-running worker processes, so a package upgrade without a restart leaves the old code serving requests

Your form code, Form IDs and SDK setup stay the same.

If you run PHP yourself

Many Forminit users run PHP on their own side: WordPress sites, headless WordPress with Contact Form 7, Laravel apps that verify signed webhooks, or PHP proxies that call the Forminit API with a secret key. Those servers need their own update.

Check what you are running:

php -v

Then compare against the fixed releases:

Branch	Fixed in	Notes
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35	End of life on 31 December 2026
PHP 8.1 and older	No upstream release	Use your vendor’s backport or the PHP team’s source backports for 7.4, 8.0 and 8.1

A few things that are easy to miss:

• Restart every worker. Reload PHP-FPM or restart Apache after upgrading. php -v on the CLI tells you nothing about the binary your web server has loaded.
• Distribution packages first. Linux distributions and LTS vendors received the patches in advance, so updated packages should already be available.
• remirepo users. The PHP team notes that rpms.remirepo.net will not have updates on release day and recommends switching to distribution packages or building from source.
• Managed hosting. If your host manages PHP for you, confirm with them which version your site is running.

If you can’t update yet

The advisory lists partial mitigations. They reduce exposure to specific attack paths but do not make an installation safe, so treat them as a bridge to the update:

• Set session.upload_progress.enabled=0 in php.ini or the FPM pool config (not ini_set() or .user.ini) and restart every worker
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker
• Lower post_max_size (8M without uploads, 32M with uploads) and keep upload_max_filesize below it
• Enforce request size, field count and multipart part limits at the web server or proxy, including for requests without a Content-Length
• Set memory_limit=-1 with php_admin_value so applications can’t override it, and use a container or cgroup limit as the real memory boundary. Don’t use RLIMIT_AS or RLIMIT_DATA for this, because they can cause the exact allocation failure the bug needs

The full technical details are in the two GitHub advisories linked above. If you have questions about how this affects your Forminit setup, contact us.