> ## Content Index > Fetch the complete content index at: https://securinglaravel.com/llms.txt > Use this file to discover other available public pages before exploring further. # Laravel Security Notice: Critical PHP Security Release - The Day After - URL: https://securinglaravel.com/security-notice-critical-php-security-release-the-day-after/ - Published: 2026-10-22T03:11:05.000Z - Updated: 2026-10-22T03:11:05.000Z - Description: [Notice #6] The patches landed, the servers (just) survived, and the disclosure fell apart around them. Here’s the full round-up in one place - where to find the details, how to get patched, and the chaos that made a hard day harder. - Author: Stephen Rees-Carter - Tags: Security Notice, Core PHP, Vulnerabilities Yesterday two CRITICAL security vulnerabilities were announced in PHP, with patches scheduled to be released at 2pm UTC - i.e. midnight in Brisbane. I sent out my [Security Notice](https://securinglaravel.com/laravel-security-notice-critical-php-security-release/) and followed it up with a series of updates as the day happened. It was a long day for everyone involved in updating and patching servers. Now that the patches and disclosures have been published, I wanted to round up all the details in one place, to hopefully answer some of your questions and send you in the right direction for the rest. However, if you have any questions you haven't seen answers to, leave a comment and I'll see what I can find out. ## Laravel Cloud, Forge, & Vapor update Source: [https://laravel.com/blog/php-critical-vulnerability-response-updates](https://laravel.com/blog/php-critical-vulnerability-response-updates?ref=securinglaravel.com) **Laravel Cloud** applications have all been patched automatically. The team worked through the different regions systematically applying patches. **Laravel Vapor** runtimes were patched but required a redeployment to update applications to the patched versions. The team planned to auto-deploy the patch, but it looks like they are recommending customers do a redeploy. So if you have any Vapor apps, go give it a redeploy. Custom/Docker images on Vapor are your responsibility to update via a deployment once the image is patched. **Laravel Forge** was hit with what you could accurately call an accidental Distributed Denial of Service (DDos) attack from everyone trying to use it to patch the servers at once. It is honestly incredible it was as responsive as it was and the servers didn't melt into puddles. The worker queue that processed commands on the servers was flooded with jobs and took a long time to process. Yikes. Ubuntu 26.04 LTS servers received the patch very quickly, so patching those was trivial, however the 24.04 LTS and 22.04 LTS were still configured with a deprecated package repository, which took hours to build new packages - delaying the release of those patches. This wasn't the fault of the Forge team - I don't think anyone expected that repository to be so slow at getting the update, and once it became clear, there was no way to fix it across the fleet. Folks could manually update, but realistically asking devs to swap out package repositories in the middle of a huge patching event could lead to bigger issues, so we all just impatiently waited for the new packages to drop. Forge now includes an alert when you log in to advise if your PHP versions still need to be patched. So go check that out. ## Applying the patch If you're on Forge, or a Ubuntu server, head over to the article the Laravel team put together: [https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026](https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026?ref=securinglaravel.com). It outlines the fixed versions of PHP and SSH instructions for Ubuntu servers. If you're on another distro, you'll need to check your own distro's update instructions and if the packages are available. Note, only PHP 8.2 and newer were patched officially - they are the only supported versions. If your app is on an older version of PHP, you need to be working on an upgrade immediately. If that involves upgrading Laravel, then check out [https://laravelshift.com/](https://laravelshift.com/?ref=securinglaravel.com). If you cannot apply the patch now, go implement the [published mitigations](https://www.php.net/archive/2026.php?ref=securinglaravel.com#2026-10-21-5). ### Cloudflare WAF Rules Cloudflare have developed [Web Application Firewall (WAF) rules](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/?ref=securinglaravel.com) which can help protect against attacks. They aren't a complete solution for long-term protection, but they will help protect your site until you can get the patches applied. These new rules are automatically deployed and enabled for **free customers.** Paid customers will need to [manually enable these rules](https://dash.cloudflare.com/?to=/:account/:zone/security/security-rules&ref=securinglaravel.com). Ironically it's better to be a free customer right now! ## Where can I find out more about these vulnerabilities? The first place to go is the official announcement, here: [https://www.php.net/archive/2026.php#2026-10-21-5](https://www.php.net/archive/2026.php?ref=securinglaravel.com#2026-10-21-5) > **PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.** > > **Who is at risk:** all PHP installations serving web requests, including PHP-FPM, Apache with mod\_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod\_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs. > > **The vulnerabilities:** > **\- RCE via OOM corruption**, CVE-2026-109618 ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=securinglaravel.com)): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid. > \- **RCE via stale global state**, CVE-2026-109619 ([GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=securinglaravel.com)): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it. There is a summary of the vulnerabilities in the announcement, along with the limited mitigations. Note, these mitigations only slow down the attacks, they won't stop them entirely. The two GitHub advisories contain all the details - [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=securinglaravel.com) and [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=securinglaravel.com) \- including mitigations and impacts. They are worth a read if you want to dive deeper. My brain is too tired to do that right now, so you'll have to do your own learning here. **Once you've checked out the official disclosures, head over to** [**https://calif.io/php2shell/**](https://calif.io/php2shell/?ref=securinglaravel.com)**. In fact, you should start here.** [Ryan Austin](https://x.com/lcfr%5Fhax?ref=securinglaravel.com) of [Calif](https://calif.io/?ref=securinglaravel.com) has done an incredible write up of the vulnerability, and its history. There are even comics. **Seriously, go check it out.** To keep digging, you can then go to [php2shell.com](https://www.php2shell.com/?ref=securinglaravel.com), which was set up by Wiz Research, who were part of the team that worked on this. They have provided demo videos, mitigation details, and links to more technical details from the other researchers and security companies who were involved. (It's also a bit of a corporate marketing site, but they link to a lot of good material.) The next essential place to visit is an article posted by the PHP Foundation, but it deserves its own section... ## Disrupted Disclosure and the chaos that unfolded... After the patches were released, the PHP Foundation published [Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=securinglaravel.com). It outlines the vulnerabilities and a brief history of how they were discovered and who was involved in the work, which includes the [PHP Foundation's Ecosystem Security Team](https://thephp.foundation/blog/2026/05/18/announcing-ecosystem-security-team/?ref=securinglaravel.com). 💡 **As a side note, I am on the Ecosystem Security Team as the Laravel Community representative. I had no part of this event though, and this article is entirely my own.* ### The Leak The article then goes on to explaining what fell apart with this disclosure. It was originally scheduled for later this week, but someone announced the CVEs with an (incorrect) release date and CVSS score of 10 (the real CVSS was 9.2). 💡 If you've never heard of it before, CVSS stands for Common Vulnerability Scoring System and is a way of scoring vulnerabilities for criticality. It calculates the score based on the attack vector, complexity, required privileges, if user interaction is needed, the impacted scope, and the impacts to confidentiality, integrity, and availability of the application and its data. 10 is the highest score and means very bad things are coming. You can find the calculator here: [https://www.first.org/cvss/calculator/3.1](https://www.first.org/cvss/calculator/3.1?ref=securinglaravel.com) No technical details were leaked, however a CVSS 10 (as the rumours were suggesting) would send folks scanning the codebase for something big. The team decided to bring the release forward by a 24 hours and push out their announcement. They couldn't release immediately as package distributors we're still applying, testing, and packaging up the patches for release. Pushing out the details would have allowed attackers to start exploiting it in the wild before the patches were available. Despite what some armchair commentators on social media would like to believe, it takes a significant amount of time to push out a patch like this to a project the size of PHP. ### The Video and PoCs The next failure was one of the security firms accidently posting a video demonstrating the attack in action. Although they removed it, it was copied and started circulating online, and unfortunately provided a roadmap directly towards the vulnerabilities. This allowed anyone with an AI agent to direct it towards the PHP source code, looking for CVSS 9.2 that behaved in a specific way. ### PoC attacks AI generated Proof of Concept (PoC) attacks soon started being published. Which is an unethical thing to do, and is clearly only done in order to try and claim credit for finding something they have no real claim to. I even saw one person asking for cryptocurrency donations for his "discovery". 😡 This spawned folks recommending `php.ini` config changes that would supposedly prevent the attacks. Unfortunately, as we've mentioned above, the only full fix is the patch. These mitigations weren't confirmed and may have given people a false sense of security as to their effectiveness. I worry some people would have applied the "mitigation" and ignored the issue, believing they were no safe. This turned a "there is something big coming, are we ready" into a mess of misinformation, scared people, and terrible takes from people who have no idea how long it takes to actually release a patch and the purpose of responsible disclosure. ### Broken Embargo It gets worse. One of the companies who was building patches decided to release them early - which effectively handed the attack to anyone with the skills to turn a binary patch into a working exploit. They claimed it was because exploits were already available, however it undermined the coordinated disclosure and put everyone at more risk. Although we can't know for sure, I truly believe yesterday would have been a lot less stressful for everyone if it wasn't for the actions of a few jerks (and the accidental video release). The PHP Foundation finish off their article with a [call for support and funding](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=securinglaravel.com#what-we-need-from-you), to give them more resources to deal with these sorts of issues. If that is something your organisation can do, please consider it. Valorin Security/Securing Laravel has been financially supporting The PHP Foundation since it was started in November 2021. ## How are other teams working on this Scott Helme over at Report URI has a [great blog post](https://blog.report-uri.com/responding-to-php2shell-cve-2026-109618-and-cve-2026-109619/?ref=securinglaravel.com) where he walks through each of the steps he was taking during the mitigation and patching process. He covers different rules he was applying, including Cloudflares rules, config changes, etc. It's worth a read if you want to keep digging. ## Is it over? No. *Our* servers may be patched, but there is a large amount of the internet that are running outdated and unpatched PHP, and I suspect the fallout as they start to get compromised could get messy. I've seen a few posts already about attacks being detected in the wild. [![](https://storage.ghost.io/c/d9/0d/d90de76f-6031-4e2c-85b8-3447a38c4992/content/images/2026/10/image-5.png)](https://bsky.app/profile/campuscodi.risky.biz/post/3myg7tgxt2225?ref=securinglaravel.com) Cybersecurity journo Catalin Cimpanu linking to reports of attacks. [![](https://storage.ghost.io/c/d9/0d/d90de76f-6031-4e2c-85b8-3447a38c4992/content/images/2026/10/image-6.png)](https://x.com/eastdakota/status/2113079352682570051?ref=securinglaravel.com) Cloudflare CEO reporting millions of exploitation attempts. There are also reports of a related vulnerability that is still unpatched, however from what I can figure out, it isn't exploitable in the wild and is considered a bug not a vulnerability. But I'll keep my eyes out for more on this. I would also be **very surprised** if more vulnerabilities at this level don't start dropping in other languages soon. AI has unfortunately changed the game, and things are going to get worse. ## Wrapping Up I hope that's given you a sense of where things stand, and pointed you in the right direction for some answers. I know a lot of you are probably still working hard on this, and have had hardly any sleep. Thank you for trying to keep the internet a bit safer. I only had 4 servers to patch, and was able to keep them offline until patches were out, so I got it easy compared to a lot of places. Please let me know what questions you still have, and I'll update this article.