🚨 FortiBleed Turns 430,000 Firewalls Into a Ransomware Feed: Why "Exploitable" Beats "Reachable"

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: Reachable vs. Exploitable — The Distinction That Decides What You Actually Fix (continue reading) 

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter

The week did not hand us a single marquee breach. It handed us five variations on the same failure: the credential or key an attacker wants is now reachable, and the only question left is whether the surrounding context makes it exploitable. FortiBleed turned tens of thousands of exposed FortiGate firewalls into a working credential feed for two ransomware crews. A Langflow authorization-bypass flaw let one operator read other tenants' flows and walk off with their LLM and AWS keys. Fake Paysafe and Skrill SDKs sat in build pipelines returning fake success while reading AWS and GitHub tokens out of the environment.

That mechanic is exactly what Harry Wetherald, co-founder and CEO of Maze, spends his days on. His argument: reachability tells you a vulnerability might be exploitable; exploitability tells you an attacker actually has everything needed to trigger it — and reasoning across code and cloud context to answer the second question is the shift AI finally makes possible.[Listen to the episode]

⚡ TL;DR for Busy Readers

• 🚨 FortiBleed is now a ransomware pipeline. SOCRadar tied the mass FortiGate credential theft (~430,000 firewalls targeted) to the INC and Lynx crews. Reset FortiGate admin and VPN credentials and enforce MFA today — the exposure already happened at config-read time.

• 🚨 A CVSS 6.1 flaw did the real damage. CISA's July 7 KEV batch includes Langflow's cross-tenant IDOR (CVE-2026-55255), used to steal other tenants' LLM and AWS keys, alongside a CVSS 10.0 ColdFusion flaw exploited within hours. Patch by July 10; pull exposed Langflow behind auth and rotate every reachable key.

• Fake payment SDKs raided build pipelines. 17 typosquatted Paysafe/Skrill/Neteller packages on npm and PyPI harvested AWS, GitHub, and npm tokens from CI runners. Audit runner env-var scopes; move build secrets to short-lived OIDC.

• Your own bucket can be turned against you. Unit 42 detailed a global-namespace bucket-hijacking flaw that reroutes live data streams to an attacker-owned bucket with a reused name. Never delete-and-forget a bucket name referenced anywhere.

• ADFS can hand over a live signing key. Mandiant showed active ADFS token-signing keys recoverable from machine DPAPI, enabling MFA-bypassing SAML forgery. Audit AutoCertificateRollover state and certificate drift.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1.  FortiBleed credential-theft campaign confirmed as a ransomware pipeline for INC and Lynx

Primary source: BleepingComputer 
Reporting: SOCRadar STRU · Recorded Future · SecurityWeek

What Happened

SOCRadar's threat research unit tied the mass FortiGate credential-theft campaign known as FortiBleed to the INC and Lynx ransomware operations. This is the first confirmed link between the harvesting and downstream ransomware deployment. Investigators found an operator with FortiBleed infrastructure access logged into both the INC and Lynx negotiation panels, and INC victims overlapping with FortiBleed data. The campaign is assessed to have targeted more than 430,000 internet-facing FortiGate firewalls, deployed packet sniffers on roughly 19,000 devices, and cracked configuration-file hashes into verified working administrator credentials for tens of thousands of systems.

Why It Matters

The FortiGate SSL-VPN is the identity edge for most hybrid enterprises, and a cracked admin credential there is not a vulnerability to patch because it is a valid login that survives patching. The credential inventory is now demonstrably feeding two active ransomware crews, turning "we have MFA-less VPN admins" from a hygiene finding into a named, in-progress ransomware precursor.

Action for defenders: Reset all administrative and VPN credentials on internet-facing FortiGate devices, enforce MFA on every admin and remote-access account, and pull VPN auth logs for anomalous admin logins and any sign of packet-capture tooling.

2. CISA adds four exploited flaws to KEV, including a Langflow cross-tenant IDOR that steals LLM and AWS keys

Primary source: CISA KEV alert 
Reporting: The Hacker News 
Analysis: Sysdig

What Happened

On July 7 CISA added four actively exploited flaws to the KEV catalog with a July 10 federal deadline: Adobe ColdFusion path traversal CVE-2026-48282 (CVSS 10.0), two JoomShaper/PageBuilder unauthenticated file-upload RCEs (CVE-2026-56290 and CVE-2026-48908, both CVSS 10.0), and Langflow authorization-bypass IDOR CVE-2026-55255 (CVSS 6.1). Sysdig reported a single operator chaining the Langflow IDOR with an unauthenticated RCE (CVE-2026-33017) against internet-exposed instances between June 22 and June 25, using the cross-tenant IDOR to read other tenants' flows and steal their LLM-provider and AWS keys. The ColdFusion flaw was exploited within hours of disclosure.

Why It Matters

The CVSS ordering is inverted from the risk — the 6.1 Langflow bug, not the 10.0s, is the one that handed an attacker a live credential set for someone else's cloud account. An AI-orchestration platform is a credential vault, and a cross-tenant IDOR against it is a supply route into every cloud those flows touch.

Action for defenders: Patch all four by July 10; for Langflow, pull any internet-exposed instance behind authentication immediately and rotate every LLM-provider and cloud key any hosted flow could reach — treat exposed instances as already harvested.

🛠 If you only do one thing this week: Find every internet-exposed AI-orchestration or agent platform (Langflow and anything like it), put it behind authentication, and rotate every LLM and cloud key it could reach. This week's Langflow story is the proof that a "medium" CVSS flaw on a credential-holding platform is the one that actually converts to cloud compromise — reachable became exploitable the moment those keys were sitting there.

☁️ 3. Fake Paysafe, Skrill and Neteller SDKs on npm and PyPI harvest CI/CD secrets

Primary source: Socket 
Reporting: BleepingComputer · The Hacker News

What Happened
Socket flagged a coordinated cluster of 17 malicious packages — 13 on npm, 4 on PyPI, typosquatting the Paysafe, Skrill and Neteller payment SDKs, published July 7. The packages expose the expected payment APIs and return fake success responses while collecting environment variables and exfiltrating them, including via an Ngrok endpoint and an AWS-hosted C2. Captured variables include PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN and NPM_TOKEN. The npm packages were flagged as malicious within roughly six minutes of publication, each shipping four rapid versions with per-version obfuscation keys to defeat hash-based tracking.

Why It Matters
The target is not the payment platform, it is the CI runner, a package that pretends to process payments while reading AWS and GitHub tokens out of the build environment turns a routine install into cloud-credential exfiltration. The six-minute flag time helps teams using package firewalls and does nothing for teams that pull latest on every build, because the payload runs at install.

Action for defenders
Block the named packages, audit CI/CD environment-variable scopes so a compromised install cannot read cloud or registry tokens, and move build-time secrets to short-lived OIDC tokens rather than static keys in the runner environment.

🏥 4. Unit 42 details a cloud bucket-hijacking flaw that reroutes your data to an attacker-owned bucket

Primary source: Palo Alto Networks Unit 42 
Reporting: The Hacker News

What Happened

Unit 42 described a bucket-hijacking technique affecting major cloud providers, which it characterizes as a fundamental architectural issue rather than a single-vendor bug. Because storage-bucket names occupy a globally unique namespace, an attacker who learns the name of a decommissioned or deletable bucket can delete it and immediately recreate it under their own account with the same name, that was silently rerouting any data stream still writing to that name (critical logs, telemetry, sensitive data) into attacker-controlled storage. Unit 42 notes the echo of Aqua Security's 2024 "Bucket Monopoly" method and says there is no evidence of in-the-wild abuse to date.

Why It Matters

The trust assumption being broken is that a bucket you configured as a destination stays yours. Global-namespace reuse means a name you stop owning can become someone else's inbound pipe without a single credential being stolen, which reframes bucket naming and lifecycle from housekeeping into a data-exfiltration control.

Action for defenders
Inventory every hard-coded bucket destination in logging, backup, and data pipelines; never delete-and-forget a bucket whose name is referenced anywhere, and adopt naming with account-scoped random suffixes so a released name cannot be re-registered as a data sink.

🛡️ 5. Mandiant recovers active ADFS token-signing keys from machine DPAPI, enabling MFA-bypassing SAML forgery

Primary source: Mandiant / Google Cloud Threat Intelligence 
Reporting: SecurityBrief

What Happened

Mandiant disclosed that in ADFS deployments where AutoCertificateRollover is disabled and certificates are rotated manually, configuration drift can leave an active token-signing key exposed in machine-scoped DPAPI while the Windows Internal Database still references a stale certificate. An attacker who recovers that live private key can forge SAML assertions for any user in the federated environment, reaching ADFS-tied applications including Microsoft 365 and Entra ID while bypassing MFA. The technique avoids touching LSASS and the live ADFS process, reducing the telemetry most monitoring relies on. Mandiant frames it as an evolution of the Golden SAML attack.

Why It Matters

This turns a documentation-level operational detail — "we rotate ADFS certs by hand" into a full cloud-identity compromise, because the forged SAML token is trusted by every downstream cloud app federating through ADFS. The MFA bypass is the sharp edge: the control most enterprises treat as their identity backstop is not in the path when the assertion itself is signed with a valid key.

Action for defenders: 
Audit ADFS for AutoCertificateRollover state and any drift between the certificate the service is actively signing with and the record in the configuration database; where manual rotation is used, confirm no orphaned active signing key remains recoverable from machine DPAPI.

6.  European Commission presents an Action Plan on Cybersecurity and Artificial Intelligence

Primary source: European Commission 
Reporting: Commission press corner · MLex

What happened: On July 7 the European Commission presented its Action Plan on Cybersecurity and Artificial Intelligence, framed around defending against AI-accelerated attacks and enabling safe use of AI in security. It directs the Commission to strengthen Europe's capacity to evaluate AI models before they enter the EU market in line with the AI Act, to work with ENISA on a European Blueprint for secure access to advanced AI systems for cybersecurity, and to stand up a secure platform to test AI for cybersecurity by the end of 2026. Analysts note the plan emphasizes implementing existing frameworks rather than new legislation.

Why it matters:  Pre-market model evaluation tied to the AI Act moves AI security from a vendor-attestation question to a market-access condition, which changes procurement for any cloud or security platform shipping model capabilities into the EU. Expect model-provenance and secure-access-to-AI questions to surface in supervisory conversations the way DORA incident-reporting expectations did this year.

Action for defenders: If you operate in or sell into the EU, map which AI capabilities in your cloud stack will fall under AI Act pre-market evaluation, and track the ENISA secure-access Blueprint as an input to AI governance and vendor assessment.

🎯 Cloud Security Topic of the Week:

Reachable vs. Exploitable — The Distinction That Decides What You Actually Fix

Two of this week's stories are token problems wearing different clothes. Azure CLI issued tokens through an OAuth flow that never met the policy; SimpleHelp accepted tokens it never verified were signed. Kahn's episode is the conceptual layer under both: as autonomous agents multiply, the same two questions is this identity real, and is this access still appropriate — stop being solved by static permissions and start requiring standards built for identities whose goals change every day. The through-line for the week is that the management and identity plane is where the damage now lands, and agent identity is the version of that problem heading straight for every enterprise that shipped an agent this quarter. [Listen to the full episode →]

Featured Experts This Week 🎤

• Harry Wetherald — Co-founder & CEO, Maze

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

Before diving into our insights, let's clarify some key terms:

• Reachability: Whether an attacker can at least get to the vulnerability — in cloud, roughly whether it can be reached from the network; in code, whether the vulnerable function is actually active rather than dead code. Signals only that something might be exploitable.

• Exploitability: Whether all the context is present for an attacker to actually trigger the specific vulnerability (e.g., can a triggering request pass input sanitization and surrounding controls). The deeper determination AI now automates.

• Cross-tenant IDOR: An Insecure Direct Object Reference where an authenticated user references another tenant's object (here, another Langflow tenant's flow ID) to read data — in CVE-2026-55255, other tenants' LLM and AWS keys.

• FortiBleed: The name for the mass credential-compromise campaign against internet-facing FortiGate firewalls, extracting configuration files and cracking stored credential hashes, now linked to INC and Lynx ransomware.

• Golden SAML: An attack in which a stolen ADFS token-signing key is used to forge SAML assertions for any federated user, bypassing MFA; Mandiant's machine-DPAPI key recovery is an evolution of it.

• Bucket hijacking (global-namespace reuse): Re-registering a released, globally unique storage-bucket name under an attacker account to silently receive data still being written to that name.

• SCA / SAST: Software Composition Analysis (third-party/dependency code, e.g., CVEs) and Static Application Security Testing (your own code). Maze Code ships one product for each.

• "Security brain": Wetherald's term for a persistent, enriched, cached context layer plus threat model and human-defined priorities that a coding agent queries before and while writing code — his proposed successor to "shift left."

This week's issue is sponsored by Maze

💡Our Insights from this Practitioner 🔍

Reachable vs. Exploitable, and the AI-Native AppSec Program

Harry Wetherald has spent two years building AI agents that reason across code and cloud. The through-line: the tooling finally exists to answer the question that actually matters, but only for teams that treat reliability and cost as first-class engineering problems rather than vendor talking points.

1. Reachable means "the code is alive." Exploitable means "the attacker has everything they need."

Wetherald's opening move is to separate two words the industry uses interchangeably. Reachability is a blunt filter; exploitability is the full-context judgment call.

"So that difference really is a difference between reachable, but is the code alive i, in the simplest terms? And exploitable is, is all the context kind of there for the attacker to actually be able to trigger the specific vulnerability?"

In code, that means first filtering out dead code, then testing whether a request that triggers the vulnerability can actually pass input sanitization and the controls around the application. The same logic applies in cloud and it maps directly onto this week's Langflow story, where "reachable" and "exploitable" were only a set of exposed keys apart.

 2.  Untuned AI is confidently wrong, the failure mode moved from "obvious false positive" to "detailed, plausible false positive"

Old rule-based scanners drowned teams in obvious noise. Out-of-the-box models are more accurate on a first pass but wildly inconsistent run to run, and their errors now arrive wrapped in convincing detail.

"they give very confident but sometimes wrong results 'cause they'll go very deep in an investigation, take one wrong turn along the way, and then give you the wrong answer."

The fix is training agents to run investigations reliably and to catch their own mistakes, plus heavy monitoring and validation on top. Run the same agent on the same data in a poorly built system, Wetherald notes, and it can return a different answer five times out of ten.

3. The frontier labs' security tools test as inferior and more expensive

One of the sharper takes in the conversation. Wetherald argues the lab-built security offerings are side projects that can't match tools honed for a year or two on a specific domain, and — unusually — they cost more, because the labs' incentive is to sell tokens.

"what we've seen from Claude Code Security and from other, the Google and, and OpenAI equivalents is when you test them, they're far inferior to the more domain-specific tools that people have spent a year, two years honing, refining, training, et cetera."

His buying advice: evaluate them the way you once evaluated bundled Microsoft or Google security — fine if "good enough" for the use case, but if security is strategic, go to specialists and avoid locking into one lab.

4.  Cost IS accuracy, the case for 100x optimization, not 20%

Because customers have a fixed budget ceiling, every place you cut cost without losing accuracy frees budget to spend on deeper analysis elsewhere. Cost engineering isn't a margin lever; it's the accuracy lever.

"if you run Mythos, uh, on every PR for a 10,000-person software company, it comes out as $52 million a year."

Wetherald's grounding story: the first Maze cloud run at a Fortune 100 customer extrapolated to roughly "$4 million a week" — about the company's total funding at the time — which forced cost to become a core product constraint. The takeaway for buyers is to ask how a vendor cuts cost by ~100x (dynamic routing across expensive and cheap models, or no model at all for some steps), not by a token percentage.

5. The number-one buyer red flag is a black box

Because LLM-based tools inherently produce long chains of reasoning, a modern AI security product that behaves like an opaque box has no excuse. Auditability — "how did you reach that decision" — is the thing to demand.

"If you're talking to an, like, AI-based product and it looks like a black box and it's not telling you in really clear detail what it's doing, I would run a mile."

His second buyer test: ask what the vendor built on top of the out-of-the-box models. If anyone could replicate it by pointing a frontier model at a codebase with a few prompts, the vendor has added nothing.

6. Tear down the AppSec/cloud wall — and put a "security brain" behind the coding agent

Wetherald argues the historic separation of AppSec and cloud security was an artifact of tooling, not of the risk — the same underlying issue is often handled by two teams. LLMs act as a translator across the two domains, so the wall should come down.

"We shouldn't be sat here in five years' time and going, our AppSec and our cloud security program runs completely separately."

Looking forward, he sees coding agents (Cursor, Claude Code, Devin) needing a security "brain" to call — an enriched, cached context layer plus the org's threat model and priorities — rather than each agent crawling raw data in the moment it writes code. That, in his view, is the useful successor to "shift left."

7. Fully delegate the verifiable decisions; keep humans on remediation — for now

Where a decision is logically verifiable, Wetherald wants humans out of the loop, because it has to run across potentially millions of findings.

"where it's kinda logically verifiable, so exploitability ... in both camps, cloud and AppSec ... I don't think we should be having humans in the loop of that decision."

Remediation is where teams still want a human on the final step. The path to more automation is data-driven, not a switch: if an action has succeeded several times, consider automating the next one, starting with simple, well-understood code and cloud fixes.

📚 RELATED RESOURCES 🎧

• CISA Known Exploited Vulnerabilities Catalog — authoritative list of what's being exploited; the July 7 additions carry a July 10 deadline

• Palo Alto Networks Unit 42 — Cloud Bucket Hijacking Risks — the global-namespace reuse technique in detail

• Mandiant — Recovering Active ADFS Signing Keys via Machine DPAPI — the Golden SAML evolution and detection guidance

• Socket — npm/PyPI Payment-SDK Typosquat Campaign — package list and IOCs

• European Commission — Action Plan on Cybersecurity and AI — the policy backdrop to the week's AI-exposure stories

• Maze — Harry Wetherald's company; recently launched Maze Code (SCA + SAST-style AI agents)

Podcast Episode

• Cloud Security Podcast  : Episode with Harry Wetherald

Question for you? (Reply to this email)

🤔  When you triage a finding, do you stop at "reachable" or do you actually confirm it's exploitable before it costs your team a week?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast