CVE-2026-12918
MediumCVSS 4.9Exploitation Probability (EPSS)
Low risk24th percentile - higher than 24% of all known CVEs
Summary
The Mail Mint plugin for WordPress is vulnerable to generic SQL injection via the 'recipients' parameter in all versions up to and including 1.24.1. Authenticated attackers with administrator-level access can store a malicious payload that is later executed when reading campaigns, allowing extraction of sensitive database information.
Risk Assessment
The risk involves potential theft of sensitive data from the WordPress database, such as user passwords or customer data, by an authenticated administrator. However, the attack requires administrator privileges, limiting its exploitation in typical scenarios.
Recommendation
Immediately update the Mail Mint plugin to the latest available version that includes a fix for this vulnerability. If an update is not available, temporarily restrict access to the admin panel to trusted users only.
Other vulnerabilities in Mail Mint
See all- CVE-2026-14342Medium
The Mail Mint plugin for WordPress is vulnerable to time-based SQL Injection via the 'contact_ids' parameter in versions up to and including 1.24.2. This is due to insufficient escaping and lack of proper SQL query preparation.
- CVE-2026-27349Medium
The WordPress plugin Mail Mint up to version 1.19.5 exposes sensitive system information to unauthorized entities, allowing retrieval of embedded sensitive data.
Original NVD description (English source)
The Mail Mint – Email Marketing, Newsletter, Email Automation & WooCommerce Emails plugin for WordPress is vulnerable to generic SQL Injection via the 'recipients' parameter in all versions up to, and including, 1.24.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. This is a second-order SQL injection: the malicious payload is first stored unsanitized via a POST request to /mrm/v1/campaigns/ (bypassing filter_recipients() validation because an int-cast of a string like '1) OR ...' evaluates to a real numeric ID), and is then triggered by a subsequent GET request to /mrm/v1/campaigns/{id} that deserializes the recipients and passes the raw id string through array_column() into the vulnerable query.