Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Both standalone servers configure CORS with alloworigins=[""], allowcredentials=True, allowmethods=[""], and allowheaders=[""]. Affected Code The docker-compose file (opensslencryptserver/docker-compose.yml:75) also defaults CORSORIGINS to , and .env.example ships with CORSORIGINS=. Impact This is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker's website could make authenticated API calls on behalf of any user who visits it. Recommended Fix - Remove wildcard defaults — require explicit origin configuration - Never combine alloworigins=[""] with allowcredentials=True - Update .env.example with placeholder domains instead of Fix Fixed in commit 809416b on branch releases/1.4.x — changed CORS default from [""] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Refresh tokens are accepted as URL query parameters in the keyserver and telemetry server routes. Affected Code Impact Tokens in URL query parameters are exposed in: - Server access logs - Proxy/CDN logs - Browser history - HTTP Referer headers - Network monitoring tools This creates significant token leakage risk. Recommended Fix - Accept refresh tokens in the request body (POST) instead of query parameters - Use Body(...) instead of Query(...) Fix Fixed in commit 4b2adb0 on branch releases/1.4.x — moved refresh token from Query parameter to POST body via RefreshRequest Pydantic model.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /ready endpoint in opensslencryptserver/server.py at lines 159-175 catches database errors and returns the full exception string in the response. Affected Code 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": "notready", "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.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The revokekey method in opensslencryptserver/modules/keyserver/service.py at lines 195-270 accepts a clientid parameter but never verifies that the requesting client is the same as key.ownerclientid. Impact Any authenticated client can revoke any other client's key, as long as they provide a valid revocation signature. While the signature requirement mitigates this somewhat (you need the private key to sign), the lack of ownership check is a defense-in-depth gap. Recommended Fix - Add an ownership check: verify clientid == key.ownerclientid before allowing revocation - Return 403 Forbidden if the requesting client does not own the key Fix Fixed in commit 05e45f3 on branch releases/1.4.x — added documentation that ML-DSA signature verification IS the cryptographic ownership check; added info-level logging on successful verification.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PublicKeyBundle.fromdict() method in opensslencrypt/modules/keybundle.py at lines 329-361 creates bundles from untrusted data without verifying the signature. The docstring warns to call verifysignature() after creation, but the toidentity() method (line 363-391) can convert an unverified bundle directly to an Identity object. Affected Code Impact If fromdict() followed by toidentity() is called without an intervening verifysignature() call, encryption could be performed against an attacker's public key, leaking secrets. While keyresolver.py (lines 146-147) does verify before use, the unguarded API path remains directly callable. Recommended Fix - Add a verified flag to PublicKeyBundle that must be set before toidentity() can be called - Or have toidentity() automatically call verifysignature() and raise on failure - Or make fromdict() require verification as part of construction Fix Fixed in commit f4a1ba6 on branch releases/1.4.x — fromdict() now verifies selfsignature…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In opensslencrypt/modules/jsonvalidator.py at lines 234-238, when the jsonschema library is not installed, all schema validation is silently skipped with only a print warning. Affected Code Additionally, unknown metadata format versions (line 288-293) bypass schema validation entirely, and all schemas use additionalProperties: true allowing arbitrary extra fields. Impact An attacker who can influence the Python environment (remove the jsonschema package) or craft metadata with an unknown version number can bypass all schema checks. Malformed or malicious metadata will be accepted without validation. Recommended Fix - Make jsonschema a required dependency, not optional - Or fail-closed: refuse to process metadata when validation cannot be performed - Reject unknown format versions instead of silently skipping validation - Consider using additionalProperties: false in schemas Fix Fixed in commit 6e7f938 on branch releases/1.4.x — validateagainstschema() now raises…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The generatepseudorandomsequence() function in opensslencrypt/plugins/steganography/core/utils.py at lines 89-91 uses Python's random module (Mersenne Twister) for steganographic pixel/sample selection. Affected Code Additionally, the steganography password is stored as a plain Python string (not SecureBytes) and only 8 bytes (64 bits) of the SHA-256 hash are used for the seed, reducing effective security to 64 bits. Impact The Mersenne Twister's state can be recovered from approximately 624 outputs. An attacker who knows or guesses the password can predict the PRNG sequence and determine exactly which pixels contain hidden data, potentially extracting the hidden data without the password. Recommended Fix - Use HMAC-DRBG or secrets module for cryptographically secure pixel selection - Use full 32-byte SHA-256 output as seed material - Store the password in SecureBytes instead of a plain string Fix Fixed in commit 09e96e0 on branch releases/1.4.x — replaced…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Passwords passed via the --password / -p CLI argument in opensslencrypt/modules/cryptclisubparser.py at lines 150-154 are visible to any user on the system via ps aux or /proc/[pid]/cmdline. Affected Code Similarly, --keystore-password exposes the keystore password. Impact On multi-user systems, any user can observe the encryption password by listing processes. The CRYPTPASSWORD 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 OPENSSLENCRYPTPASSWORD env var support; --password now emits deprecation…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Severity: HIGH Summary The TOTP brute-force rate limiter in opensslencryptserver/modules/pepper/totp.py at lines 47-98 uses an in-memory defaultdict(list) as a class variable. Affected Code Impact 1. Rate limit state is not shared across multiple server instances/workers — an attacker can distribute attempts 2. All rate limit state is lost on server restart — allows immediate retry 3. In multi-worker deployments, each worker has independent rate limit state Recommended Fix - Use Redis or the database for rate limit state storage - Or use a shared-memory approach for multi-worker deployments - At minimum, persist lockout state to survive restarts Fix Fixed in commit 2749bc0 on branch releases/1.4.x — added abstract RateLimitBackend with InMemoryBackend and DatabaseBackend implementations; defaults to DatabaseBackend when DB available.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Severity: HIGH Summary The Whirlpool hash implementation in opensslencrypt/modules/registry/hashregistry.py at lines 570-589 uses glob patterns to find .so modules in site-packages and loads the first match via importlib without verifying module integrity. Affected Code Impact The glob pattern "whirlpoolpy313.so" is broad and takes the first match without verifying: - File hash/signature - File ownership/permissions - Whether it's a legitimate module If an attacker can place a malicious .so file matching this pattern in any site-packages directory, it will be loaded and native code executed. Recommended Fix - Verify the module's integrity (hash or signature) before loading - Use a specific filename rather than a glob pattern - Check file permissions and ownership Fix Fixed in commit 963d0d1 on branch releases/1.4.x — added os.path.realpath() to resolve symlinks and validation that found .so files are within known site-packages directories before loading.
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.