GHSA-h3m5-p59h-x88p
openssl-encrypt has visible password in process list via --password CLI argument
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
Passwords passed via the --password / -p CLI argument in openssl_encrypt/modules/crypt_cli_subparser.py at lines 150-154 are visible to any user on the system via ps aux or /proc/[pid]/cmdline.
Affected Code
subparser.add_argument(
"--password", "-p",
help="Password (will prompt if not provided, or use CRYPT_PASSWORD environment variable)",
)
Similarly, --keystore-password exposes the keystore password.
Impact
On multi-user systems, any user can observe the encryption password by listing processes. The CRYPT_PASSWORD environment variable alternative is also visible via /proc/[pid]/environ (though with slightly restricted access).
Recommended Fix
- Document the security implications prominently
- Recommend interactive prompting (already supported) as the secure default
- Consider supporting password file descriptors (
--password-fd) or reading from stdin - Consider marking the argument as deprecated in favor of interactive prompting
Fix
Fixed in commit e78a366 on branch releases/1.4.x — added --password-file and --password-fd arguments; added OPENSSL_ENCRYPT_PASSWORD env var support; --password now emits deprecation warning.
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-h3m5-p59h-x88p 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-h3m5-p59h-x88p 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-h3m5-p59h-x88p. 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-h3m5-p59h-x88p in your dependencies?
O3 detects GHSA-h3m5-p59h-x88p across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.