On November 1, 2022, Dropbox disclosed that a phishing attack had given attackers access to 130 of its private GitHub repositories. The breach followed a pattern that had become disturbingly common in 2022: attackers impersonated a CI/CD service to harvest developer credentials, then used those credentials to access source code and internal systems.
The Attack
In early October 2022, multiple Dropbox employees received phishing emails impersonating CircleCI, the continuous integration platform that Dropbox uses. The emails directed recipients to a fake CircleCI login page that asked for their GitHub credentials and hardware authentication token (a one-time password generated by their hardware MFA key).
At least one employee fell for the phish. With valid GitHub credentials and the OTP, the attacker accessed Dropbox's GitHub organization and cloned 130 private repositories.
What Was Exposed
The compromised repositories contained:
- Internal prototypes and tools — copies of third-party libraries modified for Dropbox's use
- Configuration files — some containing API keys and other credentials
- Code used by Dropbox's security team — internal security tooling
- Personal information — a few thousand names and email addresses belonging to Dropbox employees, current and past customers, sales leads, and vendors
Dropbox stated that the attacker did not access the core Dropbox application code, user file content, or payment information. The 130 repositories represented a subset of Dropbox's total GitHub presence and were primarily related to internal tooling and configuration.
The CircleCI Connection
The choice to impersonate CircleCI was strategic. CI/CD platforms are tightly integrated with source code repositories — developers expect to authenticate to them frequently, and the authentication flow often involves GitHub credentials. A phishing email from "CircleCI" asking a developer to log in to GitHub doesn't trigger the same suspicion as a random credential request might.
This wasn't the first time CircleCI was used as a phishing lure. GitHub had issued a security alert in September 2022 warning about a phishing campaign using fake CircleCI notifications to steal GitHub credentials. The campaign targeted users across multiple organizations, not just Dropbox.
The pattern is clear: CI/CD platforms that integrate with code repositories are prime impersonation targets. They represent a trust relationship that developers are accustomed to, and they provide a plausible pretext for credential requests.
The MFA Bypass Problem
Dropbox's disclosure noted that the phishing page captured hardware authentication tokens (OTPs from hardware keys). This is an important detail because it means the phishing page was proxying authentication in real time — capturing the OTP and using it before it expired.
However, Dropbox also noted that they were in the process of migrating to WebAuthn-based authentication, which would have prevented this attack. WebAuthn (the protocol behind FIDO2 security keys) binds the authentication challenge to the legitimate domain, making it impossible for a phishing site to relay the response.
The timeline is telling: Dropbox knew WebAuthn was more secure and was migrating to it, but the migration wasn't complete when the attack occurred. This is a common scenario — organizations identify the right security control but are caught in the gap between decision and full deployment.
Supply Chain Implications
CI/CD Trust Relationships as Attack Surface
The attacker exploited the trust relationship between developers and their CI/CD platform. This is a supply chain relationship — CircleCI is part of Dropbox's software development supply chain, and the trust developers place in CircleCI-related communications became the attack vector.
Source Code as Supply Chain Asset
The 130 compromised repositories contained modified third-party libraries, internal tools, and configuration. Each of these is a supply chain component: the third-party libraries are upstream supply chain, and the internal tools are part of Dropbox's development supply chain. Exposure of these components gives attackers insight into Dropbox's technology stack and potential vulnerabilities.
Credential Exposure in Repositories
The disclosure that some configuration files contained API keys highlights an endemic problem: credentials in code repositories. Despite years of awareness and tooling (git-secrets, truffleHog, GitHub secret scanning), credentials continue to appear in repositories. When those repositories are exposed in a breach, every credential becomes a potential pivot point for further attacks.
Lessons and Recommendations
Complete Your WebAuthn Migration
If you've decided to deploy phishing-resistant MFA, treat the migration as urgent. The gap between "we know we should" and "it's fully deployed" is when you're most vulnerable, because you've identified the risk but haven't mitigated it.
Treat CI/CD Communications with Suspicion
Train developers to treat emails from CI/CD platforms with the same caution they'd apply to any other authentication request. Better yet, ensure that CI/CD authentication flows don't rely on email-initiated login prompts.
Scan Repositories for Credentials
Implement automated secret scanning in all repositories — not just public ones. Use tools like GitHub's secret scanning, truffleHog, or Gitleaks to detect credentials before they're committed and to identify existing credential exposure.
Limit Repository Access
Not every developer needs access to every repository. Implement the principle of least privilege for repository access, and regularly audit who has access to what.
Monitor Repository Cloning
Unusual patterns of repository cloning — especially bulk cloning of repositories by a single account — should trigger alerts. The attacker cloned 130 repositories; this kind of bulk access should be detectable.
Audit Third-Party Library Modifications
Modified copies of third-party libraries that live in private repositories represent hidden supply chain risk. They don't receive automatic vulnerability notifications, and they may contain custom code that introduces new vulnerabilities. Track these modifications and ensure they're maintained.
The Broader Pattern
The Dropbox breach was one of several similar incidents in 2022 where CI/CD impersonation was used to harvest developer credentials:
- GitHub warned about CircleCI phishing campaigns in September 2022
- The Heroku/Travis CI incident (April 2022) involved stolen OAuth tokens from CI/CD platforms
- The 0ktapus campaign (August 2022) used similar real-time credential relay techniques
The software development supply chain — the tools, platforms, and workflows developers use daily — has become a primary attack surface. Defending it requires treating developer tooling with the same security rigor as production infrastructure.
How Safeguard.sh Helps
Safeguard.sh provides visibility into your development supply chain, including the tools, platforms, and integrations that your development workflows depend on. Our platform scans for exposed credentials in codebases, monitors for unauthorized changes to dependencies and configurations, and helps enforce security policies across your development lifecycle. When breaches like the Dropbox incident occur, Safeguard.sh enables rapid assessment of whether your organization's code and dependencies were affected.