--- schema: 1 kind: vulnerability title: "CVE-2026-65766 and CVE-2026-65879 — SP Page Builder for Joomla: a CSRF token Joomla hands to anonymous visitors is the only guard on an ORDER BY injection, plus a shipped-in-source shared secret that opens a mail relay" headline: "The Joomla page builder whose icon-upload zero-day was exploited in June ships four more flaws — one reads the whole database without an account" summary: > mySites.guru disclosed four vulnerabilities in JoomShaper's SP Page Builder 6.7.0 on 2026-07-27, all fixed the same day in 6.7.1, with four CVEs assigned by the Joomla CNA and a fifth (CVE-2026-65876, 9.2, an unauthenticated SQL injection the discloser did not report or test) covering the same versions — so 6.7.1 fixes five issues, not four. CVE-2026-65766 (Joomla CNA, CVSS 4.0 9.2) places a request value straight into the ORDER BY clause of the Dynamic Content endpoint's query; the only control in front of it is a Joomla CSRF token, which Joomla issues to every anonymous visitor on page load, so a scripted attacker fetches a token and replays it — effectively pre-authentication SQL injection that reads the entire Joomla database, password hashes included. CVE-2026-65879 is a design flaw rather than a slip: the contact-form addons sign the configured recipient address with a secret hardcoded identically into every shipped copy of the extension, so anyone holding the extension can forge a signature and send mail to any recipient with a spoofed sender through the site's own mail server. The same extension's unauthenticated icon-upload zero-day was being exploited in the wild in June 2026. discovered_at: "2026-08-02T13:45:00Z" event_date: "2026-07-27" run_id: 2026-08-02T1309Z-audit priority: high immediate_action: null tags: [vulnerabilities, sqli, pre-auth, info-disclosure, patch-available, phishing] regions: [global, europe] sectors: [public-sector, technology, education] entities: [trend:joomla-extension-file-upload-rce-wave] techniques: [T1190] affected_products: ["JoomShaper SP Page Builder"] cves: - id: CVE-2026-65766 cvss: "9.2" epss: null type: sqli vector: zero-click auth: pre-auth status: [patch-available] affected: "SP Page Builder 6.7.0 and earlier, per the discloser's own advisory — the Dynamic Content endpoint's tag-sort feature concatenates the request's sort `direction` value raw into the query's ORDER BY clause, a position that cannot be safely parameterised." fixed: "SP Page Builder 6.7.1, released 2026-07-27 (JoomShaper closed all four reported flaws in that release, per the discloser)." - id: CVE-2026-65879 cvss: "9.8" cvss_note: "CISA-ADP CVSS 3.1 — the Joomla CNA assigned this identifier no metrics, so this score is not on the CVSS 4.0 scale its four siblings use and must not be ranked against them." epss: null type: logic-flaw vector: zero-click auth: pre-auth status: [patch-available] affected: "SP Page Builder 6.7.0 and earlier — the `ajax_contact` / `form_builder` contact-form addons sign the configured recipient address with a secret hardcoded identically into every shipped copy of the extension (CWE-798), so the signature is forgeable by anyone holding the extension." fixed: "SP Page Builder 6.7.1." - id: CVE-2026-65877 cvss: "8.2" epss: null type: sqli vector: zero-click auth: post-auth status: [patch-available] affected: "SP Page Builder 6.7.0 and earlier — the media manager's search and date filters place request input into the query unescaped; reachable by a low-privilege author account." fixed: "SP Page Builder 6.7.1." - id: CVE-2026-65878 cvss: "8.3" epss: null type: path-traversal vector: zero-click auth: post-auth status: [patch-available] affected: "SP Page Builder 6.7.0 and earlier — the media-delete action removes a file at a request-supplied path with no traversal guard; reachable by a low-privilege author account." fixed: "SP Page Builder 6.7.1." - id: CVE-2026-65876 cvss: "9.2" epss: null type: sqli vector: zero-click auth: pre-auth status: [patch-available] affected: "SP Page Builder 6.7.0 and earlier — an unauthenticated SQL injection through the `catid` parameter of the `loadMoreArticles` endpoint. The discloser states plainly that this one is not among the four it reported and that it did not test it, so the mechanism here is the CNA record's description as the discloser relays it, not the discloser's own analysis." fixed: "SP Page Builder 6.7.1 — the discloser states 6.7.1 fixes five issues in total, not four." sources: - url: "https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/" publisher: "mySites.guru" date: "2026-07-27" role: primary closed_sources: [] evidence: - quote: "It is protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker could read the entire database, password hashes included" publisher: "mySites.guru" - quote: "The contact-form addons protected the recipient address with a secret that was hardcoded identically into every copy of the extension" publisher: "mySites.guru" verification: single-source sourcing_note: "Single-source by design for the mechanisms: mySites.guru is the discovering and reporting party for four of the five flaws and its own write-up is the authority for what each does. The SCORES, however, are read from each identifier's own CVE record (`cveawg.mitre.org/api/cve/`), not from the discloser's table, because the two disagree about provenance. The Joomla CNA scored CVE-2026-65766, -65877, -65878 and -65876 with CVSS 4.0 (9.2 / 8.2 / 8.3 / 9.2). CVE-2026-65879 carries NO CNA metrics at all: its 9.8 is a CISA-ADP CVSS 3.1 score, so it is on a different scale from its four siblings and is not comparable with them — the discloser's table labels all four its 'CNA score' column, which is where that error entered. The discloser's own lower CVSS 4.0 self-assessments (8.7 / 6.9 / 7.1 / 7.2) are named in the body; it states that where its numbers and the CNA's differ, the CNA's is the one that travels with the CVE. CVE-2026-65876 is not one of the four mySites.guru reported and it says it did not test it. Credibility 2: one assessing party for the mechanisms, uncorroborated by an independent second." confidence: medium update_of: null references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: B credibility: 2 watchlist_hit: false actions: - "Query your Joomla estate for SP Page Builder and update every instance below 6.7.1; on any site that ran 6.7.0 or earlier while internet-reachable, treat the Joomla user table as read — force a password reset for all accounts and rotate the site secret, because the SQL injection needs no account and returns password hashes." migrated_from: null --- This is a recovery published by the 2026-08-02 weekly quality audit: the disclosure landed inside the audit window and no entry covered it. The reason CVE-2026-65766 matters is the shape of the control that was supposed to stop it. Two scores are in circulation and the discloser says which one to use: "The CNA scored the pre-authentication SQL injection 9.2 Critical. We scored it 8.7 High", and "Where the two differ, the CNA’s number is the one that travels with the CVE." ([mySites.guru, 2026-07-27](https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/)) — so this entry carries the CNA figures. The Dynamic Content endpoint's tag-sort feature concatenates the request's sort `direction` value directly into the query's `ORDER BY` clause — a position no prepared statement can parameterise — and the only thing in front of that endpoint is a Joomla CSRF token. Joomla issues a valid token to every visitor on page load, anonymous ones included, so an attacker's script fetches a page, lifts the token and replays it; mySites.guru states the flaw is "protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker could read the entire database, password hashes included" ([mySites.guru, 2026-07-27](https://mysites.guru/blog/sp-page-builder-sql-injection-mail-relay-disclosure/)). The discloser confirmed it with a time-based blind proof on its own test install. A CSRF token is an anti-forgery control, not an authentication control, and any extension that treats one as an authorisation gate has the same defect class regardless of vendor. The second flaw, CVE-2026-65879, is a design decision rather than an oversight. The `ajax_contact` and `form_builder` contact-form addons protect the configured recipient address with a signature, but as the discloser puts it, "The contact-form addons protected the recipient address with a secret that was hardcoded identically into every copy of the extension" — so the secret is public to anyone who downloads the extension, the signature is forgeable, and an attacker sets an arbitrary recipient and a spoofed sender. The outbound mail then leaves the victim's own domain and mail server, which is what makes this a deliverability and reputation problem rather than a nuisance: the spam or phishing carries the site's authenticated sending identity. Two further issues need only a low-privilege `author` account — an unescaped SQL injection in the media manager's search and date filters (CVE-2026-65877, CVSS 4.0 8.2), and a media-delete action that removes a request-supplied path with no traversal guard (CVE-2026-65878, CVSS 4.0 8.3), letting an author delete `configuration.php` or a protective `.htaccess`. A fifth identifier against the same versions, CVE-2026-65876, is a second unauthenticated SQL injection — through the `catid` parameter of the `loadMoreArticles` endpoint, scored CVSS 4.0 9.2 by the CNA — which the discloser explicitly did not report and did not test, but which 6.7.1 also fixes: "If you are working out what 6.7.1 actually fixed, the answer is five issues, not four." Two things put this above the routine extension-update cycle for a public-sector estate running Joomla. First, the mechanics: an anonymous, scriptable request that returns the full user table needs no exploitation signal to force a timeline. Second, the base rate for this specific extension — mySites.guru notes it reported "the June 2026 unauthenticated icon-upload zero-day that was being exploited in the wild and fixed in 6.6.2" in the same product, and describes SP Page Builder as "one of the most widely installed page builders in the ecosystem". A product whose last unauthenticated flaw was exploited before the fix shipped does not get the benefit of the doubt on the next one. **Defender takeaway:** patch to 6.7.1, then decide whether the database was already read. There is no reliable "was I exploited" artefact for a blind SQL injection that reuses a legitimate endpoint with a legitimate token, so the honest posture on a site that was internet-reachable on 6.7.0 is to assume the user table left the building: reset every Joomla account password, rotate the site secret in `configuration.php`, and review administrator-group membership. For the mail relay, check outbound mail volume and bounce rates from the site's sending domain over the exposure period — an open relay shows up as delivery reputation damage before it shows up in the application. **Triage:** the SQL injection produces web-server access-log entries that look entirely legitimate — a valid CSRF token, an ordinary Dynamic Content endpoint path, HTTP 200. The discriminators are in the parameter and the pattern rather than the endpoint: sort-direction values that are not `asc` or `desc`, unusually long or syntactically complex query-string values on that endpoint, and above all a long run of near-identical requests from one source with response-time variation rather than response-content variation, which is the signature of a time-based blind extraction. A single request is unremarkable; a few thousand of them against one endpoint from one address, each differing by a character, is the finding. For the mail-relay flaw, the artefact is in the mail logs rather than the web logs: messages leaving the site's mail server whose recipient domain has no relationship to the site's own audience.