Northflank October 2026 security incident: exposed secrets

Incident report·30 October 2026

On October 30, 2026, Northflank disclosed a security incident and instructed all users to treat their environment variables as decrypted. Its status page also reported customer confirmations of AI-key misuse. Source: Northflank's incident notice.

The immediate instruction is explicit:

All users should assume their environment variables are decrypted and begin rotation immediately.

Northflank's October 30 update is the source for that guidance.

Reporting cutoff: October 30, 2026, 15:12 UTC. The incident remained identified at that update. Follow the linked notice for subsequent changes. Seekrit publishes this article; the security analysis and deployment recommendations below are ours.

What happened in the Northflank security incident?

Northflank's warning covers workload secrets, secret groups, and global secrets. It enabled PostgreSQL and MongoDB credential rotation for all users and recommended disabling public exposure on addons where enabled. Source: Northflank.

These are publication times, not an established intrusion window. The notice does not establish the full attack path or final affected-account count.

How could secret keys in environment variables be exposed?

An environment variable can hold much more than application configuration. OPENAI_API_KEY can authorize paid inference. DATABASE_URL can contain a database password. A cloud credential might allow access to storage or infrastructure. The impact depends on what each credential can do.

The following explains the general risk, not Northflank's confirmed attack mechanism. Encrypting a value in storage protects the stored bytes. A component that supplies that value to an application still needs a way to decrypt it, and the application eventually receives usable authentication.

An attacker who gains access to that decryption authority, deployment configuration, or a process already holding plaintext may obtain the secret without breaking the encryption algorithm. Masking a value in a dashboard does not remove those paths.

Once copied, a bearer API key can be used directly against its issuer. The attacker does not need to keep using your application. Removing the variable from Northflank therefore cannot invalidate a stolen copy; revocation has to happen at the service that issued it.

What should Northflank users do now?

Use Northflank's current instructions alongside your incident-response process. Our recommended sequence is:

1. Inventory credentials and what they authorize. Include production, preview environments, jobs, build credentials, database passwords, registry tokens, cloud keys, webhook signing secrets, and credentials for other secrets managers. These are categories to check, not a claim that every category was present or misused in this incident.
2. Revoke exposed credentials at their issuers from a trusted device. Prioritize powerful credentials and active misuse. If immediate revocation interrupts service, account for that explicitly. Do not leave an abused key active just to preserve a smooth rollout.
3. Deliver replacements through a trusted recovery path. Follow the provider's containment guidance before supplying fresh secrets to affected systems. Use separate, narrowly scoped credentials for each integration.
4. Verify the running consumers. Confirm that services and jobs use the replacements and that old credentials fail. A dashboard edit alone does not prove that a running process has changed its environment.
5. Review activity at the upstream services. Check API usage, billing, database access, resource creation, and permission changes where logs are available. Preserve relevant evidence. Requests made with a stolen key may never appear in your application's own logs.

If a complete SEEKRIT_TOKEN bundle was stored in an affected environment, treat it as a credential with decryption power. Follow the service-token revocation and key-rotation guidance, and rotate the upstream secrets it could unlock. Revoking a token cannot recall plaintext or keys already copied.

How Seekrit can help prevent this kind of API-key exposure

The useful design change is to keep a reusable upstream key outside the hosting platform that runs the application. Seekrit supports several ways of delivering secrets, and they offer different protection.

Encrypt before storage, and control who can decrypt

In Seekrit's ordinary secret-storage path, clients encrypt values before sending them to the API. Authorized clients hold the private keys needed to unwrap environment keys and decrypt the values. A copy of the secret ciphertext alone is insufficient to recover them. See the security model.

That protection depends on keeping decryption authority separate. The full v2 service-token bundle contains both an authentication secret and a private key. Clients send only the authentication component to the API, but stealing the complete local bundle still gives an attacker both capabilities for its grants.

Similarly, Seekrit's Northflank sync deliberately decrypts authorized values and pushes them into a Northflank secret group. It is useful for distribution; it does not keep those copies outside Northflank. Enabling sync grants the sync engine scoped decryption authority, so this path has a different trust boundary from client-only decryption.

Keep the real API key in an external credential broker

For supported HTTP integrations, run seekrit-proxy on separately controlled infrastructure. The application sends a placeholder such as {{seekrit:OPENAI_API_KEY}}. The broker checks its configured policy, substitutes the real value, and forwards the permitted request.

If neither the upstream key nor a token capable of decrypting it is stored on Northflank, disclosure of Northflank's environment variables cannot reveal that key. This is the specific exposure path the design can prevent.

Keep the broker's deployment credentials and administration outside Northflank too. A sidecar on the same controlled host does not provide this separation. Protect the broker with authenticated ingress and restrict upstream hosts, secret names, HTTP methods, and paths. A placeholder is a name, not authorization.

Stolen broker access can still be used for allowed requests, including costly inference or permitted data access. Apply caller permissions, usage limits, and provider budgets where available. The broker remains trusted, and the receiving API still sees its own credential. This design does not prevent a hosting intrusion or outage, and an HTTP broker does not automatically cover direct database connections or registry pulls.

Make rotation independent of the application deployment

With the external broker already in place, the application's placeholder can stay unchanged when you replace an upstream key. Update the value in Seekrit and verify that the broker has reloaded it through its configured refresh mechanism or a restart. Revoke the old key at the issuer.

That can remove the need to redeploy the application just to change an API key. It depends on the broker's own availability and refresh behavior; saving a new value does not prove every running component has picked it up.

Frequently asked questions

Does syncing Seekrit secrets to Northflank protect the Northflank copies?

No. Sync sends usable secret values to Northflank. Those copies remain within Northflank's trust boundary and need the same incident response as values entered there manually.

Does a Seekrit token in Northflank keep upstream keys out of reach?

Not if it is the complete token bundle with decryption grants. That bundle can fetch and decrypt authorized secrets. Keep it with the external broker when the goal is to isolate upstream keys from the application host.

Would Seekrit have prevented the Northflank incident?

We cannot claim that. A separately controlled Seekrit broker can prevent upstream-key extraction from application environment variables when neither the key nor its decryption authority is stored there. Compromised broker access can still authorize permitted operations.

Start with your highest-value API integration. Use the credential broker guide to move its reusable key outside the application host. Our deployment walkthrough explains the same separation using Railway as an example. For related reporting, read the October API-key security roundup.