CVE-2026-21628 is a critical flaw (CVSS 9.8) in the Templaza Astroid Framework, a template framework for Joomla. An improperly secured file management feature lets unauthenticated users upload dangerous file types, leading to remote code execution. The record names no fixed version, so check with the vendor.
What's affected
The record names Templaza Astroid Framework and gives no version range. The weakness is CWE-434 (unrestricted upload of a file with a dangerous type). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
The only reference is the vendor site, astroidframe.work. Its home page lists Astroid v3.5.2 and Astroid Pro v1.1.2 as the latest releases, but it does not say that either one addresses this CVE. I therefore could not confirm a fixed version. Ask Templaza, and treat every installation as affected until they confirm. The record does not mark the issue as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
In the Joomla administrator, go to System, then Manage Extensions, and filter for Astroid. Note the version of the framework and of any Astroid based template you use.
Then look for files that should not be there. On the server, search for script files in folders that should only hold images and media.
find /var/www/html/images /var/www/html/media -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) 2>/dev/null
Adjust the path for your site root. Compare modification times with your last known good deployment, and check web server logs for unexpected POST requests to Astroid related paths.
What to do now
- Ask Templaza which version fixes CVE-2026-21628, and update to it as soon as they confirm.
- Until then, restrict access to Astroid file management paths at the web server, and deny script execution in upload and media folders.
- Run a file integrity check on the Joomla site and remove any script file you cannot explain. If you find one, treat the site as compromised.
- Rotate the Joomla admin, database and hosting credentials after a compromise, and review user accounts.
- Keep full backups outside the web root so that you can restore a clean copy.
Why it matters
The failure is in access control on a file feature. A file manager is a powerful tool, and it should check who is calling it, what kind of file is arriving and where it will be stored. The record says it did none of these well enough, so an unauthenticated visitor could place a file with a dangerous type on the server.
If the server then runs that file, the visitor controls the site. On shared hosting that may reach other sites on the account too. This pattern appears often in content management extensions, because templates and frameworks ship file features that outlive their review.
The defence in depth steps are the same everywhere: allowlist file types, store uploads outside the web root or without execute permission, and require a login for file operations.
Quick check
Does the vendor site confirm a fix?
No. It shows newer releases but does not link them to this CVE. Ask the vendor before assuming a release is safe.
Sources
Last reviewed: 19 October 2026.
