Fortinet encrypted your config backups with 'Mary had a littl' for six years

The AES key that Fortinet used to encrypt every password, pre-shared key, and LDAP bind credential in your FortiGate configuration backup is the string Mary had a littl. Sixteen bytes. Identical on every device. Unchanged across FortiOS 5.x and 6.0.x. Decryptable with a 12-line Python script that has been public on GitHub since 2019.

CISA added CVE-2019-6693 to the Known Exploited Vulnerabilities catalog on June 25, 2025. Six years after the patch. Not because someone finally got around to it, but because Akira ransomware operators built automated tooling that chains this flaw with an authentication bypass to pull and decrypt credentials from live FortiGates in a single operation.

The vulnerability itself is straightforward. FortiOS stored sensitive fields in configuration backups encrypted with AES-128-CBC. The key was compiled into the firmware. Every FortiGate running affected versions shared the same key. If you had the backup file, you had the passwords: VPN user credentials, IPsec pre-shared keys, LDAP bind accounts, HA cluster secrets, certificate private key passphrases. The only credential spared was the local administrator password, which used SHA-256 hashing instead.

This was not a subtle cryptographic weakness. It was a nursery rhyme.

What Akira did with it

Stairwell’s research documented two tools in Akira’s operational infrastructure. The first, decrypt.py, was a lightly modified copy of the public PoC. The second, fortiConfParser.py, was more interesting: it chained CVE-2019-6693 with CVE-2022-40684, an authentication bypass rated CVSS 9.8. The tool authenticates to a FortiGate using the bypass, pulls the running configuration, and decrypts every credential field. No backup file needed. No prior access needed. Stairwell observed this tool targeting at least 13 IP addresses, nine belonging to US companies.

Akira is not alone. CISA’s KEV entry flags ransomware campaign use as “Known,” and the Snatch ransomware-as-a-service operation has also been linked to exploitation of this CVE for credential harvesting from enterprise VPN appliances.

The attack chain is efficient because it removes the precondition that made CVE-2019-6693 seem low-risk in 2019. Back then, you needed the backup file first, and the CVSS score (6.5) reflected that assumption. Akira’s tooling made the assumption irrelevant.

This is also why CISA waited six years. The KEV catalog requires confirmed active exploitation, and until ransomware operators industrialized the chain, CVE-2019-6693 was a theoretical post-compromise amplifier. The January 2025 Belsen Group leak of 15,000 FortiGate configuration files, followed by April’s joint advisory on symlink persistence in compromised FortiGates, made the threat landscape concrete. Backup files are circulating. Credentials are being harvested. The six-year-old bug matters now in ways it didn’t in 2019.

The part that should bother you

CVE-2019-6693 is not an isolated engineering mistake. Fortinet has shipped hard-coded cryptographic keys across multiple product lines for the better part of a decade.

CVE-2018-9195: FortiOS and FortiClient used XOR with a static key to encrypt all communications with FortiGuard cloud services. SEC Consult found it in 2018. Fortinet took 18 months to replace the cipher with TLS.

CVE-2020-9289: FortiManager and FortiAnalyzer used the same hard-coded key pattern for CLI configuration secrets. Synacktiv published a decryptor.

CVE-2023-37936: FortiSwitch shipped a hard-coded cryptographic key that enabled unauthenticated remote code execution, CVSS 9.6.

CVE-2026-25815: FortiOS through 7.6.6 encrypts LDAP credentials in config files with a default key identical across all deployments. The private data encryption feature that would prevent this exists but is off by default. Fortinet’s position is that enabling it is the customer’s responsibility.

Each of these came from a different product team. The pattern is not one engineer making one bad call. It is an organization that does not have a cross-product policy against compiling shared secrets into firmware. That is a process failure, and process failures repeat until the process changes.

What to do about it

If you are running FortiOS 5.6.10 or earlier, 6.0.0 through 6.0.6, or 6.2.0, the CISA KEV deadline was July 16, 2025. Upgrade to 5.6.11, 6.0.7, or 6.2.1 at minimum. Realistically, if you are still on 5.x or 6.0.x, you should be planning a major version upgrade, not a point release.

Patching closes the vulnerability on the device. It does not close the vulnerability in every backup file you generated while the device was unpatched. Those files are still decryptable with the same key. If any backup was ever attached to a support ticket, stored on a shared drive, emailed to an MSP, or uploaded to a TAC portal, assume the credentials in it are compromised.

After patching, enable private-data-encryption in the CLI. On FortiOS 7.6.1 and later, a random per-device key is generated automatically. On earlier patched versions, you supply a 32-digit hex key manually. Then rotate every credential that touched the device: VPN passwords, IPsec pre-shared keys, LDAP bind accounts, HA passwords, and any certificate private keys loaded on the appliance. The LDAP bind account deserves particular attention because it typically has broad read access to Active Directory and is often reused across devices.

Search your environment for .conf files from affected FortiGates. Check ticketing systems, NAS shares, email archives, SFTP servers. Delete or encrypt what you find.

The real lesson

A vulnerability with a CVSS of 6.5 and no remote code execution sat quietly for six years until a ransomware group built the right tool to chain it with something worse. The score was accurate for the vulnerability in isolation. The score was useless for predicting the risk once the ecosystem around it changed.

Fortinet patched this specific bug in 2019. They did not fix the pattern. The same class of vulnerability appeared in 2020, 2023, and 2026. The patch for CVE-2019-6693 added an optional private-data-encryption feature that lets administrators supply their own key. The feature shipped off by default. Seven years later, CVE-2026-25815 proved that the default still matters.

This is exactly the kind of old-but-suddenly-active vulnerability that PatchDay Alert tracks: a low-CVSS bug that sat dormant until a ransomware group built the right chain around it. If you run FortiGate, the patch is not the last step. The credential rotation is. And if Fortinet’s track record on this class of bug is any guide, the private-data-encryption toggle is worth enabling before the next CVE proves it was necessary.