Skip to content

xrdp

By sorona.xyz Bug bounty on Sorona

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
13
Public CVEs
34
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
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 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://github.com/neutrinolabs/xrdp

Products and areas 12

  • chansrv and every virtual channel it serves: clipboard, drive redirection over FUSE, audio, microphone input and smartcard forwarding
  • Configuration parsing across xrdp.ini, sesman.ini and the module definitions, plus the xrdp-sesadmin and xrdp-sesrun administrative tools
  • RSA key handling and the xrdp-keygen tool that produces the server key material
  • SECURITY.md names the GitHub advisory form as the security channel and does not limit scope beyond the project's own code, so everything shipped from the repository is in, together with the xorgxrdp X server module the project maintains alongside it
  • The codec and compression paths, including RemoteFX through librfxcodec, JPEG, planar and interleaved bitmap compression
  • The drive redirection mount, where a remote client's filesystem is exposed into a local session and vice versa
  • The loadable authentication modules and anything they accept from the network side
  • The pre-authentication RDP front end on TCP 3389: X.224 connection requests, the MCS layer, the capability exchange and every field parsed before a user exists
  • The security layers, covering standard RDP encryption, TLS and the NLA and CredSSP path, together with the NTLM implementation behind it
  • The sesman session manager: authentication through PAM and the other supported backends, session creation, the user switch and the privilege drop around it
  • The session lifecycle, covering reconnection to an existing session, session termination and the decision about which user may attach to which display
  • The xorgxrdp X server module and the shared-memory and pixel-transfer path between it and xrdp
Out of scope (6)
  • A finding already covered by an open or published advisory, which the first-come-first-served duplicate policy will close
  • Deployments exposing 3389 to the internet with no TLS and no network controls, which is an operator decision
  • Distribution packaging and vendor patches rather than the upstream repository
  • FreeRDP, Remmina or the Microsoft RDP client's own defects, as opposed to xrdp's handling of what they send
  • Local users with a valid account doing what their account already permits inside their own session
  • The X server and desktop environment behind the session rather than xrdp and xorgxrdp

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.
  • Do not use the project mailing list for security issues.
  • Say which process is affected.
  • Include the client that triggered it.
  • Duplicates are handled first-come-first-served and only the first reporter is credited

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.

Sorona credits this project with 34 CVEs, 19 of them recent. The individual records appear here after the next sync.

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 CVE history 19 Last 12 months 34 Lifetime Memory safety 50 % Parsing/validation 25 % Auth bypass 15 % Info disclosure 10 % Latest advisories Loading the feed Overview xrdp is how a Linux machine accepts an RDP connection. It is what the Ubuntu and Debian remote-desktop guides tell you to install and the standard answer for Linux virtual desktops in cloud environments, sitting on TCP 3389 and parsing bytes before anyone has authenticated. The advisory record makes the case without needing a headline CVE: 19 advisories published in the last twelve months out of 34 ever, including a batch of at least five on a single day in July 2026. That is the busiest listener in this category outside FreeRDP and it pays nothing, so sorona.xyz pays you directly on qualified, reproduced findings. In scope SECURITY.md names the GitHub advisory form as the security channel and does not limit scope beyond the project's own code, so everything shipped from the repository is in, together with the xorgxrdp X server module the project maintains alongside it The pre-authentication RDP front end on TCP 3389: X.224 connection requests, the MCS layer, the capability exchange and every field parsed before a user exists The security layers, covering standard RDP encryption, TLS and the NLA and CredSSP path, together with the NTLM implementation behind it RSA key handling and the xrdp-keygen tool that produces the server key material The sesman session manager: authentication through PAM and the other supported backends, session creation, the user switch and the privilege drop around it The session lifecycle, covering reconnection to an existing session, session termination and the decision about which user may attach to which display chansrv and every virtual channel it serves: clipboard, drive redirection over FUSE, audio, microphone input and smartcard forwarding The drive redirection mount, where a remote client's filesystem is exposed into a local session and vice versa The xorgxrdp X server module and the shared-memory and pixel-transfer path between it and xrdp The codec and compression paths, including RemoteFX through librfxcodec , JPEG, planar and interleaved bitmap compression Configuration parsing across xrdp.ini , sesman.ini and the module definitions, plus the xrdp-sesadmin and xrdp-sesrun administrative tools The loadable authentication modules and anything they accept from the network side Out of scope FreeRDP, Remmina or the Microsoft RDP client's own defects, as opposed to xrdp's handling of what they send The X server and desktop environment behind the session rather than xrdp and xorgxrdp Deployments exposing 3389 to the internet with no TLS and no network controls, which is an operator decision Local users with a valid account doing what their account already permits inside their own session Distribution packaging and vendor patches rather than the upstream repository A finding already covered by an open or published advisory, which the first-come-first-served duplicate policy will close Most-valued findings Memory corruption in the pre-authentication path on TCP 3389. This is the densest part of the record and the highest-impact class, because the listener parses attacker-chosen bytes with no credential in play at all Anything in the NLA or CredSSP handling that accepts an authentication result it should reject, since that check is the only thing between the open port and a login Defects in sesman , which runs privileged and performs the user switch. A bug there is local or remote privilege escalation to root rather than access to one desktop Session attachment errors that let one user reconnect to another user's live session, on a multi-user server where that is the entire trust boundary Drive redirection and FUSE mount handling, where a remote client's filesystem meets a local session and path handling decides what crosses Clipboard and channel handling in chansrv , which processes data the remote client fully controls on behalf of an authenticated session Codec decoder bugs in librfxcodec and the bitmap compression paths, where compressed input drives length arithmetic Remotely triggerable crashes of the listener with a real algorithmic cause, on the only remote-access route into a machine that may have no other one 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 through the GitHub advisory form on neutrinolabs/xrdp , the channel SECURITY.md documents. Private vulnerability reporting is enabled Do not use the project mailing list for security issues. It is private but the project describes it as explicitly not secure, and it exists for non-security matters Duplicates are handled first-come-first-served and only the first reporter is credited, a policy the project attributes to the volume of reports it receives. On a project publishing this many advisories, check the open advisory list before spending a week on a finding Say which process is affected. xrdp is the pre-authentication listener, sesman runs privileged and handles login, chansrv handles per-session channels and xorgxrdp is the X server module Include the client that triggered it. Behaviour differs between the Microsoft RDP clients, FreeRDP and Remmina, and a reproduction needs the client side named The project offers credit only. There is no reward and no reward terms to accept Disclosure Coordinated through GitHub private vulnerability reporting and published as a GitHub Security Advisory with a CVE alongside a release. The project ships advisories in batches rather than one at a time, so plan for an embargo running to the next security release rather than to a fixed day count. Distribution packages lag upstream by months on this project, so hold the detail until the advisory is public. 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