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

Key Points:

• What happened. On October 30, 2026, Northflank reported a security incident. Its status page tells every user to "assume all environment variables have been decrypted" and to rotate all secrets. Users report that their AI keys were already used.
• What is not known yet. As of the October 31, 13:34 UTC update, Northflank has not published a root cause or a list of affected customers. The page does not say whether Bring Your Own Cloud (BYOC) customers are affected.
• What to do today. If you use Northflank, rotate AI and payment keys first, then database and cloud credentials, then the rest. Check provider usage logs for the days before the incident.
• Why this keeps happening. Wiz's Black October report lists nine AI developer platforms that disclosed incidents in October 2026, including Railway on October 21 and Northflank. Attackers went after stored environment variables, especially AI keys. A shared platform stores the secrets of all its customers in one place, so one break-in pays off many times.
• What we learn at Qovery. This can happen to any platform, including ours. Qovery is not a PaaS and does not host customer apps. Your apps run in your own cloud account, Qovery reaches it through an IAM role you can delete, and secret values can stay in your own secret manager. Qovery still stores the secrets you add in the Console, encrypted, and this article says so plainly.

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 evening 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.

1. 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.
2. 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.
3. Cloud credentials (AWS access keys, GCP service account keys). Replace long-lived keys with IAM roles where you can.
4. Database passwords. Northflank enabled rotation for its Postgres and MongoDB addons on October 30, and for MySQL and Redis on October 31. For external databases, create a second user, deploy it, then delete the first.
5. Session and JWT signing keys. Changing them logs every user out, so plan the timing.
6. 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:

• Search your logs for the IP addresses in the table in the next 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:

1. Within 30 minutes of the theft, one test call checked that each key worked.
2. For several days, a small script checked the keys a few times a day to make sure they were still valid.
3. Four and seven days later, the keys were used at scale. One made about 800,000 calls in 30 hours, the other about 1.7 million calls in 13 hours, mostly to Claude models. Wiz estimates the two cases "likely ran up over $100k in usage."
4. 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.

How does Qovery limit the damage of a breach like this?

Qovery deploys code too, and nothing in this section means it could not happen to us. The honest answer has two parts: what we do not hold, and what we still hold.

Qovery does not host your apps, and never will

Northflank and Railway are managed PaaS products: they run their customers' apps on infrastructure they operate. Qovery does not, and we never will. We built Qovery from day one around one rule: the control plane (Qovery) is separate from the data plane (your cloud account).

Qovery installs and manages a Kubernetes cluster in your own AWS, GCP, Azure or Scaleway account, or connects to a cluster you already run. Your apps, databases and TLS keys run there, and your logs are stored there. There is no Qovery-run fleet of servers where customer apps sit next to each other, so there is no shared runtime for an attacker to move through, and another customer's code never runs in your cluster.

Qovery's control plane sends deployment instructions to the Qovery engine over encrypted gRPC or TLS. It holds your configuration and status, and the secrets you choose to store in Qovery. The security overview describes this split in detail.

Where your builds run

Railway's entry point was its build infrastructure. By default, Qovery builds your images on a pool of build workers that Qovery runs. Each build gets a disposable, short-lived build node. Only the secrets you mark for the build are passed to it, and they are not stored in the image. If you prefer builds to stay in your own account as well, you can choose to run them in your own cluster instead.

Secret values can stay in your secret manager

With the Secret Manager integration, you give Qovery a reference such as prod/payments/stripe instead of the value. The External Secrets Operator, running in your cluster, reads the value from AWS Secrets Manager, AWS Parameter Store or GCP Secret Manager and passes it to your app. The value never goes through Qovery. If Qovery's control plane were breached, the attacker would find the path to your secret but not the secret itself.

Two limits to know. This integration is available today on Qovery-managed clusters on AWS and GCP. And the operator reads the values at deploy time, so after you rotate a secret you redeploy the services that use it. For the most sensitive secrets, your app can also read them at runtime with an IAM role, which needs no redeploy. Our article on how Qovery stores secrets shows both setups.

Qovery reaches your cloud through a role you control

On AWS, Qovery recommends the STS assume role setup. Qovery gets short-lived credentials from an IAM role in your account, instead of storing a permanent access key. Since October 23, the role also requires your organization ID as the sts:ExternalId, so it only accepts requests made for your organization (details). On GCP, Workload Identity Federation works the same way.

The role needs wide permissions, because Qovery creates and upgrades clusters, networks and databases for you. You keep control of it: every call Qovery makes with the role appears in your AWS CloudTrail, and you can delete the role at any time. Qovery then loses access to your account in one step, and your apps keep running in your cluster.

What Qovery still holds

Secrets you add in the Qovery Console, without a secret manager, are stored in Qovery's database. They are encrypted with AES-256 and a key unique to your organization, hidden in the Console, and cannot be read back through the API. They are decrypted when a deployment needs them.

Write-only secrets close the read-back path described above, because no screen or API call shows the value. They do not close every path, and no platform is immune to the ways in that Wiz lists, including ours. An attacker with deep enough access to our control plane could reach what the deployment process decrypts. That is why, after the Railway and Northflank incidents, I recommend keeping production secrets in your own secret manager and giving Qovery only the references.

I have always told my team that this can happen to anyone, and a breach like this is one of my biggest fears at Qovery. That is why we have invested in security since the first days of the company. It is a large part of our budget, and we will keep investing in it.

Qovery is SOC 2 Type II certified, and independent experts run a penetration test every year with one main goal: stealing customer secrets. Reports are on our trust center. We do our best to keep our customers safe, and none of that makes a breach impossible. It is why we would rather you hold the values yourself.

Questions to ask any deployment platform this week

Use these with Qovery, Northflank, Railway or any other vendor.

To the Northflank team and its users: we hope you are back to normal soon.