CVE-2026-74879 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt versions before 1.4.0 contain an information disclosure vulnerability in the /ready endpoint that returns full database exception strings to unauthenticated callers. Attackers can trigger database errors to extract sensitive information including hostnames, IP addresses, connection parameters, and potentially credentials from exception messages.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The openssl_encrypt library prior to version 1.4.0 contains a critical information disclosure vulnerability affecting the /ready endpoint. This specific route is typically designed for health checks or readiness probes in containerized environments, where it should return only simple status indicators such as HTTP success codes without exposing internal application details. However, due to improper error handling and exception management within this endpoint, the system fails to sanitize database-related errors before sending them back to the client. This flaw allows unauthenticated actors to interact with the endpoint in a way that triggers underlying database exceptions, which are then reflected directly in the HTTP response body rather than being suppressed or replaced with generic messages.
The technical root cause of this vulnerability lies in the lack of input validation and insufficient exception wrapping around database queries executed during the readiness check process. When an attacker sends malformed requests or specific payloads to the /ready endpoint, it causes a failure in the underlying data access layer. Instead of catching these exceptions and returning a standardized success response as intended by the health check logic, the application propagates the raw stack trace or exception message back to the requester. This behavior violates fundamental security principles regarding error handling, specifically failing to abstract internal implementation details from external users.
The operational impact of this vulnerability is significant because it facilitates unauthorized access to sensitive infrastructure information. By analyzing the returned database exception strings, an attacker can extract critical configuration data including hostnames, IP addresses, and specific connection parameters such as port numbers or service names. In more severe scenarios where credentials are included in error messages due to misconfigured logging or debugging settings, attackers may obtain usernames and passwords for the underlying database system. This information serves as a valuable reconnaissance tool, enabling further targeted attacks against the infrastructure by revealing network topology and authentication mechanisms that should remain hidden from unauthenticated parties.
From a classification perspective, this vulnerability aligns with CWE-209 which describes the generation of an error message that includes sensitive information useful for an attacker. It also relates to CWE-754 regarding improper check for unusual or exceptional conditions, as the application fails to handle unexpected database states gracefully. In terms of attack vectors, this falls under ATT&CK technique T1589 which involves gathering victim identity information through email addresses and other means, specifically leveraging software misconfigurations to extract data that aids in subsequent phases like credential access or network service discovery.
To mitigate this vulnerability, organizations must upgrade the openssl_encrypt library to version 1.4.0 or later where these error handling issues have been addressed. For systems unable to update immediately, a temporary mitigation involves implementing a reverse proxy or web application firewall rule that intercepts responses from the /ready endpoint and strips out any content resembling database exception messages before they reach the client. Additionally, developers should review all health check endpoints across their applications to ensure they do not expose internal stack traces or configuration details. Enabling strict error handling policies in production environments is essential to prevent such information leaks, ensuring that only generic success or failure indicators are returned for public-facing diagnostic routes.