Skip to main content
VulnerabilityPublished Updated

CVE-2026-6453: CubeWP Framework (WordPress plugin) · SQL Injection

Affects CubeWP Framework (WordPress plugin)Source CVE Database V5

0
Compare

Not known to be exploited · CVSS 6.5 Medium.

Data as of 31 Oct 2026, 08:20 UTC

CVSS 3.1 base score
6.5Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 40% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 1 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
cubewp1211CubeWP FrameworkAffected
  • <=1.1.30
Fixed in–

AI-suggested

Until a fix is available, restrict access to the vulnerable AJAX function to trusted users only and monitor for suspicious activity related to SQL injection attempts. Avoid using the vulnerable versions of the CubeWP Framework plugin if possible.

Description

The CubeWP Framework plugin for WordPress is vulnerable to SQL Injection in all versions up to and including 1.1.30. This is due to insufficient input sanitization in the cubewp_remove_relation() AJAX function, specifically the use of wp_unslash() on the relation_id parameter before interpolating it directly into a raw SQL query without using $wpdb->prepare(). The wp_unslash() call explicitly removes the backslash escaping that WordPress's wp_magic_quotes() adds to all $_POST data, neutralizing the only layer of SQL injection protection. The sanitize_text_field() function applied afterward offers no SQL protection. This makes it possible for authenticated attackers, with subscriber-level access and above, to append additional SQL queries to the existing query.

References

Community reviews

Loading reviews…