CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key
The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
Last updated
Overview
When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records. Database access control errors occur when: Data enters a program from an untrusted source. The data is used to specify the value of a primary key in a SQL query. The untrusted source does not have the permissions to be able to access all rows in the associated table.
Real-world CVEs
7 recorded CVEs are caused by CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key). The highest-severity and most recent are shown first. 2 new CWE-566 CVEs have been recorded so far in 2026 (3 in 2025).
- CVE-2025-9953
SQLi in Database Software's Databank Accreditation Software
Critical · CVSS 9.8 · EPSS 27th2026-02-19 - CVE-2014-0808Critical · CVSS 9.1 · EPSS 81th2014-01-22
- CVE-2026-21886
OpenCTI's GraphQL Mutations Allow Deletion of Unrelated Entities
High · CVSS 8.1 · EPSS 13th2026-03-17 - CVE-2024-22261
SQL Injection in Harbor scan log API
Medium · CVSS 5.5 · EPSS 34th2024-06-10
Common consequences
What can happen when CWE-566 is exploited.
Read Application Data, Modify Application Data, Bypass Protection Mechanism
Affects: Confidentiality, Integrity, Access Control
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
Technologies
How to prevent it
Practical mitigations for CWE-566, grouped by where in the lifecycle they apply.
Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.
Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.
How to detect it
Automated Static Analysis
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.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.
The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.
Terminology & mappings
Mapped taxonomies
- Software Fault Patterns: Tainted input to variable (SFP25)
Frequently asked questions
Common questions about CWE-566.
- What is CWE-566?
- The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
- What CVEs are caused by CWE-566?
- 7 recorded CVEs are attributed to CWE-566, including CVE-2025-9953, CVE-2014-0808, CVE-2026-21886.
- How do you prevent CWE-566?
- Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.
- How is CWE-566 detected?
- Automated Static Analysis: 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.)
- What are the consequences of CWE-566?
- Exploiting CWE-566 can lead to: Read Application Data, Modify Application Data, Bypass Protection Mechanism.
- Is CWE-566 actively exploited?
- 7 recorded CVEs are caused by CWE-566; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-566) (opens in a new tab)
- CWE-566 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-566
Get alerted the moment a new CWE-566 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.