Weakness (CWE)
CWE-89: Improper Neutralization of Special Elements used in an SQL Command
The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
How to prevent it (8 mitigations)
-
Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
-
Architecture and Design
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]
-
Architecture and Design, Operation
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.
Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.
-
Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
-
Implementation
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.
-
Implementation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.
Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.
When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.
-
Architecture and Design
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
-
Implementation
Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.
Source: MITRE CWE-89
13,971 results · Feed
-
Critical 10.0
Budibase before 3.40.0 SQL Injection via Unauthenticated Webhook
Budibase before 3.40.0 contains an unauthenticated SQL injection vulnerability in webhook-triggered automations with EXECUTE_QUERY steps. Attackers can POST attacker-controlled JSON to the webhook trigger endpoint to inject SQL payloads that execute with buil…
-
Critical 9.3CVE-2026-73663 Public exploit
FreePBX: Unauthenticated SQL injection in FreePBX missedcall via inbound Caller ID name leads to administrator takeover
FreePBX is an open source IP PBX. From 16.0.0 until 16.0.11 and 17.0.4, the FreePBX missedcall module places the inbound Caller ID name from crafted SIP From headers into the missedcalllog INSERT in agi-bin/missedcallnotify.php without escaping or bound param…
-
High 7.6
IBM i is Affected By SQL Injection Vulnerability in Db2 Mirror []
IBM i 7.6, 7.5, and 7.4 s vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
-
High 7.5
ASP-CMS SQL Injection via commentList.asp id Parameter
ASP-CMS contains a SQL injection vulnerability in the commentList.asp endpoint that allows unauthenticated remote attackers to inject arbitrary SQL by manipulating the id parameter in GET requests to the comment listing script. Attackers can bypass the applic…
-
High 7.5
Hongjing e-HR Unauthenticated SQL Injection via getSdutyTree
Hongjing e-HR contains an unauthenticated SQL injection vulnerability in the getSdutyTree servlet endpoint that allows remote unauthenticated attackers to access protected resources by supplying a path traversal sequence in the request URI to bypass the oauth…
-
High 8.8
Zalktis: SQL injection via partner-controlled fields in imported e-invoices
SQL injection in the Zalktis accounting application via trading-partner-controlled text fields in received electronic invoices. When importing a received e-invoice (UBL/PEPPOL) or an e-commerce export, Zalktis concatenates partner-controlled values directly i…
-
High 7.2
CMS Admin SQL Injection via db_data.php table_name Parameter
A CMS contains a SQL injection vulnerability in admin/db_data.php at line 509 that allows authenticated administrators to inject arbitrary SQL into a SHOW COLUMNS FROM statement by supplying unsanitized input through the table_name GET or POST parameter. Atta…
-
High 7.3
SourceCodester Simple Student Information System view_department.php sql injection
A vulnerability was found in SourceCodester Simple Student Information System. Affected by this vulnerability is an unknown functionality of the file app/admin/departments/view_department.php. Performing a manipulation of the argument ID results in sql inject…
-
High 8.5
WordPress Booktics plugin 1.0.22 - SQL Injection vulnerability
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Arraytics Booktics allows Blind SQL Injection. This issue affects Booktics: from n/a through 1.0.22.
-
High 7.6
WordPress MailChimp For WooCommerce plugin < 6.2 - SQL Injection vulnerability
Administrator SQL Injection in MailChimp For WooCommerce < 6.2 versions.
-
High 8.5
WordPress Reviewer plugin <= 3.14.2 - SQL Injection vulnerability
Subscriber SQL Injection in Reviewer <= 3.14.2 versions.
-
Critical 9.3
WordPress Church Admin plugin <= 5.1.1 - SQL Injection vulnerability
Unauthenticated SQL Injection in Church Admin <= 5.1.1 versions.
-
Critical 9.3
WordPress Everest Backup plugin <= 2.3.12 - SQL Injection vulnerability
Unauthenticated SQL Injection in Everest Backup <= 2.3.12 versions.
-
Critical 9.3
WordPress RealPress plugin <= 1.1.2 - SQL Injection vulnerability
Unauthenticated SQL Injection in RealPress <= 1.1.2 versions.
-
Critical 9.3
WordPress If-So Dynamic Content Personalization plugin <= 1.10 - SQL Injection vulnerability
Subscriber SQL Injection in If-So Dynamic Content Personalization <= 1.10 versions.
-
Critical 9.3
WordPress Active Products Tables for WooCommerce plugin <= 1.1.1 - SQL Injection vulnerability
Unauthenticated SQL Injection in Active Products Tables for WooCommerce <= 1.1.1 versions.
-
High 8.5
WordPress Visitor Traffic Real Time Statistics Pro plugin <= 11.10 - SQL Injection vulnerability
Subscriber SQL Injection in Visitor Traffic Real Time Statistics Pro <= 11.10 versions.
-
Critical 9.3
WordPress Listdom plugin <= 5.6.0 - SQL Injection vulnerability
Unauthenticated SQL Injection in Listdom <= 5.6.0 versions.
-
Critical 9.3
WordPress WPJAM Basic plugin <= 7.0.1 - SQL Injection vulnerability
Subscriber SQL Injection in WPJAM Basic <= 7.0.1 versions.
-
High 8.5
WordPress CubeWP plugin <= 1.1.30 - SQL Injection vulnerability
Subscriber SQL Injection in CubeWP <= 1.1.30 versions.
-
High 8.5
WordPress Do Lasso plugin <= 358 - SQL Injection vulnerability
Subscriber SQL Injection in Do Lasso <= 358 versions.
-
Critical 9.3
WordPress Web Directory Free plugin <= 1.7.13 - SQL Injection vulnerability
Unauthenticated SQL Injection in Web Directory Free <= 1.7.13 versions.
-
Critical 9.3CVE-2026-28001 Public exploit
WordPress WP Directory Kit plugin <= 1.5.4 - SQL Injection vulnerability
Unauthenticated SQL Injection in WP Directory Kit <= 1.5.4 versions.
-
High 7.5
WordPress WP Directory Kit plugin <= 1.5.4 - SQL Injection vulnerability
Unauthenticated SQL Injection in WP Directory Kit <= 1.5.4 versions.
-
High 8.8
PostgreSQL expression deparse allows SQL injection via EXTRACT argument
SQL injection in PostgreSQL EXTRACT() deparse allows an object owner to execute arbitrary SQL as a superuser via a hostile object definition. Attacks affect expression deparse consumers broadly, including pg_dump, psql commands like \sf, and any similar usage…
-
High 7.1
Budibase before 3.40.0 NoSQL Injection via MongoDB datasource
Budibase before 3.40.0 contains a NoSQL injection vulnerability in the MongoDB datasource integration where user-supplied parameters are enriched with handlebars using noEscaping: true and parsed without operator filtering. Attackers can inject MongoDB operat…
-
High 8.8
SQL Injection
Zohocorp ManageEngine Password Manager Pro versions before 13232 and ManageEngine PAM360 versions before 8552 are vulnerable to authenticated SQL injection.
-
High 7.5
Filter expression injection via forged keyset pagination cursor in Ash
Deserialization of Untrusted Data vulnerability in ash-project ash allows an unauthenticated attacker to inject a filter expression through a forged keyset pagination cursor, resulting in SQL injection or code execution depending on the data layer. Read actio…
-
High 7.6
IBM i is Affected By Multiple Vulnerabilities in SQL
IBM i 7.6, 7.5, 7.4, and 7.3 s vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
-
High 8.7
CamaleonCMS cama_contact_form Plugin Stored XSS via before_html Field
CamaleonCMS contains a stored cross-site scripting vulnerability in the cama_contact_form plugin that allows low-privileged authenticated attackers to inject arbitrary HTML by submitting unsanitized content to the before_html field through the contact form ed…
-
High 8.0
SiYuan before v3.7.4 SQL Injection via queryBlocks template
SiYuan versions before v3.7.4 contain a second-order SQL injection vulnerability in attribute-view template columns that expose the queryBlocks function, which executes raw SQL using string substitution instead of parameterized queries. Attackers can distribu…
-
High 7.1
CamaleonCMS 2.9.1 Authenticated SQL Injection via Post Slug Field
CamaleonCMS 2.9.1 contains an authenticated SQL injection vulnerability that allows authenticated attackers with post creation or editing privileges to submit a crafted slug value containing SQL syntax that the database backend evaluates as part of an inadequ…
-
Critical 9.6
Budibase: SQL Injection via `multipleStatements: true`
Budibase is an open-source low-code platform. Prior to 3.40.0, the MySQL integration component in Budibase is configured with multipleStatements: true, enabling execution of multiple SQL statements in a single query. Attackers can inject malicious SQL command…
-
Medium 4.3
IBM i is Affected By Multiple Vulnerabilities in SQL
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to modify data in certain SQL tables due to improper neutralization of special elements used in an SQL command.
-
Medium 6.5
IBM i is Affected By Multiple Vulnerabilities in SQL
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to modify SQL tables due to improper neutralization of special elements used in an SQL command.
-
High 8.5
IBM i is Affected By Multiple Vulnerabilities in SQL
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local authenticated attacker to cause a denial of service due to improper neutralization of special elements used in an SQL command.
-
High 8.8
Pimcore Admin Classic Bundle Vulnerable to SQL Injection in Translation Grid Date Filter via Unsanitized Property Parameter
Pimcore's Admin Classic Bundle provides a Backend UI for Pimcore. Versions prior to 2.3.6 and 1.7.18 have a SQL injection vulnerability in Pimcore's translation grid date filter — the user-supplied `property` field from the filter JSON is interpolated directl…
-
Medium 4.3
SQL injection
An authenticated attacker with low privileges can access an endpoint in the controller’s web interface that is vulnerable to SQL injection. The vulnerability affects a SQLite database used only for storing notification messages. Therefore, the impact is limit…
-
Critical 9.3
WordPress Tablesome Table plugin <= 1.2.9 - SQL Injection vulnerability
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Essekia Tablesome Table allows Blind SQL Injection. This issue affects Tablesome Table: from n/a through 1.2.9.
-
High 8.6
WP Directory Kit < 1.5.6 - Unauthenticated SQL Injection via search_location and search_category
The WP Directory Kit WordPress plugin before 1.5.6 does not sanitise and escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by unauthenticated users when a non-default search field type is configured.