Acceptance of Extraneous Untrusted Data With Trusted Data

Draft Base
Structure: Simple
Description

This vulnerability occurs when a system processes both trusted and untrusted data together, but fails to separate them. The application incorrectly treats all incoming data—including the untrusted portion—with the same level of trust as the legitimate data.

Extended Description

Think of this like receiving a sealed, trusted package along with an unvetted, open package from an unknown sender. If you treat both packages as equally safe without inspection, you risk introducing malicious content. In technical terms, this often happens when an application accepts a data structure (like a serialized object, JSON, or HTTP request) that contains a mix of validated and unvalidated fields, but the processing logic fails to distinguish between them, applying trust uniformly across the entire dataset. To prevent this, developers must implement strict data segregation and validation at the point of processing. Never assume that because part of a data stream is authorized, all accompanying data is safe. Always validate, sanitize, or reject any extraneous data elements that are not explicitly required for the current operation, ensuring trust boundaries are explicitly enforced for each data field.

Common Consequences 1
Scope: Access ControlIntegrity

Impact: Bypass Protection MechanismModify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.

Observed Examples 2
CVE-2002-0018Does not verify that trusted entity is authoritative for all entities in its response.
CVE-2006-5462use of extra data in a signature allows certificate signature forging
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • PLOVER
  • The CERT Oracle Secure Coding Standard for Java (2011)