Notifications
Clear all
Topic starter
22/07/2026 4:35 pm
TL;DR: FortiBleed exposed a structural flaw in internet-facing remote access: roughly half of Fortinet firewalls had credentials harvested, with attackers reusing leaked passwords, cracking weak hashes, and pivoting into internal networks, according to Appgate. Patch cycles did not matter because the gateway itself was the target, not a software flaw.
NHIMG editorial — based on content published by Appgate: FortiBleed, credential leak and perimeter access analysis
Questions worth separating out
Q: How should teams respond when internet-facing gateway credentials are harvested?
A: Containment starts with terminating active sessions, resetting administrative and remote-access credentials, and removing public exposure where possible.
Q: Why do exposed VPN gateways remain such a high-risk identity control?
A: Because they are designed to be reachable, they become easy to scan and easy to test at scale.
Q: What do security teams get wrong about router patching?
A: Teams often assume patching is the whole answer, but router risk also depends on exposure, lifecycle status, and service configuration.
Practitioner guidance
- Reduce exposed remote access surfaces Map every internet-facing gateway, VPN, and firewall login that accepts credentials from the public internet.
- Reset trust around legacy credentials Treat exported configuration files, weak password storage, and reused credentials as active compromise paths.
- Limit post-login reach Replace broad network access with resource-scoped access so that a single validated login cannot traverse internal segments freely.
What's in the full article
Appgate's full article covers the operational detail this post intentionally leaves for the source:
- The June 2026 advisory sequence and how Fortinet, CISA, and the UK NCSC responded across the incident window.
- The direct-routed Zero Trust and Single Packet Authorization architecture details that Appgate argues remove the exposed target.
- The specific U.S. Air Force and General Dynamics context behind the deployment example and scale claims.
- The step-by-step containment actions Appgate recommends for teams running exposed Fortinet or similar gateway products.
👉 Read Appgate's analysis of FortiBleed and perimeter credential harvesting →
FortiBleed and VPN credential harvesting: what should teams change?
Explore further
22/07/2026 4:40 pm
Perimeter access is an identity model failure, not a vulnerability class. FortiBleed reinforces that internet-facing gateways create a standing trust problem: if the device is reachable, it can be tested, and if a credential works, the network often opens too far. That turns authentication into a broad access grant rather than a constrained identity decision. Practitioners should treat exposed remote access as an identity governance issue, not a patching workflow.
A few things that frame the scale:
- Roughly half of all internet-facing Fortinet firewalls had their credentials harvested, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
A question worth separating out:
Q: Who is accountable when stolen credentials are used for stealthy internal movement?
A: Accountability should sit with the owners of identity, endpoint, and directory controls because the failure crosses all three domains. If stolen credentials can be replayed and lateral movement is not detected, that is a governance gap, not just a security event. Frameworks such as NIST CSF and PAM governance should define clear ownership for containment and review.
👉 Read our full editorial: FortiBleed shows why perimeter access models keep failing
