Chainstack says an attacker reached password hashes and credential systems; 5 days passed before detection

Five days from first access to detection, by Chainstack's own dates

Chainstack, a blockchain node and RPC infrastructure provider, dates the start of an attacker's access to 26 October 2026 and its detection to 31 October 2026. That is five days (derived: this site subtracts the two printed dates, and the page prints no times of day, so the count can be out by a day). Two of those days were spent in the production environment, which the page dates to 29 October (derived). The page says the incident was closed on 2 November, seven days after first access, and the report itself went up on 3 November, three days after detection (both derived). This briefing reads Chainstack's incident page, which the blog index lists under Announcements, together with the linked documentation, on 3 November 2026, from 18:56 UTC. The page says it was created and updated on Nov 3, 2026; its page data carries a published time of 12:12 UTC and a modified time of 13:08 UTC.

What the page does not establish is long. It gives no number of customers or records. It does not name the "third-party component" through which the attacker got in, does not say how the attacker entered the development environment, and does not say what the attacker did between 26 and 31 October beyond the list of what was accessed. It does not say whether the node credentials were read, who the attacker is, or which "broader AI-powered attack campaign" it means. The five days are a gap between two dated lines. They are not a measured dwell time, because the page does not say the attacker was present on every day of the five.

One interest to state once: Chainstack sells node and RPC infrastructure and has a commercial interest in how the incident is described, as the security vendor whose post this briefing also reads has in how the wider pattern is described. Neither fact makes either account wrong. Both are reasons to separate what each document states from what it leaves out.

What the page says, line by line, and what it leaves open

The page is short. The table pairs each statement with what a reader would need next and does not get.

The page also says it is "the single source of truth for the incident" and that Chainstack "will update it if new information becomes available". That makes the reading time part of the claim: every statement here is as of the time stamp above, and an update could change it.

The timeline, and what the day counts do and do not mean

Four lines carry dates. The arithmetic is simple and shown so it can be checked: 26 to 31 October is 5 days; 29 to 31 October is 2 days; 26 to 29 October is 3 days; 26 October to 2 November is 7 days (5 to reach 31 October, then 2 more); 31 October to 3 November is 3 days. All of these are derived by this site.

Zoom

Two cautions. First, the working label "development to production in 3 days" is a gap between two dated lines. The page does not say the same access led from one environment to the other, or that the attacker was active on each day between. Second, the page says the attacker "gained access" on those dates. It does not say how long each access lasted, or whether access was continuous. A reader who needs a dwell time has to ask Chainstack for it.

Exposed, treated as exposed, not modified, not stored

The page uses four different strengths of word for four groups of data, and the strengths matter. For the account database it says the attacker "accessed" it, and that the information "may have been exposed". For the credential systems it says the attacker "had access to" them and that Chainstack has "no evidence they were read", yet treats them as exposed. For nodes, console and API it says "not modified". For card details it says they are not stored.

Zoom

The friendly names to check. "Hashes" are not passwords, and the page does not say what kind of hash. "Not modified" is not "not accessed": the same page says the database and the credential systems were accessed, and it is silent on whether nodes, console and API were read. "Third-party component" is not "supply chain attack" unless the page says so, and it does not. "No evidence they were read" is not "were not read", and the evidence is not described. And "AI-powered attack campaign" is Chainstack's phrase with no definition.

One more reading, labelled as such. The page asks customers to regenerate platform API keys, but its list of what may have been exposed does not mention API keys. The ask is wider than the stated exposure. It may be a precaution, since the list says "includes", but the page does not say so, and a customer cannot tell which it is.

What a password hash does and does not protect

This section is a general explanation, not a finding about Chainstack, whose page does not state the algorithm. The OWASP Password Storage Cheat Sheet says passwords should be protected with "strong, slow hashing algorithms such as Argon2id, bcrypt, or PBKDF2", each with a unique salt. It says strong passwords stored that way should be "effectively impossible" for an attacker to crack, and also describes how attackers still try: pick a likely password, compute its hash, compare, and repeat with lists of passwords from other compromised sites, brute force and wordlists.

So a stolen hash is not a stolen password, and it is not harmless either. What it means depends on three things the incident page does not give: how slow the hashing was, whether each hash had its own salt, and how strong the customer's password was. A long unique password behind a slow salted hash is a poor target. A short or reused password is a better one, and a reused password matters beyond Chainstack, which is why the page tells customers to change it on other services too. Chainstack's own documentation says two factor authentication asks for a code from an authenticator app at each login, and its endpoint security page says "If your account password leaks, 2FA is what stops an attacker from logging in." The incident page does not say whether two factor secrets or recovery codes were among the data accessed.

The unnamed campaign, and the one primary that names Chainstack

The page says its findings indicate the incident "was part of a broader AI-powered attack campaign reported in late October", and that this "does not change our responsibility". It names no campaign, no report and no author. This site looked at vendor and government pages for a late October report of an AI powered campaign that mentions a third party component, supply chain, or Chainstack.

One page names Chainstack. Wiz, a security vendor, published "Black October for AI Developer Platforms" on 30 October 2026. It describes "a series of agentic attacks on AI Developer Platforms" and says at least nine such platforms disclosed incidents in October. Wiz has since added dated update lines. The one stamped 3 November, 15:40 UTC, reads: "An additional incident is publicly reported: Chainstack (October 29-31)." It adds that no tactics or indicators have been shared. That update came about two and a half hours after Chainstack's page was last modified, by the page data (derived).

What that does and does not connect. It is a security vendor's listing, so it is Wiz's judgement, not Chainstack's. Chainstack's page does not cite Wiz, so whether Chainstack means this campaign is this site's inference, and this site cannot confirm which campaign the page means. Wiz's own wording is that "there is no single vulnerability or dependency linking these attacks", so the listing does not name a shared component either. Wiz dates Chainstack to 29 to 31 October, which matches the production access and detection dates on Chainstack's page and not the 26 October development access (derived comparison). Wiz's post is about AI developer platforms and about stored environment variables that grant AI access; Chainstack's page describes neither AI keys nor environment variables, and Wiz says it has no technical detail for Chainstack. Wiz also sells security products, so it has an interest in the pattern being seen.

Other late October reports exist and the Chainstack page does not name them. This site's briefing on CrowdStrike's VAPOR PANDA and ARTEX report is a different report, and nothing read for this briefing connects Chainstack to it. Wiz also lists Northflank and Trigger.dev, on which this site has briefings: Northflank and Trigger.dev. Those are separate incidents with their own notices, and neither names Chainstack.

What the rotation documentation says

The incident page links its rotation instructions to the manage your node documentation. This site read that page, the endpoint security page, the platform API guide and the API key reference, and the account page for passwords and two factor. The node page carries a modified time of 11:13 UTC on 3 November, an hour before the incident page was published (derived from page data). That stamp covers the whole page, so it does not show when the rotation section was written.

Three consequences follow from those lines. First, the only thing that ends the exposure of an old node credential is the customer clicking Deactivate old credentials, so nothing on the Chainstack side expires them. The no downtime design is a reasonable trade, and it also means the speed of the customer's own work sets the length of the risk. Second, a customer who uses a multichain endpoint has a token that the documentation says rotation leaves unchanged. The incident page does not say whether multichain tokens were among the credentials held in the systems the attacker reached, so that customer has a question to put to Chainstack. Third, the page tells customers to "regenerate" platform API keys, and the documentation describes it as creating a new key and deleting the old one.

Chainstack's security page is context, not evidence

Chainstack's security page is a marketing page with no byline. Its page data gives a modified date of 14 July 2026. It cannot show anything about this incident. It does list intended practices that a reader may want to hold next to the timeline: "Environment isolation. Production data is not used in a non-production environment.", "Teams segregation. Access to the various environments is restricted to different teams.", MFA enforcement, hardware token use, and "24/7 monitoring".

The incident page says an attacker reached a development environment on 26 October and some production parts on 29 October, and that Chainstack detected the intrusion on 31 October. It does not say how the attacker moved between environments, which controls applied, or how detection happened. This site does not say any claim on the security page was untrue. It says the incident page gives a reader nothing to test them against.

A ranked checklist for a customer

Chainstack's own list runs: change passwords, rotate node credentials, regenerate platform API keys, watch for phishing. The ranking below is this site's. It puts rotation first because the documentation says old credentials keep working until the customer deactivates them, while a stolen hash still has to be cracked. In practice items 1 to 3 take minutes each and are best done in one sitting. Each item says whose advice it is.

Zoom

Technical details

Chainstack's incident page prints no indicators, no addresses, no file names, no commands, no hashes and no log lines. Wiz's update line says the same of the incident: no tactics or indicators have been shared. There is therefore nothing to copy from the primary to hunt for, and this site has invented nothing. What the documentation does print are the shapes of the credentials a rotation replaces. The first block shows them as the documentation prints them, with placeholders and no real values. They tell a defender what to look for in code and CI.

<network>.core.chainstack.com/<KEY>
Authorization: Bearer YOUR_API_KEY

The second block is this site's own, derived from the hostnames the same documentation prints (the standard and dedicated node hosts and the platform API host). It is a way to find where endpoints and keys live in a repository so that rotation reaches every copy. It is not a detection rule from Chainstack and it does not find credentials that sit in secret stores or CI settings, which need their own search.

grep -rIn -E "core\.chainstack\.com|p2pify\.com|api\.chainstack\.com" .

The question the report leaves unanswered

Chainstack has been plain about dates, about what to do and about its responsibility, and a customer can act on the page today. The same page rests the most important claim, that the node credentials were not read, on "no evidence". It does not say what logs or controls would have shown a read, and its own dates put five days between first access and detection (derived).

So the question for a provider and for its customers is this. When a company says it has no evidence that stored credentials were read, what record would it have had to hold to know, and has anyone other than the company seen it?

Key facts