Northflank Tells Customers to Assume Every Environment Variable Was Decrypted, the Ninth AI Developer Platform Incident on Wiz’s October List
Northflank told customers on October 30 to assume every environment variable was decrypted. Wiz counts nine AI developer platform incidents in October, and the vendors’ own accounts differ on cause...
Northflank, a cloud platform that lets developers run applications, containers, databases and AI workloads, told all customers on October 30 to “assume all environment variables have been decrypted” and to rotate every secret stored on it. Its incident page dates the first alert, from Wiz, to 11:43 UTC and the instruction to assume decryption to 13:58 UTC. At 23:38 UTC it added that users had reported “unauthorised use of AI API keys supplied to the Northflank platform.” Northflank has not said how attackers got in or how many customers are affected. When we read its status feed at 10:17 UTC on November 1, the incident was still marked Identified and the latest update, a secret-rotation option for RabbitMQ add-ons, was dated 23:31 UTC on October 31. The page headline said “Experiencing partial outage,” while seven platform components, including Networking, Services, Addons and Builds, were each listed as “Major outage.”
Table Of Content
- What Northflank has posted, in order
- Nine platforms, nine accounts
- What Wiz saw when stolen keys were used
- Where the accounts differ
- The AI-agent claim rests on short statements
- The link between the incidents is an inference so far
- Why Zeabur is closing, and who pays
- What customers of these platforms should do now
- What is still unknown
- Sources and method
The same day, Wiz published a report titled “Black October” for AI Developer Platforms, which counts “at least nine AI Developer Platforms” that “have disclosed incidents over the course of the month” and puts Northflank last. We read each vendor’s own statement, and they do not tell one story. Only Zeabur has shared what Wiz calls “a full write-up,” built from its logs, and it blames Zeabur’s own plaintext admin credentials and does not describe an AI-driven attacker. The claims that attackers used AI agents rest on short statements by executives at Warp, OpenCode and Fireworks, and on Railway’s assertion that the attacker had “abliterated models.” Below we set out Northflank’s timeline, a table of what each of the nine says, what Wiz saw when stolen cloud keys were used, where the accounts differ, what customers should do now, and what is still unknown.
What Northflank has posted, in order
Times are UTC on October 30 unless marked. They come from the timeline and the update list on Northflank’s incident page, which lists the 13:05 patch twice. The elapsed times after the table are our arithmetic.
| When | What Northflank posted |
|---|---|
| 11:43 | “Wiz threat alert,” the first entry in Northflank’s timeline. |
| 11:44 | Northflank engineers review the alert. |
| 12:02 | “Initial network policy patch.” More patching follows at 12:50 and 13:05, and Wiz’s incident response team is requested at 13:00. |
| 13:40 | Status “Investigating”: “Rotate environment variables immediately.” |
| 13:58 | Status “Identified”: “Assume all environment variables have been decrypted. Disable/rotate all keys.” |
| 15:12 | Secret rotation is enabled for Postgres and MongoDB add-ons. Users are told to rotate secrets on workloads, secret groups and global secrets, and the update says “Multiple users are confirming that their AI keys have been used.” |
| 19:28 | “Our investigation is ongoing. We have no further confirmed findings to share at this time.” The guidance is to assume all environment variables have been compromised and to disable public access to add-ons. |
| 23:38 | “Users have reported unauthorised use of AI API keys supplied to the Northflank platform.” Customers are told to revoke credentials with their issuing providers and to review AI provider usage and billing logs. Northflank says the reports “may be consistent with the broader pattern of attacks targeting AI credentials” and that “Similar IP addresses are contained in” Wiz’s report. |
| Oct 31, 01:04 | Audit logs are enabled for all customers, including free users. |
| Oct 31, 13:34, 22:32 and 23:31 | Secret rotation becomes available for MySQL and Redis add-ons, then MinIO add-ons, then RabbitMQ add-ons. |
From Wiz’s alert to the instruction to assume decryption is 2 hours 15 minutes by these timestamps, and the first patch landed 19 minutes after the alert. The page does not say how the attacker got in, which customers or how many were affected, when access began or ended, or what the network policy patch changed. BleepingComputer put those questions to Northflank and had no reply when it published. Two things should be kept apart: the instruction to assume decryption is a precaution (the page says “assume”), while the AI-key abuse is something customers reported and Northflank confirmed it received. The page has posted no customer-impact update since the rotation notices, so we cannot tell from it whether customer workloads are actually down.
Nine platforms, nine accounts
Wiz lists Fireworks AI (October 6), Andromeda (October 9), Zeabur (October 14), Lightning AI (October 15), OpenCode (October 16 to 17), Railway (October 20), Warp (October 23), CommandCode (October 28) and Northflank (October 30). Those are not all the same kind of date. Andromeda’s own post says it identified the incident on October 13 and believes activity began “on or about October 9th,” while Fireworks’ date is when it identified the activity. The table uses each vendor’s own wording and dates, in UTC unless the vendor used another zone.
| Platform | Dates in the vendor’s account | What the vendor says was reached | Cause and scale it gives |
|---|---|---|---|
| Fireworks AI | Identified October 6; bulletin October 9, last updated October 10 (Pacific time) | Environment variables “used in evaluation jobs in a limited number of customer accounts,” including API keys and tokens stored as secrets. No evidence of access to customer models, datasets, training data, prompts or outputs. | “Unauthorized use of internal Fireworks credentials.” “A limited number of customer accounts,” no count. |
| Andromeda | Identified October 13; activity began “on or about October 9th”; post dated October 20 | “Exposure of certain Andromeda and customer credentials.” No evidence of access to customer models, datasets or training data. | “We have not yet established the root cause.” Calls it part of an “industry-wide attack.” “A limited number of customer accounts.” |
| Zeabur | Attacker active October 14 to 15, last recorded activity October 15 at 21:05; wind-down announced October 17; report October 19 | Environment variables in the platform database; commands run in 865 database services; root sign-ins to 101 dedicated servers. | “Long-lived admin credentials were stored in plaintext and could be used from the public internet.” “The root cause of this incident lies with Zeabur.” |
| Lightning AI | Identified October 15 at 23:00; all user access revoked October 16 at 01:00; read-only Drive access restored October 28 | “Certain customer credentials were compromised to gain access to environments and connected third-party services.” | “Unauthorized access to credentials.” No count. Studio, Jobs and Deployments access was still to follow in the October 28 update. |
| OpenCode (The Hacker News, BleepingComputer) | Intruder reached a system on the night of October 16; earliest possible key exposure October 17 at 00:30; users emailed October 17 | Provider keys that users had saved in OpenCode Console. | A “legacy system,” as The Hacker News reports it. “1.4% of OpenCode Console users.” Calls the breach “related to a large-scale distillation attack.” |
| Railway | Attack window October 20 at 13:58 to October 22 at 03:32; disclosure October 21; preliminary report October 22 | Encrypted environment variables for a subset of workspaces, some of them decrypted. Railway cannot tell which specific keys. | “Potential privilege escalation in our build infrastructure.” “At most 1.85% of all workspaces,” about 100,000, with more customers contacted as high risk. |
| Warp (CEO’s post) | Became aware Friday, October 23; CEO’s post October 26 | “A limited amount of agent trace and telemetry data.” | “Likely starting with a hole in a vendor dependency.” “An upper bound of roughly 1% of Warp users.” |
| CommandCode | Detected and stopped October 28 (post at 23:16) | All API keys revoked; “no evidence that any users were impacted” so far. | “A large-scale distillation attack targeting Anthropic and OpenAI models.” No scale. |
| Northflank | Wiz alert October 30 at 11:43 | Customers told to assume all environment variables were decrypted; users report abuse of AI API keys. | Not disclosed. |
Six of the nine name some way in, at very different levels of detail: credentials (Fireworks, Zeabur and Lightning AI), a privilege escalation in build infrastructure (Railway), a vendor dependency (Warp) and a legacy system (OpenCode). Andromeda, CommandCode and Northflank name none. Only three give a share of their customers or workspaces: Railway (at most 1.85% of workspaces), OpenCode (1.4% of Console users) and Warp (an upper bound of roughly 1% of users). Zeabur counts servers and database services, and the rest say “a limited number” or nothing.
What Wiz saw when stolen keys were used
Wiz says it observed “downstream abuse of enterprise credentials” that it can attribute to one of the vendor breaches, and it describes two cases without saying which vendor held the keys. LLMjacking, in BleepingComputer’s description, means using stolen credentials to run AI models on another organization’s account. In both cases the first unauthorized call came within 30 minutes of the reported credential access at the vendor: “a single InvokeModel from a residential IP address, in a one-minute sweep that tested stolen keys across multiple organizations.” The call asked for Claude Fable 5.1, failed and “fell back to Opus 5.5, which worked.” For days afterward each key saw only 14 to 120 calls a day from the same small client, which Wiz reads as one job checking that the keys stayed valid.
- Case A. Four days after the first test call, a rotating proxy pool sent one call per model across vendors. A few hours later a boto3 script on a residential address listed Bedrock and EC2 quotas, and bulk traffic started 22 seconds after that. Over 30 hours, before the key was remediated, Wiz counts about 800,000 Bedrock calls, about 90% of them successful, with Opus models three quarters of the successful calls. The key’s policy allowed
global.*cross-region inference profiles, and only about 6% of calls were throttled. - Case B. This key was restricted to
us.*inference profiles. Seven days after the first test call it appeared in what Wiz calls an apparent reseller pool, which spent about four hours failing because it asked forglobal.*. Early the next morning a checker found the workingus.*model IDs, and about two hours later a script on a hosting address retested both and listed quotas, “the same script, down to the version string” as in Case A. Over 13 hours that one address made about 1.7 million calls, more than a million of them successful, and nearly all the rest were throttled by regional quotas.
At list price, Wiz says, the two cases “likely ran up over $100k in usage.” It adds that it is “not able to definitively establish the relationship between these reselling organizations and either the initial compromise” or the bulk abuse. Those actors did have the keys and tested them, which Wiz reads as a sign of “a robust market for this type of credential.” By our arithmetic the two floods ran at about 27,000 calls an hour in Case A and about 131,000 an hour in Case B. Two readings of Wiz’s timeline are ours. First, a narrow inference-profile policy plus regional quotas slowed the stolen key in Case B but did not stop it, since more than a million calls succeeded in 13 hours. Second, bulk traffic began about four days (Case A) and about eight days (Case B) after the first test call, so rotating a key promptly after a vendor’s notice, and not only after a billing alert, is the step most likely to matter.
Where the accounts differ
The AI-agent claim rests on short statements
Wiz’s headline calls the incidents “a series of agentic attacks,” and the same report says “most of these security incidents are still being analyzed, and detailed technical information is not available.” The public record for the agent claim is short. Warp CEO Zach Lloyd wrote that the attack “appears to have come from an agent swarm using a very sophisticated penetration and escalation technique,” likely starting in a vendor dependency. Fireworks CEO Lin Qiao replied on X on October 10: “From the behavior, it seems agentic.” OpenCode co-founder Dax Raad wrote on October 18 that attackers had been “non stop trying to attack our systems for the past 48 hours” and “we basically need agents going 24/7 because that’s what they have.” Railway says “Initial evidence leads us to believe that the malicious actor had access to abliterated models and substantial compute resources” (models altered so they stop refusing requests) and says it cannot yet share the details of the exploits. Zeabur’s write-up, the most detailed in the set, describes what the attacker did from logs: it used leaked credentials, read environment variables and database tables, and was “mainly looking for API keys they could use directly, especially keys for AI services.” It does not describe the attacker as AI-driven. For what attacker-run agent tooling has looked like when it was exposed, see our report on the open Cairn panels.
The link between the incidents is an inference so far
Railway’s October 21 post calls its incident “part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers,” and Andromeda calls its own activity part of an “industry-wide attack.” The Cloud Security Alliance’s October 23 note found that “No vendor has publicly linked these incidents to a single actor, and the campaign framing so far comes from Railway alone.” The note also says it “was generated with AI assistance and has not undergone official CSA review and approval processes,” and its table lists the compromise in our LiteLLM report as “related; unlinked.” BleepingComputer reports that Wiz has not confirmed the nine were the work of the same attackers.
The one technical overlap in the public record is an IP address, 23.106.46[.]239. Zeabur lists it among its indicators, and Wiz’s table lists it as “Reported by Zeabur and later used for credential checking.” Wiz says a subdomain on that address hosted a page on October 8 whose title named ARTEX and, in Chinese, a phrase Wiz translates as “autonomous penetration testing console.” Elsewhere Wiz dates an “Artex landing page” on that address to “mid-October.” ARTEX is the framework named in our reports on the ConnectWise intrusions and on Korean financial firms. Zeabur cautions that its attacker “made heavy use of proxy servers, and the same IP may be shared by different people,” and Wiz says the addresses in its table are “suspected to be linked to LLM token abuse and resale” and that it has no evidence linking them directly to the nine incidents.
Why Zeabur is closing, and who pays
Wiz says Zeabur “will be shutting down due to this incident.” Zeabur’s founder gives more reasons: growth running into limits, an architecture that became increasingly complex and hard to maintain, and two incidents in two months, writing that “The two security incidents in the second half of this year have made the shortcomings in our security and operations even clearer.” On cost, Railway says it “is unable to refund customers for spend performed with compromised API keys” and tells customers to contact their AI token providers. OpenCode’s email to affected users mentions possible reimbursement, according to BleepingComputer. Zeabur says it accepts compensation claims through its support team. Northflank’s page does not address it.
What customers of these platforms should do now
The vendors agree on the core step, and it is the one the Cloud Security Alliance note gives: “rotating keys held on affected platforms at the issuing provider, not just deleting them from the intermediary.”
- Rotate at the issuer, not only on the platform. Fireworks says “Removing a stored secret alone does not invalidate the underlying credential,” and Northflank tells customers to “Revoke existing credentials with their issuing providers, generate replacements, and update the affected secrets and workloads in Northflank.” The Hacker News makes the same point about OpenCode: “Deleting the key from Console does not revoke it.”
- On Northflank, rotate secrets in workloads, secret groups and global secrets. Use the rotation now offered for Postgres, MongoDB, MySQL, Redis, MinIO and RabbitMQ add-ons, disable public access to add-ons where enabled, read the audit logs that are now on for every account, and review AI provider usage and billing logs.
- Treat a provider’s revocation email as a prompt, not a verdict. Railway says it gave vendors such as GitHub and SpaceXSI every API key on its platform, so “Users being notified by vendors about revocation does not imply that their credentials were impacted by the incident.” Check anyway.
- Inventory where each key lives. The Cloud Security Alliance note (see the caveat above) tells security teams to “build a quick inventory of every third-party service that holds a copy of each production inference key,” because that inventory is the scope of exposure for the next disclosure.
- Cap what a stolen key can spend and trace where it leaked. The same note recommends a separate key “per platform and per application,” provider-side spending caps, rate limits and usage alerts on every key, and injecting inference credentials “at runtime from an organizational secrets manager rather than pasting them into platform dashboards.” The Hacker News lists OpenCode’s and the providers’ steps as a spend limit or alert at the provider and one key per tool.
- Look for the quiet phase (our suggestion). In Wiz’s two cases the bulk traffic came days after a single test call and a trickle of 14 to 120 calls a day, a volume unlikely to trip a spend alert. The CSA note says to review provider-side usage and billing logs for “spikes in volume, unfamiliar model selections, or traffic from unexpected regions.” If you use Bedrock, also look in your model invocation logs or CloudTrail, whichever you have enabled, for
InvokeModelcalls from addresses you do not recognize, including low-volume regular ones.
What is still unknown
- How the attacker reached Northflank’s secrets, how many customers were affected, and when access began and ended. The page says only that it has “no further confirmed findings to share.”
- Whether one actor is behind the nine. Wiz itself says there is “no single vulnerability or dependency linking these attacks.”
- Which vendor’s breach produced Wiz’s two cases, and whether the boto3 version string Wiz matched across them is the one Zeabur lists (
Boto3/1.43.111 (Linux 6.12.86)). Wiz does not print its string. - Whether Warp’s vendor, OpenCode’s legacy system and Railway’s build infrastructure are connected. Warp has not named the vendor.
- Whether Northflank’s seven platform components are as down as the status page lists them. We read the page at 10:17 UTC on November 1 and did not test any platform.
Sources and method
We read Northflank’s status page, incident page and status summary feed between about 10:00 and 10:17 UTC on November 1, Wiz’s report (dated October 30, by Benjamin Read and Rami McCarthy), and each vendor’s statement: Fireworks AI, Andromeda, Zeabur’s incident report and shutdown post, Lightning AI, Railway’s disclosure and preliminary report, and the X posts from Warp’s CEO, CommandCode, Fireworks’ CEO and OpenCode’s co-founder, which we read through the api.fxtwitter.com mirror. For OpenCode we relied on The Hacker News and BleepingComputer for the wording of its announcement and email, and for Warp on BleepingComputer for context. The Cloud Security Alliance page refuses scripted requests, so we read its note as the published PDF. Wiz’s Threat Intel Center advisories are addressed to Wiz customers and we did not read them. The two cases in Wiz’s report are Wiz’s own telemetry and we could not check them. The 2 hours 15 minutes, 19 minutes and calls-per-hour figures are our arithmetic. We did not probe any of these platforms and did not open any of the third-party sites or addresses named in Wiz’s report.








No Comment! Be the first one.