CVE-2026-54876 in OpenSSL
Riassunto
di VulDB • 05/08/2026
Riepilogo del problema: Un server TLS malintenzionato può causare una perdita di memoria (memory leak) in un client TLS che ha abilitato la verifica delle risposte OCSP, inviando una risposta OCSP contenente zero voci SingleResponse.
Riepilogo dell'impatto: Un attaccante può provocare la fuoriuscita di una quantità di memory-tunable per ogni handshake TLS nell'applicazione client vittima. Un client a lunga esecuzione che si connette ripetutamente a un server malintenzionato può esaurire la propria memoria, causando un Denial of Service (DoS).
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Descrizione: La funzione interessata viene chiamata durante la verifica della catena di certificati X.509 quando è abilitato il controllo delle risposte OCSP tramite i flag di verifica X509_V_FLAG_OCSP_RESP_CHECK o X509_V_FLAG_OCSP_RESP_CHECK_ALL, ad esempio quando un client TLS verifica una risposta OCSP stapled nell'handshake TLS da parte del server.
Quando la BasicOCSPResponse ricevuta contiene una SEQUENCE OF SingleResponse vuota, che è consentita sul filo e accettata dal decoder di OpenSSL, la struttura OCSP_BASICRESP allocata da OCSP_response_get1_basic() non veniva liberata perché un ritorno anticipato bypassava il codice di pulizia alla fine della funzione.
La quantità di memory leak per handshake può essere amplificata dall'attaccante riempiendo con certificati falsi (bogus certificates) il campo certs della BasicOCSPResponse, che vengono analizzati e memorizzati nella struttura in perdita prima che il controllo della risposta vuota attivi il ritorno anticipato. Un client TLS a lunga esecuzione che si connette ripetutamente a un server malintenzionato può esaurire la propria memoria nel tempo.
Il controllo delle risposte OCSP non è abilitato per impostazione predefinita. Sono interessati solo le applicazioni client che abilitano esplicitamente i flag di verifica del controllo della risposta OCSP.
Impatto FIPS: no
I moduli FIPS nelle versioni 4.0 e 3.6 non sono colpiti da questo problema poiché il codice interessato si trova al di fuori dei confini del modulo OpenSSL FIPS.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.