The 1-byte heap overflow in luci-lib-px5g's DER signature encoding is triggered specifically when a 2040-bit RSA key produces a 255-byte signature requiring 2-byte DER length encoding—the allocator anticipated only 1-byte length fields. Standard key sizes (1024, 2048, 4096) produce signatures of 256 or 512 bytes and never hit this code path. This is a textbook happy-path bug: the developer encoded for the common case and the standard's edge case went untested.
But the vulnerability is almost secondary. OpenWRT removed luci-lib-px5g from master rather than patching it, which signals that the library is considered dead code. This creates the real exposure: openwrt-18.06 through openwrt-25.12 remain permanently vulnerable with no clear upgrade path, because the luci applications that depend on certificate generation presumably still need some library to call. The removal decision—regardless of whether it was the right call—made patching on active release branches impossible without either finding a replacement or breaking luci functionality.
Three things the CVSS 6.6 doesn't capture. First, the blast radius: the create_selfsigned() Lua binding means the trigger isn't a network packet—it's a UI action through any luci app exposing certificate creation (captive portals, OpenVPN, web interface SSL). Second, deployed firmware: removal from master doesn't remove compiled binaries from images already flashed to devices that will never be updated. Third, the temporal gap: the "fix" already happened, potentially years before this CVE was published. The exposure window runs backward from that removal decision, not forward from disclosure.
If you're defending OpenWRT deployments: check whether your specific version includes luci-lib-px5g and whether any luci applications expose certificate generation functionality. If they do, treat the device as having a reachable attack surface despite the medium severity rating—the practical risk depends on whether an attacker can trigger non-standard key generation, which is far easier through a web interface than through network traffic. For long-term remediation, the question isn't how to patch luci-lib-px5g—it's whether luci applications have migrated to an alternative library, and if so, what that migration path is.