Northflank Security Incident (October 30, 2026): What Happened and How to Protect Your Secrets

First, to the Northflank team: we are sorry this happened to you, and we wish you a fast recovery. Northflank competes with Qovery, and we would never wish this on anyone. A security incident can happen to any company, including ours. The engineers working on it today have a hard few days ahead, and we hope their customers are safe again soon.

I am writing this because many teams who use Northflank are asking what to do this week, and because the same question applies to every deployment platform, ours included: if the platform is hacked, what can the attacker read?

This article sticks to what Northflank and its users have said in public. When something is not known, I say so.

What happened at Northflank on October 30, 2026?

Northflank's status page lists a "Security incident" marked as a major outage. Here is the timeline it gives, in UTC:

Northflank's advice covers secrets in workloads, secret groups and global secrets. It also asks users to turn off public access on addons (Northflank's managed databases and services) where it is enabled.

On the morning of October 31, the status page still marks Networking, Certificates, Services, Addons, Jobs, Builds, and Logs and Metrics as a major outage. The Northflank app and API are shown as operational.

The incident reached the front page of Hacker News the same afternoon. One user wrote that a small app on Northflank now needed new RevenueCat, Apple and AI keys. Another listed six attacks on hosted platforms since September, including Railway.

What we don't know yet

The root cause. Northflank has not said how the attacker got in. The timeline shows network policy patches, which suggests a network path inside the platform was closed, but Northflank has not confirmed what that path was. Its 23:38 update says the AI key abuse "may be consistent with the broader pattern of attacks targeting AI credentials", without naming a link.

Who is affected. The guidance is written for all users. There is no list of affected projects or regions.

BYOC customers. Northflank sells a BYOC option where workloads run in the customer's cloud account. Its BYOC page says "workloads, databases, volumes, and secrets run inside your VPC." The status page does not separate BYOC users from the others. If you run Northflank BYOC, ask Northflank directly, and rotate anyway until they answer.

We will update this article when Northflank publishes more.

What should you rotate first?

Rotate the secrets an attacker can turn into money or access fastest. The order below is the one we used in our Railway rotation guide , which has the full step-by-step checklist.

AI provider keys (OpenAI, Anthropic, and others). Northflank users already report misuse. Revoke the old key, create a new one, and set a spending limit on it.

Payment and billing keys (Stripe, RevenueCat, App Store Connect). Stripe can keep the old and new keys working together for a short time, so you can deploy the new key before you revoke the old one.

Cloud credentials (AWS access keys, GCP service account keys). Replace long-lived keys with IAM roles where you can.

Database passwords. Northflank enabled rotation for its Postgres and MongoDB addons. For external databases, create a second user, deploy it, then delete the first.

Session and JWT signing keys. Changing them logs every user out, so plan the timing.

OAuth client secrets, webhook secrets, Git tokens and registry credentials.

Rotate today even if you see no misuse yet. In the cases Wiz studied, the stolen keys were tested within 30 minutes, but the heavy use started four and seven days later. Each day you wait gives the attacker more time.

For each key, follow the same four steps: create the new one, deploy it, check that the app works, then revoke the old one. Revoking first is the fastest way to cause your own outage.

When you are done, check the provider side. Look at usage and billing for each rotated key over the last few days, and report anything unusual to Northflank support and to the provider, as Northflank asks. Northflank turned on audit logs for all customers on October 31, so check them for changes you did not make. Look for new API keys, users, SSH keys, OAuth apps or webhooks that you did not create. An attacker who had your keys may have used them to create new ones.

Two more checks, based on the Wiz report:

your logs for the IP addresses in the table in the section, for example in AWS CloudTrail or your AI provider's usage logs.

Restrict your new AI keys. Limit each key to the models and regions you use, and set a quota or spending limit. In Wiz's second case, a key limited to one group of AWS regions blocked thousands of calls.

Why do deployment platforms keep losing customer secrets?

A deployment platform has to give your app its secrets. So at some point it stores them, decrypts them, or both. When the platform is shared by many customers, the store holds the secrets of all of them.

That makes a deployment platform a good target. One way in gives the attacker database passwords, cloud keys and AI keys for many companies at once. AI keys are the easiest to use right away, which matches what Northflank users report.

What Wiz's Black October report adds

Wiz's Black October report , published on October 30, lists at least nine AI developer platforms that disclosed incidents in October 2026: Fireworks AI (Oct 6), Andromeda (Oct 9), Zeabur (Oct 14), Lightning AI (Oct 15), OpenCode (Oct 16-17), Railway (Oct 20), Warp (Oct 23), CommandCode (Oct 28) and Northflank (Oct 30). Zeabur is shutting down after its incident. Wiz writes that "all public reports highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access."

The ways in were different. Fireworks, Zeabur and Lightning AI point to stolen credentials. Railway believes the attacker got in through "privilege escalation in our build infrastructure." Warp points to a third-party vendor, and OpenCode to a "legacy system." Fireworks, OpenCode and Warp report signs of an "agent swarm," meaning attackers used AI agents to move faster. Wiz says "there is no single vulnerability or dependency linking these attacks."

Wiz followed two stolen AWS Bedrock keys from start to finish:

Within 30 minutes of the theft, one test call checked that each key worked.

For several days , a small script checked the keys a few times a day to make sure they were still valid.

Four and seven days later , the keys were used at scale. One made 800,000 calls in 30 hours, the other 1.7 million calls in 13 hours, mostly to Claude models. Wiz estimates the two cases "likely ran up over $100k in usage."

The keys showed up in resale pools , websites that sell cheap access to AI models. Wiz names two of them.

The second key did less damage because it was restricted to one group of AWS regions. Thousands of calls failed, and the account's regional quotas slowed down the rest.

Wiz shares these IP addresses, which tested or used stolen keys. Wiz says it has no evidence that links them directly to the platform breaches, so treat a match as a reason to investigate.

A Hacker News commenter described a second problem. Platforms usually let users read a variable back in the dashboard or the CLI. If a platform can show you a secret, then anyone who takes over the platform's API, or a user's session, can read it too.

Encryption at rest does not solve this. Railway's preliminary report says its variables were encrypted, and some were decrypted anyway. Something has to decrypt a secret to deploy your app, and that something can be attacked.