جميع تطبيقات `JsonParser` الأربعة تشترك في هذا العيب. ويمكن استغلال الهجوم بالتساوي عبر أيٍّ منها — سواء وصل الإدخال عبر `InputStream` أو `Reader` أو `DataInput` أو واجهة برمجة التطبيقات غير المتزامنة للتغذية غير الحاجبة (non-blocking feeder API).

**نواقل الهجوم:**

| # | الاستراتيجية | حمولة مثال | زيادة العمق | المحللات المتأثرة |
|---|----------|----------------|-----------------|------------------|
| 1 | تداخل المصفوفات | `[[[…]]]` — 1,001 رمز `[` متتالية | +1 لكل `[` | جميع الأربعة |
| 2 | تداخل الكائنات | `{"k":{"k":{…}}}` — 1,001 رمز `{` متتالية | +1 لكل `{` | جميع الأربعة |
| 3 | التداخل المتناوب | `[{"k":[{"k":…}]}]` — 1,001 رمز مختلط `[`/`{` | +1 لكل `[` أو `{` | جميع الأربعة |

ملاحظات رئيسية:

- **تداخل المصفوفات — حمل إضافي ضئيل:** لا يتطلب سوى رمزي `[` و`]`؛ لا مفاتيح ولا قيم ولا مسافات بيضاء. حمولة من 2,002 بايت مكوّنة من 1,001 زوج أقواس كافية لتجاوز الحد الافتراضي البالغ 1,000.
- **تداخل الكائنات — ضغط مضاعف على الكومة (heap):** كل `{` يخصص بالإضافة إلى ذلك فتحة مفتاح لـ`JsonReadContext` فوق عقدة سلسلة العمق، مما يضاعف استهلاك الذاكرة في الأعماق القصوى.
- **التداخل المتناوب — مراوغة جدار حماية تطبيقات الويب (WAF):** الدفاعات القائمة على مطابقة الأنماط التي تكتشف تكرار تسلسلات `[[[` أو `{{{` لا تكتشف التداخل المتناوب للرموز؛ عداد عمق المحلل يزداد بشكل مماثل بغض النظر عن نوع الرمز.
- **المغذي غير الحاجب — نفس الحمولة، سطح توصيل مختلف:** جميع استراتيجيات التداخل الثلاث قابلة للاستغلال بالتساوي عبر `NonBlockingJsonParser` وواجهة برمجة التطبيقات `ByteArrayFeeder`. يمكن تسليم الوثيقة في أجزاء صغيرة بشكل تعسفي؛ تقوم `NonBlockingJsonParserBase._startArrayScope()` / `_startObjectScope()` بزيادة عداد العمق عند كل رمز يفتح سياقًا بغض النظر عن كيفية وصول البايتات، مما يراكم العمق عبر استدعاءات `feedInput()` المتعددة.

جميع استراتيجيات التداخل الثلاث قابلة للوصول من خلال أيٍّ من تطبيقات `JsonParser` الأربعة. مع الإصدار 2.13.5، ينجح التحليل بصمت؛ مع هذا الإصلاح، ترمي المتجهات الثلاثة `StreamConstraintsException: Depth (1001) exceeds the maximum allowed nesting depth (1000)`.

---

### Sonatype-2022-6438 — طول الرمز الرقمي غير المحدود

**تفاصيل الأمان**

| الحقل | القيمة |
|-------|-------|
| معرّف Sonatype | [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% |
| طلبات سحب الإصلاح من المنبع | [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` | |

تعالج كل من هذه الطرق مخزن الأرقام الخام دون التحقق أولاً من طوله. تمرير رمز رقمي طويل بما يكفي يؤدي إلى تخصيص غير محدود في الكومة واستنزاف وحدة المعالجة المركزية (CPU) عندما يحاول JVM إنشاء مثيل لـ`BigInteger` أو `BigDecimal` من محتويات المخزن غير المقيدة.

---

**السبب الجذري:** قبل الإصدار 2.15.0، لم يفرض `JsonParser` أي حد على طول البايتات لرموز الأعداد الصحيحة، والتدوين العلمي، وأعداد الفاصلة العائمة البسيطة، وأعداد الفاصلة العائمة المركبة. عندما يخصص المحلل مخزنه الداخلي `_textBuffer` لتجميع الأرقام، يمكن للمهاجم توفير رقم بملايين الأرقام، مما يؤدي إلى نمو المخزن دون حدود وفي النهاية استنفاد ذاكرة الكومة.

**مسارات التعليمات البرمجية المعرضة للخطر:**

يوجد مساران معرضان للخطر ومتميزان بنيويًا — أحدهما مشترك بين المحللات المتزامنة الثلاثة، والثاني مسار مستقل عبر المحلل غير المتزامن.

**المسار أ — المحللات المتزامنة** (ثلاثة تطبيقات، مصبّ مشترك واحد):```
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`
التي تضبط `_intLength` / `_fractLength` / `_expLength` مباشرة دون المرور أبدًا عبر
`ParserBase.resetInt()` أو `resetFloat()`. هذا يعني أن إصلاح PR #827 من المنبع (الذي أضاف
التحقق إلى `ParserBase` فقط) **ترك `NonBlockingJsonParser` غير محمي تمامًا**.
تم اكتشاف ذلك أثناء تحليل موسع لسطح الهجوم وتمت معالجته في هذا الفرع.

**نواقل الهجوم:**

| # | شكل التوكن | مثال على الحمولة | `intLen` | `fractLen` | `expLen` | الإجمالي | القيد |
|---|------------|----------------|----------|------------|----------|-------|------------|
| 1 | عدد صحيح | `999…` — 199,999 رقمًا متتاليًا | 199,999 | 0 | 0 | 199,999 | `validateIntegerLength` |
| 2 | كسر عشري | `0.999…` — عدد صحيح من رقم واحد، وجزء كسري من 1,001 رقم | 1 | 1,001 | 0 | 1,002 | `validateFPLength` |
| 3 | تدوين علمي | `1e999…` — معامل من رقم واحد، وأس من 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 بايت، هذه هي أصغر حمولة فعالة؛ فهي تُجبر على إنشاء كائن `BigDecimal` بمقياس ±10^1001، مما يتطلب تخصيصًا غير محدود لذاكرة الكومة الوسيطة رغم صغر حجم التوكن.
- **النقطة العائمة المركبة — تفادي حد التقسيم:** مع `fractLen = 500` و`expLen = 500`، لا يصل أي مكوّن بمفرده إلى عتبة 1,000 رقم. الفحص الموحد `validateFPLength(intLen + fractLen + expLen)` هو الدفاع الوحيد الذي يسد هذه الفجوة.
- **المحلل غير الحاجب — تجاوز مستقل:** جميع أشكال التوكن الأربعة أعلاه قابلة للاستغلال بشكل مستقل عبر `NonBlockingJsonParser` من خلال `ByteArrayFeeder`. على عكس المحللات المتزامنة، يقوم `NonBlockingJsonParser` بتراكم الأرقام في حلقات خاصة (`_startPositiveNumber`, `_finishNumberIntegralPart`, `_startFloat`, `_finishFloatFraction`, `_finishFloatExponent`) تكتب `_intLength` / `_fractLength` / `_expLength` مباشرة، متجاوزًا `ParserBase.resetInt()` و`resetFloat()` تمامًا. لذلك، فإن PR #827 من المنبع — الذي عدّل `ParserBase` فقط — ترك هذا المحلل غير محمي تمامًا، مما استلزم ستة تصحيحات مستقلة في مواقع الاستدعاء في هذا الإصلاح.

يتم رفض جميع أشكال التوكن الأربعة والتجاوز غير الحاجب في وقت الترميز — قبل إنشاء أي `BigDecimal` أو `BigInteger`
— بواسطة `validateIntegerLength` و`validateFPLength` في `ParserBase` (المحللات المتزامنة)
وفي ستة مواقع استدعاء مخصصة في `NonBlockingJsonParser` (المحلل غير المتزامن). مع 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)).
> المستندات التي تتجاوز هذا الحجم (مثل حمولات PoC المكونة من 199,999 رقمًا ≈ 200 كيلوبايت) تؤدي إلى
> `ArrayIndexOutOfBoundsException` قبل أن يتمكن قيد الطول من العمل. لذلك يتم التحقق من حماية طول الأرقام
> لمحلل `UTF8DataInputJsonParser` بحمولات أقصر
> (≤ 1,001 رقماً) حيث لا يزال الخطأ قابلاً للتكرار.

---

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 / GHSA-2m67-wjpj-xhg9 — تجاوز قيد طول المستند

**تفاصيل الأمان**

| الحقل | القيمة |
|-------|-------|
| معرف Snyk | [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` موجودًا على الإطلاق، مما يعني عدم وجود أي وسيلة
لتقييد حجم المستند. يقدم هذا الإصلاح الحقل `maxDocumentLength` في
`StreamReadConstraints` ويفرضه عبر جميع مسارات المحلل.

**مسارات المحلل القابلة للاستغلال:**

| المحلل | المسار | نقطة التنفيذ |
|--------|------|-------------------|
| `UTF8StreamJsonParser` | `InputStream` → `_loadMore()` | يتحقق من `_currInputProcessed + count` بعد كل إعادة تعبئة للذاكرة المؤقتة وعند EOF |
| `ReaderBasedJsonParser` | `Reader` → `_loadMore()` | النمط نفسه المتبع في `UTF8StreamJsonParser` |
| `NonBlockingJsonParser` | `feedInput()` | يتحقق من `_currInputProcessed + _origBufferLen` بعد كل جزء إدخال |
| `UTF8DataInputJsonParser` | `DataInput` | فشل سريع: يرمي `StreamConstraintsException` إذا تم ضبط `maxDocumentLength` |

**سيناريو الهجوم:** يرسل مهاجم مستند JSON صالحًا لكنه ضخم (مثل بنية متداخلة بعمق
أو شديدة التكرار تمتد لعدة غيغابايت) إلى خدمة ضبطت
`maxDocumentLength` لمنع استنزاف الموارد. بدون تنفيذ القيد، يعالج المحلل
المستند بأكمله بغض النظر عن الحد المضبوط، مستهلكًا ذاكرة وCPU غير محدودة.

---

## الأثر الأمني

جميع الثغرات الأربع قابلة للاستغلال عن بُعد دون الحاجة إلى أي مصادقة:

- أي خدمة تعالج JSON يتحكم فيه المهاجم عبر `JsonParser` (مباشرة أو من خلال
  Jackson Databind، الذي يغلّف `jackson-core`) معرضة للخطر.
- الهجوم سهل البناء للغاية — بضع مئات من البايتات من JSON كافية لإحداث
  استهلاك غير محدود للموارد.
- لا يوجد أي أثر على السرية أو النزاهة؛ الإتاحة (DoS) هي فئة الأثر الوحيدة.

---

## تفاصيل الإصلاح

### الترقية الرسمية (موصى بها)

قم بالترقية إلى **jackson-core 2.15.4** أو أي إصدار ثابت لاحق. جميع إصدارات 2.15.x و2.16+
تتضمن واجهة برمجة التطبيقات `StreamReadConstraints` بقيم افتراضية آمنة.```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 upstream. تمت معالجة ستة مواقع لإكمال الأرقام كانت تتجاوز `ParserBase.resetInt()` بشكل فردي:

| Method | التحقق المضاف |
|--------|------------------|
| `_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 — اختبارات عمق التداخل

| Test File | Test Method | Parser modes | يغطي |
|-----------|-------------|-------------|--------|
| `read/ArrayParsingTest.java` | `testCVE_2025_52999` | stream | اجتياز تكراري يحاكي استخدام التطبيق الفعلي؛ يؤكد `StreamConstraintsException` عند العمق 1001 (تمت المعالجة) و `StackOverflowError` عند العمق 20,000 (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 — اختبارات طول الأرقام

| Test File | Test Method | Parser modes | يغطي |
|-----------|-------------|-------------|--------|
| `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` (محدود السرعة)، `ReaderBasedJsonParser`
> - `ALL_MODES` = الأوضاع الثلاثة أعلاه + `UTF8DataInputJsonParser`
> - `non-blocking` = `NonBlockingJsonParser` عبر `ByteArrayFeeder`
> - `stream` = `UTF8StreamJsonParser` (الافتراضي في `JsonFactory.createParser`)

### SNYK-JAVA-COMFASTERXMLJACKSONCORE-15907551 — اختبارات طول المستند

| Test File | Test Method | Parser modes | يغطي |
|-----------|-------------|-------------|--------|
| `constraints/LargeDocReadTest.java` | `testInputStreamExceedsLimit` | `UTF8StreamJsonParser` | محلل InputStream يفرض `maxDocumentLength` — مستند 20K مرفوض بحد 10K |
| `constraints/LargeDocReadTest.java` | `testInputStreamUnderLimitSucceeds` | `UTF8StreamJsonParser` | محلل InputStream يقبل مستندًا ضمن الحد |
| `constraints/LargeDocReadTest.java` | `testReaderExceedsLimit` | `ReaderBasedJsonParser` | محلل Reader يفرض `maxDocumentLength` — مستند 20K مرفوض بحد 10K |
| `constraints/LargeDocReadTest.java` | `testReaderUnderLimitSucceeds` | `ReaderBasedJsonParser` | محلل Reader يقبل مستندًا ضمن الحد |
| `constraints/LargeDocReadTest.java` | `testAsyncExceedsLimit` | `NonBlockingJsonParser` | المحلل غير المتزامن يفرض `maxDocumentLength` — مستند 20K مرفوض في `feedInput()` |
| `constraints/LargeDocReadTest.java` | `testAsyncUnderLimitSucceeds` | `NonBlockingJsonParser` | المحلل غير المتزامن يقبل مستندًا ضمن الحد |
| `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 — حجب الخدمة بعمق التداخل```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

---

## الترخيص

مرخّص بموجب [رخصة أباتشي، الإصدار 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.