Alle vier `JsonParser`-Implementierungen weisen diesen Fehler auf. Der Angriff lässt sich durch
jede von ihnen gleichermaßen ausnutzen – egal ob die Eingabe über `InputStream`, `Reader`, `DataInput` oder die asynchrone
nicht-blockierende Feeder-API erfolgt.

**Angriffsvektoren:**

| # | Strategie | Beispiel-Payload | Tiefenzuwachs | Betroffene Parser |
|---|----------|----------------|-----------------|------------------|
| 1 | Array-Verschachtelung | `[[[…]]]` — 1.001 aufeinanderfolgende `[`-Tokens | +1 pro `[` | Alle vier |
| 2 | Objekt-Verschachtelung | `{"k":{"k":{…}}}` — 1.001 aufeinanderfolgende `{`-Tokens | +1 pro `{` | Alle vier |
| 3 | Abwechselnde Verschachtelung | `[{"k":[{"k":…}]}]` — 1.001 gemischte `[`/`{`-Tokens | +1 pro `[` oder `{` | Alle vier |

Wichtige Beobachtungen:

- **Array-Verschachtelung – minimaler Overhead:** Es werden nur `[`- und `]`-Tokens benötigt; keine Schlüssel, Werte oder Leerzeichen. Eine 2.002-Byte-Payload mit 1.001 Klammerpaaren reicht aus, um das Standardlimit von 1.000 zu überschreiten.
- **Objekt-Verschachtelung – verstärkter Heap-Druck:** Jedes `{` allokiert zusätzlich einen `JsonReadContext`-Schlüsselslot zum Knoten der Tiefenkette, was den Speicherverbrauch bei extremen Tiefen weiter erhöht.
- **Abwechselnde Verschachtelung – Umgehung von Web Application Firewalls (WAF):** Musterbasierte Abwehrmaßnahmen, die wiederholte `[[[`- oder `{{{`-Sequenzen erkennen, sind gegenüber abwechselnder Token-Verschachtelung blind; der Tiefenzähler des Parsers erhöht sich unabhängig vom Tokentyp identisch.
- **Nicht-blockierender Feeder – gleiche Payload, andere Angriffsfläche:** Alle drei Verschachtelungsstrategien sind gleichermaßen über `NonBlockingJsonParser` und die `ByteArrayFeeder`-API ausnutzbar. Das Dokument kann in beliebig kleinen Teilen geliefert werden; `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()` erhöhen den Tiefenzähler bei jedem kontextöffnenden Token, unabhängig davon, wie die Bytes ankommen, und akkumulieren die Tiefe über mehrere `feedInput()`-Aufrufe hinweg.

Alle drei Verschachtelungsstrategien sind über jede der vier `JsonParser`-Implementierungen erreichbar.
Mit 2.13.5 gelingt das Parsen stillschweigend; mit dieser Behebung werfen alle drei Vektoren
`StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)`.

---

### Sonatype-2022-6438 — Unbegrenzte numerische Token-Länge

**Sicherheitsdetails**

| Feld | Wert |
|-------|-------|
| Sonatype-ID | [sonatype-2022-6438](https://guide.sonatype.com/vulnerability/sonatype-2022-6438/security-details) |
| Beschreibung | jackson-core — Denial of Service (DoS) |
| Veröffentlicht | 2022-12-07 |
| Quelle | Sonatype |
| CVSS-v3.1-Score | **7.5 HIGH** — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Zuweisung von Ressourcen ohne Begrenzung oder Drosselung |
| EPSS-Score | 0% |
| Upstream-Fix-PRs | [jackson-core#827](https://github.com/FasterXML/jackson-core/pull/827), [jackson-core#846](https://github.com/FasterXML/jackson-core/pull/846) |

**Verwundbare Methoden (wie von Sonatype identifiziert)**

| Methode | Anmerkungen |
|--------|-------|
| `com.fasterxml.jackson.core.base.ParserBase._parseSlowInt(I)V` | Verwundbarer Parameter: Index 0 |
| `com.fasterxml.jackson.core.base.ParserBase.convertNumberToBigDecimal()V` | |
| `com.fasterxml.jackson.core.base.ParserMinimalBase.getValueAsDouble(D)D` | Verwundbarer Parameter: Index 0 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDecimal()` | Gibt `BigDecimal` zurück |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDouble(Z)D` | |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsFloat(Z)F` | |

Jede dieser Methoden verarbeitet den rohen Ziffernpuffer, ohne vorher dessen Länge zu validieren. Die Übergabe eines
ausreichend langen numerischen Tokens führt zu unbegrenzter Heap-Allokation und CPU-Erschöpfung, wenn die JVM
versucht, aus den unbeschränkten Pufferinhalten einen `BigInteger` oder `BigDecimal` zu instanziieren.

---

**Grundursache:** Vor 2.15.0 legte `JsonParser` keine Begrenzung für die Bytelänge von Integer-Tokens, Tokens in wissenschaftlicher Notation, einfachen Gleitkomma-Tokens oder zusammengesetzten Gleitkomma-Tokens fest. Wenn ein Parser seinen internen `_textBuffer` zum Sammeln von Ziffern allokiert, kann ein Angreifer eine Zahl mit Millionen von Ziffern bereitstellen, wodurch der Puffer unbegrenzt wächst und schließlich den Heap-Speicher erschöpft.

**Verwundbare Codepfade:**

Es gibt zwei strukturell unterschiedliche verwundbare Pfade – einen, der den drei synchronen Parsern gemeinsam ist,
und einen zweiten unabhängigen Pfad durch den asynchronen Parser.

**Pfad A – synchrone Parser** (drei Implementierungen, eine gemeinsame Senke):```
JsonParser.nextToken()                         // common entry point
  │
  ├─ ReaderBasedJsonParser   ─┐
  ├─ UTF8StreamJsonParser     ├─→ ParserBase.resetInt() / resetFloat()
  └─ UTF8DataInputJsonParser ─┘         │
                                        ▼
                               _textBuffer.contentsAsString()
                               ⚠  no length check — buffer grows without bound

The non-blocking (async) parser is a particularly notable attack surface: it contains its own
digit-accumulation loops in `_startPositiveNumber`, `_startNegativeNumber`,
`_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, and `_finishFloatExponent`
that set `_intLength` / `_fractLength` / `_expLength` directly without ever going through
`ParserBase.resetInt()` or `resetFloat()`. This means the upstream PR #827 fix (which added
validation only to `ParserBase`) **left `NonBlockingJsonParser` completely unprotected**.
This was discovered during extended attack-surface analysis and remediated in this branch.

**Angriffsvektoren:**

| # | Token-Form | Beispiel-Payload | `intLen` | `fractLen` | `expLen` | Gesamt | Beschränkung |
|---|------------|----------------|----------|------------|----------|-------|------------|
| 1 | Ganzzahl | `999…` — 199.999 aufeinanderfolgende Ziffern | 199.999 | 0 | 0 | 199.999 | `validateIntegerLength` |
| 2 | Dezimalbruch | `0.999…` — einstellige Ganzzahl, 1.001-stelliger Bruchteil | 1 | 1.001 | 0 | 1.002 | `validateFPLength` |
| 3 | Wissenschaftliche Notation | `1e999…` — einstellige Mantisse, 1.001-stelliger Exponent | 1 | 0 | 1.001 | 1.002 | `validateFPLength` |
| 4 | Zusammengesetzte Gleitkommazahl | `0.999…e999…` — 500-stelliger Bruchteil, 500-stelliger Exponent | 1 | 500 | 500 | 1.001 | `validateFPLength` |

Wichtige Beobachtungen:

- **Ganzzahl — Vorzeichenzeichen ist keine Ziffer:** Das führende `-` ist von der Ziffern-Akkumulation ausgeschlossen; `-999…` und `999…` erzeugen identische `intLen`-Werte und lösen die Beschränkung bei derselben Schwelle aus.
- **Dezimalbruch — kurze Ganzzahl, unbegrenzter Bruchteil:** Der ganzzahlige Teil kann eine einzelne Ziffer (0) sein, während der Bruchteil unbegrenzt wächst; der Dezimalpunkt selbst ist von der Zählung ausgeschlossen.
- **Wissenschaftliche Notation — kompakt und dennoch katastrophal:** Bei ~1.004 Byte ist dies das kleinste wirksame Payload; es erzwingt die Instanziierung eines `BigDecimal` mit Skala ±10^1001, was eine unbegrenzte Zwischen-Heap-Allokation erfordert, ungeachtet der geringen Größe des Tokens.
- **Zusammengesetzte Gleitkommazahl — Umgehung durch geteilte Grenzwerte:** Bei `fractLen = 500` und `expLen = 500` erreicht keine Komponente für sich genommen die 1.000-Ziffern-Schwelle. Die vereinheitlichte Prüfung `validateFPLength(intLen + fractLen + expLen)` ist die einzige Verteidigung, die diese Lücke schließt.
- **Nicht-blockierender Parser — unabhängiger Bypass:** Alle vier oben genannten Token-Formen sind unabhängig über `NonBlockingJsonParser` mittels `ByteArrayFeeder` ausnutzbar. Im Gegensatz zu den synchronen Parsern akkumuliert `NonBlockingJsonParser` Ziffern in privaten Schleifen (`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`), die `_intLength` / `_fractLength` / `_expLength` direkt schreiben und `ParserBase.resetInt()` sowie `resetFloat()` vollständig umgehen. Der Upstream-PR #827 — der nur `ParserBase` modifizierte — ließ diesen Parser daher vollständig ungeschützt, was sechs unabhängige Patches an den Aufrufstellen in dieser Behebung erforderte.

Alle vier Token-Formen und der nicht-blockierende Bypass werden zum Zeitpunkt der Tokenisierung abgewiesen — bevor ein `BigDecimal` oder `BigInteger`
konstruiert wird — durch `validateIntegerLength` und `validateFPLength` in `ParserBase` (synchronen
Paser) und an sechs dedizierten Aufrufstellen in `NonBlockingJsonParser` (asynchroner Parser). Mit 2.13.5 werden alle vier Token-Formen stillschweigend akzeptiert; mit dieser Behebung wirft jeder
Parser `StreamConstraintsException: Number length (N) exceeds the maximum length (1000)`.

> **Hinweis zu `UTF8DataInputJsonParser` mit großen Payloads:** Der DataInput-Parser hat eine
> bereits bestehende interne Puffergrenze von 65 536 Byte ([jackson-core#493](https://github.com/FasterXML/jackson-core/issues/493)).
> Dokumente, die diese Größe überschreiten (z. B. 199.999-stellige PoC-Payloads ≈ 200 KB), lösen eine
> `ArrayIndexOutOfBoundsException` aus, bevor die Längenbeschränkung greifen kann. Der Schutz der Zahlenlänge
> für `UTF8DataInputJsonParser` wird daher mit kürzeren Payloads
> (≤ 1.001 Ziffern) verifiziert, bei denen der Fehler weiterhin reproduzierbar ist.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — Umgehung der Dokumentlängen-Beschränkung

**Sicherheitsdetails**

| Feld | Wert |
|-------|-------|
| Snyk ID | [SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551](https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551) |
| GitHub Advisory | [GHSA-2m67-wjpj-xhg9](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-2m67-wjpj-xhg9) |
| Beschreibung | Zuweisung von Ressourcen ohne Grenzen oder Drosselung |
| Offengelegt | 2026-04-04 |
| CVSS v4.0-Score | **8.7 HOCH** |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — Zuweisung von Ressourcen ohne Grenzen oder Drosselung |
| Betroffene Versionen | [2.8.0, 2.21.2) |
| Upstream-Fix | jackson-core 2.18.7, 2.21.2 oder höher |
| Fix-Commits | [74c9ee25](https://github.com/FasterXML/jackson-core/commit/74c9ee25) (3.x), [7ce3622f](https://github.com/FasterXML/jackson-core/commit/7ce3622f) (2.18.x) |

**Grundursache:** Selbst wenn `StreamReadConstraints.maxDocumentLength` konfiguriert ist, erzwingen Versionen vor
2.18.7 / 2.21.2 das Dokumentlängenlimit in keinem Parser-Pfad. Die blockierenden Parser
(`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) validieren niemals die kumulativ gelesenen Bytes gegen das
konfigurierte Limit. Der asynchrone Parser (`NonBlockingJsonParser`) besitzt in `feedInput()` ebenfalls keine Validierung.
Der `UTF8DataInputJsonParser` hat keinen Mechanismus, um die insgesamt verbrauchten Bytes zu verfolgen.

In jackson-core 2.13.5 gab es `maxDocumentLength` überhaupt nicht, was bedeutet, dass es keine Möglichkeit gab, die Dokumentgröße zu begrenzen. Diese Behebung führt das Feld `maxDocumentLength` in `StreamReadConstraints` ein und setzt es in allen Parser-Pfaden durch.

**Verwundbare Parser-Pfade:**

| Parser | Pfad | Durchsetzungspunkt |
|--------|------|-------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | Validiert `_currInputProcessed + count` nach jedem Puffer-Nachladen und bei EOF |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | Gleiches Muster wie `UTF8StreamJsonParser` |
| `NonBlockingJsonParser` | `feedInput()` | Validiert `_currInputProcessed + _origBufferLen` nach jedem Eingabeblock |
| `UTF8DataInputJsonParser` | `DataInput` | Fail-fast: wirft `StreamConstraintsException`, falls `maxDocumentLength` konfiguriert ist |

**Angriffsszenario:** Ein Angreifer sendet ein gültiges, aber übermäßig großes JSON-Dokument (z. B. eine tief verschachtelte
oder stark repetitive Struktur über Gigabytes) an einen Dienst, der `maxDocumentLength` konfiguriert hat, um
Ressourcenerschöpfung zu verhindern. Ohne Durchsetzung verarbeitet der Parser das gesamte Dokument ungeachtet des
konfigurierten Limits und verbraucht unbegrenzten Speicher und CPU.

---

## Sicherheitsauswirkung

Alle vier Schwachstellen sind remote ausnutzbar, ohne dass eine Authentifizierung erforderlich ist:

- Jeder Dienst, der angreiferkontrolliertes JSON über einen `JsonParser` parst (direkt oder über
  Jackson Databind, das `jackson-core` kapselt), ist gefährdet.
- Der Angriff ist trivial konstruierbar — wenige hundert Byte JSON genügen, um unbegrenzten
  Ressourcenverbrauch auszulösen.
- Es gibt keine Auswirkungen auf Vertraulichkeit oder Integrität; Verfügbarkeit (DoS) ist die einzige Auswirkungsklasse.

---

## Details zur Behebung

### Offizielles Upgrade (Empfohlen)

Führen Sie ein Upgrade auf **jackson-core 2.15.4** oder eine beliebige spätere stabile Version durch. Alle 2.15.x- und 2.16+ Versionen enthalten die `StreamReadConstraints`-API mit sicheren Standardwerten.```xml
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

Validierungsmethoden (von Parsern bei jedem neuen Token aufgerufen):```java
void validateNestingDepth(int depth) throws StreamConstraintsException;
void validateIntegerLength(int length) throws StreamConstraintsException;
void validateFPLength(int length) throws StreamConstraintsException;
void validateStringLength(int length) throws StreamConstraintsException;
void validateBigIntegerScale(int scale) throws StreamConstraintsException;

Neue Hilfsmethoden `_createChildArrayContext()` und `_createChildObjectContext()` kapseln die Kontexterstellung mit einer Tiefenprüfung:```java
protected JsonReadContext _createChildArrayContext(int line, int col) throws IOException {
    _streamReadConstraints.validateNestingDepth(_parsingContext.getNestingDepth() + 1);
    return _parsingContext.createChildArrayContext(line, col);
}

#### `json/JsonReadContext.java`

Die Signaturen von `createChildArrayContext()` und `createChildObjectContext()` wurden aktualisiert, um
`throws IOException` weiterzugeben.

#### `json/async/NonBlockingJsonParser.java` (nur Sonatype-2022-6438)

Dies ist der wesentliche zusätzliche Fix, der über den Umfang des Upstream-PR #827 hinaus entdeckt wurde. Sechs
Stellen zum Abschluss von Zahlen, die `ParserBase.resetInt()` umgingen, wurden einzeln behoben:

| Methode | Hinzugefügte Validierung |
|--------|------------------|
| `_startPositiveNumber()` — Fast-Path-Rückgabe | `validateIntegerLength(_intLength)` |
| `_startNegativeNumber()` — Fast-Path-Rückgabe | `validateIntegerLength(_intLength)` |
| `_finishNumberIntegralPart()` — endgültige Rückgabe | `validateIntegerLength(_intLength)` |
| `_finishToken()` Fall `MINOR_NUMBER_INTEGER_DIGITS` | `validateIntegerLength(_intLength)` |
| `_startFloat()` / `_finishFloatFraction()` / `_finishFloatExponent()` endgültige Rückgaben | `validateFPLength(_intLength + _fractLength + _expLength)` |
| `_finishToken()` Fälle `MINOR_NUMBER_FRACTION_DIGITS` / `MINOR_NUMBER_EXPONENT_DIGITS` | `validateFPLength(...)` |

Alle Stellen sind erreichbar: Die Fast-Path-Methoden behandeln den Fall, dass die vollständige Zahl in
einem einzigen `feedInput()`-Aufruf verfügbar ist; die `MINOR_*`-Resume-State-Fälle behandeln den Chunk-Fall,
bei dem Zahlziffern über mehrere Aufrufe eintreffen. Beide Pfade müssen abgesichert werden.

---

## Testabdeckung

### CVE-2025-52999 — Tests zur Verschachtelungstiefe

| Testdatei | Testmethode | Parser-Modi | Abdeckung |
|-----------|-------------|-------------|--------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | stream | Rekursive Traversierung, die reale App-Nutzung simuliert; bestätigt `StreamConstraintsException` bei Tiefe 1001 (behoben) und `StackOverflowError` bei Tiefe 20.000 (2.13.5) |
| `read/ArrayParsingTest.java` | `testCustomNestingDepthConstraint` | direkte API | `StreamReadConstraints.builder().maxNestingDepth(5)` — Accessor, am Limit bestanden, über Limit wirft Exception |
| `read/ArrayParsingTest.java` | `testObjectNestingDepthLimit` | stream | Objekte genau am Limit 1000 (bestanden), Objekte mit 1001 Ebenen werfen Exception |
| `read/ArrayParsingTest.java` | `testDataInputParserDepthLimit` | `UTF8DataInputJsonParser` | `UTF8DataInputJsonParser` erzwingt das 1001-Ebenen-Tiefenlimit |
| `read/ArrayParsingTest.java` | `testNonBlockingParserDepthLimit` | non-blocking | `NonBlockingJsonParser` erzwingt das 1001-Ebenen-Tiefenlimit |

### Sonatype-2022-6438 — Tests zur Zahlenlänge

| Testdatei | Testmethode | Parser-Modi | Abdeckung |
|-----------|-------------|-------------|--------|
| `read/NumberOverflowTest.java` | `testSonatype_2022_6438` | `ALL_MODES` | Ganzzahl am Limit (bestanden), Ganzzahl über Limit (fehlgeschlagen), Gleitkommazahl am Limit (bestanden), Gleitkommazahl über Limit (fehlgeschlagen), Exponent in wissenschaftlicher Notation am Limit (bestanden), Exponent über Limit (fehlgeschlagen) — alle vier Parser |
| `read/NumberOverflowTest.java` | `testNonBlockingParserNumericLengthLimit` | non-blocking | `NonBlockingJsonParser` erzwingt die Zahlenlänge |
| `read/NumberOverflowTest.java` | `testNonBlockingParserExponentLengthLimit` | non-blocking | `NonBlockingJsonParser` erzwingt die Länge des Exponenten in wissenschaftlicher Notation über `validateFPLength` |
| `read/NumberOverflowTest.java` | `testCustomMaxNumberLengthConstraint` | direkte API | `StreamReadConstraints.builder().maxNumberLength(5)` — Accessor, am Limit bestanden, über Limit wirft Exception für `validateIntegerLength()` und `validateFPLength()`, Format der Fehlermeldung |

> **Legende der Parser-Modi:**
> - `ALL_STREAMING_MODES` = `UTF8StreamJsonParser` (stream), `UTF8StreamJsonParser` (gedrosselt), `ReaderBasedJsonParser`
> - `ALL_MODES` = die obigen drei + `UTF8DataInputJsonParser`
> - `non-blocking` = `NonBlockingJsonParser` über `ByteArrayFeeder`
> - `stream` = `UTF8StreamJsonParser` (Standard `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — Tests zur Dokumentlänge

| Testdatei | Testmethode | Parser-Modi | Abdeckung |
|-----------|-------------|-------------|--------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | InputStream-Parser erzwingt `maxDocumentLength` — 20K-Dokument mit 10K-Limit abgelehnt |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | InputStream-Parser akzeptiert Dokument innerhalb des Limits |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | Reader-Parser erzwingt `maxDocumentLength` — 20K-Dokument mit 10K-Limit abgelehnt |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | Reader-Parser akzeptiert Dokument innerhalb des Limits |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | Async-Parser erzwingt `maxDocumentLength` — 20K-Dokument in `feedInput()` abgelehnt |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | Async-Parser akzeptiert Dokument innerhalb des Limits |
| `constraints/LargeDocReadTest.java` | `testDataInputWithDocLengthLimitFails` | `UTF8DataInputJsonParser` | DataInput-Parser schlägt schnell fehl, wenn `maxDocumentLength` konfiguriert ist |
| `constraints/LargeDocReadTest.java` | `testDataInputWithoutDocLengthLimitWorks` | `UTF8DataInputJsonParser` | DataInput-Parser funktioniert normal ohne konfiguriertes `maxDocumentLength` |
| `constraints/LargeDocReadTest.java` | `testDefaultFactoryNoLimit` | `UTF8StreamJsonParser` | Standard-Factory (ohne Limit) akzeptiert große Dokumente |

---

## Ergebnisse der vollständigen Testsuite```
Tests run: 957, Failures: 0, Errors: 0, Skipped: 0

---

## Validierungsergebnisse

### Regressionstest gegen jackson-core 2.13.5

Die CVE-Testmethoden wurden so entworfen, dass sie auf der 2.13.5-Codebasis **fehlschlagen** und im behobenen Build **bestehen**.

**`NumberOverflowTest#testSonatype_2022_6438`** gegen 2.13.5:```
FAIL — Sonatype-2022-6438 VULNERABILITY PRESENT: parser returned VALUE_NUMBER_INT
       for a 1001-digit integer — number length limit is not enforced

**Beide Tests am behobenen Build: PASS.**

---

## Proof of Concept

### CVE-2025-52999 — Verschachtelungstiefe DoS```java
// Build a 1001-level nested array document (just over the limit)
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1001; i++) sb.append('[');
for (int i = 0; i < 1001; i++) sb.append(']');

JsonFactory factory = new JsonFactory();
JsonParser parser = factory.createParser(sb.toString());
try {
    while (parser.nextToken() != null) { }       // ← throws on 1001st '['
    System.err.println("VULNERABLE: no exception thrown");
} catch (StreamConstraintsException e) {
    System.out.println("REMEDIATED: " + e.getMessage());
    // Depth (1001) exceeds the maximum allowed nesting depth (1000)
} finally {
    parser.close();
}

---

## Migrationsanleitung

### Option 1: Upgrade auf jackson-core 2.15.4+ (Empfohlen)```xml
<!-- Maven -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

<!-- Or with Jackson BOM -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.fasterxml.jackson</groupId>
            <artifactId>jackson-bom</artifactId>
            <version>2.15.4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

### Option 2: Diese Sicherheitsbehebung anwenden```bash
git clone https://github.com/sassoftware/jackson-core.git
cd jackson-core
git checkout 2.13.5-CVE-2025-52999-sonatype-2022-6438-GHSA-2m67-wjpj-xhg9
./mvnw install -DskipTests

---

## Lizenz

Lizenziert unter der [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0).```
Copyright 2024–2025 The Jackson Authors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.