Widespread AI Outage Exposes Fragile Cloud Dependencies Behind ChatGPT, Claude and Grok
On the night of September 3, users worldwide noticed that ChatGPT, Claude, Grok, Copilot and Gemini had gone offline almost simultaneously. The outage lasted approximately three hours and forty minutes and was quickly labeled the largest reported AI service disruption to date.
The incident began at 9:30 a.m. Eastern Time when ChatGPT started failing. Within twenty minutes Downdetector recorded more than 12,000 user reports describing failed page loads, interrupted conversations and API timeouts. At roughly the same moment Anthropic’s Claude, xAI’s Grok, Microsoft Copilot and Google Gemini also became unreachable across North America.
Developers using the Cursor code editor were among the first to feel the impact. With the underlying models unavailable, code completion and AI-assisted suggestions stopped working, forcing teams to revert to manual coding for the remainder of the evening.
Attention quickly turned to the underlying cloud infrastructure. Both Azure and Cloudflare showed correlated spikes in error reports during the same window. Azure hosts compute resources for OpenAI, Anthropic and xAI, while Cloudflare was experiencing HTTP/3 connection problems with R2 custom domains and IP geolocation errors affecting WARP users.
The concentration of AI traffic through a handful of cloud providers created a classic single point of failure. Many organizations had built critical workflows—document generation, sales proposals, code pipelines—on the assumption that these upstream services would remain continuously available.
Security teams are advised to take four immediate steps: compile a complete map of AI service dependencies, define and test manual or local-model fallback procedures, subscribe to status-page alerts for Azure and Cloudflare, and incorporate model routing across multiple providers into production architectures.
The outage demonstrated that downtime has become the new breach for organizations that depend on AI. Future resilience will require treating cloud infrastructure concentration as a core supply-chain risk rather than an operational afterthought.
Related articles
Sapper Revives Minefield to Deliver Accurate SBOM-Based Vulnerability Impact Reports for Cyber Resilience Act Compliance
Developer Perruer has forked the archived BitBom project Minefield into a new open-source tool called Sapper, fixing critical bugs in dependency graph construction and vulnerability matching. The original Minefield used roaring bitmaps and Tarjan's algorithm to build transitive dependency caches from SBOMs in O(n + m) time, but it incorrectly interpreted SPDX edge directions from protobom 0.6, creating false cycles and massively inflating dependent package counts. Additional fixes addressed SQLite memory database pooling issues, OSV range sorting errors with Go pseudo-versions and ECOSYSTEM ecosystems, and slow OSV ingestion by adding a package name index. Sapper now produces prioritized reports using CISA KEV and EPSS scores, showing exact shortest paths from vulnerable packages to root products while respecting OpenVEX statements. The tool maintains full air-gapped operation and supports CycloneDX 1.3–1.7 and SPDX 2.x formats. These improvements directly help organizations meet the 24-hour notification requirements under the EU Cyber Resilience Act for actively exploited vulnerabilities.
Fake Terraform Providers on HashiCorp Registry Distribute Go Malware to Developers
Cybersecurity researchers have identified Go-based malware distributed through two fake Terraform providers and two Go modules hosted on the official HashiCorp registry. The providers gocommunity-io/dockerd and kreuzwenker/docker, along with modules gocommunity.io/orderedbtree and gogets.dev/btreex, impersonate legitimate projects and represent the first documented case of malicious code being delivered via the HashiCorp registry. Attackers approach developers on LinkedIn, Facebook, and job forums using fake Web3 company profiles, then supply seemingly harmless repositories whose malicious behavior is triggered through npm or PyPI dependencies. Once executed, the malware collects hardware attributes, operating system data, hostname, and node availability before sending the information to attacker infrastructure. Command and control relies on a Slack channel polled every ten seconds and encrypted commands read from Sepolia testnet Ethereum smart contracts every three seconds, with each infected client using ephemeral key pairs for targeted delivery. The code matches the Graphalgo campaign previously documented by ReversingLabs and attributed to North Korean actors.
Challenges in Building Accurate SBOMs for C and C++ Projects Highlighted by CodeScoring Analysis
C and C++ ecosystems lack centralized package manifests, making SBOM generation far more complex than in Python, Java, or JavaScript. Libraries may arrive through system package managers like apt or dnf, build tools such as Conan and vcpkg, or direct source inclusion, with no single record of all components. CodeScoring’s Johnny agent uses eBPF to observe linker commands during builds and cross-references results with dpkg, RPM, and pkg-config metadata. The analysis distinguishes build-time SBOMs, which capture static libraries and compilation commands, from runtime SBOMs that reflect dynamic dependencies at execution. When version data cannot be verified, components are explicitly marked unresolved rather than guessed. The approach also addresses header-only libraries and patched artifacts that defeat simple hash matching.
CrowdSec Confirms Theft of Source Code from Roughly 300 GitHub Repositories via TanStack Supply Chain Attack
French cybersecurity firm CrowdSec has confirmed that attackers stole source code from approximately 300 GitHub repositories, including around 170 private ones. The breach occurred in May 2026 through a compromised TanStack component that exfiltrated an API key with read access to the private codebase. The stolen material included code for the company's SaaS console, AWS procedures, connectors, and automation tools, while the remaining repositories contained already-public open source code. No customer data, passwords, organization details, tokens, or other secrets were included in the leak, and all potentially affected credentials were immediately rotated. CrowdSec stated that the code is tightly integrated with internal systems and has largely changed over the past four months, reducing its usefulness outside the company's environment. The SaaS service code undergoes regular audits, and the company sees no immediate threat from the exposure while the investigation continues.