- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
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.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 6 excluded.
Web 1
- https://www.x.org
Products and areas 12
- Authentication and access control: the MIT-MAGIC-COOKIE path, Xauth file handling, the host access list and the SECURITY extension's trusted and untrusted client model
- Client isolation as the server enforces it, including grabs, selections, the cut buffer and primary selection, and what one client can read or inject into another
- Configuration parsing, xorg.conf and xorg.conf.d handling, module and driver loading, and log file handling on the privileged path
- Every server extension. The majority of this project's severe defects have historically lived there: XKB, RENDER, RANDR, XFIXES, DAMAGE, COMPOSITE, GLX, DRI, XVideo, SHM, Xinerama, SECURITY and the input extensions are all in
- Font handling and the font path, including remote font servers where they are still configured
- Input handling end to end: XInput and XI2, device hotplug, keymap and XKB handling, and event delivery between clients
- Server-side helper paths that touch the filesystem or spawn processes while privileged
- The core protocol implementation in dix: request dispatch, resource management, window and pixmap handling, and the atom and property machinery
- The GLX and direct rendering boundary as the server implements it, covering what a client can drive through it
- The Xorg DDX in hw/xfree86: driver loading, mode setting, the setuid startup path and everything the server does before it drops privilege
- The X.Org security team asks for security issues in the X.Org codebase and draws no line narrower than that, so everything below is inside the declared scope
- Xwayland and Xnest and Xvfb as DDX targets in the same repository, subject to the ChromeOS caveat above
Out of scope (6)
- Configuration an administrator chose deliberately, including running xhost + or enabling TCP listening
- Distribution packaging and distro-specific patches rather than the upstream xserver tree
- Mesa and libdrm, both paid: Mesa is named verbatim in the Chrome Browser VRP and both ship in the ChromeOS overlays
- Proprietary GPU drivers and vendor DDX modules, which belong to those vendors
- The inherent design of X11 client isolation. That any client can read any other client's input by design is a known property of the protocol and not a reportable defect
- The X11 client libraries. libX11, libXext, libXi, libXrandr, libxcb and the rest are separate repositories and ship in ChromeOS, so they are covered by the ChromeOS VRP and paid there
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz.
-
Report privately to the address on the policy page , the address the X.Org security wiki names for security issues in the X.Org codebase
-
Do not open a public issue on gitlab.freedesktop.org for a security defect
-
State whether the defect is in the Xorg DDX or in shared dix and extension code.
-
Name the extension and the exact request sequence.
-
Say whether your reproducer needs the server running setuid root
-
Give the server version and the distribution.
Not accepted
-
The inherent design of X11 client isolation
-
Configuration an administrator chose deliberately
-
Distribution packaging and distro-specific patches
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
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 Latest advisories Loading the feed Overview The X.Org Server is still the display server on RHEL, AlmaLinux and Rocky 8 and 9, and on a large amount of enterprise desktop estate that has not moved to Wayland. It parses every X protocol request from every client on the session, historically while running setuid root on the Xorg DDX path. One client reading another client's input or memory is the classic shape here, and the extension code is usually where it lives. Reports go by mail to the X.Org security team, which runs a documented workflow from report to released advisory. No bounty programme covers the X server, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The X.Org security team asks for security issues in the X.Org codebase and draws no line narrower than that, so everything below is inside the declared scope The core protocol implementation in dix : request dispatch, resource management, window and pixmap handling, and the atom and property machinery Every server extension. The majority of this project's severe defects have historically lived there: XKB, RENDER, RANDR, XFIXES, DAMAGE, COMPOSITE, GLX, DRI, XVideo, SHM, Xinerama, SECURITY and the input extensions are all in Input handling end to end: XInput and XI2, device hotplug, keymap and XKB handling, and event delivery between clients Client isolation as the server enforces it, including grabs, selections, the cut buffer and primary selection, and what one client can read or inject into another The Xorg DDX in hw/xfree86 : driver loading, mode setting, the setuid startup path and everything the server does before it drops privilege Configuration parsing, xorg.conf and xorg.conf.d handling, module and driver loading, and log file handling on the privileged path Authentication and access control: the MIT-MAGIC-COOKIE path, Xauth file handling, the host access list and the SECURITY extension's trusted and untrusted client model Font handling and the font path, including remote font servers where they are still configured The GLX and direct rendering boundary as the server implements it, covering what a client can drive through it Xwayland and Xnest and Xvfb as DDX targets in the same repository, subject to the ChromeOS caveat above Server-side helper paths that touch the filesystem or spawn processes while privileged Out of scope The X11 client libraries. libX11, libXext, libXi, libXrandr, libxcb and the rest are separate repositories and ship in ChromeOS, so they are covered by the ChromeOS VRP and paid there Mesa and libdrm, both paid: Mesa is named verbatim in the Chrome Browser VRP and both ship in the ChromeOS overlays Proprietary GPU drivers and vendor DDX modules, which belong to those vendors The inherent design of X11 client isolation. That any client can read any other client's input by design is a known property of the protocol and not a reportable defect Configuration an administrator chose deliberately, including running xhost + or enabling TCP listening Distribution packaging and distro-specific patches rather than the upstream xserver tree Most-valued findings Memory corruption in extension request handling, driven by a length, an index or a count the client supplies. This is the densest class in the server's history and the extensions are where it concentrates Anything reachable from an unauthenticated or untrusted client connection, which raises the severity considerably over a bug needing a normal authorised client Privilege escalation on the Xorg DDX startup path, where the server historically runs setuid root and reads configuration, loads modules and opens log files before dropping privilege Configuration and module loading defects that let a local user steer what the privileged server loads or writes Client isolation failures that go beyond X11's known design, such as a client reaching another client's resources through a resource-ID or lifetime confusion rather than through the protocol's documented lack of separation XKB and keymap handling flaws, a repeat source of severe bugs and reachable from any client on the session Xauth and access control handling that lets a connection through without the cookie it should have needed Input event delivery defects that route keystrokes to a client that should not receive them, particularly across a screen locker Shared code in dix or in an extension that is also reachable through Xwayland, which multiplies the affected population well past classic X11 sessions 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 privately to [email protected] , the address the X.Org security wiki names for security issues in the X.Org codebase Do not open a public issue on gitlab.freedesktop.org for a security defect State whether the defect is in the Xorg DDX or in shared dix and extension code. Anything shared also reaches Xwayland, which changes who else is affected and where the fix has to land If the finding is Xwayland-only, know that Xwayland ships in ChromeOS and Google's ChromeOS VRP may pay for it. Check there before treating it as unpaid Name the extension and the exact request sequence. Almost everything interesting here is an extension request handled with attacker-controlled lengths or indices Say whether your reproducer needs the server running setuid root, since many distributions now start Xorg without it and that changes the severity considerably Give the server version and the distribution. RHEL and its derivatives carry heavily backported branches and the upstream tree is often ahead of what is deployed There is no bounty. Reports earn an advisory credit and nothing more Disclosure Coordinated by mail with the X.Org security team, which runs a documented checklist to take a report from private disclosure through to a released advisory. Fixes and advisories go out together, with distributions briefed ahead of the release because so much enterprise estate carries the server. Enterprise distributions then backport into branches years older than upstream. Hold detail until the advisory and the coordinated releases are out. 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