CVE-2025-10187
BaseFortify
Publication date: 2025-10-18
Last updated on: 2025-10-21
Assigner: Wordfence
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wordfence | gspeech | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | 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. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-10187 is a SQL Injection vulnerability in the GSpeech TTS WordPress plugin affecting all versions up to 3.17.13. It occurs because the plugin insufficiently escapes and validates the 'field' parameter in AJAX requests, allowing authenticated users with Administrator-level access or higher to inject additional SQL queries. This can lead to unauthorized extraction of sensitive information from the database. The vulnerability arises from the plugin trusting user-supplied input without proper sanitization or prepared statements in its SQL queries. [1, 3]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an authenticated administrator or higher user to perform unauthorized SQL queries on the plugin's database table. This can lead to extraction of sensitive information stored in the database, potentially exposing confidential data. Although it requires high-level access, exploitation could compromise data confidentiality and integrity within the WordPress site using the vulnerable plugin. [1, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability can negatively affect compliance with standards such as GDPR and HIPAA because it enables unauthorized access to sensitive personal or protected health information stored in the database. Data breaches resulting from SQL injection attacks can lead to violations of data protection and privacy regulations, potentially resulting in legal penalties and loss of trust.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring AJAX POST requests to the WordPress plugin's backend, specifically targeting the 'wpgsp_apply_ajax_save' action in the 'gspeech_backend.php' file. Look for POST requests containing the 'field' parameter with suspicious or malformed SQL content. Detection can involve checking for unauthorized or malformed 'field' values that do not match the allow-listed database columns. Since the vulnerability requires authenticated users with Administrator-level access, monitoring admin AJAX requests for unusual 'field' parameters is key. Specific commands could include using web server logs or tools like curl or Burp Suite to send crafted POST requests to the AJAX endpoint and observe responses. For example, a curl command to test might be: curl -X POST -d "action=wpgsp_apply_ajax_save&type=save_data&field=fieldname&val=value&_ajax_nonce=NONCE_VALUE" https://yourwordpresssite.com/wp-admin/admin-ajax.php Replace 'fieldname', 'value', and 'NONCE_VALUE' accordingly. Detection scripts should verify if the server rejects invalid fields or malformed input with 400 errors or 403 errors for unauthorized users. Additionally, monitoring for unexpected database queries or errors related to the 'gspeech_data' table can help detect exploitation attempts. [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating the GSpeech TTS WordPress plugin to the latest version that contains the security fix (post version 3.17.13). The fix involves strict server-side validation of the 'field' parameter against an allow-list of database columns, sanitization of all inputs, use of prepared SQL statements, and authorization checks ensuring only users with 'manage_options' capability can perform updates. If updating is not immediately possible, restrict access to the plugin's AJAX endpoints to trusted administrator users only, and monitor for suspicious activity. Additionally, ensure that WordPress nonces are properly verified and that user capabilities are enforced. Clearing relevant caches and transients after updates is also recommended to avoid stale data. Applying the patch described in the changeset (Resource 1) will prevent SQL injection by enforcing these controls. [1, 3]