Cloud Security

Joomla Page Builder RCE: Two CVSS 10 Flaws Hit Cloud CMS

July 11, 2026 · 8 min read · By CloudAI Security

On July 7, 2026, CISA added two CVSS 10.0 Joomla page-builder flaws to its Known Exploited Vulnerabilities catalog after confirming active, unauthenticated exploitation in the wild. CVE-2026-48908 (JoomShaper SP Page Builder) and CVE-2026-56290 (Joomlack Page Builder CK) both let attackers upload and execute PHP with zero credentials, drop web shells, and plant backdoor Super User accounts that survive patching — turning every exposed cloud-hosted Joomla instance into a live target.

Two Joomla RCEs Strike Cloud CMS

Both flaws carry a maximum CVSS 10.0 score, let any attacker upload and execute PHP with no credentials, and already have working public proof-of-concept code published on GitHub. The federal remediation deadline of July 10, 2026 has now passed, meaning every unpatched cloud-hosted Joomla instance still running these extensions is a live, scanned target with a public exploit available.

What the Vulnerabilities Actually Do

Both bugs are the same class — unauthenticated arbitrary file upload that converts into full remote code execution — and neither requires any valid login. The technical differences sit in how the upload endpoint is reached and where the shell lands.

CVE-2026-48908 (JoomShaper SP Page Builder) is an unrestricted upload of a file with a dangerous type. According to The Hacker News, exploitation works via an HTTP POST request to the index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon endpoint, which accepts a PHP payload disguised as a custom icon. NVD rates it at the maximum CVSS 4.0 score of 10.0 (9.8 under CVSS 3.1). Versions through 6.6.1 are vulnerable; the fix shipped in version 6.6.2.

CVE-2026-56290 (Joomlack Page Builder CK) is an improper access control flaw around the file-upload handler that lets an unauthenticated attacker write executable files anywhere the web server can read. The fixed releases are 3.6.0, 3.4.10, and 3.1.1, depending on the supported Joomla line, covering affected versions through 3.5.10.

CVE	Component	Class	CVSS	Fixed Version
CVE-2026-48908	JoomShaper SP Page Builder	Unauthenticated file upload → PHP RCE	10.0	6.6.2
CVE-2026-56290	Joomlack Page Builder CK	Improper access control → RCE	10.0	3.6.0 / 3.4.10 / 3.1.1

The Exploitation Is Already Underway

These were not theoretical findings. Monitoring service mySites.guru recorded CVE-2026-56290 exploitation starting June 27, 2026, ten days before the KEV listing, with attackers dropping web shells onto exposed sites. The Hacker News reports that the first confirmed shell sat at /media/com_pagebuilderck/gfonts/bhup.php — an uploader keyed on a $_POST['_upl'] field. Because the flaw lets the attacker choose the destination folder, planted files need not live in obvious upload directories.

SP Page Builder was exploited as a zero-day in the same window. A public proof-of-concept repository on GitHub now documents the full exploit chain, lowering the bar for opportunistic scanning. Black Kite’s threat team notes that attackers were systematically planting hidden Super Administrator accounts as part of the same campaign, creating persistent re-entry paths that survive a patch unless administrators also run a full user audit and file-system scan.

The KEV listing itself is the strongest signal of severity. Inclusion means CISA has confirmed in-the-wild exploitation, and under Binding Operational Directive 26-04, federal agencies were required to remediate by July 10, 2026. Private-sector teams should treat that same date as a hard internal deadline, not a suggestion.

Backdoor Admins That Outlive the Patch

The most dangerous aspect of this incident is not the upload itself — it is the persistence. According to Black Kite, attackers created rogue Super User accounts using innocuous display names like “Web Editor” or “Admin Backup,” paired with email addresses on the @secure.local domain. These accounts grant full administrative control and do not disappear when the extension is updated.

This is the pattern that catches cloud teams off guard. An engineer patches the extension, confirms the version number is now 6.6.2, marks the ticket resolved, and the hidden account continues to operate. The web shell may be removed, but the admin credential remains valid. In cloud-hosted environments where the same CMS template or machine image is replicated across dev, staging, and production, a backdoor account baked into the database propagates with every fresh deployment.

Why Cloud Teams Own This Problem

Joomla sites do not exist in a vacuum. In 2026, the vast majority run on cloud infrastructure — AWS EC2 and Lightsail instances, Google Cloud VMs, Azure virtual machines, or containerized behind a load balancer. A web shell on a cloud-hosted Joomla instance is an interactive foothold inside the network perimeter, and from there the blast radius expands quickly.

The risk compounds because CMS instances frequently store credentials in configuration files within the web root: database connection strings, S3 access keys, SMTP credentials, and API tokens for payment or analytics integrations. An attacker with PHP execution can read configuration.php and exfiltrate every secret it references. If those credentials grant access to other cloud resources — an RDS instance, an S3 bucket, a Secrets Manager entry — the initial CMS compromise becomes a lateral-movement springboard into the broader cloud account.

This is why cloud security teams cannot treat CMS vulnerabilities as “a web team problem.” The foothold is in your cloud. The credentials are in your cloud. The blast radius is your cloud. Teams running Joomla on shared tenancy should be validating this the same way they validate an exposed IAM key.

Detection and Forensics Checklist

If any Joomla instance with either extension was internet-exposed between mid-June and the patch date, assume compromise until proven otherwise. Gridinsoft and mySites.guru outline a thorough review process that goes well beyond a version bump.

File System Hunt

Search all web-served directories for PHP files that should not exist. Priority locations: /images/, /media/, /tmp/, /cache/, extension asset folders, and template directories. A file named like an icon, image, or cache object can still contain PHP. Start under /media/com_pagebuilderck/ and /media/com_sppagebuilder/, then widen the sweep. Because the upload flaw lets attackers pick the destination, do not assume shells sit only in upload directories.

Administrator Account Audit

Review the Joomla user table for any Super User account created during the exposure window. Flag accounts with display names like “Web Editor” or “Admin Backup,” or email addresses on unfamiliar domains such as @secure.local. Check recent login timestamps against expected admin working hours. Any account that does not map to a known maintainer or client roster is suspect.

Access Log Review

Before rotating logs, preserve suspicious POST requests to page-builder endpoints, new file paths that returned HTTP 200, and admin logins shortly after upload attempts. The uploadCustomIcon task and any POST hitting com_pagebuilderck upload routes are the indicators to grep for.

Credential Rotation

After cleanup, rotate everything the compromised host could touch: Joomla Super User passwords, database credentials, SFTP and SSH keys, hosting panel passwords, and any API tokens stored in configuration files or reachable from the administrative account. If the instance stored cloud credentials, rotate those keys as well — treat a confirmed web shell as a full secret exposure.

Patch, Then Verify, Then Harden

Move SP Page Builder to 6.6.2 or later and Page Builder CK to the fixed branch matching your Joomla version. Update Joomla core and every other extension while the site is in maintenance mode, because attackers chain multiple extension flaws and a single patched component does not close every door. Inventory public exposure across production, staging, forgotten subdomains, agency preview hosts, and restored backups — attackers scan abandoned Joomla installs first, and a staging copy that resolves publicly is just as exploitable as production.

For teams operating CMS infrastructure at scale, the structural lesson is supply-chain discipline. Joomla’s extension ecosystem has historically been a soft target, and these two page-builder flaws reinforce a recurring pattern: the most popular components attract the most exploit attention, and unauthenticated upload paths are consistently the weakest link. Prioritize continuous exposure management — know which extensions are installed, which versions, and which are internet-facing — rather than waiting for a KEV listing to trigger a scramble.

Adobe ColdFusion CVE-2026-48282 — another CVSS 10.0 RCE added to CISA KEV in the same July 7 batch as the Joomla flaws
Ghost CMS CVE-2026-26980 — the recurring pattern of CMS extensions weaponized for mass site compromise
SharePoint RCE CVE-2026-45659 — another KEV-listed cloud-hosted RCE with a hard federal patch deadline