--- title: Cloudflare deploys protections against php2shell... description: Cloudflare has deployed default WAF rules protecting customers against two newly disclosed PHP vulnerabilities dubbed php2shell, CVE-2026-109618 and... canonical: https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Cloudflare deploys protections against php2shell vulnerability | daily.dev og:description: Cloudflare has deployed default WAF rules protecting customers against two newly disclosed PHP vulnerabilities dubbed php2shell, CVE-2026-109618 and... og:url: https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao og:image: https://api.daily.dev/og/posts/uG5ifucAO.png og:image:alt: Cloudflare deploys protections against php2shell vulnerability 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. # Cloudflare deploys protections against php2shell vulnerability **[Cloudflare](https://daily.dev/sources/cloudflare)** · 6 min read · 0 upvotes · 0 comments ## Summary Cloudflare has deployed default WAF rules protecting customers against two newly disclosed PHP vulnerabilities dubbed php2shell, CVE-2026-109618 and CVE-2026-109619. The flaws affect all web servers running PHP 5.4 or later and can allow denial of service, remote code execution, and data exposure. Cloudflare says protections went live at 3:02 am UTC on October 21, about 9 hours before public disclosure, after the vulnerability leaked early and attackers began probing. The protections rely on a new 'full transaction detection' capability that inspects both request and response data to block malicious origin responses. PHP powers almost 70% of websites, and Cloudflare still urges admins to patch PHP itself since the WAF rules are only a defense-in-depth layer. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the php2shell vulnerability in PHP and which versions are affected? php2shell refers to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting all web servers running PHP 5.4 or later. They stem from unsafe memory handling when PHP processing is interrupted by errors, such as running out of memory, allowing attackers to send crafted HTTP requests that can cause denial of service, remote code execution, or exposure of sensitive data. _Teams tracking PHP runtime CVEs and patch timelines can follow coverage like this on daily.dev._ ### Does a web application firewall fully protect against the php2shell PHP CVEs without patching? No, WAF rules are only a defense-in-depth layer; since the flaws live in the PHP runtime itself, administrators must update the PHP software running their applications, not just application code or plugins. Cloudflare recommends keeping WAF protections enabled while applying the vendor PHP update as soon as possible. _Developers weighing mitigation versus patching strategy can keep up with PHP security advisories via daily.dev._ ### How did Cloudflare detect exploit attempts for the php2shell PHP vulnerabilities without high false positives? Cloudflare built 'full transaction detection,' a new WAF capability combining signals from both the HTTP request and the origin's response within the same transaction. This lets a response rule block a matching malicious origin response before it reaches the requester, since request data alone often can't distinguish an exploit attempt from legitimate traffic. _Engineers evaluating WAF detection techniques for runtime exploits can track approaches like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 17 comments across hackernews (as of 2026-10-22). **TL;DR:** Discussion mostly veers away from Cloudflare's response itself into a broader debate about memory-unsafe languages, AI-assisted exploitation, and who bears liability for insecure software, with some direct praise for the speed of the mitigation. **Sentiment:** 20% positive · 55% mixed · 25% skeptical **The case for** - Several commenters praised how quickly the protections were deployed ahead of public disclosure. - Some argued software liability and stricter engineering standards (e.g., formal verification, memory-safe languages) could reduce future incidents. **The pushback** - Some pushed back that even memory-safe languages still accumulate CVEs, undercutting calls to simply avoid memory-unsafe languages. - Concern that open-weight LLMs capable of end-to-end exploitation could further concentrate power among a few large infrastructure gatekeepers. - One commenter noted the attacker-defender asymmetry means successful attacks are inevitable regardless of mitigations. **By community** - hackernews (mixed): Praise for the fast WAF rollout is present but is overshadowed by a long tangential debate about memory safety, liability, and AI-driven exploitation risks. **Hottest debate:** Whether the real fix is holding software makers liable for insecurity (as with physical products) versus the practicality/feasibility of mandating memory-safe or formally verified languages. **Open questions** - How should liability for insecure software be structured without stalling the pace of development? - What realistic mitigations exist against AI-assisted, large-scale exploitation of vulnerabilities like this one? **Highlights** > Thank you cloudflare. This single action would save millions of websites from getting pwnd > — [CrimsonRain on hackernews](https://news.ycombinator.com/item?id=50184974) > Stop using memory-unsafe languages for anything unless a formal proof of safety is produced, only use OSes with strong sandboxing mechanism, make sure every piece of software is being sandboxed, etc. Or even just: “make the software authors liable of criminal negligence if an exploit occurs and they cannot demonstrate that they did everything possible to avoid it”. It would indeed have slowed down the field immensely, but we would have avoided the chaos that is ahead of us right now. And that sounds crazy compared to the standard we're used to, but what's crazy is that if your coffee machine explodes and harm you the makers are liable, but if your coffee machine is part of a botnet that disrupts a critical infrastructure, causing the death of people, then somehow the coffee machine maker faces literally no liability for not securing their IoT crap. > — [stymaar on hackernews · 2 comments](https://news.ycombinator.com/item?id=50184985) > But scripts written in PHP are themselves memory-safe. The problem here isn't in a particular PHP script, but rather in the underlying implementation of the PHP runtime, which was written in a memory-unsafe language. If that's your standard, then Python isn't a memory-safe language either, since CPython is partially written in C. Same as many other memory-safe languages like Ruby, anything in the .NET ecosystem... > — [solatic on hackernews · 1 comments](https://news.ycombinator.com/item?id=50185123) > > 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) > As big a fan of open software as I am, the combinations of open-weight LLM models that are capable of e2e cyber-penetration (even by actors that might just put in the compute and prompt it: "make me money") and the current mitigations that let those entities, that already hold too much data and power (political, infrastructure, etc), expand to become the eventual gatekeepers of the "open internet", is highly worrisome. If you have ideas for how we can adjust to this safely and with an eventual more equal distribution of power, please do share. > — [mentalgear on hackernews · 2 comments](https://news.ycombinator.com/item?id=50183262) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50181326) · 82 points · 17 comments ## Similar posts on daily.dev - [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 - [CISA confirms PHP2Shell under attack as researchers clock successful exploits](https://daily.dev/posts/cisa-confirms-php2shell-under-attack-as-researchers-clock-successful-exploits-lrlask0g2) · The Register · 0 upvotes · 0 comments - [PHP2Shell Shows Why Security Cannot Stop at the Last Test](https://daily.dev/posts/php2shell-shows-why-security-cannot-stop-at-the-last-test-kibbq2lgf) · Medium · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#php](https://daily.dev/tags/php), [#cloudflare](https://daily.dev/tags/cloudflare) [View this post on daily.dev](https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao) ```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":"Cloudflare deploys protections against php2shell vulnerability","url":"https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao"},"datePublished":"2026-10-21T14:00:21.874Z","dateModified":"2026-10-22T06:31:07.629Z","description":"Cloudflare has deployed default WAF rules protecting customers against two newly disclosed PHP vulnerabilities dubbed php2shell, CVE-2026-109618 and...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3b73e5c83c7934fdb5af94f73190df52?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3b73e5c83c7934fdb5af94f73190df52?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Cloudflare","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":"Cloudflare","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/38522e1d11354cd6b7af66f9d4316735","url":"https://daily.dev/sources/cloudflare"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,php,cloudflare","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Cloudflare","item":"https://daily.dev/sources/cloudflare"},{"@type":"ListItem","position":3,"name":"Cloudflare deploys protections against php2shell vulnerability"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/cloudflare-deploys-protections-against-php2shell-vulnerability-ug5ifucao#faq","mainEntity":[{"@type":"Question","name":"What is the php2shell vulnerability in PHP and which versions are affected?","acceptedAnswer":{"@type":"Answer","text":"php2shell refers to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting all web servers running PHP 5.4 or later. They stem from unsafe memory handling when PHP processing is interrupted by errors, such as running out of memory, allowing attackers to send crafted HTTP requests that can cause denial of service, remote code execution, or exposure of sensitive data. Teams tracking PHP runtime CVEs and patch timelines can follow coverage like this on daily.dev."}},{"@type":"Question","name":"Does a web application firewall fully protect against the php2shell PHP CVEs without patching?","acceptedAnswer":{"@type":"Answer","text":"No, WAF rules are only a defense-in-depth layer; since the flaws live in the PHP runtime itself, administrators must update the PHP software running their applications, not just application code or plugins. Cloudflare recommends keeping WAF protections enabled while applying the vendor PHP update as soon as possible. Developers weighing mitigation versus patching strategy can keep up with PHP security advisories via daily.dev."}},{"@type":"Question","name":"How did Cloudflare detect exploit attempts for the php2shell PHP vulnerabilities without high false positives?","acceptedAnswer":{"@type":"Answer","text":"Cloudflare built 'full transaction detection,' a new WAF capability combining signals from both the HTTP request and the origin's response within the same transaction. This lets a response rule block a matching malicious origin response before it reaches the requester, since request data alone often can't distinguish an exploit attempt from legitimate traffic. Engineers evaluating WAF detection techniques for runtime exploits can track approaches like this on daily.dev."}}]} ```