Critical-rated bug in obscure Python encryption tool lets attackers swap in their own keys

A newly disclosed vulnerability, tracked as CVE-2026-81702, has been flagged as “critical” - but before anyone panics, it’s worth being clear about what this actually breaks, and how many people it could plausibly touch.

The bug lives in openssl_encrypt, a small, niche Python package for handling encryption identities (the GitHub repository shows precisely two stars at the time of writing). It is not OpenSSL itself, the ubiquitous library that underpins huge swathes of the internet’s encryption. That distinction matters, because a “critical” bug in a library almost nobody uses is a very different story to one in something everyone’s browser relies on.

What the bug actually does

According to the GitHub security advisory, the problem sits in how the tool loads saved “identities” - essentially stored contact records containing someone’s public key and a fingerprint used to verify it hasn’t been tampered with.

When you import a new identity, openssl_encrypt correctly re-derives the fingerprint from the actual key file and checks it matches. But when it loads an existing identity from its identity.json store, it simply trusts whatever fingerprint is written down - without re-checking it against the real key.

That means an attacker who can plant or modify files in a shared identity store (say, a shared contacts folder, an extracted archive, or a custom --identity-store path) can swap in their own public key while leaving the original, trusted-looking fingerprint in place. The tool will display the fingerprint you expect to see, giving no visible sign anything is wrong, while quietly encrypting your files to the attacker’s key and validating their forged signature as genuine. VulnCheck classifies this as CWE-345, “Insufficient Verification of Data Authenticity” - a fair description of a system checking the label rather than the contents.

So who is actually at risk

Here’s the catch: this only matters to users of this specific, obscure package, and only in a fairly particular scenario - one where an attacker already has the ability to plant or alter files in an identity store you then load. If you’ve never heard of openssl_encrypt, you are not affected. There is no suggestion in any of the advisories that this is being exploited in the wild, and no evidence it touches mainstream tools, operating systems or the OpenSSL project that shares part of its name.

There’s also a wrinkle worth flagging: the severity ratings don’t quite agree. NVD’s listing headlines it as critical with a CVSS score of 9.8, while VulnCheck scores it slightly lower at 9.3 using the newer CVSS v4 framework. Both agree it’s serious in principle - a full break of the trust model - but the scoring gap is a useful reminder that these numbers aren’t gospel, just one input among several.

What to do about it

If you or your organisation happen to use openssl_encrypt for managing encrypted identities, the fix is straightforward: update to version 1.4.9, where the fingerprint is properly re-derived and checked on load, matching the safer behaviour already used when importing new identities.

For everyone else, this is a case study rather than a call to action - a good illustration of why a “critical” label deserves a moment’s scrutiny before it becomes a headline, not after.