Cowtowncoder

ProtobufParser. readStringKey() reads the length prefix of a protobuf map entry's string key into an attacker-controlled int and then checks ( inputPtr + len) <= inputEnd using signed arithmetic. For values near Integer.MAX VALUE the addition overflows to a negative value and the check passes even when the input contains no key data. The parser then calls finishShortText(len), which expands the text buffer to the declared length via TextBuffer.expandCurrentSegment and Arrays.copyOf, throwing OutOfMemoryError: Requested array size exceeds VM limit. An 8-byte malformed message containing a map entry with a declared key length of 0x7FFFFFFF is sufficient. Configured StreamReadConstraints, including maxStringLength, maxNameLength, maxDocumentLength and maxNestingDepth, do not prevent the failure. Applications running with -XX:+ExitOnOutOfMemoryError terminate the JVM. This is the same integer-overflow pattern addressed for other call sites in the remediation associated with CVE-2026-104016 and CVE-2026-104017; the map-key call site was corrected on the 3.x branches only, leaving the corresponding 2.x branches unguarded. Release lines 2.18, 2.19 and 2.20 do not contain readStringKey() and are not affected by this vector. No privileges or user interaction beyond the ability to submit data for parsing are required. The 3.0 release line and 3.1.0-3.1.5 / 3.2.0-3.2.1 do not contain readStringKey() and are therefore not affected; the method first appears in 3.1.6 and 3.2.2, mirroring its introduction at 2.21.6 on the 2.x side.

يقوم محلل Smile غير المتزامن `NonBlockingByteArrayParser` بتخصيص مصفوفة بايتات بناءً على بادئة طول ثنائية خام مأخوذة من مدخلات غير موثوقة دون وجود حد أقصى أو فحص للتجاوز. وتحديداً، عند مواجهة العلامة الثنائية الخام 0xFD، تقوم الدالة ` decodeVInt()` بحساب الطول دون وجود حماية التجاوز المستخدمة في الدالة `SmileParser. readUnsignedVInt` المتزامنة. بعد ذلك، تقوم ` startRawBinary` بتخصيص الطول المعلن عنه فوراً. يمكن أن يؤدي ذلك إلى جعل مدخلات صغيرة تتسبب في تخصيص كمية هائلة من الذاكرة، مما يؤدي إلى حدوث `OutOfMemoryError` في نقاط نهاية Smile التفاعلية أو غير المتزامنة. بالإضافة إلى ذلك، فإن VInt (عدد صحيح متغير) مصمم لتجاوز العدد الصحيح يؤدي إلى طول سالب، مما يتسبب في `NegativeArraySizeException`. كلا السيناريوهين قد يؤديان إلى تعطل الطلب أو خيط المعالجة.

يحدث تجاوز في عدد صحيح (integer overflow) في `ProtobufParser` عند تحليل حقول النصوص والبايتات في protobuf المسبوقة بطول. يستخدم المحلل حسابات الأعداد الصحيحة الموقعة 32 بت للتحقق مما إذا كان `( inputPtr + len) <= inputEnd`. إذا قدم المهاجم قيمة varint يتم فك تشفيرها إلى طول قريب من `Integer.MAX VALUE` ، فإن عملية الجمع تتجاوز إلى قيمة سالبة، مما يسمح بتجاوز فحص الحدود. لاحقاً، تقوم الدالة ` finishShortText(len)` باستدعاء `TextBuffer.expandCurrentSegment(len)` ، والتي تؤدي إلى تشغيل `Arrays.copyOf` وتتسبب في حدوث `OutOfMemoryError` لأن حجم المصفوفة المطلوب يتجاوز حد JVM. يستمر هذا الخلل بغض النظر عن ضبط `-Xmx` أو إعدادات `StreamReadConstraints.maxStringLength` و `maxDocumentLength`. لا يتطلب الأمر أي صلاحيات أو تفاعل من المستخدم سوى القدرة على إرسال بيانات للتحليل.

تفشل أدوات التحليل المبنية على إدخال الأحرف، مثل مصادر Reader أو String أو char[] التي يتم تقديمها بواسطة ReaderBasedJsonParser، في تطبيق قيد `maxNameLength` بشكل صحيح أثناء تجميع أسماء خصائص كائنات JSON. بدلاً من الحد المقصود البالغ 50,000 حرف، يستخدم النظام فحص `maxStringLength` الذي يسمح بما يصل إلى 100,000,000 حرف. يحدث هذا لأن الدالة ` parseName2()` تقوم بتجميع الاسم في TextBuffer وتتحقق فقط من `maxStringLength` عندما يمتلئ الجزء، مما يؤخر فحص `validateNameLength(int)` حتى يتم تخزين الاسم بالكامل في الذاكرة المؤقتة. يمكن للمهاجم عن بُعد استغلال ذلك من خلال تقديم اسم خاصية طويل بما يكفي، مما يجبر النظام على تخصيص ذاكرة بنحو 200 ميجابايت لكل طلب، وهو ما قد يؤدي إلى استنفاد الذاكرة (heap) وتعطل العملية. هذه الثغرة قابلة للاستغلال في الإعدادات الافتراضية لأن `maxDocumentLength` معطل افتراضياً. أدوات تحليل إدخال البايت غير متأثرة.

توجد مشكلة حيث يقوم البرنامج بالتحقق من الفئة الخارجية لمعرف نوع اسم الفئة ولكنه يفشل في التحقق بشكل صحيح من الفئات الموجودة داخل وسيطاتها العامة. يحدث هذا لأن الدالة `DatabindContext. resolveAndValidateGeneric()` تتحقق من الفئة الخارجية مقابل النوع الأساسي المعلن، ولكنها تمرر الوسائط إلى ` validateTypeParameter()`، والتي تتحقق منها مقابل النوع الأساسي الخارجي بدلاً من الربط العام المعلن الخاص بها. نتيجة لذلك، يمكن قبول فئات غير ذات صلة داخل نوع فرعي عام أو داخل معرفات نوع مصفوفة بسيطة بمجرد الموافقة على النوع الأساسي. يمكن استغلال ذلك من خلال تعدد الأشكال لاسم الفئة القائم على التعليقات التوضيحية أو التحديد النوعي الافتراضي المهيأ. على سبيل المثال، إذا تم الإعلان عن خاصية كـ `Map<String,String>`، يمكن للمهاجم تقديم `HashMap<FileSystemXmlApplicationContext,String>`. إذا كان Spring موجودًا في classpath، فقد يؤدي ذلك إلى تنفيذ أوامر عشوائية عبر `ProcessBuilder.start()` من خلال تحميل ملف XML يتحكم فيه المهاجم.

يفشل محلل JSON غير المعطل (غير المتزامن) في jackson-core في فرض قيد `maxNumberLength` المحدد في `StreamReadConstraints`. يحدث هذا لأن مسار التحليل غير المتزامن في `NonBlockingUtf8JsonParserBase` والفئات ذات الصلة لا يستدعي طرق التحقق من صحة طول الأرقام. وعلى وجه التحديد، تقوم طرق مثل ` finishNumberIntegralPart()` بتجميع الأرقام في `TextBuffer` دون إجراء أي فحوصات، كما تفشل ` valueComplete()` في استدعاء `resetInt()` أو `resetFloat()`، حيث يتم تنفيذ `validateIntegerLength()` و`validateFPLength()`. يمكن للمهاجم إرسال مستند JSON يحتوي على رمز رقمي بطول تعسفي، مما يؤدي إلى تخصيص مفرط للذاكرة في `TextBuffer` واحتمال حدوث خطأ `OutOfMemoryError`. بالإضافة إلى ذلك، إذا استدعت التطبيق `getBigIntegerValue()` أو `getDecimalValue()`، فقد تتعرض JVM لاستنفاد موارد وحدة المعالجة المركزية (CPU) بسبب تحليل BigInteger بدرجة تعقيد O(n^2)، مما يؤدي إلى رفض الخدمة.

يوجد ثغرة تسمح بتجاوز قيود طول الأرقام في المحلل غير المعطل. يمكن للمهاجم إرسال بيانات JSON على شكل أجزاء صغيرة دون إرسال بايت إنهاء، مما يبقي المحلل في حالة `MINOR NUMBER INTEGER DIGITS` إلى أجل غير مسمى. يؤدي هذا إلى زيادة حجم المجمع (accumulator) استنادًا إلى `maxStringLength` (القيمة الافتراضية 20 ميغابايت) بدلاً من `maxNumberLength` (القيمة الافتراضية 1000)، مما قد يؤدي إلى استهلاك ما يصل إلى 40 ميغابايت من الذاكرة المؤقتة (heap) لكل اتصال. ويمكن أن يؤدي ذلك إلى استنفاد ذاكرة الكومة في JVM عند اقترانه بالتزامن الذي يتحكم فيه المهاجم. تؤثر هذه المشكلة على مسارات الأرقام الصحيحة في فئة `NonBlockingUtf8JsonParserBase`، وتحديدًا داخل الدوال ` startPositiveNumber()` و` startNegativeNumber()` و` finishNumberIntegralPart()`. تعتبر أطر العمل التفاعلية التي تزود المحلل غير المتزامن بالبايتات فور وصولها، مثل Spring WebFlux/Reactor وQuarkus وHelidon وVert.x، معرضة بشكل خاص لهذه المشكلة. أما المحللات المتزامنة والمحللات غير المتزامنة التي تعمل على مدخلات كاملة، فهي غير متأثرة.

The issue is related to resource exhaustion due to a lack of a check in primitive value deserializers to avoid deep wrapper array nesting when the UNWRAP SINGLE VALUE ARRAYS feature is enabled. This can allow an unauthenticated attacker to expose assets in the environment susceptible to exploitation, with no impact to confidentiality, no impact to integrity, and high impact to availability, requiring no user interaction.

The issue is related to the allocation of unlimited memory in the com.fasterxml.jackson.dataformat:jackson-dataformat-cbor package of the jackson-dataformats-binary library. This can be exploited by a remote attacker to cause a denial of service. The unchecked allocation of a byte buffer can cause a java.lang.OutOfMemoryError exception.

The issue allows remote attackers to conduct server-side request forgery (SSRF) attacks via vectors related to a DTD. This can be exploited in the XmlMapper component of the Jackson XML dataformat.