{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "bmcweb OpenBMC web",
          "vendor": "unknown",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "binreaper via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Hi all,\n\nPosting a brief summary of a four-finding disclosure on bmcweb (the OpenBMC HTTP/Redfish web server), which ships in \nBMC firmware on most modern enterprise servers \u2014 Intel, IBM, HPE, NVIDIA, and various ODMs.\n\nFull timeline and analysis on the blog:\n\n  https://binreaper.pages.dev/posts/2026-05-27-bmcweb-disclosure/\n\n## Why bmcweb matters\n\nA Baseboard Management Controller boots before the host CPU, has full control over the server (power, firmware, \nconsole, in some configurations DMA), and is reachable from the management network. bmcweb is OpenBMC\u0027s HTTP front door \n\u2014 Redfish API, web UI, KVM/console WebSocket. C++23 on Boost.Beast, single-threaded async, supports HTTP/1.1 and HTTP/2.\n\nThe single-threaded design means any blocking operation, large allocation, or event-loop stall takes the entire \nmanagement interface offline.\n\n## The four findings\n\nAll reported 2026-02-23 to openbmc-security () lists ozlabs org.\n\n| ID | Title | CVSS | Status |\n|----|-------|------|--------|\n| CONN-F2 | `Expect: 100-continue` bypasses body_limit (pre-auth OOM) | 7.5 | FIXED \u2014 commit `0b2049b0` (2026-04-21), \nGHSA-p3gc-68x5-g9w3 |\n| H2-F2 | HTTP/2 `Content-Length` trusted for `std::string::reserve()` (instant OOM) | 7.5 | FIXED \u2014 commit `62526bb0` \n(2026-04-21), silent (no advisory) |\n| H2-F1 | HTTP/2 no body_limit per stream (pre-auth OOM via streamed DATA frames) | 7.5 | UNFIXED \u2014 Gerrit 90580 today |\n| AUTH-F6 | mTLS UPN suffix matching authenticates parent-domain / TLD-only certs | 6.8 | UNFIXED \u2014 Gerrit 90581 today |\n\n## Three things worth flagging to this audience\n\n1. **GHSA-p3gc-68x5-g9w3 has no CVE attached** (`cve_id: null`). It is not in NVD, OSV, the GitHub global Advisory \nDatabase, or any distro security tracker that I checked. From a downstream-propagation perspective, the GHSA exists \nonly on the bmcweb security tab. The upstream maintainer\u0027s 2026-05-14 reply: \"As far as I\u0027m aware, there will be no CVE \nassigned for this.\"\n\n2. **One of two coordinated 2026-04-21 patches got an advisory; the other didn\u0027t.** CONN-F2 (the HTTP/1.1 bug) got \nGHSA-p3gc. H2-F2 (the HTTP/2 sibling, same severity band, fix landed in the same minute) got no advisory at all. Anyone \napplying bmcweb 3.0.0 because of the published advisory gets the H2-F2 fix as a side effect but doesn\u0027t know it.\n\n3. **Intel firmware containing the unpatched binary is still on Intel\u0027s Download Center.** M50FCP BMC 2.94-0 (Download \nCenter ID 775817), dated January 2026, predates the upstream fix. I submitted CONN-F2 to Intel\u0027s bug bounty program \n(Intigriti); triage accepted the scope, then closed out-of-scope under an \"open-source projects we contribute to\" \nclause five hours later, despite the submission being explicitly about the vendor-distributed binary.\n\n## H2-F1 (unfixed, posted today)\n\nbmcweb\u0027s HTTP/1.1 path inherits its body limit from Boost.Beast\u0027s parser; the HTTP/2 path does not. \n`HttpBody::reader::put()` in `http/http_body.hpp` appends incoming DATA-frame bytes to `value.str()` (a `std::string`) \nwith no size check. Authentication runs in `onRequestRecv()` on END_STREAM \u2014 i.e., after the full body has been \nreceived and buffered. nghttp2 auto-replenishes flow-control windows by default; bmcweb does not set \n`nghttp2_option_set_no_auto_window_update`.\n\nResult: any client that can complete the TLS handshake (ALPN h2 is the default protocol path) can stream unlimited DATA \nframes before authentication is ever attempted. The single-threaded event loop dies from OOM.\n\nSuggested fix in Gerrit 90580 (https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90580): per-stream byte counter on \n`HttpBody::reader`, bound at the existing `BMCWEB_HTTP_BODY_LIMIT` (30 MiB by default).\n\n## AUTH-F6 (unfixed, posted today)\n\n`isUPNMatch()` in `http/mutual_tls.cpp` performs domain suffix matching when validating mTLS client certificates in \nUserPrincipalName mode. The algorithm walks dot-separated labels right-to-left and returns true once the UPN domain \nruns out of labels, regardless of how many hostname labels remain. The project\u0027s own existing unit test asserted the \nconsequence as expected behaviour:\n\n  EXPECT_TRUE(isUPNMatch(\"user@com\", \"hostname.region.domain.com\"));\n\nA certificate with a UPN that is just a TLD authenticates any BMC in that TLD; a parent-domain certificate \nauthenticates any nested BMC. CVSS 6.8 because UPN mode is opt-in (default is CommonName) and requires a CA-signed \nclient cert with the broad UPN.\n\nSuggested fix in Gerrit 90581 (https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90581): replace the walk with exact-match \nplus one-label-prefix tolerance (preserves `user () domain com` matching `bmc-01.domain.com`; rejects deeper nesting).\n\n## Disclosure status\n\nMaintainer-side track is closed per Ed Tanous\u0027s 2026-05-14 reply (\"This bug is no longer embargoed, and the fix is on \nmaster. There\u0027s no longer a reason to send direct messages to the security responders. If you believe further action is \nneeded, please use the normal project communication channels.\"). Earlier today the H2-F1 and AUTH-F6 disclosures went \nto openbmc () lists ozlabs org with their respective Gerrit changes. This Full Disclosure post is the broader-audience \nsignal.\n\nReproducers exist for CONN-F2 and H2-F1 (Python; pocs/bmcweb/ in my files). I am not attaching them; happy to share \nwith downstream vendor PSIRTs or fork maintainers on request.\n\nBest regards,\nbinreaper\nbobdabot () proton me\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T07:55:58Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/May/24"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/May/24"
        },
        {
          "url": "https://binreaper.pages.dev/posts/2026-05-27-bmcweb-disclosure/"
        },
        {
          "url": "https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90580"
        },
        {
          "url": "https://gerrit.openbmc.org/c/openbmc/bmcweb/+/90581"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/May/24"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "bmcweb (OpenBMC web server): four vulnerabilities \u2014 two unfixed, GHSA without a CVE",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0375",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/May/24",
            "automated": true,
            "contentSha256": "6852b448e7d72ea2ff80ff82586b29e359572243987e20550b5e76b62591f199",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/May/24",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-05-27T10:32:42Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-11T07:55:58Z",
    "dateUpdated": "2026-09-11T07:55:58Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0375"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}