URGENT: Security Report: SP Page Builder Upload Endpoint Actively Exploited (asset.uploadCustomIcon)
Konzeptplus AG
Hello JoomShaper Team,
I'm writing to report active exploitation attempts against SP Page Builder on one of our production websites, and to ask for your confirmation on the current fix status.
Our environment:
- SP Page Builder Pro, version 6.6.2
- Joomla site
What we are seeing: Our access logs show repeated, automated attacks targeting the SP Page Builder upload endpoint: POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon The requests carry attacker-identifying user agents including "sppb-rce-poc", "case-insensitive-php-exec" and "poc-tot-cve-2026-48908", indicating this is tied to a known/published CVE (CVE-2026-48908) targeting this endpoint. During the same incident, a malicious PHP file was found on our server under /images/spsimpleportfolio/, so our site was compromised, though we cannot yet confirm the exact upload vector.
We note your changelog for 6.6.2 (15 June 2026) states "Fixed security for upload endpoints." Our questions:
- Does version 6.6.2 fully remediate CVE-2026-48908 and the asset.uploadCustomIcon upload vulnerability, or is a further update required?
- If 6.6.2 is the complete fix, can you confirm the endpoint should reject these upload attempts, so we can be confident our exposure is closed?
- Do you have any guidance on additional hardening or indicators of compromise we should check for on affected sites?
Given that these attacks are ongoing and clearly automated against SP Page Builder installations, we would appreciate a prompt response, and if any additional fix is needed, we would ask that it be released as soon as possible.
Thank you for your help.
Pascal - HTProtect.org
Accepted AnswerThis vulnerability has been fixed by the update.
You should review all Super User accounts and run a malware scan. If anything is found, restoring a clean backup is always the safest option.
I have built a security extension that helps protect Joomla websites and stay updated against these common attacks. It can detect malware and clean up most of the infections it finds with just a few clicks.
Torsten.S
Accepted AnswerSummary of Our Cleanup and Recovery Process After a Joomla Compromise
After recovering several compromised Joomla websites, I wanted to share the steps we took to successfully clean the systems. Hopefully this may help others facing a similar incident.
- Assume the attacker had full administrative access
Do not assume that removing a single malicious file is sufficient.
Perform a complete review of:
Joomla administrator accounts User groups and permissions Access control entries Installed extensions Database integrity 2. Remove all unauthorized administrator accounts
In our case, several unauthorized Super Users had been created.
Verify:
all administrator accounts user groups creation dates last login information
Remove every account you cannot positively identify.
- Inspect the database
Besides users, also inspect permission-related tables.
Look for:
orphaned permission records suspicious assets unexpected ACL entries
Attackers may leave persistence mechanisms inside the database.
- Restore Joomla core files
Do not rely on individual file cleaning.
Replace Joomla core files with fresh copies from the official Joomla release matching your installed version.
This ensures no modified core files remain.
- Inspect uploaded files
Search your web space for:
unexpected PHP files alternative PHP extensions executable scripts in upload locations suspicious configuration files
Do not only search by filename—inspect file contents where necessary.
- Remove malicious uploads completely
If an extension-specific upload directory was abused, remove all suspicious content.
If possible, rebuild that directory from a clean installation instead of trying to identify every malicious file individually.
- Prevent code execution in upload directories
Where appropriate, configure your web server so uploaded files cannot be executed as PHP.
This significantly limits the impact of future upload vulnerabilities.
- Rotate secrets and credentials
After any compromise:
change Joomla secrets change administrator passwords change hosting passwords rotate database credentials if appropriate review SSH keys and API tokens
Assume all credentials may have been exposed.
- Review web server logs
Analyze access logs for:
exploitation attempts suspicious POST requests newly created users administrator logins unusual client IPs
This often reveals how the compromise occurred.
- Verify the vulnerability has been patched
Cleaning a hacked site without fixing the original vulnerability only leads to reinfection.
Update:
Joomla all extensions all templates
Remove extensions you no longer use.
- Create a clean backup only after verification
Do not restore from an unknown backup.
Only create a new backup after:
all malicious files are removed database has been verified administrator accounts have been checked logs no longer show successful exploitation 12. Continue monitoring
Even after cleanup:
monitor web server logs monitor new administrator accounts monitor file changes monitor extension updates
Most internet-facing Joomla sites continue to receive automated scans every day.
Final assessment
In our case, the original compromise was successfully removed.
Subsequent log analysis showed only:
automated vulnerability scanners bot traffic spam account registrations search engine crawlers AI crawlers
There was no evidence of a second successful compromise after the cleanup.
Paul Frankowski
Accepted AnswerWhole topic > https://www.joomshaper.com/forum/question/45152
Duplicates are not needed. It's easier for everyone to have ONE!
- Yes.
- SPPB update fixed, but do not remove uploaded malware files or changes in database.
- Is inside shared topic, also link to https://github.com/zkrana/joomla-security-scanner