jackson-check

Selbstprüfungstool für insgesamt 26 Sicherheitshinweise zu jackson-databind + jackson-core. Einzelnes Jar ohne Abhängigkeiten, keine Netzwerkverbindung.

Es beantwortet drei Fragen, die Dependabot nicht beantworten kann:

0. Bin ich von dem betroffen, das Dependabot nicht erfasst hat? —— Stand 2026-10-05 bleibt nur noch CVE-2026-68498 in jackson-core übrig (siehe Abschnitt „v0.3.0").
1. Von wie vielen dieser 26 bin ich wirklich betroffen? —— Durchsucht euren Quellcode nach Auslösebedingungen (@JsonView / polymorphe Typen / Groß-/Kleinschreibung-unabhängiges Matching……) und reduziert „eine betroffene Version ist installiert" auf „dieses Feature wird tatsächlich genutzt".
2. Auf welche Version sollte ich eigentlich aktualisieren? —— Die von den einzelnen Advisories angegebenen Fix-Versionen sind untereinander inkonsistent; erst die Schnittmenge aller Einträge liefert die Antwort.

java -jar jackson-check.jar ./target ./src

🔴 v0.4.0 (2026-10-05): Die Version „alles auf einmal repariert“ hat sich erneut geändert – 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3

Am 09-30 und 10-01 hat FasterXML erneut 4 High-Advisories veröffentlicht (alle 7.5, alle Denial of Service):

Nummer	Koordinate	Thema	Auslösebedingung
CVE-2026-91776	jackson-databind	Jede unbekannte type id hinterlässt einen Eintrag im Cache für die gesamte Prozesslebensdauer, der Speicher wächst nur	@JsonTypeInfo(use = Id.NAME, defaultImpl = …) + Angreifer kann die type id kontrollieren + Mapper wird langfristig wiederverwendet
CVE-2026-91777	jackson-databind	Beim nachträglichen Definieren von Vorwärtsreferenzen in umgekehrter Reihenfolge etwa N²/2 Vergleiche (N=2000 → 2.003.000 Vergleiche)	Nicht vertrauenswürdiges JSON in eine Collection oder Map mit @JsonIdentityInfo deserialisieren
CVE-2026-89425	jackson-core	Fehlerhafte Tokens werden vollständig in die Fehlermeldung eingebaut, ohne Begrenzung durch maxErrorTokenLength	Nur der Pfad createParser(DataInput); laut Advisory gibt es keine Konfiguration, die das abmildert
CVE-2026-89407	jackson-core	Quadratisches Backtracking der Regex in NumberInput.looksLikeValidNumber() (bei 160.000 Zeichen gemessen 74,4 Sekunden)	Einen String aus JSON an ein numerisches Feld binden (Standardverhalten von databind); dieser Pfad unterliegt maxStringLength (Standard 20 Millionen) statt maxNumberLength (Standard 1000)

Die Fixversionen beider Koordinaten tragen dieselbe Nummer: 2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3 (alle auf Central herunterladbar; 89407 ist im 3.2-Zweig in 3.2.2 behoben, 89425 benötigt 3.2.3, es gilt die höhere Version).

Daher reichen die von v0.2.0 / v0.3.0 ausgegebenen 2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2 seit dem 09-30 nicht mehr aus. Die JARs der alten Version wissen davon nichts – bitte mit v0.4.0 erneut scannen.

⚠️ Diese vier sind keine Dependabot-Blindstellen: Sie wurden am Tag ihrer Veröffentlichung in die globale GitHub-Schwachstellendatenbank aufgenommen, Dependabot warnt ordnungsgemäß. v0.4.0 übernimmt sie nur, damit die Antwort auf „auf welche Version soll ich aktualisieren“ korrekt bleibt.

🔴 Gleichzeitig wird eine Aussage von v0.2.0 korrigiert: Der Abschnitt „v0.2.0“ weiter unten schreibt „diese 4 sind nicht in der globalen GitHub-Schwachstellendatenbank erfasst, Dependabot meldet sie nicht“ – das galt bis zum 09-14, seit dem 2026-09-28 gilt es nicht mehr – alle vier sind inzwischen in der globalen Datenbank erfasst (ASSERT2 in gen_rules.py am 10-05 erneut ausgeführt: Blindstelle auf der databind-Seite 4 → 0). Das Einzige, was sich derzeit noch nicht finden lässt, ist CVE-2026-68498 in jackson-core.

🔴 v0.3.0 (2026-09-21): jackson-core ist eine andere Koordinate, ein Scan von databind findet sie nicht

Die gesamte Prüftabelle von v0.2.x enthielt nur eine einzige artifactId: jackson-databind. Daher konnte dieses Tool von den 7 Advisories, die FasterXML im Repository jackson-core veröffentlicht hat, keines einzige finden – und es meldet deshalb keinen Fehler, sondern überspringt einfach stillschweigend alle jackson-core-*.jar. „Nicht gefunden“ und „du bist sicher“ sehen im Bericht identisch aus.

v0.3.0 ändert die Granularität der Prüfung von advisory × groupId × Intervall auf advisory × groupId × artifactId × Intervall, Prüfung, Schnittmengenbildung und „diese Koordinate wurde nicht gescannt“ verwenden alle die vollständige Koordinate als Schlüssel.

Der wichtigste Eintrag – CVE-2026-68498 (high 7.5, 2026-09-12): StreamReadConstraints.maxNameLength (Standard 50.000 Zeichen) greift auf dem Zeicheneingabepfad nicht. ReaderBasedJsonParser ruft beim Akkumulieren von Attributnamen die Obergrenze für String-Länge auf (Standard 100 Millionen, etwa das 2000-Fache), die eigentliche Namensprüfung läuft erst, nachdem der gesamte Key gescannt wurde – zu diesem Zeitpunkt sind bereits etwa 200 MB alloziert. Ein einziger überlanger JSON-Key genügt, die Standardkonfiguration ist betroffen.

• Betroffen: >= 2.16.0, <= 2.18.9 → 2.18.10 · >= 2.19.0, <= 2.21.5 → 2.21.6 · >= 2.22.0, <= 2.22.1 → 2.22.2 · 3.x (tools.jackson.core) <= 3.1.5 → 3.1.6 · <= 3.2.1 → 3.2.2
• Byte-Eingabe ist nicht betroffen: UTF8StreamJsonParser validiert bei jeder Puffererweiterung erneut. Wer aus byte[] / InputStream parst, ist nicht betroffen; betroffen ist nur, wer aus String / Reader / char[] parst.
• Bytecode in beide Richtungen geprüft: Der Aufruf von validateNameLength existiert nur im ReaderBasedJsonParser der korrigierten Version, in der betroffenen Version fehlt er (in allen drei Zweigen reproduziert: 2.18.9→2.18.10 · 2.21.5→2.21.6 · 3.1.5→3.1.6).

⚠️ Grenzen der Werkzeugfähigkeiten, hier festgehalten, damit sie nicht falsch interpretiert werden: Dieses Werkzeug kann die jar-Version beurteilen, aber nicht, wie du sie aufrufst – bei der häufigsten Schreibweise readValue(someStringVariable, …) kann ein Textscan nicht erkennen, ob diese Variable ein String oder ein byte[] ist. Daher bedeutet „keine Auslösebedingung gefunden“ nicht, dass du nicht betroffen bist – so steht es auch im Bericht.

🔴 Nicht so lesen: „Dependabot ist bei jackson-core völlig blind“: Von den 7 Einträgen zu jackson-core ist nur CVE-2026-68498 in der globalen GitHub-Schwachstellendatenbank nicht auffindbar; die übrigen 6 sind erfasst, und Dependabot warnt ordnungsgemäß. Dieser eine Eintrag wird bei jedem erneuten Lauf von ASSERT-C2 in gen_rules.py überprüft – ändert sich die Zahl, wird die Generierung verweigert.

v0.2.0 (2026-09-14): Am 08-21 / 09-01 wurden erneut 4 Einträge veröffentlicht, die damals nicht in der globalen GitHub-Schwachstellendatenbank erfasst waren

🔴 Dieser Abschnitt ist ein Protokoll vom 09-14, zwei Stellen sind bereits veraltet (siehe oben „v0.4.0“): ① Diese 4 Einträge wurden am 2026-09-28 in die globale Datenbank aufgenommen, Dependabot meldet sie jetzt; ② die Versionen für „alles auf einmal beheben“ sind nicht mehr 2.18.10 / 2.21.6 / 3.1.6. Der Originaltext bleibt erhalten und wird nicht gelöscht.

FasterXML hat auf der Security-Seite des eigenen Repositories 4 neue Einträge veröffentlicht: