arduino-esp32 CVE-2026-42855

Requires that the target device runs the arduino-esp32 WebServer library with Digest authentication enabled and configured for per-resource (per-URI) access control - the vulnerability only matters when different protected URIs are meant to have distinct authorization. The attacker must first obtain at least one valid Digest response computed for some URI in the realm (i.e. hold or capture credentials for one resource); a completely credential-less attacker cannot forge the response. Limiting factors: reachable HTTP interface, Digest (not Basic or unauthenticated) auth in use, and possession of one valid digest response; deployments using a single shared credential for all endpoints gain no additional access from the bypass and are effectively unaffected in practice.

The NVD vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N yields 7.5 (High), but the PR:N (unauthenticated) rating conflicts with the description: to produce a 'valid digest response' the attacker must already possess valid credentials for at least one protected URI, which is functionally a low-privilege authenticated position - this looks like per-resource privilege escalation, not fully unauthenticated access, so PR:L is more defensible (flagged for vendor verification). Corroborating signals are muted: EPSS is 0.04% (13th percentile), SSVC records Exploitation: none and Technical Impact: partial, and no POC or KEV listing exists - so this is a real but low-urgency issue rather than an imminent mass-exploitation threat. The one aggravating factor is SSVC Automatable: yes, meaning replay could be scripted at scale once an attacker has any foothold credential. On balance: legitimate to patch, but not an emergency for most deployments, and the confidentiality-only impact (C:H, I:N, A:N) likely understates real risk on devices where protected endpoints trigger physical actuation (potential integrity impact).

An attacker who has been granted (or has sniffed) a valid Digest response for a low-sensitivity endpoint such as /status captures that Authorization header. They then send a request to a higher-value protected endpoint such as /admin or /gpio, reusing the same digest response but with the target URI on the request line. Because the server validates the hash against the header's URI field rather than the requested resource, the request is accepted, granting access the attacker was never authorized for; no public POC is currently identified but the technique is trivially scriptable.