GHSA-8h88-gxp3-j7pg
openssl-encrypt's unverified key bundle from_dict() + to_identity() path allows encryption to attacker keys
Blast Radius
openssl-encryptReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The PublicKeyBundle.from_dict() method in openssl_encrypt/modules/key_bundle.py at lines 329-361 creates bundles from untrusted data without verifying the signature. The docstring warns to call verify_signature() after creation, but the to_identity() method (line 363-391) can convert an unverified bundle directly to an Identity object.
Affected Code
@classmethod
def from_dict(cls, data: Dict) -> "PublicKeyBundle":
"""
SECURITY: Does NOT verify signature. Call verify_signature() after creation.
"""
# Creates bundle without verification
Impact
If from_dict() followed by to_identity() is called without an intervening verify_signature() call, encryption could be performed against an attacker's public key, leaking secrets. While key_resolver.py (lines 146-147) does verify before use, the unguarded API path remains directly callable.
Recommended Fix
- Add a
verifiedflag toPublicKeyBundlethat must be set beforeto_identity()can be called - Or have
to_identity()automatically callverify_signature()and raise on failure - Or make
from_dict()require verification as part of construction
Fix
Fixed in commit f4a1ba6 on branch releases/1.4.x — from_dict() now verifies self_signature by default (verify=True parameter); raises ValueError on verification failure.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | openssl-encrypt | all versions | 1.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openssl-encrypt. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openssl-encrypt to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8h88-gxp3-j7pg is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-8h88-gxp3-j7pg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8h88-gxp3-j7pg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8h88-gxp3-j7pg in your dependencies?
O3 detects GHSA-8h88-gxp3-j7pg across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.