Incorrect Privilege Assignment

Draft Base
Structure: Simple
Description

This vulnerability occurs when a system mistakenly grants a user, process, or entity a specific permission or privilege they should not have. This error creates an unintended level of access, allowing the actor to perform actions beyond their intended authority.

Extended Description

Incorrect privilege assignment is a core authorization flaw where the system's security model fails to properly enforce the principle of least privilege. Instead of granting the minimum access necessary for a function, the system erroneously provides elevated rights—such as administrative capabilities, write access to sensitive files, or the ability to modify other users' data. This mistake often stems from misconfigured access control lists (ACLs), flawed role-based access control (RBAC) logic, or errors during user/role provisioning. From a developer's perspective, this vulnerability is frequently introduced during code deployment or user management, rather than within the core application logic itself. Common scenarios include copying permission sets from high-privilege accounts, incorrectly mapping users to roles, or failing to validate inherited permissions. To prevent this, always implement explicit privilege assignment, audit permission changes, and use automated tools to verify that access controls match the intended security policy before deployment.

Common Consequences 1
Scope: Access Control

Impact: Gain Privileges or Assume Identity

A user can access restricted functionality and/or sensitive information that may include administrative functionality and user accounts.

Potential Mitigations 2
Phase: Architecture and DesignOperation
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Phase: Architecture and DesignOperation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Demonstrative Examples 3

ID : DX-97

The following example demonstrates the weakness.

Code Example:

Bad
C
c

/* do some stuff /

c

ID : DX-142

The following example demonstrates the weakness.

Code Example:

Bad
Java
java

// privileged code goes here, for example:* System.loadLibrary("awt"); return null;

java

ID : DX-108

This application sends a special intent with a flag that allows the receiving application to read a data file for backup purposes.

Code Example:

Bad
Java
java

Code Example:

Attack
Java
java
Any malicious application can register to receive this intent. Because of the FLAG_GRANT_READ_URI_PERMISSION included with the intent, the malicious receiver code can read the user's data.
Observed Examples 4
CVE-1999-1193untrusted user placed in unix "wheel" group
CVE-2005-2741Product allows users to grant themselves certain rights that can be used to escalate privileges.
CVE-2005-2496Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.
CVE-2004-0274Product mistakenly assigns a particular status to an entity, leading to increased privileges.
References 1
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Affected Resources
  1. System Process
Taxonomy Mapping
  • PLOVER
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • The CERT Oracle Secure Coding Standard for Java (2011)