Xclow3N

When `http.Transport` sends an HTTP/1 CONNECT request containing a non-empty `Request.Body`, the body is written directly to the connection without framing following the request headers. If the server responds to the CONNECT request with a non-2xx keep-alive response, the connection is returned to the idle pool. Since CONNECT requests are not expected to have a request body, the server may treat the remaining body bytes as a subsequent pipelined HTTP/1.1 request. This results in a desynchronized pooled connection, causing the next user of that connection to receive the response intended for the injected request. In reverse proxies, such as `httputil.ReverseProxy`, that utilize a shared `Transport`, this behavior can lead to cross-user response poisoning.

An unauthenticated remote attacker can cause a denial of service by sending a complete LDAP operation followed by the initial bytes of an incomplete LDAPMessage on the same connection. This sequence forces the server to assign the connection to a second worker thread before the first worker's result is flushed. The second worker then blocks until the `nsslapd-ioblocktimeout` is reached while holding the connection mutex, which prevents the delivery of the completed operation's result. By repeating this process across a small number of connections relative to the configured worker-thread pool size, an attacker can exhaust the entire pool under default configurations, denying service to all clients, including anonymous and authenticated users via plaintext and TLS.

A flaw exists where the server fails to discard plaintext bytes buffered from a client connection during StartTLS negotiation. This allows an on-path attacker to inject a crafted LDAP message that is processed after the TLS upgrade. Due to a messageID collision, the response to the injected message is delivered to the client instead of the response to the client's own pending operation. Consequently, a client application may incorrectly treat a failed authentication (bind) attempt as successful.

An unauthenticated HTTP/2 client can exploit the way the proxy forwards data for configured non-WebSocket HTTP upgrades before the upstream accepts them. By placing a complete HTTP/1.1 request within extended CONNECT data, the attacker can cause the proxy to downgrade the request and write the data unframed to a keep-alive HTTP/1.1 upstream. This results in a smuggled response remaining queued in the shared pool, which can then be received by a different downstream client. This issue does not affect WebSocket upgrades, plain CONNECT, disabled backend keep-alive, per-downstream pools, or configurations where `max requests per connection` is set to 1.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, occurs on serverless-plugin routes. This allows an attacker to manipulate the request stream so that other clients receive responses chosen by the attacker or responses intended for other users.

يمكن للمستخدمين المصادق عليهم تنفيذ هجوم تزوير الطلبات من جانب الخادم (SSRF) عن طريق إرسال عناوين URL مُعدَّلة خصيصًا. تحدث هذه المشكلة داخل الدالة `fetch url()` في فئة `ScenarioImport`، مما يسمح للمهاجمين بإجراء طلبات HTTP تعسفية. ويمكن استغلال ذلك لاستكشاف خدمات الشبكة الداخلية، وتعداد المنافذ من خلال توقيعات الأخطاء، والوصول إلى نقاط نهاية البيانات الوصفية السحابية لاسترداد بيانات الاعتماد الحساسة.

يحتوي البرنامج على مشكلتين تتعلقان بتزوير الطلبات من جانب الخادم (SSRF). SSRF هو عيب يتيح للمهاجم حث التطبيق من جانب الخادم على إرسال طلبات إلى موقع غير مقصود، مما قد يؤدي إلى الوصول إلى الموارد الداخلية أو تجاوز قيود الشبكة.

يقوم Netty بتحليل السلاسل الموضوعة بين علامتي اقتباس بشكل غير صحيح في قيم ملحق ترميز النقل المقسم (chunked transfer encoding) في HTTP/1.1، مما يتيح شن هجمات تهريب الطلبات. وعلى وجه التحديد، يوقف Netty تحليل رأس المقطع عند أحرف العودة/السطر الجديد داخل السلاسل الموضوعة بين علامتي اقتباس بدلاً من رفض الطلب باعتباره غير صحيح التكوين. وهذا يؤدي إلى اختلاف في التحليل بين Netty والمحللات المتوافقة مع RFC. والسبب الجذري هو أن Netty لا يتحقق من أن بايتات العودة/السطر الجديد محظورة داخل امتدادات المقطع قبل بايتات العودة/السطر الجديد الختامية. يجب رفض أي طلب يحتوي على بايتات العودة إلى السطر/تغذية السطر داخل قيمة امتداد المقطع رفضًا قاطعًا باعتباره غير صالح. يمكن أن تؤدي هذه المشكلة إلى تهريب الطلبات، وتسميم ذاكرة التخزين المؤقت، وتجاوز التحكم في الوصول، واختطاف الجلسة.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة إصدارات Apache Tomcat من 11.0.0-M1 إلى 11.0.18، ومن 10.1.0-M1 إلى 10.1.52، ومن 9.0.0.M1 إلى 9.0.115، ومن 8.5.0 إلى 8.5.100، ومن 7.0.0 إلى 7.0.109 الوصف يوجد تفسير غير متسق لطلبات HTTP («تهريب طلبات/استجابات HTTP») في Apache Tomcat بسبب امتداد جزء غير صالح. وقد يتيح ذلك للمهاجم تهريب الطلبات، مما يؤدي إلى سلوك غير متوقع أو انتهاكات أمنية. التوصيات الترقية إلى الإصدار 11.0.20 الترقية إلى الإصدار 10.1.52 الترقية إلى الإصدار 9.0.116

يقوم محلل HTTP/1.1 بمعالجة السلاسل الموضوعة بين علامتي اقتباس بشكل غير صحيح ضمن قيم امتداد ترميز النقل المقسم إلى أجزاء. وعلى وجه التحديد، يوقف المحلل تحليل رأس المقطع (chunk header) عندما يصادف تسلسل علامة إرجاع العربة وتغذية السطر (CRLF) داخل سلسلة محاطة بعلامات اقتباس، بدلاً من التعامل معها على أنها خطأ في التحليل. ويسمح هذا السلوك للمهاجم بحقن طلبات HTTP مزورة، مما قد يؤدي إلى تسميم ذاكرة التخزين المؤقت، وتجاوز ضوابط الوصول، واختطاف الجلسة.

تتعامل مكتبة go-mail بشكل غير صحيح مع قيم `mail.Address` عند تمريرها إلى أوامر `MAIL FROM` أو `RCPT TO` الخاصة بعميل SMTP. قد يؤدي ذلك إلى توجيه العناوين بشكل غير صحيح أو تهريب معلمات ESMTP. يتطلب الاستغلال الناجح أن يسمح كود المستخدم بإدخال عناوين بريد إلكتروني عشوائية. تنشأ المشكلة من استخدام القيمة الأولية لـ `Address` بدلاً من طريقة `String()`، التي تقوم بتطبيق الهروب والعلامات الاقتباسية بشكل صحيح على عناوين البريد الإلكتروني. وعلى وجه التحديد، قد يفسر خادم SMTP عنوان بريد إلكتروني مزيف مثل `”toni.tester@example.com> ORCPT=admin@admin.com“@example.com` بشكل خاطئ، مما قد يؤدي إلى توجيه رسائل البريد الإلكتروني إلى مستلمين غير مقصودين أو السماح بحقن أوامر SMTP إضافية.