Discovering 9 DoS Vulnerabilities in Elastic Beats

After finding dozens of zero-days in libraries such as OpenSSL and Amazon’s crypto stack, we wondered what vulnerabilities might be lurking in other critical software infrastructure. That led us to Elastic’s ELK stack (Elasticsearch, Logstash, and Kibana), which is one of the most widely deployed logging, search, and observability platforms in use today. With $1.5 billion in revenue, Elastic is trusted by thousands of organizations, so vulnerabilities in the ELK stack have a wide blast radius.

Focusing our efforts on Elastic's lightweight data shippers, or Beats, we used the AISLE analyzer to discover 9 denial-of-service (DoS) vulnerabilities in the ELK stack. Eight of these vulnerabilities have since been fixed, and one more is pending a final patch. Left unaddressed, each of these nine vulnerabilities could have been exploited to create blind spots in the security pipelines of Fortune 10 enterprises and government agencies.

In this blog, we’ll give a high-level overview of our findings.

The Findings at a Glance

Packetbeat

Filebeat

Metricbeat

Elastic Beats: The Basics

Elastic Beats are open-source agents that collect and ship operational data such as network traffic, logs, and metrics to Elasticsearch or other destinations. They are commonly deployed on production hosts, in containers, and at network boundaries:

• Packetbeat passively captures and decodes network protocols (DNS, HTTP, MongoDB, PostgreSQL, AMQP, NFS, and many others).
• Filebeat ships log data and can expose HTTP endpoints for webhook ingestion or listen for NetFlow/IPFIX streams.
• Metricbeat collects system and service metrics, including a Prometheus remote_write receiver.

The availability of a system's logging capabilities is paramount to the security of the system. Any ability to halt or restrict the logging of events creates a serious security risk because tamper-evident logs provide little assurance when relevant events are entirely missing. Even a few seconds of missing logs can mean the difference between a serious security incident being detected and understood, or going unnoticed altogether. If logs do not exist in the first place, the audit trail is incomplete and the chain of custody is compromised, undermining accountability, detection, and forensic investigation.

Two Classes of Denial of Service

While all nine vulnerabilities result in denial of service, they divide cleanly into two categories based on how the attacker takes down the process and how much effort it requires.

Resource exhaustion

These vulnerabilities let a remote attacker drive sustained memory or CPU growth until the Beat process is killed by the OS' out-of-memory killer, or simply becomes completely unresponsive. Some require a sustained stream of packets but others need just a single request.

• Packetbeat IPv4 fragment reassembly — By sending incomplete IPv4 fragments with high TTLs and varying IDs, an attacker can make Packetbeat retain copied fragment payloads in a cache with no per-flow or global byte limit. The result is sustained memory and CPU exhaustion, along with the possibility of telemetry being misattributed across flows.
• Metricbeat Prometheus remote_write — An attacker uses a small Snappy payload can advertise an enormous decoded size, and because Metricbeat trusts that size when it passes the body into snappy.Decode(nil, data), this leads to an attacker-controlled allocation and an immediate OOM crash.
• Filebeat http_endpoint — Chunked, gzip-compressed requests exploit two separate gaps: Filebeat misaccounts for max_in_flight_bytes when ContentLength is -1, and it decompresses the body without a size cap. Together, those behaviors let an attacker bypass limits and drive the process into memory exhaustion.
• Filebeat NetFlow — Here the attacker only needs to forge a large record count in a small NetFlow packet. Filebeat trusts that count when pre-allocating flow records for fixed-length templates, producing repeated multi-megabyte allocations and steadily rising RSS.
• Packetbeat Redacted decoder — Details redacted until fix.

In each of these vulnerabilities, the code reads a length, count, or size field from untrusted input and uses it to allocate memory or accumulate data without checking whether the declared size is plausible. Fixes thus involve clamping declared sizes against the bytes that are actually available and enforcing hard upper bounds before allocation.

Unchecked input crashes

These vulnerabilities let a remote attacker crash the Beat process instantly with a single malformed packet. In each of them, parsers index or slice into byte buffers using attacker-controlled offsets or counts without verifying that enough data exists. In Go, this causes a runtime panic. Because none of the affected parsers have panic recovery, the panic propagates to the top-level runner, which logs a fatal message and exits.

• Packetbeat AMQP — An attacker sends a truncated AMQP frame, which is parsed by Packetbeat through property and field-table branches that index into buffers without checking len(data), resulting in an out-of-bounds panic.
• Packetbeat PostgreSQL — An attacker sends a DataRow that claims more fields than an earlier RowDescription declared, which is indexed by Packetbeat into m.fieldsFormat without validating the count, resulting in a runtime panic and process crash.
• Packetbeat MongoDB — An attacker sends a forged MongoDB message with negative or oversized length fields that are trusted by Packetbeat during truncation, BSON slicing, and reply allocation, leading to a panic or OOM from a single TCP segment.
• Packetbeat NFS — An attacker sends a truncated RPC/NFS fragment that is consumed by Packetbeat's XDR helpers without checking that enough bytes remain in the buffer, resulting in an immediate crash and, in some paths, unbounded allocation.

The Fixes

AISLE provided fixes for all nine issues which were then iterated on by Elastic. In each case, the vulnerabilities were fixed with proper bounds checking.

Note that AISLE’s autonomous system found other security vulnerabilities in Elastic software, which we’ll be reviewing in a future post. In each case, we followed responsible disclosure practices in collaboration with the Elastic maintainers.

Talk to Us

AISLE's analyzer found nine High-severity vulnerabilities in one of the most widely deployed observability stacks in the world. Want to know what it would find in yours? Get in touch

Our sincere appreciation goes to the Elastic maintainers for their collaboration and support. These issues were discovered and reported by Pavel Kohout using AISLE’s analyzer.