Two blockchain-service providers published significant security information during the first week of November. Chainstack issued an incident report on November 3, 2026. Chainalysis expanded its earlier disclosure on November 4 and reported several services restored on November 7. They are separate incidents with different facts and customer actions.
Chainstack asks customers to rotate access
Chainstack says an attacker reached development infrastructure October 26 and parts of production October 29, before access was cut October 31. Its November report says a customer-account database containing names, member email addresses, and password hashes was accessed.
The company treats node credentials as exposed despite lacking evidence they were read. It asks customers to change passwords, rotate node credentials, and regenerate platform API keys where used. It says nodes, the console, and the API were not modified and customer-facing services continued operating.
Rotation is a completed transition
Chainstack’s documentation describes generating replacement credentials, moving applications to the new set, and then deactivating the old set. Both remain usable until that final step, with no automatic timeout. Administrators should therefore verify completion rather than stop after obtaining a replacement.
The node procedure replaces endpoint tokens, password-based access, and relevant gRPC credentials together. It does not change a separate multichain authentication token, according to the guide. Teams need an inventory of the actual credential types their integrations use.
Chainalysis revises the scope of its incident
Chainalysis’s November 4 update says names, usernames, password hashes, and live tokens for all users were exposed. It also reported apparent unauthorized access to some KYT accounts and directly notified those customers. The company said it still had no evidence of investigation-data access or manipulation of attribution data.
On November 7, Chainalysis said Reactor, KYT’s interface and API, and Address Screening were back online with enhanced security. It directed customers to specific reconnection instructions. That update should not be generalized into a declaration that every product or integration had recovered.
Apply each provider’s instructions separately
Our operational analysis is to list the affected account, credential owner, dependent service, and completion evidence for each provider. A shared spreadsheet or incident record should distinguish requested rotation, application deployment, and confirmed revocation. None is a substitute for the others.
Use an authenticated, known vendor route to obtain current instructions. Incident announcements create opportunities for impersonation, so avoid sending credentials through support messages or following unexpected reset links without verification.
For applications that depend on screening or analytics availability, reconcile work delayed during the interruption. A service returning online does not establish that all queued requests were replayed successfully or that every downstream system received the intended result. Decide who checks that backlog and how exceptions are resolved.
Keep attribution claims bounded
Both security and recovery accounts can evolve as evidence improves. Record the date of the provider update used for a decision, and revisit it when the vendor changes its findings. The immediate priority is verified containment and reliable customer access, without assuming a shared attacker or mechanism merely because incidents occurred in the same industry.