Home/AI Tools/Coding Assistants

GitHub’s Outage Exposed How Dependent Coding Has Become on AI

GitHub's nearly eight-hour outage on August 17 revealed that Copilot runs on a genuinely separate authentication and routing layer than the rest of the platform, recovering hours after every other core service was already fixed.

Staff

August 23, 2026 · 4 min read

GitHub went down for nearly eight hours on August 17, taking Copilot, Actions, Issues, Pull Requests, and enterprise authentication with it. In its own post-mortem, the company traced the root cause to network saturation on load balancers in its Central US data center, triggered by a new peak in traffic, not a bad deployment or configuration change. The outage itself is a familiar kind of incident. What makes it worth real attention is how it recovered: Copilot came back nearly three hours after every other core service was already fixed, exposing that the AI layer now runs on infrastructure with a fundamentally different failure and recovery pattern than the rest of the platform.

How the outage actually unfolded

The incident began at 13:28 UTC and ran until 21:15 UTC, seven hours and forty-seven minutes end to end. At its peak, web and API error rates hit roughly 20 percent, while archive downloads and raw repository content, the kind of requests triggered constantly by installation scripts, Docker builds, and CI pipelines pulling source files, saw error rates near 50 percent. SAML and OIDC authentication, SCIM provisioning, and Team Sync went down alongside Actions, effectively locking out any organization relying on single sign-on for its CI/CD pipeline, not just individual developers trying to push code.

Seven of the eight affected services, API Requests, Actions, Git Operations, Issues, Pages, Pull Requests, and Webhooks, were declared mitigated by 16:59 UTC, roughly three and a half hours in. Copilot was conspicuously absent from that recovery announcement. It did not fully clear until the incident closed entirely at 21:15 UTC, nearly two and a half hours after everything else had already stabilized. According to GitHub’s own status page, the specific reason traces to a separate technical failure: delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified Copilot-related traffic by roughly 10 times, generating additional load precisely while the system was already trying to recover.

Why Copilot lives on a genuinely different clock

The core technical detail worth understanding is that Copilot’s underlying AI model providers stayed operational throughout the entire incident. Whatever kept Copilot down after everything else recovered was not a failure upstream at the model layer, it sat entirely inside GitHub’s own authorization and routing infrastructure, the plumbing that connects a developer’s request to the model actually generating a response. That distinction matters for anyone building products on top of AI coding assistants: the model being available is necessary but not sufficient. The authentication, routing, and retry logic wrapped around it constitutes its own independent point of failure, one that can behave completely differently from the rest of a platform’s infrastructure even when they’re nominally part of the same product.

The capacity problem GitHub has been racing to solve

This outage did not happen in isolation. GitHub CTO Vladimir Fedorov wrote in April that the company set out last fall to expand capacity tenfold, then concluded by February it actually needed to plan for 30 times its current scale, a revision that reflects just how fast AI-driven coding activity has grown on the platform. GitHub’s own July infrastructure report noted that agentic development workflows have surged since late December 2025, with pull request activity now generating load that spans Git storage, Actions, search, and background job processing simultaneously, a fundamentally different traffic pattern than the platform was originally architected around. In June, a Microsoft spokesperson acknowledged that the spike in AI agent development had tested GitHub’s infrastructure limits directly, and said the company was accelerating its migration onto Azure while separately pursuing a multi-cloud strategy that includes renting capacity from AWS, Microsoft’s own biggest cloud competitor.

That last detail is worth sitting with: Microsoft’s own developer platform apparently needs capacity from a rival cloud provider to keep pace with AI-driven demand, a genuinely unusual admission for a company that would ordinarily prefer to keep that workload entirely on its own infrastructure. It is also GitHub’s 13th recorded incident in the first 17 days of August alone, according to independent tracking, a frequency that points toward a systemic capacity strain rather than an isolated, one-off event.

What this means for teams depending on AI coding tools daily

For any team that has made Copilot or a similar AI coding assistant a genuine part of its daily workflow, this outage is a concrete argument for having a fallback plan that does not assume the assistant will always be there, not because the underlying model is unreliable, but because the infrastructure wrapped around it is a separate, independently failing system with its own recovery timeline. GitHub says it is now working on isolating critical services from each other and designing systems that preserve partial functionality during future incidents, exactly the kind of architectural response this outage’s specific failure pattern, one service’s retry bug delaying a completely different service’s recovery, points toward as necessary.

See GitHub’s own incident status page for the complete technical post-mortem.

Up Next

Copilot Snitched on Its Own Security Hole

AI Safety

Varonis Threat Labs discovered a critical Microsoft Copilot Personal vulnerability, CoSnitch, by repeatedly questioning the AI assistant until it revealed the undocumented parameter that let attackers silently exfiltrate connected account data with one click.

Staff

August 23, 2026 · 4 min read

Security researchers at Varonis Threat Labs found a critical vulnerability in Microsoft Copilot Personal that let a single clicked link silently pull sensitive data out of a victim’s connected Gmail, Google Drive, and calendar accounts, with no further clicks or confirmation required. Microsoft patched the flaw, tracked as CVE-2026-24301 and nicknamed CoSnitch, on August 18. The more striking detail is how researchers found it: they didn’t reverse-engineer any code. They simply kept asking Copilot why a certain attack wouldn’t work, and the assistant eventually explained, in plain language, exactly how to make it work.

How the attack actually worked

CoSnitch chained three separate flaws together. The first was automatic prompt execution: Copilot’s standard ?q= URL parameter, combined with an undocumented parameter called autorun=1, caused any attacker-supplied prompt embedded in a link to execute the instant the page loaded, with no click, confirmation, or user action required beyond opening the link itself. The second was data exfiltration through a channel that looked entirely routine: Copilot would collect information from a user’s already-connected apps, then quietly transmit it to an attacker-controlled server disguised as an ordinary request to summarize a webpage, the kind of action security tools see Copilot perform constantly and have no reason to flag.

The third component, and the one Varonis called the most concerning for long-term risk, was persistent memory poisoning. An attacker could host a page with instructions hidden in HTML comments or invisible page elements, and when a victim asked Copilot to summarize that page, the assistant would process the hidden instructions alongside the visible content. Those hidden instructions could write new rules directly into Copilot’s persistent memory, rules that survived password resets, session revocations, and even device re-enrollment, meaning cleaning up after an attack required manually finding and removing the poisoned memory entries rather than simply changing a password.

The flawed assumption underneath all three

Varonis’s report identifies the actual root cause with unusual clarity: the entire system assumed that any request to a connected application, Gmail, Drive, Calendar, always began with a deliberate, direct user instruction. CoSnitch broke that assumption entirely. The victim had, at some earlier point, legitimately granted Copilot access to those connected apps, so no unauthorized OAuth access or password theft was ever needed. The vulnerability wasn’t in the permission system, it was in the belief that legitimate access could only ever be invoked by an intentional user action, when in reality a maliciously crafted link could invoke that same access without the user doing anything more than opening a page.

Why the discovery method matters as much as the bug

Varonis is calling its approach meta-hacking: rather than analyzing Copilot’s underlying code, researchers repeatedly asked the assistant itself why a given attack path was blocked, reframing questions and probing its refusals until it revealed the specific undocumented parameter that made the exploit possible. That’s a genuinely different vulnerability-discovery method than traditional reverse engineering, and it reflects a real, structural risk specific to conversational AI systems: a model trained to be transparent and helpful about its own reasoning can be steered into explaining its own security weaknesses to whoever asks the right sequence of questions, a very different failure mode than a traditional system quietly leaking implementation details through error messages or logs.

This isn’t Varonis’s first Copilot disclosure this year. CoSnitch is the third vulnerability the firm has reported to Microsoft in 2026, following Reprompt, which bypassed Copilot’s safety guardrails simply by asking the same question twice, and SearchLeak, which turned Microsoft 365 Copilot Enterprise into a covert exfiltration channel. All three share the same underlying pattern Varonis has flagged: a single click on what looks like an entirely ordinary link is enough to trigger the full attack chain, with no obvious warning sign visible to the victim or their security team at the time.

A patch that took eight months

Varonis reported CoSnitch to Microsoft in December 2025, and the fix didn’t ship until August 18, 2026, roughly eight months later. Microsoft says it found no evidence the vulnerability was ever exploited in the wild, and a spokesperson told reporters the fix was applied server-side, meaning enterprise customers running Microsoft 365 Copilot were unaffected and no customer action is required, since the vulnerability was specific to Copilot Personal, the consumer assistant at copilot.microsoft.com. Varonis has still recommended that users review Copilot’s granted permissions, remove any connections they no longer actively need, and confirm their security tooling can actually detect unusual activity originating from an AI assistant, since as this case shows, that activity can look identical to the assistant’s normal, expected behavior.

The underlying lesson extends well past Copilot specifically. As more AI assistants get wired into connected personal accounts, email, calendars, cloud storage, the same core assumption CoSnitch exploited, that connector access only ever follows a deliberate user request, is one every assistant with similar integrations needs to actively defend against, not simply assume holds by default.

See Varonis’s full technical writeup for the complete disclosure timeline and exploit chain.