Pjfanning

An issue exists when binding a JSON string to a `javax.xml.datatype.Duration` or `javax.xml.datatype.XMLGregorianCalendar` field via the `CoreXMLDeserializers.Std. deserialize` function. The software passes the raw string directly to `DatatypeFactory.newDuration(value)` or `newXMLGregorianCalendar(value)`. Because the XML Schema lexical grammar allows numeric components of arbitrary length, the JDK uses `BigInteger(String)` and `BigDecimal(String)` constructors, which have quadratic complexity relative to the digit count. Since the input is treated as a JSON string rather than a JSON number, the `StreamReadConstraints.maxNumberLength` guard is bypassed, and the XML datatype deserializer fails to perform length validation. An unauthenticated attacker can send a request containing a string with several million digits, causing excessive CPU consumption and potentially saturating server worker threads.

The deserializer for java.nio.file.Path resolves an attacker-supplied URI without restricting the URI scheme. In the `JDKFromStringDeserializer.NioPathHelper.deserialize` function, a string from untrusted JSON is passed to `new URI(value)` and then to `Path.of(uri)`. If a `FileSystemNotFoundException` occurs, the code enumerates `ServiceLoader<FileSystemProvider>` and calls `provider.getPath(uri)` on the first provider matching the attacker-chosen scheme. This allows untrusted JSON to select and drive an arbitrary registered `FileSystemProvider` during `readValue` under a default `JsonMapper`, forcing provider class loading. While the resolved path is inert with only JDK built-in providers (file, jar/zipfs), further impact is possible if a side-effecting third-party `FileSystemProvider` is present on the classpath.

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

اسم البرنامج المعرض للخطر والإصدارات المتأثرة: إصدارات jackson-core الأقدم من 2.15.0 الوصف: تحدث المشكلة عند معالجة ملفات الإدخال التي تحتوي على بيانات متداخلة بعمق، مما قد يتسبب في حدوث خطأ StackoverflowError بسبب العمق المفرط. تم إدخال حد قابل للتكوين لعمق التصفح، بقيمة افتراضية تبلغ 1000، لمنع حدوث هذا الخطأ. في حالة بلوغ هذا الحد، يتم إصدار استثناء StreamConstraintsException. يجب على المستخدمين تجنب معالجة ملفات الإدخال من مصادر غير موثوقة كحل مؤقت. التوصيات: بالنسبة للإصدارات الأقدم من 2.15.0، قم بالتحديث إلى الإصدار 2.15.0 أو أحدث لتضمين الحد القابل للتكوين لعمق التداخل ومنع حدوث خطأ «StackoverflowError». كحل مؤقت، يُنصح بتجنب معالجة ملفات الإدخال المتداخلة بعمق من مصادر غير موثوقة حتى يتم تطبيق التحديث.

The web-based admin console in H2 Database Engine can be started via the CLI with the argument `-webAdminPassword`, which allows the user to specify the password in cleartext for the web admin console. Consequently, a local user (or an attacker that has obtained local access through some means) would be able to discover the password by listing processes and their arguments. The issue was fixed in version 2.2.220.

The issue concerns the XML parser used in the Excel-Streaming-Reader, which did not apply all necessary settings to prevent XML Entity Expansion issues. This problem is resolved by upgrading to version 2.1.0. There is no known workaround for this issue.