For: developers, dApp operators and organization admins who use Chainstack nodes or its API. This article is based on the company's official notice and does not cover attack methods.
Developing: this article will be updated as the organisation publishes more
- Who is affected
developers, dApp operators and organization admins who use Chainstack nodes or its API.
- Confirmed so farSee the table ↓
- Period of unauthorized access
- Reach into production
- Customer account database
1 more
- Investigation
Listed as possibly affected
- Organization names, account holder names
- Email addresses of organization members
- Password hashes
1 more
- Node credentials
- Not yet confirmed
- How many customers are affected
- Which algorithm the password hashes use
- What the third-party component is and how the intrusion unfolded
2 more
- Whether node credentials were actually read
- Whether any misuse (secondary damage) occurs
- What to do nowSee the steps ↓
- Change your password
- Rotate node credentials
- Regenerate platform API keys
3 more
- Find and replace embedded endpoints and keys
- Check for unexpected usage or billing
- Verify anyone claiming to be Chainstack without opening their links
- Where to verify (source)All sources ↓
- Chainstack, "Incident report: what happened and what customers need to do" (English, dated November 3, 2026; checked November 4)
- Last checked
- As of November 4, 2026
Follow-up plans and what we checked
The company's notice is dated November 3 and says it will be updated if new information becomes available. We checked the text of the notice on November 4 and found no change since the November 3 version. The company says it closed its investigation on November 2.
What Chainstack users should do today
Change your password
The company asks customers to change their password, including on any other service where they reused the same one.
- This site's addition: use a password manager so each service has its own password (Choosing a password manager)
- This site's addition: turn on two-factor authentication if it is available to you. The notice does not mention it
Rotate node credentials
The company asks customers to rotate node credentials. It says this is self-service in the console and that current endpoints keep working until rotation is complete, so there is no downtime. The company's documentation explains the steps.
- This site's addition: put the new credentials into your apps first, check that they work, then invalidate the old ones
Regenerate platform API keys
If you use the platform API, the company asks you to regenerate your API keys. Also update CI/CD, automation scripts and operations tools that use them. Delete keys you no longer use instead of recreating them (this site's addition, Environment variables and API keys basics).
Find and replace embedded endpoints and keys
Node endpoints often take the form of a URL that carries credentials, and can sit in app code, config files, CI variables and front ends. This site's view: a URL embedded in a front end is visible to every visitor, so until you rebuild and redeploy after rotating, the old credentials remain in public output.
- Search config, CI secret variables, container environment variables and repository history for old URLs
- Rebuild and redeploy published front ends (build output and source maps)
- Where you can route requests through your own server, avoid handing credentials to the browser
Check for unexpected usage or billing
The company says nodes, the console and the API were not modified and service continued. In case credentials were used, this site suggests checking:
- Whether request counts, callers and methods used on your nodes look unusual
- Whether your bill suddenly rose
- Whether your organization has members or permissions you do not recognize
Verify anyone claiming to be Chainstack without opening their links
The company asks customers to watch for phishing and says it will never ask for passwords, tokens or keys. Do not use links in the email; open the official console or notice page yourself. What is phishing?
① Rotate the credentials in the console
Current endpoints keep working until you finish (company)
↓
② Switch apps, CI and front ends to the new ones and check they work
↓
③ Confirm the old credentials are no longer used
No old URL left in published front ends
What happened (from Chainstack's notice)
The following is based on the incident report the company published, dated November 3, 2026.
October 26, 2026
An external attacker accessed a development environment (company's explanation)October 29
The attacker accessed part of the production environment (company's explanation)October 31
The company detected the intrusion and cut the access paths the same day (company's explanation)November 2
The company finalized its investigation and closed the incident (company's explanation)November 3
Notice published. The company says it is emailing all customersNovember 4
This site checked the text of the notice. No change since the November 3 version found
- Entry point
- An external attacker accessed part of the infrastructure through a third-party component. The notice does not say what the component is
- Context
- The company assesses the incident as part of a broader AI-powered attack campaign reported in late October. It also writes that this does not change its responsibility for what happened in its own environment
- Information that may have been exposed
- Organization names, account holder names, the email addresses of organization members, and password hashes (customer account database). The hash algorithm is not stated
- Node credentials
- Systems holding them were accessed. No evidence they were read, but treated as exposed
- Not included
- Payment method details (the company does not store them). No modification of nodes, console or API; service continued
- Company response
- Cut the access paths, hardening its systems, emailing all customers. It asks users to change passwords, rotate node credentials, regenerate platform API keys and watch for phishing
What is known and not yet known
The state as of November 4, 2026. This table will be rewritten when follow-ups appear.
| Item | What the notice says | Status |
|---|---|---|
| Period of unauthorized access | October 26, 2026 (development) to October 31 (detected and cut off) | Confirmed (company) |
| Reach into production | Part of production accessed on October 29 | Confirmed (company) |
| Customer account database | The attacker accessed it | Confirmed (company) |
| Organization names, account holder names | May have been exposed | Possible (company) |
| Email addresses of organization members | May have been exposed | Possible (company) |
| Password hashes | May have been exposed. Algorithm not stated | Possible (company) |
| Node credentials | Systems holding them were accessed. No evidence they were read, but treated as exposed | Possible (company) |
| Payment method details | Not stored by the company, so not exposed | Not included (company) |
| Changes to nodes, console or API | None; service continued | Not included (company) |
| Number of affected customers | Not stated. The company says all customers are being emailed | Not stated |
| Entry point | A third-party component. What it is is not stated | Under investigation |
| Misuse (secondary damage) | Not stated | Not stated |
| Investigation | Finalized on November 2 and the incident closed. Updated if new information emerges | Confirmed (company) |
Why this says Possible
The company writes that customer account information "may have been exposed", and that it treats node credentials as exposed although it has no evidence they were read. This site keeps the status in the company's own terms. The notice does not show what was actually taken out.
What account data and node credentials can lead to
The following is what can generally happen with this combination of items, not something the company has said happened here.
- Organization names + account holder names + member email addresses: material for convincing messages that pose as the company or a partner
- Password hashes: a hash is not the password itself, but weak or reused passwords can be guessed later. The algorithm is not stated, so strength cannot be judged. Changing the password comes first (What is password hashing?)
- Node credentials: the credentials used to reach an endpoint; whoever holds them can send requests as the customer, which can affect usage and billing. If embedded in a front end, they were visible to visitors anyway
- Reused passwords: if the same password is used on another service, change it there too. How to check whether a password has leaked
What developers and operators should review
Only "a third-party component" has been published as the way in. From the published facts (systems holding credentials were accessed; rotation is possible without downtime), only general review points follow.
- Build so rotation is easy: do not write credentials into code; pass them from environment variables or a secrets manager. One place to change means you can act on the day a notice like this arrives
- Hand fewer credentials to the browser: a URL embedded in a front end stays in public output. Route through your own server, or use controls that restrict where a credential can be used if the vendor offers them (check the vendor's documentation)
- Separate keys by purpose: separate credentials per environment (development, production) and per app keep the impact of rotation small (Environment variables and API keys basics)
- Protect the vendor console: make two-factor authentication mandatory where available and turn on login and key-creation alerts (Choosing multi-factor authentication)
These are general review points and do not mean the company or its users failed to do them.
Sources (public records)
The facts in this article are based on the public information below. We do not speculate on the entry point or the range of data taken, which have not been published.
- Chainstack, "Incident report: what happened and what customers need to do" (English, dated November 3, 2026; checked November 4) — chainstack.com
Update history
2026-11-04: First version. Based on the company's incident report dated November 3, 2026 (checked November 4; no newer update found).
Read next
- A newer developer-service case: unauthorized access to a DigiCert internal system
- A newer developer-platform case: unauthorized access to an internal WorkOS sales app
- Managing API keys and secrets: Environment variables and API keys basics / Leaked credentials that stay valid
- Related incidents: PingCAP (TiDB Cloud) unauthorized access, Railway secrets exposure, Northflank incident and API keys
- Preparing for scam messages: What is phishing?
- Protect your accounts: Choosing multi-factor authentication
- Other 2026 incidents: Data breaches and cyberattacks (Japan and overseas)