Andrea Leopardi

**Name of the Vulnerable Software and Affected Versions** elixir-protobuf versions 0.8.0 through 0.17.0 **Description** An unauthenticated remote attacker can cause a crash of the decoding process by providing a deeply nested JSON document. This occurs when an application decodes attacker-supplied JSON into a schema containing a self-referential or cyclic message type using the functions `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from decoded/3`. In `lib/protobuf/json/decode.ex`, the `embedded-message` clause of the `decode singular/3` function recurses into `internal from json data/3` for each nesting level without incrementing or verifying the decoder's depth counter. While the `increase depth and maybe throw/1` guard exists, it only applies to `Google.Protobuf.ListValue` and `Google.Protobuf.Struct` clauses, rendering the `recursion limit` option ineffective for user-defined message types. Consequently, each nesting level allocates a stack frame and heap objects, allowing a sufficiently deep document to exhaust the memory of the decoding process and crash it. If the BEAM `max heap size` process flag is set to unlimited, concurrent requests may exhaust the memory of the entire node. **Recommendations** Update elixir-protobuf to version 0.17.1. As a temporary workaround, reject JSON documents whose nesting depth exceeds a fixed bound at the web or middleware layer before they are passed to the `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from decoded/3` functions.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.10.x **Description** A resource allocation issue allows a malicious HTTP/2 server to force a client to buffer up to approximately 16 MiB per connection in frames that should be rejected, leading to excessive client memory consumption. This occurs because the function `decode next/2` in `lib/mint/http2/frame.ex` only validates the frame against the `max frame size` variable after the entire declared payload has been received. Until the payload is complete, the system returns `:more`, causing `Mint.HTTP2` to store all received bytes in the connection buffer. A server can declare a frame length up to 16,777,215 bytes and withhold the final byte to maintain this buffer for as long as the connection remains open. This can lead to memory exhaustion for clients maintaining numerous connections to untrusted origins, such as proxies, crawlers, or webhook senders. **Recommendations** Update elixir-mint to version 1.11.0 or later. As a temporary workaround, connect to untrusted origins using HTTP/1 only by setting `protocols: [:http1]` in the `Mint.HTTP.connect/4` function to avoid the HTTP/2 frame decoder.

**Name of the Vulnerable Software and Affected Versions** mint versions 1.1.0 through 1.10.x **Description** A malicious HTTP/2 server can cause a denial of service by exhausting memory on the client host. The issue occurs because `Mint.HTTP2` only enforces the `max header list size` setting on the compressed size of an inbound header block, rather than the decoded header list as required by RFC 9113. An attacker can use HPACK indexed fields to create a small compressed block that expands into a very large decoded list. Specifically, the `join cookie headers/1` function in `lib/mint/http2.ex` copies every `cookie` value of a response into a single new binary, which can lead to the allocation of approximately 1 GB for a single response under default settings. This memory exhaustion can crash the process owning the connection or the entire BEAM virtual machine. **Recommendations** Update to version 1.11.0 or later. As a temporary mitigation, lower the `max header list size` value within `client settings` in the `Mint.HTTP.connect/4` function to a small value (e.g., 4,096) to bound the response size. Restrict connections to untrusted servers to HTTP/1 by setting `protocols: [:http1]` to avoid the HTTP/2 receive path. Avoid setting `max header list size` to `:infinity`.

**Name of the Vulnerable Software and Affected Versions** mint versions 0.1.0 through 1.10.0 **Description** An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection. This can lead to response-queue poisoning, where bytes from one response are attributed to subsequent requests sharing the same connection. The issue occurs because the `chunk size/1` function in `Mint.HTTP1.Parse` stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Subsequently, the `decode body/5` function in `Mint.HTTP1` discards all bytes up to the CRLF using `Parse.ignore until crlf/1`. This results in the acceptance of hex digits followed by arbitrary bytes, whereas RFC 9112 only permits chunk extensions introduced by a `;`. Consequently, an RFC-strict intermediary may reject a line that Mint accepts, causing a disagreement on chunk boundaries and the end of the response body. **Recommendations** Update mint to version 1.10.1 or later.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 1.9.3 through 1.9.x **Description** An inefficient algorithmic complexity issue allows a remote HTTP server to exhaust CPU resources on the client host, leading to a denial of service. The `parse hex prefix/2` function in `lib/mint/http1/parse.ex` processes hex digits of a chunked response's chunk-size field using an arbitrary-precision accumulator without limiting the digit count. This results in O(N squared) time complexity for processing N digits. Additionally, the `handle data/2` function prepends the `conn.buffer` and re-parses from the beginning for every socket message, which can be exploited by a server sending digits in small packets to repeatedly trigger the high CPU cost. This state is reached after a valid status line and header section, potentially bypassing intermediaries that only inspect headers. **Recommendations** Update to version 1.10.0.

**Name of the Vulnerable Software and Affected Versions** elixir-mint versions 0.1.0 through 1.9.9 **Description** A remote HTTP server can cause a denial of service by exhausting memory on the client host. This occurs because two HTTP/1 response-parser states accumulate server data without limits. Specifically, the `decode status line/4` function stores unconsumed data in `conn.buffer` when the status line is incomplete, and the `decode body/5` function does the same for an unterminated chunk-extension line. Both functions wait for a CRLF (Carriage Return Line Feed) sequence that a malicious server may never send, causing `conn.buffer` to be prepended to every subsequent socket message. While a budget exists via `:max header list size`, it only applies to `decode headers/5` and `decode trailer headers/4`, leaving these two states unprotected. An attacker can stream bytes indefinitely until the BEAM node is terminated by the operating system's out-of-memory handler. In the case of chunk-extensions, the attack occurs after a valid status line and header section, potentially bypassing intermediaries that only inspect headers. **Recommendations** Update elixir-mint to version 1.10.0 or later.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات elixir-mint من 0.1.0 إلى 1.9.2 **الوصف** توجد مشكلة تهريب استجابات HTTP بسبب التفسير غير المتسق لطلبات HTTP. يمكن لخادم HTTP/1 ضار أن يخل بالتزامن بين وسيط صارم وعميل Mint على اتصال مجمَّع، مما يؤدي إلى تسميم قائمة انتظار الاستجابات للطلبات اللاحقة التي تشترك في ذلك الاتصال. تستخدم الدالة `decode body()` الموجودة في `lib/mint/http1.ex` الدالة `Integer.parse(data, 16)` لتحليل سطر حجم القطعة (chunk-size) في استجابة Transfer-Encoding: chunked. في حين أن RFC 7230 يحظر استخدام بادئات الإشارة لحجم القطعة، فإن `Integer.parse/2` تقبل علامات + أو - في بداية السطر. ونتيجةً لذلك، يُعامل سطر حجم القطعة الذي يحتوي على +5 على أنه قطعة مكونة من خمسة بايتات، ويُعامل +0 أو -0 على أنهما قطعتان منتهيتان بطول صفر، مما يؤدي إلى إنهاء نص الرسالة قبل الأوان. ويرفض الوسيط الذي يلتزم بصرامة بمعايير RFC هذه الأشكال، مما يتسبب في خلاف حول حدود الاستجابة. في حالة اتصالات keep-alive المجمعة، يمكن لمصدر متأثر بالمهاجم حقن بايتات ينسبها العميل إلى الاستجابة الشرعية التالية، مما يؤدي إلى إتلاف الاستجابات لطلبات قيد التنفيذ غير ذات صلة. يتطلب هذا وجود بنية شبكية يتم فيها وضع وسيط HTTP/1 يلتزم بصرامة بمعايير RFC (مثل وكيل أو موزع تحميل أو جدار حماية الويب WAF) بين عميل Mint والمصدر، ويتم إعادة استخدام الاتصالات. **التوصيات** تحديث elixir-mint إلى الإصدار 1.9.3 أو أحدث.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات elixir-mint من 0.1.0 إلى 1.9.1 **الوصف** يمكن لخادم HTTP بعيد أن يتسبب في رفض الخدمة عن طريق استنفاد الذاكرة على مضيف العميل. تقوم الدالتان `Mint.HTTP1.decode headers/5` و`Mint.HTTP1.decode trailer headers/4` بتجميع رؤوس الاستجابة التي تم تحليلها وحقول الملحق المقسمة إلى أجزاء في قائمة لكل طلب `request.headers buffer` التي تستمر عبر شرائح TCP. ونظرًا لعدم وجود حد أقصى لعدد الرؤوس أو إجمالي البايتات، واستخدام محلل `:erlang.decode packet(:httph bin, binary, [])` بحدود حجم افتراضية غير محدودة، يمكن لخادم ضار بث أسطر الرؤوس أو الملاحق إلى ما لا نهاية دون إرسال السطر الفارغ الختامي. يؤدي هذا إلى تزايد حجم حالة الاتصال بلا حدود حتى يتم إنهاء عقدة BEAM بواسطة معالج نفاد الذاكرة في نظام التشغيل. **التوصيات** تحديث elixir-mint إلى الإصدار 1.9.2 أو أحدث.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات elixir-mint من 0.1.0 إلى 1.9.1 **الوصف** يمكن لخادم HTTP/2 عن بُعد أن يتسبب في استنفاد الذاكرة وحالة رفض الخدمة على مضيف العميل. تقوم الدالة `handle continuation/3` الموجودة في `lib/mint/http2.ex` بتجميع أجزاء كتل الرؤوس من إطارات CONTINUATION في HTTP/2 في بنية متداخلة لا يتم تحريرها إلا عند استلام إطار يحمل علامة END HEADERS. وعلى الرغم من وجود فحص لحد الحجم عبر `assert header block within max size/2`، فإن البروتوكول يسمح لإطارات CONTINUATION بأن تحتوي على حمولات بطول صفر. يمكن للمهاجم إرسال سلسلة غير محدودة من هذه الإطارات ذات الطول صفر، مما يتجاوز الحد الأقصى للحجم ويزيد باستمرار من استهلاك الذاكرة عن طريق إضافة خلية cons واحدة لكل إطار، مما يؤدي في النهاية إلى إنهاء عمل عقدة BEAM بسبب نفاد الذاكرة. **التوصيات** تحديث elixir-mint إلى الإصدار 1.9.2 أو أحدث.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Mint من 0.5.0 إلى 1.9.0 **الوصف** توجد مشكلة تتعلق برفض الخدمة في الوحدة النمطية `Mint.HTTP1`. عند فك تشفير نص استجابة HTTP المقسمة إلى أجزاء، يقوم البرنامج بتجميع أجزاء جزئية في `data buffer` (قائمة iolist غير محدودة) باستخدام الدالة `add body to buffer/2` ولا يرسل البيانات حتى يتم استلام طول الجزء المعلن بالكامل. ونظرًا لأن حجم الجزء يتم تحليله من الخادم دون حد أقصى، يمكن لخادم ضار تحديد حجم جزء ضخم وإرسال البايتات ببطء. وهذا يجبر العميل على تخزين البيانات مؤقتًا إلى أجل غير مسمى، مما قد يؤدي إلى حالة نفاد الذاكرة. ويمكن أن يحدث هذا عندما يتبع العميل عمليات إعادة التوجيه، أو يسترد عناوين URL التي يقدمها المستخدم، أو يعالج webhooks. وترتبط هذه المشكلة بالدالة `decode body/5` الموجودة في الملف `lib/mint/http1.ex`. **التوصيات** تحديث mint إلى الإصدار 1.9.1 أو أحدث.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات hpax من 0.1.1 إلى 1.0.3 **الوصف** توجد مشكلة تتعلق بعدم كفاءة التعقيد الخوارزمي أثناء فك تشفير الأعداد الصحيحة ذات الطول المتغير في HPACK. لا تفرض الدالة `Elixir.HPAX.Types`:decode remaining integer/3، التي يتم الوصول إليها عبر نقطة الدخول `Elixir.HPAX`:decode/2، حدًا أعلى على القيمة التي تم فك تشفيرها أو على عدد بايتات الاستمرار. ونظرًا لأن الأعداد الصحيحة في BEAM تستخدم دقة عشوائية، فإن تسلسل بايتات الاستمرار ينتج عددًا كبيرًا (bignum) من O(N) بت، مما يؤدي إلى تكلفة فك تشفير فائقة الخطية تبلغ تقريبًا O(N^2). يمكن لمهاجم غير مصدق استغلال هذه الثغرة عن طريق إرسال كتلة رأس HTTP/2 صغيرة تستهلك قدرًا مفرطًا من وحدة المعالجة المركزية (CPU) والذاكرة المؤقتة، مما يؤدي إلى تضخيم هجوم رفض الخدمة. **التوصيات** تحديث hpax إلى الإصدار 1.0.4 أو أحدث.