CVE-2026-2413: Unauthenticated SQL Injection in Ally Affects 400,000 WordPress Sites
The Ally WordPress plugin - formerly known as Pojo Accessibility - has a confirmed unauthenticated SQL injection vulnerability tracked as CVE-2026-2413. With over 400,000 active installations, it is already under active exploitation. If you or your clients are running this plugin, update to version 4.1.0 immediately.
What Is the Ally Plugin?
Ally (plugin slug: pojo-accessibility) is a widely-used accessibility toolbar plugin for WordPress. It adds WCAG-focused UI controls to the front end of sites, making it a common inclusion across agency-built portfolios and SMB client sites. Its large install base is precisely what makes this vulnerability significant.
What the Vulnerability Does
CVE-2026-2413 is an unauthenticated SQL injection flaw, meaning an attacker does not need any WordPress account or session to exploit it. By crafting a malicious HTTP request to an endpoint exposed by the plugin, they can extract data directly from the site's database - including user credentials, session tokens, and any personally identifiable information stored there.
Wordfence confirmed live exploitation attempts and issued a firewall rule before many sites had completed their plugin updates. That gap - between disclosure and full patch coverage across a large install base - is exactly the window attackers target.
What to Do Now
The patched version is 4.1.0. The remediation steps in order of priority are:
- Update the Ally plugin to 4.1.0 on every affected site immediately
- If you manage a fleet, prioritise internet-facing production sites first
- Enable or verify WAF rules covering this CVE - Wordfence has signatures available
- Review server logs for suspicious query-string patterns:
UNION,SELECT,SLEEP(, encoded quotes (%27,%22) - Check for unexpected admin accounts or modified plugin files created before the patch was applied
- If compromise cannot be ruled out, rotate database credentials and privileged WordPress passwords
The Bigger Picture
This incident follows the same pattern as CVE-2026-1492 from earlier this month - a widely-installed plugin, no authentication required, active exploitation within days of disclosure. The recurring lesson is that auto-updates alone are not a sufficient response strategy. By the time WordPress auto-update cycles complete across a diverse client portfolio, exploit campaigns are already well underway.
For teams managing multiple WordPress sites, this is the case for treating unauthenticated injection vulnerabilities as a patch-SLA event rather than a routine update. A WAF rule buys time; it does not replace the patch. Both are required.