[FD] bmcweb (OpenBMC web server): four vulnerabilities — two unfixed, GHSA without a CVE

[binreaper via Fulldisclosure <fulldisclosure@xxxxxxxxxxxx>]

Hi all,

Posting a brief summary of a four-finding disclosure on bmcweb (the OpenBMC 
HTTP/Redfish web server), which ships in BMC firmware on most modern enterprise 
servers — Intel, IBM, HPE, NVIDIA, and various ODMs.

Full timeline and analysis on the blog:

  https://binreaper.pages.dev/posts/2026-05-27-bmcweb-disclosure/

## Why bmcweb matters

A Baseboard Management Controller boots before the host CPU, has full control 
over the server (power, firmware, console, in some configurations DMA), and is 
reachable from the management network. bmcweb is OpenBMC's HTTP front door — 
Redfish API, web UI, KVM/console WebSocket. C++23 on Boost.Beast, 
single-threaded async, supports HTTP/1.1 and HTTP/2.

The single-threaded design means any blocking operation, large allocation, or 
event-loop stall takes the entire management interface offline.

## The four findings

All reported 2026-02-23 to openbmc-security@xxxxxxxxxxxxxxxx.

| ID | Title | CVSS | Status |
|----|-------|------|--------|
| CONN-F2 | `Expect: 100-continue` bypasses body_limit (pre-auth OOM) | 7.5 | 
FIXED — commit `0b2049b0` (2026-04-21), GHSA-p3gc-68x5-g9w3 |
| H2-F2 | HTTP/2 `Content-Length` trusted for `std::string::reserve()` (instant 
OOM) | 7.5 | FIXED — commit `62526bb0` (2026-04-21), silent (no advisory) |
| H2-F1 | HTTP/2 no body_limit per stream (pre-auth OOM via streamed DATA 
frames) | 7.5 | UNFIXED — Gerrit 90580 today |
| AUTH-F6 | mTLS UPN suffix matching authenticates parent-domain / TLD-only 
certs | 6.8 | UNFIXED — Gerrit 90581 today |

## Three things worth flagging to this audience

1. **GHSA-p3gc-68x5-g9w3 has no CVE attached** (`cve_id: null`). It is not in 
NVD, OSV, the GitHub global Advisory Database, or any distro security tracker 
that I checked. From a downstream-propagation perspective, the GHSA exists only 
on the bmcweb security tab. The upstream maintainer's 2026-05-14 reply: "As far 
as I'm aware, there will be no CVE assigned for this."

2. **One of two coordinated 2026-04-21 patches got an advisory; the other 
didn't.** CONN-F2 (the HTTP/1.1 bug) got GHSA-p3gc. H2-F2 (the HTTP/2 sibling, 
same severity band, fix landed in the same minute) got no advisory at all. 
Anyone applying bmcweb 3.0.0 because of the published advisory gets the H2-F2 
fix as a side effect but doesn't know it.

3. **Intel firmware containing the unpatched binary is still on Intel's 
Download Center.** M50FCP BMC 2.94-0 (Download Center ID 775817), dated January 
2026, predates the upstream fix. I submitted CONN-F2 to Intel's bug bounty 
program (Intigriti); triage accepted the scope, then closed out-of-scope under 
an "open-source projects we contribute to" clause five hours later, despite the 
submission being explicitly about the vendor-distributed binary.

## H2-F1 (unfixed, posted today)

bmcweb's HTTP/1.1 path inherits its body limit from Boost.Beast's parser; the 
HTTP/2 path does not. `HttpBody::reader::put()` in `http/http_body.hpp` appends 
incoming DATA-frame bytes to `value.str()` (a `std::string`) with no size 
check. Authentication runs in `onRequestRecv()` on END_STREAM — i.e., after the 
full body has been received and buffered. nghttp2 auto-replenishes flow-control 
windows by default; bmcweb does not set 
`nghttp2_option_set_no_auto_window_update`.

Result: any client that can complete the TLS handshake (ALPN h2 is the default 
protocol path) can stream unlimited DATA frames before authentication is ever 
attempted. The single-threaded event loop dies from OOM.

Suggested fix in Gerrit 90580 
(https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90580): per-stream byte counter 
on `HttpBody::reader`, bound at the existing `BMCWEB_HTTP_BODY_LIMIT` (30 MiB 
by default).

## AUTH-F6 (unfixed, posted today)

`isUPNMatch()` in `http/mutual_tls.cpp` performs domain suffix matching when 
validating mTLS client certificates in UserPrincipalName mode. The algorithm 
walks dot-separated labels right-to-left and returns true once the UPN domain 
runs out of labels, regardless of how many hostname labels remain. The 
project's own existing unit test asserted the consequence as expected behaviour:

  EXPECT_TRUE(isUPNMatch("user@com", "hostname.region.domain.com"));

A certificate with a UPN that is just a TLD authenticates any BMC in that TLD; 
a parent-domain certificate authenticates any nested BMC. CVSS 6.8 because UPN 
mode is opt-in (default is CommonName) and requires a CA-signed client cert 
with the broad UPN.

Suggested fix in Gerrit 90581 
(https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90581): replace the walk with 
exact-match plus one-label-prefix tolerance (preserves `user@xxxxxxxxxx` 
matching `bmc-01.domain.com`; rejects deeper nesting).

## Disclosure status

Maintainer-side track is closed per Ed Tanous's 2026-05-14 reply ("This bug is 
no longer embargoed, and the fix is on master. There's no longer a reason to 
send direct messages to the security responders. If you believe further action 
is needed, please use the normal project communication channels."). Earlier 
today the H2-F1 and AUTH-F6 disclosures went to openbmc@xxxxxxxxxxxxxxxx with 
their respective Gerrit changes. This Full Disclosure post is the 
broader-audience signal.

Reproducers exist for CONN-F2 and H2-F1 (Python; pocs/bmcweb/ in my files). I 
am not attaching them; happy to share with downstream vendor PSIRTs or fork 
maintainers on request.

Best regards,
binreaper
bobdabot@xxxxxxxxx

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/