CVE-2026-118513 in Symfony
Riassunto
di VulDB • 04/11/2026
L'elusione dell'autenticazione tramite spoofing in X509Authenticator e X509AuthenticationListener di Symfony, nelle versioni precedenti alla 5.4.56, alle 6.x precedenti alla 6.4.50, alle 7.x precedenti alla 7.4.23 e alle 8.x precedenti alla 8.1.11, consente a un attaccante in possesso di un certificato emesso dall'CA (Certification Authority) attendibile dell'applicazione che può influenzare il CN (Common Name) di autenticarsi come utente arbitrario dell'applicazione, incluso uno con privilegi elevati, sfruttando una correzione incompleta per CVE-2026-45063.
X509Authenticator estrae l'identificatore utente dal Subject DN (Distinguished Name) che il server web trasmette tramite $_SERVER['SSL_CLIENT_S_DN']. La correzione per CVE-2026-45063 ha ancorato tale estrazione a un confine RDN (Relative Distinguished Name), ma l'espressione regolare utilizzata non era consapevole delle sequenze di escape. L'espressione viene eseguita su un DN già serializzato, quindi non è in grado di distinguere un separatore RDN da un carattere separatore che si verifica all'interno di un valore. Secondo lo standard RFC 2253, utilizzato da Apache e dal $ssl_client_s_dn di nginx, una virgola presente all'interno di un valore viene escapata come \,, ma l'espressione la interpreta comunque come un separatore. L'RFC 2253 non tratta inoltre il carattere / come un separatore, lasciandolo così com'è all'interno di un valore, mentre l'espressione considera ogni / come un separatore. Il formato legacy X509_NAME_oneline(), utilizzato dal LegacyDNStringFormat di Apache e da $ssl_client_s_dn_legacy di nginx, è lo speculare: esso escapa la barra come \/ e lascia la virgola non escapata. In questo formato, un certificato privo dell'attributo emailAddress o il cui CN avvelenato (poisoned) lo precede, si autentica utilizzando l'indirizzo email "smuggled" (nascosto).
Per supportare sia l'RFC 2253 che il formato legacy X509_NAME_oneline(), X509Authenticator e X509AuthenticationListener ora dividono il DN in RDN prima di cercare l'attributo, anziché abbinare l'attributo alla stringa serializzata. Vengono selezionati i separatori dalla serializzazione, si effettua la divisione solo sulle occorrenze non escapate di tali separatori, si de-escape ogni RDN successivamente applicando le regole del relativo formato e si richiede che l'attributo occupi un intero RDN. La grammatica dei valori accettati rimane invariata.
Le applicazioni che trasmettono una chiave utente per-attributo (come SSL_CLIENT_S_DN_Email) e i deployment il cui CA genera o convalida il subject non sono interessati da questa vulnerabilità.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.