- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 11
- 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
11 assets you may test, 4 excluded.
Web 1
- https://github.com/linux-pam/linux-pam
Products and areas 10
- Conversation-function handling and the data passed between modules and the calling application
- Every module shipped in this repository across all four management groups, auth, account, password and session, including the many that have never carried an advisory
- pam_access and its host, network and origin matching, along with the other modules that turn an attribute into an access decision
- pam_env and the reading of ~/.pam_environment and the system environment files
- pam_namespace and the polyinstantiation machinery, which does privileged filesystem work on paths inside a user's control
- pam_unix and the password verification path: hash comparison, shadow-file access and the helper binary it invokes
- Session and credential setup through pam_setcred and pam_open_session, where privileged work happens after authentication has already succeeded
- The configuration parser: /etc/pam.conf, the /etc/pam.d directory, and how a malformed or unexpected entry is interpreted
- The libpam core: stack evaluation order, return-code handling, and the required/requisite/sufficient control-flow semantics that decide whether a failure actually fails
- There is no SECURITY.md and no declared scope. The GitHub private advisory channel is enabled and produces real GHSAs, and it takes security defects anywhere in the Linux-PAM tree
Out of scope (4)
- A distribution's choice of default PAM stack, which is configuration by the distributor rather than a defect in the code
- Password-guessing and brute-force observations against a correctly functioning pam_unix
- Third-party PAM modules that are not in this repository, including vendor SSO modules, pam_mount, and the long tail of out-of-tree modules
- Weak local policy an administrator configured deliberately, such as a permissive pam_access rule or a disabled password quality check
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 at github.com/linux-pam/linux-pam/security/advisories/new
-
Name the module and the stack
-
Show the bug in Linux-PAM itself rather than in a distribution's default PAM configuration
-
Give the impact in terms of the privilege boundary crossed
-
propose your own disclosure timeline in the report and settle it in the advisory thread
Not accepted
-
Third-party PAM modules that are not in this repository
-
A distribution's choice of default PAM stack
-
Weak local policy an administrator configured deliberately
-
Password-guessing and brute-force observations against a correctly functioning pam_unix
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 CVE history 2 Last 12 months Race condition / symlink 35 % Local privilege escalation 30 % Environment injection 20 % Auth bypass 15 % Latest advisories Loading the feed Overview Linux-PAM is the layer every credential check on a glibc Linux system runs through. login , sshd , sudo , su , display managers and screen lockers all hand the decision to a PAM stack rather than making it themselves, so a defect here reaches the authentication path of hundreds of millions of hosts at once, frequently before any login completes. CVE-2025-8941 is the shape worth holding in mind: a race in pam_namespace combined with symlink manipulation, ending at root. Working proof-of-concept code for that class is already public. The project publishes no security policy and pays nothing, so sorona.xyz pays you directly on qualified, reproduced findings. In scope There is no SECURITY.md and no declared scope. The GitHub private advisory channel is enabled and produces real GHSAs, and it takes security defects anywhere in the Linux-PAM tree The libpam core: stack evaluation order, return-code handling, and the required / requisite / sufficient control-flow semantics that decide whether a failure actually fails Every module shipped in this repository across all four management groups, auth, account, password and session, including the many that have never carried an advisory pam_unix and the password verification path: hash comparison, shadow-file access and the helper binary it invokes pam_namespace and the polyinstantiation machinery, which does privileged filesystem work on paths inside a user's control pam_env and the reading of ~/.pam_environment and the system environment files pam_access and its host, network and origin matching, along with the other modules that turn an attribute into an access decision The configuration parser: /etc/pam.conf , the /etc/pam.d directory, and how a malformed or unexpected entry is interpreted Conversation-function handling and the data passed between modules and the calling application Session and credential setup through pam_setcred and pam_open_session , where privileged work happens after authentication has already succeeded Out of scope Third-party PAM modules that are not in this repository, including vendor SSO modules, pam_mount , and the long tail of out-of-tree modules A distribution's choice of default PAM stack, which is configuration by the distributor rather than a defect in the code Weak local policy an administrator configured deliberately, such as a permissive pam_access rule or a disabled password quality check Password-guessing and brute-force observations against a correctly functioning pam_unix Most-valued findings A race or symlink-following defect in pam_namespace that turns privileged session setup into a write the user chose. CVE-2025-8941 and CVE-2025-6020 are both this shape, and it is the largest slice of the project's recent history Environment or variable injection that survives into a privileged context. CVE-2025-6018 and CVE-2025-6019 became root only once pam_env output was chained through a systemd session, so chains count here Anything that makes the stack return success where it should return failure, including control-flow and return-code confusion in libpam itself, since that is auth bypass across every service on the host at once Host, origin or identity matching that an attacker can influence, the way CVE-2024-10963 let a spoofed hostname satisfy pam_access Memory corruption in pam_unix or the core reachable with attacker-controlled username or password material, because that surface is touched pre-auth by sshd 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 at github.com/linux-pam/linux-pam/security/advisories/new; private vulnerability reporting is enabled on the repository and the project publishes real advisories from it Name the module and the stack: pam_namespace , pam_env , pam_access and the rest behave differently depending on where in the stack they sit and which service pulled them in, so a bare module name is not a reproduction Show the bug in Linux-PAM itself rather than in a distribution's default PAM configuration, and rather than in a third-party module such as pam_mount or a vendor SSO module Give the impact in terms of the privilege boundary crossed, whether pre-auth, auth bypass, or unprivileged-to-root, because that is what determines whether a PAM defect matters There is no published policy or embargo window, so propose your own disclosure timeline in the report and settle it in the advisory thread Disclosure Coordinated through GitHub private vulnerability reporting and published as a GitHub Security Advisory; GHSA-f9p8-gjr4-j9gx is the pattern to expect. Distributions have to rebuild and ship the module set behind a PAM fix, so the practical embargo is longer than the advisory date suggests and public proof-of-concept code tends to appear quickly once it lifts. No written policy exists, so agree the timeline explicitly rather than assuming one. 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