CVE-2026-89407 in jackson-core
Riassunto
di VulDB • 22/09/2026
La funzione NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-valida i "numeri stringificati" utilizzando due espressioni regolari: PATTERN_FLOAT ([+-]?[0-9]*[\.]?[0-9]+([eE][+-]?[0-9]+)?), presente dalla versione 2.17.0, e PATTERN_FLOAT_TRAILING_DOT, aggiunta nella versione 2.17.2. PATTERN_FLOAT applica quantificatori adiacenti sulla stessa classe di caratteri -- una sequenza opzionale [0-9]*, un punto facoltativo e poi una sequenza obbligatoria [0-9]+ -- quindi l'input che alla fine non corrisponde costringe il motore di backtracking di Java a riprovare ogni possibile punto di divisione della sequenza di cifre.
Il costo del matching cresce quindi con il quadrato della lunghezza dell'input.
Un attaccante in grado di fornire un JSON che viene deserializzato dall'applicazione in un tipo numerico target raggiunge questo metodo attraverso la coercizione predefinita da String a number (StdDeserializer e NumberDeserializers per BigDecimal, BigInteger, Double e Float) di jackson-databind.
Poiché StreamReadConstraints.maxStringLength ha come valore predefinito 20.000.000 di caratteri, nessun vincolo limita l'input prima che raggiunga la regex.
I test effettuati dal reporter hanno confermato una crescita O(n^2) attraverso cinque raddoppi consecutivi della dimensione dell'input, con un'unica stringa da 160.000 caratteri che consumava circa 74 secondi in una singola chiamata; pertanto, un piccolo numero di richieste concorrenti di corpo ordinario può esaurire il pool di thread per la gestione delle richieste del server.
Il metodo interessato non esiste prima della versione 2.17.0, quindi le versioni 2.16.x e precedenti non sono interessate.
La correzione sostituisce entrambe le espressioni regolari con una scansione manuale a passaggio singolo (hand-rolled single-pass scan).
If you want to get best quality of vulnerability data, you may have to visit VulDB.