We published Akeeba Backup for Joomla 10.3.7, Akeeba Backup for WordPress 9.1.8, Akeeba Solo 9.1.8, and Admin Tools for Joomla 7.9.0 today. These releases are mainly focused on security hardening.
We will preface this by clarifying that none of the issues fixed could result in your site getting hacked.
Access control fixes
By default, our software is only accessible to Super User (Joomla) or Administrator (WordPress) accounts, or to the single account you use to log into Solo. These are the users with the highest access on your site. This has always worked perfectly fine, and it's not broken. If a less-privileged user tries to access our software under the default configuration, they are denied access.
We also give an option to allow less privileged users to access some features in our software using permissions (Joomla) or roles and capabilities (WordPress). We discourage the use of these features as they are equivalent to privilege escalation. We still offer these features for some practical use cases where convenience and the trusted but not too technical nature of a user may result in a negligible security risk.
An audit of our access checks across all three products found inconsistencies, in both directions. None of this is reachable through the default configuration, where only a Super User (Joomla), an Administrator (WordPress), or your own Solo login can access our software at all. Every issue below only comes into play if you have deliberately chosen to delegate some access to a lower-privileged user or role — an uncommon setup that requires specific, intentional action on your part. Even then, it only changes what that already-delegated account could do. It could not change what an outside, unauthenticated visitor could do. It could not change what a user without any access to the component at all could do.
- In Akeeba Backup, several backend pages (Schedule, Push, Statistics, Profile management, and the "delete backup" action) weren't enforcing their intended access privilege at all, due to missing wiring in the underlying code. In practice, this meant any account with generic access to the component could reach these pages regardless of the specific privilege you had actually granted it. We've closed this gap. In the same effort, access to the Schedule page — which can display API secrets — is now further restricted to accounts with full administrator access; previously, it allowed access to anyone with any level of access to the component.
- In Akeeba Solo, a related issue affected the user and profile management pages: an internal lookup that matches the current page to its access rule could fail to recognise certain page names, causing the check to be skipped rather than enforced. This is now fixed.
- In Admin Tools, we found both directions of the problem. The Control Panel and its quick actions required a narrower permission than intended, so a user you'd explicitly granted general Admin Tools access to could still be denied entry to the Control Panel; we've relaxed that specific check to match the access you intended to grant. We also found, and fixed, a handful of other checks (including the Site IP Allow List and several single-item management screens) that had been silently falling back to an overly permissive default, which could let a limited operator perform actions — such as creating a Temporary Super User account — that they should not have had access to.
Improved anti-CSRF checks
Our software uses session tokens (Joomla, Solo) or nonces (WordPress) — unpredictable values tied to your current login — to make sure that a request to perform an action really did originate from within our own interface, and not from some unrelated page you simply happen to have open at the same time. Without this protection, a malicious or compromised web page could embed a hidden link, form, or image that, just by loading in your browser while you're still logged in — no click required — causes your browser to silently send a request to our software and carry out an action on your behalf. This method of attack is called Cross-Site Request Forgery (CSRF).
While auditing our software, we discovered inconsistencies and missing checks in fairly anodyne features with no practical value to an attacker. We have addressed those in today's releases.
To put this into perspective, the worst an attacker could do is trick a logged-in user into deleting an offsite copy of a backup archive in Akeeba Backup or Solo (if they know its ID), or trick a logged-in user into running the temporary directory cleaner in Admin Tools. If anything, these attacks would only inconvenience the site owner while working against the attacker's goals.
A few other affected features would cause an unexpected page to appear in the user's browser, waiting for user action. This makes those issues non-exploitable, as it would give away the fact that they are being attacked, leading to an immediate, intuitive reaction (closing the browser window) before any potentially damaging action is taken.
New security features in Admin Tools for Joomla!
As a follow-up to the security issues we've seen in third party Joomla! software, we have introduced a number of additional security features in Admin Tools.
UploadShield reloaded. The original UploadShield was contributed to Joomla years ago, but developers still bypass it by not using Joomla's API to handle uploads. The reintroduced and improved UploadShield feature now scans uploaded files for embedded PHP code, disguised PHP file extensions, multiple/double extensions, and attempts to override the .htaccess handler (thus closing the one hole that could bypass the .htaccess Maker's Frontend and Backend Protection features). This feature runs regardless of how third-party developers choose to handle uploads. This significantly raises the bar against file-upload-based attacks. The downside is that if you use this feature, everyone except a logged-in Super User (who may still need to upload template overrides) forfeits the ability to upload .php files to your site.
PHP File Change Scanner: core file verification. The scanner can now verify your site's core Joomla files against precomputed checksums, on top of its existing change detection, making it easier to spot tampered core files.
Configuration Monitoring: change diffs. Configuration change notifications now include a diff of what actually changed, with sensitive values redacted, so you can review changes at a glance without exposing secrets.
Improved SQLiShield. SQLiShield's performance against one-bit oracle exfiltration attacks has also been improved.
Improved PHPShield. PHPShield blocks attempts to abuse PHP's built-in stream wrappers (such as php://filter) — a common technique for tricking a vulnerable script into disclosing your site's source code, instead of running it. We found that prefixing such an attempt with a space, tab, or similar whitespace character could let it slip past PHPShield's check entirely. We've closed this gap. To put this in perspective: this bypass only matters if some other script on your site — in Joomla core, or more likely in a third-party extension — already has a file-inclusion weakness for PHPShield to guard against in the first place; on its own, it doesn't give an attacker a way in.