25 Minutes to GitHub Admin Access on Baseten's Production Environment: A Supply Chain Security Wake-Up Call

Incident Overview

A security research team conducting a penetration test against Baseten — an AI infrastructure company — gained administrator access to its production GitHub repositories in just 25 minutes. The story gained traction on Hacker News (60 upvotes, 14 comments), thrusting the well-worn topic of "developer supply chain security" back into the spotlight.

Baseten provides machine learning model deployment and inference services, and its GitHub organization houses core codebases, CI/CD configurations, and deployment credentials. In the hands of an attacker, admin-level access could mean modifying code, injecting backdoors, tampering with deployment pipelines, and potentially compromising every downstream customer that depends on their services. The 25-minute time investment stands in stark contrast to the potential damage it could enable.

Note: The original source material consists only of the headline and discussion activity — the specific attack chain and vulnerability details have not been fully disclosed in publicly available information. This article analyzes the incident by type. For technical details, refer to any official or research team follow-up reports.

Why GitHub Admin Access Is So Dangerous

In modern software delivery, a source code repository is no longer just "a place to store code" — it's the central nervous system of the entire software supply chain. Admin access means the ability to:

• Modify branch protection rules to bypass code review and merge malicious code directly
• Read or replace deployment keys and cloud credentials stored in repositories and Actions Secrets
• Tamper with CI/CD pipelines so malicious builds are automatically distributed to production
• Add collaborators or deploy keys to establish long-term, covert backdoors

For infrastructure companies like Baseten that host AI models on behalf of other businesses, risk propagates downstream along the service chain. Attackers don't need to breach each customer individually — compromising the upstream platform grants access to an attack surface multiplied dozens of times over. This is precisely the logic repeatedly demonstrated by supply chain attacks like SolarWinds and Codecov in recent years.

The SolarWinds incident (2020) is the defining case study in software supply chain attacks: attackers compromised SolarWinds' build environment and planted malicious code in an official Orion software update, causing approximately 18,000 customers worldwide — including multiple U.S. federal agencies — to unknowingly install backdoored versions. The Codecov incident (2021) is even closer to the scenario described here: attackers modified Codecov's CI script, causing companies using its service to inadvertently leak local environment variables (including various secret keys) to the attackers while uploading code coverage reports. Both incidents cemented a security consensus: compromising an upstream toolchain offers a dramatically better return on investment than attacking downstream targets one by one. This is exactly why repository permissions at infrastructure-layer companies become high-value targets.

What 25 Minutes Really Means

Achieving privilege escalation this quickly typically points to a few common weak spots — not sophisticated zero-day exploits:

Leaked Credentials and Tokens

Developers accidentally exposing Personal Access Tokens, GitHub App private keys, or cloud credentials in code commits, public Gists, CI logs, or bundled frontend artifacts is the most frequent entry point. Automated scanning tools can sift through massive amounts of public data and surface valid credentials within minutes.

GitHub offers a native Secret Scanning feature that automatically detects commonly formatted secrets (such as AWS Access Keys, GitHub PATs, Slack Tokens, etc.) on code push and alerts repository administrators when found. However, this mechanism is powerless against secrets already leaked into public Gists, Stack Overflow posts, or historical commits. Third-party tools like GitGuardian and TruffleHog can continuously scan entire git histories and public code hosting platforms — and attackers and defenders are often using the same toolchain. Notably, GitHub Personal Access Tokens (PATs) don't automatically expire (unless manually configured), meaning a leaked token that goes undetected can remain valid for months or even years. This is the core reason they're far more dangerous than temporary credentials.

Misconfiguration

Overly permissive organization-level permission settings, high default access for members, and a lack of least-privilege principles allow a low-privilege foothold to rapidly escalate to admin. Excessive authorization granted to third-party GitHub Apps and integration services is another common stepping stone.

Social Engineering and OAuth Abuse

Phishing attacks targeting developers, or malicious OAuth application authorizations, can grant account-level access without the victim ever realizing it. If the targeted account already holds an admin role, the attacker effectively skips the privilege escalation step entirely.

The significance of 25 minutes isn't the speed itself — it's what that speed reveals: the defenses may simply not exist. An unobstructed attack path signals obvious gaps in defense-in-depth and detection mechanisms.

A Defensive Checklist for Your Team

Drawing on the common lessons from incidents like this, AI and infrastructure teams can tighten their defenses across the following areas:

1. Enforce least privilege: Default organization members to read-only; strictly limit admin roles and audit them regularly.
2. Secret governance: Enable GitHub Secret Scanning and Push Protection; centralize secret management in a Vault-type system; prohibit plaintext secrets from being committed to repositories.
3. Short-lived credentials: Replace long-lived cloud credentials with OIDC federated identity so that leaked tokens expire quickly.
4. Branch protection and signed commits: Enforce required reviews and commit signing on production branches to block single-point tampering.
5. Third-party app audits: Regularly clean up OAuth authorizations and GitHub App permissions; follow a "grant only what's needed" principle.
6. Anomaly detection: Set up real-time alerts for permission changes, newly added deploy keys, and logins from unusual geographic locations.

Implications for the AI Industry

The AI infrastructure sector has expanded at breakneck speed over the past two years, with many startups channeling resources into model performance and product iteration while security investment lags behind. But as these companies begin shouldering customers' core business operations and sensitive data, the interest on that security debt becomes extremely costly.

The Baseten incident — whatever the final details turn out to be — is a reminder: AI companies must protect not only model weights and training data, but also the software supply chain that delivers those capabilities. For enterprises relying on third-party AI platforms, a vendor's security maturity should be a hard evaluation criterion during vendor selection, not an afterthought used to assign blame.

Security has never been a binary question of "have you been breached or not" — it's an economic question of "how much does it cost to breach you." When that cost is only 25 minutes, no rational attacker would pass up the opportunity.

Background: OIDC Federated Identity

OIDC (OpenID Connect) federated identity is the recommended keyless authentication approach between major cloud providers (AWS, GCP, Azure) and GitHub Actions. Here's how it works: when a CI/CD pipeline runs, GitHub issues a short-lived JWT Token for that specific workflow. With a trust policy configured on the cloud provider side, this token can be exchanged directly for time-limited cloud resource access credentials — no long-lived secrets need to be stored in GitHub Secrets at any point. Even if an attacker intercepts a workflow's temporary credentials, the validity window is typically only 15 minutes to 1 hour, dramatically narrowing the exploitable timeframe.

By comparison, the traditional approach stores long-lived credentials like AWS_ACCESS_KEY_ID in Secrets — once leaked, they remain exposed until manually rotated.