WordPress Social Share And Social Locker plugin <= 1.4.2 - SQL Injection vulnerability

The SQL Injection vulnerability in Social Share And Social Locker allows attackers to bypass security measures and directly interact with the underlying database. Due to the 'blind' nature of the injection, attackers must infer data through multiple queries, making exploitation potentially time-consuming but still highly impactful. Successful exploitation could lead to the extraction of sensitive user data, including usernames, passwords, email addresses, and potentially even financial information if the plugin handles such data. Furthermore, an attacker could modify database records, leading to data corruption or denial of service. This vulnerability shares characteristics with other SQL injection flaws, where attackers leverage malformed SQL queries to gain unauthorized access.

WordPress websites utilizing the Social Share And Social Locker plugin, particularly those running versions 0 through 1.4.2, are at significant risk. Shared hosting environments where multiple websites share the same database are especially vulnerable, as a compromise of one site could potentially expose data from others.

• wordpress / composer / npm:

grep -r "reputeinfosystems/social-share-and-social-locker" wp-content/plugins/

• wordpress / composer / npm:

wp plugin list | grep "Social Share And Social Locker"

• generic web:

curl -I https://your-wordpress-site.com/wp-content/plugins/social-share-and-social-locker/ | grep -i "SQL"

• generic web: Review WordPress access logs for unusual SQL query patterns originating from the plugin’s endpoints.

1. 2025-04-03Disclosure

   disclosure

1. Reservado2025-04-01
2. Publicada2025-04-03
3. Modificada2026-04-28
4. EPSS atualizado2026-03-23

The primary mitigation for CVE-2025-31911 is to immediately upgrade the Social Share And Social Locker plugin to version 1.4.3 or later. If upgrading is not immediately feasible due to compatibility issues or breaking changes, consider temporarily disabling the plugin to prevent exploitation. While a direct WAF rule is difficult to implement for blind SQL injection, implementing a WAF rule that blocks suspicious SQL query patterns targeting the plugin's endpoints could offer some protection. Monitor WordPress access logs for unusual SQL query patterns originating from the plugin’s endpoints. After upgrading, confirm the vulnerability is resolved by attempting a test SQL injection query through the plugin’s functionality and verifying that it is properly sanitized.