Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The WebSocket client in src/hackney_ws.erl imposes no upper bound on memory consumption in three code paths. First, read_handshake_response/3 accumulates received bytes into a growing buffer with no size cap; the per-receive timeout resets on every chunk, so a server that streams bytes without ever sending \r\n\r\n causes the buffer to grow until memory is exhausted. Second, parse_payload/9 and parse_active_payload/8 do not validate the declared frame payload length against any limit; because RFC 6455 allows payload lengths up to 2^63-1 bytes, a server that announces a very large frame and dribbles bytes causes the accumulation buffer to grow until OOM. Third, the frag_buffer field in #ws_data{} accumulates continuation frames indefinitely; a server that sends an endless stream of non-final (nofin) fragmented frames without ever sending a final (fin) frame grows frag_buffer without bound.
In all three cases the attacker only needs to control the WebSocket server the hackney client connects to, with no authentication or special client configuration required.
This issue affects hackney: from 2.0.0 before 4.0.1.
CVE-2026-47073 is a critical resource exhaustion vulnerability in the Erlang-based hackney WebSocket client library affecting versions 2.0.0 through 4.0.0. The vulnerability allows remote attackers controlling a WebSocket server to trigger unbounded memory allocation through three distinct attack vectors: incomplete handshake responses, oversized frame declarations, and infinite frame fragmentation. This can lead to denial of service by exhausting server memory without requiring authentication. Organizations using hackney for WebSocket communications face immediate risk of service disruption.
IMMEDIATE ACTIONS:
1. Identify all systems running hackney versions 2.0.0-4.0.0 using dependency scanning tools (rebar3, mix, or package managers)
2. Isolate affected systems from untrusted WebSocket servers or implement network segmentation
3. Enable memory monitoring and alerting on affected services to detect exploitation attempts
4. Review WebSocket server logs for suspicious patterns: incomplete handshakes, oversized frame declarations, or fragmented frames without completion
PATCHING GUIDANCE:
1. Upgrade hackney to version 4.0.1 or later immediately
2. For Erlang/OTP projects: update rebar.config or mix.exs dependencies
3. Rebuild and redeploy applications with patched version
4. Test WebSocket functionality post-upgrade in staging environment
COMPENSATING CONTROLS (if immediate patching impossible):
1. Implement reverse proxy (nginx/HAProxy) with request size limits and timeout enforcement
2. Configure per-connection memory limits at OS level using cgroups or ulimit
3. Implement WebSocket frame size validation at application layer before hackney processing
4. Restrict WebSocket connections to trusted/authenticated servers only
5. Deploy connection-level rate limiting and timeout enforcement
DETECTION RULES:
1. Monitor for sustained memory growth on hackney processes without corresponding legitimate traffic
2. Alert on WebSocket connections with incomplete handshakes lasting >30 seconds
3. Flag frame declarations with payload_length > 100MB
4. Detect fragmented frames (nofin flag) without completion within 5-minute window
5. Monitor system OOM killer events correlated with WebSocket activity
الإجراءات الفورية:
1. تحديد جميع الأنظمة التي تقوم بتشغيل إصدارات hackney 2.0.0-4.0.0 باستخدام أدوات فحص التبعيات (rebar3 أو mix أو مديري الحزم)
2. عزل الأنظمة المتأثرة عن خوادم WebSocket غير الموثوقة أو تنفيذ تقسيم الشبكة
3. تفعيل مراقبة الذاكرة والتنبيهات على الخدمات المتأثرة للكشف عن محاولات الاستغلال
4. مراجعة سجلات خادم WebSocket للأنماط المريبة: المصافحات غير المكتملة أو إعلانات الإطارات الكبيرة أو الإطارات المجزأة بدون إكمال
إرشادات التصحيح:
1. ترقية hackney إلى الإصدار 4.0.1 أو أحدث على الفور
2. لمشاريع Erlang/OTP: تحديث تبعيات rebar.config أو mix.exs
3. إعادة بناء ونشر التطبيقات مع الإصدار المصحح
4. اختبار وظيفة WebSocket بعد الترقية في بيئة التدريج
الضوابط البديلة (إذا كان التصحيح الفوري مستحيلاً):
1. تنفيذ reverse proxy (nginx/HAProxy) مع حدود حجم الطلب وفرض المهلة الزمنية
2. تكوين حدود الذاكرة لكل اتصال على مستوى نظام التشغيل باستخدام cgroups أو ulimit
3. تنفيذ التحقق من حجم إطار WebSocket على مستوى التطبيق قبل معالجة hackney
4. تقييد اتصالات WebSocket بخوادم موثوقة/مصرح بها فقط
5. نشر تحديد معدل على مستوى الاتصال وفرض المهلة الزمنية
قواعد الكشف:
1. مراقبة نمو الذاكرة المستمر على عمليات hackney بدون حركة مرور شرعية مقابلة
2. التنبيه على اتصالات WebSocket ذات المصافحات غير المكتملة التي تستمر لأكثر من 30 ثانية
3. وضع علم على إعلانات الإطارات مع payload_length > 100MB
4. الكشف عن الإطارات المجزأة (علم nofin) بدون إكمال في نافذة 5 دقائق
5. مراقبة أحداث OOM killer على مستوى النظام المرتبطة بنشاط WebSocket