CAPEC-109
Object Relational Mapping Injection
An attacker leverages a weakness present in the database access layer code generated with an Object Relational Mapping (ORM) tool or a weakness in the way that a developer used a persistence framework to inject their own SQL commands to be executed against the underlying database. The attack here is similar to plain SQL injection, except that the application does not use JDBC to directly talk to the database, but instead it uses a data access layer generated by an ORM tool or framework (e.g. Hibernate). While most of the time code generated by an ORM tool contains safe access methods that are immune to SQL injection, sometimes either due to some weakness in the generated code or due to the fact that the developer failed to use the generated access methods properly, SQL injection is still possible.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-109: Object Relational Mapping Injection: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/109.html and https://cve.bz/cve/capec/109?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
[Determine Persistence Framework Used] An attacker tries to determine what persistence framework is used by the application in order to leverage a weakness in the generated data access layer code or a weakness in a way that the data access layer may have been used by the developer.
1 technique
- An attacker provides input to the application in an attempt to induce an error screen that reveals a stack trace that gives an indication of the automated data access layer used. Or an attacker may simply make some educated guesses and assume, for instance, that Hibernate is used and try to craft an attack from there.
[Probe for ORM Injection vulnerabilities] The attacker injects ORM syntax into user-controllable data inputs of the application to determine if it is possible modify data query structure and content.
Exploit
They carry out the attack.
[Perform SQL Injection through the generated data access layer] An attacker proceeds to exploit a weakness in the generated data access methods that does not properly separate control plane from the data plan, or potentially a particular way in which developer might have misused the generated code, to modify the structure of the executed SQL queries and/or inject entirely new SQL queries.
1 technique
- An attacker uses normal SQL injection techniques and adjusts them to reflect the type of data access layer generation framework used by the application.
Prerequisites
An application uses data access layer generated by an ORM tool or framework
An application uses user supplied data in queries executed against the database
The separation between data plane and control plane is not ensured, through either developer error or an underlying weakness in the data access layer code generation framework
Skills required
- Medium skill
Knowledge of general SQL injection techniques and subtleties of the ORM framework is needed
Resources required
None: No specialized resources are required to execute this type of attack.
Consequences
| Impact | Affects | Note |
|---|---|---|
| Modify Data | Integrity | |
| Unreliable Execution | Availability | |
| Read Data | Confidentiality | |
| Gain Privileges | Confidentiality, Access Control, Authorization | |
| Execute Unauthorized Commands | Confidentiality, Integrity, Availability | Run Arbitrary Code |
Mitigations
Remember to understand how to use the data access methods generated by the ORM tool / framework properly in a way that would leverage the built-in security mechanisms of the framework
Ensure to keep up to date with security relevant updates to the persistence framework used within your application.
Weaknesses it exploits
- CWE-20 Improper Input Validation
- CWE-89 Improper Neutralization of Special Elements used in an SQL Command
- CWE-564 Use of Hibernate with HQL/SQL Query String Containing External Input
Recent CVEs with these weaknesses
- 4.9CVE-2026-105427
Improper input validation in Ivanti EPMM before version 12.10.0.1, 12.9.0.3, and 12.8.0.5 allows a remote authenticated attacker with admin privileges to permanently disable all Apache HTTPS services resulting in denial of service.
- 6.7CVE-2026-105426
Improper input validation in Ivanti EPMM before version 12.10.0.1, 12.9.0.3, and 12.8.0.5 allows a remote authenticated attacker with admin privileges to set arbitrary Linux kernel parameters as root.
- 9.6CVE-2026-108186
Improper Input Validation in Zoom Workplace for Windows may allow an unauthenticated user to conduct an escalation of privilege via network access.
- 9.8CVE-2026-121653
SQL injection in the Core of Ivanti Endpoint Manager before version 2024 SU8 allows a remote unauthenticated attacker to achieve remote code execution.
- 7.7CVE-2026-125759
Nango before 0.71.3 contains an sql injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL by supplying a crafted task group key to the orchestrator API. Attackers can send a malicious group.key to POST /v1/…
- 6.3CVE-2026-125871
The sourcecache expansion module in MISP Modules (misp-modules) contains a Server-Side Request Forgery (SSRF) vulnerability. When a user with permission to create or modify attributes of type 'link' or 'url' submits an attribute value, the…
- 7.2CVE-2026-12572
Zoho Corporation ManageEngine DDI Central version below 6201 is vulnerable to SQL injection in HA replication username handling leading to command execution as the PostgreSQL service account.
- 5.5CVE-2026-125703
A flaw was found in the GStreamer gst-plugins-bad MXF plugin. Insufficient bounds checks when parsing crafted VANC data can cause an out-of-bounds read in the demuxer, while an incorrect buffer size calculation when muxing multiple ancilla…
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-66 SQL Injection
Examples
When using Hibernate, it is possible to use the session.find() method to run queries against the database. Th…
When using Hibernate, it is possible to use the session.find() method to run queries against the database. This is an overloaded method that provides facilities to perform binding between the supplied user data and place holders in the statically defined query. However, it is also possible to use the session.find() method without using any of these query binding overloads, hence effectively concatenating the user supplied data with rest of the SQL query, resulting in a possibility for SQL injection. While the framework may provide mechanisms to use methods immune to SQL injections, it may also contain ways that are not immune that may be chosen by the developer.
MITRE's words, unchanged: CAPEC-109 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.