Multiple Vulnerabilities in On Semiconductor’s Quantenna Line of Chipsets
On Semiconductors is a semiconductor company based out of Arizona that has several product lines used in everything including consumer products, automotive, medical, and even military and aerospace. In 2019, they acquired a company by the name of Quantenna that made Wi-Fi SoC’s used in many access points and routers including those used by telecoms in customer deployments. These chips are interesting not only because of the sometimes-unique ways in which they are deployed inside devices, but also because they are ARC-based, which is not an architecture I run into very often. While Quantenna chipsets are not as common today as they once were, On Semiconductor is still developing new versions of this line, such as their QCS-AX2 and QCS-AX3 chips.
QCSAPI RPC Service
One thing that all the chips in this line have in common is a software development kit (SDK) that includes a build system and several proprietary binaries. This is a fairly common practice for chip makers, especially in cases where the chips are sufficiently complex. After all, if you want different vendors to adopt your chipset in their ecosystems, you need to make the development process as easy and efficient as possible. These types of SDK’s are a very tempting target for attackers, as any vulnerabilities discovered are likely to impact every device from every vendor that incorporates the affected chipsets. As such, I always keep an eye out for any services that are included as part of an SDK when investigating a device. In the case of the Quantenna line of chips, there is a binary called qcsapi that is used for configuring and debugging the Wi-Fi interface. It has hundreds of commands that you can run such as get_firmware_version, flash_image_update, get_SSID, get_PSK, enable_wps_push_button, and many more. This binary can be called locally but is also able to run over TCP or UDP as an RPC service. In these cases, the service spawns on a random port and registers itself with the portmapper service as libtirpc. The qcsapi RPC protocol is composed of some header bytes followed by the command and arguments in plaintext separated by 4-byte length fields.
Vulnerabilities
One of the many commands that can be run via the qcsapi RPC service immediately jumped out as a good place to investigate for potential vulnerabilities – run_script. Of course, this command doesn’t allow just any command to be run. There is a whitelist of eleven scripts that are intended only for limited debugging purposes. However, I very quickly found that several of these scripts were vulnerable to command injection. This was the first place I looked, and I had already found seven distinct vulnerabilities. For example, here is the contents of the transmit_file script that is one of the whitelisted commands:
As you can see, the transmit_file command takes two arguments, intended to be the name of the file to be transmitted and the IP address to transmit it to. However, no validation is done on either of the arguments before they are used in a call to tftp, so an attacker can inject whatever command they would like to run instead into one of the arguments and hijack execution flow. And because this service runs as the root user, the injected command will be run as root as well leading to complete device takeover.
In addition to this, it was found that telnet logins were passwordless by default. This was done intentionally to “ease customer product development”. On Semiconductors recommends customers disable telnet in the build options when deploying their chips. However, it seems that even in cases where telnet has been disabled in the build, it is still present in the deployed system and can be re-enabled by simply running the S42inetd init script. And since I had already found multiple ways to run any command I wanted using the previously mentioned vulnerabilities, it was trivial to obtain a full, remote, passwordless root shell on any device that uses a Quantenna chipset with the qcsapi RPC service enabled.
Disclosure and Vendor Response
In April of this year, On Semiconductors was contacted and provided details of all of these discovered vulnerabilities. After some initial back and forth, On Semiconductors drafted a security best practices document in lieu of any patches or fixes. They are confident that this document, if followed properly, adequately addresses all the issues I uncovered, although I am inclined to disagree. As there are no patches available to address these issues, it becomes even more imperative for vendors to track what services and binaries are present in the devices they release. This demonstrates the importance of secure development cycles and adequate SBOM tracking solutions, not just in the case of Quantenna chipsets, but in every instance of a chip that comes from an outside source.
The vulnerabilities mentioned above can be tracked as CVE-2025-3459, CVE-2025-3460, CVE-2025-3461, CVE-2025-32455, CVE-2025-32456, CVE-2025-32457, CVE-2025-32458, and CVE-2025-32459.