Ruby (CRuby)

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 Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. Ruby sits at Tier 2, where the panel grades a merged patch from $100 for a one-liner up to $5,000 for a complicated, high-impact improvement, entirely at its discretion, and no memory-safety multiplier applies at this tier. Patches must be at least one month and no more than twelve months old, maintainers hold a veto, the panel may split the award with them, and sanctions and territory exclusions apply. Latest advisories Loading the feed Overview CRuby is the reference implementation of Ruby: the C interpreter, the virtual machine, the garbage collector and the standard library that every Rails application in production is actually running on, and the thing every gem in the ecosystem is compiled against. A defect in the interpreter core reaches every application above it at once, with no per-application mitigation available. Its HackerOne programme is the study's canonical vulnerability disclosure programme in a bounty costume: the metadata advertises bounties, the github.com/ruby/ruby scope row reads eligible_for_bounty: false , and the policy says in plain words that it offers no monetary payout for a vulnerability discovery. So the project pays nothing, and sorona.xyz pays you directly on qualified, reproduced findings. In scope Ruby takes reports through its HackerOne programme and the address in SECURITY.md, against github.com/ruby/ruby . That object is the upstream CRuby tree in full rather than any one subsystem of it The interpreter core: the virtual machine, the garbage collector and the C sources underneath them, where the memory-safety defects that make up the largest share of this project's history live The standard library as a whole, with the parsers and decoders that read untrusted bytes as its sharpest edge Deserialisation and metaprogramming paths, where structured untrusted data is rebuilt into live objects or decides what code runs The interpreter's threading machinery and the race conditions that live inside it Memory allocation and integer arithmetic across the C sources The output paths where untrusted data becomes markup or a shell argument, contextual auto-escaping included The C extension boundary that every compiled gem in the ecosystem is linked against Out of scope One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude by name along with resource-exhaustion denial of service A patch the maintainers decline: the reward panel states it will not second-guess a maintainer's decision, so an unmerged patch is worth nothing however good it is RubyGems, Rack and the wider gem ecosystem, which this study records as separate projects with no paid pathway of their own Forks and downstream repackagings of the interpreter rather than the upstream repository the OSS-Fuzz integration names Application-level bugs in code written in Ruby, as opposed to defects in the interpreter that runs it Most-valued findings Memory corruption in the interpreter core or in a C extension shipped with it, reachable from Ruby-level input. This is the largest class in the project's profile at 33% and the one with the clearest path from a script to the host process A structural fix that eliminates an error-prone pattern across the C sources rather than patching one site, which is exactly what the reward panel grades at the top of its ladder Parsing and validation flaws in standard-library decoders that take untrusted bytes, at 28% the second-largest class and the surface the fuzzers already reach Anything that turns deserialisation or metaprogramming of untrusted data into code execution, because that is the shape that reaches every Rails deployment at once Allocator hardening or integer-arithmetic cleanup work in the C core, which the Patch Rewards rules name as qualifying categories in their own right 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 Ruby's HackerOne program or the address in SECURITY.md; both are real channels and both pay nothing. The policy says verbatim that it does not offer monetary payouts for vulnerability discoveries Send a detailed, reproducible report with the script or input that triggers it, against a supported interpreter release; if we can't reproduce it, it isn't eligible Give the Ruby security team room to ship a fix before any public writeup. Releases are batched and advertised with their own advisory If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. That is a separate pathway with its own rules The Patch Rewards side is rate-limited to three submissions per person per month, requires patches at least one month and no more than twelve months old, and excludes researchers in sanctioned territories; the researcher bears their own tax liability Disclosure Coordinated with the Ruby security team, which batches fixes into scheduled point releases and publishes its own advisory with researcher credit. Publication timing follows the release, not a fixed clock, so 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