CVE-2026-68494 in jackson-core
Riassunto
di VulDB • 04/08/2026
La correzione rilasciata in jackson-core 2.18.6 e 2.21.1 per CVE-2026-18401 (GHSA-72hv-8253-57qq, elusione del vincolo di lunghezza nei numeri nel parser non bloccante) è incompleta. Questo record copre la restante modalità di bypass.
La correzione precedente collegava validateIntegerLength() a una nuova funzione helper _setIntLength() e la invocava ovunque venisse determinata la parte intera di un numero: quando arriva un byte terminatore, viene rilevato un punto (.) o 'e'/'E', oppure l'input termina all'interno di un valore completamente memorizzato nel buffer. Non è stata tuttavia invocata sul percorso rilevante per l'attaccante in cui il parser rimane senza input mentre si trova ancora nello stato minore MINOR_NUMBER_INTEGER_DIGITS e restituisce NOT_AVAILABLE al chiamante.
Di conseguenza, un attaccante che trasmette JSON a un parser non bloccante tramite molti piccoli chunk, senza inviare mai un byte terminatore, mantiene indefinitamente il parser all'interno dello stato MINOR_NUMBER_INTEGER_DIGITS. _textBuffer.expandCurrentSegment() accresce l'accumulatore ad ogni chunk mentre validateIntegerLength() non viene mai chiamata. L'accumulatore è limitato solo da maxStringLength (20 MiB per impostazione predefinita) anziché da maxNumberLength (1000 per impostazione predefinita), con un'amplificazione di circa 20.000 volte rispetto al limite documentato. Poiché i valori char Java occupano due byte, una singola connessione può essere spinta fino a circa 40 MiB di heap prima che il validatore si attivi finalmente quando il valore viene completato.
Il codice equivalente per il percorso delle frazioni è corretto: _finishFloatFraction() chiama _setFractLength() prima del suo ritorno NOT_AVAILABLE. La chiamata mancante interessa i percorsi delle cifre intere in _startPositiveNumber(), _startNegativeNumber() e _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase.
Impatto: framework reattivi come Spring WebFlux/Reactor, Quarkus, Helidon e Vert.x alimentano il parser asincrono con i byte HTTP o gRPC in arrivo man mano che arrivano, che è esattamente la forma di alimentazione a chunk richiesta. Gli operatori che impostano StreamReadConstraints.maxNumberLength aspettandosi che questo limiti la memoria per valore numerico non ottengono tale garanzia; la memoria si accumula per connessione concorrente e una concorrenza controllata dall'attaccante può esaurire l'heap JVM. I parser sincroni (UTF8StreamJsonParser, ReaderBasedJsonParser) e il parser asincrono che opera su input completo non sono interessati.
L'esecuzione dell'exploit richiede solo la capacità di trasmettere dati a un endpoint di parsing; non sono necessarie autorizzazioni o interazione con l'utente.
Questo problema interessa com.fasterxml.jackson.core:jackson-core dalla versione 2.15.0 alla 2.18.7, dalla 2.19.0 alla 2.21.3 e dalla 2.22.0 alla 2.22.0, nonché tools.jackson.core:jackson-core dalla 3.0.0 alla 3.1.3 e dalla 3.2.0 alla 3.2.0. Le versioni precedenti alla 2.15.0 non sono interessate, poiché StreamReadConstraints -- che definisce l'impostazione maxNumberLength -- è stato introdotto per la prima volta in jackson-core 2.15.0; pertanto, nelle release precedenti non esiste alcun vincolo di questo tipo da eludere. Si noti che GHSA-r7wm-3cxj-wff9 indica il range interessato delle versioni 2.x senza un limite inferiore.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.