The CubeWP Framework plugin for WordPress is vulnerable to SQL Injection in all versions up to and including 1.1.30. This is due to insufficient input sanitization in the cubewp_remove_relation() AJAX function, specifically the use of wp_unslash() on the relation_id parameter before interpolating it directly into a raw SQL query without using $wpdb->prepare(). The wp_unslash() call explicitly removes the backslash escaping that WordPress's wp_magic_quotes() adds to all $_POST data, neutralizing the only layer of SQL injection protection. The sanitize_text_field() function applied afterward offers no SQL protection. This makes it possible for authenticated attackers, with subscriber-level access and above, to append additional SQL queries to the existing query.
The WPvivid Backup & Migration plugin for WordPress is vulnerable to SQL Injection via the export_data parameter in versions up to, and including, 0.9.131. This is due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. The values are received in prepare_export_post(), passed through sanitize_text_field() and stripslashes(), JSON-decoded, and the attacker-controlled JSON object keys are collected as $posts_ids without integer casting. They are stored in the export task options and later joined with commas and interpolated directly into a `WHERE ID IN (...)` clause inside a $wpdb->get_results() call in export_post_to_xml() (unquoted, numeric context), with no $wpdb->prepare() or esc_sql(). This makes it possible for authenticated attackers, with Administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
The Icegram Mailer plugin for WordPress is vulnerable to SQL Injection via the 'fields' parameter in versions up to, and including, 1.0.12. This is due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query in the Icegram_Mailer_Logs_Table::get_logs() function, where each element of the `fields` array received from $_REQUEST['data'] is joined verbatim into the SELECT clause via implode() with no whitelist, escaping, or prepared-statement placeholder. This makes it possible for authenticated attackers, with Administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
The Database Collation Fix plugin for WordPress is vulnerable to time-based SQL Injection via the 'force-collation-algorithm' parameter in all versions up to, and including, 1.2.10 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. Exploitation requires a trigger.txt file to be present in the plugin's directory (/wp-content/plugins/database-collation-fix/trigger.txt), a condition created by DesktopServer integration events such as site creation, copy, import, move, export, or deploy.
The GSheetConnector – CF7 Google Sheets Connector with Real-Time Sync plugin for WordPress is vulnerable to generic SQL Injection via the 's' parameter in all versions up to, and including, 5.2.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. wp_unslash() strips magic-quote protection and sanitize_text_field() does not escape SQL metacharacters, leaving single quotes and other SQL metacharacters intact before the value is interpolated into the query.
The Icegram Engage – Popups, Optins, CTAs & Lead Generation plugin for WordPress is vulnerable to second-order SQL Injection via 'messages[][id]' Parameter in all versions up to, and including, 3.1.42 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with contributor-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. The injection is second-order: the malicious id value is first persisted to post meta via the save_campaign_preview() AJAX action (gated by a nonce check and edit_post capability, requiring Editor-level access or above), and only executed as SQL when a subsequent preview request triggers get_message_data() to interpolate the stored value directly into a SQL IN() clause without $wpdb->prepare() or integer casting.
The Participants Database WordPress plugin before 2.7.8.4 does not properly sanitize and escape a user-supplied parameter before using it in a SQL query, allowing unauthenticated attackers to perform SQL injection attacks.
The Pinpoint Booking System – Version 2 plugin for WordPress is vulnerable to blind SQL Injection via the 'field' parameter in all versions up to, and including, 2.9.9.6.9 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. The nonce required to reach the vulnerable endpoint is emitted on all plugin admin pages loaded under manage_options, making it trivially obtainable by any authenticated administrator.
The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call).
An initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server "Prepare threshold" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration.
The corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with "cannot insert multiple commands into a prepared statement" once prepare_threshold=0 is set on that connection.
This issue affects pgAdmin 4: from 9.13 before 9.17.
The fix for CVE-2026-12044 in pgAdmin 4 9.16 hardened qtLiteral and switched sixteen COMMENT ON / pgstattuple / pgstatindex templates to it, but missed several sinks that had been placed in test_sql_string_literal_lint.py's ALLOWLIST on the incorrect assumption that schema, table, publication, and subscription names sourced from pg_catalog via the browser tree could never contain an apostrophe. PostgreSQL permits arbitrary characters in quoted identifiers, so a low-privileged user able to CREATE TABLE, CREATE PUBLICATION, or CREATE SUBSCRIPTION can plant an apostrophe'd object name that breaks out of the unescaped '{{ name }}' template interpolation the moment any user (including a higher-privileged one) opens that object's Statistics or Dependencies tab, allowing arbitrary SQL statement injection in the viewing user's database session.
Affected sinks: the Index Statistics query for all-indexes listing (coll_stats.sql, both the 16_plus and default PostgreSQL-version template variants -- distinct from the single-index stats.sql path already fixed in CVE-2026-12044), and the publication and subscription dependencies.sql / get_position.sql templates (both the pg and ppas/EPAS dialect variants for publications).
Fix switches all of these templates to qtLiteral(conn) for name interpolation, and updates publications/__init__.py and subscriptions/__init__.py to pass conn=self.conn into the dependencies.sql render_template call so the qtLiteral filter has a connection to quote against. The corresponding ALLOWLIST entries in test_sql_string_literal_lint.py are removed now that these sinks are properly escaped rather than merely assumed safe. A behavioral regression test renders each fixed template with a stacked-statement apostrophe payload and asserts both that the object name appears exactly as qtLiteral-escaped and that the rendered SQL parses as exactly one statement, verifying the assertion genuinely fails against the pre-patch raw-interpolation form.
This issue affects pgAdmin 4: the Index Statistics sink from 1.0, and the Publications/Subscriptions sinks from 5.0, both before 9.17.
A SQL injection vulnerability exists in PHP Jabbers PHP Poll Script allowing an authenticated attacker to exploit improper input neutralization in the pjAdminPolls.controller.php endpoint. This vulnerability enables high-impact SQL injection attacks. The issue was fixed in version 4.1. The vulnerability has a high CVSS 4.0 score of 8.6.
CVE-2025-67650 is an authenticated SQL injection vulnerability in multiple PHP Jabbers scripts, specifically in the Appointment Scheduler product. The flaw arises from improper neutralization of input provided by authenticated users in parameters related to sorting functions, enabling SQL injection attacks. This vulnerability has a high severity score of 8.6 and was published in July 2026. The issue has been fixed in certain versions, though those specific versions are not listed in the provided data.
A critical SQL injection vulnerability exists in PHP Jabbers Car Rental Script versions prior to 4.1. The flaw arises from improper neutralization of user input in parameters used for sorting functions, allowing unauthenticated attackers to perform SQL injection attacks. This vulnerability has a CVSS 4.0 score of 9.3, indicating high severity. The issue was fixed in version 4.1.
CVE-2026-12721 is a high-severity SQL injection vulnerability in the Kirki WordPress plugin versions before 6.0.13. The plugin fails to properly sanitize and escape user-supplied input used in SQL queries, allowing unauthenticated attackers to perform SQL injection. This vulnerability can lead to unauthorized access to sensitive data. No official patch or remediation guidance is currently confirmed.
CVE-2026-15381 is a SQL injection vulnerability in the WP Go Maps WordPress plugin versions before 10.1.04. The plugin fails to properly sanitize and escape a parameter used in a SQL query, allowing unauthenticated users to perform SQL injection attacks. The vulnerability has a low CVSS score of 3.7 and does not require user interaction or privileges to exploit, but has high attack complexity. No official patch or remediation guidance is currently available.
A SQL injection vulnerability exists in the Product Feed Manager For WooCommerce WordPress plugin versions before 7.6.1. The plugin fails to properly sanitize and escape custom filter rules used in SQL queries, allowing users with Contributor role or higher to execute SQL injection attacks. This vulnerability has a high severity score of 8.1 and can lead to unauthorized data disclosure and modification.
CVE-2026-14554 is a SQL injection vulnerability in the Check & Log Email WordPress plugin versions before 2.0.15. It arises because the plugin does not properly sanitize and escape parameters used in SQL queries. This flaw allows users with administrator privileges to perform SQL injection attacks, potentially leading to unauthorized data access or modification. The vulnerability has a medium severity rating with a CVSS score of 6.5. No official patch or remediation guidance is currently provided by the vendor.
Kamaji is the Hosted Control Plane Manager for Kubernetes. Prior to 26.7.4-edge, the PostgreSQL and MySQL datastore drivers build DDL statements by interpolating the user-supplied DataStoreUsername/DataStoreSchema directly into SQL via fmt.Sprintf, without escaping identifiers. These fields have no format validation, so a value containing a quote character breaks out of the quoted identifier — SQL injection executed over Kamaji's root connection to the shared datastore. etcd driver is not affected.This issue is fixed in version 26.7.4-edge.