- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 7
- 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.authelia.com
Products and areas 12
- Every second-factor method: TOTP registration and verification, WebAuthn registration and assertion, mobile push and the Duo integration
- First-factor authentication against the file backend and against LDAP or Active Directory, including the password hashing and the search and bind configuration
- Password reset, account registration and the email flows behind both, including the identity verification tokens they carry
- Regulation and rate limiting, the mechanism that gates repeated authentication attempts
- Session management: the session cookie, its domain and lifetime, inactivity handling, the remember-me path and the session storage backend
- The access control rule engine in full: domain, subdomain, resource, method, subject and network matching, plus the policy levels from bypass through one-factor to two-factor and deny
- The API, the health and metrics endpoints, and anything reachable without a session
- The configuration loader, secret file handling and environment variable expansion
- The forward-auth endpoints every supported reverse proxy calls, and the headers Authelia returns for the proxy to act on and pass downstream
- The OpenID Connect provider Authelia implements, covering client registration, every grant type, PKCE handling, the consent flow, token issuance and the userinfo endpoint
- The policy asks for GitHub private vulnerability reporting on authelia/authelia or email to [email protected], and treats direct messages as a discouraged fallback. It declares no boundary narrower than Authelia itself
- The storage backends and what is written to them, including secrets, TOTP shares and WebAuthn credentials
Out of scope (6)
- An access control rule an operator wrote that is simply more permissive than intended
- A proxy configuration that forwards a request without calling the auth endpoint, which is an operator error rather than an Authelia defect
- The applications sitting behind the portal
- The LDAP or Active Directory server Authelia authenticates against
- The reverse proxies themselves, whose configuration decides whether Authelia is consulted at all
- Third-party Docker images, Helm charts and packages the project does not publish
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report through GitHub private vulnerability reporting on authelia/authelia , or by email to the address on the policy page
-
Direct messages to the core team on Matrix or Discord are documented but discouraged. Use the advisory form or the security address
-
Give the full Authelia configuration and the reverse proxy snippet. A forward-auth finding depends on both halves and the proxy configuration decides what headers survive
-
Name the session and cookie configuration, including the cookie domain and whether several applications shared one session domain. Most session findings turn on that
-
Say which second-factor method was in play. TOTP, WebAuthn and the push methods are separate verification paths with separate code
-
hold detail until the advisory and the release are out.
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-33525 | Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In version 4.39.15, an attacker may potentially be able to inject javascript into the Authelia login page if several conditions are met simultaneously. Unless both the `script-src` and `connect-src` directives have been modified it's alm | Low 0.5 | 26 Mar 2026 |
| CVE-2021-32637 | Authelia is a a single sign-on multi-factor portal for web apps. This affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed UR | Critical 10.0 | 28 May 2021 |
| CVE-2021-29456 | Authelia is an open-source authentication and authorization server providing 2-factor authentication and single sign-on (SSO) for your applications via a web portal. In versions 4.27.4 and earlier, utilizing a HTTP query parameter an attacker is able to redirect users from the web application to any domain, including potentially malicious sites. This security issue does not directly impact the sec | Medium 5.7 | 21 Apr 2021 |
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 3 Last 12 months 7 Lifetime Auth bypass 40 % Access control 25 % Session handling 20 % Info disclosure 15 % Latest advisories Loading the feed Overview Authelia is the authentication portal in front of self-hosted infrastructure. It runs as the companion to nginx, Traefik and Caddy, and the proxy asks it whether a request may proceed. Everything behind it, from admin panels through to file shares, is exposed the moment that answer is wrong, and a large homelab and small-business population puts it in exactly that position. Its policy runs unpaid coordinated disclosure with credit at maintainer discretion, and the project is openly seeking sponsorship to fund audits it cannot pay for. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for GitHub private vulnerability reporting on authelia/authelia or email to [email protected] , and treats direct messages as a discouraged fallback. It declares no boundary narrower than Authelia itself The forward-auth endpoints every supported reverse proxy calls, and the headers Authelia returns for the proxy to act on and pass downstream The access control rule engine in full: domain, subdomain, resource, method, subject and network matching, plus the policy levels from bypass through one-factor to two-factor and deny Session management: the session cookie, its domain and lifetime, inactivity handling, the remember-me path and the session storage backend First-factor authentication against the file backend and against LDAP or Active Directory, including the password hashing and the search and bind configuration Every second-factor method: TOTP registration and verification, WebAuthn registration and assertion, mobile push and the Duo integration The OpenID Connect provider Authelia implements, covering client registration, every grant type, PKCE handling, the consent flow, token issuance and the userinfo endpoint Password reset, account registration and the email flows behind both, including the identity verification tokens they carry Regulation and rate limiting, the mechanism that gates repeated authentication attempts The storage backends and what is written to them, including secrets, TOTP shares and WebAuthn credentials The configuration loader, secret file handling and environment variable expansion The API, the health and metrics endpoints, and anything reachable without a session Out of scope The reverse proxies themselves, whose configuration decides whether Authelia is consulted at all The applications sitting behind the portal A proxy configuration that forwards a request without calling the auth endpoint, which is an operator error rather than an Authelia defect The LDAP or Active Directory server Authelia authenticates against An access control rule an operator wrote that is simply more permissive than intended Third-party Docker images, Helm charts and packages the project does not publish Most-valued findings Any path where the forward-auth endpoint returns success for a request an access control rule denies. The proxy trusts that answer completely and nothing downstream re-checks it Header spoofing, where a client-supplied header survives into the response Authelia hands the proxy and forges the authenticated identity for the application behind it Session handling defects, above all cookie domain scoping across subdomains, where a session issued for one application authenticates a request to another Two-factor bypass in WebAuthn assertion handling or TOTP verification, since the second factor is the reason most of these deployments exist The OpenID Connect provider's token issuance, audience and PKCE checks, because that surface hands identity to other applications and a defect there escapes the portal entirely Password reset and registration flows that bind a credential or a second factor to an account the requester does not own Access control rule matching where a domain, path or network expression matches wider than it reads, which silently downgrades a two-factor rule to bypass Regulation bypass allowing unlimited first-factor attempts against an internet-facing portal Credential and secret disclosure from the storage backend, the configuration loader or any endpoint reachable without a session 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 through GitHub private vulnerability reporting on authelia/authelia , or by email to [email protected] Direct messages to the core team on Matrix or Discord are documented but discouraged. Use the advisory form or the security address Nothing is paid at any severity. Credit in the advisory and the contributors list is at maintainer discretion, and the project is seeking sponsorship for audits Give the full Authelia configuration and the reverse proxy snippet. A forward-auth finding depends on both halves and the proxy configuration decides what headers survive Name the session and cookie configuration, including the cookie domain and whether several applications shared one session domain. Most session findings turn on that Say which second-factor method was in play. TOTP, WebAuthn and the push methods are separate verification paths with separate code Disclosure Coordinated privately with a small volunteer core team through GitHub private vulnerability reporting or the security address, published as a GitHub Security Advisory with a CVE alongside a patched release. The team is small, so allow for a slower cycle than a vendor programme, and hold detail until the advisory and the release 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