Improper Neutralization of CRLF Sequences vulnerability in benoitc hackney allows HTTP Request Splitting. hackney does not percent-encode carriage return (\r) or line feed (\n) characters in the URL query component before constructing the HTTP/1.1 request target. Characters outside the grammar defined in RFC 3986 Section 3.4 must be percent-encoded, but hackney_url:make_url/3 passes the query binary directly without validation or escaping. An attacker who can control all or part of a URL passed to hackney can inject raw CRLF sequences into the query string, which are then sent as HTTP line breaks in the request target. This enables injection of arbitrary HTTP headers or splitting of the HTTP request.
This issue affects hackney: from 0 before 4.0.1.
CVE-2026-47075 is a critical HTTP Request Splitting vulnerability in the Erlang/Elixir hackney HTTP client library affecting versions before 4.0.1. The vulnerability allows attackers to inject arbitrary HTTP headers or split HTTP requests by exploiting improper neutralization of CRLF sequences in URL query parameters. With an active exploit available and widespread use of hackney in microservices and API integrations across Saudi organizations, this poses an immediate risk to applications handling untrusted URL inputs.
IMMEDIATE ACTIONS:
1. Identify all applications using hackney library by scanning dependency files (rebar.lock, mix.lock, package.json for Node.js wrappers)
2. Audit URL construction code to identify instances where user-controlled input flows into hackney requests
3. Implement input validation: reject URLs containing raw CR (\r) or LF (\n) characters before passing to hackney
PATCHING GUIDANCE:
1. Upgrade hackney to version 4.0.1 or later immediately
2. For Erlang/OTP projects: update rebar.lock with {hackney, "4.0.1"}
3. For Elixir projects: update mix.exs to {:hackney, "~> 4.0.1"}
4. Rebuild and redeploy all affected services within 48 hours
COMPENSATING CONTROLS (if immediate patching delayed):
1. Implement URL validation middleware that percent-encodes CRLF characters: replace \r with %0D, \n with %0A
2. Deploy WAF rules to detect and block HTTP requests with injected headers (look for CRLF patterns in query strings)
3. Restrict hackney usage to internal, trusted URL sources only
4. Monitor HTTP logs for suspicious header injection patterns
DETECTION RULES:
1. Log all HTTP requests containing %0D or %0A in query parameters
2. Alert on requests with duplicate or malformed HTTP headers
3. Monitor for requests with header names appearing in query strings
4. Track failed HTTP parsing events in application logs
الإجراءات الفورية:
1. تحديد جميع التطبيقات التي تستخدم مكتبة hackney من خلال مسح ملفات التبعيات (rebar.lock, mix.lock)
2. تدقيق كود بناء URL لتحديد الحالات التي يتدفق فيها المدخل الذي يتحكم به المستخدم إلى طلبات hackney
3. تنفيذ التحقق من المدخلات: رفض عناوين URL التي تحتوي على أحرف CR أو LF خام قبل تمريرها إلى hackney
إرشادات التصحيح:
1. ترقية hackney إلى الإصدار 4.0.1 أو أحدث فوراً
2. لمشاريع Erlang/OTP: تحديث rebar.lock باستخدام {hackney, "4.0.1"}
3. لمشاريع Elixir: تحديث mix.exs إلى {:hackney, "~> 4.0.1"}
4. إعادة بناء ونشر جميع الخدمات المتأثرة في غضون 48 ساعة
الضوابط البديلة (إذا تأخر التصحيح الفوري):
1. تنفيذ برنامج وسيط للتحقق من URL يقوم بترميز أحرف CRLF: استبدال \r بـ %0D، \n بـ %0A
2. نشر قواعد WAF للكشف عن حقن الرؤوس وحظره
3. تقييد استخدام hackney لمصادر URL الداخلية الموثوقة فقط
4. مراقبة سجلات HTTP للأنماط المريبة
قواعد الكشف:
1. تسجيل جميع طلبات HTTP التي تحتوي على %0D أو %0A في معاملات الاستعلام
2. التنبيه على الطلبات ذات الرؤوس المكررة أو المشوهة
3. مراقبة الطلبات التي تحتوي على أسماء رؤوس في سلاسل الاستعلام
4. تتبع أحداث فشل تحليل HTTP في سجلات التطبيق