The matrix

Three layers of scope

Product, build, reachability. Miss one and the kit is a paperweight. Hit all three and it is an edge-device problem.

In: FortiGate appliances whose model string appears below. Only the SSL-VPN web portal (sslvpnd HTTPS). Hardware generations D, E, and F, from 30E/40F/60E branch units through 1800F/2200E/4201F/5001E campus boxes.

Out, unless proven otherwise: FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiVoice, FortiMail. Models not in the 53. FortiOS past Fortinet's published cuts - FG-IR-24-015 and FG-IR-23-097 are the authority, not my filenames. A device can still be historically in scope: patched today, exploited last year, implant left behind.

Network: SSL-VPN enabled, listener reachable from wherever the operator sat, model+build matching a file or the operator willing to crash-and-retry nearby builds. Disable the portal, restrict sources, or hide it behind a broker the attacker cannot reach, and this pack drops out of practical scope. Historical-compromise scope is a different sentence.

The kit is built as if the operator expected whatever FortiGate recon returned, not a single planted box. Combined with public SSL-VPN exposure being common, the question is not "did we have a 60E?" The question is inventory.

CPU is not a footnote

FortiOS is not one binary. This kit tracks that fact.

If the CMDB says "FortiGate-60F on 7.0.8," the matching sample is a specific file, not "any 60F script." Architecture unlabeled in a script means it never set context.arch. Behavior still clustered with ARM32 or 64-bit families. I did not re-validate offsets against vendor images for this write-up. I am telling you what the filenames and code shape claim.

Firmware trains

Family A labels cover nearly the full advertised CVE-2024-21762 window, including 7.4.0 and 7.4.1 (fixed in 7.4.3). Family B stays inside CVE-2023-27997. No Family B file is labeled 7.2.5+, 7.0.12+, 6.4.13+, or 7.4.x.

6.4 is where the author spent the most stamps. 7.4 is a toe in the water, not a museum.

Twenty SKUs that carry both families (click)

1000D, 100F, 101F, 1200D, 1500D, 2000E, 200E, 200F, 201E, 2200E, 3000D, 300D, 400F, 40F, 500D, 500E, 600E, 601E, 60F, 81F

Different files, different builds. Same appliance name in the asset database is not "we already counted that."

The 53

Search, filter, page through. Matching clients are in exp/ as exp_<SKU>-v<ver>.py. File counts are only filled where the recovered tree was loud (60E/100E/60F/100F). "One" family means this SKU appears in the kit but not in both A and B lists. Arch is the dominant picture in the recovered clients, not a vendor datasheet. The GitHub copy adds four extra files the first catalog did not have: exp_30E-v6.2.4.py, exp_30E-v6.2.12.py, exp_30E-v6.2.14.py, exp_40F-v7.0.5.py.

A box can be CVE-open and still kit-miss: vulnerable per advisory, SKU not in the 53. Public clients still exist. This pack is not the only threat.