CVE-2026-75976

The CVE describes a CVSS 9.9 buffer overflow in TRENDnet router firmware's NVRAM handling for wan_l2tp_password — a strcpy() that copies a user-controlled L2TP password into a fixed buffer without bounds checking. That's the textbook vulnerability. What the CVE description doesn't tell you is why this matters differently than a typical stack overflow. The critical detail is the NVRAM component. This is non-volatile storage — the overflow payload persists across reboots. That reframes your entire remediation approach. If an attacker has already exploited this to plant a malicious configuration payload in NVRAM, flashing patched firmware doesn't clean the compromise. The device boots into your patched code, but the weaponized state survives. Your remediation checklist must answer two questions before you declare this resolved: does the firmware update mechanism sanitize NVRAM partitions it shouldn't be touching, or does every affected device require a factory reset to clear the persisted payload? A SOHO router isn't an endpoint — it's a chokepoint. This device handles DNS, NAT, DHCP, and often USB storage for every device behind it. Compromising this strcpy() gives an attacker a forward operating position inside the network segment. The blast radius isn't one compromised box; it's every device that trusts that router's network stack. Prioritize this CVE based on its downstream exposure, not just its CVSS score. The deeper pattern here is entropy. That strcpy() almost certainly lives in a legacy NVRAM module that every developer avoids touching — something labeled vendor_sdk/legacy/nvram_handling.c that no one wants to break. The code wasn't written insecurely out of negligence; it was written once, never reviewed again, and avoided until something broke publicly. This is the structural reality of embedded firmware: unsafe patterns persist not because developers ignore warnings, but because the SDK provides no safe alternatives and the cost of understanding legacy components exceeds the cost of leaving them alone. Your practical steps: verify whether the firmware patch clears NVRAM or merely patches the code path. If it doesn't clear NVRAM, factor in a factory reset as part of remediation. Treat this as a chokepoint compromise with downstream exposure — the patched firmware doesn't fully remediate the fleet if the weaponized state survives in deployed devices.

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