CVE-2025-44954 is a critical flaw (CVSS 9.0) in RUCKUS SmartZone. Versions before 6.1.2p3 Refresh Build ship a hardcoded SSH private key for a root equivalent account. Anyone who obtains the key can log in over SSH. Upgrade to 6.1.2p3 Refresh Build or later and limit management access.
What's affected
Per the CVE record, RUCKUS SmartZone (SZ) before 6.1.2p3 Refresh Build has a hardcoded SSH private key for a root equivalent user account. The record's product list also names a set of CommScope Ruckus access points, including the C110, E510, H320, H350, H510, M510, R320 and R510. Check CommScope's advisory to see exactly which products and builds apply to you.
The Claroty Team82 write up describes the affected product as Ruckus Virtual SmartZone (vSZ) and says Ruckus Networks has provided patches. It describes a built in user with the same privileges as root, with default public and private RSA keys in its SSH directory. Because the same key ships with every copy, anyone who holds a Ruckus device or image holds the key.
The CVSS vector uses attack complexity High, which is why the score is 9.0 and not higher. The scope is changed, meaning an attacker who gets in can affect more than the component itself.
How to check if you're exposed
Start with version. In the SmartZone web interface, the version appears in the system information area. Compare it with the fixed build named in CommScope's advisory. The record's wording is "before 6.1.2p3 Refresh Build", so anything older needs attention. Confirm the exact fixed build in the advisory rather than relying on the number alone.
Next, find out who can reach the management interfaces. From a host on each network segment, check whether SSH answers on the controller:
nmap -p 22,443 <controller-address>
Run this only against systems you own. If SSH answers from user networks, guest networks or the internet, your exposure is wider than it needs to be.
Finally, review SSH authentication logs on any system that records them, such as a syslog collector or a firewall. Public key logins to the controller from addresses that are not your administrators deserve a closer look.
What to do now
- List every SmartZone controller and virtual instance, and record the version of each.
- Read CommScope's security advisory and the CERT/CC note, and plan the upgrade to the fixed build for your release line.
- Until you have patched, restrict SSH and web management to a small set of admin addresses on a dedicated management network. Claroty recommends the same approach: limit access to wireless management environments to trusted users, using a secure protocol such as HTTPS or SSH.
- Block management ports from guest, user and internet side networks at the firewall.
- After patching, review the account list and SSH settings, and rotate administrator passwords.
- Check logs from before the patch for unexplained SSH sessions, and treat any as an incident.
- Add the controllers to your asset inventory so the next advisory finds them faster.
Why it matters
The record maps the issue to CWE-1394, use of a default cryptographic key. A key that is the same on every device is not a secret. It works like a password printed in the manual, except that it grants root level access to the system that manages your wireless network.
Wireless controllers sit in a trusted place. They hold network configuration, and they often see traffic for many sites. Compromise of one can be a foothold for much more.
Hardcoded credentials are a recurring class of flaw in network and embedded products, and they are hard to spot from outside the vendor. Keep firmware and controller software on a regular update schedule, and keep management interfaces off the open network.
You can see where a product shows up in your software inventory with Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan. The Gold directory lists related CVEs by vendor.
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2025-44954 being exploited in the wild?
The record does not report exploitation and its CISA KEV flag is false. That can change, so check the CISA catalog again before you decide how urgent this is.
Does limiting access make patching unnecessary?
No. Limiting access reduces who can reach the login service, but the key is still present until you install the fixed build. Treat it as a stopgap.
Sources
- CVE-2025-44954 on Gold
- NVD record for CVE-2025-44954
- Claroty Team82 disclosure entry for CVE-2025-44954
- Also listed in the CVE record and not retrieved: the CERT/CC note VU#613753 and a CommScope security advisory FAQ (ID 20250710).
Last reviewed: 18 October 2026.
