SP Page Builder's Joomla 3 Security Patch Was Incomplete. Version 1.0.3 Fixes It.

JoomShaper has released version 1.0.3 of the Joomla 3 Security Patch for SP Page Builder, and it finishes a job the first release started. When SP Page Builder 6.9.1 fixed five security issues we reported, Joomla 3 sites were left out, because they cannot run the 6.x package at all. The Joomla 3 patch that shipped alongside it, version 1.0.2, was meant to back-port those fixes. It back-ported four of them, left the fifth live, and shipped a cross-site scripting fix that stopped one character short. Version 1.0.3 closes both gaps.

We found them while verifying the released packages on 14 September, proved each on a Joomla 3.10.12 test site with the patch files in place, and reported them to JoomShaper the same day. This post is what those two gaps were, how 1.0.3 addresses them, and the part that no patch version fixes: most Joomla 3 sites running SP Page Builder cannot install it.

What version 1.0.2 left open

The 6.9.1 round had five findings. Four of them are ordinary back-ports: the same corrected code, moved to the older files. The two that did not travel cleanly are the interesting ones, and both are the kind of gap that appears when a fix is applied to the exact place it was reported and not to the code sitting next to it.

The first was the captcha bypass. The second was an XSS fix that escaped one of two sinks on the same line. There was also a smaller observation about where the captcha type is read from, which 1.0.3 has now tidied up as well.

The captcha bypass that never reached Joomla 3

SP Page Builder’s Pro form addons verify their captcha in a public AJAX handler that anyone can call. The bypass, described in full in the 6.9.1 write-up, is that the handler reads a view_type value straight from the request, and when that value says the form is being rendered inside a module, the code throws away the real captcha result and replaces it with a test of whether the submitted token is merely non-empty. Declare view_type=module and the captcha is gone. It is published as CVE-2026-79701, with an affected range reaching back to 3.2.6, so every Joomla 3 build has been in scope the whole time. Rather than issue a new number for the Joomla 3 branch, the Joomla CNA is extending that same record, since it is one defect across two branches.

That override was still present, word for word, in the files the 1.0.2 patch shipped for the contact form and the form builder. The opt-in form, the third addon of the same family, was not in the patch at all, so a Joomla 3 site kept whatever it already had there. The one fix in the round that an anonymous attacker could reach without any account was the one the Joomla 3 patch did not apply.

We proved it the same way as on the modern branch: two submissions to the contact addon with the same invalid reCAPTCHA token, identical apart from one field. Without view_type, the response was “Invalid Recaptcha”. With view_type=module and a matching module id, the response was the mail stage, so the captcha gate had already been passed. One field, two outcomes, the same junk token.

Version 1.0.3 removes the module override from all three addons, the opt-in form now included, so the captcha plugin’s verdict is the one that counts in every render context.

An XSS fix that stopped one character short

The 1.0.2 patch also introduced a new file, the dynamic content filter addon, as its cross-site scripting fix, and added fifteen htmlspecialchars calls to it. Two sinks were missed, and they were on lines the patch itself had edited.

The addon renders a range slider whose minimum and maximum come from a request parameter. On the label line, the value was escaped inside the data-value attribute and then printed again, unescaped, as the element’s own text content a few characters later:

$output .= '<span class="slider-min-value" data-value="'.htmlspecialchars($minValue, ENT_QUOTES, 'UTF-8').'" data-field-id="' . $fieldId . '" >'.$minValue.'</span>';

The first $minValue is safe. The second, in the text node, was not, so a crafted value reflected straight into the page. The escaping had reached the attribute and stopped before the text a few characters to its right. Version 1.0.3 wraps both, matching the complete fix already present on the 6.x branch. The Joomla security team assigned it CVE-2026-102426.

The through-line across this vendor’s last several rounds is exactly this shape: the fix reaches the reported location and not the sibling running the same code. The 6.8.0 remote code execution sat in the method directly below the one hardened in 6.7.1. Here the correction reached one of two values on a single line, and skipped the opt-in form entirely.

Only 5.6.1 sites can install it

The harder limitation is unchanged from 1.0.2, and it is not about any one finding. The patch checks the installed version and will not run on anything except SP Page Builder 5.6.1 exactly. Across the Joomla 3 sites we monitor that run SP Page Builder, only about 3% are on 5.6.1. For the other 97%, this patch will not install, and neither will 6.9.1. The largest single group is on SP Page Builder 3.8.x, and it has no official fix at all.

There is a second, quieter problem, and it is one we had already raised with JoomShaper. The patch installs as a Joomla file package: it overwrites files in place and, once applied, the component still reports its own version as before. To any updater, and to any scanner that reads a version number, a patched Joomla 3 site looks identical to one that has never been touched. A security fix you cannot detect is one you cannot manage across more than a handful of sites.

Apply 1.0.3 in one click with mySites.guru

A version number cannot tell a patched Joomla 3 site from an unpatched one, so mySites.guru reads the files instead. The Unpatched JoomShaper Security Holes tool runs on each snapshot of a connected Joomla 3 site and looks inside the installed files for a string that exists only in a given release of JoomShaper’s patch. For Helix Ultimate, Helix3 and SP Page Builder it reports whether the extension is installed, whether any patch has been applied, and whether the applied patch is the current release. It now recognises 1.0.3, so a site still on 1.0.2 shows as needing the update rather than as a green tick it has not earned.

Applying the patch is one click on that site’s tool page. When you click it, mySites.guru:

• backs up the files the vendor package is about to overwrite, and stops if the backup fails
• downloads JoomShaper’s own 1.0.3 package from our CDN and checks it against a pinned SHA-256, so the site receives the exact file JoomShaper published
• installs it through Joomla’s own extension installer, so the vendor’s version check runs and a site on the wrong SP Page Builder version is turned away, just as it would be if you installed the package by hand
• reports the outcome per extension, so a failed backup, download or install shows up as a failure on the page instead of a success with nothing changed

Undoing it is one click too, restoring the backed-up originals. We install the whole vendor package because the patched files call methods that exist only in other patched files, so splicing them in one at a time would leave a site that fatals.

The tool also covers one hole that no JoomShaper package reaches: a local file include in the SP Page Builder 3.8.x addon loader. The vendor patch installs only onto 5.6.1, so for 3.8.x sites the tool applies a small guard to that one line, with its own backup and its own revert.

If you look after Joomla 3 sites that run SP Page Builder, Helix Ultimate or Helix3, connect them to mySites.guru and the tool will show you which ones are exposed, then patch them in a click. See pricing for plans.

Apart from that one guard, none of this helps the sites the vendor patch will not install onto. Joomla 3 reached end of life in August 2023, and the extensions built for it are following it out. The fix for those sites is the migration that has been waiting, not another patch. Until then, the findings that need a logged-in account are the ones to think hardest about: audit who holds Author and Editor, and turn off self-registration where nothing depends on it.