fix(security): run the connection test's local CLI probe only for local callers (GHSA-jmq6-8j86-8xqj)

[diegosouzapw]

⚠️ base-red inherited: #14963

Fixes GHSA-jmq6-8j86-8xqj (reported by @zer0d4y5).

Problem

For cline / qoder connections, testSingleConnection() calls getCliRuntimeStatus(), which spawns sh -c 'command -v -- "$1"' on the host. That is the LOCAL_ONLY capability that Hard Rules #15/#17 keep away from non-local callers. Three remotely reachable routes run it:

• POST /api/providers/{id}/test (the one in the report);
• POST /api/providers/test-batch;
• the background test after POST /api/providers.

None of them is in LOCAL_ONLY_* or SPAWN_CAPABLE_*. On an instance with requireLogin=false, an anonymous remote caller could trigger the spawn and learn whether the CLI is installed. As the reporter says, this is not command injection: the tool id comes from a fixed map and is passed as an argv element.

Fix: gate the probe, not the route

Adding only /test to the local-only lists would leave test-batch and provider creation open. It would also remove the "Test connection" button from tunnel-served dashboards for every provider. Instead:

• getRequestPeerLocality(request) in src/shared/utils/apiAuth.ts returns loopback | lan | remote. It uses the same trusted signals, in the same order, as isLoopbackRequest(), which now delegates to it with identical verdicts. It fails closed to remote, and client-supplied locality headers are not trusted.
• The three routes pass allowLocalRuntimeProbe = locality !== "remote", which matches the LOCAL_ONLY semantics (loopback or private LAN, never through a reverse proxy).
• Remote callers get the upstream connection test without the local CLI diagnosis. The credential-health scheduler, which runs inside the server, keeps the probe (the default is true).

The reporter's other suggestion, a build-time check that derives spawn reachability and fails when a route reaches a spawn sink without being gated, would have caught this class earlier. It is worth doing as its own change; it is not part of this fix.

Validation

• tests/unit/provider-test-local-runtime-probe.test.ts, 5 cases:
  • a remote caller never calls the probe (the test injects a spy);
  • local and scheduler callers do;
  • the locality verdicts, including a client-supplied locality header being ignored when a stamping server is in front;
  • a source guard on the three call sites.
  • All 5 fail on the old code.
• Existing suites stay green: provider-401-ambiguous-runtime, verified-connection-activation-11446, docker-bootstrap-loopback-14296, v1-models-keyless-loopback-13354 (20 tests).