Hello,
Thank you for your message and for sharing the details from your hosting provider.
To be very clear: none of our uikit modules or the Astroid framework has any security vulnerability. We maintain strict security standards, perform regular audits, and release updates precisely to prevent issues like this.

If your hosting provider claims that an Astroid file caused the hack, they must provide concrete proof (for example, a specific exploit path, log evidence, or CVE reference showing how the vulnerability was used). General statements without evidence are not acceptable and are often just assumptions.

In the future, your hosting provider should refrain from making such claims without clear forensic evidence. Blaming a third-party extension without proper investigation is misleading and unprofessional.Important point:

If a hacker already had admin access to your Joomla installation, this almost always means the core Joomla CMS itself (or the server) was compromised first — not through any third-party extension like Astroid. Once an attacker has admin rights via Joomla’s core, they can edit or replace any file on the site, including Astroid template files.
That is exactly why it looks like “an Astroid file was affected” — the attacker simply used admin rights to modify it after the initial breach.You mentioned you already have the latest Astroid update installed, which confirms there was no unpatched vulnerability on our side.If you can share the full statement from your provider (the part after “The hack occurred on…”), the exact logs, or any other technical details, we will be happy to review them together and help you clarify this with your host.We are here to support you 100 % and want to get your site secure again as quickly as possible.

Best regards, Joomlaplates    

The reported vulnerability has been CONFIRMED and FIXED. The Astroid Framework for Joomla had a critical security flaw where admin-only AJAX endpoints relied solely on for authentication. This token validates CSRF protection but does not verify that a valid admin session exists. An unauthenticated attacker could obtain a token from the admin login form and use it to perform privileged actions.

If .htaccess blocks access to /administrator/, the attacker cannot reach the login page and therefore cannot obtain the token. In that case, the vulnerability is effectively not exploitable from outside.
Please protect your backend with .htaccess