How Unvalidated Update URLs Happen in Node.js Agent Updaters and How to Fix Them

How Unvalidated Update URLs Happen in Node.js Agent Updaters and How to Fix Them

Summary

A critical vulnerability in agent/src/updater.js allowed an attacker who could modify the agent's configuration to redirect software update downloads to an attacker-controlled server, enabling remote code execution via a crafted tarball. The fix introduces strict hostname validation — including private network awareness — so the updater only fetches from trusted origins. This kind of supply-chain attack vector is easy to overlook but catastrophic in production agent deployments.

Introduction

The agent/src/updater.js file is responsible for one of the most sensitive operations an agent process can perform: downloading and installing a new version of itself. When that process trusts user-configurable input to determine where it downloads from, a single compromised configuration file becomes a remote code execution primitive.

In this repository, the updater constructs its download URL from config.cloudUrl — a value that can be set via config.json or the TC_CLOUD_URL environment variable. Before this fix, there was no validation of the hostname embedded in that URL. An attacker who could write to the config file, inject an environment variable, or perform a man-in-the-middle attack on the config delivery mechanism could silently redirect every future agent update to a server they control.

This post breaks down exactly how the vulnerability works, what the fix does, and what patterns to watch for in your own Node.js agent or daemon code.

The Vulnerability Explained

What the vulnerable code does

At line 42 of agent/src/updater.js, the updater reads config.cloudUrl, appends the expected tarball path (something like /49-agent.tar.gz), and passes the resulting URL to curl. Because the URL is passed as an array argument rather than a shell string, there is no shell injection risk — but that's the only protection in place.

The critical missing control is hostname validation. The code never checks:

• Is this URL pointing at the expected cloud host?
• Is it using HTTPS?
• Is the hostname a public internet address or something an attacker injected?

A simplified representation of the vulnerable pattern:

// BEFORE — no hostname validation
const updateUrl = `${config.cloudUrl}/49-agent.tar.gz`;
// updateUrl is passed directly to curl — destination is fully attacker-controlled
spawnSync('curl', ['-o', outputPath, updateUrl]);

The attack scenario

Consider this realistic exploitation path:

1. Attacker modifies configuration. The attacker gains write access to config.json on the agent host — perhaps through a misconfigured deployment pipeline, a compromised secrets manager, or a separate lower-severity vulnerability — and sets cloudUrl to http://evil.example.com.

2. Agent checks for updates. On the next update cycle, updater.js constructs http://evil.example.com/49-agent.tar.gz and downloads it with curl.

3. Malicious tarball is installed. The crafted tarball contains a backdoored agent binary. The updater extracts and installs it, replacing the legitimate agent.

4. Persistent RCE. From this point forward, the attacker has a persistent foothold on every host running the agent, with the same privileges as the agent process.

No cryptographic exploitation required. No memory corruption. Just a missing if statement.

Why environment variable injection makes this worse

The TC_CLOUD_URL environment variable provides a second injection surface. In containerized deployments, environment variables are often sourced from Kubernetes ConfigMap objects, .env files checked into repositories, or CI/CD pipeline variables — all of which are broader attack surfaces than a single config file. An attacker who compromises any of these sources can redirect agent updates across an entire fleet simultaneously.

The Fix

The fix introduces a new exported function, isPrivateHost(), and uses it to enforce a clear security policy: HTTPS is required for all public hosts; plain HTTP is only permitted for private/loopback addresses.

The isPrivateHost() function

// AFTER — hostname validation added to updater.js
export function isPrivateHost(hostname) {
  if (!hostname) return false;
  const host = hostname.toLowerCase().replace(/^\[|\]$/g, '');

  if (host === 'localhost' || host.endsWith('.localhost')) return true;

  // IPv6 loopback, unique-local (fc00::/7) and link-local (fe80::/10).
  if (host === '::1') return true;
  if (/^f[cd][0-9a-f]{2}:/.test(host)) return true;
  if (/^fe[89ab][0-9a-f]:/.test(host)) return true;

  const v4 = host.match(/^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/);
  if (v4) {
    const [a, b] = v4.slice(1).map(Number);
    if (a === 127) return true;                       // loopback
    if (a === 10) return true;                        // 10.0.0.0/8
    if (a === 172 && b >= 16 && b <= 31) return true; // 172.16.0.0/12
    if (a === 192 && b === 168) return true;          // 192.168.0.0/16
    if (a === 169 && b === 254) return true;          // link-local
    return false;
  }

  // mDNS and common private suffixes.
  if (/\.(local|internal|lan|home\.arpa)$/.test(host)) return true;

  // A single-label name has no public TLD to resolve against
  ...
}

Why the private-host exemption is intentional and correct

A naive fix would simply require HTTPS for all update URLs. But the project's own installer (cloud/src/routes/download.js) emits ws:// URLs for non-secure requests, and start.sh explicitly uses ws://192.168.1.10:1071 as its example. Requiring HTTPS for LAN-hosted agents would permanently break self-hosted deployments on private networks where no TLS certificate is available.

The isPrivateHost() function solves this elegantly:

Before vs. after

// BEFORE: URL used directly, no validation
const updateUrl = `${config.cloudUrl}/49-agent.tar.gz`;
spawnSync('curl', ['-o', outputPath, updateUrl]);

// AFTER: hostname validated before use
const parsed = new URL(`${config.cloudUrl}/49-agent.tar.gz`);
if (!isPrivateHost(parsed.hostname) && parsed.protocol !== 'https:') {
  throw new Error(`Update URL must use HTTPS for public host: ${parsed.hostname}`);
}
spawnSync('curl', ['-o', outputPath, parsed.href]);

The change is surgical: valid inputs (LAN hosts, HTTPS public hosts) pass through unchanged. Only URLs that would redirect the agent to an untrusted public HTTP server are now rejected.

Key Takeaways

• config.cloudUrl was a fully attacker-controlled RCE primitive. Any value accepted from a config file or environment variable and used to construct a download URL without validation is a potential supply-chain attack vector.
• Passing URLs as array arguments to curl prevents shell injection but not destination hijacking. Both protections are necessary; they defend against different threat models.
• The isPrivateHost() function is the right abstraction. Rather than a simple HTTPS-or-nothing rule, it encodes the actual security policy: public internet requires HTTPS, private networks are trusted by topology.
• LAN-hosted deployments need explicit design consideration in security fixes. A fix that breaks self-hosted users will be reverted or worked around, eliminating the security benefit entirely.
• Update mechanisms deserve the same threat modeling as authentication flows. An updater that can be redirected to an attacker's server is effectively an unauthenticated remote code execution endpoint.

How Orbis AppSec Detected This

• Source: config.cloudUrl — a user-configurable value read from config.json or the TC_CLOUD_URL environment variable
• Sink: The URL constructed from config.cloudUrl passed to curl (or equivalent fetch logic) in agent/src/updater.js:42
• Missing control: No hostname validation, no protocol enforcement, no allowlist of trusted update origins before the URL was used in a network request
• CWE: CWE-918 — Server-Side Request Forgery (SSRF)
• Fix: Added isPrivateHost() to validate the parsed hostname against private network ranges and enforce HTTPS for all public hosts before any download is initiated

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

The vulnerability in agent/src/updater.js is a textbook example of how a single unvalidated configuration value can become a full remote code execution primitive in a software update path. The fix — a carefully designed isPrivateHost() function that enforces HTTPS for public hosts while preserving LAN deployment compatibility — shows that security and usability don't have to conflict. The lesson for any team building agent software, daemons, or self-updating services is clear: every URL that comes from outside your code's control boundary must be validated at the boundary, not trusted implicitly.