Suricata

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. This is a Tier 2 project, in scope through its OSS-Fuzz integration, so $5,000 is the reachable ceiling; the $15,000 headline and the 2× and 3× memory-safety multipliers are Tier 1 only. Awards start at $100, the patch has to be between one and twelve months old, submissions are capped at three per person per month, and one-liner fixes for non-exploitable crashes are not rewarded. Sanctions and territory exclusions apply. CVE history 24 Last 12 months 65 Lifetime Denial of service 40 % Parsing/validation 25 % Memory safety 20 % Info disclosure 10 % Latest advisories Loading the feed Overview Suricata is the open-source IDS and IPS engine underneath a large share of commercial and community network security: Security Onion, SELKS, Corelight sensors, Stamus Networks, the pfSense and OPNsense plugins, AWS Network Firewall, and a great many enterprise and government sensor fleets. It is fed raw hostile traffic by design, and in IPS mode runs inline at a chokepoint able to drop or forward everything crossing it. A memory-safety bug in one of its application-layer parsers is reachable by any packet on the wire and lands in the process that controls the traffic. Its stream of 65 CVEs is dominated by parser-driven denial of service and evasion. The OISF pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Report through the process in Suricata's SECURITY.md, which the OISF runs around the project's release cadence with its own severity levels. The engine repository is the object: the Suricata-Update tool and SuriControl live in separate repositories, and everything else in the engine is in play The application-layer parsers as a whole, an unusually large mixed Rust and C surface covering HTTP/1, HTTP/2, TLS, SMB, DCERPC, DNS, SSH, MQTT, Modbus, ENIP, DNP3, NFS, SMTP, FTP, RDP and QUIC among others The detection engine and rule parser under detect-* in full, including the PCRE and Hyperscan integration that compiles attacker-influenced patterns The stream reassembly and defragmentation engine, together with the flow and session state it maintains The capture and packet-acquisition paths, including the NFQUEUE, AF_PACKET and DPDK modes that run inline with elevated privileges in IPS deployments The output layer, EVE JSON above all, where attacker-influenced field values reach a serialiser and then whatever consumes it The unix socket control interface, and the configuration and ruleset loading that runs behind it Out of scope Detection bypasses and evasion techniques that are rule-coverage gaps rather than defects in the engine's code Rulesets such as Emerging Threats and Talos, which are separate products and not Suricata code The Suricata-Update Python tool and SuriControl, which live in their own repositories and are not covered here unless they are in OSS-Fuzz in their own right Non-exploitable crash fixes at one-liner scale, and denial of service through resource exhaustion, which the reward rules place below the bar Patches younger than one month or older than twelve, which the reward age window excludes at both ends Anything not merged upstream, and anything reverted within the first month after it lands Most-valued findings Memory corruption in an application-layer parser reachable from ordinary traffic, because it lands in a process running inline with the power to drop or forward everything. This is the class that clears the systemic-hardening bar and pays at the top Structural hardening of the stream reassembly and defragmentation engine, where an evasion or state-exhaustion fix is architectural rather than a single bounds check Rule-parser and detection-engine defects, including through the PCRE and Hyperscan integration, since sensor operators load third-party rulesets they did not audit Parser-driven denial of service, which is 40% of Suricata's CVE stream and takes a whole sensor offline, but only where the fix is systemic, since the reward rules explicitly discount one-liner crash patches Bugs in the EVE JSON output path or the unix socket control interface, where the sensor's own telemetry or control plane becomes the injection point into whatever consumes it Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the process in Suricata's SECURITY.md; the OISF coordinates around its release cadence and offers no money for the report itself Send something reproducible: the pcap, ruleset or config that triggers it. A parser finding without a trigger cannot be triaged If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month, with the patch between one and twelve months old. That is a separate pathway with its own rules One-liner fixes for non-exploitable crashes are not rewarded on the Google side, which covers much of Suricata's denial-of-service stream unless the patch is a systemic hardening change Suricata's own Tier 1 to Tier 4 support levels are a different tiering from Google's and do not change what a patch is worth; a fix in a Community-tier component still sits in Google Tier 2 Google's side is capped at three submissions per person per month and cannot pay anyone on a sanctions list or resident in Russia or Belarus Disclosure Coordinated with the OISF through the process documented in the project's SECURITY.md, which defines severity levels and ships advisories alongside each maintenance release. The embargo is bounded by that release cadence rather than open-ended, and Patch Rewards adds no confidentiality term of its own. 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