CVE-2026-81714: openssl_encrypt before 1.4.9 Plugin Signing Trust Anchor Enrollment Bypass
opensslencrypt (pip: openssl-encrypt) versions <= 1.4.8 use suffix-tolerant fingerprint matching in enrolltrustkey when binding a plugin-signing trust anchor. An operator who confirms a short (forgeable, ~32-bit) GPG key id could unknowingly enroll an attacker's colliding key as a trusted anchor, which then vouches for malicious plugins under the ENFORCE signature policy. Version 1.4.9 fixes this by requiring the confirmed value to exactly match the full primary-key fingerprint (case-insensitive, whitespace-stripped).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openssl_encrypt (pip: openssl-encrypt)to a version that resolves this vulnerability.Fixed in 1.4.9 - Upgrade
Upgrade
openssl_encrypt (pip: openssl-encrypt)to a version that resolves this vulnerability.Patch openssl_encrypt before 1.4.9 Plugin Signing Trust Anchor Enrollment Bypass
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using openssl_encrypt version 1.4.8 or earlier are exposed when an operator enrolls a plugin-signing trust anchor and confirms a short GPG key ID. The impact applies where the ENFORCE signature policy relies on that enrolled anchor to validate plugins.
What does an attacker need to exploit it?
An attacker needs a GPG key whose short, approximately 32-bit key ID collides with the key ID presented for confirmation. They must cause an operator to confirm that short identifier during trust-anchor enrollment, allowing the colliding attacker key to be trusted.
Are installations safe if operators verify full fingerprints?
The vulnerable enrollment behavior accepts suffix matches, so safety depends on what value is confirmed during enrollment. Version 1.4.9 requires an exact match against the full primary-key fingerprint after case and whitespace normalization.
What can be done before upgrading?
Do not enroll plugin-signing trust anchors based on short GPG key IDs. Verify the complete primary-key fingerprint through a trusted channel before accepting a key, and avoid trusting newly enrolled anchors until that verification is complete.
How can I determine whether remediation is needed?
Check whether the installed openssl_encrypt version is 1.4.8 or earlier and review plugin-signing trust-anchor enrollments. Anchors enrolled after confirmation of a short key ID should be treated as needing revalidation against the full primary-key fingerprint.