CVE-2025-3461 is a critical flaw (CVSS 9.1) in onsemi Quantenna Wi-Fi chipsets, which ship with an unauthenticated telnet interface by default. The record lists the SDK through version 8.0.0.28 as affected and says no patch existed at publication. The fix is to disable telnet in your product build and follow the vendor best practices guide.
What's affected
The CVE record covers the Quantenna Wi-Fi chipset through version 8.0.0.28 of the latest SDK. It names several onsemi QCS-AX2 products and their firmware: QCS-AX2-A12, QCS-AX2-S5, QCS-AX2-T12 and QCS-AX2-T8.
The record also states the issue appeared to be unpatched when it was first published. No fixed version is listed. The onsemi support article on product support and security best practices is the place to check for current guidance, so confirm there before you plan around a firmware update.
The researchers who published the disclosure add an important caveat. A device is only exposed if the maker of the end product left both the telnet function and the chip's RPC service reachable. They also note that it can be hard to tell which access points and routers use this chipset, so end users often cannot work out their own exposure.
How to check if you're exposed
If you build or manage devices on this chipset, check the vendor's guidance first and then look at what the device exposes on the network.
- Ask your device or module supplier whether the product uses a Quantenna chipset and which SDK version it ships.
- From a trusted management network, scan the device for an open telnet port (TCP 23 or a custom port) using your normal port scanner.
- Review the build or configuration to see whether the telnet service and the RPC service can be started from the network side.
- Read the onsemi best practices article and compare its recommendations with your product configuration.
Do not test devices you do not own or manage. You can also run the free in-browser dependency scan at gold.safeguard.sh/scan and browse the Gold directory for related advisories.
What to do now
- Identify every product in your fleet or catalogue that uses a Quantenna Wi-Fi chipset.
- Disable the telnet function in the product build, and disable the RPC service where it is not needed.
- Keep management interfaces off untrusted networks, and segment Wi-Fi infrastructure from sensitive systems.
- Apply the recommendations in the onsemi best practices guide.
- Ask your supplier for a firmware update plan and watch the advisory for a fixed SDK release.
Why it matters
The weakness is CWE-306, missing authentication for a critical function. According to the public disclosure, the telnet login for the root account accepts a connection without a password. Anyone who can reach the service gets an administrative shell on the chip.
The CVSS vector rates the attack as network based, with no privileges and no user interaction. That is why the score is high even though real exposure depends on how the device maker configured the product. This CVE is not on the CISA Known Exploited Vulnerabilities list, and the record does not report exploitation in the wild.
Firmware that sits inside other vendors' products is hard to track. A chipset SDK flaw can show up in many brands, which is why an accurate inventory of components matters.
Quick check
Is CVE-2025-3461 fixed?
The record says it appeared unpatched at publication and no fixed version is listed. The vendor published a best practices guide for implementors. Check the onsemi article for updates.
Does every device with a Quantenna chip have this exposure?
No. The disclosure says exposure depends on whether the product maker left telnet and the RPC service reachable. Ask your supplier about your specific product.
Sources
- onsemi: Quantenna Wi-Fi product support and security best practices
- AHA! disclosure for CVE-2025-3461
Last reviewed: 18 October 2026.
