bmcweb

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. bmcweb 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 9 Last 12 months 30 Lifetime Auth bypass 30 % Access control 25 % Memory safety 25 % Parsing/validation 15 % Latest advisories Loading the feed Overview bmcweb is the Redfish and web front end of OpenBMC, the network-facing surface of a baseboard management controller. A BMC sits on a management network with full out-of-band control of the host below it: power, console, virtual media and firmware flashing, all of it beneath the operating system and invisible to anything running there. OpenBMC is deployed at scale by Meta, Google, IBM and Microsoft on OCP designs, by Nvidia for Bluefield and DGX management, and by Ampere and Inspur. One authentication bypass in bmcweb is a datacentre-wide, below-the-OS compromise. Read the CVE counts as an upper bound: NVD indexes them against OpenBMC as a whole. OpenBMC pays nothing for a vulnerability report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope OpenBMC takes security reports for the whole project at [email protected] , and this page covers bmcweb, its network-facing component. Everything in the bmcweb tree is inside that, and Google's patch money covers the bmcweb repository alone The Redfish REST API in full: URI routing, JSON request parsing, and the OData response builders that serialise the machine's own state back out Authentication and session management across HTTP Basic, session tokens, cookies and the mTLS client-certificate path Role-based privilege enforcement between the ReadOnly, Operator and Administrator roles, the only thing separating a monitoring account from a power-control one The embedded web server in full: connection handling, HTTP/1.1 parsing, chunked encoding, and the multipart form handling used for firmware upload Every WebSocket endpoint, including the KVM and Serial-over-LAN proxies that hand a remote client the host's console The firmware-update (UpdateService) path end to end, by which an image reaches flash, along with the checks that are supposed to gate it The boundary where bmcweb turns a request into a call into the rest of OpenBMC on the caller's behalf Out of scope The rest of the OpenBMC distribution, meaning the Yocto layers and the phosphor-* daemons, unless separately integrated into OSS-Fuzz, since projects/openbmc does not exist Vendor BMC forks, which is the practical limitation here: most shipped BMCs are AMI MegaRAC or a vendor derivative rather than upstream bmcweb Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail Crash-only one-liners that silence a non-exploitable abort without closing a class of defect Patches over twelve months old, which fall outside the program's age window Patches the bmcweb maintainers decline, since the reward is contingent on the merge rather than on the idea Most-valued findings Unauthenticated access to a Redfish endpoint that should require a session. Authentication bypass is 30% of this component's bug profile, and on a BMC one bypass is out-of-band control of the host Privilege confusion between ReadOnly, Operator and Administrator, where a monitoring credential reaches power control, virtual media or the update service Flaws in the UpdateService multipart handler that let an image be written to flash without the checks the design assumes Memory corruption in the HTTP/1.1 or multipart parser reachable pre-authentication, since bmcweb is C++ and the parser runs before any identity is established Authorisation gaps on the KVM and Serial-over-LAN WebSocket proxies, which expose the host console rather than the BMC's own data Structural hardening of the routing and privilege layer that closes a family of these at once, rather than a single endpoint fix 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. A vulnerability report on its own earns nothing there Submit the patch to the bmcweb 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 The covered object on the patch rail is the bmcweb component rather than the OpenBMC distribution: only repositories with their own OSS-Fuzz integration qualify Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the OpenBMC security team through [email protected] , which triages for the whole project rather than for bmcweb alone. Allow for the fact that server vendors rebase and re-ship BMC firmware on their own release trains. 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