- Top reward
- $7,500
- Top severity paid
- Not published
- Assets in scope
- 9
- Public CVEs
- 90
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $7,500
- top reward.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 7 days
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
Sorona does not publish a reward table for this program.
- Response
-
Within 7 days
Give the security team time to respond (acknowledgement typically within 7 days) before escalating or going public
- 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
9 assets you may test, 6 excluded.
Web 1
- https://go.dev
Products and areas 8
- Cryptographic weaknesses such as practical key recovery, constant-time failures, or signature and certificate-validation bypass in crypto/tls and crypto/x509
- Defects in the Go toolchain itself: the gc compiler, the linker and assembler, the go command, and go vet
- Leaked credentials, sensitive write-access keys, or insecure configuration in Go's own repositories, which the OSS VRP treats as a standing top priority
- Parser and resource-handling flaws reachable through importable packages: algorithmic-complexity or decompression-bomb denial of service, stack exhaustion from recursive parsing, XSS in html/template, and argument or PATH injection via os/exec
- Path-traversal and filepath-handling flaws, including Windows-specific behavior in path/filepath
- Security bugs in the Go standard library that break a documented security property, spanning crypto/*, encoding/*, net/http, path/filepath, os/exec, syscall, archive/*, and the rest of the stdlib, reported to the Go security team
- Supply-chain exposure across Go project infrastructure: the module proxy (proxy.golang.org), the checksum database (sum.golang.org), the vulnerability database tooling (vuln.go.dev), and Go's build and release infrastructure
- Vulnerabilities in the golang.org/x/... sub-repositories that are part of the Go project (for example x/crypto, x/net, x/text, x/tools)
Out of scope (6)
- Automated scanner or fuzzer output submitted without triage, a reproducer, or root-cause analysis
- Bugs that are not actually present in a Go package (misattributed user-code issues)
- Denial-of-service or panics with no security-relevant impact beyond a crash, and issues that only affect Go releases already fixed in the two most recent major versions
- Findings already subsumed by an entry in the Go vulnerability database, or documented as expected behavior in Go's published vulnerability-classification decisions
- Third-party or non-Go-project code; report those upstream first
- Vulnerabilities in Go applications or non-importable code, including anything in package main or an installable command, which sit outside the Go vulnerability database's scope
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 first.
-
Report privately to the Go security team; keep the write-up succinct with a clear description, exploitation method, and a reproduction test case
-
For memory-corruption reports on flagship projects, provide OSS-Fuzz reproduction steps against an existing fuzz target or a merged patch
-
State the affected Go version and confirm the issue reproduces on a currently supported release
-
One root-cause vulnerability per report; do not combine unrelated findings
-
Avoid attachments where possible; inline the proof of concept and steps
-
Give the security team time to respond (acknowledgement typically within 7 days) before escalating or going public
Not accepted
-
Vulnerabilities in Go applications or non-importable code
-
Bugs that are not actually present in a Go package
-
Findings already subsumed by an entry in the Go vulnerability database
-
documented as expected behavior in Go's published vulnerability-classification decisions
-
Third-party or non-Go-project code
-
Denial-of-service or panics with no security-relevant impact beyond a crash
-
issues that only affect Go releases already fixed in the two most recent major versions
-
Automated scanner or fuzzer output submitted without triage, a reproducer, or root-cause analysis
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 90 CVEs, 22 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 sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Product vulnerabilities (a security bug in Go's own code), Google OSS VRP tier OT0 │ $500 - $7,500 │ $625 - $8,500 Supply-chain compromise of the repository or release pipeline, tier OT0 │ $3,133.70 - $31,337 │ $3,916.70 - $32,337 Other security issues, tier OT0 │ $1,000 │ $1,250 Submit a vulnerability CVE history 22 Last 12 months 90 Lifetime Denial of service 45 % Code execution 20 % Auth bypass 15 % Info disclosure 12 % Latest advisories Loading the feed Overview Go is Google's open-source programming language together with its compiler, toolchain, and standard library, underpinning huge swaths of cloud and infrastructure software. It already runs a paid bounty via Google's Open Source Software VRP, where Go is a flagship project earning the top reward tiers, and it operates a mature security team with coordinated disclosure and CVE assignment. Route your report through sorona.xyz and we pay 1.25x whatever that program awards, plus up to $1,000 more for especially complex or well-chained bugs. In scope Security bugs in the Go standard library that break a documented security property, spanning crypto/, encoding/, net/http, path/filepath, os/exec, syscall, archive/*, and the rest of the stdlib, reported to the Go security team Defects in the Go toolchain itself: the gc compiler, the linker and assembler, the go command, and go vet Vulnerabilities in the golang.org/x/... sub-repositories that are part of the Go project (for example x/crypto, x/net, x/text, x/tools) Cryptographic weaknesses such as practical key recovery, constant-time failures, or signature and certificate-validation bypass in crypto/tls and crypto/x509 Parser and resource-handling flaws reachable through importable packages: algorithmic-complexity or decompression-bomb denial of service, stack exhaustion from recursive parsing, XSS in html/template, and argument or PATH injection via os/exec Path-traversal and filepath-handling flaws, including Windows-specific behavior in path/filepath Supply-chain exposure across Go project infrastructure: the module proxy (proxy.golang.org), the checksum database (sum.golang.org), the vulnerability database tooling (vuln.go.dev), and Go's build and release infrastructure Leaked credentials, sensitive write-access keys, or insecure configuration in Go's own repositories, which the OSS VRP treats as a standing top priority Out of scope Vulnerabilities in Go applications or non-importable code, including anything in package main or an installable command, which sit outside the Go vulnerability database's scope Bugs that are not actually present in a Go package (misattributed user-code issues) Findings already subsumed by an entry in the Go vulnerability database, or documented as expected behavior in Go's published vulnerability-classification decisions Third-party or non-Go-project code; report those upstream first Denial-of-service or panics with no security-relevant impact beyond a crash, and issues that only affect Go releases already fixed in the two most recent major versions Automated scanner or fuzzer output submitted without triage, a reproducer, or root-cause analysis Most-valued findings Vulnerabilities that lead to supply-chain compromise of the Go project's repositories or its module, proxy, and checksum infrastructure (the OSS VRP's highest-priority category) Remote code execution reachable through a Go stdlib or toolchain package Cryptographic key recovery, certificate-validation bypass, or authentication bypass in crypto/tls and crypto/x509 Leaked credentials or sensitive write-access / package-manager keys for Go project infrastructure OSS-Fuzz-reproducible memory-safety and crash bugs in Go project code, where OSS-Fuzz reproduction against an existing target is accepted as higher-quality proof Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Report privately to the Go security team; keep the write-up succinct with a clear description, exploitation method, and a reproduction test case For memory-corruption reports on flagship projects, provide OSS-Fuzz reproduction steps against an existing fuzz target or a merged patch State the affected Go version and confirm the issue reproduces on a currently supported release One root-cause vulnerability per report; do not combine unrelated findings Avoid attachments where possible; inline the proof of concept and steps Give the security team time to respond (acknowledgement typically within 7 days) before escalating or going public Disclosure Coordinated disclosure via the Go security team, which triages on PUBLIC, PRIVATE, and URGENT tracks, assigns CVEs, and targets a fix or public disclosure within 90 days. Do not disclose publicly before the coordinated release; premature disclosure can forfeit the reward. 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