Unauthenticated Remote Code Execution in SP Page Builder found by mySites.guru

SP Page Builder is JoomShaper’s drag-and-drop page builder for Joomla, one of the most widely installed page builders in the ecosystem. We have reported issues in it before: the June 2026 unauthenticated icon-upload zero-day fixed in 6.6.2, and a round of four vulnerabilities including a pre-auth SQL injection and an open mail relay, fixed in 6.7.1. This is the one that makes those look tame. In SP Page Builder 6.7.1, the release that fixed our previous reports, mySites.guru found a pre-authentication remote code execution flaw, plus a second unauthenticated file-write issue on the same endpoint. Both were reported to JoomShaper before any public detail, and both are fixed in SP Page Builder 6.8.0, released on 12 August 2026. We re-tested the released package the same day to confirm the fixes hold.

If you run SP Page Builder on any Joomla site, update to 6.8.0 now. If you manage more than a handful of sites, read on for how to find every affected one at once.

TL;DR

• mySites.guru found a pre-authentication remote code execution flaw in SP Page Builder, and reported it privately to JoomShaper
• Unauthenticated PHP file inclusion (CVSS 4.0 9.3, Critical). The Dynamic Content “load more” endpoint renders an addon definition taken straight from the request. The addon name is concatenated into a file path with no traversal check, then included and run as PHP. It is protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker can make the site execute a PHP file from anywhere the server can read, inside the web root or outside it
• Unauthenticated arbitrary file write (CVSS 4.0 Medium). The same endpoint lets an attacker set an addon id that becomes a filesystem path, so an anonymous request could create a directory and write a file outside the cache folder
• The flaw sits in the method directly below the one JoomShaper hardened in 6.7.1, which is why 6.7.1, our previous fix, is itself vulnerable
• Update to SP Page Builder 6.8.0 immediately
• Reported privately on 27 July 2026, fixed in 6.8.0 on 12 August 2026, 16 days later. We re-tested the released package the same day and confirmed both issues are closed
• The fix did not ship on its own. It arrived bundled with 6.8.0, a planned feature release, rather than as an immediate point release
• The Joomla CNA published CVE-2026-67285 (the file inclusion) and CVE-2026-67286 (the file write) on 12 August 2026
• The endpoint itself is still unauthenticated in 6.8.0. The two sinks we reported are fixed, but it still renders an addon definition sent by the visitor
• mySites.guru already flags every connected Joomla site still running a vulnerable version

The worst one: an anonymous request that runs your code

SP Page Builder’s Dynamic Content feature renders lists of content, articles, tags and custom collections. When a visitor asks for more items, a front-end endpoint returns the next page of them. To do that, the endpoint takes an addon definition, supplied in the request body itself, and renders it server-side.

That is the root of it. Rather than loading the saved addon from the page a visitor is looking at, the endpoint trusts a complete addon tree the caller hands it, and one of the things an addon carries is its name. The name is used to locate the addon’s code on disk, by pasting it into a file path, and that path is then included and executed as PHP. Nothing strips or rejects ../ from the name, so the name is a free path. An addon “named” a traversal string points the include anywhere on the filesystem, and Joomla runs whatever site.php it finds there.

The only thing standing in front of the endpoint is a CSRF token check, and, exactly as with the SQL injection we reported last week, that is not the barrier it looks like. Joomla issues a valid token to every visitor, anonymous ones included, the moment they load any page. A scripted attacker fetches a token and sends it back, so in practical terms this is pre-authentication code inclusion. The one precondition is that the collection being rendered returns at least one item, because the include happens inside the per-item loop, and the default articles collection satisfies that on any site with a single published article.

We confirmed it on our own SP Page Builder test install. We placed a harmless marker PHP file, made the unauthenticated request that pointed the include at it, and the marker’s output came back at the top of the HTTP response, proving the file ran as PHP inside the application. We then placed a second marker outside the web root entirely and it executed the same way, confirming the traversal is not confined to the site’s own folder. We did not run any harmful code.

The second one: an anonymous request that writes to your disk

Because the same endpoint renders a caller-supplied addon tree, every addon’s rendering code becomes a public endpoint driven by attacker-chosen settings. Most addons just draw HTML. Some touch the filesystem. The Flickr addon builds a cache path from the addon’s id, then creates that directory and writes a file into it. The id, like the name, comes straight from the request and is never checked.

Setting the id to a traversal string, an anonymous request creates a directory and writes a file well outside the intended cache folder. On our test install it created the directory and wrote a 31 KB file where it should not have been able to. The impact here is narrower than the code execution above: the filename is fixed, so this is not code execution by itself and it does not chain into the first issue. What it does give an unauthenticated attacker is directory creation anywhere the web user can write, the ability to overwrite that specific cache file, disk exhaustion, and forced outbound requests to a third-party API with a query string they control.

Why the last fix did not cover this

This is the part worth dwelling on. SP Page Builder 6.7.1 was the release that fixed the four issues we reported the week before, among them a pre-authentication SQL injection in the Dynamic Content controller. The 6.7.1 fix hardened that specific method: it added a permission check and an allow-list, with a code comment naming the SQL injection it was closing.

The endpoint in this report sits directly below that method, in the same file, and received neither the permission check nor any input hardening. The area was clearly on the developers’ radar when they patched the method above it. The one immediately below was left open. That is why a site diligently updated to 6.7.1, the fix for the previous round, is exposed to something worse. The lesson, for any maintainer, is that when you find one unauthenticated flaw in a controller it is worth auditing the whole controller, not just the reported method.

What 6.8.0 actually changed

We tested the released 6.8.0 package the day it shipped, re-running both proof-of-concept requests against a clean install. Both are closed, and the fixes are the right ones for the two sinks we reported:

• The addon name is now checked against an allow-list of plain directory names before it is used to build a path, and the include is additionally guarded by a file-existence check. Our traversal payload renders an empty item instead of executing the planted file.
• The addon id is stripped of anything outside A-Z a-z 0-9 _ - before it reaches the filesystem, so the Flickr write can no longer escape the cache folder.

One thing did not change. The endpoint still has no authorisation check. It is still reachable by any anonymous visitor holding the CSRF token Joomla gives away, and it still renders an addon definition supplied in the request. 6.8.0 edited that same controller six times, adding an extra permission check to six other methods in the file, and left this one as it was. The two doors we reported are bolted; the corridor they open onto is unchanged.

That matters for what comes next rather than for whether you should update. You should update, today. But the pattern that produced both of these findings, trusting a component definition sent by the visitor, is still how the endpoint works, and every addon with a filesystem or network side effect is still reachable through it with attacker-chosen settings.

The release notes do not tell you any of this

Here is the entire mention of this vulnerability in the SP Page Builder 6.8.0 release notes:

Hardened input validation, file handling, and access checks across the component.

That is it. One line, filed under “Updates”, sitting below “Added Copy, Paste, and Paste Style support for addons inside the Table addon” and above nothing at all. A pre-authentication remote code execution flaw, present in every release since 5.5.0, reachable by anyone on the internet with no login, is announced to users in the same register as a clipboard feature.

Judge for yourself. This is the entire 6.8.0 release note:

The release notes do not say “security release”. They do not say “critical”. They do not give a severity, a CVSS score, a CVE, or a hint that any of this is urgent. They do not say that a site left on 6.7.1 can be made to execute an attacker’s PHP. There is no “update immediately” anywhere on the page. A site owner reading that changelog over coffee has no way to tell this apart from a maintenance release, and will quite reasonably schedule it for whenever they next do updates.

What makes it worse is that JoomShaper clearly knows how to write a security changelog entry, because two lines further down, under “Fixes”, they do exactly that:

Fixed an unauthenticated SQL injection in the article loading endpoint.

Fixed a broken access control issue in the Comment addon that allowed guests to post comments while anonymous comments were disabled.

Both of those are named, scoped and honest. So the vagueness applied to the two issues in this article is not a house style or a limitation of their changelog format. Those two got a plain-English description; ours got “hardened input validation”. The most severe bug in the release is the most vaguely described one in the release notes, and it is not credited to anyone.

We have written before about what a security changelog entry owes the people running your code. The short version: say what class of flaw it was, say which versions were affected, say whether it needs urgent action, and name the researcher. None of that is difficult, and all of it changes whether a busy administrator patches today or next month. Vague release notes do not protect users from attackers. Attackers diff the release. Only the defenders are left guessing.

Credit where it is due, though not to the vendor. The Joomla Security Strike Team assigned CVE-2026-67285 and CVE-2026-67286 to these two issues within hours of the release, and went back and updated the credits on the earlier SP Page Builder CVEs so that mySites.guru is named there too. That is the ecosystem’s security team doing the vendor’s job for them, and doing it properly.

The fix waited for the feature release

JoomShaper acknowledged both issues on the day we reported them, 27 July, and confirmed a fix was in progress. That fix reached site owners sixteen days later, on 12 August, as part of SP Page Builder 6.8.0. There was no 6.7.2 in between.

Look at what else 6.8.0 carries: multilingual page support for EasyStore, multiple recipient emails in the Form Builder, clearing page hits from the editor menu, labels on Dynamic Content pages, improved AcyMailing compatibility, copy and paste inside the Table addon. That is a planned feature drop, months in the making, and the vendor’s own announcement opens by calling it “packed with exciting new features and improvements”. The patch for a pre-authentication remote code execution flaw travelled along with it.

An allow-list on a directory name and a sanitiser on an id did not need to wait for multilingual EasyStore pages. They could have gone out as 6.7.2 the same week, on their own, with a release note saying what they were for. Instead every SP Page Builder site on the internet stayed exposed for sixteen days to a flaw the vendor already knew about, so that the fix could arrive on the feature release’s schedule.

Sixteen days is not a scandal in isolation. Plenty of vendors take considerably longer, and JoomShaper answered within hours and fixed both sinks properly when they did. The problem is the coupling. Once a security fix is tied to a feature release, the date it reaches users is decided by whatever else is in the box, by QA on multilingual storefronts and clipboard support in table addons, and that is exactly backwards for the one class of change that should never wait for anything.

The 6.8.0 announcement is worth reading for what it does cover. It gives the unauthenticated SQL injection in the article loading endpoint a dedicated “Security Enhancement” section: affected versions, the fixed version, a CVE, the CWEs, step-by-step upgrade instructions, and a credit to the researchers who reported it, ourselves included. That is a good vendor security note, and it shows the standard JoomShaper is perfectly capable of meeting. The file inclusion and the file write described in this article appear nowhere on that page.

Which versions are affected?

The vulnerable code is present in SP Page Builder 6.7.1, the current release when we reported this, and from our testing in every version back to 5.5.0, where the Dynamic Content feature was introduced. The relevant files are byte-for-byte identical across 6.6.2, 6.7.0 and 6.7.1, so this is not a 6.7.1 regression, it is long-standing. JoomShaper fixed it in SP Page Builder 6.8.0.

How do you update SP Page Builder safely?

1. Take a backup first. Before any extension update on a production Joomla site, back up the database and files. If you use mySites.guru, trigger a snapshot or a full backup first.
2. Update through Joomla’s Extensions manager, or in bulk from mySites.guru. On a single site, open the Joomla administrator, go to System, then Update, then Extensions, and let Joomla pull SP Page Builder 6.8.0. If you manage more than one site, use the mySites.guru mass update feature to upgrade SP Page Builder across every affected site from one dashboard.
3. Confirm the version. After updating, check SP Page Builder reports 6.8.0 or later.
4. Clear caches. Clear Joomla’s cache and any CDN or page cache.

Because this is a code-execution flaw, updating closes the door but does not undo anything an attacker may already have done while it was open. If a vulnerable version was live and internet-facing for any length of time, treat the site as potentially compromised: check for unexpected files and admin users, rotate the Joomla secret and any stored credentials, and restore from a known-good backup if anything looks wrong.

How do I find every SP Page Builder site I manage?

Up to about ten sites, you can log in to each Joomla admin and check. Past that, you need a single view. mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for SP Page Builder once and get back every connected site running it, the version each one is on, and whether an update is available.

Why page builders keep producing this

Page builders make attractive targets for the same reason they are useful: they render content through front-end endpoints that anonymous visitors are meant to reach. An element that loads more items, a contact form that accepts a submission, none of it can require a login, because the whole point is that visitors use it. Every one of those public endpoints is attack surface, and when the code behind them trusts request input, an anonymous visitor becomes an anonymous attacker. This flaw is the sharp end of that: the endpoint trusted not just a value but an entire component definition from the request, and one field in it decided which PHP file to run.

We have seen the same shape across the ecosystem this year, from PageBuilder CK to Quix and the wider month of Joomla disclosures. Page builders are worth using. The ones that accept input from anonymous visitors simply need updating the moment a fix exists, which makes these updates security-critical rather than feature maintenance.

Stay ahead of the next one

There will be another, because Joomla runs on thousands of third-party extensions and the ones that accept input from anonymous visitors keep producing bugs like these. The hard part is never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before an attacker does.

That is the job mySites.guru does for you. It keeps a live inventory of every extension on every Joomla and WordPress site in your account, flags the ones with a known vulnerability, and lets you push the update to all of them from one screen.

Want the alerts and the tooling to act on them? Start with a free audit on one site and see your full extension inventory, or sign up for mySites.guru to get vulnerability alerts and one-click updates across every site you manage.

Disclosure and severity

The headline finding is an unauthenticated PHP local file inclusion (CWE-98, path traversal per CWE-22) reachable over the network, gated only by a CSRF token that Joomla issues to everyone. It yields execution of PHP from an attacker-chosen path and, given any writable-and-readable site.php, full remote code execution. The second finding is an unauthenticated arbitrary directory creation and file write (CWE-22), bounded by a fixed filename.

We score every issue under CVSS 4.0. The file inclusion comes out at 9.3, Critical: no privileges, no user interaction, network reachable, with a full compromise of confidentiality, integrity and availability once code runs.

Each finding, scored under CVSS 4.0:

Further Reading

• Our SP Page Builder SQL injection and mail relay disclosure - the four issues fixed in 6.7.1, the release this flaw survived in.
• The June 2026 SP Page Builder icon-upload zero-day - an earlier, separate flaw in the same component, exploited in the wild and fixed in 6.6.2.
• Why AJAX endpoints are a CMS security blind spot - the recurring public-endpoint pattern behind flaws like these.
• CWE-98: PHP Remote File Inclusion and CWE-22: Path Traversal - the canonical references for these weakness classes.
• JoomShaper’s SP Page Builder 6.8.0 announcement - the vendor’s own write-up of the release, including the security note for the separate SQL injection it also fixes.
• JoomShaper - the vendor’s site, where SP Page Builder 6.8.0 is available.