Insecure Default Credentials vulnerability in NI grpc-device when TLS configuration is not present

NI's grpc-device is a gRPC façade that exposes National Instruments hardware driver APIs (DAQ, scopes, signal generators, switches) to remote clients so engineers can script and share lab instruments. The flaw is configuration-by-omission: if the operator does not supply server_cert, server_key, and root_cert in the server config, the daemon silently starts in plaintext, no-auth mode. Any client that can reach the listening port (default 31763) can issue driver calls — meaning *control of attached physical hardware*, raw memory access on some boards, and in certain driver paths, code execution on the host. All shipped versions of grpc-device prior to a TLS-enforcing release are affected; this is a design default, not a regression.

Vendor scored it CVSS 9.1 CRITICAL (AV:N/AC:L/PR:N/UI:N → C:H/I:H/A:N) under the assumption that an internet-reachable instance equals full read/write on the device API. That math is correct in isolation but ignores deployment reality: grpc-device runs on engineering test benches, on lab subnets, on PXI chassis controllers — not on internet-facing tiers. Shodan/Censys exposure for port 31763 is negligible. The vendor severity overstates real-world risk for ~95% of installs. It is still legitimately concerning where the host is dual-homed or where the lab network bridges to corporate AD.

Why this verdict

• Vendor baseline is fair on paper but wrong on population: AV:N/PR:N earns 9.1, but the affected component lives on lab subnets with effectively zero internet footprint — first downward pressure.
• Friction — network position: exploiting requires reachability to a non-standard port (31763) on a host that is rarely routed; attacker must already be inside the lab segment or have a foothold in corp with east-west visibility.
• Friction — weaponization gap: there is no Metasploit module, no public weaponized PoC, and post-exploit value is bounded by what the attached hardware can do (signal generation, switching) rather than data or credentials.
• Role multiplier: low-value role (test bench / engineer workstation) — chain succeeds; blast radius caps at hardware misuse and local code execution on the engineer's box. This is the modal deployment.
• Role multiplier: typical role (shared lab / CI hardware-in-the-loop runner) — chain succeeds; blast radius extends to disrupting test pipelines and tampering with HIL results. Still bench-scoped.
• Role multiplier: high-value role (manufacturing-line PXI controller, OT-adjacent test cell, dual-homed lab → corp) — chain succeeds and blast radius reaches production-test integrity or corp pivot. This role is a minority (<10%) of installs and not canonical for the component, so it lifts the verdict OFF an IGNORE floor but does not pin it to HIGH. If your shop runs grpc-device on a production line or OT-adjacent fixture, escalate this CVE to HIGH locally — the global verdict cannot.
• No KEV, no in-the-wild, low EPSS — no time pressure beyond the noisgate MEDIUM track.

Why not higher?

HIGH would require either a credible high-value deployment role at ≥10% of the installed base (grpc-device is not a hypervisor, IdP, PAM, backup, edge, or CA — it's an instrument bus) or active exploitation evidence. Neither exists. The unauthenticated-network vector looks scary in CVSS but the reachable population is dozens of hosts globally.

Why not lower?

LOW or IGNORE is wrong because the bug is real, the default is genuinely unsafe, and there are non-zero deployments where grpc-device sits on a manufacturing line or on a dual-homed host. Misconfigured instances do exist and the fix is a config change you should make — not something to leave on the backlog forever.

1. Bind grpc-device to localhost only where remote access is not required — Edit the server config to server_address: 127.0.0.1:31763. Eliminates the remote attack surface entirely. Apply within the noisgate MEDIUM track — i.e., bundle into your next lab-host config sweep; no mitigation SLA applies, so move under the 365-day remediation window.
2. Enforce the full TLS triplet (server_cert, server_key, root_cert) on every grpc-device instance that must accept remote calls — Issue certs from your internal PKI, set root_cert to require client certs (mTLS), and verify the server refuses to start in plaintext mode. This is the vendor-blessed mitigation. Complete within the 365-day remediation window; sooner if hosts are dual-homed.
3. Firewall port 31763 (and any custom grpc-device ports) at the lab-VLAN edge — Default-deny inbound from corp and internet to lab; default-deny outbound from lab to corp except for explicit jump-host paths. This survives operator config drift on individual lab hosts.
4. Inventory grpc-device instances — Run nmap -p 31763 --script=banner across lab subnets; cross-check against an asset list of NI driver hosts. You likely don't know how many you have.
5. Subscribe to NI security advisories and pin the grpc-device commit — Track the upstream repo for the planned hardening release that refuses plaintext bind on non-loopback addresses.

Run this from an auditor workstation that has network reach to the candidate lab host. Requires grpcurl installed (brew install grpcurl or download the release binary). Invoke as ./check-ni-grpcdevice.sh <target-host> [port] — example: ./check-ni-grpcdevice.sh labhost-07.lab.corp 31763. No elevated privileges needed; this is an unauthenticated network probe.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-9142 NI grpc-device plaintext default
# Exits: 0 VULNERABLE, 1 PATCHED, 2 UNKNOWN

set -u
HOST="${1:-}"
PORT="${2:-31763}"

if [[ -z "$HOST" ]]; then
  echo "usage: $0 <host> [port]" >&2
  exit 2
fi

if ! command -v grpcurl >/dev/null 2>&1; then
  echo "UNKNOWN: grpcurl not installed" >&2
  exit 2
fi

# Step 1: TCP reachability
if ! (exec 3<>/dev/tcp/"$HOST"/"$PORT") 2>/dev/null; then
  echo "UNKNOWN: $HOST:$PORT not reachable"
  exit 2
fi
exec 3<&- 3>&-

# Step 2: try plaintext reflection — if it answers, TLS is off
PLAIN_OUT=$(grpcurl -plaintext -connect-timeout 5 "$HOST:$PORT" list 2>&1)
if echo "$PLAIN_OUT" | grep -qiE 'nidevice|ni\.|grpc\.reflection'; then
  echo "VULNERABLE: $HOST:$PORT answered plaintext gRPC reflection (TLS not enforced)"
  echo "--- services ---"
  echo "$PLAIN_OUT"
  exit 0
fi

# Step 3: try TLS — if it answers, TLS is enforced
TLS_OUT=$(grpcurl -insecure -connect-timeout 5 "$HOST:$PORT" list 2>&1)
if echo "$TLS_OUT" | grep -qiE 'nidevice|ni\.|grpc\.reflection'; then
  echo "PATCHED: $HOST:$PORT enforces TLS"
  exit 1
fi

echo "UNKNOWN: $HOST:$PORT did not return a recognizable grpc-device response"
echo "plaintext: $PLAIN_OUT"
echo "tls: $TLS_OUT"
exit 2

Sources

1. NI grpc-device — Server Security Support wiki
2. ni/grpc-device GitHub repository
3. gRPC Authentication documentation
4. Trend Micro — How Unsecure gRPC Implementations Can Compromise APIs
5. IBM PTC — gRPC Security Best Practices
6. CWE-306: Missing Authentication for Critical Function
7. Datadog — Avoid insecure gRPC connection
8. CISA KEV Catalog