libsoup

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, not for the report. libsoup sits in Tier 2, which caps at $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Memory-safety hardening can carry a 2× or 3× multiplier. Patches must be between one and twelve months old, submissions are rate-limited to three a month, and sanctions and territory exclusions apply. CVE history 28 Last 12 months 57 Lifetime Memory safety 50 % Denial of service 25 % Parsing/validation 15 % Info disclosure 8 % Latest advisories Loading the feed Overview libsoup is the HTTP stack underneath GNOME and, more importantly, underneath WebKitGTK, so it parses attacker-controlled HTTP for the Epiphany browser and for every GTK application that renders web content. It ships by default on Debian, Ubuntu, Fedora and RHEL desktops, and a parsing bug in it is reachable from a hostile web server with no user interaction beyond loading a page. Fifty of its fifty-seven lifetime advisories landed in the last two years, twenty-eight in 2026 alone, which is sustained researcher attention going unpaid. GNOME takes reports as a confidential GitLab issue and pays nothing, and the European bounty that once covered the client side was removed in February 2026, so sorona.xyz pays you directly on qualified, reproduced findings. In scope GNOME's SECURITY.md takes a libsoup security issue as a confidential issue on GNOME GitLab, and Google's Tier 2 row covers the whole library rather than the client half only. Everything below is inside that HTTP/1.1 and HTTP/2 request and response parsing in full, the surface a hostile server reaches the moment a page loads SoupSession , connection reuse and the connection pool, where state from one exchange can bleed into the next Cookie jar handling and same-site logic, which decides what credentials leave the machine and for whom Authentication negotiation across Basic, Digest, NTLM and Negotiate, including how a challenge from an untrusted origin is parsed Content-Encoding and chunked transfer decoding, historically the richest source of length-confusion and overflow bugs in any HTTP stack The WebSocket handshake and framing path soupserver , the server side of the library, which Google's Tier 2 row covers even though upstream has historically treated it as lower priority Out of scope Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail Bugs that actually live in GnuTLS or glib-networking and are merely reached through libsoup Application-level misuse of the libsoup API rather than a defect in the library Denial of service that requires an already-privileged local attacker Patches outside the one-to-twelve-month age window the program requires Most-valued findings Memory corruption in HTTP/1.1 or HTTP/2 response parsing reachable from a hostile server with no interaction beyond loading a page, half of libsoup's bug history and the exact path WebKitGTK exposes Length or boundary confusion in chunked transfer or Content-Encoding decoding, the classic route from a malformed response to a heap write Request smuggling or response splitting arising from disagreement between libsoup's framing and an upstream proxy's Cookie jar or same-site logic errors that send credentials to an origin that should never have seen them Connection-pool state confusion in SoupSession that lets one origin's response or authentication state be served against another Structural hardening of a parser that closes a class of these at once, which is the shape the top of Google's ladder is written for Client-side findings ahead of soupserver ones on upstream priority, since a server-side patch still has to clear that upstream bar even though Google's row covers 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. The cash on Google's rail is paid for a merged upstream patch rather than for a vulnerability report. A report on its own earns nothing there libsoup develops on GNOME GitLab, so the merged artefact is a GitLab merge request rather than a GitHub pull request Keep the patch merged, without reverts, for one month before claiming, and submit it while it is between one and twelve months old Three Patch Rewards submissions per person per month is the hard cap The dead Sovereign Tech Fund program covered only the client side and excluded soupserver ; Google's Tier 2 row carries no such split and covers the whole library Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure GNOME takes security reports as confidential issues on GNOME GitLab, per the project's SECURITY.md, and pays nothing for them; libsoup fixes usually reach users as coordinated distribution updates because WebKitGTK depends on them. 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