- What: fortitool, a single-binary open-source FortiOS firmware decryptor published on August 21, 2026, consolidates years of scattered Fortinet decryption research into one MIT-licensed Go tool covering v6.x through 8.0.
- The finding that matters: the hardcoded AES key from CVE-2019-6693 ("Mary had a littl") still decrypts real secrets out of config backups on builds through at least FortiOS 7.2.3, roughly three years longer than the public record suggested.
- And its replacement is now public: 7.4 (build 2731 onward) moved to AES-256-CBC under a new hardcoded key, which the tool's author recovered and published. A new key that is still hardcoded is not a fix, it is a longer runway.
- The lesson: treat every FortiOS config backup you have ever emailed, ticketed, or dropped in a shared drive as plaintext. Rotate what is in them, and start logging who exports them.
Most firmware-decryption releases are a curiosity for people who reverse engineer appliances. This one has an operational edge, and it is worth separating the two halves.
The first half is the tool. fortitool is a static Go binary that unpacks FortiOS images end to end: the outer 512-byte XOR layer, the rootfs crypto underneath it, and every container format in between. Before it, the same work meant chaining together several half-maintained scripts, each covering a different firmware era. Now it is one command, and it auto-detects which encryption era an image belongs to rather than making you pass a version flag.
The second half is the part that should reach the people who run these firewalls rather than the people who take them apart.
The 2019 key outlived its own disclosure by three years
FortiOS stores sensitive values in configuration backups as set <field> ENC <base64>. Those look encrypted, and technically they are. They are also encrypted under a key that ships inside the product.
That key was disclosed in 2019 as CVE-2019-6693. The reasonable assumption, six years on, is that it belongs to history. The tool's author reports otherwise: the same 2019 key decrypted 22 factory certificate passwords and default credentials out of real 7.2.3 backups, and the recovered plaintext includes exactly the sort of thing you would expect, down to the word "guest".
A hardcoded key is a known weakness with a known shape. What changes the risk calculation is its lifespan. Every organization that read the 2019 advisory, patched forward, and moved on has been generating config backups ever since under the impression the ENC values meant something. If the key was live through 7.2.3, then years of backups sitting in ticket attachments, vendor support cases, MSP shared drives and email threads are readable by anyone who kept a copy. The exposure is not the firewall. It is the paper trail around it.
The 7.4 replacement is stronger crypto and the same design
Fortinet did move. From build 2731, FortiOS 7.4 upgraded config-secret encryption from AES-128-CBC to AES-256-CBC under a different key, with an eight-byte ASCII marker appended after encryption that pushes the base64 blob from 200 to 208 characters. That marker is how the tool tells the two eras apart without being told.
The problem is what did not change. The new key is still hardcoded, and it is now published in the tool's source. Moving from AES-128 to AES-256 raises the cost of breaking the cipher, which was never how these secrets were going to be recovered. They were recovered by reading the key out of the firmware, and that is exactly what happened again.
This is the distinction worth holding onto: a stronger algorithm under a shipped key is not a stronger secret. It is the same secret with a longer name.
What the rest of the tool tells you about the estate
Two details in the write-up are easy to skim past and are useful if you run a mixed fleet.
- The hardening timeline was staggered by architecture. ARM-based appliances stayed on the legacy ChaCha20 rootfs path through 7.4.11 while x86 moved earlier. If you have been assuming a single version number means a single security posture across your fleet, it does not.
- Roughly 25 distinct outer-layer keys are reused across product lines. Key reuse at that scale means recovering one image's keystream has value well beyond that one image.
What to actually do this week
None of this requires a new detection or a product purchase. It requires treating a class of file differently than you have been.
- Find every config backup you have ever exported. Ticketing systems, email, vendor support cases, MSP file shares, laptops, the network share someone made in 2021. That inventory is the actual scope of this issue.
- Rotate what those backups contain, not just admin passwords: IPsec pre-shared keys, RADIUS and LDAP bind credentials, certificate passphrases, SNMP community strings, API keys. Assume every one of them in an old backup is known.
- Stop treating backup export as a routine admin action. It is a credential-export action. Log it, alert on it outside a change window, and review who can do it.
- Ask your MSP or integrator what they hold. Third parties accumulate config backups as a normal part of doing the work, and their retention is usually longer and looser than yours.
Hardcoded keys in network appliances keep producing this exact story: disclosure, a version bump, a quiet assumption that the problem aged out, and then somebody demonstrates years later that it did not. The durable defense is not tracking each key. It is deciding that any secret which leaves a device inside a vendor-encrypted blob is a secret you have already disclosed, and building rotation and access logging on that assumption instead.
The tool's author is direct about intent, licensing it MIT with the note to "only use this against firmware for hardware you own, for security research or interoperability purposes," and summarising the operational consequence in one line: a FortiOS config backup should be treated as plaintext-adjacent. That is the correct read, and it is the sentence to bring to whoever owns your firewall estate.
Do you know where your config backups are?
RedEye Security helps organizations inventory credential-bearing artifacts, rotate what has been exposed, and put logging around the export actions that quietly move secrets off your devices. If you run Fortinet at the edge, that inventory is this week's work.