UpGuard can now report that it has secured an Elasticsearch database containing data from APIsec.ai, a security company that claims to be used by 80% of the Fortune 100. The database contained over three terabytes of data generated through monitoring customers’ APIs for weaknesses, including configuration information for private scanning instances, results of API scans for customers’ endpoints, and personal information for users collected during scanning. Together, the data provides extensive information about the attack surfaces of these enterprises.
Timeline
UpGuard detected the open database on the morning of March 5th, 2025. After analyzing the database and determining its significance, UpGuard notified APIsec via email. The database was secured that day.
Significance
The database contained indices for executing the APIsec test suites against customer APIs and storing the results. The largest index, "fx-testsuite-responses-lob," had over 99 million entries using two terabytes of storage space. Multiple indices included data from the scanning tests, with two factors contributing to the large size of the collections: first, the API test responses could be very verbose, including information for many inputs and outputs against an endpoint; and second, the data collection had results spanning from 2018 to 2025.
Scan results
The APIsec platform helps companies secure their APIs by running tests for common weaknesses like those identified in the OWASP 10. Performing that activity requires specifying the endpoints, choosing which tests to run, and then regularly rerunning those tests to detect new weaknesses. When exposed, this information poses a risk by providing detailed reconnaissance information to attackers. By enumerating what tests are being performed, this data also allows attackers to look for potential issues not being tested.
System credentials
The index named “fx-accounts” included only six entries, each specifying a username and credentials for a service. Those included the access keys and secret key for an AWS account and credentials for a Slack account and a GitHub account. The created on and last modified time stamps indicated these were created in 2018. Without testing these credentials, UpGuard has no knowledge of whether they were still active at the time of exposure.
A larger collection of system data was found in the index "fx-clusters." This collection contained 3772 objects, each containing some configuration data for an APIsec scanning instance. 218 entries contained the same AWS accessKey as the record in fx-accounts. Based on the number of clusters using this accessKey, this AWS account appears to have been used for a substantial number of APIsec's scanners.
APIsec also offers a self-hosted deployment option so companies have greater control over their data and the option to scan endpoints not accessible over the internet. Those self-hosted scanners are created with identifiers and credentials that allow them to communicate with the APIsec web interface. The data included 1340 unique values for the scanner “name” field and 1903 unique values of "FX_KEY."
Personal and account information
The data set included some personally identifiable contact information. Most of this was data used for the sale and operation of the platform, like customers’ names and email addresses associated with their billing accounts. The account metadata included the companies’ names, their plan type, and if/when SSO or MFA were enabled. Information related to APIsec’s public case study customers provided additional evidence that this collection represented real business data. As with the detailed scan data of endpoints, this information gives attackers useful technical and social recon about many potential targets.
In one curious case, a nail salon website in the UK appears to have sent its own users’ data as responses to APIsec scans, perhaps as a result of testing for (and discovering) an unauthenticated API. As a result, entries for 224 nail salon technicians were captured, including name, email address, mobile phone number, and a bcrypted password. The password values were identical, suggesting the system set these and did not reflect individual passwords. UpGuard analysts identified natural persons matching the names in the data set working as nail technicians in the UK, supporting the case that this data was for real people.
Conclusion
As companies build up their capabilities for attack surface monitoring, the importance of third-party vendor security increases as well. Reconnaissance information that attackers would aim to collect but which might require access unavailable to them can become concentrated in security tools, which then become the very risk they aim to mitigate. Even the additional security of running private scanning clusters can be a double-edged sword when data leaks expose the secrets used to configure those instances or reveal which customers don’t have MFA enabled.
.jpg)
.jpg)
