CrowdSec

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 CVE history 2 Last 12 months Parsing/validation 40 % Access control 30 % Denial of service 15 % Info disclosure 10 % Latest advisories Loading the feed Overview CrowdSec is a behaviour-based intrusion prevention system built around a shared reputation network. An agent parses logs on each host, scenarios decide which source addresses are behaving badly, and bouncers for iptables, nftables, nginx and Cloudflare enforce that decision, while confirmed findings feed a central blocklist every other participant consumes. CVE-2026-44982 shows what a defect here costs: the AppSec component silently dropped the request body for chunked and HTTP/2 requests, so the inspection layer stopped inspecting the traffic it was installed to inspect, with nothing in the logs to say so. CrowdSec is a commercial vendor that still pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy covers the agent, the Local API, and the bouncers the CrowdSec team develops and maintains under the crowdsecurity organisation. Everything in that set is fair game; community-written bouncers sit outside it The agent in full: log acquisition across every supported source, the parsers and scenarios that turn attacker-influenced lines into decisions, and the buckets and profiles behind them The Local API in full, including authentication, the machine and bouncer registration flow, and the decision and alert endpoints Every bouncer the CrowdSec team maintains, covering the iptables and nftables firewall bouncers that apply blocking decisions with privilege, and the remediation components for nginx and Cloudflare The AppSec component and its request handling end to end, from transfer encoding and HTTP version handling through to rule evaluation The Central API client and the consumption of shared blocklist data published by other participants The hub, and how the agent fetches, verifies and loads the parsers, scenarios and collections published there Local configuration and credential handling on the host, including the files the agent and its bouncers read at startup Out of scope Community-written bouncers, which the scope statement excludes by name, since only those the CrowdSec team develops and maintains are covered Anything outside the crowdsecurity organisation, including third-party integrations that call the Local API False positives and false negatives in a scenario, which are detection-tuning matters rather than defects in the code The commercial console as a hosted service, as distinct from the agent and API code that talk to it Most-valued findings Anything that makes the inspection path skip traffic it should have read, the CVE-2026-44982 class, where the operator sees no error and receives no protection Injection out of a parser or scenario into a privileged firewall command, since the whole design ends with the agent driving iptables or nftables on the strength of a log line an attacker wrote Local API authentication or registration defects that let an unauthorised machine or bouncer enrol, or let one tenant's decisions reach another's enforcement point Anything letting an attacker poison what the agent reports upstream, because the reputation feed carries that decision to every other participant in the network Hub supply-chain defects in how parsers, scenarios and collections are fetched and verified before the agent loads and executes them 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 to [email protected] , or through GitHub private vulnerability reporting on crowdsecurity/crowdsec ; an optional GPG key is published if you want to encrypt Check the scope statement before you write: the agent, the Local API and the bouncers the CrowdSec team develops and maintains under the crowdsecurity organisation are what the policy covers Community-written bouncers are explicitly excluded, so name the bouncer you tested and say who publishes it Include the log lines, parser and scenario that reproduce the behaviour. The detection chain is entirely data-driven and a claim about it is untestable without the input For AppSec findings, state the transfer encoding and HTTP version you used, since CVE-2026-44982 turned on exactly that distinction Disclosure Coordinated with the vendor through [email protected] or GitHub private vulnerability reporting, and published as a GitHub Security Advisory against crowdsecurity/crowdsec . The scope statement is written tightly enough that the first thing triage establishes is whether the component you tested is one the CrowdSec team maintains, so lead with that. 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