How Insecure Update Manifest Fetching happens in Node.js and how to fix it

The Vulnerability: One Character That Opened the Door to RCE

The server.js file in the Mineradio application handles the critical task of fetching update manifests — the metadata documents that tell the application where to download new versions of itself. A flaw at line 567 in the readUpdateManifest function meant this process could silently fall back to an unencrypted HTTP connection, handing any network-positioned attacker the ability to serve a fake update and achieve remote code execution on every affected machine.

The root cause? A single character in a regular expression: the ? that made the s in https optional.

The Vulnerability Explained

The Vulnerable Code

Here is the readUpdateManifest function as it existed before the fix:

async function readUpdateManifest(ref) {
  const value = String(ref || '').trim();
  if (!value) throw new Error('UPDATE_MANIFEST_MISSING');
  if (/^https?:\/\//i.test(value)) {   // ← BUG: accepts http:// too
    const resp = await fetch(value, {
      headers: { 'User-Agent': `Mineradio/${APP_VERSION}` },
    });
    // ...
  }
}

The regex /^https?:\/\//i uses ? to make the s optional, meaning it matches both:

• https://legitimate-update-server.com/manifest.json ✅
• http://attacker-controlled.com/manifest.json ✅

This means any caller — whether from configuration, a deep link, or a network-sourced value — could pass an http:// URL and have it accepted without complaint. The application would then fetch the manifest over a completely unencrypted TCP connection.

Why This Is Critical: The Attack Scenario

Consider the following attack chain specific to this code:

1. Initial position: An attacker gains a MITM position on the network (e.g., via a rogue Wi-Fi access point, ARP spoofing on a corporate LAN, or a compromised router). Alternatively, they obtain a TLS certificate from a rogue or compromised Certificate Authority — a real-world scenario demonstrated multiple times with DigiNotar, Comodo, and others.

2. Interception: The application calls readUpdateManifest with an http:// manifest URL. Because there is no TLS, the request travels in plaintext. The attacker intercepts it transparently.

3. Malicious manifest injection: The attacker responds with a crafted manifest.json that points to an attacker-controlled installer URL, with a matching (but fake) checksum if no signature verification is in place.

4. Installer delivery: The application calls normalizeManifestUpdateInfo (visible in the diff context at line 563) to parse the attacker's manifest, then proceeds to download and execute the trojanized installer.

5. Result: Full remote code execution under the user's account — on every machine running the affected version of Mineradio.

This is not a theoretical attack. The User-Agent header in the fetch call (Mineradio/${APP_VERSION}) even reveals the application name and version to any passive observer, making targeted exploitation trivially easy.

What Makes This Worse

• Auto-update trust: Users implicitly trust auto-update mechanisms. A malicious update that arrives silently is far more dangerous than a phishing link a user might scrutinize.
• No integrity check visible in the diff: The code fetches the manifest and normalizes it, but there is no visible cryptographic signature verification of the manifest content, meaning HTTPS enforcement is the only line of defense.
• Production code: This is not test infrastructure. The server.js file is in the production codebase and runs on every end-user machine.

The Fix

The fix is surgical and precise — a one-character change to the URL validation regex:

Before

if (/^https?:\/\//i.test(value)) {

After

if (/^https:\/\//i.test(value)) {

Removing the ? quantifier makes the s in https mandatory. Any URL that begins with http:// (without the s) will no longer match the condition, and the fetch call will never be reached. The function will fall through to whatever non-URL handling exists below, or throw an appropriate error.

Why This Change Is Sufficient (and What It Doesn't Cover)

This fix is the correct and minimal change for this specific problem:

• It rejects HTTP at the validation layer, before any network I/O occurs — the best place to stop a bad input.
• It preserves all valid behavior: any legitimate manifest URL using https:// continues to work exactly as before.
• It is not bypassable via case variation because the regex already uses the i (case-insensitive) flag, meaning HTTP://, Http://, and all other capitalizations are also rejected.

However, developers maintaining this code should be aware that HTTPS enforcement alone does not protect against:
- Compromised CAs issuing fraudulent certificates for the update server domain
- Manifest tampering if the update server itself is compromised

Defense-in-depth would add cryptographic signing of manifests (e.g., verifying an Ed25519 signature on the manifest JSON before parsing it).

Key Takeaways

• The ? in https? is a silent HTTPS downgrade: In any security-sensitive URL check, https? means "HTTP is fine too." Audit every such regex in your codebase.
• readUpdateManifest was the single point of failure: All update fetching funneled through this one function, making it both the highest-value target and the right place to add enforcement.
• Update mechanisms deserve the same scrutiny as authentication: A compromised update channel is equivalent to a compromised login — both give an attacker persistent access.
• The User-Agent header (Mineradio/${APP_VERSION}) advertised the target: Over HTTP, this header is visible to any passive observer, enabling version-targeted attacks. HTTPS hides it.
• One-line fixes can close critical attack paths: The entire RCE chain described above is broken by removing a single ? character.

How Orbis AppSec Detected This

• Source: The ref parameter passed into readUpdateManifest(ref) — an externally controllable string representing the manifest URL.
• Sink: The fetch(value, { headers: { 'User-Agent': ... } }) call at server.js:567, reached only after the insufficiently strict regex check passes.
• Missing control: No enforcement that the URL scheme is exclusively https:. The regex /^https?:\/\//i permitted plain HTTP URLs to reach the fetch call without any warning or error.
• CWE: CWE-319 — Cleartext Transmission of Sensitive Information (also related to CWE-494: Download of Code Without Integrity Check).
• Fix: The regex was tightened from /^https?:\/\//i to /^https:\/\//i, making the s in https mandatory and rejecting all non-HTTPS manifest URLs before any network request is made.

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

A single ? in a regular expression at line 567 of server.js was the difference between a secure update mechanism and a remote code execution vulnerability. The readUpdateManifest function accepted http:// URLs, meaning any attacker with a network position between the user and the update server could intercept the request, inject a malicious manifest, and deliver a trojanized installer — silently, on every affected machine.

The fix is a one-character change: removing the ? from https? so that only https:// URLs are accepted. Small changes in security-critical validation code carry outsized consequences in both directions — a single permissive character can open a critical attack path, and removing it can close it entirely.

When building or reviewing update mechanisms, treat the transport layer as a security boundary, not an implementation detail. Enforce HTTPS strictly, verify manifest signatures cryptographically, and audit every URL validation regex for accidental permissiveness.