In January 2024, a threat actor operating under the handle "emo" posted a dataset containing the personal information of over 15 million Trello users on the Breach Forums hacking marketplace. The data was not obtained through a traditional breach or network intrusion. Instead, the attacker exploited an insecure Trello REST API endpoint that allowed anyone to query whether an email address was associated with a Trello account and, if so, retrieve the corresponding user profile information.
The incident highlighted a growing category of security exposure: API enumeration attacks where publicly accessible APIs are used to correlate and enrich data at scale.
How the Scraping Worked
Trello, owned by Atlassian, provides a public REST API that developers use to build integrations with the project management platform. One endpoint in particular allowed querying member information by email address. The endpoint was designed to facilitate features like inviting users to boards and finding collaborators.
The problem was that this endpoint was accessible without authentication and returned user profile data including:
- Full name
- Username
- Email address
- Profile bio
- Account activity indicators
The threat actor took a list of email addresses from previous data breaches and other sources, hundreds of millions of addresses, and queried them against the Trello API. For every email address that matched an existing Trello account, the API returned the associated profile data. The result was a dataset of 15.1 million email addresses correlated with Trello account information.
The technique is straightforward: take a large list of known email addresses, automate queries against the API, collect the results. No hacking required. No credentials needed. No exploitation of any vulnerability in the traditional sense. The API was working exactly as designed; it was the design that was the problem.
Why This Matters
On the surface, the exposed data might seem relatively benign. Names, email addresses, and usernames are not Social Security numbers or passwords. But the value of this dataset lies in its correlation power.
Spear phishing: Knowing that a specific person uses Trello, combined with their name and email, allows attackers to craft highly targeted phishing emails. "Your Trello board has been shared with you" or "Action required on your Trello workspace" are compelling lures when sent to known Trello users.
Credential stuffing targeting: If a user's email appears in both the Trello dataset and a previous breach that included passwords, attackers can attempt to use those credentials against the user's Trello account and any other services where they might reuse passwords.
Social engineering enrichment: The dataset enriches existing attack databases. An attacker planning a targeted attack against a company can now confirm which employees use Trello, learn their usernames, and potentially infer information about team structures and projects from profile bios.
Account enumeration: The dataset confirms which email addresses are associated with active Trello accounts, allowing attackers to focus their efforts on confirmed active users rather than spraying attacks across unverified email lists.
The API Enumeration Problem
Trello is far from the only service with this type of API exposure. API enumeration attacks have become a widespread problem across the technology industry. The pattern is consistent:
- A service provides an API endpoint that accepts an identifier (email, phone number, username)
- The endpoint returns different responses for existing vs. non-existing accounts
- Attackers automate queries to map identifiers to accounts at scale
Major incidents following this pattern include:
- Twitter (2022): An API vulnerability allowed enumeration of 200 million email addresses associated with Twitter accounts
- Facebook (2021): Phone number enumeration led to the exposure of 533 million user records
- LinkedIn (2021): API scraping exposed data from 700 million user profiles
In each case, the companies initially downplayed the incidents by noting that no systems were "hacked" in the traditional sense. The APIs were used as intended. But the scale of abuse, querying millions or billions of identifiers to build massive correlation databases, was clearly not the intended use case.
Atlassian's Response
After the dataset appeared on Breach Forums, Atlassian acknowledged the issue and restricted the Trello API endpoint so that it could no longer be queried by unauthenticated users. The company stated that it was committed to protecting user privacy and that the API change would prevent similar scraping in the future.
Atlassian did not characterize the incident as a data breach, noting that no unauthorized access to Trello's systems or databases had occurred. The API had returned only data that users had chosen to include in their public profiles.
This characterization, while technically accurate, frustrated security researchers who pointed out that users did not consent to having their email-to-account correlation exposed at scale. The fact that a profile is individually accessible does not mean it is appropriate for mass aggregation and sale on criminal forums.
API Security Lessons
The Trello incident reinforced several API security principles that many organizations still struggle to implement:
Rate limiting: The Trello API allowed the threat actor to make millions of queries without triggering rate limits. Effective rate limiting would not have prevented the issue entirely but would have drastically increased the time and cost required for mass scraping.
Authentication requirements: Sensitive endpoints that can be used for enumeration should require authentication. If Trello had required an authenticated session to query user information by email, the mass scraping would have been significantly more difficult.
Response normalization: APIs should return identical responses for existing and non-existing accounts. If the endpoint returns the same response regardless of whether the email matches an account, enumeration becomes impossible.
Behavioral analysis: API monitoring should detect patterns consistent with scraping, such as sequential queries from the same IP, queries against known breach email lists, or query volumes that exceed any legitimate use case.
Data minimization in API responses: APIs should return only the data necessary for the requested operation. If the endpoint's purpose was to facilitate board invitations, it did not need to return profile bios and activity indicators.
The Growing Threat of Data Correlation
The Trello scraping incident is part of a broader trend where threat actors aggregate data from multiple sources, including API scraping, public records, social media, and previous data breaches, to build comprehensive profiles of potential targets.
No single data source may contain enough information for a successful attack. But when data from Trello is combined with data from LinkedIn, data from a previous password breach, and data from a public records search, the resulting profile can be devastatingly effective for social engineering, identity theft, or targeted attacks.
This correlation problem means that even seemingly minor data exposures can have significant consequences when combined with other available data. Organizations can no longer evaluate the sensitivity of data in isolation; they must consider how that data might be combined with other sources.
How Safeguard.sh Helps
The Trello incident demonstrates that API security is a critical component of the software supply chain. Safeguard.sh helps organizations understand and manage the software components that create API exposure:
- Software inventory and SBOM analysis identifies every API-exposing component in your environment, ensuring you know which services are accessible externally and what data they can return.
- Vulnerability and misconfiguration detection goes beyond traditional CVEs to identify API design flaws, missing rate limits, and insecure default configurations in the software you deploy.
- Continuous monitoring tracks changes in your API-exposing components, alerting you when updates modify API behavior or introduce new endpoints that could be abused.
- Third-party risk assessment evaluates the API security practices of SaaS tools your organization depends on, like Trello, so you can make informed decisions about which services to trust with your data.
Your organization's attack surface includes every API endpoint of every service your employees use. Safeguard.sh helps you see that surface clearly and manage the risks it creates.