MuRu Guard 5.3.0: Country Lookups on Your Own Server and a Hardening Pass

MuRu Guard 5.3.0 is a protection and privacy update. Country blocking now answers from a database stored on your own site, so your visitors' IP addresses no longer go to an outside lookup service. We also did a hardening pass on MuRu Guard itself, reviewing it the way an attacker would, and closed the gaps that review found: places a webshell could hide from the scan, a way to fake a visitor's IP behind a proxy, and a rule that blocked ordinary contact messages. It also helps you through the PHP2Shell PHP flaw, finds scripts planted in article options, and scheduled scans work again on Joomla 6.1.

• Country lookups on your own server
• The real visitor IP, even behind a proxy
• No more hiding places for webshells
• Scripts hidden in article options
• Shield blocks the right things
• PHP2Shell: what Joomla site owners should do
• Scheduled scans
• For Pro
• Upgrade checklist
• FAQ

Country lookups on your own server

Country blocking, the Threat Monitor's countries and the new-country login alert all need to know where an IP address is. Until now MuRu Guard asked a free online service, over plain HTTP, once for every new visitor, and kept a file of every IP it had looked up. That service limits how many lookups a site may make and does not allow commercial use, so on a busy site country blocking could quietly stop working.

From 5.3.0 your site keeps its own copy of the free DB-IP country database, about 4 MB, downloaded directly from DB-IP and refreshed every month by the scheduled scan. Every lookup is answered from disk in a fraction of a millisecond, and no visitor IP leaves your server. The old file of looked-up IPs is deleted on update.

Under the blocked-countries field you see the database date and an Update now button. A new copy is checked before it replaces the old one, and if the database is ever missing, visitors are allowed through rather than blocked.

[SCREENSHOT: Site Protection, the blocked-countries field with the database date and the Update now button]

The real visitor IP, even behind a proxy

Behind Cloudflare or a load balancer, the visitor's IP arrives in a header such as X-Forwarded-For. Earlier versions believed that header from anyone once you selected it, and used its first address. If your server could also be reached directly, a visitor could send the header themselves and pick any IP, even one on your allow list.

Now the header is read only when the request comes from a trusted proxy, and X-Forwarded-For is read from the right, where your own proxy writes. A new Trusted proxy IPs setting lists your proxy. Local proxies and Cloudflare are recognised without it.

No more hiding places for webshells

• Trusted-looking folders. MuRu Guard skips the folders of Akeeba, Admin Tools, RSFirewall and htProtect, which contain security code that looks like malware. That skip used to match the folder name anywhere in a path, so a webshell under images/administrator/components/com_akeeba/ was never scanned or watched. Now only the real folders are skipped.
• MuRu Guard's own data folder. Snapshots of cleaned files naturally contain the malware that was removed, so they are exempt from the content check. That exemption now applies only to snapshots MuRu Guard really wrote. Any other file placed there is reported as unexpected.
• Files marked safe. A file you marked safe stays hidden only while its contents are unchanged. If someone replaces it, it shows up again.

Scripts hidden in article options

A script can sit in an article without being in its text. Helix Ultimate stores a post's audio, video and gallery embed code in the article's options and prints it on the page as raw HTML, so a <script> or an onload= handler planted there runs for every visitor while the article text looks perfectly clean. The scan never looked there.

The Pro article scan now also reads each article's options (the attribs, images, urls and meta fields). It flags scripts, onload and onerror handlers, <object> and <embed> elements, javascript: links and iframes from unknown hosts, and the finding says article options in the reason so you know where to look.

A Clean options button on those findings removes the script from the article's options only. The article text and every other setting stay. It tries to remove just the bad parts, such as the script or the handler, and keeps a legitimate YouTube or Vimeo embed when nothing else is wrong. If something bad is still left in a field afterwards, that one field is emptied. A snapshot is taken first, so you can restore the original from Protected Repairs, and a row that cannot be cleaned safely is left alone.

[SCREENSHOT: the Content SEO-Spam finding with the "article options" reasons and the Clean options button]

Shield blocks the right things

• Fewer false blocks. The code-execution rule used to block a contact message like "my operating system (Windows 11) keeps crashing". It now needs the shape of a real PHP call, so ordinary text passes and real payloads are still blocked.
• Administrators are not a blind spot. A logged-in admin is still exempt from rate limits, country and blocklist checks, but a high-severity attack payload is now blocked for them too, so a hijacked admin session cannot carry an exploit past Shield. Saving articles in the backend is not affected.
• Steady under a flood. The failed-login store is capped, and the attack log skips an entry rather than making requests queue behind its file lock.

PHP2Shell: what Joomla site owners should do

In October 2026 two critical flaws in PHP itself were published, together called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). A crafted upload request can run code on the server while PHP is still reading the request, before Joomla starts. That means no Joomla extension can block it from inside PHP, MuRu Guard included. Attacks were reported within a day of the details leaking.

What MuRu Guard 5.3.0 does about it:

• Tells you whether you are exposed. The dashboard's PHP banner warns when your PHP is behind on security releases, and the PHP configuration audit (Pro) now has a PHP2Shell row that checks your exact version and the session.upload_progress.enabled setting the attack uses.
• Stops the attack before it reaches PHP. Every known PHP2Shell request is a file upload. Upload lockdown (Settings, Site Protection, Emergency) makes the web server refuse uploads, so they never reach PHP. On an unpatched PHP it now shows a red notice and includes the administrator area by default, because the attack works on any page. On nginx it gives you the matching rule to paste.
• Helps you check afterwards. If your site was exposed, run a full scan: file integrity monitoring, the webshell signatures and the new-Super-User check show what an attacker left behind.

Steps for a Joomla site:

1. Update PHP, or ask your host for the patched version.
2. Until then, switch on Upload lockdown with the administrator area included, and turn session.upload_progress.enabled off in your PHP settings.
3. After updating, switch Upload lockdown off, run a full MuRu Guard scan, and change your database password, Joomla's secret and any API keys, because one of the flaws can leak server memory.

Scheduled scans

• They work again on Joomla 6.1, where the webcron URL returned a 502 error.
• The token must be at least 32 characters (use the Generate button) and can be sent in an X-MuruGuard-Token header, which keeps it out of server logs.
• A scan runs at most once every 5 minutes and never twice at once, and a wrong token is slowed down.
• With the secret administrator URL on (Pro), a call with the correct token reaches the scan instead of the hidden-admin page.

For Pro

• Signature feed. Patterns that would be slow are refused before use, and virtual patches run with a limit, so one bad rule cannot slow your site.
• Fleet commands can switch a protection on, but turning one off needs an admin on the site.
• The AI assistant cannot read database dumps, backups, logs or key files, cannot write PHP into upload or cache folders or create server configuration files, and treats file contents as data rather than instructions.

Upgrade checklist

1. Update the MuRu Guard component to 5.3.0 and the Shield plugin to 2.3.0.
2. If you use country blocking, open Settings, Site Protection and check that the database date is shown.
3. Behind a public proxy that is not Cloudflare? Add it under Trusted proxy IPs.
4. Using scheduled scans? If your token is shorter than 32 characters, generate a new one and update your cron job.
5. Run a scan and look at Content SEO-Spam. A finding that says "article options" can be cleaned with the Clean options button.
6. Check your PHP version: PHP2Shell is only fixed by updating PHP.

Frequently asked questions

Country data: IP Geolocation by DB-IP.