CVE-2023-38319 is a critical severity (CVSS 9.8) OS command injection in OpenNDS before 10.1.3: the FAS key entry in the configuration file is not sanitized, so anyone who can influence that file can run commands. Upgrade to 10.1.3 or later and restrict who can write the configuration.
What's affected
The affected product is OpenNDS, a captive portal used on routers and access points. The NVD record says versions before 10.1.3 fail to sanitize the FAS key entry in the configuration file, allowing attackers with direct or indirect access to the file to execute arbitrary operating system commands. The record is dated 2024-01-26 and scores 9.8, Critical, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
The record references the OpenNDS ChangeLog, the v10.1.3 release and Forescout's SIERRA:21 research. The release page for v10.1.3 describes fixes for multiple potential security vulnerabilities and credits an external researcher, but the entries it lists carry other CVE numbers. It does not name CVE-2023-38319. Confirm in the ChangeLog and your firmware vendor's notes that the fix is included in the build you deploy.
This is one of four OpenNDS records with the same shape, each for a different configuration entry. The sibling records are CVE-2023-38317 for the interface name, CVE-2023-38318 for the gateway FQDN and CVE-2023-38323 for the status path script. FAS is OpenNDS's forwarding authentication service, which hands the login decision to an external service.
Weakness class: CWE-78.
How to check if you're exposed
List the installed OpenNDS version and compare it with 10.1.3.
opkg list-installed | grep -i opennds
That command suits OpenWrt. On other systems use the package manager. Many access points and routers bundle OpenNDS inside vendor firmware, so also read the firmware release notes. Then find every process or tool that can write the OpenNDS configuration file, such as a web console, a cloud management agent or a provisioning script.
What to do now
- Find all devices that run OpenNDS, including ones where it is built into vendor firmware.
- Upgrade to 10.1.3 or later, or apply the firmware update that contains it.
- Limit write access to the configuration file to root and trusted management tooling.
- Review any tool that sets the FAS key value and make sure it validates input before writing.
- Check the current configuration for unexpected characters or commands in any entry.
Why it matters
The pattern is command injection by configuration. OpenNDS reads a value from its configuration file and passes it into a command that is run by a shell. If the value contains shell syntax, that syntax runs with the privileges of the OpenNDS process. On a router or access point that is commonly root.
It is tempting to treat configuration as trusted. In captive portal deployments it often is not, because values are filled in by management portals, vouchers or scripts that handle input from outside. The FAS key entry here is one of several that were not cleaned. The CVE is not on the CISA Known Exploited Vulnerabilities list, and the sources I read do not report exploitation.
OS command injection happens when a program builds a shell command from data it does not fully control. If the data contains shell syntax, the shell runs it with the program's privileges. The safe approach is to avoid the shell, pass arguments as separate values, and validate configuration values against a strict allow list before use.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan covers the dependencies a code project declares. It does not see firmware, desktop software or vendor appliances, so keep this item in your asset inventory and track the vendor's advisory.
Quick check
Is this exploitable without access to the device?
The description requires direct or indirect access to the configuration file. Anything that writes that file on behalf of a remote user is indirect access.
Is patching one of these CVEs enough?
Upgrading to 10.1.3 or later addresses the version range in the record for all four, but confirm with the ChangeLog.
Sources
Last reviewed: 19 October 2026.
