systemd

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 on the Tier 2 row, which systemd reaches through its OSS-Fuzz integration, for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. The Tier 2 column runs from $100 for a one-liner to $5,000 for a complicated, high-impact change, and the memory-safety multiplier is Tier 1 only, so it does not apply here. The patch must be at least one month and under twelve months old, it is rate-limited to three submissions a person a month, the maintainers hold a veto, and sanctions and territory exclusions apply. CVE history 55 Lifetime Access control 28 % Memory safety 28 % Parsing/validation 24 % Info disclosure 14 % Latest advisories Loading the feed Overview systemd is PID 1 on essentially every mainstream Linux distribution: RHEL, CentOS, Fedora, Debian, Ubuntu, SUSE, Arch, Amazon Linux 2023 and the base images under most container hosts. It owns far more than init, taking in logging through journald, DNS through resolved, device management through udev, sessions through logind and network configuration, across hundreds of millions of servers. A local privilege escalation here is root on nearly every Linux box in existence, and German federal money was once pointed at exactly that: the Sovereign Tech Fund bounty on YesWeHack paid up to EUR 10,000 for systemd. It is dead and delisted, and the project itself pays nothing, so sorona.xyz pays you directly on a qualified, reproduced finding. In scope Reports go to the systemd security address at [email protected] , against upstream systemd rather than a distribution's patched build. The object is the whole project, from PID 1 out to every daemon it ships PID 1 itself: unit activation, the D-Bus interfaces systemd exposes, and every boundary an unprivileged user can cross into work that runs as root journald end to end, from records arriving over the socket from unprivileged processes, through indexing, to the files other users read systemd-resolved in full, which parses DNS responses from the network and is the resolver every process on the host trusts udev and its rule engine, where device attributes supplied by attached hardware drive rule matching and helper execution logind and the session and seat logic, including the polkit boundaries that decide which user may act on which session The configuration parsers as a set: unit files, sysusers, tmpfiles and credentials, wherever a specifier, path or permission becomes a privileged action systemd-networkd and the DHCP and NDP client paths, which consume unauthenticated packets from the local network The sandboxing and hardening directives, ProtectSystem, PrivateTmp and the seccomp integration, which are a security control in their own right Out of scope Distribution packaging and downstream patches: unit files or defaults a distribution ships that upstream systemd does not Defects that actually live in the kernel, dbus-daemon, polkit or glibc rather than in systemd itself Configuration arguments about upstream defaults, such as which units are enabled or how a hardening directive is set, which are policy rather than a defect Attacks that assume the attacker is already root, which sits outside the boundary systemd is defending One-line fixes for non-exploitable crashes, which the Patch Rewards rules will not reward, including crashes that come from resource exhaustion Patches the maintainers decline, patches under one month or over twelve months old, and anything past three submissions a person a month Most-valued findings Local privilege escalation from an unprivileged user to root through a systemd interface, which is the top bug class here at 28% and the reason this target is priced the way it is Memory corruption in journald or resolved reachable from data an unprivileged process or a network peer supplies, since both run privileged and both parse untrusted input by design A parsing flaw in unit, tmpfiles or credential handling that turns an attacker-influenced string into a privileged file operation Sandbox or hardening-directive bypass, where a service confined by ProtectSystem, PrivateTmp or a seccomp filter can reach outside it. A whole-class fix here is exactly what the top of the Patch Rewards scale rewards Cross-session or cross-user information disclosure through logind or the journal, which quietly breaks the isolation every multi-user Linux host assumes 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. Send a detailed, reproducible report to the systemd security address; if the maintainers cannot reproduce it, it is not eligible Show the bug against upstream systemd rather than a distribution's patched build, or demonstrate that the upstream code carries it too Give the maintainers room to ship a fix and publish an advisory before any public writeup The retired Sovereign Tech Fund programme on YesWeHack is delisted and pays nothing, so do not treat it as a live route The Google patch money is a separate pathway: you land the fix upstream yourself and keep it merged, without reverts, for one month, and at Tier 2 there is no memory-safety multiplier Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated privately with the systemd security team at [email protected] , which also coordinates with distribution security teams before a fix lands, because a systemd advisory has to ship simultaneously across every major distribution. Hold the detail until that coordinated release is out. Nothing in the Patch Rewards rules restricts who may help you prepare or route the report. 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