Fortinet Auth Bypass 2026: Is Your Perimeter In Scope?

Somebody pastes a Fortinet advisory link into #security at four in the afternoon on a Thursday. Nobody argues about whether it needs patching. The network team picks it up, the maintenance window gets booked, and for about twenty minutes it looks like a normal day.

Then someone asks the question that changes the temperature of the channel: "Would the pentest from March have caught this?" The room goes quiet, because nobody can remember whether the firewalls were in scope. Somebody thinks they were. Somebody else thinks the scope was the application. The report is in a shared drive and nobody wants to be the person who opens it in front of everyone.

That silence is the real finding. Patching answers this advisory; scope answers the next one. If you cannot say from memory whether your perimeter appliances, their management interfaces, and their admin authentication paths were inside the last engagement, you will have this exact conversation again in four months with a different vendor's name on the advisory. Here is what Fortinet actually disclosed, why perimeter appliances are systematically the least-tested infrastructure most organisations own, and the specific scope language that changes the answer.

What Fortinet Actually Disclosed in August 2026

Half the coverage of the August batch collapsed separate issues into one scary headline, which is unhelpful when you are trying to work out whether you are affected. Two of the CVEs below landed on 12 August; the third is from January and is here because it is the one that was actually exploited. Three products, three different preconditions. The preconditions are the part that matters, so here is the whole picture in one place before we get into what it means.

CVE-2026-26035 (FortiWeb): Arbitrary Credentials

This is the loud one. A remote, unauthenticated attacker can log into the FortiWeb GUI or CLI using an arbitrary username and password, where a Remote RADIUS Type admin account has the wildcard option enabled. That option is off by default, which is the only reason this is not an unqualified emergency for every FortiWeb operator on the planet.

One detail worth flagging before it causes an argument in your risk meeting: Fortinet rates this High in FG-IR-26-158, while NVD and most third-party trackers carry it as CVSS 9.8 critical. The gap is a scoring judgement about the non-default precondition, not a disagreement about the mechanics. Pick one, cite the source next to the number, and move on.

"Off by default" gives less comfort than it sounds like it should, because wildcard RADIUS admin accounts get enabled by people solving a real problem. Someone needed group-based admin access to work without provisioning every account locally, they turned the option on, it worked, and that was three years and two staff departures ago. You can confirm your exposure in minutes, but only if somebody goes and looks.

CVE-2026-70468 (FortiManager): FortiGate Impersonation

Lower score, arguably more interesting. A remote unauthenticated attacker holding a valid certificate can impersonate any FortiGate managed by that FortiManager, using crafted FGFM requests, where a specific CLI option is set. FGFM is the protocol FortiGate devices use to talk to their manager. It is not a thing most people outside the network team think about, and it almost never appears in a pentest scope statement.

Two things stop this being a panic. The certificate requirement is a genuine barrier, not a formality, and the affected set is narrow: FortiManager and FortiManager Cloud 7.2.5 to 7.2.9, 7.4.3 to 7.4.5, and 7.6.1. If you run 7.2.3 or 7.4.1 you are not on the affected list for this CVE, which is the opposite of the usual "everything below the fixed build" pattern and is easy to get wrong when you triage from a headline instead of the advisory.

Details are in the vendor advisory (FG-IR-26-160) and the NVD entry; you can also pull both records through our CVE lookup tool if you want the version ranges in one place. Fortinet scores it 7.3; some trackers publish 8.1.

Neither August flaw was reported as exploited in the wild at the time of disclosure. That is genuinely good news and worth saying plainly, because a lot of the coverage implied otherwise.

Why the Preconditions Matter More Than the CVSS Score

Both August issues are gated behind a configuration choice. Not a version number, a configuration choice. That distinction determines what kind of testing can find them.

A version-gated vulnerability is findable by anything that can read a banner. A scanner sees FortiWeb 7.4.8, checks a table, raises a finding. A configuration-gated vulnerability is different: the scanner sees the same banner either way, but whether you are exploitable depends on whether a Remote RADIUS Type admin account exists with the wildcard option on. The scanner cannot know that. It is not authenticated to your device and the setting is not advertised in any response it can read.

This is the gap a scoped test closes and a scan does not. We have written about where that line sits in when automated pentesting is enough, and the short version applies here: automation is excellent at "is this version vulnerable" and blind to "is this deployment configured into the vulnerable state."

The August batch is the news. But the flaw that shows why this distinction matters was disclosed seven months earlier, and almost nobody remembers it.

The FortiGate Flaw Everybody Forgot

CVE-2026-24858, published as FG-IR-26-060, is a FortiCloud SSO admin authentication bypass carrying a CVSS of 9.4. It is an alternate-path authentication bypass (CWE-288): where FortiCloud SSO is enabled, an attacker holding their own FortiCloud account and a registered device reaches administrative access on devices registered to somebody else's account, through a path that was never supposed to grant it. Not a memory-corruption exotic, not a chain requiring a foothold. It reaches beyond FortiOS to other FortiCloud-registered products, so scope your check to FortiProxy, FortiManager and FortiAnalyzer as well as your FortiGates.

The part that separates it from the August batch: it was confirmed exploited in the wild. Here is the sequence that matters.

Sit with the order of those entries. Exploitation came first, then a vendor-side mitigation, then the advisory. A KEV listing with a three-day federal remediation deadline landed the day before the advisory that explained the flaw. Anyone whose only detection strategy was "patch what the advisory tells us to patch" was, by definition, downstream of the whole sequence.

That is the structural problem with treating perimeter security as a patching function. Patching is reactive to disclosure, and disclosure is not reliably ahead of exploitation on edge devices. What gets ahead of it is knowing what your admin authentication paths look like from the outside before anybody publishes anything, which is a testing question rather than a patching one. So why does nobody test them?

Why the Perimeter Appliance Is the Least-Tested Thing You Own

Here is the observation that reframes the whole thing: in most penetration tests, the firewall is where the test starts from or passes through. It is rarely what the test targets.

The tester connects through the VPN to reach the internal scope. The external test resolves your public IPs and works on what is behind them. The firewall is scenery, the thing between the tester and the interesting stuff, and the scope statement was written on the assumption that it is infrastructure rather than a target in its own right. Three dynamics keep it that way.

It Is Owned by the Network Team, and the Scope Was Written by the App Team

Scope statements get written by whoever owns the thing being tested: the application owner, a security lead closest to the product, or a compliance manager working from last year's document. The firewall belongs to the network team, who were not in the scoping call, were not asked what they would like tested, and who reasonably assume that if security wanted the firewall tested they would have said so.

Nobody made a decision to exclude the perimeter. That is what makes it durable. A deliberate exclusion gets revisited; an unexamined assumption gets copy-pasted into next year's SOW.

"Managed by Our Vendor" Reads as "Someone Else's Problem"

If an MSP or managed network provider runs your Fortinet estate, there is a strong pull toward assuming the perimeter is covered. Sometimes it is. Often what is covered is availability, change management, and firmware currency, which are real services but are not adversarial testing of admin authentication paths.

The question worth asking is narrow and answerable: do you test the externally reachable admin authentication paths on our devices, or do you maintain them? Those are different services and most contracts only buy the second.

Management Planes Sit Outside Almost Every Scope Statement Ever Written

FortiManager. FortiCloud SSO. RADIUS admin authentication. FGFM device-to-manager channels. Read the last three scope statements you signed and count how many mention any of these. For most teams the answer is zero, and it is zero at organisations with mature, well-run security programs.

Management planes are the highest-value target on the network and the least-tested surface on it. A compromised FortiManager is not one device, it is policy control over every device it manages. Once an attacker holds the management plane, the next move is almost always credential harvesting rather than dramatic disruption, the pattern we traced in the ShinyHunters Oracle PeopleSoft campaign: access to a management or integration layer converted quickly into credentials for everything downstream.

The practical question is what an unauthenticated tool can settle on its own and what needs a defined scope behind it. On a perimeter appliance, the line is unusually sharp, and it is worth being precise about where it falls, because most of the left column is not black-box work.

Read the left column as what an engagement can cover when the scope grants it the access it needs: device configuration read access, an internal network position, or test credentials, depending on the item. None of these are things a tester achieves from the public internet with no credentials. Read the right column as what no unauthenticated external scan reaches, regardless of how good the scanner is or who sells it.

The honest summary is that one engagement type does not cover both columns. External testing tells you what an attacker can reach; configuration review tells you whether what they reach is in the vulnerable state. Buying only the first and believing you bought the second is the actual failure mode, and attackers have spent the last eighteen months proving those gaps pay. The data says so plainly.

What the 2026 Attack Data Says About Edge Devices

Edge VPN and firewall appliances have been a dominant ransomware initial-access vector through mid-2026, and not for one vendor. Fortinet, Palo Alto, Citrix and Check Point have all had edge authentication issues weaponised at speed. This is a category problem, and any organisation reading this and quietly thinking "good thing we run Palo Alto" has drawn the wrong conclusion.

Two numbers from Fortinet's own 2026 Global Threat Landscape Report are worth citing carefully. The first is about volume.

Treat that figure as directional rather than independent, and read the base year carefully. A jump from roughly 1,600 to 7,831 is a 5x move in twelve months, which is a large enough step to reflect improved victim-tracking coverage as much as a genuine five-fold rise in attacks. It is a vendor's count, drawn from a vendor's telemetry, and every threat report published by a security company has a visibility bias baked into it. Note also that Fortinet's own attribution is to cheaper offensive tooling, not to edge devices specifically. The edge-device connection is a separate argument, and it rests on CISA's Known Exploited Vulnerabilities catalog, where edge and remote-access products have been consistently over-represented relative to their share of the software estate.

The more useful question is what that volume is made of. Ransomware operators are not, for the most part, burning novel exploits on initial access. They are reusing published edge-device vulnerabilities against organisations that have not yet patched, and buying credentials from access brokers who got them the same way. That is a commodity supply chain, and its economics reward speed. The cheaper it is to weaponise a disclosed edge flaw, the shorter the window between publication and mass exploitation, and the less a monthly patch cycle protects you.

This is where the second number changes how you should plan. When time-to-exploit was measured in days, a monthly maintenance window was a defensible risk position: you accepted a few days of exposure on the tail end of each cycle and made the trade knowingly. That calculation assumed you had days. Fortinet's data says you no longer do.

Run the arithmetic on your own change process before reading the next figure. Count the hours from advisory publication to somebody on your team reading it, then to a change request, then to approval, then to the next available window, then to the last device in the estate actually rebooting on the new build. For most organisations that number is measured in weeks, not hours. Now compare it to this.

Be precise about what that number is, because it is widely misquoted. It is time-to-exploit measured from public disclosure to observed exploitation in the wild. It is not dwell time, and it is not time-to-encryption after an intruder gets in. Those are different metrics from different studies, and conflating them produces a scarier slide and a worse decision.

Read correctly, it is still the number that breaks a monthly patch cycle. If exploitation of a critical edge flaw begins within a day or two of the advisory landing, and your change process needs three weeks to touch the last device, you are exposed for essentially the whole exploitation window on every cycle. The gap is not closed by patching faster than you realistically can. It is closed by knowing, before the advisory lands, which of your appliances are internet-reachable and which admin paths are exposed on them, so that the triage on day one is a short list rather than a discovery exercise.

The other consequence worth planning around is what edge compromise yields. Perimeter appliances sit on the credential path: VPN concentrators handle authentication material for the whole workforce, management platforms hold device credentials and API tokens. Edge compromise is rarely the objective, it is the credential harvest that makes everything after it cheap, a dynamic we covered in credential exposure and the 2026 attack surface.

So the question is not whether your edge matters. It is whether anyone has tested it, which takes us back to the document that decides.

Would Your Pentest Have Caught It? Read Your Scope Statement

Open the last engagement's scope statement. Not the report, the scope. It is usually one paragraph on page two of the SOW and it determines everything the report could possibly have contained. Here are four real phrasings and an honest ruling on each.

You cannot write the third scope honestly without knowing what is actually internet-facing, and most organisations are wrong about that by a margin. Reachable management portals turn up on forgotten subdomains more often than anyone would like. Our subdomain finder is a free way to check your own domain, and it is worth doing before the scoping call rather than during it.

Once you know what the right scope language looks like, the next job is turning it into something you can hand to a vendor.

The Perimeter Scope Checklist

Lift this into your next scope statement or vendor RFP. It is written as things to demand from any provider, not a description of any one vendor's coverage.

One warning before you send it: this is a multi-discipline list, not a single engagement. Items 1, 7, 9 and 16 are external testing. Items 2 to 6, 8, 10, 11 and 15 need configuration read access or test credentials. Items 12, 13 and 14 need internal network access and log access. Expect a credible provider to tell you which items they cover and which need a different engagement or a different supplier. A provider who ticks all sixteen without asking about access is telling you something useful about how the report will read.

Sixteen items. None require a specific vendor, product, or methodology. All are answerable in a scoping conversation, and the answers tell you a lot about who you are dealing with. The checklist is for your next engagement, though, and the advisory is on the channel now.

A note on the third scope phrasing above, since it is the one people copy verbatim: naming management interfaces and administrative authentication paths gets those surfaces enumerated and their exposure tested. It does not, on its own, grant a tester the device access needed to read a RADIUS configuration. If you want that, the scope has to say so and somebody has to provision the access. Scope language opens the door; it does not walk through it.

What To Do This Week, Whether or Not You Buy Anything

Sequenced, and useful even if you never speak to a security vendor about any of it.

If your firewalls are managed by an MSP, add a step before all of these: find out whether your provider tests these paths or maintains them. Ask for the scope statement of whatever testing they perform on your behalf and read it against the checklist above.

Plenty of MSPs do excellent work here. Others sell configuration management and let the customer infer that testing is included, which is less dishonesty than a gap neither party has said out loud. If they maintain rather than test, you need independent coverage of the management layer, and the economics of MSP-delivered penetration testing are worth understanding before you negotiate it.

Where an Independent Test Fits

The network team that owns the firewall reviewing its own firewall configuration is self-assessment. That is not an insult to your network team, who probably know the estate better than any external tester will in a five-day engagement. It is a statement about what an auditor, a QSA, or a customer's procurement team can accept as evidence. They were not there and cannot verify your internal review. What they can accept is a test performed by someone independent of the thing tested, against a defined scope, at a defined time, reviewed and signed by a certified security professional.

Worth being accurate about what "independent" means here, because it is routinely overstated by vendors including ours. PCI DSS v4.0 does not require an external third party. Requirement 11.4.1 asks that the testing methodology be performed by a qualified internal resource or a qualified external third party, with organisational independence of the tester. A properly separated internal team can satisfy it. What an external report buys you is that the independence is self-evident to the third party reading it, rather than something you have to explain in an org chart. That is a real advantage, and it is a narrower claim than "auditors require an external tester".

The cadence is the part that is not negotiable: 11.4.2 and 11.4.3 require internal and external penetration testing at least once every twelve months and after any significant infrastructure or application upgrade or change, and 11.4.4 requires retesting to verify remediation. Applying an emergency firmware patch to a KEV-listed authentication bypass on an in-scope perimeter device is a significant change by any reasonable reading, though your QSA makes the call. If you operate in Europe, related obligations sit in the NIS2 testing requirements, which mandate assessing the effectiveness of your risk-management measures rather than prescribing penetration testing by name.

It is also the cleanest way to think about how continuous testing and point-in-time reports fit together, which we cover in what CTEM means for penetration testing. Continuous testing is what tells you a significant change happened. The signed test is what you owe when it does. The advisory told you to patch; the retest proves the patch landed on every device; the signed report is what you hand to the third party who asks in six months.

Be clear about what that buys you, because no honest provider covers the whole checklist above on its own. CyberOrbit handles the systematic 80%: the externally reachable surface, tested the same way every time, evidenced end to end, and independently signed. Deep on-device configuration review and novel business-logic attacks still need a specialist working alongside it. Any provider who tells you one engagement covers all sixteen items is selling you the scope statement you wanted to hear.

Run the free External Security Check on your own domain to see what is actually reachable from outside, and use the subdomain finder to catch the forgotten hosts your inventory does not list.

Frequently Asked Questions