Improper Verification of Cryptographic Signature

Draft Base
Structure: Simple
Description

This vulnerability occurs when an application fails to properly check the digital signature on data, or skips the verification step entirely, allowing tampered or forged information to be accepted as legitimate.

This vulnerability occurs when an application fails to properly check the digital signature on data, or skips the verification step entirely, allowing tampered or forged information to be accepted as legitimate.
Extended Description

Cryptographic signatures are essential for verifying the authenticity and integrity of data, such as software updates, authentication tokens, or API messages. When an application doesn't validate these signatures correctly—by using the wrong key, ignoring expiration, or not checking the result—attackers can inject malicious data, escalate privileges, or bypass security controls. This often happens due to misunderstood libraries, manual implementation of complex protocols, or simply overlooking the verification step after signature extraction. Detecting these flaws requires checking code paths where signatures are processed, ensuring robust key management, and using up-to-date libraries. While SAST tools can flag missing verification calls, managing this at scale across microservices and third-party dependencies is challenging. An ASPM like Plexicus helps by correlating these findings across your entire stack, and its AI can provide automated, context-aware remediation suggestions to fix the vulnerable code efficiently.

Common Consequences 1
Scope: Access ControlIntegrityConfidentiality

Impact: Gain Privileges or Assume IdentityModify Application DataExecute Unauthorized Code or Commands

An attacker could gain access to sensitive data and possibly execute unauthorized code.

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Demonstrative Examples 1
In the following code, a JarFile object is created from a downloaded file.

Code Example:

Bad
Java
java
The JAR file that was potentially downloaded from an untrusted source is created without verifying the signature (if present). An alternate constructor that accepts a boolean verify parameter should be used instead.
Observed Examples 4
CVE-2002-1796Does not properly verify signatures for "trusted" entities.
CVE-2005-2181Insufficient verification allows spoofing.
CVE-2005-2182Insufficient verification allows spoofing.
CVE-2002-1706Accepts a configuration file without a Message Integrity Check (MIC) signature.
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Taxonomy Mapping
  • PLOVER
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443
  • ISA/IEC 62443