CVE-2026-71260

The vulnerability in ESPHome's web_server component exposes plaintext passwords through a 'value' JSON field even when the entity is configured with `mode: password`. The 'state' field masks the password correctly, but a parallel serialization path ('value') returns the unmasked value—likely added to support a configuration UI that needed the raw credential for form persistence. That original use case has likely rotted away, leaving orphaned code that still outputs sensitive data with no owner who remembers why it was exempt from the masking contract. The immediate remediation is to mask the 'value' field, but that may break legitimate consumers. The deeper question is whether ESPHome should treat 'mode: password' as a security boundary rather than a display hint. A schema-level constraint that refuses to generate any JSON path containing unmasked password-mode values would make the inconsistency impossible rather than merely forbidden. The next developer who adds a new output path (WebSocket, SSE, future API) would hit a compile-time failure rather than a review gap. The CVSS 6.5 score is misleading in context. The device sits on your broadcast domain alongside laptops, NAS, and smart home hubs. The credential that leaks is often the WiFi PSK itself—an attacker with network access extracts credentials that unlock the entire subnet, not just this device. Additionally, WiFi passwords on these devices rarely rotate; a 2026 extraction may grant access through the device's operational lifetime. Check your ESPHome configurations: any entity using `mode: password` that also has a 'value' field in JSON output is affected. Review whether your web_server component actually needs the 'value' field, and consider whether the default port 80 binding with no authentication is appropriate for components that handle network credentials.

Reviewed through automated stages and approved by a human before publication.