This is a sprintf stack overflow in the formwrlSSIDset function on the Tenda W6-S, triggered by unbounded 'GO' and 'index' parameters copied into a 64-byte stack buffer. The endpoint is network-exposed and requires no authentication. CVSS 9.8 is warranted — this is textbook pre-auth remote code execution material.
The EPSS score of 0.00295 should not comfort you. That metric reflects observed exploitation through honeypots and network telemetry — instrumentation that largely does not cover consumer IoT deployments behind residential NATs and consumer routers. Tenda devices are not being actively scanned for this vulnerability because they sit in network segments nobody is instrumenting. Low EPSS here is evidence of a measurement blindspot, not evidence of safety.
What matters more than the CVE details is the pattern: this is the same vulnerability class Tenda has shipped repeatedly across product generations. sprintf overflows in pre-auth network handlers are not a surprise in 2026 — static analysis catches this reliably. The fact that it shipped suggests either no tooling, no review, or deliberate acceptance of known risk. Given the track record, the third option is the most plausible.
For defenders: assume similar flaws exist in other functions on this firmware image. Network-segment Tenda devices; do not trust them at the perimeter. The patch deployment rate on consumer Tenda hardware is effectively zero — these devices run until they fail. Your response is isolation, not patching.
The deeper question is whether coordinated disclosure is the right tool for a vendor with this track record. Each CVE treats the symptom. The disease is a firmware development pipeline that produces the same flaw class repeatedly. That may warrant escalation beyond standard disclosure timelines — not because this specific CVE is exceptional, but because the disclosure mechanism has already been tested against this vendor and failed.