Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

LLVM / Clang

By sorona.xyz Bug bounty on Sorona llvm.org

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
10
Public CVEs
9
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.
Replies within 2 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.

Severity Reward
Critical $1,500+
High $700+
Medium $300+
Low $100 $100 / 1 month Claude Max
Response
Within 2 days The Security Response Group targets acknowledgement within two business days
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

10 assets you may test, 6 excluded.

Web 1

  • https://llvm.org

Products and areas 9

  • Anything in the project running with more privilege than the person who invoked it, or crossing a privilege boundary the caller expected to hold
  • Clang itself where a defect reaches past compile time into the produced binary rather than stopping at a crash
  • Code generation across every back end and every target, where the emitted binary is more exploitable than the source called for
  • compiler-rt in full: the runtime support the compiler links into finished programs, which is the surface the policy actively points reporters at
  • libc++ and libc++abi, standard library code running inside a very large share of shipped C++ software
  • lldb and the debug information it consumes
  • lld, the linker, covered by this entry and the default on Android. A linker creates output, so it sits on the stronger side of the tools distinction that runs through this whole category
  • MLIR and Flang, both part of the same tree and covered by the same process
  • The policy takes reports across the whole LLVM project through a dedicated advisory repository, then narrows on what counts. Its own framing is that most miscompilations are ordinary bugs, and that one qualifies when there are clear indications the produced binary becomes significantly easier to exploit
Out of scope (6)
  • Arbitrary code execution inside LLVM from a maliciously crafted C, Rust or bitcode input file, ruled out in the policy by name
  • Bugs in clang, clangd or a JIT's optimizer caused by untrusted input. The policy states these parts were never hardened and does not treat them as security sensitive
  • Incorrect use of LLVM's APIs by a calling project
  • Miscompilations with no clear indication that the produced binary became significantly easier to exploit, which the policy treats as ordinary correctness bugs
  • Sanitizer defects. The policy states most sanitizers are not considered security sensitive
  • Unwinding and exception handling

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.
  • File through GitHub private vulnerability reporting on the dedicated repository, github.com/llvm/llvm-security-repo . It is not the main llvm/llvm-project repo
  • For a miscompilation the bar is explicit and high: clear indications that the produced binary is significantly easier to exploit.
  • Do not report crashes from a crafted C, Rust or bitcode input file.
  • That publication clock belongs to the group, so hold the detail until they open the advisory.

Not accepted

  • Bugs in clang, clangd or a JIT's optimizer caused by untrusted input
  • Arbitrary code execution inside LLVM from a maliciously crafted C, Rust or bitcode input file
  • Sanitizer defects
  • Unwinding and exception handling
  • Incorrect use of LLVM's APIs by a calling project
  • Miscompilations with no clear indication that the produced binary became significantly easier to exploit

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.

Search NVD
CVESeverityPublished
CVE-2023-29932 Medium 5.5 5 May 2023
CVE-2023-29933 Medium 5.5 5 May 2023
CVE-2023-29934 Medium 5.5 5 May 2023
CVE-2023-29935 Medium 5.5 5 May 2023
CVE-2023-29939 Medium 5.5 5 May 2023
CVE-2023-29941 Medium 5.5 5 May 2023
CVE-2023-29942 Medium 5.5 5 May 2023
CVE-2023-26924 Medium 5.5 27 Mar 2023
CVE-2014-2893 Low 1.9 23 Apr 2014

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 10 Last 12 months Memory safety 45 % Compiler correctness 25 % Denial of service 20 % Info disclosure 10 % Latest advisories Loading the feed Overview LLVM is the compiler infrastructure under an enormous amount of shipped software. Clang is the system compiler on macOS, iOS and Android, the back end generates code for Rust, Swift, Mesa and most GPU and machine-learning stacks, and lld is Android's default linker. LLVM's policy declines the obvious targets: it states the parts that take untrusted input were never hardened. It points instead at the runtime libraries the project ships into production binaries, where a defect in compiler-rt or libc++ runs inside everybody's software long after the compile ended. The response group is staffed from four companies that all run paid programmes, yet LLVM pays nothing. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy takes reports across the whole LLVM project through a dedicated advisory repository, then narrows on what counts. Its own framing is that most miscompilations are ordinary bugs, and that one qualifies when there are clear indications the produced binary becomes significantly easier to exploit compiler-rt in full: the runtime support the compiler links into finished programs, which is the surface the policy actively points reporters at libc++ and libc++abi, standard library code running inside a very large share of shipped C++ software lld, the linker, covered by this entry and the default on Android. A linker creates output, so it sits on the stronger side of the tools distinction that runs through this whole category Code generation across every back end and every target, where the emitted binary is more exploitable than the source called for lldb and the debug information it consumes MLIR and Flang, both part of the same tree and covered by the same process Clang itself where a defect reaches past compile time into the produced binary rather than stopping at a crash Anything in the project running with more privilege than the person who invoked it, or crossing a privilege boundary the caller expected to hold Out of scope Bugs in clang, clangd or a JIT's optimizer caused by untrusted input. The policy states these parts were never hardened and does not treat them as security sensitive Arbitrary code execution inside LLVM from a maliciously crafted C, Rust or bitcode input file, ruled out in the policy by name Sanitizer defects. The policy states most sanitizers are not considered security sensitive Unwinding and exception handling Incorrect use of LLVM's APIs by a calling project Miscompilations with no clear indication that the produced binary became significantly easier to exploit, which the policy treats as ordinary correctness bugs Most-valued findings Memory-safety defects in compiler-rt and libc++, the surface the policy explicitly points at. These ship into production binaries and carry ordinary library risk inside software that never chose to depend on them A miscompilation with a demonstrated exploitability delta. Show that the emitted binary is significantly easier to attack than the source implies, since that is the exact bar the policy sets Optimisation that deletes or weakens a security check the source actually wrote, the clearest way to meet that bar lld defects that alter the produced executable, since a linker creates the artifact everyone ships Anything crossing a privilege boundary in a component that runs inside a build or CI pipeline with credentials attached Runtime library defects reachable from data a finished program receives, since that is where a compiler bug turns into an application vulnerability 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. File through GitHub private vulnerability reporting on the dedicated repository, github.com/llvm/llvm-security-repo . It is not the main llvm/llvm-project repo The Security Response Group targets acknowledgement within two business days Issues become public after roughly fourteen weeks, so plan for a long embargo that ends on the group's clock rather than yours For a miscompilation the bar is explicit and high: clear indications that the produced binary is significantly easier to exploit. Without that argument it is an ordinary bug Do not report crashes from a crafted C, Rust or bitcode input file. The policy states those parts of LLVM were never hardened and rules the class out by name There is no reward. LLVM pays nothing, and none of the member companies' VRPs scope upstream LLVM Disclosure Handled by the LLVM Security Response Group, roughly twenty-five engineers drawn from Apple, Google, ARM and Red Hat, through GitHub private vulnerability reporting on a dedicated repository. Acknowledgement is targeted at two business days and issues are published after about fourteen weeks. That publication clock belongs to the group, so hold the detail until they open the advisory. 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