On 3 November 2026, Chainstack disclosed that an attacker had reached a customer account database inside its infrastructure. The company provides blockchain infrastructure. The database held organisation names, account holder names, member email addresses and password hashes. Entry came through a test Grafana instance whose default administrator credentials were still in place. From there the attacker moved out of a development environment and into parts of production over three days, before Chainstack detected the intrusion and contained it on 31 October. Full technical details followed in the company's incident report on 10 November, updated again on 11 November.
Timeline of the intrusion#
Chainstack dates the intrusion from 26 October to 31 October 2026, and finalised the investigation on 2 November.
| Date | Event |
|---|---|
| 26 October 2026 | The attacker entered through the test Grafana instance in a development environment |
| 29 October 2026 | The attacker reached production |
| 31 October 2026 | Chainstack detected the intrusion and contained it |
The first access came on 26 October, in a development environment. The way in was a test Grafana instance, set up in a development Kubernetes cluster during July 2026, exposed to the internet, still running its default administrator credentials, and guarded by nothing else: no single sign-on, no basic authentication. At 19:26 UTC the attacker started reaching internal services through Grafana's data-source proxy, with no destination allowlist in place and no network policy to limit where Grafana could connect.
By 21:01 that evening the attacker had got as far as an internal MCP tool server. The server gives AI agents access to Kubernetes operations, asks for no authentication, and runs under a service account bound to cluster-admin. Over the following ninety minutes the attacker probed an internal workflow engine for write access, set up administrator users in the development identity provider, and swapped a development web application's JavaScript. On 27 October the same technique hit the staging web application and the development Grafana. The injected loader pointed at a second-stage script hosted on silverbullet.icu, which Chainstack did not retrieve, so what it did is unknown.
By 29 October, development cloud credentials and an API key for the internal BI tool were already being used from an attacker address. Between 17:03 and 17:12 the attacker changed a workflow in the workflow-automation platform, editing its database directly so it ran shell commands, then fired it with a valid webhook token and restored the original. The run produced a machine identity for the infrastructure access gateway. At 17:49 that identity pulled up a production Kubernetes cluster's secrets and read several one at a time. That was the move into production.
The heaviest activity came on 31 October. Between 01:40 and 08:31 UTC the attacker pulled secrets in bulk from the production secrets manager. New keys appeared, together with a Kubernetes service account carrying a long-lived token, short-lived pods ran in production, and a relay was installed as a static pod. One of the secrets read was the private key belonging to a VPN peer on the database network. A client using that key connected to the database network from 03:39. Two clients now presented the same peer identity, the tunnel endpoint flapped, and a database replication pipeline went down. The failure is what started the investigation. From about 07:30 the attacker connected to a production database as an administrative user, working from pods it had created, and pulled query results out through pod command output in base64 chunks. Between 10:39 and 10:43 the attacker queried PostgreSQL's pg_shadow view on one instance, the view holding role password hashes. Chainstack spotted the intrusion and cut the access paths the same day. The last observed use of a copied credential came at 06:28 on 2 November.
Records the attacker reached#
The attacker reached a database of customer account information, and the incident report lists what may have been exposed: organisation names, account holder names, member email addresses for organisations on Chainstack, and password hashes. The company puts it as "may have been exposed", not as a confirmed copy, and the notice does not say which password-hash algorithm was used.
The attacker also got to the systems that hold node credentials. Chainstack states it has no evidence the credentials were read, but it treats them as exposed anyway and asks customers to rotate them.
The exposure has two limits. Customer-facing services kept working normally through the whole incident, and customer nodes, the console and the API were left untouched. Chainstack also states it keeps no payment method details such as full card numbers or security codes, so none of those were exposed.
An email address with a password hash is the pair that feeds credential stuffing: where the same password was reused elsewhere, the hash gives an attacker a starting point. The organisation name and account holder name supply the detail that makes a phishing message look genuine, and that combination keeps its value after the incident ends.
The Grafana entry point#
The entry point was a test dashboard, not a software vulnerability. No software vulnerability was needed, and Chainstack states it found no evidence that one was exploited. Default credentials, exposed administrative functionality, missing authentication, over-broad permissions and long-lived credentials formed the chain, and in three days it took an attacker from a test dashboard to production databases.
The pivot was Grafana's data-source proxy. The proxy lets Grafana pull data from configured sources. An administrator can aim a data source at any URL, and the proxy forwards the request and hands back the response. With no destination allowlist and no network policy to limit where Grafana could connect, the proxy opened a way into the cluster network.
The MCP tool server was the next link: it gives AI agents access to operations, asked for no authentication, and ran under a service account bound to cluster-admin. The third link was the route from development to production. Machine credentials taken in development also worked in production. The automation platform let shell commands run with a machine identity mounted into the same pod. The remediation programme aims for development to have no path to production, and detection came from a side effect: the compromised VPN key, used from two endpoints at once, broke a database replication pipeline, and that failure started the investigation.
The ARTEX campaign#
Chainstack places the incident inside a broader AI-powered attack campaign reported in late October. The company assesses with high confidence that the attacker used ARTEX, an open-source framework that orchestrates LLM agents to automate intrusions. The markers line up: the attacker's resources carried artx and artex prefixes, and the attacker tunnelled through chisel, which reporting on ARTEX also describes.
Attribution stops at the tooling. Chainstack notes that public reporting ties ARTEX to several unrelated groups, so the framework gives no name to whoever was behind this intrusion, and none of its indicators appear in the actor-specific indicators CrowdStrike published for Vapor Panda or Microsoft for Storm-0940 and Storm-3358. The company therefore attributes the tooling, not the actor.
In The Hacker News's assessment, the incident shares overlaps with a campaign by a China-linked cluster targeting high-value firms with ARTEX. That is the researchers' assessment, not Chainstack's, and this article reports it as such.
WorkOS, an API platform, disclosed a security incident involving the same framework, according to The Hacker News. It was discovered on 30 October 2026 and stayed within its GTM systems, leaving production systems and customer platform data unaffected. A separate incident came from Chainalysis on 30 October 2026. Chainalysis is a blockchain analysis firm, a different company from Chainstack, and it took its Reactor and Data Solutions products offline as of 2 November. AliasFleet covered that Chainalysis breach in a separate article, and the DIVD breach, which involved the same ARTEX framework, in an earlier one. The tooling is shared across the three incidents. The companies and the incidents are different, and this article keeps them separate.
Customer measures#
Chainstack is emailing every customer, and asks each of them to take four steps. The same sequence appears in the guide to what to do when an email is in a data breach, for any breach: find what leaked, fix reused passwords, expect phishing, then contain the next one.
The first step is a password change, on Chainstack and anywhere else the same password was reused. Changing the password alone does not finish the job: sessions, tokens and recovery settings can survive a reset. The guide on changing passwords after a breach sets out what else has to happen.
The second step is to rotate the node credentials, which can now be done through self-service rotation in the console, with current endpoints working until the rotation is complete. Third comes regenerating platform API keys, for anyone who uses the platform API. Fourth is the phishing watch. Chainstack states it will never ask for passwords, tokens or keys.
The phishing watch matters because of what leaked. A message that quotes an organisation name, an account holder name and the timing of Chainstack's real notice will look genuine, and the words on the page will not give the forgery away. The check that still works is in the guide on how phishing uses a leaked email: verify through a channel the sender does not control, by opening the app or typing the address directly, and never click a link in a breach email.
On its own side, Chainstack cut off the attacker's network sources, disabled the compromised identities and deleted their keys, and took out the attacker-created Kubernetes identities, pods and relay. Long-lived tokens were revoked, access to Kubernetes API endpoints was restricted, and the affected development cluster was shut down. Exposed credentials were rotated, cluster certificate authorities and join tokens were renewed, and customer login sessions were invalidated.
Your address is probably in this file. Check whether it is, do the password work above, and then fix the part you control: the address you hand out next time. One AliasFleet alias per service means the next leak can only point back to the service that leaked it. Founders Club is $7 a month, locked forever, instead of $12. Early members only.
Open items in the investigation#
Several items stay open in the public record. No victim count has been disclosed, which leaves the scale of the exposure unknown. The password-hash algorithm is unstated, so the notice gives no way to judge the practical risk of the hashes. Whether the customer account database was copied out or only accessed is unconfirmed, and the company has not said whether it reported the incident to a regulator. The second-stage script the injected JavaScript loader pointed at was never retrieved, so what it did is unknown. Chainstack calls the incident report page the single source of truth.
Have I Been Pwned is the quickest public check for whether an address turns up in known breach data. A Chainstack customer who finds an address in the file should go through the company's four steps in order, starting with the password change and the node credential rotation.
