Allium Revokes API Keys After Unauthorised Access

Allium, a company that sells cleaned-up blockchain data to businesses and developers, says it found unauthorised access to “certain Allium systems” on 25 October. Its main app was then offline for about two and a half days. Now that it is back, existing API keys are being revoked, users must set new passwords, and uploaded data is locked.

The disclosure came on 28 October in a security update signed by chief executive and co-founder Ethan Chan, alongside a detailed notice on the company’s status page. It turns what customers had seen as an extended “maintenance” outage into a confirmed security incident. It also leaves the key questions open: what the intruder reached, and whether any customer data left Allium’s systems.

From “maintenance” to a security incident

Allium’s status page shows how the incident unfolded in public. At 19:31 Eastern time on 25 October (23:31 GMT), it said its Explorer was “undergoing maintenance and is currently unavailable”. By the morning of 26 October, Allium had “taken the Allium App offline as a precautionary step”. The outage stayed open until 09:00 Eastern time on 28 October (13:00 GMT), when the Explorer and its API came back.

Chan’s post explains the gap. “On October 25, we identified a security incident involving unauthorized access to certain Allium systems,” he wrote. “We took immediate steps to restrict access and secure our systems. We have notified affected customers directly.” Allium has brought in an independent cybersecurity firm and says it will publish “a summary of our findings and the measures taken in response” once the investigation ends.

A separate status-page incident shows Allium’s datashare deliveries, which push data into customers’ own cloud data warehouses, were delayed from the evening of 26 October. Allium says delivery resumed on 27 October and was running normally on 28 October. It has not said whether that problem was connected to the security incident.

What customers have to do now

The measures on the status page are the clearest sign of how seriously Allium is treating the incident:

API keys: “existing API keys are being revoked”. Customers need to create a new key in the app to restore API access, unless their Allium contact is issuing one directly.
Passwords: users are asked to set a new password when they next sign in, and Allium recommends turning on multi-factor authentication.
Uploaded data: uploading new data and accessing previously uploaded data are “temporarily disabled”. Queries that use uploaded tables will not run until this is switched back on.

Some features are still missing. Allium Assistant and the Allium MCP, which the status page groups together as its AI features, were not yet available on 29 October. A status-page incident covering their recovery was still open.

Key rotation tells customers more than the statement does

This is TSN’s analysis. Allium’s written statement is brief, but its actions say a good deal. Companies revoke every existing API key and force password resets when they cannot rule out that credentials were exposed. Freezing access to customer-uploaded data points the same way: those tables belong to customers, not Allium, and switching them off suggests the company wants to be sure who can reach them before reopening. None of this proves that keys, passwords or data were taken. It does mean customers should act as if they might have been.

For firms that build on a data provider, the practical risk sits downstream. Any service that stored an Allium key in code, a CI pipeline or a third-party tool now holds a dead credential and should replace it. It is also worth checking whether that key was used from unexpected places before it was revoked. Recent incidents show how stolen tokens travel, from campaigns that steal GitHub tokens to reach CI secrets to Foundation’s decision to revoke all its Cloudflare keys after a phishing wave.

There is a compliance angle too. Crypto businesses use blockchain data providers for analytics, reporting and, in some cases, transaction monitoring. A provider incident is a third-party risk event that many firms will need to log and assess, even if their own systems were never touched. The Solflare case, where a validator stopped earning rewards after a provider key incident, shows how a supplier’s problem can quickly become the customer’s. Allium says it has told “affected customers directly”. Customers who heard nothing still have to rotate their keys and reset their passwords.

What is still unknown

Allium has not said how the intruder got in, which systems were accessed, how many customers were affected or whether any data was copied. It has not named any affected customer. The findings it has promised from the independent investigation will be the first real test of how far the incident went. TSN will update this story when they are published. Other incidents are tracked on TSN’s ransomware and cyber attacks hub.