Description

The webserver in UnrealIRCd 6.0.5 through 6.2.6 before 6.2.7 does not limit the number of HTTP request headers, which allows remote attackers to cause a denial of service (memory consumption and unresponsive server) via an HTTP request with an unlimited number of headers, if a websocket or JSON-RPC listener is enabled (disabled by default).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-13T02:17:05.103Z",
  "pubdate": "2026-09-13T02:17:05.103Z",
  "executiveSummary": "The webserver component within UnrealIRCd is susceptible to a denial-of-service (DoS) vulnerability arising from a lack of resource constraints regarding HTTP request headers.\nThis vulnerability is classified as an improper restriction of excessive input, leading to uncontrolled resource consumption.\nThe flaw affects UnrealIRCd versions 6.0.5 through 6.2.6, specifically when a websocket or JSON-RPC listener is enabled.\nAn unauthenticated remote attacker can exploit this by crafting a single HTTP request containing a virtually unlimited number of headers.\nThe primary impact is the exhaustion of available system memory, which renders the IRCd process unresponsive and necessitates a service restart to restore operational stability.\nAlthough these listeners are disabled by default, their activation creates a significant attack vector that bypasses standard request processing limits.",
  "technicalDetails": "The vulnerability resides in the HTTP parsing logic of the UnrealIRCd webserver module. The root cause is the absence of a defined limit on the number of HTTP headers processed per request before the server commits memory to store these headers.\nWhen a websocket or JSON-RPC listener is active, the webserver parses incoming HTTP traffic. An attacker can initiate a connection to one of these listeners and transmit a crafted HTTP request featuring an excessive volume of header fields. Because the implementation does not impose a maximum header count, the memory allocator continues to reserve space for each incoming header field until the heap becomes exhausted or the process hits operating system memory limits.\nThe attack flow proceeds as follows: 1) The attacker establishes a TCP connection to the port assigned to the JSON-RPC or websocket listener. 2) The attacker sends an HTTP request payload containing an abnormally large number of headers (e.g., thousands of unique, redundant, or malformed headers). 3) The server's parsing routine iterates through these headers, allocating memory for each one as it processes the request object. 4) As the allocation demand scales linearly with the number of headers provided, the server's memory consumption increases rapidly. 5) This leads to process instability, memory exhaustion, and a failure to service legitimate requests, ultimately causing the daemon to crash or become entirely unresponsive.\nThis vulnerability does not require authentication or specific user privileges, as it targets the request processing phase prior to session validation or request completion. It is exposed to any network entity capable of reaching the listening port. The lack of validation on the quantity of HTTP headers makes this a high-impact DoS vector for deployments where web-based management or websocket integration is enabled."
}