All four `JsonParser` implementations share this flaw. The attack is equally exploitable through
any of them — whether input arrives via `InputStream`, `Reader`, `DataInput`, or the async
non-blocking feeder API.

**공격 벡터:**

| # | 전략 | 예시 페이로드 | 깊이 증가 | 영향받는 파서 |
|---|----------|----------------|-----------------|------------------|
| 1 | 배열 중첩 | `[[[…]]]` — 1,001개의 연속된 `[` 토큰 | `[`마다 +1 | 4개 모두 |
| 2 | 객체 중첩 | `{"k":{"k":{…}}}` — 1,001개의 연속된 `{` 토큰 | `{`마다 +1 | 4개 모두 |
| 3 | 교차 중첩 | `[{"k":[{"k":…}]}]` — 1,001개의 혼합 `[`/`{` 토큰 | `[` 또는 `{`마다 +1 | 4개 모두 |

주요 관찰 사항:

- **배열 중첩 — 최소 오버헤드:** `[` 및 `]` 토큰만 필요합니다. 키, 값 또는 공백이 필요 없습니다. 1,001개의 대괄호 쌍으로 구성된 2,002바이트 페이로드만으로도 기본 제한 1,000을 초과하기에 충분합니다.
- **객체 중첩 — 증폭된 힙 압력:** 각 `{`는 깊이 체인 노드 위에 `JsonReadContext` 키 슬롯을 추가로 할당하여, 극단적인 깊이에서 메모리 소비를 가중시킵니다.
- **교차 중첩 — 웹 애플리케이션 방화벽(WAF) 우회:** 반복되는 `[[[` 또는 `{{{` 시퀀스를 탐지하는 패턴 매칭 방어는 교차 토큰 중첩을 인식하지 못합니다. 파서의 깊이 카운터는 토큰 유형과 관계없이 동일하게 증가합니다.
- **비차단 피더 — 동일한 페이로드, 다른 전달 표면:** 세 가지 중첩 전략 모두 `NonBlockingJsonParser` 및 `ByteArrayFeeder` API를 통해 동일하게 악용할 수 있습니다. 문서는 임의로 작은 청크로 전달될 수 있습니다. `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()`는 바이트가 도착하는 방식과 관계없이 모든 컨텍스트 시작 토큰에서 깊이 카운터를 증가시키므로, 여러 `feedInput()` 호출에 걸쳐 깊이가 누적됩니다.

세 가지 중첩 전략 모두 네 가지 `JsonParser` 구현 중 어느 것을 통해서도 도달할 수 있습니다. 2.13.5에서는 파싱이 조용히 성공합니다. 이 수정 사항이 적용되면 세 가지 벡터 모두 `StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)` 예외를 던집니다.

---

### Sonatype-2022-6438 — 무제한 숫자 토큰 길이

**보안 세부 정보**

| 필드 | 값 |
|-------|-------|
| Sonatype ID | [sonatype-2022-6438](https://guide.sonatype.com/vulnerability/sonatype-2022-6438/security-details) |
| 설명 | jackson-core — 서비스 거부(DoS) |
| 게시일 | 2022-12-07 |
| 출처 | Sonatype |
| CVSS v3.1 점수 | **7.5 높음** — `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) — 제한 또는 조절 없는 리소스 할당 |
| EPSS 점수 | 0% |
| 업스트림 수정 PR | [jackson-core#827](https://github.com/FasterXML/jackson-core/pull/827), [jackson-core#846](https://github.com/FasterXML/jackson-core/pull/846) |

**취약한 메서드(Sonatype 식별)**

| 메서드 | 참고 |
|--------|-------|
| `com.fasterxml.jackson.core.base.ParserBase._parseSlowInt(I)V` | 취약 매개변수: 인덱스 0 |
| `com.fasterxml.jackson.core.base.ParserBase.convertNumberToBigDecimal()V` | |
| `com.fasterxml.jackson.core.base.ParserMinimalBase.getValueAsDouble(D)D` | 취약 매개변수: 인덱스 0 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDecimal()` | `BigDecimal` 반환 |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsDouble(Z)D` | |
| `com.fasterxml.jackson.core.util.TextBuffer.contentsAsFloat(Z)F` | |

이 메서드들은 각각 원시 숫자 버퍼를 처리할 때 먼저 길이를 검증하지 않습니다. 충분히 긴 숫자 토큰을 전달하면 JVM이 제약 없는 버퍼 내용에서 `BigInteger` 또는 `BigDecimal`을 인스턴스화하려고 시도하면서 무제한 힙 할당과 CPU 고갈이 발생합니다.

---

**근본 원인:** 2.15.0 이전에는 `JsonParser`가 정수, 과학적 표기법, 단순 부동 소수점 또는 복합 부동 소수점 토큰의 바이트 길이에 제한을 두지 않았습니다. 파서가 숫자를 축적하기 위해 내부 `_textBuffer`를 할당할 때, 공격자는 수백만 자리의 숫자를 제공하여 버퍼가 무한정 커지게 하고 결국 힙 메모리를 고갈시킬 수 있습니다.

**취약한 코드 경로:**

구조적으로 구별되는 두 가지 취약 경로가 있습니다. 하나는 세 개의 동기 파서가 공유하는 경로이고, 다른 하나는 비동기 파서를 통한 독립적인 두 번째 경로입니다.

**경로 A — 동기 파서**(세 가지 구현, 하나의 공유 싱크):```
JsonParser.nextToken()                         // common entry point
  │
  ├─ ReaderBasedJsonParser   ─┐
  ├─ UTF8StreamJsonParser     ├─→ ParserBase.resetInt() / resetFloat()
  └─ UTF8DataInputJsonParser ─┘         │
                                        ▼
                               _textBuffer.contentsAsString()
                               ⚠  no length check — buffer grows without bound

비차단(비동기) 파서는 특히 주목할 만한 공격 표면입니다. `_startPositiveNumber`, `_startNegativeNumber`,
`_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`에
자체적인 숫자 누적 루프가 있으며, `ParserBase.resetInt()` 또는 `resetFloat()`를 거치지 않고
`_intLength` / `_fractLength` / `_expLength`를 직접 설정합니다. 이는 업스트림 PR #827 수정(`ParserBase`에만
검증 추가)이 **`NonBlockingJsonParser`를 완전히 무방비 상태로 남겼음**을 의미합니다.
이 문제는 확장된 공격 표면 분석 중에 발견되었으며 이 브랜치에서 수정되었습니다.

**공격 벡터:**

| # | 토큰 형태 | 예시 페이로드 | `intLen` | `fractLen` | `expLen` | 합계 | 제약 조건 |
|---|------------|----------------|----------|------------|----------|-------|------------|
| 1 | 정수 | `999…` — 연속 숫자 199,999개 | 199,999 | 0 | 0 | 199,999 | `validateIntegerLength` |
| 2 | 소수 | `0.999…` — 1자리 정수, 1,001자리 소수 부분 | 1 | 1,001 | 0 | 1,002 | `validateFPLength` |
| 3 | 과학적 표기법 | `1e999…` — 1자리 가수, 1,001자리 지수 | 1 | 0 | 1,001 | 1,002 | `validateFPLength` |
| 4 | 복합 부동소수점 | `0.999…e999…` — 500자리 소수 부분, 500자리 지수 | 1 | 500 | 500 | 1,001 | `validateFPLength` |

주요 관찰 사항:

- **정수 — 부호 문자는 숫자가 아님:** 앞의 `-`는 숫자 누적에서 제외됩니다. `-999…`와 `999…`는 동일한 `intLen` 값을 생성하며 동일한 임계값에서 제약 조건을 트리거합니다.
- **소수 — 짧은 정수, 무제한 소수 부분:** 정수 부분은 한 자리(0)일 수 있는 반면 소수 부분은 제한 없이 커질 수 있습니다. 소수점 자체는 개수에서 제외됩니다.
- **과학적 표기법 — 작지만 파괴적:** 약 1,004바이트로 가장 작은 유효 페이로드입니다. 토큰 크기가 작음에도 불구하고 스케일 ±10^1001인 `BigDecimal` 인스턴스화를 강제하여 무제한 중간 힙 할당을 요구합니다.
- **복합 부동소수점 — 분할 한계 회피:** `fractLen = 500` 및 `expLen = 500`일 때 각 구성 요소는 개별적으로 1,000자리 임계값에 도달하지 않습니다. 통합 검사 `validateFPLength(intLen + fractLen + expLen)`이 이 공백을 메우는 유일한 방어책입니다.
- **비차단 파서 — 독립적 우회:** 위의 네 가지 토큰 형태 모두 `ByteArrayFeeder`를 통한 `NonBlockingJsonParser`를 통해 독립적으로 악용될 수 있습니다. 동기식 파서와 달리 `NonBlockingJsonParser`는 `_intLength` / `_fractLength` / `_expLength`를 직접 기록하는 비공개 루프(`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`)에서 숫자를 누적하므로 `ParserBase.resetInt()` 및 `resetFloat()`를 완전히 우회합니다. 따라서 `ParserBase`만 수정한 업스트림 PR #827은 이 파서를 완전히 무방비 상태로 남겼으며, 이번 수정에서 6개의 독립적인 호출 지점 패치가 필요했습니다.

네 가지 토큰 형태와 비차단 우회는 토큰화 시점에 거부됩니다. `BigDecimal` 또는 `BigInteger`
가 생성되기 전에, 동기식 파서에서는 `ParserBase`의 `validateIntegerLength`와 `validateFPLength`에 의해,
비동기 파서에서는 `NonBlockingJsonParser`의 6개 전용 호출 지점에서 거부됩니다. 2.13.5에서는
네 가지 토큰 형태가 모두 조용히 수락됩니다. 이번 수정을 적용하면 모든 파서가
`StreamConstraintsException: Number length (N) exceeds the maximum length (1000)`을 던집니다.

> **대용량 페이로드에서의 `UTF8DataInputJsonParser` 참고 사항:** DataInput 파서에는
> 기존 내부 버퍼 제한이 65 536바이트입니다 ([jackson-core#493](https://github.com/FasterXML/jackson-core/issues/493)).
> 이 크기를 초과하는 문서(예: 199,999자리 PoC 페이로드 ≈ 200KB)는 길이 제약 조건이 발동하기 전에
> `ArrayIndexOutOfBoundsException`을 트리거합니다. 따라서 `UTF8DataInputJsonParser`에 대한 숫자 길이
> 보호는 버그가 여전히 재현되는 더 짧은 페이로드(≤ 1,001자리)로 검증됩니다.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — 문서 길이 제약 우회

**보안 세부 정보**

| 필드 | 값 |
|-------|-------|
| Snyk ID | [SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551](https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551) |
| GitHub 권고 | [GHSA-2m67-wjpj-xhg9](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-2m67-wjpj-xhg9) |
| 설명 | 무제한 또는 조절 없는 리소스 할당 |
| 공개일 | 2026-04-04 |
| CVSS v4.0 점수 | **8.7 높음** |
| CWE | [CWE-770](https://cwe.mitre.org/data/definitions/770.html) — 무제한 또는 조절 없는 리소스 할당 |
| 영향받는 버전 | [2.8.0, 2.21.2) |
| 업스트림 수정 | jackson-core 2.18.7, 2.21.2 이상 |
| 수정 커밋 | [74c9ee25](https://github.com/FasterXML/jackson-core/commit/74c9ee25) (3.x), [7ce3622f](https://github.com/FasterXML/jackson-core/commit/7ce3622f) (2.18.x) |

**근본 원인:** `StreamReadConstraints.maxDocumentLength`가 구성된 경우에도 2.18.7 / 2.21.2
이전 버전은 어떤 파서 경로에서도 문서 길이 제한을 적용하지 않습니다. 차단 파서
(`UTF8StreamJsonParser`, `ReaderBasedJsonParser`)는 구성된 제한에 대해 누적 읽기 바이트를
검증하지 않습니다. 비동기 파서(`NonBlockingJsonParser`)도 `feedInput()`에 검증이 없습니다.
`UTF8DataInputJsonParser`에는 총 소비 바이트를 추적할 메커니즘이 없습니다.

jackson-core 2.13.5에는 `maxDocumentLength`가 전혀 존재하지 않아 문서 크기를 제한할 방법이
없었습니다. 이번 수정은 `StreamReadConstraints`에 `maxDocumentLength` 필드를 도입하고
모든 파서 경로에서 이를 적용합니다.

**취약한 파서 경로:**

| 파서 | 경로 | 적용 지점 |
|--------|------|-------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | 버퍼를 다시 채울 때마다 및 EOF에서 `_currInputProcessed + count` 검증 |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | `UTF8StreamJsonParser`와 동일한 패턴 |
| `NonBlockingJsonParser` | `feedInput()` | 각 입력 청크 후 `_currInputProcessed + _origBufferLen` 검증 |
| `UTF8DataInputJsonParser` | `DataInput` | 빠른 실패: `maxDocumentLength`가 구성된 경우 `StreamConstraintsException` 발생 |

**공격 시나리오:** 공격자는 리소스 고갈을 방지하기 위해 `maxDocumentLength`를 구성한 서비스에
유효하지만 지나치게 큰 JSON 문서(예: 수 기가바이트에 달하는 깊게 중첩되거나 매우 반복적인 구조)를
전송합니다. 적용이 없으면 파서는 구성된 제한과 관계없이 전체 문서를 처리하여 무제한의 메모리와
CPU를 소비합니다.

---

## 보안 영향

네 가지 취약점 모두 인증 없이 원격으로 악용 가능합니다:

- 공격자가 제어하는 JSON을 `JsonParser`를 통해(직접 또는 `jackson-core`를 래핑하는 Jackson Databind를 통해) 구문 분석하는 모든 서비스가 위험합니다.
- 공격은 사소하게 구성 가능합니다 — 수백 바이트의 JSON만으로도 무제한 리소스 소비를 트리거할 수 있습니다.
- 기밀성 또는 무결성 영향은 없으며, 가용성(DoS)만이 유일한 영향 클래스입니다.

---

## 수정 세부 정보

### 공식 업그레이드 (권장)

**jackson-core 2.15.4** 이상의 안정 버전으로 업그레이드하세요. 모든 2.15.x 및 2.16+ 릴리스에는
안전한 기본값을 가진 `StreamReadConstraints` API가 포함됩니다.```xml
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.15.4</version>
</dependency>

검증 메서드 (각 새 토큰에 대해 파서가 호출함):```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;

새로운 헬퍼 메서드 `_createChildArrayContext()` 및 `_createChildObjectContext()`는 깊이 검사로 컨텍스트 생성을 래핑합니다:```java
protected JsonReadContext _createChildArrayContext(int line, int col) throws IOException {
    _streamReadConstraints.validateNestingDepth(_parsingContext.getNestingDepth() + 1);
    return _parsingContext.createChildArrayContext(line, col);
}

#### `json/JsonReadContext.java`

`createChildArrayContext()` 및 `createChildObjectContext()` 시그니처가 `throws IOException`을 전파하도록 업데이트되었습니다.

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

업스트림 PR #827 범위를 넘어 발견된 주요 추가 수정 사항입니다. `ParserBase.resetInt()`를 우회하는 6개의 숫자 완성 지점이 개별적으로 수정되었습니다:

| 메서드 | 추가된 검증 |
|--------|------------------|
| `_startPositiveNumber()` — 빠른 경로 반환 | `validateIntegerLength(_intLength)` |
| `_startNegativeNumber()` — 빠른 경로 반환 | `validateIntegerLength(_intLength)` |
| `_finishNumberIntegralPart()` — 최종 반환 | `validateIntegerLength(_intLength)` |
| `_finishToken()` 케이스 `MINOR_NUMBER_INTEGER_DIGITS` | `validateIntegerLength(_intLength)` |
| `_startFloat()` / `_finishFloatFraction()` / `_finishFloatExponent()` 최종 반환 | `validateFPLength(_intLength + _fractLength + _expLength)` |
| `_finishToken()` 케이스 `MINOR_NUMBER_FRACTION_DIGITS` / `MINOR_NUMBER_EXPONENT_DIGITS` | `validateFPLength(...)` |

모든 지점에 도달할 수 있습니다. 빠른 경로 메서드는 전체 숫자가 단일 `feedInput()` 호출로 제공되는 경우를 처리하고, `MINOR_*` 재개 상태 케이스는 숫자 자릿수가 여러 호출에 걸쳐 도착하는 분할된 경우를 처리합니다. 두 경로 모두 보호되어야 합니다.

---

## 테스트 커버리지

### CVE-2025-52999 — 중첩 깊이 테스트

| 테스트 파일 | 테스트 메서드 | 파서 모드 | 설명 |
|-----------|-------------|-------------|--------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | stream | 실제 앱 사용을 시뮬레이션하는 재귀 순회; 깊이 1001에서 `StreamConstraintsException`(수정됨) 및 깊이 20,000에서 `StackOverflowError`(2.13.5)를 확인 |
| `read/ArrayParsingTest.java` | `testCustomNestingDepthConstraint` | direct API | `StreamReadConstraints.builder().maxNestingDepth(5)` — 접근자, 한도 도달 시 통과, 한도 초과 시 예외 발생 |
| `read/ArrayParsingTest.java` | `testObjectNestingDepthLimit` | stream | 정확히 한도 1000인 객체(통과), 1001 레벨 객체는 예외 발생 |
| `read/ArrayParsingTest.java` | `testDataInputParserDepthLimit` | `UTF8DataInputJsonParser` | `UTF8DataInputJsonParser`가 1001 레벨 깊이 한도를 적용 |
| `read/ArrayParsingTest.java` | `testNonBlockingParserDepthLimit` | non-blocking | `NonBlockingJsonParser`가 1001 레벨 깊이 한도를 적용 |

### Sonatype-2022-6438 — 숫자 길이 테스트

| 테스트 파일 | 테스트 메서드 | 파서 모드 | 설명 |
|-----------|-------------|-------------|--------|
| `read/NumberOverflowTest.java` | `testSonatype_2022_6438` | `ALL_MODES` | 한도에 도달한 정수(통과), 한도 초과 정수(실패), 한도에 도달한 부동소수점(통과), 한도 초과 부동소수점(실패), 한도에 도달한 과학적 표기법 지수(통과), 한도 초과 지수(실패) — 네 가지 파서 모두 |
| `read/NumberOverflowTest.java` | `testNonBlockingParserNumericLengthLimit` | non-blocking | `NonBlockingJsonParser`가 숫자 길이를 적용 |
| `read/NumberOverflowTest.java` | `testNonBlockingParserExponentLengthLimit` | non-blocking | `NonBlockingJsonParser`가 `validateFPLength`를 통해 과학적 표기법 지수 길이를 적용 |
| `read/NumberOverflowTest.java` | `testCustomMaxNumberLengthConstraint` | direct API | `StreamReadConstraints.builder().maxNumberLength(5)` — 접근자, 한도 도달 시 통과, 한도 초과 시 `validateIntegerLength()` 및 `validateFPLength()` 모두에서 예외 발생, 오류 메시지 형식 |

> **파서 모드 키:**
> - `ALL_STREAMING_MODES` = `UTF8StreamJsonParser` (stream), `UTF8StreamJsonParser` (throttled), `ReaderBasedJsonParser`
> - `ALL_MODES` = 위 3개 + `UTF8DataInputJsonParser`
> - `non-blocking` = `ByteArrayFeeder`를 통한 `NonBlockingJsonParser`
> - `stream` = `UTF8StreamJsonParser` (기본 `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — 문서 길이 테스트

| 테스트 파일 | 테스트 메서드 | 파서 모드 | 설명 |
|-----------|-------------|-------------|--------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | InputStream 파서가 `maxDocumentLength`를 적용 — 10K 한도에서 20K 문서가 거부됨 |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | InputStream 파서가 한도 내 문서를 허용 |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | Reader 파서가 `maxDocumentLength`를 적용 — 10K 한도에서 20K 문서가 거부됨 |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | Reader 파서가 한도 내 문서를 허용 |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | Async 파서가 `maxDocumentLength`를 적용 — 20K 문서가 `feedInput()`에서 거부됨 |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | Async 파서가 한도 내 문서를 허용 |
| `constraints/LargeDocReadTest.java` | `testDataInputWithDocLengthLimitFails` | `UTF8DataInputJsonParser` | DataInput 파서는 `maxDocumentLength`가 구성되면 빠르게 실패 |
| `constraints/LargeDocReadTest.java` | `testDataInputWithoutDocLengthLimitWorks` | `UTF8DataInputJsonParser` | DataInput 파서는 `maxDocumentLength` 구성 없이 정상 작동 |
| `constraints/LargeDocReadTest.java` | `testDefaultFactoryNoLimit` | `UTF8StreamJsonParser` | 기본 팩토리(제한 없음)는 대용량 문서를 허용 |

---

## 전체 테스트 스위트 결과```
Tests run: 957, Failures: 0, Errors: 0, Skipped: 0

---

## 검증 결과

### jackson-core 2.13.5에 대한 회귀 테스트

CVE 테스트 메서드는 2.13.5 코드베이스에서 **실패**하고
수정된 빌드에서 **통과**하도록 설계되었습니다.

**`NumberOverflowTest#testSonatype_2022_6438`** (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

**수정된 빌드에 대한 두 테스트 모두: PASS.**

---

## 개념 증명

### CVE-2025-52999 — 중첩 깊이 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();
}

---

## 마이그레이션 가이드

### 옵션 1: jackson-core 2.15.4+로 업그레이드 (권장)```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>

### 옵션 2: 이 보안 수정 사항 적용```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

## 라이선스

[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.