🚨 CVE-2026-17347
The MASTER_PASSWORD_HOOK setting, introduced in pgAdmin 4 7.2, lets an administrator configure an external command that returns a per-user encryption key, with %u in the configured string replaced by the current user's name. The previous implementation substituted the username directly into the command string and executed the result with subprocess.Popen(..., shell=True). Because the username can originate from an external authentication source (OAuth/OIDC claims, Kerberos, webserver auth) rather than a value pgAdmin fully controls, a username containing shell metacharacters (';', '$()', backticks, pipes, '&&', newlines) allowed an authenticated user to execute arbitrary commands as the pgAdmin service account in any deployment where the configured hook string uses %u.
Fix tokenises the trusted, administrator-configured hook string into an argument vector first (using shlex in POSIX-quoting mode, with backslash-escaping disabled so Windows-style paths are not mis-parsed), substitutes the untrusted username into the individual argv elements, and executes with shell=False. The username is therefore always confined to a single argv element; any shell metacharacters it contains are inert. Administrators whose MASTER_PASSWORD_HOOK previously relied on shell features (pipes, redirection, environment-variable expansion, globbing) within the hook string itself must move that logic into the invoked script, since it is no longer interpreted by a shell.
This issue affects pgAdmin 4: from 7.2 before 9.17.
🎖@cveNotify
The MASTER_PASSWORD_HOOK setting, introduced in pgAdmin 4 7.2, lets an administrator configure an external command that returns a per-user encryption key, with %u in the configured string replaced by the current user's name. The previous implementation substituted the username directly into the command string and executed the result with subprocess.Popen(..., shell=True). Because the username can originate from an external authentication source (OAuth/OIDC claims, Kerberos, webserver auth) rather than a value pgAdmin fully controls, a username containing shell metacharacters (';', '$()', backticks, pipes, '&&', newlines) allowed an authenticated user to execute arbitrary commands as the pgAdmin service account in any deployment where the configured hook string uses %u.
Fix tokenises the trusted, administrator-configured hook string into an argument vector first (using shlex in POSIX-quoting mode, with backslash-escaping disabled so Windows-style paths are not mis-parsed), substitutes the untrusted username into the individual argv elements, and executes with shell=False. The username is therefore always confined to a single argv element; any shell metacharacters it contains are inert. Administrators whose MASTER_PASSWORD_HOOK previously relied on shell features (pipes, redirection, environment-variable expansion, globbing) within the hook string itself must move that logic into the invoked script, since it is no longer interpreted by a shell.
This issue affects pgAdmin 4: from 7.2 before 9.17.
🎖@cveNotify
GitHub
Fix MASTER_PASSWORD_HOOK tokenisation on Windows · pgadmin-org/pgadmin4@e7a8576
posix=False in shlex.split() never strips quote characters, so any
Windows hook path quoted to handle spaces (or any quoted argument)
came out with literal quotes still attached, and unquoted space...
Windows hook path quoted to handle spaces (or any quoted argument)
came out with literal quotes still attached, and unquoted space...
🚨 CVE-2026-17349
/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.
Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials.
This issue affects pgAdmin 4: from 9.0 before 9.17.
🎖@cveNotify
/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.
Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials.
This issue affects pgAdmin 4: from 9.0 before 9.17.
🎖@cveNotify
GitHub
fix: close remaining tool-RBAC gaps found in review · pgadmin-org/pgadmin4@64a9cdb
Extends the tool-permission enforcement pattern from the reported CVE
fix to the backup/restore/maintenance/import_export blueprints, which
had the identical front-door-only gap: only create_*_job ...
fix to the backup/restore/maintenance/import_export blueprints, which
had the identical front-door-only gap: only create_*_job ...
🚨 CVE-2026-17351
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.
🎖@cveNotify
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.
🎖@cveNotify
GitHub
fix(llm): reject multi-statement and non-read-only AI assistant queries · pgadmin-org/pgadmin4@bf47924
The AI Assistant's execute_sql_query tool runs LLM-generated SQL inside
a BEGIN TRANSACTION READ ONLY wrapper. However, the LLM-supplied query
was sent to psycopg as-is, so a multi-statemen...
a BEGIN TRANSACTION READ ONLY wrapper. However, the LLM-supplied query
was sent to psycopg as-is, so a multi-statemen...
🚨 CVE-2026-17566
pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).
The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.
This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.
🎖@cveNotify
pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).
The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.
This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.
🎖@cveNotify
GitHub
fix(security): reject ambiguous backslash-escape in import/export que… · pgadmin-org/pgadmin4@1496fab
…ry guard
_is_query_parens_balanced() always treated \' inside a single-quoted
string as an escaped quote, matching psql only when
standard_conforming_strings=off. Under the actual default...
_is_query_parens_balanced() always treated \' inside a single-quoted
string as an escaped quote, matching psql only when
standard_conforming_strings=off. Under the actual default...
🚨 CVE-2026-58048
Improper preservation of SQL mode when renaming databases in cPanel allows execution of SQL in root context.
🎖@cveNotify
Improper preservation of SQL mode when renaming databases in cPanel allows execution of SQL in root context.
🎖@cveNotify
cPanel & WHM Documentation
138 Change Log | cPanel & WHM Documentation
This document lists the cases and bugs worked on during the version 138 release cycle.
🚨 CVE-2026-3141
The FormGent plugin for WordPress is vulnerable to unauthorized arbitrary file deletion due to a missing capability check on the /wp-json/formgent/responses/attachments REST API endpoint in all versions up to, and including, 1.9.2 This is due to the REST API route being registered without any authentication middleware in routes/rest/api.php. This makes it possible for unauthenticated attackers to delete arbitrary files within the formgent uploads directory. Additionally, on Linux servers where the wp-content/uploads/formgent directory does not yet exist (the default state after plugin installation), the path traversal protection can be bypassed, enabling deletion of arbitrary files including wp-config.php which can lead to complete site takeover via a fresh WordPress installation.
🎖@cveNotify
The FormGent plugin for WordPress is vulnerable to unauthorized arbitrary file deletion due to a missing capability check on the /wp-json/formgent/responses/attachments REST API endpoint in all versions up to, and including, 1.9.2 This is due to the REST API route being registered without any authentication middleware in routes/rest/api.php. This makes it possible for unauthenticated attackers to delete arbitrary files within the formgent uploads directory. Additionally, on Linux servers where the wp-content/uploads/formgent directory does not yet exist (the default state after plugin installation), the path traversal protection can be bypassed, enabling deletion of arbitrary files including wp-config.php which can lead to complete site takeover via a fresh WordPress installation.
🎖@cveNotify
🚨 CVE-2025-15669
The Bit Form WordPress plugin before 3.1.4 does not sanitise one of its conversational-form display settings before rendering it on the public-facing form, allowing high-privilege users (such as administrators, who do not hold the unfiltered_html capability on multisite) to store JavaScript that executes in the browser of any visitor who views the form.
🎖@cveNotify
The Bit Form WordPress plugin before 3.1.4 does not sanitise one of its conversational-form display settings before rendering it on the public-facing form, allowing high-privilege users (such as administrators, who do not hold the unfiltered_html capability on multisite) to store JavaScript that executes in the browser of any visitor who views the form.
🎖@cveNotify
WPScan
Bit Form < 3.1.4 - Admin+ Stored XSS via Conversational Form Progress Label
See details on Bit Form < 3.1.4 - Admin+ Stored XSS via Conversational Form Progress Label CVE 2025-15669. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-10827
The Spectra Legacy WordPress plugin before 2.20.0 does not validate or escape several block style attributes before using them to build the CSS it outputs on the front end, allowing users with the Contributor role and above to inject arbitrary CSS into the pages that render the affected block. The injected styles are served to anonymous visitors of those pages and can force external resource loads, deface/redress the page, or exfiltrate data via CSS attribute selectors. JavaScript execution is not possible at this role (the script-tag breakout is removed by KSES), so the impact is limited to CSS injection.
🎖@cveNotify
The Spectra Legacy WordPress plugin before 2.20.0 does not validate or escape several block style attributes before using them to build the CSS it outputs on the front end, allowing users with the Contributor role and above to inject arbitrary CSS into the pages that render the affected block. The injected styles are served to anonymous visitors of those pages and can force external resource loads, deface/redress the page, or exfiltrate data via CSS attribute selectors. JavaScript execution is not possible at this role (the script-tag breakout is removed by KSES), so the impact is limited to CSS injection.
🎖@cveNotify
WPScan
Spectra (Ultimate Addons for Gutenberg) < 2.20.0 - Contributor+ Stored CSS Injection via Block Attributes
See details on Spectra (Ultimate Addons for Gutenberg) < 2.20.0 - Contributor+ Stored CSS Injection via Block Attributes CVE 2026-10827. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-11882
The Builderall for WordPress plugin before 3.0.2 does not bind the state value of its public OAuth authentication routes to the initiating user session, allowing unauthenticated attackers to complete the connection flow and overwrite the stored third-party integration access token. A durable overwrite requires the site to already be connected to a paid account.
🎖@cveNotify
The Builderall for WordPress plugin before 3.0.2 does not bind the state value of its public OAuth authentication routes to the initiating user session, allowing unauthenticated attackers to complete the connection flow and overwrite the stored third-party integration access token. A durable overwrite requires the site to already be connected to a paid account.
🎖@cveNotify
WPScan
Builderall for WordPress < 3.0.2 - Unauthenticated OAuth Access Token Poisoning via Public REST Routes
See details on Builderall for WordPress < 3.0.2 - Unauthenticated OAuth Access Token Poisoning via Public REST Routes CVE 2026-11882. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-12696
The wpForo Forum WordPress plugin before 3.1.2 does not sanitize and escape a user profile field before outputting it inside an HTML attribute on the public participant profile page, allowing users with a subscriber-level account to inject JavaScript that executes in the browser of any visitor who views the profile, including a logged-in administrator.
🎖@cveNotify
The wpForo Forum WordPress plugin before 3.1.2 does not sanitize and escape a user profile field before outputting it inside an HTML attribute on the public participant profile page, allowing users with a subscriber-level account to inject JavaScript that executes in the browser of any visitor who views the profile, including a logged-in administrator.
🎖@cveNotify
WPScan
wpForo Forum < 3.1.2 - Subscriber+ Stored XSS via Profile Location Field
See details on wpForo Forum < 3.1.2 - Subscriber+ Stored XSS via Profile Location Field CVE 2026-12696. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-12966
The Direct Payments for WooCommerce WordPress plugin before 2.5.3 does not verify that the requester owns the targeted WooCommerce order in several unauthenticated AJAX handlers before changing its status and overwriting its payment metadata, allowing unauthenticated attackers to tamper with other customers' orders, including forging a "payment sent" state, overwriting the payment-method label, and attaching forged payment-proof files.
🎖@cveNotify
The Direct Payments for WooCommerce WordPress plugin before 2.5.3 does not verify that the requester owns the targeted WooCommerce order in several unauthenticated AJAX handlers before changing its status and overwriting its payment metadata, allowing unauthenticated attackers to tamper with other customers' orders, including forging a "payment sent" state, overwriting the payment-method label, and attaching forged payment-proof files.
🎖@cveNotify
WPScan
Direct Payments for WooCommerce < 2.5.3 - Unauthenticated Cross-Customer Order Tampering via digages AJAX Actions
See details on Direct Payments for WooCommerce < 2.5.3 - Unauthenticated Cross-Customer Order Tampering via digages AJAX Actions CVE 2026-12966. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13157
The Demo Import WordPress plugin through 1.1.3 does not validate the type of files uploaded during demo-content import (the WordPress file-type test is disabled), allowing high-privilege users (Administrator by default, including non-super-admin site administrators on multisite) to upload executable PHP files to the uploads directory.
🎖@cveNotify
The Demo Import WordPress plugin through 1.1.3 does not validate the type of files uploaded during demo-content import (the WordPress file-type test is disabled), allowing high-privilege users (Administrator by default, including non-super-admin site administrators on multisite) to upload executable PHP files to the uploads directory.
🎖@cveNotify
WPScan
Theme Demo Import <= 1.1.3 - Admin+ Arbitrary File Upload
See details on Theme Demo Import <= 1.1.3 - Admin+ Arbitrary File Upload CVE 2026-13157. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13158
The Everest Toolkit WordPress plugin through 1.2.3 does not validate the type of files uploaded during demo-content import (the WordPress file-type test is disabled), allowing high-privilege users (Administrator by default, including non-super-admin site administrators on multisite) to upload executable PHP files to the uploads directory.
🎖@cveNotify
The Everest Toolkit WordPress plugin through 1.2.3 does not validate the type of files uploaded during demo-content import (the WordPress file-type test is disabled), allowing high-privilege users (Administrator by default, including non-super-admin site administrators on multisite) to upload executable PHP files to the uploads directory.
🎖@cveNotify
WPScan
Everest Toolkit <= 1.2.3 - Admin+ Arbitrary File Upload
See details on Everest Toolkit <= 1.2.3 - Admin+ Arbitrary File Upload CVE 2026-13158. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13329
The Buckaroo Woocommerce Payments Plugin WordPress plugin before 4.9.0 does not perform any capability check or nonce validation on an AJAX action that processes payment capture refunds, allowing any authenticated user, including Subscribers, to trigger refunds against captured orders.
🎖@cveNotify
The Buckaroo Woocommerce Payments Plugin WordPress plugin before 4.9.0 does not perform any capability check or nonce validation on an AJAX action that processes payment capture refunds, allowing any authenticated user, including Subscribers, to trigger refunds against captured orders.
🎖@cveNotify
WPScan
WC Buckaroo BPE Gateway < 4.9.0 - Subscriber+ Unauthorized Order Refund
See details on WC Buckaroo BPE Gateway < 4.9.0 - Subscriber+ Unauthorized Order Refund CVE 2026-13329. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13596
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.
🎖@cveNotify
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.
🎖@cveNotify
WPScan
Participants Database < 2.7.8.4 - Unauthenticated SQL Injection via List Search
See details on Participants Database < 2.7.8.4 - Unauthenticated SQL Injection via List Search CVE 2026-13596. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13604
The Pixelavo WordPress plugin before 1.5.4 registers an unauthenticated AJAX action, gated only by a nonce that it emits publicly on every front-end page, that forwards client-supplied event data to the configured Facebook Conversions API using the administrator's stored access token. This allows an unauthenticated visitor to inject arbitrary conversion events into the administrator's Facebook ads account and exhaust the configured API quota.
🎖@cveNotify
The Pixelavo WordPress plugin before 1.5.4 registers an unauthenticated AJAX action, gated only by a nonce that it emits publicly on every front-end page, that forwards client-supplied event data to the configured Facebook Conversions API using the administrator's stored access token. This allows an unauthenticated visitor to inject arbitrary conversion events into the administrator's Facebook ads account and exhaust the configured API quota.
🎖@cveNotify
WPScan
Pixelavo < 1.5.4 - Unauthenticated Facebook CAPI Event Injection via pixelavo_event AJAX
See details on Pixelavo < 1.5.4 - Unauthenticated Facebook CAPI Event Injection via pixelavo_event AJAX CVE 2026-13604. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13725
The Dynamic Pricing With Discount Rules for WooCommerce WordPress plugin before 5.0.0 does not validate a nonce or user capabilities on one of its AJAX actions and reflects unsanitised user input in the response, allowing unauthenticated attackers to perform Reflected Cross-Site Scripting against a victim who is induced to send a crafted request.
🎖@cveNotify
The Dynamic Pricing With Discount Rules for WooCommerce WordPress plugin before 5.0.0 does not validate a nonce or user capabilities on one of its AJAX actions and reflects unsanitised user input in the response, allowing unauthenticated attackers to perform Reflected Cross-Site Scripting against a victim who is induced to send a crafted request.
🎖@cveNotify
WPScan
Dynamic Pricing With Discount Rules for WooCommerce < 5.0.0 - Reflected XSS via wdpAjax
See details on Dynamic Pricing With Discount Rules for WooCommerce < 5.0.0 - Reflected XSS via wdpAjax CVE 2026-13725. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-13729
The Podlove Podcast Publisher WordPress plugin before 4.5.3 does not perform nonce validation on some of its administrative create and delete actions, allowing attackers to create rogue records or delete legitimate ones via a forged request (CSRF) when a logged-in administrator is tricked into visiting a crafted page.
🎖@cveNotify
The Podlove Podcast Publisher WordPress plugin before 4.5.3 does not perform nonce validation on some of its administrative create and delete actions, allowing attackers to create rogue records or delete legitimate ones via a forged request (CSRF) when a logged-in administrator is tricked into visiting a crafted page.
🎖@cveNotify
WPScan
Podlove Podcast Publisher < 4.5.3 - Podcast Contributor/Group/Role Creation and Deletion via CSRF
See details on Podlove Podcast Publisher < 4.5.3 - Podcast Contributor/Group/Role Creation and Deletion via CSRF CVE 2026-13729. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14195
The Brizy WordPress plugin before 2.8.18 does not properly verify authorization on a request handler before returning post content, allowing users with the Contributor role or higher to read the content of arbitrary posts, including other users' private, pending, and draft posts.
🎖@cveNotify
The Brizy WordPress plugin before 2.8.18 does not properly verify authorization on a request handler before returning post content, allowing users with the Contributor role or higher to read the content of arbitrary posts, including other users' private, pending, and draft posts.
🎖@cveNotify
WPScan
Brizy – Page Builder < 2.8.18 - Contributor+ Sensitive Information Disclosure via get_post_info
See details on Brizy – Page Builder < 2.8.18 - Contributor+ Sensitive Information Disclosure via get_post_info CVE 2026-14195. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14197
The Fluent Support WordPress plugin before 2.3.1 does not perform a per-ticket access check before reassigning a ticket's customer, allowing a restricted support agent to change the assigned customer of any ticket in the system, including tickets outside their granted scope.
🎖@cveNotify
The Fluent Support WordPress plugin before 2.3.1 does not perform a per-ticket access check before reassigning a ticket's customer, allowing a restricted support agent to change the assigned customer of any ticket in the system, including tickets outside their granted scope.
🎖@cveNotify
WPScan
Fluent Support < 2.3.1 - Agent+ Arbitrary Ticket Customer Reassignment via IDOR
See details on Fluent Support < 2.3.1 - Agent+ Arbitrary Ticket Customer Reassignment via IDOR CVE 2026-14197. View the latest Plugin Vulnerabilities on WPScan.
🚨 CVE-2026-14214
The Booking for Appointments and Events Calendar WordPress plugin before 2.4.4 does not restrict which fields can be written through its customer import, allowing a user with the Amelia Manager role to modify arbitrary columns of any stored user record by supplying them in the import request.
🎖@cveNotify
The Booking for Appointments and Events Calendar WordPress plugin before 2.4.4 does not restrict which fields can be written through its customer import, allowing a user with the Amelia Manager role to modify arbitrary columns of any stored user record by supplying them in the import request.
🎖@cveNotify
WPScan
Amelia < 2.4.4 - Amelia Manager+ Arbitrary User-Field Modification via Mass Assignment
See details on Amelia < 2.4.4 - Amelia Manager+ Arbitrary User-Field Modification via Mass Assignment CVE 2026-14214. View the latest Plugin Vulnerabilities on WPScan.