How GitHub's forgotten security rules ended up blocking real users

GitHub disclosed that some rate-limiting and blocking rules, originally deployed as emergency measures during past abuse incidents, remained active long after the threats had passed and gradually began affecting legitimate users. Reports surfaced on social media of people hitting 'too many requests' errors during ordinary, low-volume browsing; investigation revealed that composite fingerprinting signals were occasionally matching legitimate, logged-out traffic.

While the false-positive rate was extremely small relative to overall traffic, it was still unacceptable for the users affected. Tracing the root cause required correlating logs across multiple infrastructure layers—edge, application, and rule configuration—each with different schemas, underscoring that observability matters as much for defense mechanisms as it does for product features.

After removing the outdated rules, GitHub is now building stronger lifecycle management practices: treating incident-response mitigations as temporary by default, requiring deliberate, documented decisions to make them permanent, improving cross-layer visibility into blocks, and conducting post-incident reviews. The episode serves as a reminder that at scale, security controls need the same ongoing maintenance, documentation, and monitoring as any other production system.