Skip to content

OpenThread

Bug bounty on Sorona openthread.io

Accepting reports open-source
Top reward
$7,500
Top severity paid
Not published
Assets in scope
9
Public CVEs
3
Last change
No changes yet

At a glance

What to know before you start testing.

Pays up to $7,500
top reward.
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.

Sorona does not publish a reward table for this program.

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, 9 excluded.

Web 1

  • https://openthread.io

Products and areas 8

  • 6LoWPAN header compression and decompression, fragment reassembly, and the mesh forwarding built on top
  • Google's open-source VRP takes security issues in the latest versions of the code held in the repositories it lists, and openthread/openthread is named in the published tier file at TIER_OT0: a product vulnerability anywhere in the stack's own code is accepted, at $500 to $7,500
  • Mesh Link Establishment and the whole network formation flow: joining, commissioning, the Joiner and Commissioner roles, the DTLS handshakes underneath them, and the network key, key rotation, Thread Domain material and Operational Dataset they establish
  • Repository configuration and the release pipeline, which Google prices under its separate supply-chain category
  • The application protocols the stack terminates: CoAP and CoAPS, the SRP client and server, DNS-SD resolution, the Border Agent, and the border-routing features
  • The IEEE 802.15.4 layer: MAC frame parsing, MAC security and key handling, the CSL and receive paths, and everything that runs on a frame the radio picks up before anyone has authenticated
  • The IPv6 stack the project ships: address configuration and resolution, ICMPv6, UDP, multicast forwarding, and the routing logic between mesh nodes
  • The POSIX platform layer with its daemon and CLI surfaces, the NCP and RCP spinel interface between host and radio co-processor, and the public otXxx API a vendor SDK ports against
Out of scope (9)
  • Attacks that require the Thread network credential the attacker was already given, since that is inside the trust boundary
  • Defects that only reproduce on a release the project no longer ships, since the program covers the latest versions
  • Memory-corruption reports submitted without exact OSS-Fuzz reproduction steps against an existing fuzz target, or a merged upstream patch
  • Other repositories in the openthread org, which the tier file does not list and which pay nothing for a product vulnerability after the April 2026 rules update
  • Physical-layer and RF jamming attacks, which the protocol does not claim to defend against
  • Reports filed by anyone other than the finder: Google wants the submission through bughunters.google.com under the researcher's own identity, and it does not pay Google or Google Partner employees
  • Rewards to researchers on a sanctions list, in a sanctioned territory, or located in Russia or Belarus, which Google states it cannot issue
  • Silicon-vendor radio drivers and closed platform layers, which belong to the chip vendor rather than to OpenThread
  • Third-party Thread stacks and vendor forks that are not listed in Google's repository tier file

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.
  • Memory-corruption reports need exact OSS-Fuzz reproduction steps or a merged patch
  • Attacks that assume the attacker was already given the Thread network credential are inside the trust boundary and are not eligible
  • Only openthread/openthread is in scope; vendor forks and third-party Thread stacks are not in Google's tier file
  • Frame the report accurately: a bug in the project's own code is a product vulnerability, while compromise of the repository or release pipeline is a separate and differently priced supply-chain category
  • Google's reward panel sets the amount at its discretion within the published band, so the tier ceiling is a maximum rather than an expectation
  • Google's rules state that privately disclosing a flaw to a third party, for any purpose other than fixing it, will typically not qualify for a reward

Not accepted

  • Physical-layer and RF jamming attacks
  • Attacks that require the Thread network credential the attacker was already given
  • Memory-corruption reports submitted without exact OSS-Fuzz reproduction steps against an existing fuzz target, or a merged upstream patch
  • Defects that only reproduce on a release the project no longer ships
  • Reports filed by anyone other than the finder

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-2021-33889 Medium 6.8 2 Jul 2021
CVE-2020-8916 Medium 5.0 7 Jul 2020

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 vulnerability (Tier OT0; supply-chain compromise is a separate category) │ $500 - $7,500 │ $625 - $8,500 Other security issue (Tier OT0 flat award) │ $1,000 │ $1,250 Submit a vulnerability CVE history 1 Last 12 months 3 Lifetime Memory safety 45 % Parsing/validation 30 % Denial of service 15 % Auth bypass 8 % Latest advisories Loading the feed Overview OpenThread is the reference implementation of the Thread networking protocol and the mesh layer underneath Matter, the smart-home interoperability standard. It runs on Google Nest hubs, thermostats and speakers, on Apple HomePod and Apple TV acting as Thread border routers, on Amazon Echo devices, and inside the Thread radios that Nordic, Silicon Labs, NXP and Texas Instruments ship into an enormous range of third-party smart-home products. The attack surface is radio-adjacent and pre-authentication: MLE and 6LoWPAN reassembly parse frames from anything within RF range, so a memory-safety bug here is a proximity-triggered code-execution primitive on devices sitting inside people's homes, on hardware that updates slowly if at all. Google rates it Tier OT0 on the Open Source Software VRP, where a product vulnerability runs from $500 to $7,500 and a discretionary panel decides where in that band a finding lands. sorona.xyz adds 1.25× on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Google's open-source VRP takes security issues in the latest versions of the code held in the repositories it lists, and openthread/openthread is named in the published tier file at TIER_OT0: a product vulnerability anywhere in the stack's own code is accepted, at $500 to $7,500 The IEEE 802.15.4 layer: MAC frame parsing, MAC security and key handling, the CSL and receive paths, and everything that runs on a frame the radio picks up before anyone has authenticated 6LoWPAN header compression and decompression, fragment reassembly, and the mesh forwarding built on top The IPv6 stack the project ships: address configuration and resolution, ICMPv6, UDP, multicast forwarding, and the routing logic between mesh nodes Mesh Link Establishment and the whole network formation flow: joining, commissioning, the Joiner and Commissioner roles, the DTLS handshakes underneath them, and the network key, key rotation, Thread Domain material and Operational Dataset they establish The application protocols the stack terminates: CoAP and CoAPS, the SRP client and server, DNS-SD resolution, the Border Agent, and the border-routing features The POSIX platform layer with its daemon and CLI surfaces, the NCP and RCP spinel interface between host and radio co-processor, and the public otXxx API a vendor SDK ports against Repository configuration and the release pipeline, which Google prices under its separate supply-chain category Out of scope Silicon-vendor radio drivers and closed platform layers, which belong to the chip vendor rather than to OpenThread Physical-layer and RF jamming attacks, which the protocol does not claim to defend against Attacks that require the Thread network credential the attacker was already given, since that is inside the trust boundary Third-party Thread stacks and vendor forks that are not listed in Google's repository tier file Memory-corruption reports submitted without exact OSS-Fuzz reproduction steps against an existing fuzz target, or a merged upstream patch Other repositories in the openthread org, which the tier file does not list and which pay nothing for a product vulnerability after the April 2026 rules update Defects that only reproduce on a release the project no longer ships, since the program covers the latest versions Reports filed by anyone other than the finder: Google wants the submission through bughunters.google.com under the researcher's own identity, and it does not pay Google or Google Partner employees Rewards to researchers on a sanctions list, in a sanctioned territory, or located in Russia or Belarus, which Google states it cannot issue Most-valued findings Pre-authentication memory corruption in 6LoWPAN fragment reassembly or 802.15.4 frame parsing, reachable from RF range with no credential: the largest expected class at 45% and the finding that reaches the top of the band A malformed MLE message that corrupts state or executes code during joining or commissioning, since that path is exposed to any radio in range by design Any flaw that lets an unjoined device obtain or derive the Thread network key, which converts proximity into full mesh membership Memory corruption in CoAPS/DTLS handling or the SRP server on a border router, where the attacker reaches the device from the IP network rather than from RF range Frame or message parsing bugs in the NCP/RCP spinel interface, which sits between the host stack and radio firmware and is rarely treated as untrusted 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. Memory-corruption reports need exact OSS-Fuzz reproduction steps or a merged patch, which is materially harder on embedded C/C++ than on a file-format parser and is the main reason reports stall here Attacks that assume the attacker was already given the Thread network credential are inside the trust boundary and are not eligible Only openthread/openthread is in scope; vendor forks and third-party Thread stacks are not in Google's tier file Frame the report accurately: a bug in the project's own code is a product vulnerability, while compromise of the repository or release pipeline is a separate and differently priced supply-chain category Google's reward panel sets the amount at its discretion within the published band, so the tier ceiling is a maximum rather than an expectation Google's rules state that privately disclosing a flaw to a third party, for any purpose other than fixing it, will typically not qualify for a reward Disclosure Coordinated through Google Bug Hunters, which triages the report, lands the fix upstream and publishes on its own schedule with researcher credit. Because Google treats a private disclosure to a third party as grounds for disqualification, file with Google directly, and give the fix real time to propagate: silicon vendors and device makers have to pick it up and ship firmware before anything in the field is protected. 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