libcoap

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, not for the report. libcoap sits in Tier 2, which caps at $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be no more than twelve months old, submissions are rate-limited to three per person per month, and sanctions and territory exclusions apply. CVE history 12 Last 12 months 16 Lifetime Memory safety 40 % Parsing/validation 35 % Denial of service 20 % Latest advisories Loading the feed Overview libcoap is the most widely used C implementation of CoAP (RFC 7252), the constrained-device REST protocol that replaces HTTP where HTTP is too heavy. It ships inside Zephyr, RIOT, Contiki-NG and ESP-IDF, inside the LwM2M stacks that provision a large share of cellular IoT and smart metering, and inside industrial and building-automation gateways. CoAP endpoints are routinely exposed on UDP with little or no authentication, putting this parser on the attack surface of devices that are rarely patched. The CVE record makes the point: twelve of the sixteen lifetime CVEs were published in the last twelve months. The project pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The project takes security reports through the address in its SECURITY.md and asks for a working reproducer; a report that merely suggests a file may be vulnerable under certain conditions is refused. Nothing narrower than the library itself is carved out, and everything below is inside it CoAP message parsing in full: the option parser, token handling and the header walk that runs on every datagram before anything else in the library sees it Block-wise transfer (Block1/Block2) reassembly, where an attacker controls both the fragment sizes and their arrival order Observe subscription state handling and resource registration, where a peer can drive the server's own bookkeeping The DTLS integration layers against OpenSSL, GnuTLS, Mbed TLS and TinyDTLS, including session resumption, which is libcoap's own glue rather than the TLS libraries beneath it OSCORE (Object Security for Constrained RESTful Environments) processing, the end-to-end protection layer that is meant to survive an untrusted proxy Proxy and multicast handling, where one crafted message can be amplified or relayed into a network the sender could not reach directly Out of scope The underlying TLS libraries themselves. OpenSSL, GnuTLS, Mbed TLS and TinyDTLS all have their own payers, and only libcoap's integration code is in scope here Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail Crash-only one-liners: a fix that silences a non-exploitable crash without closing a class of defect does not clear the top of the reward ladder Patches over twelve months old, which fall outside the program's age window Reports that merely suggest a file may be vulnerable under certain conditions, which the maintainers reject outright Patches the libcoap maintainers decline, since the reward is contingent on the merge rather than on the idea Most-valued findings Structural hardening of the block-wise reassembly path that closes a whole family of length and offset defects at once. Memory safety is 40% of this project's bug history, the block-wise code is where it concentrates, and most of the recent CVE record has landed there Remote memory corruption in the option or token parser reachable from a single unauthenticated UDP datagram, before any DTLS session exists Bounds and state hardening in OSCORE processing, where a bug defeats the one layer designed to hold up across an untrusted proxy Session-resumption and state-machine confusion in the DTLS integration glue that lets one peer take over or replay another's session Amplification and relay abuse through the proxy and multicast paths, which turn a small library on a small device into a network-wide problem 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. The cash on Google's rail is paid for a merged upstream patch rather than for a vulnerability report. A report on its own earns nothing there Submit the patch to the libcoap maintainers yourself and keep it merged, without reverts, for one month before claiming Patches must be no more than twelve months old when you submit them for reward Three Patch Rewards submissions per person per month is the hard cap libcoap does not accept reports which merely suggest a file may be vulnerable under certain conditions. Bring a reproducer rather than scanner output Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the libcoap maintainers through the address in the project's SECURITY.md. 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