Safeguard
Application Security•

CWE-494 Download of Code Without Integrity Check: Fixes

Software that fetches and runs code without verifying it trusts the network and the host. Learn how signing and verification close the gap in updates and installers.

Safeguard Security Team
4 min read

CWE-494, Download of Code Without Integrity Check, is when a product downloads source code or an executable from a remote location and runs it without sufficiently verifying its origin and integrity. It is not language specific. Auto updaters, installers, plugin managers, build scripts and firmware update routines all fit.

This is a supply chain weakness at heart. The code you run is only as trustworthy as the path it took to reach you.

How it happens

MITRE says an attacker can run malicious code by compromising the host server, spoofing DNS, or modifying the code in transit.

# Vulnerable: runs whatever the server returns, over a channel that may be tampered with
curl -k https://updates.example.com/install.sh | sh

The -k option turns off certificate validation, so a person in the middle can swap the script. Even with validation on, nothing proves the file is the one the vendor published, because a compromised server would serve the bad file with a valid certificate.

The record lists several observed cases. CVE-2019-9534: a satellite phone does not validate its firmware image. CVE-2021-22909: a chain where a router's firmware update procedure uses curl with the insecure option, which disables certificate validation and allows an adversary in the middle attack with a malicious firmware image. CVE-2008-3438: an operating system that does not verify the authenticity of its own updates. CVE-2008-3324: an online poker client that does not verify the authenticity of its own updates.

What an attacker gains

MITRE lists execution of unauthorized code or commands, with integrity, availability and confidentiality all affected. Untrusted code can compromise program control flow, run attacker commands, read or modify sensitive resources, or stop the program from working.

How to find it

MITRE names several methods.

  • Manual analysis such as penetration testing, threat modeling and interactive tools that let a tester record and modify an active session.
  • Black box monitoring of the process as it talks to the operating system and network. This works when you lack source, did not write the software, or want to confirm the build did not introduce the problem.
  • Static analysis, which can find some instances.

For your own repositories, search build scripts, Dockerfiles and installers for curl | sh, wget without a checksum, and flags that disable certificate checks.

How to fix it

MITRE's mitigations, in plain steps.

  1. When you ship updates, sign the code with cryptographic signatures and change the download client to verify them before running anything. Code signing technologies such as Authenticode apply. Make sure the verification itself does not contain weak certificate or signature checks.
  2. Use a vetted library or framework that does integrity checking on transmitted code, rather than writing your own.
  3. Forward and reverse DNS checks can detect DNS spoofing, but MITRE calls this partial. It does not stop changes on the host or in transit.
  4. Encrypting the code before transmission is also partial. It does not detect DNS spoofing or changes on the hosting site.
  5. Run the code with the lowest privileges needed, in an isolated account, so a successful attack does not reach everything else.
  6. Where possible, run it in a sandbox or jail such as chroot, AppArmor or SELinux. MITRE rates this as limited, since it narrows the blast radius rather than preventing the attack.
# Better: pin a checksum published through a separate trusted channel
curl -fsSLO https://updates.example.com/tool-1.4.2.tar.gz
echo "<expected sha256 from the release notes>  tool-1.4.2.tar.gz" | sha256sum -c -

A checksum from the same server only helps against corruption. Signature verification against a key you already hold is stronger, since a server compromise alone cannot forge it.

Try it yourself

Signed provenance is the modern answer for build artifacts. Step through how an attestation ties an artifact to the build that made it.

Click through it at your own pace, or open it full screen.

The same question applies to packages you pull in. The free in-browser dependency scan at gold.safeguard.sh/scan needs no login, keeps the file on your machine and covers up to 100 dependencies.

Quick check

Does HTTPS alone solve this?

No. It protects the transport, but if the server is compromised it will serve malicious code over a perfectly valid connection. You need to verify the code itself, ideally with a signature.

Why is a sandbox only a partial fix?

It limits what the downloaded code can reach, but the rest of the application can still be compromised.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.