--- title: Critical PHP security update due October 21 at 14:00 UTC description: PHP's security team is releasing a high-stakes security update at 14:00 UTC on October 21. Anyone running PHP should plan to upgrade as soon as the patch... canonical: https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Critical PHP security update due October 21 at 14:00 UTC | daily.dev og:description: PHP's security team is releasing a high-stakes security update at 14:00 UTC on October 21. Anyone running PHP should plan to upgrade as soon as the patch... og:url: https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0 og:image: https://api.daily.dev/og/posts/57hO7AcC0.png og:image:alt: Critical PHP security update due October 21 at 14:00 UTC og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Critical PHP security update due October 21 at 14:00 UTC **[Collections](https://daily.dev/sources/collections)** · 9 min read · 64 upvotes · 7 comments ## Summary PHP's security team is releasing a high-stakes security update at 14:00 UTC on October 21. Anyone running PHP should plan to upgrade as soon as the patch lands. Taylor Otwell says the Laravel team is working with the PHP Foundation to get patched PHP versions into base images for Laravel Cloud, Forge, and Vapor quickly. Laravel users may need to redeploy apps to pick up the fix, though the team is also exploring a way to patch apps silently without a redeploy. Laravel customers have already been emailed, with more updates to follow. ## Content On October 21, 2026, the PHP project shipped emergency fixes for two critical remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. Both are rated 9.2 on CVSS v4.0. An attacker needs no login. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. ## What the bugs are Both flaws sit in PHP's core engine, in the request lifecycle before any application code runs. That is why WordPress, Drupal, Joomla, Magento and Laravel are all exposed. The problem is the interpreter, not the app. A plain "Hello World" script on an affected version is also vulnerable. - **CVE-2026-109618** is an out-of-memory handling bug. PHP aborts a request on memory exhaustion with longjmp(), which can leave partly initialized request data behind. - **CVE-2026-109619** involves stale global state that survives across requests on the same worker. A later request can read or write through pointers into freed memory. With a controlled heap layout, that becomes a use-after-free and then code execution. The same flaw can also leak process memory, which may hold passwords, tokens and API keys. The vulnerable code goes back to PHP 5.4. Affected setups include PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is rated highest risk. PHP's security team says there is no complete mitigation. Updating is the only real fix. PHP runs roughly 70% of websites whose server-side language is known. Several posts compare the bugs to Heartbleed and Log4Shell. ## How they were found Frontier AI models were involved. Calif found one flaw in August using GPT-5.6 Sol, as part of OpenAI's Patch the Planet initiative. Wiz Research says it independently found both, using its Atlas agent with Gemini 4 Argon and GPT-5.6 Sol. Wiz reported the first bug on August 24. OpenAI says to its knowledge the AI found the bug ahead of attackers, which gave defenders time to prepare. The fix took about two months because it required a major change to the engine. The PHP Foundation's own postmortem is blunt about the delay. The underlying out-of-memory weakness had been noticed earlier, with one account tracing it to a 2020 observation and another to a 2024 audit. The security team had several competing fixes, each with trade-offs, such as broken backward compatibility, new denial-of-service paths, or changes to many third-party extensions. It struggled to pick one, and a small group of engine experts had other duties. The Foundation calls this "a structural failure" and is asking companies that depend on PHP to fund more engine engineers. ## The leak and the embargo fight The embargo came apart. The CVE IDs leaked the day before release, Calif accidentally posted an exploit video that evening, and details reached Hacker News. PHP moved the release up a day but held it to 14:00 UTC so distributors could finish packaging. Cloudflare turned on WAF rules for all customers at 3:02 UTC on October 21, about nine hours before disclosure, after attackers began probing. Its protections rely on a new "full transaction detection" capability that inspects both requests and responses. Cloudflare still tells admins to patch PHP itself. Then came the Chainguard dispute. Chainguard published built images containing the fix at 07:41 UTC, more than six hours before the coordinated release. The PHP Foundation says Chainguard unilaterally broke the embargo, which let anyone study the fix in binary form while everyone else waited. CEO Dan Lorenc says Chainguard didn't leak anything. He says it shipped early because several vendors in the disclosure group reported exploitation in the wild. He didn't name them or publish evidence, and PHP's security team found no working public exploit by release time. Lorenc has since apologized for the added stress on maintainers. Chainguard's policy allows shorter timelines when exploitation is active, and the patch it shipped was PHP's own. I think the principle matters more than who was right about the evidence. Coordinated disclosure only works if everyone holding the fix ships at the same moment. When one party goes early, the fix becomes a map for attackers. ## Sites going dark CERT-EU told organizations that couldn't patch in time to consider taking sites offline. The NSA and the FBI gave similar advice, as did CISA, and many did. Reported shutdowns include: - **Netherlands:** the NCSC's own site, the Port of Rotterdam, Overheid.nl, KNVB, major political parties and hospitals. - **Finland:** state IT provider Valtori took government public network services offline. - **France:** the Interior Ministry put its sites into preventive maintenance. - **UK:** the Office for Budget Responsibility, Edinburgh and Oxford councils, and some BBC pages. - **Denmark:** municipal IT provider Kombit shut down services including the national school communication platform. - **Japan:** MUFG, Mizuho and Shizuoka Bank paused some services, as did airlines and Seven-Eleven Japan. Prime Minister Sanae Takaichi urged site owners to check for PHP use. Wikipedia took down affected systems, and Pinboard, the GrapheneOS forum and OBS pulled parts of their sites. Most of these were precautions, not confirmed breaches. ## Is it being exploited? Attempts are certainly happening. Cloudflare's Matthew Prince said attempts rose from thousands before the announcement to tens of thousands within 45 minutes, hundreds of thousands within two hours, and millions afterward. Arctic Wolf has seen scanning and attempts pulling ELF and Golang binaries, with some payloads linked to the Potassium botnet, a Mirai-derived family. Amazon said an attempt began four days before disclosure, and one report traces pre-disclosure exploitation to October 17. Successful attacks are another matter. Officials in Germany, the Netherlands and Japan say none has succeeded, and Germany's BSI called the flaw harder to exploit than expected. Wiz has seen exploitation attempts but no successful end-to-end attack in its telemetry. It tracked two exploit kit variants: an older chain blocked by PHP's post_max_size limit, and a newer one that reliably exhausts memory but fails to leak the heap addresses needed for the last stage. Build differences, memory limits and worker configuration seem to block that step. Underground forums agree. Experienced posters on Exploit.in and XSS say the public proofs of concept mostly crash PHP instead of giving code execution. They say the exploits need build-specific memory offsets from libphp.so that can't be predicted or brute-forced, and one tester logged 8 of 8 crashes on PHP 8.4.26 and none on patched 8.4.27. Some called the public GitHub code "AI slop." Systems without ASLR, such as some Palo Alto and Citrix NetScaler appliances, are where exploitation may get much easier. But there are counterexamples. A researcher at Tolmo says his team built a working exploit in under a day. Adel Karimi's public report is the strongest evidence of a working exploit, though only on a favorable single-worker Apache mod_php setup. Mandiant's Charles Carmakal says some validated proofs of concept reach RCE against mod_php but not PHP-FPM. VulnCheck built an exploit that gets around ASLR on x86-64 PHP 8.4.26, with display_errors off, which it says is the first known to work under those conditions. And LiveOverflow had an agent build an exploit that works under concurrent traffic by saturating Apache prefork to block other connections. Expect environment-specific exploits, not one universal one. ## A third bug The PHP Foundation reserved CVE-2026-115560 for a third RCE bug. It won't get an emergency fix and will be patched in the next regular release. It needs an unlikely setup: an app switching session.serialize_handler to php at runtime via ini_set() with session upload progress enabled. Until then, set session.upload_progress.enabled=0. ## Who is exposed The unpatched pool is huge. Scan data on 2,220,231 internet-facing PHP services found 72.7% on branches no longer supported upstream. PHP 7.4.3 and 7.4.33 alone make up 21.3%. Another 418,288 records use distro-packaged version strings whose real patch state can't be read from the banner. PHP also turns up on VPN, storage and building-automation interfaces on ports like 81, 8080 and 8888. Censys counted about 2.58 million internet-facing hosts running PHP, and VirusTotal about 5.1 million exposed IP addresses. Wiz says vulnerable internet-exposed machines fell about 67% within days of disclosure. PHP 8.1 and older get no official fix. The PHP team did publish minimal source backports for 7.4, 8.0 and 8.1, and nothing exists for 5.4 through 7.3. ## What to do 1. Update the PHP runtime itself to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating WordPress, plugins or frameworks doesn't change PHP. 2. Restart your workers after updating. 3. If you can't patch, or you're on 8.1 or older, take the PHP service offline or isolate it. 4. Check hosts, containers and CI. Docker updated its Official and Hardened Images within 24 hours. Laravel Cloud auto-patches, Forge users must update manually, and Vapor apps on PHP 7 need an upgrade to PHP 8. On Azure DevOps, Microsoft patches PHP on hosted images, but PHP your own pipeline steps install is your job. NixOS 25.05 users can get paid patching from Determinate Systems. 5. Look for signs of earlier compromise. A patch closes the door but doesn't show whether someone already walked through. ## Other trouble the same day Node.js shipped security releases for versions 22, 24 and 26, fixing 10 bugs including an RCE and two TLS certificate bypasses. Indian certificate authority eMudhra disclosed that eight of its intermediate certificates had extremely weak keys, and browser vendors blocked them. Railway paused deployments after a possible unauthorized access to stored variables. Some see this as the new normal. OpenAI expects AI-found vulnerabilities to increase sharply in the coming months, and Anthropic's Jason Clinton warned security leaders that "we need to hold on for ~18 months." I find that more unsettling than the outages. The bugs sat in the engine for years, and the shrinking gap between disclosure and exploitation won't give anyone much slack. ## Questions this post answers ### When is the critical PHP security update being released? The PHP security team is releasing it at 14:00 UTC on October 21. Anyone running PHP in any environment should plan to upgrade as soon as the release lands, since it addresses a high-stakes security issue. _Developers tracking the PHP patch window can follow release updates on daily.dev as the deadline nears._ ### Will I need to redeploy my Laravel app after the October PHP security patch? Possibly. The Laravel team is working with the PHP Foundation to get patched PHP versions into base images for Laravel Cloud, Forge, and Vapor quickly, but redeployment may be needed to pick up the fix. The team is also building a way to silently patch applications without requiring a redeploy. _Teams planning deployment steps around urgent PHP patches can keep tabs on Laravel platform updates via daily.dev._ ### How should I prepare my infrastructure for an upcoming critical PHP security patch? Clear time around the release window and know exactly how your PHP version gets deployed, whether through a managed platform image, a container, or a server package, so you can apply the patch quickly once it's available. This preparation matters most right as a patched build becomes available. _Ops teams prepping for emergency PHP patch rollouts can track deployment advice through daily.dev._ ## Community take How the wider developer community reacted, aggregated from 12 discussions and 1165 comments across hackernews (as of 2026-10-27). **TL;DR:** Updated PHP version released to GitHub: Discussion centers less on the PHP patch itself and more on the chaotic, drawn-out coordinated disclosure process involving Wiz, Calif, and OpenAI, with frustration over delayed distro/Docker packages and suspicion the disclosure was partly a PR/marketing exercise. Today's PHP Security Release, and How We're Strengthening PHP Security: Discussion is dominated by outrage over Chainguard breaking the coordinated disclosure embargo by publishing patched images early, with a smaller but vocal minority defending the move given apparent in-the-wild exploitation, plus a side-drama over a security firm's unprofessional 'dancing anime girl' proof-of-concept video that may have triggered the chaos. There isn't an easy exploit for this PHP vulnerability: Reactions are split: some agree the vulnerability is harder to weaponize than the panic suggested and blame sensationalized disclosure/marketing, while many push back hard, citing vendor writeups showing real RCE, legacy servers at risk, and AI accelerating exploit development. **Sentiment:** 8% positive · 30% mixed · 62% skeptical **The case for** - Some argue coordinated, embargoed disclosure (even if slow) was still better than an uncontrolled leak or a disruptive fork-and-patch approach. - Some argue Chainguard did the right thing by shipping a fix quickly once exploitation appeared to be happening in the wild rather than waiting for a coordinated marketing moment. - Several agree the panic was overblown and driven by rumor, Twitter PoC claims, and a chaotic disclosure window rather than an actual working exploit. - Some argue finding and responsibly reporting a critical vulnerability is inherently good regardless of motive. - Some see value in AI agents surfacing long-dormant, complex memory-safety bugs that human review missed for decades. **The pushback** - Many suspect the disclosure was timed and framed as a PR/marketing stunt for OpenAI and the involved security vendors. - Many feel Chainguard unilaterally broke trust and should no longer be given embargoed advance access. - Multiple commenters cite vendor reports (Wiz, Calif, the PHP Foundation) claiming real unauthenticated RCE against default configurations, contradicting the post's thesis. - Many argue the Calif researcher's own writeup shows deep human domain expertise, not AI, was the key factor in finding the bug, contradicting OpenAI's framing. - Many are suspicious that a proof-of-concept video leaked before the official disclosure, possibly breaking responsible disclosure. **By community** - hackernews (heated): Heavy debate over whether the disclosure process was mishandled or exploited for publicity, mixed with real frustration over slow distro/Docker rollout and skepticism toward AI-assisted security findings and AI-generated mitigation advice. **Hottest debate:** Updated PHP version released to GitHub: Whether the two-month coordinated disclosure handling by OpenAI, Wiz, and the PHP security team was a responsible process or a self-serving PR stunt that left everyone else scrambling. **Open questions** - Why did official Docker images and several Linux distro packages lag so far behind the disclosed release time despite advance notice? - Was there actually credible evidence of in-the-wild exploitation before Chainguard released its images, or just a chaotic viral video? - Has anyone been successfully breached by this vulnerability before patches were released, or were reported log entries misread? - What exactly is the vulnerability and am I affected, given the marketing-heavy announcement makes this hard to determine? - How exactly did the proof-of-concept video leak before official disclosure, and who was responsible? **Highlights** > > I want to understand how it leaked. I guess a whole lot of people were looped in between September 21 and October 21? Yes. I was at AWS when Spectre and Meltdown were discovered, and we received approximately a month of advance notice and put together teams to apply mitigations. The work of the team was on a need-to-know basis--even team members' managers only knew they were pulled onto a critical project, not what the specific project was. But there were still 30+ people in the company who knew, and that was just one company (I'm guessing Google/Azure/other cloud providers got similar advance notice). Now, this is a much wider scale vulnerability, in the sense that Spectre/Meltdown primarily impacted cloud providers, but this attack impacts literally anyone who runs PHP. Dozens, if not hundreds, of companies likely got advance notice that a patch needed to be installed. In those companies there are teams of people applying those patches. All it takes is one of them who wants 15 minutes of internet fame to leak the details. > — [mjr00 on hackernews · 1 comments](https://news.ycombinator.com/item?id=50181705) > > It was the best I could do. Honestly, and not to be harsh, but doing absolutely nothing is better than what you've done here. Not only is this proxy unlikely to actually protect against the issues, but this code almost certainly has its own, equally bad security vulnerabilities. A 30 second check with Opus 5.5 found at least one heap overflow, multiple memory leaks, and a number of bugs that shows that it doesn't even succeed at doing what it claims. I appreciate that you're trying to help, but there are better tools for the approach that you're going for here, and injecting noise with AI slop that isn't even reviewed at a basic level is causing noise, confusion, and potential harm in an already urgent, tense situation. > — [mirashii on hackernews](https://news.ycombinator.com/item?id=50182890) > > Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications. And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE. > — [chinathrow on hackernews · 4 comments](https://news.ycombinator.com/item?id=50181226) > > So why was everyone so scared? I think this section misses the mark. The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer. Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked". So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do? We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?" So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires. This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad. > — [Tadpole9181 on hackernews · 4 comments](https://news.ycombinator.com/item?id=50189461) > > Stop using memory-unsafe languages for anything If you bother to check, you'll eventually notice that even "memory-safe languages" have accumulated a good share of CVEs, inclusive for memory safety issues. Check out RustSec. > — [locknitpicker on hackernews](https://news.ycombinator.com/item?id=50191784) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50180873) · 427 points · 230 comments - [hackernews](https://news.ycombinator.com/item?id=50182987) · 241 points · 148 comments - [hackernews](https://news.ycombinator.com/item?id=50188948) · 236 points · 132 comments - [hackernews](https://news.ycombinator.com/item?id=50181175) · 187 points · 127 comments - [hackernews](https://news.ycombinator.com/item?id=50180836) · 305 points · 114 comments - [hackernews](https://news.ycombinator.com/item?id=50194070) · 222 points · 90 comments - [hackernews](https://news.ycombinator.com/item?id=50179828) · 242 points · 89 comments - [hackernews](https://news.ycombinator.com/item?id=50259343) · 178 points · 60 comments - [hackernews](https://news.ycombinator.com/item?id=50172041) · 165 points · 56 comments - [hackernews](https://news.ycombinator.com/item?id=50187708) · 103 points · 52 comments - [hackernews](https://news.ycombinator.com/item?id=50176077) · 146 points · 50 comments - [hackernews](https://news.ycombinator.com/item?id=50181326) · 82 points · 17 comments ## Community discussion Top comments from developers on daily.dev. **@slabb** · 4 upvotes > Check it [https://blog.slabb.dev/en/php2shell-cve-2026-109618-cve-2026-109619-two-critical-rces-in-php-core-lab-demo-and-how-to-fix-38f6](https://blog.slabb.dev/en/php2shell-cve-2026-109618-cve-2026-109619-two-critical-rces-in-php-core-lab-demo-and-how-to-fix-38f6) > And try it: [https://github.com/slabbdev/php2shell-cve-2026-109618-109619](https://github.com/slabbdev/php2shell-cve-2026-109618-109619) **@diyweb** · 3 upvotes > For anyone running many sites, the painful part is not the patch, it is knowing which site is on which PHP version. Build an inventory first, patch internet-facing ones, then verify with a version check and watch error logs afterward. At DiyWeb we think about this a lot, since managing hosting for multiple websites in one place makes this kind of emergency far less chaotic. **@20shamza** · 2 upvotes > The detail that keeps getting lost: these flaws sat in PHP core for years and were surfaced with AI help (OpenAI's Patch the Planet audit, and Wiz independently), then the disclosure leaked a day early and Cloudflare was already seeing live attacks hours before the patches shipped. If you run PHP, the only real fix is updating: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. Full timeline and breakdown: https://daily.dev/posts/two-critical-php-flaws-sat-in-the-codebase-for-over-a-decade-ai-models-helped-researchers-find-them-vbjhhxxex **@renis** · 2 upvotes > I’m in the middle of lunch, and then I get this news. **@pdfopsdev** · 2 upvotes > worth noting opcache will happily keep serving the old bytecode after you deploy the patch if you don't bust the cache or restart php-fpm. seen that bite people on 'silent' hotfixes before, the files change but the running process doesn't notice. ## Similar posts on daily.dev - [PHP2Shell: Why One PHP Vulnerability Put Much of the Web on Emergency Patch Mode](https://daily.dev/posts/php2shell-why-one-php-vulnerability-put-much-of-the-web-on-emergency-patch-mode-gllstobba) · Medium · 0 upvotes · 0 comments - [Websites offline. The internet is on fire. Obviously, we were unprepared.](https://daily.dev/posts/websites-offline-the-internet-is-on-fire-obviously-we-were-unprepared--hv1iepv7z) · Medium · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#php](https://daily.dev/tags/php), [#laravel](https://daily.dev/tags/laravel) [View this post on daily.dev](https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Critical PHP security update due October 21 at 14:00 UTC","url":"https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0"},"datePublished":"2026-10-20T22:04:45.644Z","dateModified":"2026-10-27T23:05:56.884Z","description":"PHP's security team is releasing a high-stakes security update at 14:00 UTC on October 21. Anyone running PHP should plan to upgrade as soon as the patch...","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":7,"discussionUrl":"https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":64},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":7}],"keywords":"security,php,laravel","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"Critical PHP security update due October 21 at 14:00 UTC"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0","comment":[{"@type":"Comment","text":"Check it https://blog.slabb.dev/en/php2shell-cve-2026-109618-cve-2026-109619-two-critical-rces-in-php-core-lab-demo-and-how-to-fix-38f6\nAnd try it: https://github.com/slabbdev/php2shell-cve-2026-109618-109619","datePublished":"2026-10-21T12:03:54.574Z","url":"https://daily.dev/posts/57hO7AcC0#c-qtzdEc0I8","author":{"@type":"Person","name":"Sam LABBE","url":"https://daily.dev/slabb","image":"https://media.daily.dev/image/upload/s--4py3ZbO9--/f_auto/v1791845430/avatars/avatar_iqt7ahbrSNRmJmpeNy6AK?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"For anyone running many sites, the painful part is not the patch, it is knowing which site is on which PHP version. Build an inventory first, patch internet-facing ones, then verify with a version check and watch error logs afterward. At DiyWeb we think about this a lot, since managing hosting for multiple websites in one place makes this kind of emergency far less chaotic.","datePublished":"2026-10-21T17:55:21.282Z","url":"https://daily.dev/posts/57hO7AcC0#c-9AFHxciEC","author":{"@type":"Person","name":"DiyWeb","url":"https://daily.dev/diyweb","image":"https://media.daily.dev/image/upload/s--dgS6jDeN--/f_auto/v1790879420/avatars/avatar_774zDwMaRTNS1fv5OKStX?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"The detail that keeps getting lost: these flaws sat in PHP core for years and were surfaced with AI help (OpenAI’s Patch the Planet audit, and Wiz independently), then the disclosure leaked a day early and Cloudflare was already seeing live attacks hours before the patches shipped. If you run PHP, the only real fix is updating: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. Full timeline and breakdown: https://daily.dev/posts/two-critical-php-flaws-sat-in-the-codebase-for-over-a-decade-ai-models-helped-researchers-find-them-vbjhhxxex","datePublished":"2026-10-22T05:57:18.808Z","url":"https://daily.dev/posts/57hO7AcC0#c-HsselO4vD","author":{"@type":"Person","name":"SYED ALI HAMZA SHAH","url":"https://daily.dev/20shamza","image":"https://media.daily.dev/image/upload/s--xFbf_iCR--/f_auto,pg_1/v1792572201/avatars/avatar_t2yMfuITgxEkFcLSMUMan?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"I’m in the middle of lunch, and then I get this news.","datePublished":"2026-10-21T17:56:02.382Z","url":"https://daily.dev/posts/57hO7AcC0#c-z1k3UWQ14","author":{"@type":"Person","name":"Renis","url":"https://daily.dev/renis","image":"https://lh3.googleusercontent.com/a-/AOh14GibUeLAAy830VlX3NrKw0ySJNoswHch55m79hYL7w=s100"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"worth noting opcache will happily keep serving the old bytecode after you deploy the patch if you don’t bust the cache or restart php-fpm. seen that bite people on ‘silent’ hotfixes before, the files change but the running process doesn’t notice.","datePublished":"2026-10-21T18:01:10.462Z","url":"https://daily.dev/posts/57hO7AcC0#c-hKoGTAEzw","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/critical-php-security-update-due-october-21-at-14-00-utc-57ho7acc0#faq","mainEntity":[{"@type":"Question","name":"When is the critical PHP security update being released?","acceptedAnswer":{"@type":"Answer","text":"The PHP security team is releasing it at 14:00 UTC on October 21. Anyone running PHP in any environment should plan to upgrade as soon as the release lands, since it addresses a high-stakes security issue. Developers tracking the PHP patch window can follow release updates on daily.dev as the deadline nears."}},{"@type":"Question","name":"Will I need to redeploy my Laravel app after the October PHP security patch?","acceptedAnswer":{"@type":"Answer","text":"Possibly. The Laravel team is working with the PHP Foundation to get patched PHP versions into base images for Laravel Cloud, Forge, and Vapor quickly, but redeployment may be needed to pick up the fix. The team is also building a way to silently patch applications without requiring a redeploy. Teams planning deployment steps around urgent PHP patches can keep tabs on Laravel platform updates via daily.dev."}},{"@type":"Question","name":"How should I prepare my infrastructure for an upcoming critical PHP security patch?","acceptedAnswer":{"@type":"Answer","text":"Clear time around the release window and know exactly how your PHP version gets deployed, whether through a managed platform image, a container, or a server package, so you can apply the patch quickly once it's available. This preparation matters most right as a patched build becomes available. Ops teams prepping for emergency PHP patch rollouts can track deployment advice through daily.dev."}}]} ```