CISA added two Joomla page-builder vulnerabilities to its Known Exploited Vulnerabilities catalog on July 7, 2026, after confirming that attackers are using them in the wild. Both bugs matter for the same reason: an unauthenticated request can lead to a PHP file upload and remote code execution on a Joomla site.
The affected extensions are JoomShaper SP Page Builder, tracked as CVE-2026-48908, and Joomlack PageBuilder CK, tracked as CVE-2026-56290. Updating is the first step, but it is not the only step. If a vulnerable site was exposed before the patch, assume you also need to check for web shells, hidden administrator accounts, modified templates, and suspicious PHP files in web-served folders.
Who is affected
This is a site-owner and agency-maintainer issue, not a normal home-PC alert. Check every Joomla site where either page-builder extension is installed, including staging copies and older client sites that still resolve publicly.
| Extension | Risk and patch check |
|---|---|
| JoomShaper SP Page Builder | CVE-2026-48908 allows unauthenticated file upload that can execute PHP code. Researcher reporting lists versions through 6.6.1 as affected and 6.6.2 as the fixed release. |
| Joomlack PageBuilder CK | CVE-2026-56290 is an unauthenticated arbitrary-file-upload flaw leading to full RCE. Researcher reporting lists PageBuilder CK through 3.5.10 as affected, with fixed releases 3.6.0, 3.4.10, and 3.1.1 for supported Joomla lines. |
Why the KEV update changes the response
A vulnerability being listed in CISA KEV means defenders should treat it as an exploited exposure, not only as a theoretical patch note. The practical risk is a server-side foothold: uploaded PHP, a file-manager backdoor, a rogue super-user account, or a small loader that keeps access alive after the extension is updated.
For SP Page Builder, researcher notes describe exploitation through the asset.uploadCustomIcon task and warn that simply unpublishing the component is not a complete defense. For PageBuilder CK, the core issue is an access-control failure around file upload that can become remote code execution. In both cases, patching closes the known door; compromise review tells you whether someone already walked through it.
What to check first
- Update the extension. Move SP Page Builder to 6.6.2 or later and PageBuilder CK to the fixed branch that matches your Joomla version. Update Joomla core and other extensions while the site is already in maintenance mode.
- Inventory public exposure. Check production, staging, old subdomains, agency preview hosts, and backups restored under temporary names. Attackers scan forgotten Joomla installs first.
- Review administrator users. Look for new Super User accounts, odd email domains, recent logins outside the normal admin window, and accounts that do not match the client or maintainer roster.
- Search web-served folders for new PHP. Pay special attention to
/images/,/media/,/tmp/,/cache/, extension asset folders, and template directories. A file named like an icon, image, cache object, or update helper can still contain PHP. - Check access logs before rotating them. Preserve suspicious POST requests to page-builder endpoints, new file paths that returned HTTP 200, and admin logins shortly after upload attempts.
- Rotate credentials after cleanup. Change Joomla Super User passwords, hosting panel passwords, SFTP/SSH keys, database credentials, and API tokens that were stored in the site or reachable from the compromised account.
If a site was hit, do not trust a single file deletion as cleanup. Reinstall the extension from a clean package, compare templates against a known-good copy, review scheduled tasks or cron jobs, and check whether the domain is now being flagged by reputation systems. A web application firewall can reduce repeat probes, but it should support a patch-and-cleanup workflow rather than replace it; our WAF explainer covers that boundary. For broader CMS botnet context, see the GoTrim CMS compromise write-up.
FAQ
Does this affect every Joomla site?
No. The urgent check is for Joomla sites with JoomShaper SP Page Builder or Joomlack PageBuilder CK installed. Still, agencies should inventory old Joomla copies because forgotten staging sites are often left exposed.
Is updating enough?
Updating closes the known vulnerability, but it does not remove a web shell or rogue administrator account that may already exist. Patch first, then review users, files, logs, and credentials.
Should home users scan their Windows PC because of this?
Usually no. This is a Joomla server issue. A Windows scan is relevant only if you downloaded suspicious site backups, PHP files, or archives from a compromised server and opened them locally.
References
- CISA. “Known Exploited Vulnerabilities Catalog,” updated July 7, 2026, accessed July 7, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- NIST National Vulnerability Database. “CVE-2026-48908 Detail,” published June 20, 2026, accessed July 7, 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-48908
- NIST National Vulnerability Database. “CVE-2026-56290 Detail,” published June 29, 2026, accessed July 7, 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-56290
- Phil Taylor, mySites.guru. “SP Page Builder Zero Day RCE Fixed in 6.6.2,” mySites.guru, accessed July 7, 2026. https://mysites.guru/blog/sp-page-builder-zero-day-uploadcustomicon-rce/
- Phil Taylor, mySites.guru. “PageBuilder CK RCE – CVE-2026-56290,” mySites.guru, accessed July 7, 2026. https://mysites.guru/blog/pagebuilderck-unauthenticated-file-upload-rce/
