CVE-2026-15439 in GamiPress Plugin
Summary
by MITRE • 09/11/2026
The GamiPress plugin for WordPress is vulnerable to authenticated (Subscriber+) SQL Injection via the 'q' parameter of the wpForo integration AJAX selector (action gamipress_wpforo_get_posts) in versions up to, and including, 7.9.7. The value is passed only through $wpdb->esc_like() and interpolated directly into a single-quoted LIKE clause with no %s placeholder. Because esc_like() runs after WordPress core magic quotes, it doubles the injected backslash (\' -> \\'), which MySQL reads as one literal backslash followed by a live closing quote, allowing the attacker to break out of the string and inject boolean-based SQL. The wpForo plugin only needs to be active to register the callback; no wpForo vulnerability is used. Requires a Subscriber account, which can read the gamipress_admin nonce (exposed on every admin page, e.g. /wp-admin/profile.php). Note: the researcher's Simple:Press vectors (PoC 2 & 3) do not reproduce in current code, which uses $wpdb->prepare() with %s placeholders; only the wpForo selector is confirmed.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The GamiPress plugin for WordPress contains a critical authenticated SQL injection vulnerability affecting versions up to and including 7.9.7. This flaw resides within the integration module designed to interface with the wpForo forum software, specifically triggered through an AJAX endpoint identified by the action name gamipress_wpforo_get_posts. The security defect is located in the handling of the query parameter designated as q, which serves as a search term for retrieving posts from the integrated forum system. While authentication at the Subscriber level or higher is required to exploit this vulnerability, such access rights are relatively common and easily attainable by malicious actors who have registered on WordPress sites using GamiPress. The presence of the wpForo plugin alone is sufficient to register the vulnerable callback function; exploitation does not depend on any pre-existing vulnerabilities within the wpForo software itself, making it a standalone issue within the GamiPress codebase that can be triggered independently once the integration module is active.
The technical root cause of this vulnerability stems from improper input sanitization and query construction practices by the WordPress database abstraction layer when used incorrectly by plugin developers. The developer utilized the $wpdb->esc_like() function to sanitize user-supplied input before interpolating it directly into a SQL LIKE clause enclosed in single quotes without employing the standard %s placeholder mechanism provided by $wpdb->prepare(). This approach bypasses several layers of automatic protection that WordPress core typically enforces through its prepared statement architecture. Specifically, because esc_like() executes after WordPress has applied magic quote transformations to incoming data, any backslash characters present in the input are doubled from a single backslash to two backslashes. When MySQL parses this double-escaped string within a single-quoted context, it interprets the sequence as one literal backslash followed by an unescaped closing quotation mark. This parsing behavior effectively breaks out of the intended string boundary, allowing an attacker to inject arbitrary SQL commands into the query structure.
This specific mechanism enables boolean-based blind SQL injection attacks against the underlying database server. By manipulating the injected payload and observing variations in the application's response or timing, a low-privileged user can extract sensitive data from the WordPress database with precision. The impact of this vulnerability is severe as it compromises the confidentiality and integrity of all data accessible to the database user account running the web application. This includes administrative credentials stored within wp_users tables, personal information associated with registered users, configuration settings for GamiPress itself, and potentially other plugins' data if they share the same database schema. The ability to execute arbitrary SQL commands also opens pathways for further exploitation, such as modifying site content or escalating privileges by manipulating user roles directly through SQL updates, although direct privilege escalation typically requires additional vectors beyond this specific injection point.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command and falls under the MITRE ATT&CK technique T1059 Command and Scripting Interpreter via database queries or data manipulation commands often categorized within lateral movement or credential access depending on the specific payload executed. The exposure of the gamipress_admin nonce on every admin page, such as /wp-admin/profile.php, facilitates the authentication requirement by allowing attackers to easily obtain valid nonces needed for AJAX requests without needing complex session hijacking techniques. This widespread exposure significantly lowers the barrier to entry for exploitation compared to vulnerabilities requiring unique or dynamically generated tokens that are not publicly accessible across multiple endpoints.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary solution is to upgrade GamiPress to a version later than 7.9.7 where this specific code path has been corrected, likely by replacing the direct interpolation with proper use of $wpdb->prepare() using %s placeholders for all user-supplied variables regardless of whether esc_like or other escaping functions are applied. For sites unable to upgrade immediately due to compatibility constraints, temporary mitigations include restricting access to WordPress admin pages and AJAX endpoints through IP whitelisting if feasible, although this is often impractical in dynamic environments. Additionally, implementing a Web Application Firewall with rules capable of detecting SQL injection patterns within POST parameters targeting the specific action name gamipress_wpforo_get_posts can provide an additional layer of defense by blocking malicious payloads before they reach the application logic. Regular auditing of plugin code for correct usage of WordPress database APIs is essential to prevent similar vulnerabilities in future updates or other plugins that may follow incorrect sanitization patterns.