CWE-346 Origin Validation Error: Check Who Is Talking

CWE-346, Origin Validation Error, is the weakness of not properly verifying that the source of data or communication is valid. MITRE places it as a class level weakness, covering browsers, servers, web pages and file handlers alike.

If your code responds to messages, requests, updates or downloaded files, someone has to decide whether the sender is who it claims to be. When no one does, anything that can reach the interface is treated as if it came from a trusted party.

How it happens

Software exposes functionality to a particular kind of source: another page from the same site, a DNS server it asked, a file the user chose to download. The code accepts input and acts on it, but it never confirms the input really came from that kind of source.

MITRE's consequence statement puts it well: an attacker can access any functionality that is inadvertently accessible to the source. If the code trusts "whoever sent this," then the attacker becomes whoever sent this.

Three observed examples from the record show different shapes.

• CVE-2000-1218: a DNS server accepted updates from hosts it did not query, which led to cache poisoning. The server never checked that the answer came from the party it had asked.
• CVE-2018-6074: a browser did not set Mark-of-the-Web for a downloaded executable if the name was close to the maximum path length, which prevented the usual security warning on that file.
• CVE-2025-0411: a zip extraction program did not propagate Mark-of-the-Web metadata to files extracted from an archive downloaded from the internet. The extracted files lost the marker that said they came from an untrusted origin.

The second and third examples are about origin metadata being lost. The data kept its content but dropped the label saying where it came from, so later checks had nothing to act on.

What an attacker gains

MITRE lists access control impact: gaining privileges or assuming identity. In the DNS case, an attacker controls what the cache believes. In the file case, an executable from the internet runs without the warning meant for it. In the web case, a page from any origin can drive functionality meant for a trusted one.

How to find it

MITRE notes that automated static analysis can find some instances of this weakness by analyzing source code. Combine it with a review of every entry point.

• List the places your code receives messages or data from outside its own process or trust zone.
• For each, write down which sources are allowed, and where in the code that is enforced.
• If the answer is "nowhere," or "we trust the format," you have a finding.
• For file handling, check that origin markers survive every transformation, such as copying, extracting and converting.

How to fix it

MITRE lists no mitigations in the record. These steps follow from the definition.

1. Allow only the sources you expect, and compare against an explicit list, not a pattern that can be satisfied by an attacker's name.
2. Verify the origin using something the sender cannot forge, such as a cryptographic proof or a property of the connection you control.
3. Carry origin metadata along with the data, and make sure it survives processing.
4. Fail closed. If you cannot determine the origin, treat the data as untrusted.

A common web example is the browser message API. The vulnerable version accepts any message:

window.addEventListener("message", (event) => {
  applySettings(event.data);        // any page can send this
});

The fixed version checks who sent it, with an exact comparison:

const ALLOWED = "https://app.example.com";

window.addEventListener("message", (event) => {
  if (event.origin !== ALLOWED) return;   // ignore other senders
  applySettings(event.data);
});

Use an exact string match against the full origin. Checking whether the origin merely contains your domain lets an attacker register a lookalike that passes.

Quick check

Sources

• MITRE CWE-346: https://cwe.mitre.org/data/definitions/346.html