Short answer: Rolling out the October 2026 PHP security patch in Laravel means getting every runtime onto 8.5.12, 8.4.27, 8.3.36 or 8.2.35: servers, Docker base images and CI runners. Bump the patch level first, test on staging, deploy, then restart queue workers, Horizon and Octane, because long-running processes keep the old binary in memory.
The PHP team released these versions on 21 October 2026 to fix CVE-2026-109618 and CVE-2026-109619, two bugs it says can allow unauthenticated remote code execution. Here’s how I’d sequence the rollout for a team running several Laravel apps.
What exactly changed in PHP?
Only the patch level. There’s no new language feature and no deprecation to chase, so the upgrade risk is low.
The PHP 8 ChangeLog lists the security fix under Core as “Avoid state corruption via bailout.” The advisory describes the two bugs:
- CVE-2026-109618: an out-of-memory failure can interrupt PHP while request data is half-initialized, and cleanup then trusts it.
- CVE-2026-109619: request-owned state can survive after its memory is freed, so the next request on the same worker may use it.
That second one is a worker reuse problem. PHP-FPM pools, Octane and anything else that serves many requests per process are exactly where it lives.
I’ve broken down both bugs, how the scores differ and which server setups are most exposed in the October 2026 PHP vulnerability explained.
Which PHP versions does a Laravel team need to target?
Stay on your current minor and take its patch release. Changing minor versions during a security rollout mixes two kinds of risk.
| Your branch | Target | Note |
|---|---|---|
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | End of life 31 Dec 2026 per php.net |
| 8.1 or older | Upgrade the minor | No official fix |
If you’re stuck on 8.1, this is the push to plan the jump. I covered the language changes that tend to bite in my notes on modern PHP from 8.0 to 8.4.
Step 1: Take inventory before touching anything
Make a list of every place PHP runs. Teams usually remember the web servers and forget the rest:
- Web servers (PHP-FPM, mod_php, FrankenPHP)
- Queue and scheduler boxes
- Docker images, including the ones only used in CI
- CI runners and
setup-phpstyle actions - Local dev environments (lower priority, still worth doing)
On a server, ls /etc/php shows installed versions on Debian and Ubuntu layouts, and php -v plus php-fpm8.x -v tells you what is live. Patch versions you aren’t using too. An idle 8.2 install still gets picked up by a stray cron or CLI script.
Step 2: Check Composer’s platform setting
Look at composer.json for config.platform.php. Many teams pin it so composer install resolves packages for production’s PHP, not a developer’s laptop.
A patch bump (8.3.35 to 8.3.36) won’t change dependency resolution, so you usually don’t need to edit it. If you’re moving off 8.1 at the same time, update the pin, run composer update --dry-run, and read what moves. Then run composer check-platform-reqs on the target environment to confirm the installed PHP and extensions satisfy the lock file.
Step 3: Rebuild Docker images instead of trusting tags
A php:8.3-fpm tag points at a new build only after the image maintainers rebuild it. Your registry cache and your Dockerfile’s FROM line may still be on the old one.
- Rebuild with
--pullso the base image is fetched fresh. - If you pin by digest, update the digest.
- Run
php -vinside the built image as a CI step and fail the build if it isn’t the patched version.
That last check is cheap and saves the “we deployed, but the image was cached” conversation.
Step 4: Update CI so tests run on the patched runtime
If your CI installs PHP through an action or a package repository, pin to the patch level or bust the cache so runners pick up the new build. Then run the full test suite once against it. A patch release rarely breaks tests, but you want proof before production.
Step 5: Patch staging, then production
On servers installed from distribution or Ondřej Surý packages, the update is a package upgrade (apt-get update then upgrade the php8.x-* packages) followed by a PHP-FPM restart. Hosted panels such as Laravel Forge offer a per-version update action that does the same job. Forge’s own advisory page notes that its automatic security updates do not cover PHP, so don’t assume unattended upgrades caught it.
Check that the package candidate is the fixed version before upgrading. Repositories can lag the upstream release by a few hours. The PHP advisory also warns that the volunteer-run rpms.remirepo.net would not have updates on release day, so RHEL-family servers using it need a different source.
Restarting PHP-FPM drops in-flight requests for a moment, so pick a quiet window.
Step 6: Restart everything that holds PHP in memory
This is the step teams skip. Queue workers, Horizon, Octane and Reverb started from the CLI keep running the old PHP binary until they restart.
php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload
Your process manager (Supervisor, systemd) brings them back on the new binary. Given that CVE-2026-109619 involves state carried between requests in a worker, long-lived Octane workers are the last place you want an old runtime.
Step 7: Verify, then write it down
Run php -v and php-fpm8.x -v on each host and record the version. For containers, log the version at boot. Keep a short table per app: environment, PHP version, date patched. Next time a critical release lands, that table is your inventory.
To roll out the session upload-progress mitigation across all your Forge servers at once, use this recipe.
What if a server can’t be patched today?
The php.net advisory lists partial mitigations, including session.upload_progress.enabled=0 set in php.ini or the FPM pool (not via ini_set() or .user.ini), a low post_max_size, and on PHP 8.5, fatal_error_backtraces=0. Each blocks a known path, not the whole class. Treat them as hours of cover, not a fix.
If that server is on PHP 8.1 or older, there’s no official patch coming, so the real fix is to upgrade your PHP version to a supported branch.
FAQ
Do I need to change my Laravel version for this PHP patch?
No. It’s a patch release within each PHP branch, so any Laravel version that runs on your current PHP minor keeps working.
Does composer update install the PHP fix?
No. Composer manages packages, not the PHP runtime. You update PHP through your OS packages, Docker image or hosting panel.
Why restart queue workers after updating PHP?
CLI workers load PHP once and keep it in memory. Until they restart, they run the old, vulnerable binary.
Is PHP 8.1 covered by the October 2026 release?
No official 8.1 release was issued. The PHP team published minimal source backports for 7.4 to 8.1, but most teams should upgrade to a supported branch.
How fast should we roll this out?
The PHP team asks all users to update immediately and says there are no complete mitigations. I’d treat it as same-day work for anything internet-facing.
Sources: PHP news archive 2026, PHP 8 ChangeLog, PHP supported versions, Laravel Forge advisory. Last checked 22 October 2026.
Shahrukh Akhtar (Shaz3e) is CTO & Co-Founder of Diligent Creators Pvt. Ltd., building EloSync and other SaaS products. Find him on X, LinkedIn, Peerlist and GitHub.
