Unauthenticated file upload flaws in Joomla's JCE Editor and SP Page Builder under active exploitation

Two Joomla extensions carry unauthenticated arbitrary file upload vulnerabilities that give attackers remote code execution on the hosting server, and at least one of them is being exploited in the wild. According to a writeup published on dev.to, the flaws are tracked as CVE-2026-48907 in JCE Editor and CVE-2026-48908 in SP Page Builder, and both carry high severity ratings. The post reports that FortiGuard Labs continued to see active exploitation of the SP Page Builder issue after it was publicly disclosed.

How the vulnerabilities work

The problems sit in two specific endpoints: profiles.import in JCE Editor and asset.uploadCustomIcon in SP Page Builder. As the dev.to analysis describes it, both endpoints accept an uploaded file without confirming who the caller is and without checking what the file is, either by type or by content. No credentials and no valid session are needed, which is what classifies the bugs as unauthenticated rather than privilege-escalation issues. Uploading a file that the server treats as executable PHP converts the flaw into full remote code execution on the machine running the CMS.

The underlying pattern is a familiar one, the post notes: functionality intended for administrators, such as importing a configuration profile or setting a custom icon, is reachable through a route that never verifies the administrative context. An ordinary editor convenience becomes a write capability open to anyone on the internet.

Why Joomla extensions are a recurring weak point

Joomla's core codebase is comparatively small next to its extension ecosystem, the writeup argues. Real-world sites stack up page builders, editors, form components and template frameworks to make the CMS usable, and each of those is its own separately maintained dependency that the site owner has to track. The practical consequence is that a Joomla installation can be completely current at the core level and still run a vulnerable extension, so an attacker does not need an elaborate exploit chain when a single reachable endpoint will accept a file.

What operators should check

The dev.to post lays out a response checklist. Administrators should verify the installed versions of JCE Editor and SP Page Builder and move to the releases that patch these identifiers. Web server access logs deserve a review for POST requests aimed at profiles.import and asset.uploadCustomIcon, with traffic from external source addresses treated as suspicious regardless of the response code returned. Filesystem hunts should look for newly created PHP files under upload, media, cache and template directories, compared against a known-good inventory. Database checks should cover the user and extension tables for accounts or components created outside normal change management. If a web shell is confirmed, every credential reachable from that host should be considered exposed and rotated once the shell is removed. The writeup also points operators to FortiGuard's outbreak alerts and the Joomla security centre for ongoing tracking.

Why it matters

These are not theoretical findings. One flaw is already being exploited following disclosure, both require nothing more than an HTTP request to trigger, and both end with the attacker executing their own code on the server. For anyone running Joomla, the lesson is that a patched core does not equal a patched site: extension inventories need the same version discipline as the CMS itself, and file-upload endpoints inside administrative tooling deserve standing attention as a detection signal.