Written by Jordan Hardy

When the air becomes the attack surface: CVE-2026-6058 and a lesson in threat modeling

When we think about “validating untrusted input”, we usually picture a text field in a web form, a login box, a URL-parameter or a JSON string sent to an API.

But what happens when input is pulled directly from the air?

This blog post describes CVE-2026-6058, a vulnerability I recently discovered in the Zyxel WRE6505 v2 Wi-Fi range extender. It is a straightforward, Medium-severity “Denial-of-Service” bug in the device’s management interface that is not weaponizable on a large scale. It does however highlight a critical lesson in threat modeling and demonstrates exactly why EU-regulators are forcing manufacturers to pay closer attention to the security of their products.

A future blog post will also go into the regulatory implications under the EU’s Cyber Resilience Act for such devices, so keep an eye out for that.

The vulnerability: untrusted input from the spectrum

The Zyxel WRE6505 v2 is a consumer-grade WiFi range extender. During setup, it scans the air to display a list of available networks (a.k.a. “SSID”s). Nothing exotic about that; your laptop does this all the time.

What is often overlooked here: the IEEE 802.11 standard that governs how these SSIDs are constructed, dictates that, (at the raw frame level, with appropriate tooling) a valid SSID could contain up to 32 bytes of arbitrary data. WiFi clients are free to interpret this data however they see fit and truncating the SSID from byte 33 onward is standard practice.

This comes with a few interesting side effects regarding assumptions on how “well-behaved” the broadcasting device is:

A wireless access point broadcasting an SSID can put any byte in there. For example, if the byte sequence is F0 9F 98 83, depending on how the client interprets  the SSID bytes, this wireless network will show up as ????, ðŸ˜ƒ or .

The 32-byte limit is dictated by the standard as in “A well-behaved access point should not be expected to broadcast an SSID of more than 32 bytes, so clients are free to ignore byte 33 and onward”. An attacker is free to put up to 255 bytes in there.

The bytes of the SSID can be arbitrarily chosen so any of those bytes can be a control character like a newline, tab and a null-byte.

Weaponization of this last point is what ultimately led to Zyxel issuing CVE-2026-6058 to me for this finding.

When the Zyxel device formats its scan results into a JSON object and sends them to the browser, it fails to correctly handle these control characters. If a nearby access point broadcasts an SSID containing a newline character (0x0A), the device injects it as a literal linebreak into the JSON object. The browser’s parser immediately rejects the malformed response, but the frontend UI does not warn the user that this has happened.

Consequently, the network discovery page is infinitely stuck on a “Scanning…” spinner. If the device is brand new, this effectively soft-bricks the device for its intended purpose. A similar thing happens when the device has already been set up: after displaying the “Scanning…” spinner for two minutes the management UI defaults to displaying an empty page. When the person managing the device wants to change the upstream network, they are effectively blocked from doing so.

An attacker simply needs to run a rogue access point nearby with a malformed SSID which is trivial using a small Raspberry Pi running hostapd. Any vulnerable device in radio range is subjected to this management-plane-DoS until the rogue device is removed. The attacker never has to authenticate or even communicate directly with the target.

What should I do when I own a Zyxel WRE6505 v2?

Since Zyxel made it very clear that this is an unsupported product and they are not intending to issue any patches for this bug, it would be counter-advisable to keep using it.

That being said, I have some food for thought:

This particular bug is unlikely to affect you unless you or someone in your household is being personally targeted.

This particular product type is usually built around the same architecture, so other WiFi range extenders may have the same issue (CVEs apply to specific products, hence CVE-2026-6058 only applies to the Zyxel WRE6505 v2). It’s not because you are using another range extender from another brand that this issue doesn’t affect you.

This is the first CVE that was ever published for the Zyxel WRE6505 v2 specifically (*). This means that the device is heavily under-researched and more vulnerabilities are likely to surface. I will definitely keep looking for them.

(*) Two side notes here :

CVE-2017-7964 was issued for the first version of the WRE6505, but that issue had been patched in the v2 release.

Other documented vulnerabilities in the WiFi protocol affect this product. Research by KU Leuven professor Mathy Vanhoef (https://www.linkedin.com/in/vanhoefm/) that led to the FragAttacks (https://www.fragattacks.com/) also applies to the Zyxel WRE6505 v2.

I responsibly disclosed this vulnerability to Zyxel PSIRT on 30 March 2026. Zyxel was very responsive and after a few rounds of technical discussion, they confirmed my findings and awarded me the CVE identifier CVE-2026-6058. While “normal” timelines for CVE disclosure are usually a lot longer, Zyxel’s lack of needing time to develop a patch was a catalyst for expedited issuing of this CVE.

About the Author:

Georges’ lifelong curiosity about ‘how stuff works’ culminated in a Master’s degree in Electro-Mechanical Engineering. With over 15 years of experience in technical and managerial roles within the biotech industry, he developed a deep proficiency in programming and a passion for cybersecurity. This unique combination of engineering logic and coding expertise makes Georges an ideal Application Security expert; he relates to the daily challenges of software developers while fully understanding the adversarial mindset of hackers. Since transitioning to AppSec in 2017, he has consulted for a wide variety of business contexts. Georges joined Toreon in 2021, where he currently serves as the Product Owner for Threat Modeling Consulting. He is also the Lead Trainer for Toreon’s globally recognized ‘Whiteboard Hacking’ training. Leveraging his background in electronics, Georges is a key member of the hardware penetration testing team, with specific expertise in threat modeling for embedded medical and non-medical devices.