The CVE description names 'openssl_encrypt' as the product, which misleads security scanners and analysts into treating this as a cryptographic library flaw. In reality, this is a PHP application using the openssl_encrypt() function, where the /ready health check endpoint returns full database exception strings to unauthenticated callers. This is a health-check-path-gone-wrong scenario, not a crypto vulnerability.
The CVSS 7.5 rating likely understates real risk in containerized deployments. Health check endpoints are polled continuously by Kubernetes, load balancers, and monitoring systems—attackers don't need to time reconnaissance; they simply wait for a transient database error or deliberately trigger one. The EPSS score of 0.00259 likely reflects that most organizations don't realize their health endpoints are doing this, meaning defenders aren't looking for it.
The more significant risk is credential disclosure. Database exception strings routinely embed connection parameters including plaintext credentials in connection strings. This isn't just hostname leakage—it enables lateral movement. Whether credentials actually appear depends on your deployment configuration: PHP's PDO exceptions typically don't echo password parameters, but many custom implementations and older frameworks do. You should assume credential exposure is possible and audit your exception output.
The patch fix is likely in the health endpoint response handling, not in the openssl_encrypt function itself. The real vulnerability is treating /ready as throwaway plumbing rather than a security boundary. Nobody threat-models health endpoints, and the tooling ecosystem doesn't scaffold them with output sanitization by default. Check your health endpoints in production: confirm they return minimal status codes rather than exception payloads, and ensure database connection strings never appear in any error output.