PHP2Shell and the case for a simpler web

Why we should question the infrastructure behind a page of text and images

A website that mainly displays text and images should have to justify the complexity behind it. After years of building, hosting and supporting websites, I increasingly think we have that decision backwards. We start with a live content management system, a database and a collection of plugins, then spend years maintaining everything needed to keep a fairly ordinary page online.

PHP2Shell is another reason to reconsider that default. Disclosed on 21 October 2026, it exposes serious weaknesses in PHP itself, beneath the applications that depend on it. Researchers demonstrated attacks against deployments of WordPress, Drupal and Joomla. Keeping the website's own code tidy does not remove a flaw in the runtime underneath it. [1]

For organisations running affected PHP installations, the immediate job is to patch. For everyone deciding what to build next, there is a longer-term question: how much of this machinery does the website actually need?

My answer, for many blogs, portfolios, campaign sites and business information pages, is substantially less. Static publishing can make these sites cheaper to operate, easier to recover and less exposed to entire categories of application vulnerability. The provider delivering those files can still fail. Both truths belong in the same discussion.

What PHP2Shell actually changes

PHP2Shell covers two related vulnerability classes: CVE-2026-109618 and CVE-2026-109619. The first concerns corruption during out-of-memory handling. The second concerns internal state surviving after the memory it refers to has been freed. Under exploitable conditions, PHP can subsequently treat invalid or stale memory as usable data. The consequences can include unauthenticated remote code execution. [2][3]

In ordinary language, the software responsible for running the website can get confused about its own memory in ways an attacker can exploit. A sufficiently successful attack can let someone run code on the affected server. Wiz also demonstrated disclosure of process memory, potentially exposing secrets such as authentication tokens and API keys. These are runtime flaws, rather than a vulnerability in one particular WordPress plugin. [1]

From a web request to a server-side risk

1. 1 · InputA crafted request arrives

   An attacker sends input to a website running an affected PHP version.

2. 2 · Runtime flawPHP mishandles memory

   Memory exhaustion or a stale reference can leave PHP using memory that is no longer valid.

3. 3 · ExploitationThe attacker exploits that state

   If the required conditions line up, the flaw can undermine the running process.

↳Secrets can leak

Process memory may reveal authentication tokens, API keys or other sensitive data.

↳Code can run on the server

A successful code-execution attack runs with the permissions of the affected process.

The configuration matters. PHP's maintainers identify Apache with mod_php as the highest-risk case, with a demonstrated attack that can run before application code starts. Their warning also covers other PHP web deployments, including PHP-FPM. It would be a mistake to assume that choosing a different PHP integration automatically makes a deployment safe. [4]

At publication, the fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distribution and long-term-support vendors may provide corresponding backports. The PHP project says an update is the only complete solution; temporary mitigations address particular paths without eliminating the whole problem. A future migration to static publishing does not replace today's patching work. [4]

There is already evidence of attempts to exploit the flaws. AWS says its honeypots observed PHP2Shell-related attempts on 17 October, before public disclosure. It also cautions that it could not determine whether those attempts would have succeeded against real systems. That distinction matters: observed attack attempts are evidence of urgency, without being proof that every exposed website has been compromised. [5]

Wiz credits AI with helping researchers develop and adapt exploit chains that previously demanded considerable specialist effort. The implication I draw is that complexity is becoming a weaker defence. We should expect more scrutiny of old code, while remembering that the same tools can help maintainers investigate and fix it. [1]

While I was writing this, Node.js joined the patch queue

While writing this article, I also came across a report about another urgent runtime security update. Node.js's 21 October release fixes ten vulnerabilities, including CVE-2026-111497, a high-severity flaw in its Brotli decompression code. The affected supported release lines are Node.js 22, 24 and 26; the fixed releases are 22.23.4, 24.22.1 and 26.12.1. This is a separate vulnerability from PHP2Shell, with its own conditions for exploitation. [6]

Vercel explains that exposure arises when an application or one of its dependencies decompresses Brotli data controlled by an attacker. That data might arrive in a request or in a response fetched from another server. Its bulletin reports demonstrations of memory disclosure and command execution. It also makes an important distinction: filtering incoming requests does not protect the application from every malicious response it might fetch. The runtime still needs updating. [7]

For me, this strengthens the architectural argument. Replacing a live PHP application with a live Node.js application still leaves a runtime to maintain, along with the libraries and services around it. The useful question is which parts of the website need to execute on a server at all.

My own static publishing tools use Node.js, so this is relevant to my build environment too. Static publishing does not excuse me from updating that toolchain. But building an article with Node and then delivering the finished HTML is different from requiring a live Node process to handle every reader's visit. When publication and delivery are separated properly, maintaining the builder need not mean taking the published article offline.

The dependencies behind a simple page

Consider what a conventional CMS deployment can involve. A visitor requests an article. Depending on its caching arrangement, that request may pass through a CDN and web server, invoke PHP, query MySQL or another database, load a theme and plugins, and assemble a response.

Each component can be useful. Collectively, they create obligations: updates, compatibility checks, access controls, backups, capacity planning and recovery procedures. MySQL is a database system; PHP is a programming language and runtime. Both also represent maintained software that an operator depends on.

Caching can reduce how often the application runs, but a reachable origin or administration interface still needs protection. The underlying system does not stop existing because most visitors receive a cached page.

A static publishing workflow moves the assembly work to publication time. It produces the HTML, styles, scripts and media first, then serves those files to readers. Eleventy, for example, builds prerendered pages from templates and content without requiring a browser JavaScript framework. [8]

That distinction changes the work required to read an article. The reader does not need a PHP process to be healthy or a database connection to succeed. If the publishing tools temporarily break, a well-separated delivery system can continue serving the previous successful build.

For a site that changes a few times a week, generating its pages when the content changes is often a sensible trade. The irony is that static pages were part of the web long before modern CMS platforms became commonplace. Today's tooling makes that older architecture much more convenient to author, preview and publish.

How Google Cloud killed (and didn't care about) small business, What losing Siteroo taught me

My concern about dependencies is personal.

Around June 2024, during an unresolved Google Cloud billing dispute, Siteroo lost its Compute Engine infrastructure: the virtual machines running the live site, the snapshot backups and the machine images we would have used to restore it.

I documented the experience publicly. Our usual spend of around $2 to $5 a month had risen to more than $100 over two months. I disputed the charges and opened three support cases. The excess charges were eventually waived, but the Compute Engine resources had been auto-deleted by Google Cloud Platform's auto-deletion policies during the suspension, as I understood and described it at the time. As I described it at the time, the billing account appeared to have been closed and a deletion policy triggered. I was still trying to establish exactly what had happened. [9]

I also recorded that I had seen no prior deletion warning and had been told I would need paid technical support to pursue whether the resources could be restored. Resolving the disputed charges did not bring those resources back. That is my account of the support experience; it was not the same kind of failure as an accidental data-centre outage.

One suggestion in the Reddit discussion particularly stuck with me: “Deletion ought to archive to coldline for a year behind the scenes.” A recoverable cold-storage copy retained for 12 months, with a clear route to restore it once a customer settled the account, would have made an enormous difference to me. That was a commenter’s proposal, not an existing recovery guarantee. But I think it is a reasonable principle: a billing dispute should not so easily become an irreversible loss of someone’s work. [9]

What stayed with me was how little care I felt from a company with Google's resources. The charges could be waived, yet the work itself was still gone. I cannot know what individual employees felt, but the process left me feeling that keeping a small customer's business recoverable simply did not matter enough. UniSuper's very different experience, discussed below, reinforced my concern that even a large organisation cannot treat a provider's scale as a substitute for independent recovery. I have also shared my concerns on Facebook.

There was a revealing difference between the two sites involved. The Cloud Storage objects for my static site survived, and I could bring that site back. The WordPress site's Compute Engine instances, snapshots and machine images did not. Static files had proved much easier to recover in that particular incident. That does not mean a storage bucket is exempt from deletion.

An off-cloud WordPress backup survived too. Its existence saved us from having no copy, but turning it back into a working site became another project. My later restoration post described hours navigating plugin upgrade prompts and upload limits across Nginx, the Bitnami environment, PHP configuration and WordPress. I eventually got the permitted upload size from 80 MB to 900 MB and began importing the backup without the paid upgrade I had been prompted to buy. [10]

That post described an outage lasting more than eight months. The wider recovery was also complicated by my being away and by a domain-expiry problem that affected the registrant email address. It would be misleading to turn all of that elapsed time into a claim about one technical repair. The combination of deletion, support friction and restoration work was the experience that changed my approach.

Google's own documentation warns that prolonged billing-account suspension can result in resources being removed irrecoverably. [11] For me, an open support case had not preserved the production resources or their recovery copies. Administrative processes belonged in my risk assessment alongside software and hardware.

That experience effectively ended my willingness to keep relying on the same arrangement for Siteroo. I had been supporting a long chain of software and infrastructure suppliers to get text and media onto a screen. Even with a surviving backup, restoring that chain was much harder than copying a working set of static files.

I now ask two separate questions: what failure can destroy this backup, and what will I actually need to restore from it?

UniSuper showed why recovery independence matters

The UniSuper incident in 2024 exposed a different route to provider-controlled deletion. The joint statement from UniSuper and Google Cloud described an inadvertent provisioning misconfiguration that led to deletion of a private-cloud subscription. It also said backups involving an additional provider helped reduce data loss and support restoration. [12]

Google's later technical account clarified the scope. The deletion affected one Google Cloud VMware Engine private cloud spanning two zones. It did not delete UniSuper's entire Google account, its other private clouds or its backups stored in Google Cloud Storage. An omitted provisioning parameter had caused the affected environment to receive a fixed term and be deleted when that term expired. [13]

The precise scope matters, especially when early headlines describe an entire account and all backups disappearing. The documented failure is serious enough without enlarging it.

My lesson from it is that redundancy must be assessed against the failure you are trying to survive. Duplicating infrastructure across locations can help with a local outage. It may not help when both copies sit inside the same object that a provider's control system deletes.

There is no requirement for every small business to run an elaborate installation across several clouds. There is a strong reason to know which copies survive the loss of the production environment, and to test whether those copies can actually restore a useful service.

The cloud outages keep coming

The recent Google Cloud outage adds another example. According to Google's preliminary report, its London region suffered disruption on 20 October 2026 lasting six hours and ten minutes. A power interruption was followed by failures in the controls intended to start and connect backup generators. Once battery reserves ran out, infrastructure went offline; failover and capacity pressure then affected other regional services. [14]

Cybernews' coverage of that same London outage brought the consequences closer to everyday life: Revolut customers experienced service disruption, while customers of HSBC, Lloyds and Bank of Scotland also reported banking and payment problems. The report noted that a direct connection to Google had not been confirmed for all of those banks. This was an availability incident, not evidence that their data had been deleted. Even so, it is another reminder that infrastructure failures reach far beyond a cloud dashboard, into people's ability to pay for groceries or fuel. [27]

The report was published on 22 October, but the outage itself occurred on 20 October. Google's account describes a major regional incident, rather than a failure of every Google Cloud region worldwide. Businesses depending on the affected services could nevertheless experience disruption wherever their customers were located.

AWS's UAE situation is more prolonged. In my capture of the AWS Health Dashboard on 23 October 2026 at 5:33 am AEDT (UTC+11), the affected-services panel listed 144 disrupted services and five resolved services for the UAE regional incident that began in March. This is a timestamped snapshot of that incident's regional service list, not a claim that 144 AWS services were failing worldwide or that a new outage began that morning. [15]

The accompanying incident update gives that number a more sobering context. AWS attributes the disruption to damage associated with the conflict in the Middle East. Its 15 September update says access to resources and data hosted exclusively in the mec1-az2 Availability Zone cannot be restored, while recovery work continues elsewhere in the region. Customers who had backups or accessible copies in other regions had a route to rebuild. For me, that is the practical distinction between having a backup and having a recovery copy that survives the same event.

View the affected-services list: 144 disrupted, five resolved

There was also the major AWS disruption on 20 October 2025. AWS's account traces it to a defect in DynamoDB's DNS automation in Northern Virginia, with consequences for dependent services. Different services experienced different periods of impairment; this was not a simultaneous shutdown of every AWS region. [16]

About a month later, Cloudflare suffered its 18 November 2025 outage. Its account describes a database permissions change producing an oversized Bot Management configuration file, which caused failures in the network software consuming it. Core traffic was largely normal after roughly three hours, with recovery work continuing afterwards. [17]

Cloudflare then suffered another outage on 5 December. That incident lasted approximately 25 minutes and affected customers accounting for around 28% of its HTTP traffic. It arose during changes associated with mitigating a React Server Components vulnerability. A security provider's own change disrupted customers using different application stacks. [18]

More outage coverage: Google Cloud reporting in the Daily Mail and Cloudflare reporting in the Express.

Cloudflare belongs in this article because I use it. A static website can be perfectly intact and still become unreachable when its delivery network fails. Removing PHP does not repair a provider's power supply, DNS automation or traffic-handling software.

The architectural benefit is narrower and still valuable: fewer application components need to work to deliver the page, and the page can be easier to reproduce elsewhere. Availability also requires a recovery plan for the dependencies that remain.

Why my own website is static

The published pages on stefs.site are 100% static. My blog uses Eleventy, with its source managed through Git and publication through Cloudflare Pages. Reading an article does not require a live WordPress installation, PHP interpreter or database query. I have written separately about building and migrating it with Codex. [19]

This removes the application-server maintenance I previously associated with running a publishing site. There is no virtual machine for me to log into to keep the blog's PHP, database and CMS stack operating. Cloudflare delivers the files through its hosting network. [20]

That is what I mean by a static website. Servers still exist at the provider. DNS, TLS certificates, account security and the deployment workflow still matter. The accurate claim is that the page does not need my own live application stack to be generated for each reader.

My workflow is also much easier to change. I can describe an improvement to Codex, review the result and publish it through the existing build process. Small changes can be live in seconds once ready, although the actual timing depends on the task, checks and deployment. Prompting has made implementation more accessible; it has not made reviewing the result unnecessary.

Build tools and browser-side dependencies still need care. A compromised deployment account can publish malicious files. An external script can harm visitors even when the HTML containing it is static. OWASP explicitly identifies third-party JavaScript as a source of code-execution, information-disclosure and uncontrolled-change risks. [21]

The improvement is that maintaining the publishing tools is a different problem from keeping a database-backed application available for every visitor. I can also keep a known-good copy of the finished site, so recovery does not first require reconstructing the exact build environment.

For this workload, the cost benefit includes the time I no longer spend administering a CMS runtime. Static hosting can be very inexpensive, but the full bill still includes domains, paid integrations, development tools and whatever level of support the site needs.

A heart button does not have to determine the whole architecture

Static publishing works especially well when dynamic features are limited and separable.

A heart button that changes appearance in one browser is straightforward client-side behaviour. Remembering that choice on that device is different from maintaining a trustworthy total across all readers. A shared count needs shared storage and an authorised way to write to it somewhere.

Comments have the same distinction. Approved comments can be stored in Markdown, JSON or another static file and included when the site is rebuilt. Someone or something still has to receive submissions, handle spam, moderate content and publish the update. Giving visitors direct write access to the site's files would create a different security problem.

An external commenting service can handle those responsibilities separately. My current blog uses Giscus, with discussions hosted on GitHub. The article itself remains a static page; the discussion feature has its own service dependency. [19]

The design goal should be that a failed comments request leaves a readable article. The same applies to analytics, reactions and a support-payment link. Optional features should be able to fail without taking the main content with them.

I would also favour publishing the actual article in HTML. If the browser first receives an empty application shell and must contact several APIs before it can display a paragraph, much of the availability advantage has been given away. Files being hosted statically does not, by itself, guarantee that the information readers need is present in those files.

Resuleet shows where dynamic services still earn their place

Resuleet is another project I have built using a static-based approach, with its implementation produced through Codex. Vercel and Cloudflare remain dependencies. Using AI to build the code does not alter the responsibilities that come with operating it.

There is also an important difference between a static frontend and an entirely static product. A job-application service that handles accounts, documents and AI-powered workflows still needs dynamic services for those functions. Authentication, stored user data and AI requests cannot be wished away by choosing static hosting for the interface.

Modern frameworks explicitly support this distinction. Next.js can export static HTML, CSS and JavaScript while browser code fetches data from external services; features requiring a live server remain separate architectural decisions. That is a general capability, rather than proof that every application using such a framework has no backend. [22]

My aim is to keep the public interface and straightforward content as simple as possible, while giving the functions that genuinely need live processing an appropriate home. A failure in an AI integration should not automatically make a public explanation page unreadable.

Moving complexity into APIs can be sensible. It can also hide it. The useful question is which dependencies must work for each user task, and what remains usable when one fails.

Moving to SaaS changes who maintains the system

At a university where I worked, the organisation relied on 23 WordPress sites.

I have since heard that the campaign sites moved towards SaaS after an exploit, with reduced appetite for paying a developer to maintain them. My understanding is that a Drupal site is still supported through an external company. I have not independently confirmed those arrangements or the rationale for the change.

It does illustrate a plausible organisational decision. A SaaS contract can replace some internal hosting and software-maintenance work with a service someone else operates. That can be reasonable when the supplier offers capabilities and support an organisation would struggle to provide itself.

The costs and responsibilities change location. Subscription fees, integration work, data exports, access management and exit arrangements still need an owner. An organisation can retire its own WordPress servers and remain heavily dependent on another company's application, staff and cloud infrastructure.

Content editing also deserves attention. A communications team may need approvals, scheduling, accessible templates and reliable media management. A static workflow must meet those needs if it is to be a useful replacement. A Git-backed editor, or a separately managed CMS that publishes static output, can preserve editing convenience while reducing the machinery exposed to readers.

The business case should compare the whole operating arrangement. A cheaper hosting invoice means little if publishing becomes unusable for the people responsible for the content.

Will any of this create more IT jobs?

After the CrowdStrike incident in July 2024, I thought employers might finally invest more seriously in the people keeping their systems operational.

On 19 July, a CrowdStrike sensor configuration update caused affected Windows machines to crash. It was an operational failure involving trusted security software. Microsoft estimated that 8.5 million Windows devices were affected, with disproportionate consequences because many belonged to organisations running critical services. [23][24]

PHP2Shell is a different kind of event: attackers can exploit a vulnerability in a widely used runtime. The connection is the concentration of consequences around shared dependencies. Static websites would not have fixed crashed Windows endpoints, but both incidents should encourage organisations to examine which outside components can interrupt their work.

More than two years after CrowdStrike, I am less confident that a major incident automatically produces more permanent jobs. There is a difference between work that needs doing and a position someone has approved funding for.

ISC2's 2025 international survey of 16,029 cybersecurity practitioners and decision-makers reported hiring freezes at 39% of respondents' organisations and budget cuts at 36%. Those are survey findings, rather than a census of all employers, but they show that recognised security needs can coexist with constrained hiring. [25]

My own search for remote WordPress roles offered a smaller, personal example. When I asked Grok to find opportunities, it returned almost nothing beyond one WP Engine role. One bot-assisted search cannot establish the size of a labour market. It can reflect search coverage, filters and timing as well as the jobs available.

It nevertheless fits a frustration I have felt: specialist website work seems increasingly difficult to find under a dedicated title. I suspect some work has moved to lower-cost labour markets, while some has been absorbed into broader digital-marketing roles. Those are impressions, not conclusions I can prove from that search.

Knowing how to edit WordPress content is also different from understanding the hosting, permissions, recovery and runtime underneath it. Combining those responsibilities into a marketing position does not remove the need for the technical knowledge. If the maintenance remains necessary, somebody still has to be equipped and paid to do it.

Simplification may reduce routine CMS maintenance work while increasing the value of migration, architecture, accessibility, secure deployment and recovery planning. Whether that creates more jobs overall depends on investment and organisational choices. I would rather argue for funding useful engineering than promise another hiring boom after another alarming headline.

The maintainers underneath the business model

The PHP Foundation's account of these vulnerabilities deserves attention. It says early signs of the out-of-memory problem were identified in 2024, but difficult compatibility decisions, decision-making processes and limited resources delayed the fix. It describes that delay as a structural failure and explains why funded specialists were essential to the response. [26]

That is a concrete lesson for industries relying on shared software. A business can spend heavily on hosting, applications and security products while contributing little to the maintenance of the runtime those purchases depend on.

The dependency meme accompanying this article works because it exaggerates something recognisable: the distance between the apparent scale of digital infrastructure and the small components or teams supporting it. Its arrows are satire, rather than an engineering diagram, but the question about who maintains the foundations is serious.

Reducing unnecessary dependencies and paying for the necessary ones are compatible decisions. A business that needs PHP should support a sustainable PHP ecosystem. A campaign page that does not need PHP should be allowed to avoid it.

Open source makes this dependency visible. Proprietary software and SaaS still rely on people, budgets and maintenance decisions that customers may see even less clearly.

What industries should change

I would start every new publishing project by asking which functions require a live server response. An article, product explanation, event timetable or public information page may need updates without needing a database query for every reader. Personal accounts, transactions, stock reservations and private records have different requirements.

Then separate the essential content from optional services. A university campaign page should be able to explain the course when its analytics provider is unavailable. A public information page should not disappear because its comment widget fails. An online shop may still need a transactional backend while keeping its guides and support information independently readable.

Recovery should be designed alongside publishing. Keep copies of the content, uploaded media, source, working build and necessary configuration somewhere that will survive the loss of the production account. Export external comments or other service data that matters too; a Git repository may not contain the whole service. Know who controls the domain and DNS, and retain a recovery contact outside the domain you are recovering. Check whether an alternative host can serve the site correctly, including its URLs and assets.

This does not require pretending that migration is instantaneous. DNS changes, certificate issuance, missing configuration and inaccessible accounts can all slow recovery. A portable site reduces the work involved; testing establishes how long the remaining work actually takes.

Organisations should also make an explicit decision about which services deserve more elaborate redundancy. A personal blog and an emergency information service have different tolerance for downtime. Multiple providers add cost and coordination of their own. A small site may be well served by independent backups and a tested alternative deployment, while a critical service may justify keeping that alternative ready to use.

Finally, give someone responsibility for the residual risk. Moving to static publishing can remove a large maintenance burden. Moving to SaaS can transfer operational work. Neither arrangement makes account security, supplier oversight or continuity planning happen automatically.

The useful outcome of PHP2Shell would be a more deliberate choice of architecture and better support for the software we keep. Patching is necessary. Learning from the incident means also questioning whether the next site needs the same exposed runtime in the first place.

Related videos

A simpler default for the next website

Dynamic websites earn their complexity when the service needs live transactions, personalisation, private data or frequent shared updates. Those are real requirements, and there are many good reasons to use a well-maintained CMS or application platform.

For a large amount of ordinary publishing, I think static should be considered first. It can remove the PHP and database stack from delivery, make a working site easier to copy and move, and reduce the number of small operational problems that accumulate around keeping a CMS online.

I still depend on Cloudflare. Resuleet still depends on external platforms and services. My experience with Siteroo is exactly why I want to understand those dependencies, preserve recovery options and avoid adding more machinery than the job requires.

After PHP2Shell, CrowdStrike, provider deletions and repeated cloud outages, I would like more organisations to value that kind of engineering. Sometimes the most useful work is deciding which systems can be retired, then making sure the simpler replacement meets the actual need.

For a page whose purpose is to let someone read an article, that is a worthwhile place to start.

Keep it simple, stupid. KISS. For me, that means using the least machinery that meets the need, and making sure I can recover it when something goes wrong.

Are you still using dynamic sites? If so, what for?

Sources

1. Wiz Research. PHP2Shell original disclosure. 21 October 2026.
2. PHP project. CVE-2026-109618 RCE via OOM corruption. 21 October 2026.
3. PHP project. CVE-2026-109619 RCE via stale global state. 21 October 2026.
4. PHP project. Critical remote code execution security advisory and fixed releases. 21 October 2026.
5. AWS Security Blog. PHP2Shell exploitation attempts observed in MadPot. October 2026.
6. Node.js Project. Wednesday, October 21, 2026 Security Releases. 21 October 2026.
7. Vercel Security Team. Node.js security advisory: Brotli decoder RCE (CVE-2026-111497). 21 October 2026.
8. Eleventy. Official static site generator documentation. Accessed 23 October 2026.
9. SiterooWeb. Public firsthand account of Compute Engine deletion during a billing dispute. Reddit post and author-supplied account.
10. Siteroo. Public restoration update describing the surviving off-cloud backup. Text and screenshot supplied by the author.
11. Google Cloud. Project suspension guidelines and Cloud Billing account suspension. Accessed 23 October 2026.
12. UniSuper and Google Cloud. Joint statement on private cloud deletion and recovery. 8 May 2024, subsequently clarified.
13. Google Cloud. Technical account of the UniSuper GCVE incident. 24 May 2024.
14. Google Cloud Service Health. London region outage preliminary incident report. Incident 20 October 2026; report 22 October 2026.
15. AWS Health. UAE regional operational issue and affected services. Incident began March 2026; substantive update 15 September 2026.
16. AWS. DynamoDB service disruption in Northern Virginia. 19–20 October 2025 in the provider’s Pacific timeline.
17. Cloudflare. Cloudflare outage on 18 November 2025. 18 November 2025.
18. Cloudflare. Cloudflare outage on 5 December 2025. 5 December 2025.
19. Stefan Caliaro. How I Finally Built My Own Static Blog with Codex and Cloudflare Pages. 1 October 2026.
20. Cloudflare. Pages Direct Upload and prebuilt assets. Accessed 23 October 2026.
21. OWASP. Third Party JavaScript Management Cheat Sheet. Accessed 23 October 2026.
22. Next.js. Static exports and their supported features. Accessed 23 October 2026.
23. CrowdStrike. Technical details of the Falcon update for Windows hosts. 20 July 2024.
24. Microsoft. Helping our customers through the CrowdStrike outage. 20 July 2024.
25. ISC2. 2025 Cybersecurity Workforce Study. 4 December 2025.
26. The PHP Foundation. Today’s PHP security release and how we are strengthening PHP security. 21 October 2026.
27. Cybernews. Google Cloud resolves outage that crashed Revolut, Lloyds, HSBC and Spotify across Europe. 20 October 2026; includes qualifications about unconfirmed connections between reported disruptions.