An independent researcher found and reported to the HackerOne portal a flaw in how QRadar handles incoming network connections from external data sources (called “HTTP Receivers”). The flaw lets an attacker shut down all log collection on a QRadar system without credentials, special tools, or a large attack infrastructure.
This flaw was an example of a denial-of-service vulnerability based on CWE-400 Uncontrolled Resource Consumption, but not a break-in. An attacker using this cannot steal data or take control of the system — they can only stop it from collecting logs. However, for a security monitoring tool whose entire job is to see what’s happening on a network, going blind could be a significant failure.
A Denial-of-Service (DoS) attack is a cybersecurity attack designed to make a server, network, or application unavailable to legitimate users. Attackers typically achieve this by overwhelming the target with excessive traffic or requests, exhausting its resources and causing significant performance degradation or service outages. Unlike a Distributed Denial-of-Service (DDoS) attack, which originates from multiple systems, a traditional DoS attack typically comes from a single source.
How the attack works
When a device connects to QRadar’s HTTP Receiver to send log data, QRadar immediately assigns a dedicated worker (a processing slot) using the ecs-ec-ingress service to handle that connection — even before checking whether the device is allowed to connect. An attacker could exploit this by:
- Opening a large number of network connections to QRadar
- Sending just 3 bytes of data per connection — barely anything — and then doing nothing
- QRadar keeps each worker tied up waiting for more data that never comes, forever, because there is no timeout configured in the vulnerable class in the JDK’s
com.sun.net.httpserverlibrary without settingsun.net.httpserver.maxReqTime
Since there are a limited number of workers (64 by default) and a system-wide limit on the number of connections a process can hold open (~15,000), the attacker can fill all of them up. A single laptop can open 14,774 connections in 16 minutes, so this attack didn’t require a large-scale botnet.
Under attack.
Once all available connections are used up, then all HTTP Receivers stop accepting new legitimate logs — even ones on different ports that were never targeted
Unrelated data sources stop working too — things like Office 365 and other cloud-based log integrations fail because they can no longer open the files or network connections they need. QRadar keeps reporting everything as “SUCCESS” — the health dashboard shows no problems, and no alerts fire. The jmx diagnostic tool, which IBM support uses to investigate, relies on the handler pool to inspect it and becomes unreachable at the same moment, because it itself needs a new socket to connect. As a result, the entire event collection system goes dark silently, while still reporting SUCCESS status.
Attackers could act freely during the outage without detection or logging. An operator looking at the system the next day would see a multi-hour gap in data but find no crash, no error, no restart, and no alert — nothing pointing to what happened. Recovery was instant once the attacker disconnected — within seconds, everything returned to normal with no trace left behind, or after the ingress restart, which disconnects every existing connection and then reconnects. This could allow an attacker to temporarily blind QRadar, carry out another action, and leave no forensic evidence in QRadar itself.
Mitigation.
IBM has already investigated and fixed this vulnerability via daily Auto-updates. You can confirm it by checking your console from the backend using the following commands:rpm -qa|grep -i httpreceiver
PROTOCOL-HTTPReceiver-7.6-20260930064911.noarch
If the response shows any version older than 30 September 2026, please install this package as soon as possible or enable Auto-updates. If your installation is in an air-gapped environment, you can download the weekly update package from the FixCentral repository.