eastbaycyber

CVE-2026-4275: Divi Torque Lite CSRF to Arbitrary Plugin Installation

CVE explainers 9 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-07-09
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - Divi Torque Lite for WordPress is vulnerable to CSRF that can trigger arbitrary plugin installation. - Affects addons-for-divi versions through 4.2.3 when an administrator is logged in. - Patch beyond 4.2.3 is expected, but the exact fixed version was not verifiable from available primary sources.

1) Vulnerability at a Glance

Field Value
CVE ID CVE-2026-4275
CVSS 8.8 High
Attack vector Network-based web attack via cross-site request forgery
Privileges required None for the attacker directly; success requires a logged-in administrator victim
Patch available Yes, a fix is implied because versions through 4.2.3 are vulnerable, but the exact fixed version number could not be verified from accessible primary sources

CVE-2026-4275 is a high-severity WordPress plugin vulnerability affecting Divi Torque Lite – Divi Modules for the Divi Builder & Theme, plugin slug addons-for-divi. The issue is classified as a cross-site request forgery (CSRF) flaw in REST API endpoints used to install and activate plugins.

What makes this matter operationally is the impact chain. An unauthenticated attacker does not need direct WordPress access. If they can get a site administrator to load a malicious page while logged into WordPress, they may be able to cause the site to install an arbitrary plugin from WordPress.org. In practice, that can become a stepping stone to persistence, credential theft, or full site compromise depending on what gets installed next.

2) What Is This Vulnerability?

According to the NVD description, the root cause is the use of __return_true as the permission_callback for the plugin’s /install_plugin and /activate_plugin REST API endpoints. In WordPress REST API design, the permission callback is a critical control point. If it always returns true, the endpoint may bypass the intended request validation model, including expected nonce enforcement.

NVD further notes that the endpoint handlers still contain internal current_user_can() checks. That sounds protective at first, but it is not enough to stop CSRF. In a CSRF scenario, the attacker is not trying to authenticate as themselves. They are abusing the victim administrator’s already-authenticated browser session. The browser automatically sends the admin’s session cookies with the forged request, so capability checks evaluate in the context of the administrator.

The result is a classic but dangerous web security failure mode: authorization logic exists, but request origin validation is missing or ineffective. The attacker can cause state-changing requests to be accepted simply because they come from a browser already logged into WordPress as an administrator.

Technical Notes

The behavior described by NVD centers on these REST endpoints:

  • /install_plugin
  • /activate_plugin

The risky implementation pattern is conceptually similar to:

register_rest_route(
    'divitorque/v1',
    '/install_plugin',
    array(
        'methods'  => 'POST',
        'callback' => 'install_plugin_callback',
        'permission_callback' => '__return_true',
    )
);

If the callback later relies only on capability checks such as:

if ( current_user_can( 'install_plugins' ) ) {
    // proceed with plugin install
}

then a forged request from an administrator’s browser can still succeed because the browser presents the admin’s valid cookies.

AnalystImpact · assess the risk

3) Who Is Affected?

The affected product is the WordPress plugin:

  • Product name: Divi Torque Lite – Divi Modules for the Divi Builder & Theme
  • Plugin slug: addons-for-divi

The vulnerable version range, based on the available primary description, is:

  • All versions through 4.2.3, inclusive

That means defenders should treat 4.2.3 and any earlier release as exposed unless they have independent vendor confirmation otherwise. The research material available here does not verify the exact release number that first fixed the flaw. Because of that, teams should not assume “latest in branch” safety unless they have confirmed the plugin has been updated beyond the vulnerable range.

This issue is especially relevant for organizations running WordPress sites where administrators remain logged in for long periods, use shared browsing sessions, or access untrusted links while authenticated. Managed hosting providers, agencies maintaining multiple WordPress sites, and SMBs with lightly monitored plugin inventories are at higher operational risk because plugin installation can materially change the code running on the site.

A second practical consideration is exposure of the REST route itself. Even if the site is not broadly public, any environment where an administrator can be induced to visit attacker-controlled content is in scope. That includes phishing emails, SEO poison pages, malicious ads, compromised third-party sites, or internal links if a workstation is already partially compromised.

4) CVSS Score Breakdown

NVD assigns this issue a CVSS score of 8.8 (High). The vector string was not available in the provided tool output, so the exact component values cannot be quoted here. Still, the score is consistent with a network-reachable vulnerability that can be triggered remotely through normal web interactions and can lead to significant compromise of the target application.

From an impact perspective, arbitrary plugin installation is serious because WordPress plugins extend executable application logic. Even if the initial action is “just install a plugin,” the security consequence may be equivalent to arbitrary code introduction into the environment. For defenders, that elevates this from a nuisance CSRF to a likely site-compromise path.

The score also reflects the nuance that the attacker typically needs an administrator victim to be logged in and to make a forged request, which prevents this from being scored as a trivial unauthenticated direct exploit. However, in real environments, phishing or web lure delivery is common, and browser session abuse remains a practical attack method. That is why the operational risk is high even without confirmed mass exploitation.

In the absence of the exact vector string, defenders should assume the score derives from: - remote exploitability over HTTP(S), - low attacker complexity once a lure is successful, - no direct attacker authentication, - high integrity impact due to plugin installation, - and potentially high confidentiality and availability impact if the follow-on plugin is malicious.

5) Exploitation Status

As of this check, CISA KEV status is false. CVE-2026-4275 is not listed in CISA’s Known Exploited Vulnerabilities catalog. That means there is no CISA-backed confirmation of active exploitation in the wild from the data available here.

Just as important, the available research context did not verify a public proof of concept (PoC) from accessible primary or directly retrieved sources during this session. That does not prove no PoC exists; it only means one was not confirmed here. Security teams should assume the exploit path is straightforward enough that private weaponization is plausible, especially because the underlying bug class and endpoint behavior are clearly described.

So the current status should be stated carefully:

  • Public PoC: Not verified from available sources in this session
  • Active exploitation in the wild: Not confirmed from available sources
  • CISA KEV listing: No

Because exploitation depends on social engineering or browser-driven request forgery against an authenticated admin, this vulnerability may not generate the same telemetry footprint as commodity scanning. That makes it easy to miss until a malicious plugin appears in the environment. Defenders should treat it as a high-priority patching item even without public exploitation confirmation.

ResponderRunbook · act now

6) How to Detect It

Detection should focus on two things: suspicious use of the vulnerable REST endpoints and unexpected plugin installation or activation events. Since the attacker action is mediated through the administrator’s browser, server logs may show requests that appear to come from a legitimate admin account. That means context matters more than the mere presence of a successful request.

Review web server logs, reverse proxy logs, and WordPress audit trails for requests to REST API paths containing the Divi Torque routes and plugin-management actions. Look for requests that coincide with plugin changes but originate from unusual referrers, non-admin workflow pages, or IP/user-agent combinations not typical for your admin staff.

Also check WordPress filesystem and database state for newly added plugins, especially those installed without a corresponding approved maintenance window. If you have security plugins or WordPress activity logging enabled, correlate plugin installation timestamps with admin sessions and browser activity.

Technical Notes

Example log hunting patterns to investigate:

/wp-json/.*install_plugin
/wp-json/.*activate_plugin
POST .*wp-json/.*/install_plugin
POST .*wp-json/.*/activate_plugin

Basic grep examples for common web logs:

grep -E 'wp-json/.*/(install_plugin|activate_plugin)' /var/log/nginx/access.log
grep -E 'wp-json/.*/(install_plugin|activate_plugin)' /var/log/apache2/access.log

Example Splunk search:

index=web_logs ("wp-json" AND ("install_plugin" OR "activate_plugin"))
| stats count by src_ip, http_user_agent, uri_path, http_method, http_referer, status

Example Sigma-style detection logic concept:

title: WordPress REST API Plugin Install or Activate Endpoint Access
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains:
      - "/wp-json/"
      - "/install_plugin"
      - "/activate_plugin"
    cs-method: "POST"
  condition: selection
level: medium

Useful corroborating artifacts include: - WordPress admin activity logs showing plugin installation or activation - New directories under wp-content/plugins/ - Changes in file modification times around the suspected request window

7) Mitigation and Patching

The vulnerable range is all versions through 4.2.3, inclusive. The safest remediation path is to upgrade to a version later than 4.2.3, but the exact fixed version number could not be verified from the accessible primary references available in this session. Defenders should confirm the first patched release from the plugin changelog, vendor advisory, or WordPress plugin repository before closing the ticket.

If you cannot immediately verify and install a fixed version, treat the plugin as exposed and reduce risk by limiting administrator browser exposure. That includes logging administrators out when not actively managing the site, restricting plugin installation permissions where possible, and temporarily disabling or removing the vulnerable plugin if it is nonessential.

A practical temporary workaround is to place compensating controls in front of the vulnerable REST routes. If your site does not need those plugin management endpoints exposed during normal operations, block or tightly restrict requests to them at the web server or WAF layer. This does not replace patching, but it can reduce exploitability while you validate the fixed release.

Technical Notes

If you manage plugins with WP-CLI, first check the installed version:

wp plugin list | grep addons-for-divi

Attempt upgrade to the latest available release:

wp plugin update addons-for-divi

If your policy requires pinning to a known-safe release, do not guess the fixed version. Verify it from the official plugin changelog or vendor advisory before using a version-specific install command.

Temporary Apache restriction example:

<LocationMatch "^/wp-json/.*/(install_plugin|activate_plugin)$">
    Require ip 127.0.0.1
</LocationMatch>

Temporary Nginx restriction example:

location ~* ^/wp-json/.*/(install_plugin|activate_plugin)$ {
    deny all;
    return 403;
}

If the plugin is not business-critical, disable it until a verified fix is confirmed:

wp plugin deactivate addons-for-divi

After patching or disabling, validate that: - the plugin version is above the vulnerable range, - the REST routes no longer accept unsafe requests, - and no unauthorized plugins were installed before remediation.

8) References

Primary reference for this CVE is the NVD record:

CISA KEV status reference:

Product and code-reference URLs associated with the issue:

For further reading on related vulnerabilities, you may refer to our articles on what is cryptojacking and what is n-day.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-09

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.