- 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, 6 excluded.
Web 1
- https://github.com/fatedier/frp
Products and areas 10
- Configuration parsing on both sides, including the TOML loader, environment expansion and the range and include syntax
- Every proxy type the server implements: TCP, UDP, HTTP, HTTPS, STCP, SUDP, XTCP and the TCP multiplexer
- Proxy registration and the allow-list: which remote ports, subdomains and custom domains a client may claim, and whether one client can claim another's
- Server authentication in both supported modes, the shared token and the OIDC integration, plus everything that decides whether a connecting client is allowed to register anything at all
- The dashboard and the admin API on both server and client, along with their authentication and the credentials in configuration
- The frps server control plane: the client control connection, the handshake, session multiplexing and the work queue behind them
- The HTTP and HTTPS virtual-host routers, including host header matching, subdomain routing, path routing, header rewriting and the locations rules
- The project publishes no security policy and declares no scope. Private reporting is enabled on fatedier/frp and the advisory form is the stated channel, so treat the whole repository as in scope and state your own reproduction boundary in the report
- The server plugins, covering the HTTP proxy, static file serving, unix domain socket forwarding and https2http, each of which changes what an unauthenticated peer can reach
- Transport handling underneath all of it: TLS between client and server, the mux layer, KCP and QUIC transports, and PROXY protocol parsing
Out of scope (6)
- An operator deliberately exposing an internal service through a tunnel, which is what the product does rather than a defect
- Deployments running with no token or OIDC configured at all, where the server was told to accept anyone
- Resource exhaustion from raw connection volume against a server with no limits configured
- The security of the service on the far end of the tunnel, as opposed to frp's handling of the traffic
- Third-party forks and the many rebranded frp derivatives rather than the upstream repository
- Upstream Go library defects, unless frp's own use of the library is what makes them reachable
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 through the GitHub advisory form on fatedier/frp .
-
Do not open a public issue.
-
Say which side is affected.
-
Include the full server and client TOML configuration with secrets removed.
-
Show the attack from the position an attacker actually holds, usually an unauthenticated host that can reach the frps port and nothing else
Not accepted
-
An operator deliberately exposing an internal service through a tunnel, which is what the product does rather than a defect
-
Deployments running with no token or OIDC configured at all, where the server was told to accept anyone
-
The security of the service on the far end of the tunnel, as opposed to frp's handling of the traffic
-
Resource exhaustion from raw connection volume against a server with no limits configured
-
Third-party forks and the many rebranded frp derivatives rather than the upstream repository
-
Upstream Go library defects, unless frp's own use of the library is what makes them reachable
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 Access control 40 % Auth bypass 30 % Info disclosure 20 % Denial of service 10 % Latest advisories Loading the feed Overview frp is the reverse-proxy tunnel people reach for when a service sits behind NAT and has to be reachable anyway. The frps half runs on a public host and terminates tunnels opened by clients inside private networks, putting it on the open internet in front of everything it forwards. It is one of the most widely deployed network tools on GitHub, heavy in homelabs and across Chinese enterprise infrastructure. A defect in the server side reaches every internal service tunnelled through it at once, which is the whole point of the tool working against you. There is no vendor and no bounty, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The project publishes no security policy and declares no scope. Private reporting is enabled on fatedier/frp and the advisory form is the stated channel, so treat the whole repository as in scope and state your own reproduction boundary in the report The frps server control plane: the client control connection, the handshake, session multiplexing and the work queue behind them Server authentication in both supported modes, the shared token and the OIDC integration, plus everything that decides whether a connecting client is allowed to register anything at all Proxy registration and the allow-list: which remote ports, subdomains and custom domains a client may claim, and whether one client can claim another's The HTTP and HTTPS virtual-host routers, including host header matching, subdomain routing, path routing, header rewriting and the locations rules Every proxy type the server implements: TCP, UDP, HTTP, HTTPS, STCP, SUDP, XTCP and the TCP multiplexer The server plugins, covering the HTTP proxy, static file serving, unix domain socket forwarding and https2http, each of which changes what an unauthenticated peer can reach The dashboard and the admin API on both server and client, along with their authentication and the credentials in configuration Transport handling underneath all of it: TLS between client and server, the mux layer, KCP and QUIC transports, and PROXY protocol parsing Configuration parsing on both sides, including the TOML loader, environment expansion and the range and include syntax Out of scope An operator deliberately exposing an internal service through a tunnel, which is what the product does rather than a defect Deployments running with no token or OIDC configured at all, where the server was told to accept anyone The security of the service on the far end of the tunnel, as opposed to frp's handling of the traffic Resource exhaustion from raw connection volume against a server with no limits configured Third-party forks and the many rebranded frp derivatives rather than the upstream repository Upstream Go library defects, unless frp's own use of the library is what makes them reachable Most-valued findings Anything letting an unauthenticated peer register a proxy on frps , because a registered proxy is a route into the private network the server fronts Cross-tenant reach between clients sharing one server: one client claiming a port, subdomain or custom domain another client owns, or receiving traffic intended for it Authentication bypass in the token or OIDC path, the check standing between the open internet and the tunnel fabric Host header and routing confusion in the HTTP and HTTPS virtual-host layer, where a crafted request is delivered to an internal service the requester should never have reached Unauthenticated access to the dashboard or the admin API on either side, since the admin API on frpc reconfigures a process living inside the private network Memory-unsafe or panic-inducing input in the control-connection and mux parsers, which run before authentication completes and take the whole ingress down with them Credential exposure out of configuration handling or the dashboard, given that one frp deployment's token often gates an entire estate of tunnels 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 fatedier/frp . Private vulnerability reporting is enabled and this is the only documented private channel Do not open a public issue. The project publishes no security policy, so nothing tells a reporter to avoid the public tracker; treat that as an omission rather than permission Say which side is affected. frps is the internet-facing server and frpc is the client inside the private network, and the impact is very different Include the full server and client TOML configuration with secrets removed. Almost everything on this surface depends on which proxy types, plugins and authentication mode are enabled Show the attack from the position an attacker actually holds, usually an unauthenticated host that can reach the frps port and nothing else This is an unfunded community project. There is no reward and no reward terms to accept Disclosure Coordinated through GitHub private vulnerability reporting, published as a GitHub Security Advisory alongside a tagged release. The project sets no published timeline, so the practical embargo runs to the next release. Deployment matters here: frps instances are long-lived, rarely monitored and frequently pinned to an old version, so real exposure outlasts the fix by a wide margin. Hold the detail until the advisory is 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