SP Page Builder ships a one-file controller patch in 6.6.2, and the locked support thread is a reminder that patching isn't cleanup

You patched the plugin. You updated the version. You went to bed. The site got hacked anyway, because the attacker had a key cut last week and you only changed the lock today. This is the bit nobody in vendor comms wants to lead with, and it is the bit JoomShaper has now had to concede in writing under its own support post for SP Page Builder, a Joomla page-building extension with deep penetration in the small-agency market. The vendor has published the verbatim controller patch as a public GitHub gist, alongside the bundled fix that shipped in version 6.6.2, for installations that need to apply the change by hand. The thread carrying the announcement is locked. The comments under it are not subtle about why.

For anyone who runs CMS-backed properties through any kind of automation, this is a textbook supply-chain moment: a popular extension turned into a controller endpoint that anyone could hit, a one-file fix, and a queue of operators discovering that "I updated" and "I am safe" are different sentences in different languages.

The fix, in one path

Per JoomShaper's own write-up, the entire vulnerable surface lives in a single file: components/com_sppagebuilder/controllers/asset.php. The vendor states the change "fully secures the affected controller endpoint," which is the polite way to say the previous endpoint was, in fact, not secured. The patch is bundled into v6.6.2 and is also posted as a standalone gist for users who cannot run the in-product updater for whatever reason. JoomShaper's recommended path is the obvious one (System → Update → Extensions), with the gist as a fallback for sites that cannot get there.

That is the announcement. Read it twice, because the part that matters for your runbook is what JoomShaper does not put in bold.

Patching closes the door. It does not evict the squatter.

A commenter on the same thread, an agency owner, makes the point with the clarity vendors rarely manage on their own: if your site was reachable before you patched, updating the plugin removes the entry point and does nothing about whatever the entry point was used for. Backdoors. Rogue admin accounts. Modified theme files. New scheduled tasks. PHP shells dropped in writable directories. JoomShaper, to its credit, concedes this in a follow-up reply: "no further action is needed" only applies to sites that were not compromised before the update. If you were compromised before the update, the update is step one of many.

The thread has two other tells. One operator reports they updated to v6.6.2 and the attacker is still adding .html files to the webroot and deleting .htaccess. (A patched lock is no help when the burglar is sleeping on your couch.) Another reports taking six client sites offline and counting. A third asks whether their decade-old v3.x install on a Joomla 3 site is affected and notes the same file path exists in v3.7.14. JoomShaper's reply on that branch is, generously, ambiguous.

This is the trust shape of the incident. The plugin is widely deployed, the fix is small, the cleanup is not.

Why a gist is the wrong distribution channel for a security patch

It is also a tell. When the recommended deployment channel for a critical fix is "paste this file into your install," you have learned something about the assumptions the vendor makes about its users. Namely: that many of them are not on the auto-updater, do not have a current subscription, and are running installs old enough that the in-product update path is not viable. A gist is a workaround for the failure mode of the supply chain itself.

If you are responsible for any number of these sites at scale, none of this should be a surprise. The honest read: you cannot pull a CMS extension off a vendor portal, drop it on cPanel two years ago, and expect to inherit a maintained software stack. You inherited a frozen one. The first time it moves is usually the day it has to.

What does a CI/CD-shaped response look like for CMS extensions?

The interesting question for anyone reading this on a CI/CD news site is not "did you update SP Page Builder," it is "do you have any pipeline that would have told you on Monday that it needed updating." Most agencies do not. The patterns that help are not exotic, they are just rarely applied to PHP CMS workloads:

• Treat your CMS as an artifact, not a server. Build the entire Joomla install (core + extensions + theme + config) from source into an immutable container or filesystem image on every release. A vulnerable extension version is then a line in a manifest you can grep, not a row in an admin database table you can only see by logging into the site.
• Pin extension versions in a manifest the pipeline reads. A simple extensions.yaml (or composer.json for projects that use Joomla's Composer path) lets a scheduled job diff installed versions against a vendor feed and open a PR when a security release lands. The diff is the alert.
• Rebuild forward, do not patch in place. When a CVE-class fix lands, the pipeline rebuilds the image from the new version and rolls it out, rather than scp-ing a single PHP file onto a long-lived host. Both reach the same end state for the live vulnerability. Only one of them can also be reproduced six months later when someone asks how a clean site is defined.
• Keep an offline, immutable, dated backup outside the deploy target. When the answer to "is this site compromised" is "probably," your recovery is bounded by how old your last trustworthy snapshot is. That is a CI/CD problem dressed as an ops problem: backups are a build artifact too, and the pipeline owns them.
• Run a content-integrity scan as a scheduled job. A nightly diff against the artifact's known file list catches the .html drops, the rewritten .htaccess, the unexpected PHP under /images/. This is the only check that survives a vendor patch landing too late.

None of this is unique to Joomla. The same pipeline shape applies to WordPress with plugins, Drupal with modules, and any commercial CMS where a third-party marketplace contributes large amounts of executable code into your deploy. The reason the post under discussion is generating four hundred comments instead of one is that the affected fleet was largely operated outside any of these patterns.

What is the responsible read on JoomShaper itself?

Fair, since the post offers both the bug and the response in one place. The vendor shipped a bundled fix in v6.6.2 and published the standalone file separately so non-subscribers and stale installs have a path forward. The acknowledgement that "update alone is not cleanup" is, eventually, in writing. The thread is locked, which prevents the comments section from becoming an indefinite outage ticket, and a separate channel exists for affected sites to report.

The criticism the same thread surfaces, also fair: the manual fix is shared days after sites have already been hit, the in-thread version numbers are inconsistent (the same vendor rep cites both "v6.6.2" and "v6.2.2" in different replies, which is the kind of thing a release-engineering process is meant to prevent), and the question of whether the v3.x branch is also exposed is left dangling. None of that is fatal. All of it is the cost of running a plugin marketplace at the volume SP Page Builder runs at.

What is still unresolved

A few things. Whether the v3.x branch carries the same controller and the same defect on the same path is, per the thread itself, an open question, and the operator who asked is the same one whose old install would not benefit from the in-product update path at all. The compromised-site population is undercounted by definition, because the rogue admin accounts and the .htaccess rewrites do not file support tickets, the human reading the dashboard does. And the broader pattern, plugin marketplace ships executable code into thousands of CMS installs that nobody is rebuilding, is not specific to this extension or this CMS, it is the shape of every PHP CMS supply chain in 2026.

If you maintain client sites that run SP Page Builder, the work today is two-track. Update everything to v6.6.2 or apply the gist by hand, and assume the sites were already hit. Diff the file tree against a known-good build. Audit the user table. Rotate every credential reachable from a configuration.php. Then go decide whether the pipeline you wish you had last week is the one you build this quarter.

A patched site that was already compromised is still a compromised site. Anyone who tells you otherwise is selling you something, or locking a thread.