PHP2Shell Exposed a Decade of PHP Releases. What Headless Architecture Changes for Enterprise Risk.

• What is PHP2Shell, and is your site affected?
• What should you do in the next 72 hours if you run large PHP sites?
• Why does a flaw in the language runtime matter more than a plugin flaw?
• What is React2Shell, and does it weaken the case for headless?
• Does headless architecture reduce exposure to flaws like these?
• What happened after Drupalgeddon 2 and Log4Shell?
• How fast will attackers move now that AI helps write exploits?
• How can a CMO audit a web estate's exposure in five working days?
• When is it time to plan a modernization, and when is patching enough?
• What should each executive do first?
• How we built this analysis
• Frequently asked questions
• Sources

What is PHP2Shell, and is your site affected?

Any site that serves web requests on an unpatched PHP runtime is in scope for PHP2Shell, whether it runs WordPress, Drupal, Joomla or custom code, and the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, shipped by the PHP project on 21 October 2026.

PHP2Shell is two flaws, CVE-2026-109618 and CVE-2026-109619. The PHP project's own security advisory rates the severity "Critical 9.2", and Qualys Threat Research describes vulnerabilities "that can allow unauthenticated remote code execution on PHP installations serving web requests."

The flaw sits in the language, not the CMS. Wiz Research writes: "Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4." Wiz also "demonstrated that it could execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest)".

Two figures give the scale. W3Techs reports that "PHP is used by 69.2% of all the websites whose server-side programming language we know" (read 27 October 2026). Palo Alto Networks Unit 42 counts "over 22.6 million exposed instances potentially vulnerable" in its own telemetry, a vendor figure for possible exposure, not confirmed compromise.

Amazon Threat Intelligence identified an exploitation attempt dated 17 October 2026, four days before disclosure, and adds that "it's unclear if any of these attempts would have succeeded in real-world systems." Unit 42 has retracted an earlier attribution of initial access to these CVEs. As of 27 October, our sources document attempts, not confirmed successful exploitation.

What should you do in the next 72 hours if you run large PHP sites?

In the next 72 hours, confirm that a patched PHP runtime is serving live traffic on every property you own, because CMS and plugin updates do not fix PHP2Shell, then review logs from 17 October 2026 and rotate credentials wherever the single rule below applies.

1. Patch the runtime, then verify it. The Vercel Security Team is direct: "Updating your application code or plugins does not fix these vulnerabilities." Confirm that 8.5.12, 8.4.27, 8.3.36 or 8.2.35 answers production requests on every property, including microsites and campaign sites.
2. Treat firewall rules as a bridge. Vercel says its WAF rules "reduce exposure to known exploit patterns, but do not replace patching."
3. Investigate from 17 October. Amazon's guidance reads: "For PHP2Shell, investigate from at least starting on October 17th."
4. Rotate credentials by one rule. Wiz notes that the exposed memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself." We apply one rule throughout this post (Dotfusion judgment). Rotate credentials on any host not patched within 24 hours of the 21 October release, and on any host showing suspicious activity from 17 October onward, whatever its patch time.

Why does a flaw in the language runtime matter more than a plugin flaw?

A runtime flaw matters more than a plugin flaw because, in the PHP project's own words of 21 October 2026, the attack can trigger "before any application code runs", so the CMS's own hardening does not help and the fix rests with whoever controls the runtime.

The PHP project puts it plainly: "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." Security plugins, CMS permissions and hardened themes all live in application code, so none of them stand between the request and the flaw.

A plugin flaw waits on the vendor's update. A runtime flaw waits on whoever controls PHP on the server: an internal infrastructure team, a managed host or a cloud customer. Google Cloud drew that line clearly: "While Google Cloud itself is not vulnerable, users of PHP running on Google Cloud may be vulnerable."

The PHP project deserves credit for the response. Wiz reported the flaws on 24 August 2026, and patched releases for four supported branches shipped on 21 October through coordinated disclosure. The PHP Foundation notes that "security work on PHP itself still depends on a small group of foundation-funded developers and a little volunteer help."

What is React2Shell, and does it weaken the case for headless?

React2Shell strengthens this post's architectural argument rather than weakening it: the flaw (CVE-2025-55182, CVSS 10.0, disclosed 3 December 2025) let an unauthenticated request run code on servers using React Server Components, and React's own advisory put apps whose code used no server outside scope.

The React team wrote: "There is an unauthenticated remote code execution vulnerability in React Server Components." Within hours of disclosure, Amazon "observed active exploitation attempts by multiple China state-nexus threat groups".

Next.js confirmed that "Applications using React Server Components with the App Router are affected when running: Next.js 15.x Next.js 16.x", and that "Next.js 13.x, Next.js 14.x stable, Pages Router applications, and the Edge Runtime are not affected." It told exposed teams to rotate the secrets their applications use.

The scoping line is what matters for architecture. React's advisory says: "If your app's React code does not use a server, your app is not affected by this vulnerability." Google Cloud described the same boundary, with exposure arising "when used for some server-side use cases." Front ends whose React code ran without a server sat outside scope, and those running React Server Components needed a named owner able to patch within hours.

Exhibit 1. Neither flaw needed a login; scope followed what ran on the server

	PHP2Shell	React2Shell
Disclosed	21 Oct 2026	3 Dec 2025
Layer affected	PHP engine	React Server Components
Severity	CVSS v4.0 9.2	CVSS 10.0
Login required	No	No
Earliest observed activity	Attempt on 17 Oct 2026; success unconfirmed	Exploitation attempts within hours of disclosure
Not affected	Sites not running PHP	React apps with no server; Next.js Pages Router, Edge Runtime, 13.x, 14.x stable

Source: PHP project, 21 Oct 2026; PHP security advisory GHSA-w8hw-w9fx-j79w, 21 Oct 2026; AWS Security Blog, 21 Oct 2026; React team, 3 Dec 2025; Next.js, 3 Dec 2025; AWS Security Blog, Dec 2025. All read 27 Oct 2026.

Does headless architecture reduce exposure to flaws like these?

Headless architecture reduces exposure when it removes code from the public path: a SaaS headless CMS with a read only delivery API and a prebuilt front end leaves less running code on the internet and moves CMS patching to the vendor, though the front end still needs a named patch owner.

Less code on the public path. A Next.js site can be exported as static files. The Next.js documentation says such an export "can be deployed and hosted on any web server that can serve HTML/CSS/JS static assets." The trade off: "Features that require a Node.js server, or dynamic logic that cannot be computed during the build process, are not supported".

Read only content access. In a self hosted PHP CMS, the public site and the CMS, with its credentials, run on the same server (Dotfusion analysis). With a SaaS headless CMS, the public site reads content through a delivery API. Contentful's documentation describes its Content Delivery API as "a read-only API for delivering content from Contentful to apps, websites and other media."

The CMS vendor patches the CMS. In a SaaS model the vendor operates the platform, so CMS patching leaves your team's list. Storyblok, for example, commits to "Continuous scanning, automated dependency updates, and proactive patching of security risks." This is the same shared responsibility line Google Cloud drew for PHP2Shell.

Independent security attestations give buyers a way to check a vendor's controls. Contentful lists ISO/IEC 27001 certification, SOC 2 Type 2, SOC 3, PCI DSS SAQ A and TISAX. Agility CMS states that "Agility is SOC 2 Type 2 Compliant" and "Our infrastructure runs on Microsoft Azure".

Two limits keep the claim accurate. A headless WordPress or decoupled Drupal back end still runs PHP, and the runtime patch in Vercel's bulletin applies to it in full. A server rendered front end, as React2Shell showed, carries its own runtime risk. Headless narrows exposure and moves responsibility; no architecture makes a site immune.

We favour this model because each runtime flaw like PHP2Shell falls on fewer layers your team owns, while the duty to patch what remains stays with you. Our headless versus traditional CMS ROI guide covers the business case.

Exhibit 2. Architecture decides who carries each patch

	Self hosted PHP CMS	Headless SaaS CMS, server rendered front end	Headless SaaS CMS, prebuilt (static) front end
What answers public requests	PHP runtime plus CMS	JavaScript server plus front end code	Static files on a web server or CDN
Exposed to PHP2Shell	Yes, if unpatched	No PHP runtime on your public path when the CMS is SaaS	No
Exposed to React2Shell	No	Yes, if using affected server features	Not affected by React2Shell (React: no server)
Who patches the CMS	Your team or host	CMS vendor	CMS vendor
Content access from the public site	CMS and its credentials on the same server	Read only delivery API (for example, Contentful CDA)	Read only API at build time
Trade off	Full server features	Front end patch owner required	Server features unsupported

Source: Vercel, 21 Oct 2026; React team, 3 Dec 2025; Next.js, 3 Dec 2025; Next.js Docs; Contentful Docs; Storyblok; Dotfusion analysis. All read 27 Oct 2026.

What happened after Drupalgeddon 2 and Log4Shell?

After Drupalgeddon 2 (March 2018) and Log4Shell (December 2021), the risk outlasted the first patch: Drupal issued a second remote code execution fix four weeks later, both Drupal flaws were exploited in the wild, and 2.8% of scanned applications still ran Log4Shell versions about two years after disclosure.

Drupalgeddon 2. The Drupal Security Team rated SA-CORE-2018-002 "Highly critical" on 28 March 2018, warning that it "could result in the site being completely compromised." According to BleepingComputer, "Hackers started exploiting the Drupalgeddon 2 vulnerability only two weeks after patches came out". On 25 April 2018 the team published SA-CORE-2018-004, a highly critical remote code execution advisory, and wrote: "Both SA-CORE-2018-002 and this vulnerability are being exploited in the wild."

By early June 2018, researcher Troy Mursch, as reported by BleepingComputer, had identified 115,070 sites running an outdated Drupal 7 version vulnerable to CVE-2018-7600.

Log4Shell. Log4Shell was disclosed on 9 December 2021 (Veracode). Seven months later, the US Cyber Safety Review Board called Log4j an "endemic vulnerability" and wrote that "vulnerable instances will remain in systems for many years, perhaps a decade or more." About two years on, Veracode, a security vendor, found that "2.8 percent of applications are still using versions of Log4j with the Log4Shell vulnerabilities" and that 38% used some vulnerable version of Log4j.

React2Shell. Exploitation attempts began within hours of the 3 December 2025 disclosure. The React team then published follow on advisories for two denial of service flaws (CVSS 7.5) and a source code exposure flaw (CVSS 5.3), and on 26 January 2026 a further high severity denial of service flaw (CVE-2026-23864, CVSS 7.5). About eleven months after React2Shell, PHP2Shell arrived on a different stack.

Our sources hold no 12 month figure for any of the three events, so we leave those cells empty rather than estimate. Across these three events, time to first exploitation fell from about two weeks in 2018 to hours in 2025 to a recorded attempt before disclosure in 2026, while the unpatched tail stays measured in years.

Exhibit 3. The long tail outlasts the headlines

Event	Disclosed	First exploitation	About 1 to 2 months	About 7 months	About 24 months
Drupalgeddon 2	28 Mar 2018	About 2 weeks after patch	Follow on RCE fix 25 Apr 2018, both exploited; 115,070 Drupal 7 sites unpatched at 2 months (researcher Troy Mursch, as reported by BleepingComputer)	No sourced figure	No sourced figure
Log4Shell	9 Dec 2021	Not stated in our sources	No sourced figure	CSRB: "endemic", "a decade or more"	About two years after Log4Shell (Veracode, December 2023): 2.8% of 38,278 apps on Log4Shell versions; 38% on some vulnerable Log4j
React2Shell	3 Dec 2025	Within hours	Follow on CVEs, latest 26 Jan 2026	No sourced figure	Not yet reached

Source: Drupal Security Team, 28 Mar 2018; Drupal Security Team, 25 Apr 2018; BleepingComputer, 5 Jun 2018; Cyber Safety Review Board, 11 Jul 2022; Veracode, 7 Dec 2023 (Log4Shell disclosure date and two year figures); React team, updated 26 Jan 2026; AWS Security Blog, Dec 2025. All read 27 Oct 2026.

How fast will attackers move now that AI helps write exploits?

Attackers now move in hours: Wiz says one researcher using frontier AI models did in a week what once took a world class team months, and Amazon tells security teams to measure patch timelines for critical internet facing flaws in hours, against about two weeks to first exploitation in 2018.

Wiz Research writes: "With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work." The PHP Foundation expects the volume to keep rising: "Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing."

We plan around three scenarios. The time ranges come from the sources cited; the boundaries between scenarios are Dotfusion judgment. Every scenario uses the same rotation rule. Rotate credentials on any host not patched within 24 hours of the 21 October release, and on any host showing suspicious activity from 17 October onward, whatever its patch time.

• Scenario A: Patched in hours. The host runs a supported branch and was patched within 24 hours of 21 October. Review logs for 17 to 21 October, when Amazon recorded an attempt, and rotate credentials if that review shows suspicious activity.
• Scenario B: Patched in days to four weeks. Every patch in this window sits far past the hours Amazon now expects (AWS), and a patch after about two weeks also sits past the time it took exploitation to begin after the 2018 Drupal patch (BleepingComputer). Treat the host as exposed: review its logs from 17 October and rotate its credentials, as Next.js advised for unpatched apps after React2Shell.
• Scenario C: Unsupported or still unpatched. PHP 8.1 and earlier receive no regular upstream fixes (Vercel), and at least 34.4% of PHP sites run major versions 7, 5 or 4 (our sum of W3Techs shares). For any host still unpatched on 27 October, patch now, review logs from 17 October and rotate credentials. For unsupported branches, the options are an LTS vendor backport, an upgrade to a supported branch, or a replatform.

How can a CMO audit a web estate's exposure in five working days?

A CMO can audit a web estate's PHP2Shell exposure in five working days with six checks run alongside the web team: inventory, runtime version, patch owner and speed, verified serving runtime, exposure window review, and support runway, each with a pass condition from a source or labelled as Dotfusion judgment.

Every check is a question the CMO asks and the web team, host or agency answers with evidence.

Exhibit 4. Five day audit scorecard shows where each property stands

Check	Question for the web team	Pass condition	Basis
1. Inventory	List every public site and microsite, with its owner, platform and host.	A complete list	Dotfusion judgment
2. Runtime version	Which PHP branch runs each property?	PHP 8.2 or later, on 8.2.35, 8.3.36, 8.4.27 or 8.5.12	PHP project; supported versions
3. Patch owner and speed	Who applies runtime patches, and at what date and hour did the PHP2Shell fix land?	Within hours of 21 October 2026	AWS
4. Verified serving runtime	Is the patched runtime answering production traffic, beyond staging or plugin updates?	Confirmed on production	Vercel
5. Exposure window review	Were logs reviewed from 17 October, and were credentials rotated under the rotation rule?	Both done	AWS; Wiz; rotation rule is Dotfusion judgment
6. Support runway	How many months until the branch's security support ends?	12 months or more (threshold is Dotfusion judgment)	PHP project: 8.2 ends 31 Dec 2026; 8.3 ends 31 Dec 2027

Source: PHP project, AWS Security Blog, Vercel and Wiz Research as linked, all read 27 Oct 2026; thresholds marked Dotfusion judgment are ours.

Read the scorecard by one rule (Dotfusion judgment). A fail on checks 2 to 5 means fix now, using the 72 hour steps above. A fail on check 6 means a modernization decision is due. A fail on check 3 also counts as a modernization trigger. A property on PHP 8.2 passes check 2 today and fails check 6, because its security support ends on 31 December 2026.

When is it time to plan a modernization, and when is patching enough?

Patching in place is enough when a property runs PHP 8.3 or later, the PHP2Shell fix was applied within hours, one owner patches the runtime and no replatform is planned; any one of five triggers, starting with PHP 8.2's end of security support on 31 December 2026, means a modernization decision is due.

By modernization we mean one of three options: an upgrade to PHP 8.3 or later, LTS cover, or a replatform. The rule that follows is Dotfusion judgment.

Patching in place is right when all four conditions hold: the branch has 12 months or more of security support left (PHP 8.3 or later today, per the PHP project), the PHP2Shell patch was applied within hours, one accountable owner patches the runtime, and no replatform is planned.

A modernization decision is due when any one of these triggers applies:

1. Any property runs PHP 8.1 or earlier, which no longer receives regular updates from the PHP project (Vercel; PHP end of life list).
2. Any property runs PHP 8.2, whose security support ends on 31 December 2026 (PHP supported versions).
3. The PHP2Shell patch took days or weeks rather than the hours Amazon now expects (AWS).
4. Several sites run on different stacks with different patch owners.
5. A redesign or replatform is already budgeted within 12 to 18 months.

When two or more triggers apply, a planning conversation pays for itself, because it sequences runtime upgrades, LTS cover and replatforming against the support dates before those dates set the order for you. Our enterprise guide to WordPress to headless CMS migration, our 2026 headless CMS migration cost benchmarks and the CMS migration checklist are useful preparation.

What should each executive do first?

Each executive has one first action: the CMO commissions the five day audit this week, the CDO puts a modernization decision on every PHP 8.2 or earlier property before 31 December 2026, the CIO opens a compromise review from 17 October, and the COO rewrites the patch SLA in hours.

• CMO: Commission the five day audit this week, with one named owner per property, and ask for the date and hour PHP2Shell was patched on each. Amazon's standard for critical internet facing flaws is hours (AWS).
• CDO: List every property on PHP 8.2 or earlier and put a modernization decision on each (upgrade to PHP 8.3 or later, LTS cover or replatform) into the 2027 roadmap before 31 December 2026, when 8.2 leaves security support (PHP project).
• CIO: Open a compromise review covering 17 October onward for every PHP host, given the memory exposure Wiz describes. Rotate credentials on any host not patched within 24 hours of the 21 October release, and on any host showing suspicious activity from 17 October onward, whatever its patch time.
• COO: Rewrite the web patch SLA for critical internet facing flaws in hours, and confirm that hosting and agency contracts match it. Amazon's view is that "A 7-day or 30-day SLA assumes a delay that no longer exists."

How we built this analysis

This analysis is current as of 27 October 2026 and draws on 26 sources, 23 of them primary, including vendor advisories from PHP, React, Next.js and Drupal, a US government review board, three cloud providers, and four security firms.

Several figures move. W3Techs shares were read on 27 October 2026 and update daily. The "at least 34.4%" figure is our addition of W3Techs' version 7 (26.6%), version 5 (7.7%) and version 4 (0.1%) shares; it leaves out sites on PHP 8.0 and 8.1, which also receive no regular upstream updates. Unit 42's 22.6 million is vendor telemetry of potentially vulnerable instances. AWS says it is unclear whether the observed attempts would have succeeded, and Unit 42 retracted an early attribution, so we describe attempts, not confirmed compromises.

Veracode's Log4j figures come from 38,278 applications at 3,866 organizations, scanned from 15 August to 15 November 2023. The 115,070 Drupal figure comes from researcher Troy Mursch's scan of about 500,000 Drupal 7 sites, as reported by BleepingComputer on 5 June 2018; the original scan publication was blocked when we tried to fetch it. Wiz, Qualys, Unit 42 and Veracode sell security products. The Contentful, Storyblok and Agility CMS pages are vendor statements about their own platforms.

Our bias: Dotfusion builds headless platforms on Contentful (certified partner), Storyblok (Silver partner) and Agility CMS (partner). Where a threshold, trigger or rule is ours rather than a source's, we label it Dotfusion judgment.

Frequently asked questions

Is a headless CMS more secure than WordPress?

Not automatically. A headless CMS delivered as SaaS reduces the code running on your public servers and moves CMS patching to the vendor, and a prebuilt front end narrows exposure further. A headless WordPress back end still runs PHP and needed the PHP2Shell runtime patch of 21 October 2026, and server rendered React front ends were in scope for React2Shell in December 2025. Architecture, more than the label, decides exposure.

What does PHP2Shell mean for my website?

If your website runs on PHP, it needs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 serving live traffic, because the PHP2Shell flaws disclosed on 21 October 2026 sit in PHP itself and CMS or plugin updates do not fix them. Review logs from 17 October 2026, when Amazon recorded an exploitation attempt. Rotate credentials on any host not patched within 24 hours of the 21 October release, and on any host showing suspicious activity from 17 October onward, whatever its patch time (Dotfusion judgment).

Did React and Next.js have a comparable vulnerability?

Yes. React2Shell (CVE-2025-55182), disclosed on 3 December 2025 and rated CVSS 10.0, allowed unauthenticated remote code execution in React Server Components, and Amazon observed exploitation attempts within hours. Next.js App Router applications on 15.x and 16.x were affected; Next.js 13.x, 14.x stable, Pages Router applications and the Edge Runtime were not. React apps whose code did not use a server were not affected.

When should we bring in an agency to plan a migration?

In our judgment, a modernization decision is due when any one of five triggers applies, and a planning conversation pays for itself when two or more apply. The triggers are a property on PHP 8.1 or earlier; a property on PHP 8.2, whose security support ends on 31 December 2026; a PHP2Shell patch that took days or weeks; several sites on different stacks with different patch owners; and a redesign already budgeted within 12 to 18 months. Modernization means an upgrade to PHP 8.3 or later, LTS cover, or a replatform. A property on PHP 8.3 or later, patched within hours by one accountable owner with no replatform planned, can keep patching in place.

Sources

1. PHP project, release announcement for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, 21 Oct 2026. https://www.php.net/archive/2026.php
2. PHP project, php-src security advisory GHSA-w8hw-w9fx-j79w, 21 Oct 2026. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
3. Wiz Research, PHP2Shell, 21 Oct 2026. https://www.wiz.io/blog/php2shell-php-rce
4. Vercel Security Team, PHP2Shell security bulletin, 21 Oct 2026. https://vercel.com/kb/bulletin/php2shell-security-bulletin
5. AWS Security Blog (CJ Moses), PHP2Shell exploitation attempt identified before public disclosure, 21 Oct 2026. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
6. Qualys Threat Research, analysis of the PHP critical security release, 20 Oct 2026. https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities
7. Palo Alto Networks Unit 42, threat brief on CVE-2026-109618 and CVE-2026-109619, updated 25 Oct 2026. https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/
8. Google Cloud Blog, guidance on CVE-2026-109618 and CVE-2026-109619, updated 23 Oct 2026. https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
9. The PHP Foundation, statement on the 21 October security release, 21 Oct 2026. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
10. PHP project, Supported versions, read 27 Oct 2026. https://www.php.net/supported-versions.php
11. PHP project, end of life dates for unsupported branches, read 27 Oct 2026. https://www.php.net/eol.php
12. W3Techs, PHP usage and version share, read 27 Oct 2026. https://w3techs.com/technologies/details/pl-php
13. React team, security advisory on React Server Components (CVE-2025-55182), 3 Dec 2025, updated 26 Jan 2026. https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
14. Next.js, Security advisory CVE-2025-66478, 3 Dec 2025, updated 6 Dec 2025. https://nextjs.org/blog/CVE-2025-66478
15. AWS Security Blog, React2Shell exploitation attempts after disclosure (CVE-2025-55182), Dec 2025, updated 29 Dec 2025. https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/
16. Google Cloud Blog, guidance on CVE-2025-55182, 4 Dec 2025. https://cloud.google.com/blog/products/identity-security/responding-to-cve-2025-55182
17. Next.js Docs, Static exports, read 27 Oct 2026. https://nextjs.org/docs/app/guides/static-exports
18. Drupal Security Team, SA-CORE-2018-002, 28 Mar 2018. https://www.drupal.org/sa-core-2018-002
19. Drupal Security Team, SA-CORE-2018-004, 25 Apr 2018. https://www.drupal.org/sa-core-2018-004
20. Cyber Safety Review Board (CISA), report on Log4j, 11 Jul 2022. https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
21. Contentful, Security, read 27 Oct 2026. https://www.contentful.com/security/
22. Contentful Docs, Content Delivery API, read 27 Oct 2026. https://www.contentful.com/developers/docs/references/content-delivery-api/
23. Storyblok, Security, read 27 Oct 2026. https://www.storyblok.com/security
24. Agility CMS, Security, read 27 Oct 2026. https://agilitycms.com/security
25. BleepingComputer (Catalin Cimpanu), Drupal sites still vulnerable to Drupalgeddon 2 two months on, 5 Jun 2018. https://www.bleepingcomputer.com/news/security/two-months-later-over-115-000-drupal-sites-still-vulnerable-to-drupalgeddon-2/
26. Veracode, state of Log4j vulnerabilities two years after Log4Shell, 7 Dec 2023. https://www.veracode.com/blog/state-of-log4j-vulnerabilities-how-much-did-log4shell-change/

This post was conceived and written by Chris Bryce, CEO of Dotfusion, with our stack of AI research agents doing the heavy lifting on sources and data. If you are weighing what PHP2Shell means for your web estate, or want to talk about enterprise web strategy, AEO or content operations, talk to us. We love this stuff.