Qihoo 360 Router EUVD-2026-116670

The flaw is in the verify_sign function of fs2/bin/iscm, the Firmware Signature Verification component, on Qihoo 360 router models D621-2, D603-2, D600-2, D619, D606-6 and D706 up to version 6.4.9; exploitation involves manipulating the 'sign' argument so a cryptographic signature is improperly verified. Per the CVSS vector (PR:N/UI:N) no authentication or user interaction is indicated and the attack is described as remote, but the available sources do NOT describe how the manipulated input reaches verify_sign remotely, so the concrete network-facing trigger (which service, port, or update interface) is unconfirmed. Limiting factors: affected only through 6.4.9 on the listed models; no fixed version is published because the vendor did not respond; and exploit maturity is proof-of-concept (E:P) with the PoC not verified as working code.

Signals are mostly aligned toward elevated priority but rest on a single source. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes remote, low-complexity, unauthenticated reachability with high impact to both the vulnerable and subsequent systems, and the vuln.today Decision label is act_now, which forbids any 'patch later' framing. CWE-347 (improper cryptographic signature verification) on a firmware-verification routine is architecturally serious because it can defeat the device's trust anchor. However, the corroborating signals are thin: no EPSS score is provided, the CVE is NOT on the CISA KEV list, and the exploit maturity in the vector is only E:P (proof-of-concept), consistent with the input stating the PoC is a reference that is not verified as working exploit code. The entire record originates from one reporter (VulDB) with no vendor acknowledgement - the vendor was contacted and did not respond. The description also does not state the trigger mechanism (how 'manipulation of the argument sign' is delivered remotely), so whether true network-reachable unauthenticated exploitation holds in default configurations is not established by the evidence and should be verified against the actual device attack surface. Net: treat as a high-priority issue per the act_now label and critical CVSS, but recognize the confidence is limited by single-source reporting, absent EPSS/KEV corroboration, and an undescribed trigger path.

An attacker reachable over the network supplies a manipulated 'sign' argument to the verify_sign function in fs2/bin/iscm, causing the device to accept a firmware image whose cryptographic signature is not properly validated. This could let the attacker get tampered or unsigned firmware accepted as legitimate, undermining the device's integrity. A public PoC reference exists but is not verified as working exploit code, and the exact remote trigger path is not described in the available sources.