0x4c0a32df4c0a…4c0a32e2

ConfirmedSecurity657 vB157 sat/vB3 min decode

Chainstack Breach Traced to Default Grafana Credentials and Kubernetes Access Path

Chainstack traced an October breach to default Grafana admin credentials and an unauthenticated Kubernetes tool server, exposing account names, emails and password hashes.

Chainstack Traces Customer Data Breach to Exposed Admin Tools
WitnessChainstack Traces Customer Data Breach to Exposed Admin ToolsAI-generated

Outputs

  1. Chainstack first disclosed the breach on November 3 and published a technical update dated November 10.

  2. The attacker entered through a development Grafana instance with unchanged default administrator credentials.

  3. An unauthenticated tool server with broad Kubernetes permissions formed part of the access path.

  4. Exposed data includes account names, organisation details, email addresses and password hashes.

  5. Customers must change passwords, rotate node credentials and regenerate platform API keys.

Chainstack has traced a customer data breach to unchanged default administrator credentials on a development Grafana instance, according to an expanded incident report whose technical section is dated November 10. The blockchain infrastructure provider, which first disclosed the incident on November 3, said an October intrusion exploited configuration and access-control failures rather than a software vulnerability, for which it found no evidence.

The updated report reconstructs the attacker's path through three control failures. The intruder entered via the development Grafana instance using default administrator credentials that had never been changed. An unauthenticated tool server holding broad Kubernetes permissions then formed part of the access path. Machine credentials connecting the development and production environments extended the attacker's reach across what should have been separate boundaries.

What data was exposed?

The report identifies four categories of potentially exposed information:

  • Account names
  • Organisation details
  • Email addresses
  • Password hashes

Chainstack treats node credentials as exposed despite finding no evidence they were read, and its guidance asks customers to take three actions: change passwords, rotate node credentials, and regenerate platform API keys where they are in use.

The distinction between these credential types matters operationally. A password hash is a representation of a password, while an active token may directly authorise requests. Replacing a login password therefore cannot be assumed to invalidate every other credential associated with an application. A single instruction to change a password can leave developers uncertain about application endpoints, automated jobs and service integrations — which is why the report specifies the affected credential types rather than issuing one blanket instruction.

What does the rotation process change for operators?

Chainstack's node-management documentation describes a staged rotation rather than a cut-over. New credentials are generated while the existing ones remain active. Applications migrate to the replacements, and only the final step — deactivation — permanently rejects requests using the previous credentials.

The documentation specifies two constraints that practitioners should note. Both credential sets continue working until the final step is executed, with no automatic time limit on the overlap. A node rotation also does not change a multichain authentication token, meaning that credential must be handled separately.

For operators, the overlap window reduces the risk of interrupting a working production service while applications are updated. The corresponding obligation is to finish the migration. Generating a replacement credential alone leaves the previous means of access fully available, and the absence of an automatic expiry means the old credentials remain valid indefinitely if no one completes the process. A completion record tracking which applications have moved and when the old credentials were disabled is the practical control a team can verify once the initial emergency has passed.

Why the underlying design problem is familiar

Grafana's own security guidance warns that services on the tool's local network may be reachable through its data-source proxy, and recommends controls such as limiting permitted destinations and applying firewall rules to restrict access to sensitive internal services.

Those precautions address a question that goes beyond who can log into a tool: what the tool can reach once someone has logged in. Authentication and network boundaries perform different jobs, and permission limits provide a further layer if either boundary fails. The Chainstack intrusion illustrates the point in reverse — a low-profile testing service became consequential because it could contact sensitive systems and held privileges extending beyond its immediate job.

The operational lesson generalises across crypto infrastructure. The boundary between an application and the services supporting it determines how far a single compromised component can travel, and a development environment connected by machine credentials to production collapses that boundary entirely.

What happens next?

Chainstack's expanded account gives customers more detail with which to assess their exposure and complete credential rotation. The remaining test is execution: whether access changes are finished across all affected applications, and whether the revised controls can prevent one compromised service from reaching far beyond its intended role.

via newsbtc.com (Source)

More from Nathan Brooks

Nathan Brooks

Show full bio

Market editor covering money, funding and market shifts around crypto and web3 industry at Mempool Brief.

1,100 articles