Chainstack's Intrusion Started at a Test Grafana With Default Admin Credentials and Ended in Production Secrets

Chainstack, a provider of hosted blockchain nodes, says an attacker reached its production Kubernetes secrets on October 29, 2026, three days after finding a test Grafana instance that still had its default administrator password. The company's incident report says no software vulnerability was exploited at any step. Every hop was a configuration choice: an exposed dashboard, a proxy with no destination allowlist, an internal AI tool server with no authentication, and development credentials that worked in production.

The report was first published on November 3, gained technical detail and indicators of compromise on November 10, and was updated again on November 11. Chainstack says customer-facing services kept running and that customer nodes, the console and the API were not modified.

What the attacker took

The customer account database was accessed. Chainstack lists the fields that may be exposed as organization names, account holder names, member email addresses and password hashes. It found no evidence that node credentials were read, but is treating them as exposed anyway. Payment details were not affected, because Chainstack says it does not store them.

The company asks customers to change passwords, rotate node credentials in the console, regenerate platform API keys if they use the platform API, and watch for phishing. Current endpoints keep working until a customer rotates, so rotation causes no downtime.

The chain, step by step

Chainstack's timeline, in UTC, is unusually granular. A test Grafana instance was deployed to a development cluster in July 2026, reachable from the internet, with default admin credentials still set.

• October 26: the attacker uses Grafana's data-source proxy to reach internal services, then finds an unauthenticated MCP tool server whose service account had cluster-admin rights, and injects a JavaScript loader into a development web app.
• October 29: using compromised development cloud credentials, the attacker hijacks a workflow-automation job between 17:03 and 17:12 to obtain machine identities, and at 17:49 lists and reads production Kubernetes secrets.
• October 31: bulk reads from the production secrets manager run from 01:40 to 08:31, and new keys and identities are created. At 03:39 a compromised VPN key disrupts database replication, which is what starts the investigation.
• November 2: the last observed use of a copied credential is at 06:28, and the incident is closed.

The picture above is a stock Grafana example, not Chainstack's instance. The point is how ordinary the entry was: a monitoring dashboard, not a zero-day.

1. Production secrets read (Oct 29)3 days
2. Replication disrupted, probe begins (Oct 31)5 days
3. Incident closed (Nov 2)7 days
4. First public report (Nov 3)8 days
5. Indicators published (Nov 10)15 days

Source: Chainstack security incident report, accessed 2026-11-11

The tool server is the new part

Most of this chain is old: default credentials, an open proxy, long-lived keys. The unauthenticated MCP tool server with cluster-admin is the newer ingredient. MCP servers expose actions to AI agents, and Chainstack's own remediation list now says internal services that expose privileged operations, "including AI tool servers", must require authentication and least privilege.

The site has covered other AI-related intrusions, including Google's llmjacking report and the second Fireworks AI intrusion. In the Chainstack case the internal AI plumbing was itself the escalation path.

ARTEX, with a caveat

Chainstack attributes the intruder's tooling to ARTEX, an open-source framework that uses LLM agents to automate intrusions, but says that does not identify the actor. Google Threat Intelligence Group and Mandiant described ARTEX on October 30 as noisy, with sub-agents that overwrite each other and predictable artefacts such as files named artex-probe-*. They wrote that the tools "trade stealth for velocity".

That fits the Chainstack record in one respect. Reads from the secrets manager ran for nearly seven hours, and the incident surfaced only because a VPN key disrupted replication, not because an alert fired on bulk secret reads. Chainstack's remediation list now includes alerts for bulk secret reads and new keys.

Weakness Chainstack found	Fix it lists
Default admin credentials on an internet-exposed Grafana	No admin tools exposed without an extra authentication layer
Data-source proxy with no destination allowlist	Destination allowlists and network policies on proxies and webhooks
MCP tool server with no authentication, cluster-admin	Authentication and least privilege on AI tool servers
Shell execution in a workflow platform with identities mounted	No shell execution, short-lived scoped credentials
Credentials that crossed from development to production	Separate identities and secret stores per environment

What Chainstack checked afterwards

The company says it attributed every production Kubernetes change since October 29 to staff, CI, automation or cluster controllers, apart from attacker-created objects that did not touch customer workloads. It also says the console and API images match their registry digests and that a review of production JavaScript found no injected code. The attacker had placed a JavaScript loader in the development and staging web apps on October 26 and 27.

On October 31 at 15:54, a malicious commit to a deployment repository failed because cluster access had already been cut. Chainstack records it as the last attempted write the report describes that day.

What is still open

Chainstack says the full technical section, with MITRE ATT&CK mappings and detection guidance, sits in the report itself. It does not name the actor, and it does not say how many customer accounts were in the database. Anyone running Chainstack nodes should rotate node credentials now rather than wait for a count; the company's security contact for questions is security@chainstack.com.