User accounts and access
Who can log in, how they prove it, and how many accounts nobody has used in years.
33 checks in this group, 4 with a full write-up.
Every account is a door, most of them unused
This group covers two different problems that happen to both live under “who can log in”. The first is straightforward access control: how many accounts have the keys to the whole site, whether they prove who they are with more than a password, and whether the username half of that password is something an attacker does not have to guess because it is “admin” on a large share of installs by default. The second is housekeeping that people forget is also security: accounts that registered and never logged in, accounts blocked months ago and never deleted, accounts that requested their data exported or removed under privacy law and are still sitting in a queue nobody actioned.
The two problems compound on a large client base. A portfolio built up over years accumulates accounts the way it accumulates plugins: someone was given access for a project that finished two years ago, a client’s former employee still has an active login, a test account from the build phase never got removed. None of these are being actively misused right now, which is exactly why they get missed, and every one of them is a credential that works if it is ever guessed, phished, or found in a leaked password list from an unrelated breach, because people reuse passwords across sites they have long since forgotten they had access to. Because a user table is quick to read against, every check in this group runs on the twice-daily snapshot rather than waiting for a scheduled audit.
The privacy-request checks are a different kind of risk entirely: not a technical door left open but a compliance deadline with a clock on it that a general security review will not catch. A pending export or deletion request that sits unactioned is not a vulnerability in the audit sense, but it is exactly the kind of thing that turns into a real problem if it surfaces on its own timetable rather than a checklist’s.
Joomla
Super Admin Should Not Have Username "admin"
Checks for a Super Admin account using the username admin, which hands an attacker half the credentials they need to log in as you.
Avoid MD5 Hashed Passwords (May Indicate Hacked Site)
Looks for 32-character MD5 password hashes in the users table, which Joomla never creates itself and which point to manual tampering with the database.
Enable Two-Factor Authentication Plugins
Checks whether any Two-Factor Authentication plugin is enabled site-wide, since nobody can turn on 2FA if no plugin offers it.
Fixable in one click
Disable User Registration Unless Required
Checks whether public account registration is switched on, since an open signup form invites spam bots and gives attackers an easy foothold.
Fixable in one click9% of the Joomla sites we have this data for fail it
Default Group For New Users Should Not Be Admin Or Super Admin
Checks which user group new registrations are placed into by default, because finding it set to Super Admin is a known sign the site has been hacked.
Limit The Number Of Super Admins To One
Find sites where more than one account holds full Super User rights
Use Two-Factor Authentication On All Super User Accounts
Checks every Super Admin account for two-factor or multi-factor authentication, since a stolen password alone should never be enough to log in as one.
Check For Joomla.user.helper.XXXX Usernames (2016 Hack Indicator)
Looks for usernames matching Joomla.user.helper.XXXX, the pattern a 2016 mass-hack created automatically, so finding one means the site was compromised.
Remove "Never Logged In" Accounts
Lists accounts that have never once logged in, usually spam registrations or abandoned signups that still count as personal data you are holding.
Lists non-admin accounts that have not logged in for 180 days or more, since an unused account is a credential nobody is watching.
Unactivated Users
Lists registered accounts still waiting on email activation, since a large or growing backlog is usually spam signups rather than real visitors.
Blocked Users
Counts accounts an administrator has blocked from logging in, since a growing pile of them usually means spam or abuse nobody has finished dealing with.
Privacy: Review Overdue Privacy Requests
Flags GDPR export or erasure requests that have passed their statutory deadline and now need immediate action to avoid a compliance breach.
Privacy: Review Pending Export Requests
Flags GDPR data export requests still waiting on the requester's email confirmation, the first stage of a legal deadline you need to track.
Privacy: Review Pending Remove Requests
Flags GDPR erasure requests still waiting on the requester's email confirmation, the first stage of a legal deadline you need to track.
Privacy: Process Confirmed Export Requests
Flags GDPR data export requests the user has confirmed by email, which now sit on a legal deadline until you actually export their data.
Privacy: Process Confirmed Remove Requests
Flags GDPR erasure requests the user has confirmed by email, which now sit on a legal deadline until you actually delete their data.
Privacy: Remove Completed Export Requests
Flags GDPR data export requests that have already been fulfilled but are still stored on the site, and should be cleared out once delivered.
Privacy: Remove Completed Remove Requests
Flags GDPR erasure requests that have already been carried out but are still logged on the site, and should be cleared out now the data is gone.
Users In No User Group
Find users who belong to no user group across all your sites
WordPress
"Anyone can register" should be disabled unless required
Checks whether WordPress lets anyone create an account, which widens the attack surface for any exploit that only needs a logged-in user.
Fixable in one click
New User Default Role Should Not Be Administrator
Checks the role WordPress assigns to new sign-ups: finding it set to Administrator is a common sign the site has already been compromised.
Limit The Number Of Administrators To One
Counts WordPress accounts in the Administrator role: every extra one is another set of credentials that can compromise the whole site.
Avoid Using "admin" As A Username
Looks for a WordPress account named exactly admin, which hands a brute-force attacker half the login before they have guessed anything.
Inactive Users (180+ Days)
Lists WordPress accounts that have not logged in for 180 or more days, the ones nobody would notice being misused if compromised.
Unactivated Users
Lists WordPress accounts with a live activation link that was never completed, left over from sign-ups nobody finished.
Blocked Users
Lists WordPress accounts you have blocked from logging in, so you can confirm each one still deserves to stay blocked or delete it outright.
Avoid MD5 Hashed Passwords (May Indicate Hacked Site)
WordPress has not stored passwords as raw MD5 since 2008, so finding one today usually means the database was edited directly, not through WordPress.
Privacy: Keep Pending Export Requests At Zero
Flags GDPR data export requests still waiting to be actioned, which risks missing the statutory deadline for responding to the user.
Privacy: Keep Pending Remove Requests At Zero
Flags GDPR erasure requests still waiting to be actioned, which risks missing the statutory deadline for responding to the user.
Privacy: Remove Completed Export Requests
Flags GDPR data export requests already fulfilled but still logged in WordPress, which is queue clutter you should clear out.
Privacy: Remove Completed Remove Requests
Flags GDPR erasure requests already fulfilled but still logged in WordPress, which is queue clutter you should clear out.
Users With No Role
Find users who have no role across all your WordPress sites
Find out which of these your sites fail
Connect a site and every check in this group runs against it automatically, with the result and the fix in one place. These run twice a day on every connected site.
Run a free audit