Pillar weakness
Incomplete
Log in
Also known as: Authorization
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Last updated
Access control involves the use of several protection mechanisms such as: Authentication (proving the identity of an actor) Authorization (ensuring that a given actor can access a resource), and Accountability (tracking of activities that were performed) When any mechanism is not applied or otherwise fails, attackers can compromise the security of the product by gaining privileges, reading sensitive information, executing commands, evading detection, etc. There are two distinct behaviors that can introduce access control weaknesses: Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator. Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.
3,555 recorded CVEs are caused by CWE-284 (Improper Access Control), including 32 in CISA's KEV (Known Exploited Vulnerabilities) catalog. KEVs are shown first. 627 new CWE-284 CVEs have been recorded so far in 2026 (905 in 2025).
Showing 12 of 3,555 recorded CWE-284 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-284 vulnerabilitiesWhat can happen when CWE-284 is exploited.
Varies by Context
Affects: Other
Typically introduced during these phases of the software lifecycle.
Technologies
Practical mitigations for CWE-284, grouped by where in the lifecycle they apply.
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Illustrative examples from MITRE showing how the weakness appears in code.
This code temporarily raises the program's privileges to allow creation of a new user folder.
Vulnerable example
def makeNewUserDir(username):While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.
This function runs an arbitrary SQL query on a given database, returning the result of the query.
Vulnerable example
/.../
function runEmployeeQuery($dbName, $name){While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
Multiple vendors did not use any authentication or used client-side authentication for critical functionality in their OT products.
Real CVEs that MITRE cites as examples of this weakness.
CAPEC attack patterns that exploit this weakness.
Common questions about CWE-284.
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
3,555 recorded CVEs are attributed to CWE-284, including CVE-2026-48907, CVE-2025-12480, CVE-2023-27350. 32 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Exploiting CWE-284 can lead to: Varies by Context.
Yes. 32 CWE-284 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 3,555 recorded CVEs.
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Get alerted the moment a new CWE-284 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.