Logstash

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical (Logstash asset row) │ $7,000 │ $8,000 High │ $3,000 │ $3,750 Medium │ $1,500 │ $1,875 Low │ $700 │ $875 Submit a vulnerability CVE history 2 Last 12 months 17 Lifetime Code execution 30 % Info disclosure 25 % Parsing/validation 20 % Denial of service 15 % Latest advisories Loading the feed Overview Logstash is the default ingest and transform tier for the Elastic Stack, the most widely deployed open-source log-analytics platform in existence. It is the standard log shipper in a large share of enterprise SIEM and observability builds, ships in the Debian, Ubuntu and RHEL vendor repositories and as an official Docker image with hundreds of millions of pulls, and is a near-default component in regulated-industry logging pipelines that have to retain and transform audit events. Its deployment footprint sits exactly where the most sensitive plaintext in an organisation transits: raw logs, authentication events and audit trails, before any of it is indexed. That also defines its threat model, because a parsing bug in Logstash is reachable by anyone who can get a line into a log file it reads. Elastic N.V. pays it on HackerOne against a bound per-asset row running from $700 for a Low to $7,000 for a Critical, with the table figures acting as minimums rather than fixed prices. sorona.xyz adds 1.25x on top of whatever Elastic awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. Response times ~11 hours First response ~6 days Triage ~43 days Bounty In scope Elastic registers Logstash twice and pays both: a source-code asset for github.com/elastic/logstash , and a product asset covering any currently supported version, its platform downloads and the official container on docker.elastic.co, bound up to critical severity The policy names the whole product rather than a component list: 'If we wrote code with a bug in it, we want to know about it! Our code is open so use that to your advantage!' The full plugin surface outside x-pack : inputs such as beats, http, tcp, udp, syslog, kafka, jdbc, s3 and file; the filters that transform events, including grok, mutate, json, xml, csv and ruby; the outputs that ship them onward; and the codecs on either end The pipeline configuration language and its parser, multi-pipeline orchestration through pipelines.yml , pipeline-to-pipeline communication and settings handling The event model and the deserialization paths behind it, where log content written by an untrusted party becomes an object inside the process Persistent queues and the dead-letter queue, including how events are written to disk, read back and replayed The HTTP monitoring and management API, central pipeline management, and the keystore that holds pipeline secrets The JRuby and Java runtime boundary: plugin loading, the Java plugin API and the logstash-plugin installation tooling that pulls plugins in Out of scope Reports that reach Elastic by any route other than its own HackerOne program, which the policy makes a condition of bounty eligibility Findings requiring administrative or root OS privileges, since in Elastic's words 'the boundary between an administrator and the kernel is not a security boundary' Findings only reproducible on legacy or end-of-life versions of Logstash Volumetric or request-flood denial of service, which the policy rules out permanently rather than case by case Vulnerabilities in third-party systems, domains, services and components, even where Logstash bundles or calls them Previously known vulnerable libraries reported without a working proof of concept demonstrating reachability through Logstash itself Application-layer findings shown only on a deployment below the 1 CPU and 2 GB RAM floor the program requires Anything inside the x-pack folder for open-source classification purposes, because that subtree is Elastic-Licensed; it is still paid, it is just not open source Most-valued findings Code execution reached from ingested event content, the top class at 30% of history and the one that turns any party who can write a log line into an attacker on the ingest tier A deserialization or parser flaw in a filter or codec that a crafted log record can drive without any operator involvement Disclosure of pipeline secrets, upstream credentials, or the plaintext of events held in the persistent or dead-letter queue Configuration-parser or plugin-loading behaviour that lets untrusted input change what the pipeline executes An unauthenticated path into the HTTP monitoring and management API that reveals or alters pipeline state A single crafted event that stalls or crashes the pipeline, provided the effect does not depend on traffic volume Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Reproduce on a supported, non-EOL version; findings that only work against a legacy build are out of scope Application-layer findings must be reproduced on a deployment with no less than 1 CPU and 2 GB of RAM Volumetric denial of service is never eligible for a bounty, whatever the severity of the outage Only the Apache-2.0 tree outside the x-pack folder is open source; an x-pack finding is still paid but should not be routed as an open-source finding Elastic makes bounty eligibility conditional on the report being submitted exclusively through its official bug bounty program Program stats 891 Reports resolved $986k Bounties paid 79% Response efficiency Disclosure Coordinated by Elastic, but the policy conditions bounty eligibility on the report arriving exclusively through Elastic's own HackerOne program, so file there first and treat sorona.xyz as the follow-on rail. Elastic publishes the outcome as an Elastic Security Advisory once a fix has shipped. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability