GHSA-2vhw-q7vh-7xv2 CVE-2026-74879 PYSEC-2026-3758
openssl-encrypt's readiness endpoint leaks database error details to unauthenticated callers
High
PyPI
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.44%
- Chance of exploitation in the next 30 days. Higher than 38.65% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-201 Insertion of Sensitive Information Into Sent Data
- Fix
1.4.0- Upgrade openssl-encrypt to this version or later
Description
Summary
The /ready endpoint in openssl_encrypt_server/server.py at lines 159-175 catches database errors and returns the full exception string in the response.
Affected Code
except Exception as e:
return {"status": "not_ready", "reason": str(e)}
Impact
Database exception messages can leak:
- Database hostnames and IP addresses
- Connection parameters and port numbers
- Driver version information
- Potentially database credentials if included in connection string errors
This information is available to unauthenticated callers.
Recommended Fix
- Return a generic error message:
{"status": "not_ready", "reason": "database unavailable"} - Log the full exception server-side for debugging
Fix
Fixed in commit 7aa8787 on branch releases/1.4.x — replaced str(e) with generic "database check failed" message; full exception logged server-side at WARNING level.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| openssl-encrypt | < 1.4.0 |
1.4.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
openssl-encrypt PyPI → 1.4.0
- pip
pip install --upgrade "openssl-encrypt>=1.4.0"- poetry
poetry add "openssl-encrypt>=1.4.0"- uv
uv add "openssl-encrypt>=1.4.0"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Unreported
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-201: Insertion of Sensitive Information Into Sent Data
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
How to prevent it
- Requirements: Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
- Implementation: Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
- System Configuration: Setup default error messages so that unexpected errors do not disclose sensitive information.
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| PYSEC-2026-3803 openssl_encrypt before 1.4.9 fails to validate KDF cost parameters in encrypted file metadata and keystore headers, allowing attackers to trigger unbounded… | High | Also affects openssl-encrypt |
| PYSEC-2026-3965 openssl_encrypt before 1.4.9 fails to validate the memory_cost parameter from identity file protection blocks, allowing attackers to trigger out-of-memory… | Medium | Also affects openssl-encrypt |
| PYSEC-2026-3802 openssl_encrypt before 1.4.9 executes untrusted third-party plugins with insufficient controls: the plugin signature policy defaulted to WARN, so an… | High | Also affects openssl-encrypt |
| PYSEC-2026-3801 openssl_encrypt (pip package openssl-encrypt) before 1.4.9 contains two weaknesses in the portable USB drive feature, whose threat model treats the removable… | Low | Also affects openssl-encrypt |
| PYSEC-2026-3800 openssl_encrypt (pip: openssl-encrypt) versions before 1.4.9 contain a path traversal flaw in PluginSandbox._is_safe_path, which authorized file access using a… | Medium | Also affects openssl-encrypt |
| PYSEC-2026-3964 openssl_encrypt (pip package openssl-encrypt) versions <= 1.4.8 do not redact the keyserver bearer token passed as the positional argument to 'keyserver… | Low | Also affects openssl-encrypt |
| PYSEC-2026-3799 openssl_encrypt (pip: openssl-encrypt) versions <= 1.4.8 use suffix-tolerant fingerprint matching in enroll_trust_key when binding a plugin-signing trust… | High | Also affects openssl-encrypt |
| PYSEC-2026-3781 openssl_encrypt before 1.4.9 fails to prevent namespace collisions between own identities and contacts in IdentityStore, allowing attackers to create shadowed… | Critical | Also affects openssl-encrypt |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor