Changelog & Roadmap

Added

• Backend account-hygiene audit (G1). Dormant-admin, never-logged-in, and password-never-changed reviews with one-click snapshot of protected users, plus a configurable dormancy threshold in Site Protection.
• Article + Custom-HTML-module SEO-spam scan (G2). Hidden-link/keyword-stuffing detection across articles and Custom HTML modules, reusing the standard finding pipeline (false-positive dismissal, AI review).
• Rogue scheduled-task audit (G3). Flags unknown/orphaned Joomla scheduler tasks that survive as persistence vectors, with the same row actions as other findings.
• Runtime hardening verification (G4). Probes what the live PHP runtime actually enforces (vs. what files on disk claim) and reports gaps with fix guidance.
• TLS certificate-expiry watch (G5). Warns before watched domains' certificates expire, with configurable lead days.
• Privileged login-success alerting (G6). Opt-in email the first time a Super User / Administrator / Manager logs in from a never-before-seen IP or country — brute-force blocking only catches wrong guesses; this catches the right (stolen) one. Needs Shield 2.1.0 (onUserLogin hook); alerting never blocks the login itself, even on failure.
• "I'm hacked" incident-response mode (G7). Guided lockdown checklist with step tracking, composing everything above into one capstone flow.
• Site Protection sub-tabs. The tab's seven groups (🚦 Request blocking, 🔑 Login protection, 🧹 Hardening, 🗂️ Backups & integrity, 🚧 Access lists, 🚨 Emergency, 📋 Activity log) are now switchable sub-tabs — one visible at a time, Request blocking open first — instead of one very tall scroll. The save always lands back on the sub-tab it came from. IP Access List and Known-Bad Hashes stay permanently open inside Access lists (no more expanders).
• Enable all / Disable all per group. One smart button on each toggle-heavy group (Request blocking, Login protection, Hardening) flips every switch in that tab at once; disabled switches (missing Shield plugin, Pro-gated) are never touched.
• Alert channel picker that remembers. The 🔔 Instant Alert Channels selector (Slack/Discord/Telegram) is now a saved preference instead of resetting on every reload.
• AI provider loading that can't hang forever. A 30-second client-side ceiling with a plain-English timeout message, plus a proper "no providers came back" message instead of a stuck "Testing…".

Changed

• Readable type scale across Settings. Body/description copy renders at 14px and headings at 16px in a standard system font stack (badges and mono microcopy keep their designed sizes).
• License key is masked like a password and a blank save means "no change", never "clear".

Fixed

• AI provider editor no longer stuck on "Testing…" when the dashboard returns an empty provider list.
• Alert channel selection lost on save (the picker never posted its value).
• Protection Log card markup could stay unclosed on an empty log; card and panel now close unconditionally.

Added

• Backend account-hygiene audit (G1). Dormant-admin, never-logged-in, and password-never-changed reviews with one-click snapshot of protected users, plus a configurable dormancy threshold in Site Protection.
• Article + Custom-HTML-module SEO-spam scan (G2). Hidden-link/keyword-stuffing detection across articles and Custom HTML modules, reusing the standard finding pipeline (false-positive dismissal, AI review).
• Rogue scheduled-task audit (G3). Flags unknown/orphaned Joomla scheduler tasks that survive as persistence vectors, with the same row actions as other findings.
• Runtime hardening verification (G4). Probes what the live PHP runtime actually enforces (vs. what files on disk claim) and reports gaps with fix guidance.
• TLS certificate-expiry watch (G5). Warns before watched domains' certificates expire, with configurable lead days.
• Privileged login-success alerting (G6). Opt-in email the first time a Super User / Administrator / Manager logs in from a never-before-seen IP or country — brute-force blocking only catches wrong guesses; this catches the right (stolen) one. Needs Shield 1.6.0 (onUserLogin hook); alerting never blocks the login itself, even on failure.
• "I'm hacked" incident-response mode (G7). Guided lockdown checklist with step tracking, composing everything above into one capstone flow.
• Site Protection sub-tabs. The tab's seven groups (🚦 Request blocking, 🔑 Login protection, 🧹 Hardening, 🗂️ Backups & integrity, 🚧 Access lists, 🚨 Emergency, 📋 Activity log) are now switchable sub-tabs — one visible at a time, Request blocking open first — instead of one very tall scroll. The save always lands back on the sub-tab it came from. IP Access List and Known-Bad Hashes stay permanently open inside Access lists (no more expanders).
• Enable all / Disable all per group. One smart button on each toggle-heavy group (Request blocking, Login protection, Hardening) flips every switch in that tab at once; disabled switches (missing Shield plugin, Pro-gated) are never touched.
• Alert channel picker that remembers. The 🔔 Instant Alert Channels selector (Slack/Discord/Telegram) is now a saved preference instead of resetting on every reload.
• AI provider loading that can't hang forever. A 30-second client-side ceiling with a plain-English timeout message, plus a proper "no providers came back" message instead of a stuck "Testing…".

Changed

• Readable type scale across Settings. Body/description copy renders at 14px and headings at 16px in a standard system font stack (badges and mono microcopy keep their designed sizes).
• License key is masked like a password and a blank save means "no change", never "clear".

Fixed

• AI provider editor no longer stuck on "Testing…" when the dashboard returns an empty provider list.
• Alert channel selection lost on save (the picker never posted its value).
• Protection Log card markup could stay unclosed on an empty log; card and panel now close unconditionally.

All items below are Pro features (require an active license). Settings layout changed: the dashboard cards moved into a new Settings > Analysis tab, and the free-tier Gemini key section was removed from Settings (Pro uses the separate AI key tabs).

Added

• Search code by snippet. Paste any code fragment -- for example an indicator your host sent you -- and find every file on the site containing it, with line numbers and previews. Literal (default, safe for pasted PHP) and Regex modes, scope selector per scan area, read-only: nothing is changed by searching. Shares its search core with the AI assistant's search_project tool, so both inherit the same deny-list, size caps, and limits. Each result row reuses the ✅ false-positive button and the 🤖 Check-via-AI review.
• Quarantine (reversible alternative to Delete). 📦 Quarantine Selected sits next to 🗑 Delete Selected -- Delete stays for the sure cases. Quarantined files are renamed so the web server can never execute them (plus .htaccess deny and index.html), recorded in a manifest with one-click Restore (refuses rather than overwrites an occupied path) and Delete forever. Same path guards and TimeMachine snapshots as Delete, and quarantined payloads are skipped by scans, FIM baselines, and AI search so they can never be re-flagged from quarantine.
• Custom signatures. Your own content signatures, checked against every scanned file alongside the built-in set (raw pass, decoded pass, and ZIP entries). PCRE pattern body per row with severity and label; invalid rows reject the whole batch with the offending row numbered, and patterns matching the empty string or plain benign text are refused so a typo can never flag the whole site.
• Findings export (CSV/JSON). Download exactly the finding set the results show (false-positive dismissals applied) for tickets and client reports. Raw matched-code snippets are stripped by default via an opt-in checkbox, so payload bytes never leave the site by accident.
• "New since last scan" filter. Manual and chunked scans now record the same finding baseline the scheduled check uses, and a 🆕 toggle on both file tabs narrows the lists to paths that appeared since the previous run. Server-side, so counts, pagination, and bulk actions stay consistent; the toggle and the scheduled alert emails can never disagree.
• Temporary IP auto-block. Block 1h / 24h / 7d straight from any Protection Log row, or with an expiry from the manual IP form. Expired blocks stop enforcing immediately but stay visible as grey history (swept 90 days past expiry); permanent entries work exactly as before. No Shield plugin change -- enforcement flows through the same checkIpList() gate.
• Update audit card. Prevention next to the cure: PHP version against its security-support dates, installed versions of the two covered attack vectors (SP Page Builder < 6.6.2 flagged vulnerable; JCE shown with a verify note, no invented floor), and outdated extensions from Joomla's own update cache. Read-only, with a link to Joomla's updater.

Changed

• New Settings > Analysis tab (after Site Protection) hosting Search code by snippet, the Update audit card (both moved off the dashboard), and the 🧪 Test a Request simulator (moved from Site Protection -- it is a read-only analysis tool, not a protection control).
• Custom signatures card moved to directly after Page display in General settings.

Added

• Search code by snippet. Paste any code fragment -- for example an indicator your host sent you -- and find every file on the site containing it, with line numbers and previews. Literal (default, safe for pasted PHP) and Regex modes, scope selector per scan area, read-only: nothing is changed by searching. Shares its search core with the AI assistant's search_project tool, so both inherit the same deny-list, size caps, and limits. Each result row reuses the ✅ false-positive button and the 🤖 Check-via-AI review.
• Quarantine (reversible alternative to Delete). 📦 Quarantine Selected sits next to 🗑 Delete Selected -- Delete stays for the sure cases. Quarantined files are renamed so the web server can never execute them (plus .htaccess deny and index.html), recorded in a manifest with one-click Restore (refuses rather than overwrites an occupied path) and Delete forever. Same path guards and TimeMachine snapshots as Delete, and quarantined payloads are skipped by scans, FIM baselines, and AI search so they can never be re-flagged from quarantine.
• Custom signatures. Your own content signatures, checked against every scanned file alongside the built-in set (raw pass, decoded pass, and ZIP entries). PCRE pattern body per row with severity and label; invalid rows reject the whole batch with the offending row numbered, and patterns matching the empty string or plain benign text are refused so a typo can never flag the whole site.
• Findings export (CSV/JSON). Download exactly the finding set the results show (false-positive dismissals applied) for tickets and client reports. Raw matched-code snippets are stripped by default via an opt-in checkbox, so payload bytes never leave the site by accident.
• "New since last scan" filter. Manual and chunked scans now record the same finding baseline the scheduled check uses, and a 🆕 toggle on both file tabs narrows the lists to paths that appeared since the previous run. Server-side, so counts, pagination, and bulk actions stay consistent; the toggle and the scheduled alert emails can never disagree.
• Temporary IP auto-block. Block 1h / 24h / 7d straight from any Protection Log row, or with an expiry from the manual IP form. Expired blocks stop enforcing immediately but stay visible as grey history (swept 90 days past expiry); permanent entries work exactly as before. No Shield plugin change -- enforcement flows through the same checkIpList() gate.
• Update audit card. Prevention next to the cure: PHP version against its security-support dates, installed versions of the two covered attack vectors (SP Page Builder < 6.6.2 flagged vulnerable; JCE shown with a verify note, no invented floor), and outdated extensions from Joomla's own update cache. Read-only, with a link to Joomla's updater.

Changed

• New Settings > Analysis tab (after Site Protection) hosting Search code by snippet, the Update audit card, and the 🧪 Test a Request simulator (moved from Site Protection -- it is a read-only analysis tool, not a protection control).
• Custom signatures card directly after Display in General settings.

Added

• Search code by snippet. Paste any code fragment -- for example an indicator your host sent you -- and find every file on the site containing it, with line numbers and previews. Literal (default, safe for pasted PHP) and Regex modes, scope selector per scan area, read-only: nothing is changed by searching. Shares its search core with the AI assistant's search_project tool, so both inherit the same deny-list, size caps, and limits. Each result row reuses the ✅ false-positive button and the 🤖 Check-via-AI review.
• Quarantine (reversible alternative to Delete). 📦 Quarantine Selected sits next to 🗑 Delete Selected -- Delete stays for the sure cases. Quarantined files are renamed so the web server can never execute them (plus .htaccess deny and index.html), recorded in a manifest with one-click Restore (refuses rather than overwrites an occupied path) and Delete forever. Same path guards and TimeMachine snapshots as Delete, and quarantined payloads are skipped by scans, FIM baselines, and AI search so they can never be re-flagged from quarantine.
• Custom signatures. Your own content signatures, checked against every scanned file alongside the built-in set (raw pass, decoded pass, and ZIP entries). PCRE pattern body per row with severity and label; invalid rows reject the whole batch with the offending row numbered, and patterns matching the empty string or plain benign text are refused so a typo can never flag the whole site.
• Findings export (CSV/JSON). Download exactly the finding set the results show (false-positive dismissals applied) for tickets and client reports. Raw matched-code snippets are stripped by default via an opt-in checkbox, so payload bytes never leave the site by accident.
• "New since last scan" filter. Manual and chunked scans now record the same finding baseline the scheduled check uses, and a 🆕 toggle on both file tabs narrows the lists to paths that appeared since the previous run. Server-side, so counts, pagination, and bulk actions stay consistent; the toggle and the scheduled alert emails can never disagree.
• Temporary IP auto-block. Block 1h / 24h / 7d straight from any Protection Log row, or with an expiry from the manual IP form. Expired blocks stop enforcing immediately but stay visible as grey history (swept 90 days past expiry); permanent entries work exactly as before. No Shield plugin change -- enforcement flows through the same checkIpList() gate.
• Update audit card. Prevention next to the cure: PHP version against its security-support dates, installed versions of the two covered attack vectors (SP Page Builder < 6.6.2 flagged vulnerable; JCE shown with a verify note, no invented floor), and outdated extensions from Joomla's own update cache. Read-only, with a link to Joomla's updater.

Changed

• New Settings > Analysis tab (after Site Protection) hosting Search code by snippet, the Update audit card (both moved off the dashboard), and the 🧪 Test a Request simulator (moved from Site Protection -- it is a read-only analysis tool, not a protection control).
• Custom signatures card moved to directly after Page display in General settings.

Added

• Full Migration - one export, one import (All-in-One style) - a new default "Full Migration" tab packs the entire site (users, groups, articles, categories, images, menus, modules) into a single portable ZIP package (manifest.json + per-section files). Import the package on another Joomla site and migrate everything in one guided process, in dependency order (users → articles/categories → menus → modules), with menu assignments, alias targets, article links, and related references remapped automatically.

• Full Migration Dry Run - preview the complete migration before making any database changes. The dry-run process reports items to import, update, skip, missing extensions, unresolved references, and potential migration issues section by section.

• Automatic ID and Reference Remapping - source-site IDs are automatically mapped to the corresponding target-site IDs during Full Migration, allowing related menus, articles, categories, aliases, module assignments, and other references to remain connected correctly after migration.

• Advanced Migration Mode - the individual migration tools remain available under "Advanced" for selective exports and imports:

  • Modules
  • Menus
  • Articles
  • Users

• Improved Cross-Site Migration Support - migration workflows are designed to handle differences between source and target Joomla sites while preserving relationships between imported content.

Improved

• Safer Menu Migration - imported menu structures are rebuilt using the target site's Joomla menu tree instead of directly copying source nested-set values.

• Safer Category Migration - category parent relationships are resolved using mapped IDs and aliases, while Joomla category tree structure is rebuilt after import.

• Improved User Group Migration - user groups are matched by title and missing groups are created with the correct hierarchy before users are assigned to them.

• Improved Module Assignment Migration - module menu assignments are mapped to the correct target-site menu items and invalid assignments are skipped with a warning instead of being linked to unrelated pages.

• Improved Home Page Handling - existing default/home menu items are detected during migration to prevent duplicate home pages.

• Improved Alias and Article Link Handling - alias menu items and com_content article links are remapped to their corresponding target-site IDs.

• Automatic Menu Type Handling - required menu types referenced by imported menu items are created when they are missing from both the migration package and target site, with schema-aware handling for supported Joomla versions.

• Clearer Migration Feedback - improved warnings and migration results make it easier to identify missing extensions, unresolved references, conflicting items, and other migration issues.

Fixed

• Menu tree corruption on non-empty sites - imported menu items no longer reuse source-site lft, rgt, level, and path values.

• Category tree corruption - category structural fields are no longer incorrectly copied between sites, preventing broken category hierarchies.

• Incorrect module menu assignments - module assignments are now validated against the target site's mapped menu IDs.

• Duplicate home page conflicts - imported home menu items are disabled when a conflicting default home page already exists for the same language.

• User group ID collisions - users are no longer assigned to unrelated groups when source and target Joomla sites contain different group IDs.

• Alias menu reference issues - params.aliasoptions references are correctly remapped after migration.

• Article menu link issues - com_content article menu links are correctly updated when corresponding articles and categories are migrated.

• Uninstall database cleanup - uninstall now removes both the current #__murumigration_idmaps table and the legacy #__easyimportexport_idmaps table.

Migration Guidance

• Recommended migration flow: use Full Migration when you want to migrate the complete supported site data in one package.

• Selective migration: use the tools under Advanced when you only need to migrate specific data types.

• Use Dry Run first: run the dry-run preview before importing into a production site to identify missing extensions, existing items, reference issues, and other potential conflicts.

• Recommended dependency order for Advanced migration: users → articles/categories → menus → modules.

• Always keep a backup of the target Joomla site before performing a production migration.

Added

• New detections for the July 2026 QRIS-phishing dropper campaign — Indonesian-language curl/ROT13 loaders dropped into template and layout trees of compromised sites:

  • rot13_url_loader content signature (high confidence): catches loaders hiding their remote payload URL behind ROT13 (uggc://… is ROT13 for http://), confirmed sample templates/cassiopeia/html/layouts/chromes/yesCard.php. Matches the technique, not one domain, so a re-registered host under the same trick is still caught.
  • qris_pwn_c2_domains content signature (high confidence): exact payload/C2 host IOCs from the campaign — qris-pwn.pages.dev, asukontol.pages.dev and the ROT13-decoded host used by the yesCard.php variant — wherever they appear (PHP, HTML, any scanned text file), including as an injected link.
  • pages_dev_txt_payload_fetch content signature (review severity): the campaign's generic delivery shape — a remote .txt fetched from any *.pages.dev host — so a rotated subdomain the exact-IOC signature doesn't know yet is still surfaced for review.
  • gif_header_php_masquerade check: a non-image file opening with a GIF image header followed immediately by PHP code (confirmed sample layouts/plugins/perek.php).
  • Filename IOCs yesCard.php and perek.php, matched on the bare basename at any location.

• Rogue core-layouts structural check (checkRogueCoreLayoutFile()): flags any executable file placed in a Joomla core layouts/ tree where a clean install ships none — directly inside layouts/plugins/ (subdirectories only in a clean install), inside layouts/chromes/ (only none/outline/table/html5 ship there), or as a lookalike name beside real core layout files. The allowlist was verified against the Joomla 3.10 / 4.4 / 5.3 core trees. The check applies at the webroot, administrator/layouts/, multisite subsites/<name>/layouts/ roots (each subsite is its own full Joomla root — confirmed real drops were found there), and the TinyMCE tinymcebuilder field-layout directory inside template override trees (confirmed sample: setsettings.php mimicking core setoptions.php). Custom template chromes/plugin-layout overrides elsewhere remain allowed, so legitimate overrides (Atum's own chromes, Cassiopeia's card/noCard) are unaffected.

• New scan area: top-level layouts/ is now walked in code mode and appears in the scan-areas picker. Previously the directory was recognized by name but its files never received structural checks — a dropped layouts/plugins/perek.php was invisible to the scanner.

Added

• New detections for the July 2026 QRIS-phishing dropper campaign — Indonesian-language curl/ROT13 loaders dropped into template and layout trees of compromised sites:

  • rot13_url_loader content signature (high confidence): catches loaders hiding their remote payload URL behind ROT13 (uggc://… is ROT13 for http://), confirmed sample templates/cassiopeia/html/layouts/chromes/yesCard.php. Matches the technique, not one domain, so a re-registered host under the same trick is still caught.
  • qris_pwn_c2_domains content signature (high confidence): exact payload/C2 host IOCs from the campaign — qris-pwn.pages.dev, asukontol.pages.dev and the ROT13-decoded host used by the yesCard.php variant — wherever they appear (PHP, HTML, any scanned text file), including as an injected link.
  • pages_dev_txt_payload_fetch content signature (review severity): the campaign's generic delivery shape — a remote .txt fetched from any *.pages.dev host — so a rotated subdomain the exact-IOC signature doesn't know yet is still surfaced for review.
  • gif_header_php_masquerade check: a non-image file opening with a GIF image header followed immediately by PHP code (confirmed sample layouts/plugins/perek.php).
  • Filename IOCs yesCard.php and perek.php, matched on the bare basename at any location.

• Rogue core-layouts structural check (checkRogueCoreLayoutFile()): flags any executable file placed in a Joomla core layouts/ tree where a clean install ships none — directly inside layouts/plugins/ (subdirectories only in a clean install), inside layouts/chromes/ (only none/outline/table/html5 ship there), or as a lookalike name beside real core layout files. The allowlist was verified against the Joomla 3.10 / 4.4 / 5.3 core trees. The check applies at the webroot, administrator/layouts/, multisite subsites/<name>/layouts/ roots (each subsite is its own full Joomla root — confirmed real drops were found there), and the TinyMCE tinymcebuilder field-layout directory inside template override trees (confirmed sample: setsettings.php mimicking core setoptions.php). Custom template chromes/plugin-layout overrides elsewhere remain allowed, so legitimate overrides (Atum's own chromes, Cassiopeia's card/noCard) are unaffected.

• New scan area: top-level layouts/ is now walked in code mode and appears in the scan-areas picker. Previously the directory was recognized by name but its files never received structural checks — a dropped layouts/plugins/perek.php was invisible to the scanner.

✨ New — a much deeper design knowledge base

The model behind every generation now works from a far more detailed, verified reference of how SP Page Builder's addons actually behave — not just their names.

• Sliders, carousels, tabs, accordions, galleries, forms, tables and 20+ other addons are now filled with real, complete content instead of arriving with SP Page Builder's single placeholder slide/item. A carousel gets several real slides; a pricing table's rows are filled in; a contact form gets fields that match what was actually asked for.
• Style presets are now chosen deliberately, not left at their plainest default. Addons like Person, Image Carousel, Team Carousel and Testimonial Carousel offer several distinct visual layouts — generation now understands what each one actually looks like and picks the one that fits the request, instead of silently falling back to the first option.
• Addons that need a real external account are left alone. Social feeds, email-marketing sign-ups, map/API-key integrations and similar addons are no longer given invented credentials or fake reference IDs that would silently fail — they're left at safe defaults for you to connect afterward.
• The 10 built-in "Start from a template" prompts are now full content briefs — SaaS landing page, About Us, Pricing, Team, Testimonials and the rest each specify real section counts, named pricing plans, benefit-driven headlines and realistic FAQ topics, so the result reads like a finished page rather than a wireframe that still needs a copywriting pass.

🐛 Fixed

• Dynamic Content collection pages: location and video fields were bound to the wrong addon. They printed as raw text (e.g. a JSON coordinate blob) instead of the map or video player SP Page Builder actually renders for them. Fixed.
• Item cards on a generated collection index page could all link to the same place instead of their own detail page. Traced to a missing item "alias" that SP Page Builder's own routing depends on — new sample records now get one. The in-app instructions for the one remaining manual step (a menu item pointing at the collection, which SP Page Builder itself also requires) are now specific about exactly what to add.
• "Color" was never a real Dynamic Content field type on this install and could be offered when designing a new collection's fields. Removed.
• Removed a floating button on the Dynamic Content screen that could read as acting on the collection you had open when it wasn't necessarily the one you meant — New Collection with AI, next to Import/Export, is now the one clear way to start a new collection from that screen. To regenerate an existing collection's index/detail pages, open that page directly and use the normal Generate AI Page button, which already detects the binding.

✨ New — sample data that looks like real data

• A newly created collection's sample records now get real coordinates for location fields (an actual place, not 0,0) and real stock photos for image/gallery fields, so a fresh collection looks populated instead of empty or broken on first look.

Added

• Joomla 3.10 support. The scanner component and the MuRu Guard Shield plugin now install and run on Joomla 3.10 (PHP 7.4–8.x). Database access falls back to getDbo(), the current-user lookup falls back to Factory::getUser(), the post-install cache clear uses Cache::getInstance() instead of the Joomla 4 DI container, the NotAllowed ACL exception is aliased from its Joomla 3 namespace, and str_contains / str_starts_with / str_ends_with are polyfilled. This edition bundles the component and the Shield plugin in one package (pkg_muruguard); the Quick Icons plugin and admin status module (Joomla-4-only in structure) are not included.

• Legacy Extension Virtual Patch (Pro, opt-in — Settings ▸ Site Protection). A real-time request firewall pass that blocks the publicly-disclosed unauthenticated SQL injection, RCE and path-traversal request shapes in the Joomla 3 builds of SP Page Builder, Helix (framework & Ultimate), EasyStore and SP Property Finder — versions those sites can no longer update to a patched release. Off by default. Each rule only acts when its target extension is actually installed (and still on a vulnerable version), and never fires on a normal authenticated, token-bearing editor request, so genuine use of those extensions is unaffected. Every blocked attempt is written to the Protection Log with the CVE. Rules cover:

  • SP Page Builder uploadCustomIcon unauthenticated arbitrary-file-upload RCE (pre-6.6.2)
  • SP Page Builder unauthenticated SQL injection in the article-loading endpoint (a= parameter) — best-effort signature, tightened as the upstream advisory / patched build becomes available
  • SP Page Builder dynamic_content direction ORDER BY SQL injection — CVE-2026-65766
  • SP Page Builder media JSON view search / date SQL injection — CVE-2026-65877
  • SP Page Builder media controller path traversal (delete / rename / upload) — CVE-2026-65878 and the 6.9.x media fixes
  • "Content - SP Page Builder" plugin jform[attribs][sppagebuilder_article_id] SQL injection (Author-level)
  • SP Page Builder contact-addon captcha bypass (captcha_type=default / view_type=module) — CVE-2026-65879
  • Helix3 onAjaxHelix3 unauthenticated file write / delete / template-parameter overwrite via path traversal
  • Helix Ultimate remove_image arbitrary media-file delete via a mismatched ACL check
  • EasyStore checkout.orderRepay unauthenticated order/payment forgery
  • EasyStore filter_sortby unauthenticated ORDER BY SQL injection — CVE-2026-65760
  • EasyStore checkout.searchGuestUser unauthenticated PII enumeration
  • EasyStore order/invoice view IDOR — CVE-2026-65761 (detection-only; ownership cannot be verified from the request)
  • SP Property Finder property-search zipcode / price / size / sorting SQL injection — CVE-2026-78082

Fixed

• Joomla 3 core files no longer flagged as suspicious. The "non-standard index.php", double-extension filename, and loose-file-in-a-core-directory heuristics all encoded the Joomla 4+ tree layout:

  • On Joomla 3, controllers/index.php, models/index.php, views/index.php … are real legacy-MVC class files (FinderControllerIndex extends JControllerAdmin), not blank "no direct access" stubs. A non-stub index.php inside a Joomla 3 MVC sub-folder that carries the standard _JEXEC / JPATH_ access guard is now treated as legitimate (the content-signature scan still runs on it, so a guardless dropped index.php is still caught).
  • <name>.xml.php / <name>.json.php is a standard Joomla MVC format-file convention (request.xml.php, view.xml.php, …). The /\.xml\.php$/i filename rule that flagged Joomla 3 core files such as com_privacy/controllers/request.xml.php was removed; the executable-double-extension rule (shell.php.gif, x.php.json) is unchanged.
  • cli/finder_indexer.php, cli/sessionGc.php, cli/sessionMetadataGc.php and bin/keychain.php are core Joomla 3 CLI scripts (removed in Joomla 4 when the console component replaced them) and are now on the allow-list for their directories. An unknown executable name in cli/ or bin/ is still flagged.

• Bring-your-own Gemini key box hidden on Pro. The free-tier "AI-Assisted Review (Gemini)" key field on the General settings tab is now shown only on a non-Pro site — a Pro licence configures its AI provider on the dedicated Settings ▸ Automation tab, which supersedes that key anyway.

• Form-field styling on the Joomla 3 admin. Tailwind's base reset is disabled in this component, so on the Joomla 3 admin template (isis / Bootstrap 2) every input inherited a fixed height:30px, a stray line-height, an inset box-shadow and a bottom margin, which is what made the fields look cramped and unpadded. A scoped form-control reset now neutralises those so the padding / height utilities on each field render correctly on Joomla 3 and 4/5 alike.

Fixed

• A key for a different Lyzerslab product now says so on save. 1.1.1 stopped a wrong-product key (for example a MuRu Guard free-gift key) from unlocking Pro, but the save still finished with a plain "Settings saved" and the edition quietly stayed on Free with no reason given. Saving a licence key now verifies it immediately and shows the result — an explicit "this key is not valid for MuRu Compliance Auditor, it belongs to a different Lyzerslab product" warning for a product mismatch, and matching messages for an expired, unrecognised, revoked, or site-limit-reached key.
• Correcting a licence key could stay wrong for up to an hour. The licence verdict is cached for up to LICENSE_CACHE_SECONDS (1 hour) so an ordinary page load never waits on an outbound call — but saving a changed key never reset that cache, so re-entering a corrected key (or a dashboard-side fix landing on the same key) kept echoing the OLD cached status/message until the cache happened to expire on its own, even though the save flow above already tries to show a fresh result immediately. Saving a touched licence key now resets the cache timestamp, so the very next check (the one the save itself triggers) is always a live one.

Added

• Persistent licence status line on the Settings page. Below the licence key field, a coloured status line now states whether the stored key is active, not valid for this product, expired, unrecognised, at its site limit, or simply could not be verified right now. It refreshes whenever the licence check re-runs, so the Settings page always shows the current state instead of only a Free / Pro badge.

Fixed

• A key for a different Lyzerslab product now says so on save. 1.1.1 stopped a wrong-product key (for example a MuRu Guard free-gift key) from unlocking Pro, but the save still finished with a plain "Settings saved" and the edition quietly stayed on Free with no reason given. Saving a licence key now verifies it immediately and shows the result — an explicit "this key is not valid for MuRu Compliance Auditor, it belongs to a different Lyzerslab product" warning for a product mismatch, and matching messages for an expired, unrecognised, revoked, or site-limit-reached key.
• Correcting a licence key could stay wrong for up to an hour. The licence verdict is cached for up to LICENSE_CACHE_SECONDS (1 hour) so an ordinary page load never waits on an outbound call — but saving a changed key never reset that cache, so re-entering a corrected key (or a dashboard-side fix landing on the same key) kept echoing the OLD cached status/message until the cache happened to expire on its own, even though the save flow above already tries to show a fresh result immediately. Saving a touched licence key now resets the cache timestamp, so the very next check (the one the save itself triggers) is always a live one.

Added

• Persistent licence status line on the Settings page. Below the licence key field, a coloured status line now states whether the stored key is active, not valid for this product, expired, unrecognised, at its site limit, or simply could not be verified right now. It refreshes whenever the licence check re-runs, so the Settings page always shows the current state instead of only a Free / Pro badge.

Fixed

• Self-scan false positive: MuRu Guard flagged its own helpers/muruguard.php as high severity for the x9_tools_uploader_banner content signature. The signature's own explanation text and a nearby comment contain the literal brand string it looks for, so the file matched itself. Added a narrow, per-file, per-signature exemption (the regex stays fully active against every other file).

Added

• New disguised-payload filename detections, from a real "file manager" webshell kit:
  • *.inc.json (and .inc.json.json) — the .inc counterpart of the already-caught .php.json bypass, where a server executes .inc/.json as PHP via a dropped .htaccess. *.inc.php (a normal include-file name) is deliberately not matched.
  • bob_<random>.<phpext>[.json] — the kit's payload naming (bob_9ystk.php.json, bob_goci9.phtml.json, bob_9ystk.inc.json, bare bob_x1a.php, …).

Fixed

• Self-scan false positive: MuRu Guard flagged its own helpers/muruguard.php as high severity for the x9_tools_uploader_banner content signature. The signature's own explanation text and a nearby comment contain the literal brand string it looks for, so the file matched itself. Added a narrow, per-file, per-signature exemption (the regex stays fully active against every other file).

Added

• New disguised-payload filename detections, from a real "file manager" webshell kit:
  • *.inc.json (and .inc.json.json) — the .inc counterpart of the already-caught .php.json bypass, where a server executes .inc/.json as PHP via a dropped .htaccess. *.inc.php (a normal include-file name) is deliberately not matched.
  • bob_<random>.<phpext>[.json] — the kit's payload naming (bob_9ystk.php.json, bob_goci9.phtml.json, bob_9ystk.inc.json, bare bob_x1a.php, …).

🐛 Fixed

• License verification now actually succeeds. The check never sent the product identifier the Lyzerslab dashboard's /api/license/activate endpoint requires, so every verification came back unrecognised and Pro never switched on even with a valid key. It now sends its product slug, and a key that belongs to a different Lyzerslab product (or isn't covered by a purchased plan bundle) is correctly reported as a mismatch instead of looking like a network error.
• A brief network blip no longer switches Pro off. A failed re-check now keeps the last confirmed status for that key (matching the other MuRu extensions) instead of caching the failure for up to an hour.

🔧 Changed

• All dashboard calls — license verification and the plugin's own Joomla update check — now use store.lyzerslab.com instead of the main marketing domain.

Fixed

• A MuRu Guard license key (including a free gift key) could incorrectly enable Pro here. Licence verification only checked that a pasted key looked like a key -- it never actually asked the dashboard whether that key belongs to this product. Now sends this product's identifier on every check and correctly rejects a key that belongs to a different Lyzerslab product (product_mismatch), matching how MuRu Guard's own licence check already works. Confirmed against the live dashboard.
• Pro installs were checking updates against the Free update feed. The packaged manifest's update-server URL was copied verbatim into both editions' builds, so a Pro site's own Joomla update-check silently pointed at the Free channel and would never surface a Pro-only version. Pro builds now correctly point at the Pro update feed.

Changed

• Outbound dashboard calls now go to store.lyzerslab.com instead of the main marketing domain: licence verification and the extension's own Joomla update-check. No behavior change for users; lyzerslab.com keeps serving the same routes for anyone still on an older build.

Fixed

• A MuRu Guard license key (including a free gift key) could incorrectly enable Pro here. Licence verification only checked that a pasted key looked like a key -- it never actually asked the dashboard whether that key belongs to this product. Now sends this product's identifier on every check and correctly rejects a key that belongs to a different Lyzerslab product (product_mismatch), matching how MuRu Guard's own licence check already works. Confirmed against the live dashboard.
• Pro installs were checking updates against the Free update feed. The packaged manifest's update-server URL was copied verbatim into both editions' builds, so a Pro site's own Joomla update-check silently pointed at the Free channel and would never surface a Pro-only version. Pro builds now correctly point at the Pro update feed.

Changed

• Outbound dashboard calls now go to store.lyzerslab.com instead of the main marketing domain: licence verification and the extension's own Joomla update-check. No behavior change for users; lyzerslab.com keeps serving the same routes for anyone still on an older build.

Fixed

• License verification was silently failing on every single check -- both first activation and every periodic re-check -- because the request never sent the product identifier the dashboard's /api/license/activate endpoint requires. Confirmed via live testing against the dashboard. Also added proper detection/messaging for a licence key that belongs to a different Lyzerslab product (product_mismatch) instead of it being indistinguishable from a network error.

Changed

• Outbound dashboard calls now go to store.lyzerslab.com instead of the main marketing domain: license verification, vulnerability feed, signature feed, the Renew License link, the Smart AI Assistant's dashboard calls, and the extension's own Joomla update-check (<updateservers>). No behavior change for users; lyzerslab.com keeps serving the same routes for anyone still on an older build.

Added

• New malware detections, confirmed against real dropped samples reported from a live incident: exact SHA-256 matches for a 421-byte "X9 Tools" bare file-upload webshell and a 6.5MB heavily-obfuscated PHP backdoor, plus a content-pattern signature for the "X9 Tools" webshell's self-branding and Telegram contact handle (catches re-obfuscated variants of it, not just the exact sample). The known-hash check runs independently of max_file_scan_size -- an oversized sample like the 6.5MB one no longer silently skips scanning just for being bigger than the usual scan window. Applies to the ZIP-archive content scan too, not just plain files.

Fixed

• Possible cause of "license key/settings look empty after updating." Every settings read goes through Joomla's ComponentHelper::getParams(), which caches the component registry in the _system cache group -- every save method in this codebase already knows to invalidate that cache afterward, but Joomla's own installer writes the extension's row back during an update without ever doing so itself. If the registry got cached at any point during install, the Settings panel could go on serving a stale snapshot indefinitely afterward, reading exactly like data loss even though the database row itself was untouched. postflight() now unconditionally clears the _system cache after every install/update.

Added

• Admin Lockdown. New Settings > Site Protection toggle that blocks the Joomla extension installer and creating new backend users while on -- stops a compromised admin session from installing a malicious extension or planting a fresh Super User account. Never touches Joomla's own core updates or editing an existing user (including your own profile). Off by default.
• Protected User Snapshot & Auto-Revert. Snapshots every current Super User and watches for tampering on every scheduled check. A protected account getting blocked or removed from the Super Users group is reverted automatically; an email/password change or account deletion is alerted immediately but never auto-reverted, since either can just as easily be something you did yourself. A "Take/refresh snapshot now" button lets you accept a legitimate change as the new baseline.
• Test a Request. A read-only preview tool under Settings > Site Protection: paste a URL, IP, User-Agent, or Referer and see exactly what Shield would do with it -- blocked, flagged, or allowed, and why -- before you turn any blocking switch on. Runs through the exact same checks the live gate uses; never writes to the attack log or affects real traffic.

Added

• Periodic homepage watch, independent of a full scan. On every scheduled check, fetches the live homepage and checks it's reachable, not defaced, and not showing an SEO-spam injection -- alerts by email only on an actual state transition (site goes down/comes back, gets defaced/is cleaned up, spam appears/disappears), never on every single cron hit for a condition already reported. Toggle it from Settings > Monitoring & Cleanup.
• Configuration import/export. Export your Shield/hardening/alerting/Fleet/Autopilot settings as a JSON file from Settings > Monitoring & Cleanup -- useful as a backup or to copy the same setup to another site. Deliberately a narrow, hand-maintained allowlist of feature toggles: no secret this extension stores (license key, AI/API keys, cron token, backend password) is ever included, and a hand-edited or malicious import file can't smuggle one in either -- unrecognized keys are silently skipped and reported.
• One-click core-file restore from checksum baseline. Any finding flagged by the existing core-file checksum check now offers a "Restore this file from the official Joomla release" button. Fetches the exact release tag matching your installed Joomla version from the official joomla/joomla-cms source, verifies its SHA-256 against this scanner's own bundled, pre-verified checksum manifest before writing anything, and always backs up the current file first regardless of whether it was tampered.

• Outbound dashboard calls now go to store.lyzerslab.com (the dedicated product/storefront subdomain) instead of the main marketing domain -- the vulnerability feed, the newsletter opt-in banner, and the extension's own Joomla update-check (<updateservers>) all switched. No behavior change for users; lyzerslab.com keeps serving the same routes for anyone still on an older build, so this update is not required for updates themselves to keep working.

• New malware detections, confirmed against real dropped samples reported from a live incident: exact SHA-256 matches for a 421-byte "X9 Tools" bare file-upload webshell and a 6.5MB heavily-obfuscated PHP backdoor, plus a content-pattern signature for the "X9 Tools" webshell's self-branding and Telegram contact handle (catches re-obfuscated variants of it, not just the exact sample). The known-hash check runs independently of max_file_scan_size -- an oversized sample like the 6.5MB one no longer silently skips scanning just for being bigger than the usual scan window.
• Newsletter opt-in banner restored. The dismissible "Get security alerts & updates" dashboard banner (name + email, posts to the same opt-in pipeline as the main site's own signup form) is back after being removed in 3.2.3.

🐛 Fixed

• The Generate with SP Page Builder AI button now sits directly next to the New button in the Articles toolbar and is a full-size button, so it is easy to spot. It also re-asserts itself if the toolbar finishes wiring up after the page loads.

✨ New — generate a Joomla article as an SP Page Builder layout

• When SP Page Builder's Joomla Article integration is enabled (SP Page Builder editor → Integrations), a Generate with SP Page Builder AI button now appears in the toolbar of Content → Articles.
• Give it an article title and a description of the layout you want. MuRu AI:
  1. creates a published Joomla article in your first article category;
  2. builds a full SP Page Builder layout for its body;
  3. switches the integration on for that article and writes the rendered text into the article's full text, so it displays on the front of the site straight away.
• When it finishes, you get a link to open the new article in the SP Page Builder editor and a link to its normal article edit screen.
• The button only shows when the integration is on and you have Joomla "Create" rights for articles.

🎨 A clearer Generate window

• The window now matches what you are looking at:
  • On a normal page, it just asks for a description — the Generate for choice and the This page / New Dynamic Content set options are gone.
  • On a brand-new, empty page, the Replace current page content warning and the Replace/Append choice are hidden — there is nothing to replace, so the page is simply built.
  • On a page that already has content, the Replace/Append choice and the "saved to Version History" note appear as before.
• Generating from a Dynamic Content collection. Open a collection in SP Page Builder (Dynamic Content → a collection) and a Generate pages button now appears. It builds the collection's index and detail pages from one description and fills both in against the collection's real fields. If those pages already exist, they are reused, not duplicated.
• The window shows the bound collection's name when you generate on a Dynamic Content index or detail page.

✨ New — build a whole Dynamic Content set from a prompt

• The Generate window now has a Generate for choice: This page (as before) or New Dynamic Content set (collection + index + detail).
• Pick the second option, describe the records you want to manage ("a team directory with name, role, photo, bio and department"), and MuRu AI:
  1. designs and creates the Dynamic Content collection with sensible fields (using SP Page Builder's own collection system);
  2. creates an index page and a detail page bound to it;
  3. fills both pages in — the index gets a Collection listing block, the detail page gets fields wired to the real collection data.
• Links to open each new page appear when it finishes.
• One reminder shown on completion: add a menu item pointing at the collection so the pages open on the front of the site (SP Page Builder's own new-page flow needs this step too).

The collection is created empty — add or import records afterwards. Cross-collection "related items" blocks are still not generated automatically.

✨ New — Dynamic Content pages

• MuRu AI now recognises Dynamic Content pages. When you generate on a page that was created through SP Page Builder's New Page → Dynamic Content flow (an index or a detail page bound to a collection), the layout is built against that collection's real fields:
  • Index pages get a proper Collection block wired to the collection, with grid/list layout and pagination — item click-through to the detail page works automatically.
  • Detail pages get Dynamic Text / Dynamic Media blocks bound to the actual fields you name in your prompt (title, description, specs, images, …) instead of placeholder text.
• The prompt window shows which collection the open page is bound to, so you know the generation will use live data.
• You still pick the collection and the index/detail role in SP Page Builder's own page-creation screen — MuRu AI reads that binding, it never changes it.

Note: cross-collection "related items" widgets on detail pages are not generated automatically in this version — add those by hand where needed.

Page Generation — the Generate AI Page button next to Frontend Editor, prompt window, overwrite warning, weak-model notice. Uses the AI You Already Have — reads SP Page Builder's own Generative AI key/model, supports OpenAI and Gemini, auto-adapts the request if a model rejects an option. Real SP Page Builder Knowledge, Not Guesswork — the bundled schema/addon reference and explicit output format that make results actually open correctly in the editor. Automatic Quality Control — column-width/settings repair, visibility/id checks, duplicate-heading removal, nameless-block discarding, clean failure instead of a half-saved page. A Safety Net on Every Generation — Version History snapshot before every overwrite, stale CSS cleared automatically. Configuration — response length, creativity, timeout (sensible defaults, no setup required), optional troubleshooting mode. Reliability & Privacy — admin-only, permission-checked, minimal outbound data, fails safe if anything goes wrong. Requirements — Joomla 4/5/6, SP Page Builder 6 (Free or Pro), an OpenAI or Gemini account via SP Page Builder's settings.

MuRu Compliance Auditor 1.1.0 (Free) — first release

A working on-demand accessibility auditor for Joomla. Not an overlay — it crawls your site, checks every page, and shows editors how to fix each issue at the source. (1.0.0–1.0.2 were never published; their fixes are folded into this release.)

Scanning

• Run scan (toolbar button or the Dashboard): an SSRF-safe crawler walks the site — same-origin only, redirects re-validated per hop — evaluates every page, scores it, and stores the run. A browser scan is time-boxed (~40s, each page capped at 8s) so it always returns a result; the page cap defaults to 50.
• 8 WCAG 2.2 A/AA checks, each mapped to WCAG 2.2 + EN 301 549 with a "how to fix it in Joomla" note: image alt text, document language, page title, heading structure, link names, button & iframe names, form labels, viewport zoom.

Accessibility Statement generator

• The Generate & publish statement button builds a statement in the EU model structure — entity, standard applied, conformance status, non-accessible content, preparation date/method, feedback channel, enforcement procedure — pre-filled from the site and your latest scan, and publishes it as a Joomla article you can link from a menu item.
• Conformance status is set automatically: fully conformant when no findings are open, partially conformant otherwise; the non-accessible list is grouped from your open findings with their standard mappings.
• Regenerating updates the same article in place.
• New "Accessibility statement" options fieldset: legal entity, contact email, contact-form URL, enforcement body. Blank fields fall back to the site name and the site's From address.

Screens

• Dashboard: conformance score, open-findings severity breakdown, score trend, recent scans.
• Findings: filter by severity / check / status, paginated, with mark-resolved / ignore / reopen; message, selector and markup snippet.
• Reports: download any scan as HTML, JSON or CSV.
• Settings: scan profile, page cap, timeout, results-per-page. The licence key here is write-only — the stored key is never shown, only a masked hint; clearing it drops back to the free edition. In Global Configuration the key field is masked (password style).

Fixes from first-install testing

• Tab bar now navigates and shows the active tab.
• Run scan no longer errors, and no longer 500s on a busy server (the crawl has a wall-clock budget and returns a partial result).
• A stub content-save listener that broke every save site-wide is removed.
• Added the missing options-screen heading string.

Runs entirely on your server; the only outbound call is Joomla's update check. Requires Joomla 4.0+ (tested on 6.x), PHP 8.1–8.4. GPL-2.0-or-later.

Not in this build: Pro adds the privacy & consent check, dated PDF / VPAT / SARIF reports, report integrity hashing, the rendered deep scan, scheduled scans with alerts, and an agency fleet dashboard — a separate download. That code is not present here.

MuRu Compliance Auditor 1.1.0 (Pro) — first release

Everything in Free, plus the Pro code. Enter your licence key in Settings ▸ Licence to activate it; the Pro features lock again if the licence lapses. (1.0.0–1.0.2 were never published; their fixes are folded into this release.)

Included now (Free feature set)

• Run scan with the SSRF-safe crawler (time-boxed for a browser scan); 8 WCAG 2.2 A/AA checks mapped to WCAG 2.2 + EN 301 549 with Joomla remediation notes; Dashboard score, severity mix and trend; paginated Findings with resolve / ignore / reopen; HTML / JSON / CSV report download.
• Accessibility Statement generator: builds the EU model statement from the site and your latest scan and publishes it as a Joomla article; conformance status set automatically; regenerating updates the same article; optional entity / contact / enforcement fields in options.
• Write-only licence key on the Settings screen (stored key never shown); masked key field in Global Configuration.

Pro

• Privacy & consent check — third-party trackers loaded on a page vs the consent categories you declare. Active now.
• Coming in the next releases: dated PDF audit reports, EN 301 549 / VPAT and SARIF export, report integrity hash + public verification page, the rendered deep scan (computed contrast, focus order, JS content), scheduled scans with Slack / Discord / Telegram / webhook alerts, and the agency fleet dashboard.

Requires Joomla 4.0+, PHP 8.1–8.4. Updates arrive through Joomla's own System ▸ Update screen with your licence key appended automatically.

Added

• New malware detections, confirmed against real dropped samples: a bare file-upload webshell's exact banner text ("Uploader by X-MrG3P5"), a command-execution/upload webshell's distinctive output-wrapper markers, generic "hacked by <name>" defacement calling-card text files, the .htaccess.json filename (a malicious PHP-reactivation .htaccess payload dropped under a .json-suffixed name to dodge the exact-.htaccess-basename check), and the out-of-place .nojekyll marker file. Plain .json files are now content-scanned too (previously skipped unless double-extensioned like .php.json).

Changed

• AI Integration simplified to Gemini only. Settings > AI now offers just Google Gemini (free API key from Google AI Studio) instead of a three-provider (ChatGPT/Claude/Gemini) picker. Gemini is used automatically the moment a key and model are saved -- no separate "set as default" step. The 🤖 Ask AI button now shows on every Suspicious/Cleanable Files row unconditionally (previously hidden until a provider was configured) and explains how to set one up if clicked before adding a key.

Fixed

• False positive: the "hacked by" defacement-marker signature matched ordinary English. Confirmed on a real site: SP Page Builder's own core file (addons/form_builder/site.php) contains the harmless code comment "gap ... is owned by the parent row", which the new signature's "owned by" branch matched instantly. Removed the bare word "owned" from that signature (kept the leetspeak variant "0wned", which doesn't occur in ordinary prose) -- "hacked by"/"pwned by"/"0wned by"/"defaced by" all still catch real defacement markers.
• "Ask AI" throwing ReferenceError: muruFpToken is not defined on click. A pre-existing bug, unrelated to the changes above: the CSRF token variable was declared inside a different JavaScript closure than the one the Ask AI button's click handler runs in, so clicking it always failed once the click handler actually ran, on every version that shipped this feature.

Major version milestone -- consolidates everything below (previously 3.9.0 through 3.11.1) into one dashboard release.

Added

• Externally-updatable malware content-signature feed. New signatures published from the Lyzerslab dashboard now extend this extension's own hardcoded signature set at scan time, cached and refreshed every 24h -- a newly-seen attack pattern can reach every install within hours via one dashboard entry, instead of a new detection meaning bumping this whole extension's version.
• Third-party reputation lookup (Google Safe Browsing). Bring your own free API key to check URLs found inside scanned file content against Google's own threat lists.
• "Ask AI" without a Pro license. A non-Pro site can add its own free Gemini API key (Settings > General) to power the 🤖 Ask AI button on every finding -- Pro's own richer, licensed multi-provider system is unchanged and takes priority when active.
• New malware detections, confirmed against real dropped samples: a bare file-upload webshell's exact banner text, a command-execution/upload webshell's distinctive output-wrapper markers, generic "hacked by <name>" defacement calling-card text files, the .htaccess.json filename (a malicious .htaccess payload dropped under a .json-suffixed name), and the out-of-place .nojekyll marker file.
• Deep de-obfuscation signatures, archive (.zip) content inspection, exact-hash malware database, self-test with automatic rollback on .htaccess writes, an nginx hardening snippet, Spamhaus public-blocklist IP blocking, real upload-time filtering, world-writable file permission auditing, automated repeat-offender IP auto-blocklisting, referrer blocking, automatic tmp/ folder cleanup, and a single-glance security score.

Fixed

• False positive: the "hacked by" defacement-marker signature matched ordinary English ("owned by" in a legitimate code comment). Removed the bare word "owned" from that signature; the leetspeak/hacker-slang variants it exists to catch are unaffected.

Added

• Deep de-obfuscation before content-signature matching. New checks catch a payload disguised via strrev()-reversed dangerous function names (strrev("lave") = eval), chr() arithmetic character-code building (chr(101-4) instead of a literal), and JavaScript _0x hex-array obfuscation (the standard shape produced by JS obfuscator tools, seen in real skimmer/redirect payloads). Separately, a file whose raw text contains literal \xHH/\NNN escape sequences is now also scanned as a decoded copy against the full existing signature set -- so eval(base64_decode($_POST[...])) spelled out entirely in hex escapes (never appearing as plain text anywhere in the file) is now caught the same as if it were written in plain text.
• Archive (.zip) content inspection. A .zip anywhere in the scanned tree now has its contents opened and each entry run through the exact same content-signature scan as a real file -- catching a webshell sitting inside an uploaded/dropped zip that was never extracted. Conservative budget limits (4MB archive, 512KB/entry, 256 entries, 16MB total unpack) so this can never become a decompression-bomb DoS vector against the site it's protecting.
• Self-test with automatic rollback on .htaccess writes (Pro). "Apply this rule" (added in 3.8.3) now makes one real request to the site's own homepage immediately after writing -- if it doesn't come back with a working response, the write is rolled back automatically to the exact bytes just backed up, and reported as such. Closes the gap where an unusual server config could turn a well-intentioned rule into a site-wide outage nobody noticed applying.
• nginx hardening snippet. The .htaccess advisory panel now also offers a copy-paste nginx server {} block covering the same 7 checks, translated to nginx syntax -- for the sites this whole advisory previously had nothing at all to say to.
• Public blocklist (Spamhaus ZEN) IP blocking (Pro, Shield). New "Block IPs on the Spamhaus public blocklist" toggle rejects requests from an IP currently listed on Spamhaus's free public reputation DNSBL -- no account or API key, checked via a plain cached DNS lookup, fails open on any lookup error. Known limitation, confirmed during testing: Spamhaus rate-limits/blocks free public queries above low volume, so this is a best-effort layer, not a guaranteed one -- it fails open safely either way, but shouldn't be relied on as the only protection against anything.
• Real upload-time filtering (Pro, Shield). New "Block dangerous file uploads at upload time" toggle rejects the whole request outright -- before ANY component (Media Manager, a form field, a third-party extension's own handler) ever writes the file to disk -- when an uploaded filename has a banned or disguised executable extension (shell.php, shell.php.jpg, ...). Every other upload-related check in this product runs after the fact, on the next scan; this is the one that runs at the moment of upload.
• Exact-hash malware database. New "Known-Bad Hashes" panel in Settings lets you add the MD5 of a file you've personally confirmed malicious -- every future scan flags an exact byte-for-byte match anywhere in the tree, independent of filename or location. Ships empty on purpose (no bundled/fabricated hash list).
• World-writable file permission audit. (Carried in from the previous 3.8.4 release notes below, listed here for completeness of this scan-engine round.)

Scoped out of this round, deliberately

• Externally-updatable malware-signature feed and community/crowd-sourced false-positive reporting need a new dashboard-side endpoint (a different codebase/deployment) -- not attempted here to avoid shipping a client-side mechanism pointed at nothing.
• Named-CVE request signatures beyond the existing SP Page Builder ones were not added this round -- avoided guessing at exact exploit syntax for extensions (Novarain/Astroid/Helix/DPCalendar/AcyMailing/JoomCCK) this project can't verify against real code, consistent with this project's "verify, don't fabricate" standard.
• Google Safe Browsing / Web Risk lookup needs an admin-supplied API key and a larger design pass (which URLs to check, rate-limit handling) than fit this round.
• CAPTCHA on backend login was not attempted here -- a broken login flow is a severe regression risk this project isn't comfortable shipping without live Joomla testing. Joomla core already supports reCAPTCHA/hCaptcha natively via Global Configuration > Users > Captcha, which is the safer path today.
• Site crawl/test tool (preview what Shield would block before enabling) is a larger UI feature, not started this round.

MuRu Compliance Auditor 1.0.2 (Pro) — first release

Everything in Free, plus the Pro code. Enter your licence key in Settings ▸ Licence to activate it; the Pro features lock again if the licence lapses.

Included now (Free feature set)

• Run scan with the SSRF-safe crawler (time-boxed for a browser scan); 8 WCAG 2.2 A/AA checks mapped to WCAG 2.2 + EN 301 549 with Joomla remediation notes; Dashboard score, severity mix and trend; paginated Findings with resolve / ignore / reopen; HTML / JSON / CSV report download; the EU model Accessibility Statement; the in-context Settings page.

Pro

• Privacy & consent check — third-party trackers present on a page vs the consent categories you declare. Active now.
• Coming in the next releases: dated PDF audit reports, EN 301 549 / VPAT and SARIF export, report integrity hash + public verification page, the rendered deep scan (computed contrast, focus order, JS content), scheduled scans with Slack / Discord / Telegram / webhook alerts, and the agency fleet dashboard.

Requires Joomla 4.0+, PHP 8.1–8.4. Updates arrive through Joomla's own System ▸ Update screen with your licence key appended automatically.

MuRu Compliance Auditor 1.0.2 (Free) — first release

A working on-demand accessibility auditor for Joomla. Not an overlay — it crawls your site, checks every page, and shows editors how to fix each issue at the source.

Scanning

• Run scan (toolbar button or the Dashboard): an SSRF-safe crawler walks the site — same-origin only, redirects re-validated per hop — evaluates every page, scores it, and stores the run. A browser scan is time-boxed so it always returns; use the CLI/scheduled path for a full site later.
• 8 WCAG 2.2 A/AA checks, each mapped to WCAG 2.2 + EN 301 549 with a "how to fix it in Joomla" note: image alt text, document language, page title, heading structure, link names, button & iframe names, form labels, viewport zoom.

Screens

• Dashboard: conformance score, open-findings severity breakdown, score trend, recent scans.
• Findings: filter by severity / check / status, paginated, with mark-resolved / ignore / reopen; message, selector and markup snippet per finding.
• Reports: download any scan as HTML, JSON or CSV.
• Accessibility Statement: the EU model-statement structure, pre-filled from your site.
• Settings: scan profile, page cap, timeout, results-per-page and the Pro licence key, with a link to Global Configuration for the rest.

Runs entirely on your server; the only outbound call is Joomla's update check. Requires Joomla 4.0+ (tested on 6.x), PHP 8.1–8.4. GPL-2.0-or-later.

Not in this build: Pro adds the privacy & consent check, dated PDF / VPAT / SARIF reports, report integrity hashing, the rendered deep scan, scheduled scans with alerts, and an agency fleet dashboard — a separate download, unlocked with a licence key. That code is not present here.

Fixed

• False positive: HikaShop's email template files. media/com_hikashop/mail/ (and its template/ subfolder) legitimately holds 40-50+ PHP view templates HikaShop uses to render order/payment/notification emails -- unlike almost every other media/ subfolder, which really is just static assets. Every one of them was being individually flagged as "executable file inside an upload directory." Now exempted from that specific structural check (only when com_hikashop is actually installed) -- the content-signature scan still runs on these files unconditionally, so a genuinely tampered one is still caught.
• False positive: Composer-managed sites. composer.json and composer.lock (plain JSON, not executable) no longer flag as unrecognized webroot files, and a top-level vendor/ folder is recognized as Composer's own dependency tree when a composer.json sits alongside it -- every file inside it still gets the full content-signature scan, same as any other recognized folder.
• False positive: .php-cs-fixer.php / .php-cs-fixer.dist.php. PHP CS Fixer's own config file is a hidden dot-file with a .php extension by its documented naming convention (loaded by its CLI tool, never by a web server) -- ships inside plenty of real Composer packages' vendor/ trees. (Its cache-file variants were already exempted here.)
• False positive: icon-font .htaccess files. Icon-font export tools (IcoMoon, Fontello, ...) commonly ship a minimal .htaccess purely to set the MIME type for .woff/.ttf/.eot -- now checked by content instead of blanket-flagged by location, using the exact same "is this actually permissive" criteria the scanner already applies to every other .htaccess it finds.

MuRu Compliance Auditor 1.0.1 (Pro) — first release

Everything in Free, plus the Pro code. Enter your licence key in Settings ▸ Licence to activate it; the Pro features lock again if the licence lapses.

Included now (Free feature set)

• Run scan with the SSRF-safe crawler; 8 WCAG 2.2 A/AA checks mapped to WCAG 2.2 + EN 301 549 with Joomla remediation notes; Dashboard score, severity mix and trend; paginated Findings with resolve/ignore/reopen; HTML/JSON/CSV report download; the EU model Accessibility Statement; the in-context Settings page.

Pro

• Privacy & consent check (third-party trackers present on a page vs the consent categories you declare) — active now.
• Coming in the next releases: dated PDF audit reports, EN 301 549 / VPAT and SARIF export, report integrity hash + public verification page, the rendered deep scan (computed contrast, focus order, JS content), scheduled scans with Slack / Discord / Telegram / webhook alerts, and the agency fleet dashboard.

Requires Joomla 4.0+, PHP 8.1–8.4. Updates arrive through Joomla's own System ▸ Update screen with your key appended automatically.

MuRu Compliance Auditor 1.0.1 (Free) — first release

A working on-demand accessibility auditor for Joomla. Not an overlay — it crawls your site, checks every page, and shows editors how to fix each issue at the source.

Included

• Run scan: an SSRF-safe crawler walks the site (redirects re-validated per hop, same-origin only), evaluates every page, scores it, and stores the run.
• 8 WCAG 2.2 A/AA checks, each mapped to WCAG 2.2 + EN 301 549 with a "how to fix it in Joomla" note: image alt text, document language, page title, heading structure, link names, button & iframe names, form labels, viewport zoom.
• Dashboard: conformance score, open-findings severity breakdown, score trend, recent scans.
• Findings: filter by severity / check / status, paginated, with mark-resolved / ignore / reopen.
• Reports: download any scan as HTML, JSON or CSV.
• Accessibility Statement: the EU model-statement structure, pre-filled from your site.
• Settings page for the licence key, scan profile, page cap, timeout and results-per-page, with a link to Global Configuration for the rest.

Runs entirely on your server. The only outbound call is Joomla's own update check. Requires Joomla 4.0+ (tested on 6.x), PHP 8.1–8.4. GPL-2.0-or-later.

MuRu Compliance Auditor 0.1.0 (Pro) — first release

Everything in Free 0.1.0, plus the Pro extension points bundled into the package. Pro feature implementations roll out over the next few releases.

From Free

• SSRF-safe site crawler; WCAG 2.2 A/AA checks mapped to WCAG 2.2 + EN 301 549 with Joomla remediation guidance; conformance scoring with a SHA-256 report-integrity hash; one-package install; native updates

Pro (bundled this release, activating in upcoming ones)

• Scheduled scans via Joomla's Scheduler + regression alerts (Slack / Discord / Telegram / webhook)
• Dated PDF audit reports with an integrity hash and a public verification page
• EN 301 549 / VPAT and ADA Title III export
• Rendered deep scan — computed contrast, focus order, JS-injected content
• Privacy & consent audit + right-to-be-forgotten helper
• Fleet dashboard for agencies — remote re-scan, per-client report packs
• Console command + REST endpoints for CI gating

Pro updates are delivered through Joomla's update system with your licence key appended automatically. Requirements: Joomla 4.0+, PHP 8.1–8.4.

MuRu Compliance Auditor 0.1.0 (Free) — first release

Foundation release of a native Joomla accessibility & privacy auditor. This build ships the scanning engine and the packaging; the findings dashboard, HTML report and Accessibility Statement generator arrive in the next releases.

Included

• Same-origin, SSRF-safe site crawler — blocks private / loopback / link-local / CGNAT addresses, caps pages, refuses off-site redirects
• WCAG 2.2 A/AA checks, each mapped to WCAG 2.2 + EN 301 549 with "how to fix it in Joomla" guidance: image alt text, document language, page title, heading structure, link names, button & iframe names, form labels, viewport zoom
• Conformance scoring with an order-independent SHA-256 snapshot hash (report integrity)
• One-package install (pkg_muruaudit): admin + site component, system plugin, control-panel quick icon
• Native update delivery via Joomla's System > Update

Requirements: Joomla 4.0+ (tested through 6.x), PHP 8.1–8.4. Privacy: runs entirely on your server — nothing is transmitted anywhere except Joomla's own update check.

Added

• New detection: nxtest.json / nxproof.php.json malware filenames. A customer-reported infection dropped these exact filenames at multiple depths under templates/ (e.g. templates/shaper_moview/layout/nxtest.json, templates/nxproof.php.json) as part of the SP Page Builder compromise this tool targets. Matched on the bare filename regardless of location, so it's caught wherever it's dropped, not just at a specific path. nxproof.php.json was already caught by the general double-extension rule; nxtest.json is a genuinely new case, since a single .json extension isn't inherently suspicious on its own.

Changed

• Recommended SP Page Builder update target bumped to 6.8.0. The README and the in-app version-warning banner now recommend updating to the current 6.8.0 release rather than just the 6.6.2 floor that originally patched the uploadCustomIcon RCE. The scanner's actual safe/vulnerable version check is unchanged (still correctly treats any 6.6.2+ install as patched against that RCE) -- this only updates the advice to point at the latest release instead of the bare minimum.

Added

• New detection: nxtest.json / nxproof.php.json malware filenames. A customer-reported infection dropped these exact filenames at multiple depths under templates/ (e.g. templates/shaper_moview/layout/nxtest.json, templates/nxproof.php.json) as part of the SP Page Builder compromise this tool targets. Matched on the bare filename regardless of location, so it's caught wherever it's dropped, not just at a specific path. nxproof.php.json was already caught by the general double-extension rule added in v3.2.0; nxtest.json is a genuinely new case, since a single .json extension isn't inherently suspicious on its own.

Changed

• Recommended SP Page Builder update target bumped to 6.8.0. The README and the in-app version-warning banner now recommend updating to the current 6.8.0 release rather than just the 6.6.2 floor that originally patched the uploadCustomIcon RCE. The scanner's actual safe/vulnerable version check is unchanged (still correctly treats any 6.6.2+ install as patched against that RCE) -- this only updates the advice to point at the latest release instead of the bare minimum.

Added

• Known-Vulnerability Cross-Check. New "Vulnerabilities" tab and a top-of-report banner cross-reference every installed extension's version against an admin-curated feed of published Joomla vulnerability advisories -- catching a site running a known-exploitable extension version before it's compromised, not just cleaning up after the fact. Runs as part of every scan (no extra wait), refreshes its local copy of the feed at most once every 24 hours, and fails silently to the last-cached copy if the feed is briefly unreachable so a scan is never slowed down or broken by it. No action beyond an "Update to vX.Y.Z" link -- the fix is always updating the extension, nothing is touched automatically. Free on both editions -- this is awareness, not a licensed feature.
• New detection: general double-extension webshell disguise. Any executable extension (.php, .phtml, .php3-.php7, .phar, .pht, .shtml) followed by a second, innocent-looking one -- e.g. shell.php.gif, backdoor.phtml.png, evil.php5.pdf -- is now flagged, a well-known upload-filter bypass some server configs still execute despite the trailing extension. A small allowlist of genuinely benign secondary extensions (.dist, .sample, .example, .orig, .bak, and similar backup/template conventions) is excluded so this doesn't flag legitimate files.

Security

• The Vulnerable Extensions tab's advisory link is validated as http(s):// both server-side (the dashboard API rejects any other scheme before it's ever stored) and again here before it's ever rendered as a link, rather than trusting the fetched feed blindly -- closed as part of a security review of the new dashboard API communication before this release.

Security

• Hardened the Vulnerable Extensions tab's advisory link against scheme injection. The dashboard's own API already validates an advisory's URL is http(s):// before it's ever stored, but this extension now double-checks the scheme itself before rendering the link too, rather than trusting the feed blindly -- found during a security review of the new dashboard API communication added in v3.2.0.

Added

• Known-Vulnerability Cross-Check. New "Vulnerabilities" tab and a top-of-report banner cross-reference every installed extension's version against an admin-curated feed of published Joomla vulnerability advisories -- catching a site running a known-exploitable extension version before it's compromised, not just cleaning up after the fact. Runs as part of every scan (no extra wait), refreshes its local copy of the feed at most once every 24 hours, and fails silently to the last-cached copy if the feed is briefly unreachable so a scan is never slowed down or broken by it. No action beyond an "Update to vX.Y.Z" link -- the fix is always updating the extension, nothing is touched automatically.
• New detection: general double-extension webshell disguise. Any executable extension (.php, .phtml, .php3-.php7, .phar, .pht, .shtml) followed by a second, innocent-looking one -- e.g. shell.php.gif, backdoor.phtml.png, evil.php5.pdf -- is now flagged, a well-known upload-filter bypass some server configs still execute despite the trailing extension. A small allowlist of genuinely benign secondary extensions (.dist, .sample, .example, .orig, .bak, and similar backup/template conventions) is excluded so this doesn't flag legitimate files.

Fixed

• Any action taken on scan results (Delete Selected, Mark Selected Safe, cleanup, any Super Users/Menu XSS/SPPB Assets/Defacement row action) more than 5 minutes after the original scan silently redirected back to the "run a scan" landing screen instead of showing the just-updated results -- entirely plausible while reviewing a real list of dozens of flagged items one at a time. The results view was gated on the same 5-minute freshness window the scan cache uses internally to decide whether to auto-refresh, conflating "is this data stale" with "should results even be shown at all." Results now stay visible for the rest of the session once a scan has completed, regardless of how long ago.
• A TimeMachine snapshot of an already-cleaned finding could re-trigger the same content signature against its own backup, flagging this scanner's own timemachine-index.php/timemachine-blobs/*.php (Pro's Safe Repair storage -- an intentional byte-for-byte copy of a file/DB row's "before" state, kept so Restore can put it back exactly) as a new High-severity threat. Same fix family as the existing scan-progress.php exemption: snippet-bearing reasons are now stripped for these files too, since they're structurally inert (never executed, only ever read back as JSON) and this is a real reported false positive.

Fixed

• Any action taken on scan results (Delete Selected, Mark Selected Safe, cleanup, any Super Users/Menu XSS/SPPB Assets/Defacement row action) more than 5 minutes after the original scan silently redirected back to the "run a scan" landing screen instead of showing the just-updated results -- entirely plausible while reviewing a real list of dozens of flagged items one at a time. The results view was gated on the same 5-minute freshness window the scan cache uses internally to decide whether to auto-refresh, conflating "is this data stale" with "should results even be shown at all." Results now stay visible for the rest of the session once a scan has completed, regardless of how long ago.

Fixed

• The bulk selection toolbar (Delete Selected / Mark Selected Safe) always showed "0 selected" and stayed disabled, throwing muruUpdatePanelToolbar is not defined in the console on every checkbox click. The function was defined inside the page's script closure but every "Select All" checkbox called it from an inline onclick="" attribute, which always executes in the global scope regardless of where the function is defined. Now exposed on window so it's reachable from those handlers.
• Every file under a legitimately-installed but disabled template (most commonly Joomla's own bundled Cassiopeia, sitting there unused once a different template is set as default) was flagged as suspicious. A disabled #__extensions template record on its own is completely normal and not a sign of compromise. Now only flagged when corroborated by an actual red flag -- a junk-named folder or a missing templateDetails.xml manifest -- exactly the real attack pattern this check exists for. A totally missing registry record is still always flagged, no corroboration needed.
• Settings could silently "revert" after a reload despite saving successfully because saves never invalidated Joomla's own _system cache group after writing to #__extensions, which caches the whole component registry (params included) when Joomla's system caching is enabled -- so the write succeeded but the next page load could read back the stale, pre-write value. Every settings-save path now clears that cache after writing.
• Reworded the "no matching #__extensions component record" message to acknowledge a legitimate non-core component installed separately (FTP, a migration, a custom build) without ever running through Joomla's own Install screen, instead of implying it was never really installed.

Fixed

• Every file under a legitimately-installed but disabled template (most commonly Joomla's own bundled Cassiopeia, sitting there unused once a different template is set as default) was flagged as suspicious. A disabled #__extensions template record on its own is completely normal and not a sign of compromise. Now only flagged when corroborated by an actual red flag -- a junk-named folder or a missing templateDetails.xml manifest -- exactly the real attack pattern this check exists for. A totally missing registry record is still always flagged, no corroboration needed.
• Settings could silently "revert" after a reload despite saving successfully -- most visibly, the newsletter banner's dismissal reappearing every time. Every settings-save method wrote straight to #__extensions without invalidating Joomla's own _system cache group, which caches the whole component registry (params included) when Joomla's system caching is enabled -- so the write succeeded but the next page load could read back the stale, pre-write value. Every settings-save path now clears that cache after writing.
• Reworded the "no matching #__extensions component record" message to acknowledge a legitimate non-core component installed separately (FTP, a migration, a custom build) without ever running through Joomla's own Install screen, instead of implying it was never really installed.

Added

• New detection: injected joomla@test.com admin account. A widespread automated attack wave creates a rogue Super User account using exactly this email address on hijacked sites. The Super Users check now flags any account with this exact email as suspicious (red), regardless of its username or display name.
• New: Update Site Health warning. A real reported cause of sites getting hacked through a since-patched vulnerability: Joomla's own "Check for Updates" screen silently shows nothing for an extension because the record telling Joomla where to check is broken (#__update_sites.enabled = 0, which Joomla only ever surfaces as an easy-to-miss one-line notice on its own Find Updates screen, or no update site registered at all for SP Page Builder/JCE specifically). A red banner now appears at the very top of the report -- only when this is actually broken -- naming the affected extension(s) and linking straight to Joomla's Update Sites screen to fix it.

Fixed

• Settings > AI & Automation showed two separate "upgrade to Pro" banners stacked on top of each other (one for the Smart AI Assistant, one for Automations) because both the AI Integrations panel and the Automations panel were wired to the same tab, so both rendered at once. Merged into a single panel with one combined lock banner and, once unlocked, both AI Integrations and Automations settings in one place.

Added

• New detection: injected joomla@test.com admin account. A widespread automated attack wave creates a rogue Super User account using exactly this email address on hijacked sites. The Super Users check now flags any account with this exact email as suspicious (red), regardless of its username or display name.
• New: Update Site Health warning. A real reported cause of sites getting hacked through a since-patched vulnerability: Joomla's own "Check for Updates" screen silently shows nothing for an extension because the record telling Joomla where to check is broken (#__update_sites.enabled = 0, which Joomla only ever surfaces as an easy-to-miss one-line notice on its own Find Updates screen, or no update site registered at all for SP Page Builder/JCE specifically). A red banner now appears at the very top of the report -- only when this is actually broken -- naming the affected extension(s) and linking straight to Joomla's Update Sites screen to fix it.

Changed

• Settings, simplified to 3 tabs. "Site Protection", "IP Access List", and "Scheduled Scanning" are now "General" (Scheduled Scanning) and "Site Protection" (which now also includes the IP Access List) -- fewer tabs to hunt through, matching MuRu Guard Pro's layout. Nothing was removed, only regrouped; existing settings and bookmarked links to the old tabs still land in the right place.
• Shorter admin menu name. The sidebar entry is now just "MuRu Guard" instead of "MuRu Guard Security Scanner", matching Pro.

Fixed

• The Scheduled Scanning webcron URL never actually worked for a real, unauthenticated cron caller, on any Joomla 4, 5, or 6 site. Joomla core (AdministratorApplication::findOption(), since Joomla 4.0) only lets a guest request reach option=com_login or option=com_ajax in the admin area, silently redirecting anything else -- including com_muruguard itself -- to the login page before it ever reached the webcron's own token check. The URL only ever appeared to work when tested from an already-logged-in browser tab. Fixed by routing the webcron through plg_muruguardshield (already loaded on every admin request) via Joomla's own com_ajax bridge, the guest-reachable entry point Joomla itself provides for exactly this case. The URL shown under Settings > Scheduled Scanning has changed accordingly -- copy the new one if you had the old one saved in an external cron job.
• A related crash when the scheduled-check controller is reached this new way: it previously resolved its model via $this->getModel('Scanner'), which depends on Joomla's normal component-dispatch context and returned false when the controller was constructed directly instead -- now constructs the model directly, which needs no such context.

Companion plugin also updated: plg_muruguardshield 1.2.3 provides the com_ajax bridge above -- both extensions need to be updated together for the webcron fix to take effect.

Added

• Autopilot Mode (Pro). New Settings > Automations toggle, off by default. When enabled, a scheduled scan (never a manual Run Scan, never the first-ever baseline scan) that finds a new file matching one of four hand-picked, near-zero-false-positive content signatures -- a raw request handed directly into eval/assert/shell_exec, or a secret-cookie-gated backdoor -- sends it to the AI Assistant for an independent verification call before touching anything. Only a confirmed-malicious verdict leads to removal, through the same TimeMachine-snapshotted delete path every manual repair already uses, so every auto-fix is restorable from Backup & Restore. Every other kind of finding (unrecognized files, filename patterns, anything the AI isn't confident about) is only ever reported, exactly as before. Requires an AI provider configured under Settings > AI Integrations.

Fixed

• The Scheduled Scanning webcron URL never actually worked for a real, unauthenticated cron caller, on any Joomla 4, 5, or 6 site. Joomla core (AdministratorApplication::findOption(), since Joomla 4.0) only lets a guest request reach option=com_login or option=com_ajax in the admin area, silently redirecting anything else -- including com_muruguard itself -- to the login page before it ever reached the webcron's own token check. The URL only ever appeared to work when tested from an already-logged-in browser tab. Fixed by routing the webcron through plg_muruguardshield (already loaded on every admin request) via Joomla's own com_ajax bridge, the guest-reachable entry point Joomla itself provides for exactly this case. The URL shown under Settings > Scheduled Scanning has changed accordingly -- copy the new one if you had the old one saved in an external cron job.
• A related crash when the scheduled-check controller is reached this new way: it previously resolved its model via $this->getModel('Scanner'), which depends on Joomla's normal component-dispatch context and returned false when the controller was constructed directly instead -- now constructs the model directly, which needs no such context.
• False positives on com_osmap's view.xml.php and Dropfiles' theme index.php. The filename-pattern check was flagging Joomla's own standard view.<format>.php MVC convention; the non-standard-index.php check was flagging Dropfiles' own front-end theme entry point. Both are now recognized, the same way the existing com_jce exemption already works.

Fixed

• "Select All" / "Select High Only" left the bulk toolbar stuck at "0 selected." Both handlers set each checkbox's .checked via a raw DOM property assignment, which never fires a change event — and the bulk toolbar's counter and its Mark Selected Safe / Check via AI buttons are driven entirely by a change listener. Fixed in all 9 results tabs that have bulk actions.
• False positives on JED Checker's own working copy. Running the official Joomla Extensions Directory compliance tool against this scanner's own release zip extracts a full copy of its source into tmp/jed_checker/unzipped/, which was flagged both structurally ("executable file in an upload directory") and via content signatures re-matching its own signature-definition text. Both are now recognized, the same way an already-installed copy of this scanner is.
• scan-progress.php self-flagging. This internal cache file stores the most recent scan's own findings, including the literal "Matched code: ..." snippet several checks append — so any real finding elsewhere on the site could get its snippet echoed back into this file and re-trigger the same signature on the next scan. Every snippet-bearing reason is now stripped for this one file specifically (its content is only ever read as JSON, never executed).
• .htaccess.admintools and .myjoomla.*.md5 false positives. Recognized as legitimate artifacts of Akeeba Admin Tools and the MyJoomla.com monitoring service instead of "unrecognized file in webroot."

Fixed

• False positives on JED Checker's own working copy. Running the official Joomla Extensions Directory compliance tool against this scanner's own release zip extracts a full copy of its source into tmp/jed_checker/unzipped/, which was flagged both structurally ("executable file in an upload directory") and via content signatures re-matching its own signature-definition text. Both are now recognized, the same way an already-installed copy of this scanner is.
• scan-progress.php self-flagging. This internal cache file stores the most recent scan's own findings, including the literal "Matched code: ..." snippet several checks append — so any real finding elsewhere on the site could get its snippet echoed back into this file and re-trigger the same signature on the next scan. Every snippet-bearing reason is now stripped for this one file specifically (its content is only ever read as JSON, never executed).
• .htaccess.admintools and .myjoomla.*.md5 false positives. Recognized as legitimate artifacts of Akeeba Admin Tools and the MyJoomla.com monitoring service instead of "unrecognized file in webroot."
• Newsletter banner's ✕ button didn't close it. It relied on a full page reload to reflect the dismissal; now dismisses instantly via the same no-reload pattern already used for "Mark as Safe."

Fixed

• "Ignored paths" wildcard didn't cover subfolders. A pattern ending in /* (e.g. plugins/mcp/*, documented as a way to ignore an entire extension) only ever matched files placed directly inside that folder, never anything in a subfolder underneath it, such as plugins/mcp/mcpadminlogin/. A trailing /* now also matches the whole subtree, matching the documented behavior; every other wildcard shape is unchanged.

Fixed

• "Ignored paths" wildcard didn't cover subfolders. A pattern ending in /* (e.g. plugins/mcp/*, documented as a way to ignore an entire extension) only ever matched files placed directly inside that folder, never anything in a subfolder underneath it, such as plugins/mcp/mcpadminlogin/. A trailing /* now also matches the whole subtree, matching the documented behavior; every other wildcard shape is unchanged.

Added

• New companion module: mod_muruguardstatus. A small green "Site Protected" pill published to the admin header's status row -- the same row the User Menu/logout dropdown lives in -- shown only while Protection Mode is actually active (Shield plugin installed+enabled AND the toggle is on in Settings). This is a proper module, not a plugin: the header status row is a real module position (confirmed against the actual mod_quickicon/template source on a local Joomla 6 install), and nothing else can place content there.

• New companion plugin: plg_quickicon_muruguardquickicon. A small badge on the admin Control Panel dashboard (next to Joomla's own "Post-installation messages"/"Take a Tour" widgets) showing "🛡️ MuRu Guard: Site Protected" whenever Protection Mode is actually running -- both the Shield plugin is installed+enabled AND Protection Mode is switched on in Settings. Shows nothing at all otherwise, rather than a misleading badge for "the component exists" alone. Ships as its own installable zip (dist/plg_muruguardquickicon-1.0.0.zip), same as the existing Shield plugin.

• TimeMachine Safe Repair Engine. Every repair the Smart AI Assistant makes (write/rename/delete a file) and every non-AI cleanup action (bulk delete, Clean Code, Clean Menu XSS, Clean Template Style XSS, delete rogue SP Page Builder assets, delete junk/injected template styles) now automatically saves a verified snapshot of the "before" state before anything changes -- server-enforced, not something the AI or the admin has to remember. Snapshots are SHA-256 verified before a restore trusts them, grouped into transactions (one AI request or one bulk action = one rollback-able unit), and restorable with one click, per file or for a whole transaction, from the new "Protected Repairs" list in the Smart AI Assistant panel. A restore refuses to silently overwrite a file (or database row) that changed again since the repair -- surfaced as a conflict requiring explicit confirmation to force through -- and a corrupted snapshot is never restorable even with force. Database-row snapshots (from the four DB-mutating cleanup actions) use a narrow, explicit allow-list of exactly the table+action combinations those actions can produce, never a generic "replay stored SQL" rollback. New Settings > TimeMachine tab controls the retention window (days + max snapshot count); a snapshot marked "Keep" is exempt from eviction. Every snapshot, repair, and rollback is also logged through the existing Protection Log (recordAttackLogEntry), not a second parallel audit trail. AI-mutation snapshotting is Pro-gated by construction (the only code path that creates one is already behind the AI Assistant's existing Pro+license check), and every new endpoint follows the same CSRF -> ACL -> Pro-license check sequence already used by the AI chat actions.

Changed

• File Integrity Monitoring moved into the Site Protection tab, right after Site Protection itself -- both are read-at-a-glance status cards you check routinely, not one-time configuration, so they now live together rather than FIM sitting in Backup & Restore. The Site Protection tab's badge dot no longer duplicates itself when both Shield and a FIM baseline are active -- one dot, not two.
• Protected Repairs list capped at 2 entries in the Smart AI Assistant panel, with a "See all repairs →" link to the Backup & Restore tab, which now shows the full list (with the same Restore/pin controls) instead of just linking back to the AI Assistant panel -- keeps the AI panel's sidebar short while working through many tasks, without losing access to the full history.
• Collapsed sections' "Click to expand" hint is now full black and has real spacing from the description above it, instead of pale gray text sitting right underneath with no visual separation.
• Settings reorganized from 9 tabs down to 6. General — Display/Pagination, Scheduled Scanning, and False Positives. Site Protection — Site Protection and Protection Log stay open by default (what's checked most often); IP Access List and MuRu Shield Hardening are collapsed behind a click so the tab isn't overwhelming. License — unchanged. AI & Automation — Automations (Fleet Dashboard + Alerts), then AI Integrations, both always open. Backup & Restore (new tab, renamed from "TimeMachine" for clarity) — Retention settings and where to actually restore a repair, plus File Integrity Monitoring; always open, not collapsed. Setup Guide — unchanged. A bookmarked or previously-saved link to an old tab (e.g. ?settings_tab=ai, ?settings_tab=timemachine, or ?settings_tab=protection) still lands on the right new tab rather than a blank or default one. Collapsed sections now use a real circular chevron badge and a "Click to expand" hint instead of a barely-visible glyph, and every settings card gets consistent spacing from the one after it (previously two adjacent cards under the same tab could sit flush against each other with no gap).

Fixed

• "Create Baseline" (File Integrity Monitoring) redirected to the General settings tab instead of staying on Site Protection. It used a bare window.location.reload(), which re-requests whatever URL is currently in the address bar -- and since every Settings tab switch here is client-side-only, that URL never carries view_panel/settings_tab, so a reload always landed back on Dashboard > General. Now navigates explicitly back to the Site Protection tab instead.
• AI provider Save/Test/Enable buttons could fail completely silently. Both the Settings > AI Integrations panel and the Smart AI Assistant chat's own ajax() helper had no error handling at all -- if the dashboard call failed for any reason (network drop, a non-JSON response), the promise rejected with nothing listening for it, so the button just stayed "busy" forever with no success message, no error message, nothing. Both now always resolve to a real, visible error instead of silently swallowing the failure.
• Smart AI Assistant couldn't create a file inside a brand-new directory. write_file/rename_file's path-safety check only ever validated the target's IMMEDIATE parent directory -- so asking the assistant to create a new SP Page Builder addon (which needs its own new components/com_sppagebuilder/addons/<name>/ folder) failed with a generic "This path isn't allowed", which the assistant then (reasonably, given that error) reported as a missing directory-creation capability rather than a fixable bug. The path-safety check now walks up to the deepest EXISTING ancestor directory (verifying it stays inside the site root the same way the old single-level check did), and write_file/rename_file create whatever new parent directories the validated path actually needs before writing. Traversal, symlink-escape, and deny-listed-directory protections are unchanged and re-verified.

Fixed: "Mark as Safe" no longer reloads the page (ported from Pro v3.5.6) -- it now returns a JSON acknowledgment and removes its own row in place, with zero navigation. Added: pagination on the Suspicious Files / Cleanable Files tables and the Protection Log (ported from Pro), with a new configurable "items per page" display setting under Settings > Scheduled (default 50, options 25/50/100/250/500).

Added: Bulk "Mark Selected Safe" and "Check via AI" on every results tab. Select multiple findings via each tab's checkboxes (Suspicious Files, Cleanable Files, Super Users, Menu XSS, SPPB Assets, Rogue Iconfont, Template Defacement, Template Style XSS -- Super Users and SPPB Assets never had bulk-select before this) and dismiss them all at once, or run the Smart AI Assistant against every selected file in one go (Pro, file-based tabs only). Both run through the exact same logic the single-item buttons already use, and update the page in place with zero reload.

Fixed: "Mark as Safe" no longer reloads the page at all. Confirmed reproducible in incognito mode -- clicking it visibly navigated to the bare results page, reading as an unwanted redirect. markfalsepositive() now returns a small JSON response instead of a redirect (it was only ever called via fetch, never a plain form submit), and the button's own JS removes its row and decrements the tab + panel-header counts in place. No reload, no navigation.

Fixed JED Checker compliance issues ahead of Joomla Extensions Directory submission: removed the reserved word "Free" from the extension's resolved display name, fixed a mismatch between the display name and the admin menu label, and added a missing GPL license header to admin/helpers/data/joomla_core_checksums.php.

Security: removed the temporary Fleet direct-trigger diagnostic tooling added in v3.5.3/v3.5.4 (scanner.fleetping, scanner.viewfleetdebuglog, and the debug log file they wrote). That log folder's own .htaccess blocks direct web access on Apache but not on Nginx or an Apache host with AllowOverride disabled, so it was removed proactively now that its diagnostic purpose (confirming the Fleet direct-trigger block happens at the network/hosting layer, not in this extension's code) has been served. Any leftover log file from v3.5.3/v3.5.4 is deleted automatically on update to this version.

Fixed: "Mark as Safe" occasionally reloaded the page twice from a single click, confirmed via diagnostic logging (one markfalsepositive POST, two subsequent reloads a second apart). The reload is now guarded to fire only once, and the click handler stops event propagation so it can't be picked up by anything else. Diagnosis update: the Fleet Dashboard direct-trigger issue is confirmed to be a host-level bot/WAF block on the site's hosting provider intercepting requests before they reach this site's PHP at all -- outside anything either codebase controls, requires the hosting provider to allowlist the request.

Added: temporary diagnostic tooling for the Fleet Dashboard direct-trigger issue -- a debug log at admin/helpers/data/fleetdebug.log, a no-secret scanner.fleetping task to test reachability directly, and scanner.viewfleetdebuglog (normal admin session required) to read the log without FTP/SSH access. Intended to be removed once the root cause is confirmed.

Fixed: reduced false-positive malware/virus detections from hosting-provider and third-party AV scanners (SiteGround Site Scanner, VirusTotal-aggregated engines) on admin/helpers/muruguard.php. Extended v2.8.7's string-fragmentation fix to 7 remaining signatures that spelled out dangerous PHP function names as raw literals -- detection behavior is verified byte-for-byte unchanged, only the on-disk byte sequence differs.

Fixed: Fleet Dashboard direct trigger (v3.5.0) was unreachable on every site -- the component dispatcher required a logged-in session for the fleettrigger task, which was never exempted like the existing scheduledcheck webcron endpoint was. Now fixed.

Added

• Fleet bulk actions now trigger immediately instead of only waiting for a site's next check-in. "Re-scan selected" and "Push hardening config" on the Fleet Dashboard attempt a direct call to each selected site the moment you click, so a site with no scheduled scanning configured doesn't sit pending until someone happens to log in. Falls back to the existing queue-and-wait behavior automatically for a site that's unreachable (offline, firewalled, or running a version older than this one). Secured with its own dedicated, randomly-generated token -- separate from the site's license key and separate from its own external-cron token -- rate-limited server-side, and validated against SSRF (the dashboard refuses to call a "site" that's a private/internal/loopback address or resolves to one, even if the domain string was forged).

Fixed

• Marking a finding as safe could jump you to a different results tab. Dismissing a finding reloads the page to refresh every tab's counts, but which tab reopened was previously computed as "the first tab with any findings" -- not necessarily the one you were on. Now remembered across the reload, so dismissing something on SPPB Assets or Super Users keeps you there instead of bouncing back to Suspicious Files.
• Restoring a dismissed false positive (Settings > Protection > False Positives) kicked you out of Settings entirely, back to the plain dashboard view -- the one settings-related action that hadn't been updated to use the same tab/panel-preserving redirect every other Settings save already uses.

Fixed

• Marking a finding as safe could jump you to a different results tab. Dismissing a finding reloads the page to refresh every tab's counts, but which tab reopened was previously computed as "the first tab with any findings" -- not necessarily the one you were on. Now remembered across the reload, so dismissing something on SPPB Assets or Super Users keeps you there instead of bouncing back to Suspicious Files.
• Restoring a dismissed false positive (Settings > Protection > False Positives) kicked you out of Settings entirely, back to the plain dashboard view -- the one settings-related action that hadn't been updated to use the same tab/panel-preserving redirect every other Settings save already uses.

Fixed

• The single biggest false-positive source found yet: an unrecognized top-level webroot folder was flagging every file inside it individually, all as duplicate High-confidence findings repeating the exact same fact. Confirmed on a real site: a ~200MB unrelated third-party application (nothing to do with Joomla) installed in its own top-level folder produced over 16,000 duplicate findings this way. Now the folder itself is still flagged once, so it's not invisible -- but files inside are only flagged individually based on actual content-signature matches, exactly like every other "unrecognized container" case this scanner already handles (a known extension's own data folder, an icon-font asset-only folder). A real backdoor planted anywhere inside is still caught on its own merits; verified with a regression test against a real temp directory tree, including one with an actual injected backdoor pattern.

Fixed

• The single biggest false-positive source found yet: an unrecognized top-level webroot folder was flagging every file inside it individually, all as duplicate High-confidence findings repeating the exact same fact. Confirmed on a real site: a ~200MB unrelated third-party application (nothing to do with Joomla) installed in its own top-level folder produced over 16,000 duplicate findings this way. Now the folder itself is still flagged once, so it's not invisible -- but files inside are only flagged individually based on actual content-signature matches, exactly like every other "unrecognized container" case this scanner already handles (a known extension's own data folder, an icon-font asset-only folder). A real backdoor planted anywhere inside is still caught on its own merits; verified with a regression test against a real temp directory tree, including one with an actual injected backdoor pattern.
• AI Review contrast in the Code Issues modal. Text and the "Ask AI" button used light/colored styling against the modal's white background that was hard to read. Switched to solid black text and a white button with a visible border.

Fixed

• Pre-update snapshot exemption now also covers templates, not just plugins/components -- tmp/joomtower_snapshots/.../files/templates/<name>/... from a currently-installed template (e.g. Helix Ultimate framework templates) was still flooding the results the same way the previous release's plugin/component fix addressed, just for a different extension type. Same registry-checked guarantee: an unregistered/fake template name gets no exemption.

Fixed

• AI Review UI overhaul + moved to the main results table. The Ask AI button/result inside the Code Issues modal is now a proper card (icon badge, clear heading, response bubble) instead of plain unstyled text. A new 🤖 shortcut also sits directly in each file row next to "Mark as Safe" -- opens the same modal and runs the review in one click instead of two. Hidden entirely for directory findings (nothing for the AI to read) and for folder-only rows in general.
• Pre-update snapshot exemption now also covers templates, not just plugins/components -- tmp/joomtower_snapshots/.../files/templates/<name>/... from a currently-installed template (e.g. Helix Ultimate framework templates) was still flooding the results the same way the earlier plugin/component fix addressed, just for a different extension type. Same registry-checked guarantee: an unregistered/fake template name gets no exemption.

Added

• AI review of individual scan findings. From the Code Issues view on any flagged file, click "Ask AI to review this file" to get a plain-English opinion from the Smart AI Assistant on whether it's a genuine concern or something the scanner's signature/location heuristics just don't recognize (a legitimate vendor file, a standard core file, etc.) -- grounded in the file's actual content, not just its name or location. Deliberately advisory only: it cannot mark a finding safe, delete anything, or change a confidence level on its own. It's a second opinion to read alongside the finding, since the AI can be wrong too -- "Mark as Safe" and the existing delete actions remain the only things that actually change a finding's state.

Fixed

• Massive false-positive flood from site-management "pre-update snapshot" backups. Tools that snapshot an extension's entire source tree into tmp/ before updating it (e.g. tmp/joomtower_snapshots/<label>/files/...) were having every single vendor PHP file inside individually flagged as "executable file inside an upload directory" -- thousands of ordinary, unmodified plugin/component files on a real site, none of them actually suspicious. Now recognized narrowly: a snapshot path is only exempted from that specific structural check when it names a plugin or component that is CURRENTLY actually installed (checked against the live #__extensions registry), so a fake snapshot folder imitating this naming convention for something that isn't really installed gets no exemption. Content-signature scanning is completely unaffected either way -- a real backdoor planted inside a snapshot folder is still caught the same as anywhere else.

Fixed

• Massive false-positive flood from site-management "pre-update snapshot" backups. Tools that snapshot an extension's entire source tree into tmp/ before updating it (e.g. tmp/joomtower_snapshots/<label>/files/...) were having every single vendor PHP file inside individually flagged as "executable file inside an upload directory" -- thousands of ordinary, unmodified plugin/component files on a real site, none of them actually suspicious. Now recognized narrowly: a snapshot path is only exempted from that specific structural check when it names a plugin or component that is CURRENTLY actually installed (checked against the live #__extensions registry), so a fake snapshot folder imitating this naming convention for something that isn't really installed gets no exemption. Content-signature scanning is completely unaffected either way -- a real backdoor planted inside a snapshot folder is still caught the same as anywhere else.

Fixed

• Version badge and "Check for updates" link readability, matching the same fix already shipped on Free -- merged into a single clickable pill (v3.3.1 | Check for updates) in both places the badge appears (pre-scan hero and the post-scan re-scan bar), instead of the link sitting separately in low-contrast light gray text.

Added

• Fleet bulk actions. The Fleet Dashboard on the customer dashboard can now trigger a remote re-scan or push a recommended hardening config (Protection Mode, attack-pattern blocking, brute-force blocking, bad user-agent blocking) across every licensed site at once, instead of logging into each site's admin individually. Since the dashboard can never reach into a site directly, an action is queued and delivered the next time that site checks in via its existing Fleet Reporting call, executed there, and acknowledged back on the following check-in -- so it's automatic once queued, no extra step needed on the site itself.

Fixed

• Version badge and "Check for updates" link readability. The link previously sat on its own row in light gray text, hard to read and visually disconnected from the version pill above it. Merged into a single clickable pill (v3.0.5 | Check for updates), one row instead of two.
• "Built for SP Page Builder & Helix Sites" hero callout was low-contrast, floating text. Boxed it with a visible background and border and darkened the text so it reads clearly against the hero's gradient background.

Added

• "Check for updates" link next to the version badge. New releases have always been delivered through Joomla's own Extensions update system rather than a separate download, but nothing on the dashboard said so. A small link now sits right under the version badge, pointing straight at System > Manage > Update.

Fixed

• The version badge and "Get security alerts" newsletter banner showed up on the Settings and Support panels too, not just the dashboard. Both live outside the dashboard's own content area (so they're visible before a first scan has ever run), which meant opening Settings/Support -- which only ever hid the dashboard content itself -- never hid them either. Now hidden/restored together with the panel switch.

Fixed

• The new WAF's command-injection signature (waf_cmd_injection) false-positived on ordinary Joomla traffic, including SP Page Builder editing, template style editing, and Helix Ultimate AJAX calls -- confirmed live against a real site's Protection Log. The signature treated a bare "&" as a "shell metacharacter" and "id" as a "dangerous command," but "&id=" is just an ordinary query-string parameter (id is arguably the single most common parameter name in all of Joomla) -- so almost any URL with two or more parameters could trip it. Logged-in admin sessions were protected from being blocked by the existing admin-exemption, but a non-admin visitor with WAF blocking enabled would have been. Narrowed to ";", "|", backtick, and literal "&&" (a real shell AND-operator, essentially never present by coincidence in a query string), and dropped "id" from the command list.

Added

• Active Web Application Firewall (Pro). New "Active Web Application Firewall" switch under Site Protection blocks generic SQL injection, XSS, local/remote file inclusion, and OS command-injection patterns in incoming requests -- broader than Protection Mode's original webshell-specific signatures, which stay on regardless of this switch and are checked first. Includes a signature for Joomla's CVE-2023-23752 unauthenticated webservices probe. Runs only when the existing narrow check finds nothing, so a request is never scored twice, and every proximity-free (name-and-value-not-confirmed-adjacent) match is logged rather than auto-blocked to keep false positives out of the blocking path.

Fixed

• Site Protection settings could be toggled and saved even when the MuRu Guard Shield plugin isn't installed or enabled, silently doing nothing while looking fully configured. Every toggle in that form is now disabled in the UI when the plugin isn't active, and the save itself is refused server-side too.
• Fleet Dashboard reporting could re-run a full, redundant filesystem scan on top of results a scheduled check had already computed, since it read findings through the browser-page-load-oriented getFileFindings() (session-cache-or-rescan) instead of the results already sitting on the same model instance. Now reads them directly.

Fixed

• Site Protection settings could be toggled and saved even when the MuRu Guard Shield plugin isn't installed or enabled, silently doing nothing while looking fully configured. Every toggle in that form is now disabled in the UI when the plugin isn't active, and the save itself is refused server-side too (not just a UI courtesy -- a direct POST couldn't bypass it either).

Added

• File Integrity Monitoring is now wired into scheduled-check notifications. A drifted file caught by an integrity check now rides the exact same email and Slack/Discord/Telegram alert pipeline as a regular scheduled-scan finding -- no separate "check your baseline" habit required. Alerts only on genuinely new drift (same suppression logic that already avoids re-alerting on a site's pre-existing findings), so a still-unresolved change doesn't re-notify every single day.

Changed

• File Integrity Monitoring moved out of the "Automations" settings tab into its own "Integrity" tab. It isn't an automation (Fleet reporting, alert channels) -- it's a manual baseline/check action, and sharing a tab with unrelated toggles was confusing. Also fixes a layout issue where the FIM card sat flush against the Automations tab's Save Settings button with no spacing between them.

Added

• File Integrity Monitoring (Pro). Hash every scanned file once as a known-good baseline, then check for any file whose content changed since -- catches a payload hidden inside an already-trusted file, independent of signature matching. New "File Integrity Monitoring" card under Settings > Pro Features: Create/Rebuild Baseline and Check Integrity Now, both driven by the same chunked-request architecture the scanner itself uses so hashing a large site can't hit a host's execution-time limit either. Deliberately never runs automatically and never updates the baseline on its own -- a legitimate update changes files too, so drift findings land at medium confidence with guidance to rebuild the baseline after an intentional change, and only files present in BOTH the baseline and the current scan with a different hash are reported (a brand-new file is left to the regular scanner's own unrecognized-file checks).

Fixed

• "Run a Scan" threw closeScanModal is not defined in the browser console and never started a scan. The new chunked-scan JS (muruRunChunkedScan()) was declared in the page's outer script scope while closeScanModal() is scoped inside an IIFE elsewhere on the page -- calling it from outside that IIFE fails regardless of call order, since JS closures resolve by where a function is defined, not by where it's called from. Moved the chunked-scan functions inside the same IIFE so they share scope with it.

Fixed

• "Run a Scan" threw closeScanModal is not defined in the browser console and never started a scan. The new chunked-scan JS (muruRunChunkedScan()) was declared in the page's outer script scope while closeScanModal() is scoped inside an IIFE elsewhere on the page -- calling it from outside that IIFE fails regardless of call order, since JS closures resolve by where a function is defined, not by where it's called from. Moved the chunked-scan functions inside the same IIFE so they share scope with it.

Added

• Chunked, resumable scanning. A "Run a Scan" click no longer runs the entire filesystem+database scan inside one blocking HTTP request. Instead, the scan is broken into small pieces (one directory area, the webroot/core-entry checks, or the database scan at a time), each bounded to a fixed wall-clock budget server-side, driven by a progress-bar loop in the browser. No single request can ever run long enough to hit a host's execution-time limit, regardless of how large the site is -- this is the direct fix for scans that could previously come back as a bare "500 - Whoops" on a large filesystem with no results at all. Progress is persisted to disk between calls, so it survives even if a single very large folder takes several chunk calls to get through. If a folder is so large that even its own chunk call runs out of budget partway through, that area is reported as scanned-up-to-the-time-budget rather than silently passing as complete. Fleet Dashboard reporting still fires once the chunked scan completes, same as a normal scan. Falls back to the previous one-request behaviour automatically if JavaScript/fetch isn't available.

Added

• Chunked, resumable scanning. A "Run a Scan" click no longer runs the entire filesystem+database scan inside one blocking HTTP request. Instead, the scan is broken into small pieces (one directory area, the webroot/core-entry checks, or the database scan at a time), each bounded to a fixed wall-clock budget server-side, driven by a progress-bar loop in the browser. No single request can ever run long enough to hit a host's execution-time limit, regardless of how large the site is -- this is the direct fix for scans that could previously come back as a bare "500 - Whoops" on a large filesystem with no results at all. Progress is persisted to disk between calls, so it survives even if a single very large folder takes several chunk calls to get through. If a folder is so large that even its own chunk call runs out of budget partway through, that area is reported as scanned-up-to-the-time-budget rather than silently passing as complete. Falls back to the previous one-request behaviour automatically if JavaScript/fetch isn't available.

Added

• Chunked, resumable scanning. A "Run a Scan" click no longer runs the entire filesystem+database scan inside one blocking HTTP request. Instead, the scan is broken into small pieces (one directory area, the webroot/core-entry checks, or the database scan at a time), each bounded to a fixed wall-clock budget server-side, driven by a progress-bar loop in the browser. No single request can ever run long enough to hit a host's execution-time limit, regardless of how large the site is -- this is the direct fix for scans that could previously come back as a bare "500 - Whoops" on a large filesystem with no results at all. Progress is persisted to disk between calls, so it survives even if a single very large folder takes several chunk calls to get through. If a folder is so large that even its own chunk call runs out of budget partway through, that area is reported as scanned-up-to-the-time-budget rather than silently passing as complete. Fleet Dashboard reporting still fires once the chunked scan completes, same as a normal scan. Falls back to the previous one-request behaviour automatically if JavaScript/fetch isn't available.

Added

• Chunked, resumable scanning. A "Run a Scan" click no longer runs the entire filesystem+database scan inside one blocking HTTP request. Instead, the scan is broken into small pieces (one directory area, the webroot/core-entry checks, or the database scan at a time), each bounded to a fixed wall-clock budget server-side, driven by a progress-bar loop in the browser. No single request can ever run long enough to hit a host's execution-time limit, regardless of how large the site is -- this is the direct fix for scans that could previously come back as a bare "500 - Whoops" on a large filesystem with no results at all. Progress is persisted to disk between calls, so it survives even if a single very large folder takes several chunk calls to get through. If a folder is so large that even its own chunk call runs out of budget partway through, that area is reported as scanned-up-to-the-time-budget rather than silently passing as complete. Falls back to the previous one-request behaviour automatically if JavaScript/fetch isn't available.

Fixed

• Scanning could crash with a generic "500 - Whoops" error on hosts that list set_time_limit() in disable_functions (common on some shared/managed hosting). The scan controller's best-effort attempt to raise the execution time limit called set_time_limit() unconditionally behind an @ suppression operator -- but calling a function that's been disabled at the PHP level throws an uncaught fatal Error, which @ does not and cannot suppress (it only silences warnings/notices). Now guarded with function_exists() first, so the scan simply proceeds with whatever limit the host already allows instead of crashing outright.

Added

• Pre-scan server limits advisory. The scan-gate screen now shows an actionable warning, before a scan is started, when the host won't let execution time or memory limit be raised -- including the current values and a ready-to-paste .user.ini snippet -- instead of only surfacing the problem after a large scan dies partway through.

Fixed

• Scanning could crash with a generic "500 - Whoops" error on hosts that disable set_time_limit() (common on shared hosting). The scan controller's own attempt to raise its execution-time limit called set_time_limit() unconditionally -- calling a disabled function is an uncaught fatal Error, not a warning that @ can suppress. Now guarded with function_exists() first.
• The version badge and the "Get security alerts & updates" banner only appeared after running at least one scan. Moved both to a persistent header shown regardless of scan state.

Added

• Server-limits advisory on the pre-scan screen. If the host won't let the scan raise its execution-time or memory limit, a warning now shows before running a scan -- current values, which are locked, and a .user.ini snippet to fix it.

Added

• Optional "Get security alerts & updates" banner on the dashboard. Dismissible, asks only for name (optional) and email, and never shows again once dismissed or subscribed. Submits to the same subscriber list the main Lyzerslab site's own newsletter form uses, so Free users can opt in without needing an account or license key.

Fixed

• Static-assets-only custom webroot folders (e.g. a template's /fonts folder) still showed up as a Medium-confidence finding, requiring an individual "Mark as False Positive" click per file even though the underlying content is provably inert. Now given the same treatment as a known extension's own companion data folder: no structural flag at all, but every file inside is still fully content-scanned.
• Further AV/hosting-scanner false positives on this scanner's own admin/helpers/muruguard.php (Huorong via VirusTotal, SiteGround Site Scanner -- same GitHub issue as the last release, still reproducing). Two more signatures (gsocket_indicator, phpkoru_encoder) still contained their trigger brand names as one contiguous literal string; split into concatenated fragments like webshell_generic and rce_loader_param_combo already were.

Changed

• Removed the "AI Integration" and "Security Report" toolbar buttons. Both were Pro-only links out to the marketing site with a static "PRO" badge -- not a working feature on Free, so they were just clutter. .htaccess Hardening (a real Free feature) stays.

Fixed

• Static-assets-only custom webroot folders (e.g. a template's /fonts folder) still showed up as a Medium-confidence finding, requiring an individual "Mark as False Positive" click per file even though the underlying content is provably inert. Now given the same treatment as a known extension's own companion data folder: no structural flag at all, but every file inside is still fully content-scanned.
• AV/hosting-scanner false positives on this scanner's own admin/helpers/muruguard.php (Huorong via VirusTotal, SiteGround Site Scanner). gsocket_indicator, webshell_generic, and phpkoru_encoder all still contained their trigger brand names as one contiguous literal string. Split into concatenated fragments -- detection behaviour is unchanged, only the on-disk byte sequence differs.

Fixed

• "Mark as False Positive" appeared to do nothing. The dismissal was being saved correctly, but the scan-results page reads from a 5-minute session cache on every load rather than re-scanning -- marking a finding safe never invalidated that cache, so the very next reload just showed the same stale pre-dismissal list. Same fix applied to un-marking a false positive (it now reappears immediately instead of waiting for the cache to expire).
• dompdf's own Helpers.php (bundled by multiple unrelated extensions -- com_dpcalendar, ConvertForms' PDF tool, com_rsseo, and others) flagged High as stream_wrapper_payload. It legitimately parses phar:///file:// resource URLs as part of normal PDF asset loading. Added a narrow, per-file, per-signature exemption matched by dompdf's own stable internal path (dompdf/dompdf/src/Helpers.php), not a blanket "don't scan this vendor folder" skip -- every other signature still runs fully against these files.

Fixed

• 503 errors during filesystem scan caused by catastrophic regex backtracking in rce_loader_param_combo and rce_loader_param_combo_live. Both signatures now use a multi strpos pre-check before the regex runs. Added pcre.backtrack_limit and pcre.recursion_limit caps in scanFileContent().

Security Live request scanning could miss webshell indicators when suspicious values were supplied through POST parameter names rather than parameter values. scanRequestForAttack() previously inspected flattened GET/POST values but did not include parameter names. The scanner now includes GET and POST parameter names in the combined request data, allowing request signatures to detect suspicious parameters regardless of whether they are supplied through the query string or POST body. rce_loader_param_combo_live only recognised query-string syntax. The signature now detects the ac, path, api, and t parameter combination both in query-string form and as standalone parameter names supplied by the request scanner. All four parameters must still be present together, keeping the generic t parameter from triggering the rule by itself. This remains a High-severity, block-eligible detection. Added live detection for d_time webshell probes. Requests containing a d_time parameter are now recorded as a Medium-severity signal associated with a known remote-loader webshell family. This detection is intentionally log-only to reduce false positives. Added live detection for p8 webshell authentication probes. Requests containing a p8 parameter are now recorded as a Medium-severity signal associated with a known file-manager webshell authentication gate. This detection is also log-only because p8 is a short and potentially legitimate parameter name. bengali_path_obfuscation remains scan-mode-only by design. This signature detects a specific Bengali-character substitution table inside PHP source code and therefore requires access to file contents. Live request scanning cannot reliably detect this source-code construct because it only has access to HTTP request data.

What's new

• Backend Access (MuRu Shield Hardening) now works on Nginx, not just Apache. .htaccess is Apache-only -- on Nginx (or any host with AllowOverride None or a missing mod_auth_basic), activation always failed. The companion Shield plugin (bump to 1.2.2) now enforces the same Basic Auth gate at the PHP layer on every request, so it works identically on Apache, Nginx, and LiteSpeed as long as the Shield plugin is installed and enabled.
• Clearer activation errors: if Backend Access still fails to activate and the Shield plugin isn't installed/enabled, the error now says so directly instead of only showing generic Apache/Nginx troubleshooting text.
• IP Access List moved into its own Settings tab, separate from Site Protection, with an entry-count badge. Settings sub-tabs now remember which one you were on after saving/adding/removing something in them.
• Fixed: adding or removing an IP Access List entry redirected to the main Dashboard panel instead of back to Settings.

What's new in 1.2.4

• Replaced direct CSS output with the WordPress style enqueue system
• Removed the error_reporting() call
• Removed all automatic wp-config.php modifications — configuration is now read-only, with manual setup instructions provided in the admin UI
• Removed automatic debug constant changes during deactivation and auto-disable
• Updated the admin UI and AJAX responses to reflect the new manual configuration workflow
• Cleaned up deprecated configuration and scheduling logic

New in this release (Pro)

• License system: activate/verify a license key directly from Settings > License, with automatic status checks and clear messaging when a key is invalid, revoked, or expired.
• Smart AI Assistant: chat-based project assistant with file read/search/write/rename/delete tools, a Custom Skill (project-specific instructions) field, and a rewritten system prompt that performs real multi-file investigations for "scan my project" style requests instead of a shallow summary.
• Automations (Fleet Dashboard, Alert Channels, Security Report):
  • Fleet Dashboard reporting — pushes a status summary (finding counts, protection status, version) to your Lyzerslab dashboard after every scan, so you can monitor every licensed site in one place.
  • Instant Slack/Discord/Telegram alerts on new findings from scheduled scans.
  • One-click branded, print-ready Security Report.
• MuRu Shield Hardening: server-level (.htaccess) HTTP Basic Auth gate in front of /administrator, verified with a real self-test and automatic rollback before it's ever treated as active, plus an Emergency Mode to lock the entire site during incident cleanup. Requires Apache or LiteSpeed with .htaccess support.
• Help Center: a direct in-admin contact form, no account or license required.
• Detection improvements: expanded database-level XSS scanning to cover Helix Ultimate/Helix 3 template style Custom JavaScript/CSS fields (previously only #__menu was checked), a new signature for a known attacker "calling card" marker, and several false-positive fixes (host-generated error_log files, sitemap variant files).
• License status freshness: license cache window reduced from 24h to 1h, and a revoked/deleted license now propagates correctly across every panel instead of showing stale "Active" status.

Five issues reported against 2.7.1, four of them genuine security findings. Thank you to @degiosa and @PhilETaylor for the reports.

Security

• helpers/data/*.json was readable, unauthenticated, on any non-Apache stack. That folder (attack log, failed-login usernames, the manual IP allow/block list, every visitor IP ever geolocated) was protected only by a shipped .htaccess, which nginx, Caddy/FrankenPHP, LiteSpeed running in its nginx-compatible mode, and IIS all ignore outright -- on any of those, every one of those files was a plain GET away with no session required. Every data file this component owns is now a .php file that starts with an executable stub (http_response_code(403); exit('Forbidden');) -- requesting it directly now executes that stub and returns a 403 on literally any server capable of running Joomla at all, which is the only protection that doesn't depend on a specific web server or its configuration being correct. The .htaccess stays as defence in depth on Apache, it's just no longer the only thing standing between this data and the internet. Existing installs migrate automatically: the first read/write after upgrading carries old *.json content into the new stub-protected *.php file and deletes the legacy file outright, rather than leaving an abandoned, still-readable copy sitting next to it.
• Protection Mode was fully bypassed for any authenticated user, not just admins. runShieldCheck() returned before pattern-matching, country-blocking, and logging for any non-guest session -- Joomla ships frontend user registration on by default, so an attacker could self-register, log in, and every subsequent request-pattern rule was skipped entirely, with nothing even logged. The exemption now requires core.login.admin -- the exact permission Joomla itself uses to decide who can log into the administrator at all -- so a self-registered low-privilege account gets full protection, identical to a guest. A genuinely admin-capable user is still never blocked by a pattern/country match (avoiding a real admin's own action, or their own travel/VPN IP, locking them out), but that match is now always logged regardless, so this exemption can no longer become a silent blind spot.
• Brute-force IP blocking had no proxy awareness, keying purely on REMOTE_ADDR. Behind Cloudflare, a load balancer, or NAT, every visitor can share one edge IP -- a handful of failed logins from any one of them crossed the threshold and returned a plain 403 to the entire site for everyone behind that IP. Added an opt-in (off by default) "Trusted proxy header" setting in Settings → Protection, letting an admin who has verified their site is genuinely always behind a specific proxy select which header (CF-Connecting-IP, X-Forwarded-For, X-Real-IP, True-Client-IP) carries the real visitor IP. Left on "None", behaviour is unchanged from before. The header value is only ever trusted when explicitly configured -- never by default, since blindly trusting a client-supplied header would let any visitor spoof their own IP.
• The Protection Log's 500-entry ring buffer could be flushed by the same attacker it was logging. Evicting the oldest entry to make room for a new one meant roughly 500 cheap follow-up requests could age a real intrusion's log entries out of the only copy that ever existed -- erasing the evidence the log exists to preserve. Entries evicted from the live 500-entry view are now appended to a separate, equally stub-protected archive file (capped at 20,000) instead of being discarded, raising the cost of "erase the evidence" by 40x. The Protection Log now shows a note when older entries exist in the archive.

Fixed

• components/com_jce/editor/libraries/views/plugin/index.php (JCE's own core file) was flagged High confidence as a disguised webshell. Confirmed against several real, current JCE installs: this file is JCE's own legitimate HTML wrapper layout for its editor plugin dialog windows, using JCE's defined('JPATH_PLATFORM') or die access-guard convention rather than Joomla's own blank _JEXEC stub -- structurally indistinguishable from an actual disguised webshell to the "non-standard index.php" heuristic, which had no exemption for it. Added a precise, path-exact exemption from this one structural check only; the ordinary content-signature scan still runs on this file regardless, so an actual backdoor dropped at this exact path is still caught.

Investigated

• A downloaded release zip was flagged by Microsoft Defender as Backdoor:JS/Chopper.GG!dha. This scanner's own JavaScript (the admin template's inline <script> blocks) contains no eval, Function(), document.write, or obfuscation of any kind -- reviewed line by line, nothing resembling that signature is actually present. The far more likely explanation is the same false-positive class already seen on this project (see the 2.4.5 entry above, and a similar report against a third-party scanner): the component's own malware-detection signature database necessarily contains the literal text of the patterns it detects (eval(base64_decode, gsocket, FilesMan, c99shell, ...) inside PHP string literals, repeated again in prose in the README and CHANGELOG -- exactly the kind of keyword density a cloud heuristic classifier can misjudge. This isn't something a code change on our end can reliably fix (the classification happens entirely on Microsoft's end); if you hit this, the effective path is Microsoft's own file-submission/false-positive review at https://www.microsoft.com/en-us/wdsi/filesubmission.

Fixed

• Version badge styling: fixed a missing space between two Tailwind classes (bg-[#EF89EB]text-gray-200) that merged them into one invalid class, silently dropping both the background and text color.

Added

• "Mark as Safe" on every finding row (Suspicious Files, Cleanable Files, Super Users, Menu XSS, SPPB Assets, Rogue Iconfont, Template Defacement) -- dismisses a specific finding as a false positive so it's no longer flagged on future scans. Deliberately NOT a simple path/row-id suppression: every dismissal is fingerprinted against the exact reasons text reviewed at the time (MuruguardHelper::fingerprintReasons()), so if the same file/row later matches something DIFFERENT (e.g. an attacker overwrites a previously-dismissed path with a real backdoor), the fingerprint no longer matches and it reappears as a fresh finding rather than staying silently hidden forever -- verified with an explicit test simulating exactly that scenario. New "False Positives" management section in Settings lists every current dismissal with a one-click restore. Same edit-level permission as Clean.

Security

• administrator/components/com_muruguard/helpers/data/ (attack log, IP allow/block list, login attempts, GeoIP cache, and now the false-positives list) had no protection against direct HTTP access to a known filename -- the folder's index.html only ever blocked directory listing, not a direct request for e.g. .../data/attack-log.json. Added .htaccess denying all direct access to this folder outright (both modern and legacy Apache syntax), found and fixed while reviewing where the new false-positives data would live.

Fixed

• False positive: the MuRu Guard Shield plugin's own folder flagged as a fake/malicious plugin when its files are present but not yet installed through Joomla (e.g. uploaded via FTP but Install was never clicked in Extensions > Manage). Added a specific, accurate, non-alarming message explaining exactly what this is and how to resolve it (install the plugin), replacing the generic "no matching #__extensions row" wording -- still shown, not silently hidden, so the admin is prompted to actually finish activating real-time protection.

Fixed

• The 2.6.2 admin submenu was missing an explicit "Dashboard"/"Overview" item -- confirmed working (arrow icon, expandable, Settings + Support both present) via the site's own rendered HTML, but Dashboard was deliberately left out on the assumption that clicking the parent "MuRu Guard" item itself was enough; that's not what's actually expected here. Added as a third child, positioned first. Idempotency is now checked PER ITEM (by exact link) rather than "does the parent already have any children at all" -- sites that already got Settings/Support from 2.6.2 will only have the new Dashboard item added on their next update, not duplicate rows for the two that already exist.

Fixed

• The 2.6.0 sidebar submenu didn't actually appear as an expandable dropdown under "MuRu Guard" in the primary left admin menu tree (confirmed via the site's own rendered HTML: class="no-dropdown", no child items). HTMLHelper::_('sidebar.addEntry', ...) populates a different, separate in-page panel -- it was never going to produce the arrow-icon/expandable-children behavior seen on components like SP Page Builder. That requires actual child rows in Joomla's admin menu table (#__menu) sharing the same parent_id as the component's own auto-created menu item. Added this properly via the install script (script.php), using Joomla's own nested-set-safe Table\Menu API (setLocation() + rebuild()) rather than raw SQL, since #__menu's lft/rgt columns are shared by every admin menu item on the whole site -- a wrong raw INSERT could corrupt the entire admin sidebar, not just this component's part of it. Adds "Settings" and "Support" as children (no separate "Dashboard" child needed -- the parent item's own link already goes straight there). Idempotent: only runs once, never touches an already-populated submenu, so it's safe on repeated updates. This only takes effect on an actual install/update through Joomla's installer, same as the ACL default from 2.6.0.
• Moved the version badge out of the floating top-right corner into the existing scan-results toolbar (next to "Last scanned" / cron status), instead of a separate floating element.

Changed

• Settings and Support are now reached ONLY through the new left-sidebar submenu (under the MuRu Guard menu item) added in 2.6.0, not duplicated as floating buttons in the top-right corner. The top-right area now shows just the version badge.

Security

• This scanner's own files were completely invisible to itself. SAFE_COMPONENT_PATHS blanket-skipped ALL scanning (not just content signatures -- every structural check too) for administrator/components/com_muruguard/ and its pre-rebrand name com_sppbscan/, meaning a real backdoor injected into the scanner's own code would never have been detected. Replaced with SELF_CONTENT_SIGNATURE_EXEMPTIONS, a narrow, per-file, per-signature allow-list covering ONLY the specific, empirically-verified content-signature matches that come from helpers/muruguard.php and models/scanner.php legitimately containing their own signature definitions and marker strings as source text (e.g. the literal text "xss.report", "FilesMan", "gsocket"). Every other content signature and every structural check now runs normally against this scanner's own files, including these same two files. Verified with a real backdoor injection test: eval(base64_decode($_POST['cmd'])) appended to the scanner's own helper file is correctly caught, while the genuine, unmodified files stay clean.

Added

• Left-sidebar submenu (Dashboard / Settings / Support), the same navigation pattern used by SP Page Builder and other multi-page components, instead of everything living behind floating header buttons only.
• Component version badge in the top-right header, read live from the installed manifest.
• "Support This Project" page with real funding details (Payoneer, PayPal Zoom/bKash) plus direct contact links, reached from the new Support submenu entry.
• Restricted to Super Users by default. A fresh install now denies core.admin/core.manage/core.delete/core.edit for the standard Manager and Administrator groups via a new install script (script.php), leaving only Super Users able to see or use the component out of the box -- they always bypass ACL entirely regardless of configuration. Only applied when the component's ACL is still completely untouched, so upgrading never silently overwrites a site owner's own already-customised permissions; access can always be granted back to any group afterwards via System > Users > Access Levels/Permissions.

Fixed

• False positive: an #__sppagebuilder_assets row named "icomoon" flagged "Non-default iconfont" and listed as a rogue/deletable registration. The docblock already documented "icofont, icomoon, ..." as known-legitimate iconfont names, but the actual comparison only ever checked against the single name icofont -- icomoon (IcoMoon's own extremely common icon-font export tool name, already allow-listed on the filesystem side) was never actually in the list it was compared against. Added a proper KNOWN_GOOD_ICONFONT_NAMES list covering both; a genuinely unrecognized name is still surfaced for review as before, and the underlying content checks (base64_decode/eval/script tags/PHP tags/event handlers) still run against every row regardless of name either way.

Fixed

• False positive: modules/index.html and templates/index.html (Joomla's own "prevent directory listing" blank stubs sitting directly at the group root) flagged as fake module/template folders. Same class of bug already fixed for plugins/<group>/index.html -- a bare file directly at the modules/ or templates/ root was being read as if its filename were itself a module/template name. Fixed for both.
• False positive: media/.../iconfont/icomoon flagged "Unrecognized folder inside icon-font asset directory". "icomoon" is IcoMoon's own icon-font export/build tool name -- a legitimate, common vendor subfolder (SP Page Builder's bundled icon picker uses it), not a red flag. Added to the allow-list.
• Real gap found while fixing the above: files nested two or more levels inside an iconfont/ tree (e.g. iconfont/icomoon/whatever.ext) were never checked against the icon-font file-type allow-list at all -- only files directly at the immediate iconfont/ level were. A non-executable-but-unexpected file type (anything other than the standard font/css/json/doc extensions) hidden inside an allowed subfolder like icomoon/ would previously slide through undetected by this check. Now checked at any depth, closing the gap the "icomoon" fix above would otherwise have introduced -- allow-listing a folder name is no longer a free pass for what's placed inside it.
• False positive: libraries/vendor/symfony/http-client-contracts/Test/Fixtures/web/index.php (a legitimate Symfony package's own test-fixture HTTP server script) flagged "Non-standard index.php". libraries/vendor/ is Joomla's bundled Composer dependency tree -- hundreds of third-party packages that don't follow Joomla's own "blank stub" index.php convention; a package's test fixtures/dev tooling can legitimately ship a fully functional index.php. This one structural signal isn't reliable for arbitrary vendor code; the ordinary content-signature scan (which runs on every file regardless of location) still catches an actual malicious payload dropped there.

Fixed

• The MuRu Guard Shield plugin flagged its own file (plugins/system/muruguardshield/muruguardshield.php) as a suspected webshell. A code comment explaining why user-agent blocking has its own toggle used eval(base64_decode()) as an illustrative example -- literal text that matches the eval_encoded_blob content signature. Same class of bug as the earlier com_sppbscan self-flagging issue, just via a comment instead of the signature table itself. Reworded the comment to avoid the literal pattern; see also the v1.1.1 Shield plugin release, which ships the corrected file.
• Widespread false positives on legitimate Joomla core/vendor files (templates/system/*.html, media/system/html/noxml.html, com_finder's HTML parser, libraries/vendor/php-debugbar/.../JavascriptRenderer.php, libraries/vendor/symfony/error-handler/.../exception_full.html.php, Helix Ultimate's comingsoon.php layouts) flagged as "obfuscated script injected right after <head> tag". The check searched for a <script> tag ANYWHERE later in the file after the first <head>, not actually adjacent to it -- so any file with both a <head> tag and an unrelated large/JS-heavy <script> block anywhere else in the document (a near-universal combination in real HTML-rendering code) matched, even when nothing was actually injected. Now requires the <script> tag to sit immediately after <head...> (only whitespace in between) -- the actual shape of a real head-injection defacement, which plants its payload as the very first thing in <head> specifically so it runs on every page. Verified: genuine immediate-injection patterns (including with realistic whitespace/newlines before the script tag) still correctly flagged; all five reported false-positive file shapes no longer match.

Added

• MuRu Guard Shield: manual IP Access List. Admin-managed persistent list of IPs/CIDR ranges to always block or always allow, independent of pattern/brute-force/country checks. Checked first, ahead of everything else -- an allow entry bypasses every other check; a block entry rejects unconditionally. IPv4 exact-address and CIDR entries are supported (IPv6 exact-address only, no CIDR containment).
• MuRu Guard Shield: bad user-agent blocking. Known scanner/bot user agents (sqlmap, nikto, acunetix, ...) were previously only ever logged. A new, separately-toggleable switch lets these be actively rejected, kept distinct from the general pattern-block switch since a User-Agent string alone is more prone to spoofing/false positives than an actual attack payload.
• MuRu Guard Shield: country blocking. Rejects requests from a configured list of countries, resolved via a free IP-to-country lookup (ip-api.com) cached indefinitely per IP -- a one-time network call per unique visitor IP ever seen, not a per-request dependency, and fails open (never blocks) if the lookup service is unreachable. Never applied to your own logged-in admin session, or to private/reserved IP ranges (localhost, LAN, ...). No GeoIP database is bundled -- deliberately avoids MaxMind licensing/staleness questions in favor of an on-demand, cached lookup.

Fixed

• Adding the ".htaccess Hardening" advisory as a 7th results tab pushed the tab bar to a second line. Moved it out of the tab bar entirely into its own modal, opened from a new "🛡 .htaccess Hardening" button in the toolbar (next to Change Scan Areas / Re-scan Now / AI Integration). Back to 6 tabs on one line. (Re-released as its own version number rather than an in-place update to 2.5.1, to avoid any ambiguity from a cached/stale download of a previously-issued version.)

Added

• New ".htaccess Hardening" tab — a read-only advisory that reads the site's actual root .htaccess and checks it against a fixed set of recommended directives: blocking PHP execution inside writable upload-style directories (media/images/uploads/tmp/cache — the single most directly relevant check, since a dropped webshell still runs the moment it's requested unless the server refuses to execute PHP there), disabling directory listing, blocking direct access to sensitive files (.env, .git, composer.json/lock, .sql/.bak), plus advisory security headers (X-Content-Type-Options, Permissions-Policy, HSTS -- only shown once the site is actually on HTTPS, Content-Security-Policy with an explicit caution about testing before enabling). Each missing check shows a copy-ready suggested rule. This tool never writes to .htaccess itself — a wrong edit to this specific file can take the whole site down with no way to test a rewrite rule server-side before it's live, so it only reports and suggests.

Fixed (in-place update to this same v2.5.1 package)

• Moved the .htaccess Hardening advisory out of the results tab bar (it pushed all 7 tabs to a second line) into its own modal, opened from a new button in the toolbar next to Change Scan Areas / Re-scan Now / AI Integration. Back to 6 tabs on one line.

Fixed

• Selecting a large batch (e.g. "Select all" on ~1800 flagged files) and clicking Delete/Clean failed with "The most recent request was denied because it had an invalid security token", alongside a PHP warning about max_input_vars being exceeded. Every bulk delete/clean form (Suspicious Files, Cleanable Files, Menu XSS, SPPB Assets, Template Defacement) submitted one POST field per selected checkbox — at scale this blew past PHP's default max_input_vars (1000) before Joomla ever saw the request, silently truncating the POST body, which could drop the CSRF token field along with it. The confusing "invalid token" message had nothing to do with the token actually being wrong.
• On submit, every checked box's value is now consolidated client-side into a single JSON-encoded hidden field, and the checkboxes' own name attributes are stripped so they never also submit individually — capping each request at a small, constant number of fields regardless of how many rows are selected (verified with a simulated 1800-target request: 1 POST field instead of 1800). The controller reads this consolidated field first and falls back to the original one-field-per-row array when it's absent (JS-disabled browsers, cached old page loads), so nothing regresses for smaller selections.

Fixed

• A confirmed, live webshell (libraries/init/init.php, dropped via the "PHPkoru" obfuscation service and confirmed malicious) sat in the Cleanable Files tab reporting "SKIPPED (no auto-cleanable pattern recognized)" on Clean, instead of Suspicious Files where Delete works. Root cause, more general than this one file: libraries/ has no #__extensions-style registry to structurally cross-reference the way templates/modules/plugins/components now do, so a file there with no OTHER structural red flag fell entirely on content-signature matching -- and isContentOnlyCodeAreaFinding() downgraded ANY content-signature-only finding in a code area to "Cleanable, review manually", regardless of whether the matched signature was medium (genuinely ambiguous, e.g. a commercial extension self-obfuscating for license protection) or high (this codebase's own existing severity tagging already calls that "unambiguous enough... to mark the whole file High confidence"). A high-severity content match now always routes to Suspicious Files/Delete, even with zero location-based corroboration — only genuinely ambiguous medium matches still get the cautious Cleanable/manual-review treatment. This is a general fix, not specific to one file or folder: it applies wherever a code-area file (components, modules, plugins, libraries, templates) is flagged purely by content.
• Added a dedicated, zero-false-positive-risk content signature for the "PHPkoru" obfuscation/encoding service specifically ([PHPkoru_Code] marker, phpkoru.com branding) — no legitimate Joomla file is ever processed through this tool, so this alone is now a high-severity match.

Fixed

• False positive: Joomla/Helix Ultimate's own disk-cache files (cache/helixultimate/<hash>-cache-helixultimate-<hash>.php) flagged as "Executable file inside an upload directory". This is Joomla core's standard cache-storage file naming convention (<md5>-cache-<group>-<md5>.php), used by core page caching and template frameworks like Helix Ultimate alike — not a compromise. cache/ now recognizes this exact shape and exempts it from the structural upload-directory check; content scanning still runs on it regardless, so a real backdoor merely named to mimic the pattern is still caught.
• False positive: administrator/components/com_akeebabackup/backup/index.php (Akeeba Backup's own non-blank protection stub) flagged "Non-standard index.php". com_akeeba (Akeeba's legacy Joomla 3 component id) was already a trusted SAFE_COMPONENT_PATHS entry; com_akeebabackup (the current Joomla 4/5 id, same vendor) was simply missing from the list. Added.
• False positive: plugins/captcha/index.html (Joomla's standard "prevent directory listing" stub sitting directly in a plugin group folder, not inside any specific plugin) was matched as if "index.html" were a plugin name, and flagged since no plugin is ever registered under that name. Bare files sitting directly at the group level are no longer treated as a plugin-name lookup.
• False positive: an entire, genuinely-installed, legitimate plugin folder (plugins/system/xformea, an admin-renamed copy of a real "Formea" plugin) flagged as fake. Renaming a plugin's folder (prefixing "x", "_", etc.) to disable it without touching the database is a common, legitimate Joomla admin technique — the #__extensions row survives under the plugin's original element, which no longer matches the renamed folder. Before concluding a plugin folder is fake, its own manifest XML (if present — Joomla's installer convention names it <element>.xml, unaffected by a later folder rename) is now also checked against the registry, so a renamed-but-real plugin resolves correctly while a genuinely fake, unregistered folder (no matching manifest either) is still flagged exactly as before.

Fixed

• False positive: real, stock Joomla plugins that ship disabled by default (plugins/api-authentication/basic, plugins/authentication/ldap, and others) were flagged as suspicious. The 2.4.9 #__extensions cross-check treated "disabled" as a fake-plugin signal, copying the logic that works for templates — but unlike templates, several genuinely core Joomla plugins are shipped disabled out of the box, so this flagged completely unmodified installs. The disabled-row check is removed for plugins; only a completely missing #__extensions row (never installed at all) is still flagged, which has no legitimate-install false-positive case.
• Fake components/com_xxx folders (confirmed malicious, matching the exact 2.4.9 eval_encoded_blob compromise) were landing in the Cleanable Files tab labeled "needs manual review" instead of Suspicious Files, where Delete actually works. Root cause: components were the one extension type with no structural (location-based) check at all — the 2.4.9 changelog flagged this as a known open gap, since that attack's fake component #__extensions rows were left enabled = 1, unlike its disabled fake template/plugin rows. Added getRegisteredComponents(), cross-referencing manifest_cache instead of enabled — Joomla's installer always populates this JSON blob from the extension's manifest at install time; a directly-inserted fake row has no reason to also forge it. A components/com_xxx folder with a missing #__extensions row, or a row with no populated manifest_cache, now gets the same structural finding templates/modules/plugins already get, which correctly routes it to Suspicious Files instead of Cleanable.

Fixed

• The 2.4.8 changelog claimed a fix ("index.php delete-safeguard") that was never actually committed. Confirmed fake template-root index.php files (real template name + random suffix, or tmpl_xxxxxx) were still landing in the Cleanable Files tab instead of Suspicious Files, where Clean correctly reported "SKIPPED (no auto-cleanable pattern recognized)" for every one of them, since there genuinely is no auto-repair pattern for a dropped file — only deletion applies. default.php's tab-routing logic now treats isProtectedEntryPath()'s determination for a template-root index.php as authoritative, routing confirmed-fake ones to Suspicious Files (where Delete works) instead of Cleanable.
• The view layer's Suspicious/Cleanable tab routing wasn't using the #__extensions registry check at all — only scanFilesystem(), scanDatabase(), and deleteTargets() were (since 2.4.8/2.4.9). getRegisteredTemplates() is now exposed to the view (view.html.php), and both isProtectedEntryPath() call sites in default.php now pass it through, so the strongest available signal is used consistently everywhere a file gets classified, not just at delete-time.
• cleanTemplateDefacement() (the Template Defacement tab's Clean action) didn't check the #__extensions registry, while scanDatabase()'s reporting of the same rows already did (since 2.4.8) — a #__template_styles row flagged only because its registry record is missing/disabled (manifest present, non-junk name) would show up as a finding but then always get skipped as "review manually" when the user tried to clean it. Both now use the same registry-aware logic.

Fixed

• A confirmed real compromise (32 files, found by a competing scanner after this one reported nothing) went completely undetected. Every file used the exact same shape: a commercial PHP obfuscation tool wrapping a fully-encoded backdoor in eval(base64_decode('...')), decoding its own embedded string rather than reading $_POST/$_GET directly. The only existing signature for eval() + base64_decode() required a superglobal read in the same call (eval_base64_post), so this exact "encrypted, self-decoding" pattern -- arguably the most common real-world PHP malware shape there is -- had no matching signature at all. Added a new, broader content signature (eval_encoded_blob, medium severity, since a handful of legitimate commercial extensions self-obfuscate the same way purely for license protection) that catches eval() wrapping base64_decode/str_rot13/gzuncompress/gzdecode/convert_uudecode in any combination, regardless of what's being decoded. Verified against all 32 real files from this compromise (100% match) and against Joomla core/vendor/stock-extension code (zero false positives).
• Dropped fake modules/<name> and plugins/<group>/<name> folders (holding the same backdoor) would have been routed to "Cleanable Files" instead of "Delete", the same class of bug fixed for templates in 2.4.4-2.4.8 -- a finding whose only reason is a content-signature match inside a code-area path is treated as "real file with injected code, don't delete outright". Added the same location-based structural check used for templates, adapted per extension type: a modules/ folder not named with Joomla's required mod_ prefix is disqualified on naming alone (no legitimate module is ever named otherwise); a plugins/<group>/<name> folder is cross-referenced against #__extensions the same way templates are. components/ is deliberately NOT covered by an equivalent check yet -- the same attack also faked components/com_feed, com_stat, com_base, com_track, com_util with matching #__extensions rows, but left those enabled = 1 (unlike the disabled fake template/plugin rows), so the "registered but disabled" signal that works elsewhere doesn't discriminate for components. Those files are still caught by the content-signature fix above; only the Delete-tab routing for them remains an open gap.

Fixed

• The fake-template detection added in 2.4.2 could itself be defeated. On a live, escalating attack, every on-disk signal it relied on -- the template folder, a templateDetails.xml manifest inside it, even the folder name itself (real template names plus a random suffix, e.g. beez3_rkgf, cassiopeia_tmzd, instead of the more obviously-fake tmpl_xxxxxx) -- had all been faked at once, so nothing was flagged (template_defacement correctly showed 0 when it should not have). Added a check against Joomla's own #__extensions table -- the actual source of truth for "is this template really installed" -- comparing each #__template_styles row and each templates/<name> folder against a matching, enabled extension record. The attacker was able to fake matching #__extensions rows too, but left every one of them enabled = 0, unlike the site's real templates -- so this is checked as the primary signal, ahead of (not instead of) the on-disk checks, since it's the one layer that couldn't also be silently spoofed. Verified against the real data this was found on: 264 of 269 fake template folders and 264 of 267 fake #__template_styles rows now correctly flagged, with the 5 genuinely legitimate templates (including one disabled-by-necessity core fallback) correctly left alone.
• Files inside a fake template folder were showing up in "Cleanable Files" instead of "Delete". Root cause: the folder-naming check that decides Clean-vs-Delete routing used the same narrow tmpl_xxxxxx pattern above, so a beez3_rkgf-style fake folder produced no location-based reason at all -- only a content-signature match, which routes to "review/clean" by design (that's correct for a real file with injected code, wrong for an entirely fake file with nothing legitimate to preserve). Now that the extension-registry check fires for these folders regardless of naming, affected files correctly land in Delete. Also fixed the same underlying assumption in the delete safeguard that protects a template's own root index.php from deletion -- it now checks the same registry instead of trusting that file's own folder's (fakeable) manifest, so a fake template's index.php is deletable like any other dropped file, while a real template's stays protected.

Fixed

• The #__template_styles DB scan missed the exact same "existing template name + random suffix" attack pattern that 2.4.5 fixed on the filesystem side (rows like system_jizu, core_cokx, bootstrap_base_ychp, beez3_nfbj, each titled "<name> - 默认" with empty params). The DB-side check only verified the referenced template folder existed on disk (is_dir()) — but a real mass-injection attack creates both the fake DB row and a matching folder together, so is_dir() alone never caught these. It now checks for a templateDetails.xml manifest instead, the same fix already applied to the filesystem scan: no manifest means Joomla never actually installed it as a real template, whether or not a folder happens to exist. The "Clean" action for this tab (added in 2.4.4) now recognizes these rows as deletable too, instead of skipping them for manual review.

Fixed

• 2.4.5's new "no templateDetails.xml means fake template" check false-positived on Joomla's own bundled system fallback template (templates/system/ and administrator/templates/system/ — offline.php, error.php, fatal.php, and friends, used for maintenance/error pages). This folder is core Joomla, never installed via the extension installer, so it legitimately has no manifest — unlike every other template folder. It's now explicitly exempted from the no-manifest junk check; a file inside it is still flagged normally if the actual content-signature scan finds something genuinely injected.

Fixed

• This scanner flagged its own former self as suspicious. A leftover administrator/components/com_sppbscan/ directory (this extension's name before the 2.2.0 rebrand to MuRu Guard) got no exemption from content scanning, so its helpers/sppbscan.php and models/scanner.php self-matched multiple high-confidence signatures -- unavoidable, since this scanner's own CONTENT_SIGNATURES table necessarily contains the literal marker text (xss.report, secure.local, FilesMan, ...) it's matching against, and a raw content scan of its own source finds "matches" against itself. The current-named copy only ever escaped this by coincidence, via an existing safe-path exemption for its live install path. Added the same exemption for the old com_sppbscan path.
• A real, in-the-wild mass webshell-drop pattern was completely missed, and worse, actively protected from deletion. Attackers created folders like templates/beez3_degj/, templates/cassiopeia_hhnm/, templates/responsive_jsox/ -- an existing template's own name plus a random 4-character suffix -- each containing nothing but a tiny backdoor index.php. These aren't real templates (no templateDetails.xml, nothing Joomla ever installed), but every templates/<name>/index.php was unconditionally treated as "Required — use Clean, not Delete" purely by path pattern, with no check that the folder was ever a real template at all. The existing junk-folder check also only recognized the tmpl_xxxxxx auto-generated naming style, not this "real name + random suffix" variant. Both checks now verify the folder actually has a templateDetails.xml manifest; a templates/<name>/index.php without one is flagged as a junk template folder and is now deletable like any other suspicious file, instead of being steered toward a "clean" action that never made sense for a folder with no legitimate content to preserve in the first place.

Fixed

• The scan-area picker modal's inner content (checkboxes, area labels, the Run Scan button) had no visible styling. The whole modal is moved to be a direct child of <body> at runtime so its position: fixed isn't broken by a transform-ed ancestor in Joomla's admin template — but that also takes it outside #muruguard-root, which is what Tailwind's utility classes are scoped to. The dialog chrome (backdrop, header, footer) already had a plain-CSS fallback for exactly this reason; the modal's inner content, added later, didn't. Added the missing plain CSS, scoped under #muru-scan-modal specifically so it can't leak into the rest of the Joomla admin page.
• The Template Defacement tab had no way to act on findings — every other findings tab (Files, Cleanable Files, Menu XSS, SPPB Assets) has row selection and a clean/delete action; this one was read-only, telling you to go delete rows manually via phpMyAdmin/SQL. It now has the same select-all/per-row checkboxes and a delete button as the other tabs — but only rows independently re-confirmed as junk (an orphaned template reference or an auto-generated tmpl_xxxxxx name) are actually deleted; rows flagged only for defacement text are skipped even if selected, since a text match alone isn't a reliable enough signal to safely auto-delete a row that could otherwise be legitimate.

Fixed

• The #__sppagebuilder_assets payload scan (eval(, base64_decode, xss.report, script tags, event handlers) was checking a column that doesn't exist. It read $row['asset_value'], but the real table column is assets -- asset_value was always null/empty on every real install, so this entire check has never actually inspected real row content, for any row, regardless of name. A row named exactly icofont (SP Page Builder's own legitimate default) skipped the separate name-based "non-default iconfont" check too, so in combination it had zero chance of ever being flagged no matter what it actually contained. Fixed the column name, and the payload checks now run against every row's real content unconditionally -- a "known good" name is no longer a bypass for content inspection.
• Also now checks css_path (the other attacker-controllable text field on this table) the same way, plus a new check that it only ever references an actual .css file -- a path ending in .php/.phtml/other executable extension is flagged directly, since nothing else on this table would have caught a malicious file smuggled in through that field.

Fixed

• The #__template_styles scan missed a real, active compromise pattern. It only matched classic defacement text ("Hacked by", "Owned by", ...) inside the params column. A batch of dozens of injected junk rows -- randomly named tmpl_xxxxxx, titled "<name> - 默认" ("- Default" in Chinese regardless of the site's actual language), params usually just {} -- went completely undetected, since there's no defacement text in them at all. Added a second, independent check: a row's template column is compared against the actual template folders present on disk (templates/ for the frontend, administrator/templates/ for the admin) -- a legitimate Joomla install never has a style row pointing at a template that isn't installed, so a row that does is flagged as an orphaned/injected reference. Combined with a check for the tmpl_xxxxxx auto-generated naming pattern itself for a second, corroborating signal.
• The filesystem scan had the matching blind spot on the other side of the same attack. templates/ is scanned in signature-only "code" mode (.php is expected there), so a whole templates/tmpl_xxxxxx/ folder full of dropped files went undetected as long as their content didn't happen to match a known webshell pattern -- even though the folder name itself (matching the exact junk pattern above, one-to-one with the fake database row of the same name) is a dead giveaway on its own. Added a location-based check, alongside the existing core-masquerade check, that flags anything inside a top-level templates/<name> or administrator/templates/<name> folder whose <name> matches the tmpl_xxxxxx pattern -- independent of file content, so it still catches the drop even when the payload itself doesn't match any known signature.

Changed

• Modernized the scan-area picker modal. Gradient header matching the hero, icon in a rounded badge, a pill-styled "Select all", card-style grouped sections with hover elevation, and a proper vertically-and-horizontally centered dialog (it previously only centered horizontally and sat pinned near the top of the viewport).
• Clicking Run inside that modal now closes the modal immediately before showing the scanning overlay, instead of leaving it open underneath.

Changed

• Simplified the scan-gate screen. Opening the scanner now shows just the hero (icon, title, description) and a single 🔍 Run a Scan button, instead of the full directory/checks picker sitting inline on the page. Clicking the button opens a modal with the same "🗂 Directories & checks to scan" picker (Select all + the 4 grouped sections), with its own Run button that starts the scan -- the picker itself didn't change, just where it lives.
• Settings → Protection is now the default tab, ahead of Scheduled Scanning and Setup Guide, since it's the primary place most people will want to land after installing Protection Mode.

Added

• Protection Mode: real-time attack detection and blocking. A new companion plugin, System - MuRu Guard Shield (plg_system_muruguardshield), checks every incoming request against known attack patterns -- webshell interaction, a direct probe against the SP Page Builder uploadCustomIcon RCE, known malware-drop filenames, path traversal probes, and known scanner User-Agents -- and tracks failed backend logins per IP. It ships as a separate extension because a component only runs when someone visits its own admin page; real-time, every-request protection has to live in a plugin instead.
• Settings → Protection tab. A master Protection Mode switch (log-only, zero risk of blocking real visitors when this is the only switch on), plus two independent opt-in switches to actually reject traffic: block high-confidence attack patterns (403 on a webshell/RCE/malware-filename match) and block brute-force login attempts (reject further backend logins from an IP once it crosses a configurable failed-attempt threshold and time window). All three are off by default. Already-authenticated, non-guest sessions are exempt from request-pattern blocking so a legitimate admin action can never trip a false block and lock them out of their own site -- brute-force blocking has no such exemption, since it only ever targets pre-authentication attempts.
• Protection Log, sectioned by type (Attack Pattern Matches / Brute-Force Login Attempts), showing IP address, timestamp, severity, matched rule/reason, request URI, and whether each entry was actually blocked or only logged -- the last 500 entries, newest first, with a Clear Log action. Gated behind the same Change Settings (core.admin) permission as everything else in Settings, since it's a security audit trail, not just a scan result.
• The plugin has no settings screen of its own -- it reads com_muruguard's params directly (ComponentHelper::getParams('com_muruguard')), so Protection Mode is configured entirely from this component's Settings panel. It fails open, silently, if the component isn't installed or a check throws, since a bug in a security feature that runs on every single page load must never be able to take the whole site down.

Fixed

• The Permissions tab never appeared on System → Global Configuration → MuRu Guard, no matter what access.xml declared. Confirmed by reading Joomla core's own com_config source directly: a component's Permissions tab isn't generated automatically just because access.xml exists -- each component's own config.xml has to explicitly ask for it via a <fieldset name="permissions"> containing a <field type="rules" component="com_muruguard" section="component">, the same way core components like com_cache/com_redirect do it. That fieldset was simply never added when the 4 ACL actions were introduced in 2.3.0, so access.xml alone had nothing to render into.
• The Global Configuration page title showed the raw, untranslated string com_muruguard_configuration instead of a real title -- the specific language key Joomla's com_config view requests (Text::_($component . '_configuration')) was never defined. Added COM_MURUGUARD_CONFIGURATION.

Fixed

• The Settings screen's "Scheduled Scanning" / "Setup Guide" tabs didn't switch — clicking "Setup Guide" did nothing. The tab markup and panels had been added but never wired up: there was no .muru-settings-tab.active styling and no click handler to toggle between panels, so the page just sat on whichever tab rendered first. Added the matching CSS active state (mirroring the existing results-tab styling) and a click handler that toggles the clicked tab and its matching panel, following the same active/hidden pattern already used elsewhere in the template.

Changed

• Renamed leftover sppb- CSS classes, JS functions, and PHP template helpers to muru-/muru_. These were internal naming left over from the old SPPB Scan codebase (sppb-tab, sppb-diff-block, sppbOpenCodeModal, sppb_section_open, etc.) that the 2.2.0 rebrand had missed. Left untouched anything that names the actual third-party SP Page Builder extension being scanned — sppbWarning, getSppbVersionWarning, the sppb_assets finding key, and the codex-sppb-*/codex_sppb* malware filename patterns — since those refer to the real extension, not this app's own branding.

⚠️ Breaking: SPPB Scan is rebranded to MuRu Guard

SPPB Scan is rebranded to MuRu Guard in this version. The Joomla extension element changes (com_sppbscan → com_muruguard), along with every class name, the language file, and the admin menu entry (now MuRu Guard). Joomla treats this as a different extension, not an in-place upgrade: on a site that already has the old com_sppbscan installed, uninstall it first, then install this package fresh. Scan history and settings do not carry over automatically since they live under the old element name.

Added

• Core-file checksum verification. The scanner now detects your exact installed Joomla version (from administrator/manifests/files/joomla.xml) and compares index.php, administrator/index.php, api/index.php, includes/app.php, includes/framework.php, robots.txt.dist, htaccess.txt, and web.config.txt against bundled official SHA-256 hashes for the latest patch of the 4.4 LTS, 5.x, and 6.x Joomla lines. A mismatch is byte-for-byte proof of tampering, independent of every pattern-based check — and it already caught a real gap: a backdoor appended after a file's closing ?> tag (no base64_decode, no recognizable signature) that every existing heuristic missed entirely. An unlisted Joomla version simply skips this check — never a false positive from missing coverage.
• Clean preview. In the Cleanable Files tab, the 🧬 Code Issues modal now shows a 🔍 Preview section with the exact bytes Clean would remove (and what replaces them, if anything) for any file with a recognized auto-fix pattern — computed read-only against the file's current content, never written to disk. Files with no recognized auto-fix pattern correctly show no preview button, so the UI never promises a fix that won't happen.
• Scheduled scanning via webcron, with a dedicated in-page ⚙️ Settings panel (next to the existing 💬 Support button — click it to swap the whole page for a Settings view, click "← Back to scanner" to return). From there you can flip a switch to enable/disable scheduled scanning, generate a secret token with one click, set an alert email, and copy the ready-to-use webcron URL — no trip to Global Configuration required (though System → Global Configuration → MuRu Guard still works too, and both stay in sync). Point any cron system (server crontab, host control panel, or a free external cron service) at that URL with curl/wget — no SSH, no login, no CSRF token needed. Runs the same detection as a manual scan and emails only when something new appears since the last run — never on every run, and never on the very first run (which just records a baseline). A status badge on the main dashboard shows "⏰ Scheduled scanning ON" whenever it's active, click it to jump straight into Settings.

Fixed

• Scheduled scanning was completely unreachable. Found during a self-directed security review of this component: the admin entry point required a logged-in Super User session for every task, including the new webcron endpoint — so a real cron/curl request (which has no Joomla session) was rejected before its own secret-token check ever ran. The entry point now exempts only that one task from the blanket session check; every other action is gated exactly as before.
• The scheduled-scan history (used to compute "what's new since last run") was being stored inside this component's own config params — the exact same storage System → Global Configuration saves to. Saving Global Configuration for any reason would have silently wiped that history with no warning, since Joomla's config save replaces the whole params blob with just the declared fields. It now lives in its own small file instead, immune to that entirely.

Removed

• The "pair this with ClamAV/Imunify360" and "uninstall when you're done" footer notices, from both the scanner page and this README — noise, not signal.

Fixed

• A legitimate, actively-used component/module/plugin/library/template file with a backdoor snippet injected into it could land in the "Suspicious Files" tab with only a Delete option. That's a real, needed file with malicious content added, not a foreign dropped file — deleting it would break the site. Findings inside real code directories that are flagged only by a content-signature match (no filename/location red flag alongside it) are now routed to the "Cleanable Files" tab instead, where the safe outcome is either an auto-clean or a clear "no pattern recognized, review manually" message — never an outright delete.

Changed

• Rewrote <head> script-injection detection and repair to share a single implementation based on plain string search instead of two independently-maintained regexes, so the two can never silently disagree on the same file.
• The Clean code result message now uses the right severity color (red for failures/warnings, yellow for skips, green for success) instead of always rendering as flat blue info text.

Fixed

• Clean code could silently do nothing on a read-only file. Added an explicit writability check before attempting a repair, with a clear message pointing at file ownership/permissions — the most common real-world reason a "successful" clean doesn't actually stick on shared hosting.
• Clean code now verifies its own write. After writing the repaired file, it's re-read from disk and re-checked; if the infection pattern is somehow still present (a cache, a file-integrity/restore tool, or anything else reverting the change), you now get an explicit warning instead of a false "CLEANED" result.

Added

• "AI Integration — coming soon" preview button in the re-scan bar.

Changed

• Removed the redundant Clean code button from the Suspicious Files tab — cleaning now lives exclusively in the Cleanable Files tab, so each tab has exactly one clear action (Delete vs. Clean).
• Added a shared SppbscanHelper::isProtectedEntryPath() helper and switched both the model's deleteTargets() and the results-table row renderer to use it, removing a duplicated (and slightly drifting) inline check.

Fixed

• Suspicious Files tab no longer lists files it can't actually delete. Auto-cleanable files and required core/template entry files (index.php, administrator/index.php, a template's own root index.php, ...) were still showing up in the Suspicious Files list even though Delete would just skip them — they now appear only in the Cleanable Files tab. Every finding still lands in exactly one of the two tabs; nothing is dropped.
• "Select all" did nothing in the Cleanable Files tab. The tab's <section> wrapper never actually had the id="sec-cleanable" attribute the checkbox handler was targeting (only a data-panel attribute) — every sppb_section_open() panel now gets a real id.

Fixed and Improved

• Add file content preview snippets to suspicious file findings to display matched code in the admin UI.
• Introduce a new Cleanable Files tab in the scanner view that lists files with safely auto-repairable infections (code prepended before Joomla's bootstrap or head tag injections).
• Add helper functions for detecting cleanable patterns and rendering shared file rows across tabs to reduce code duplication.
• Refactor existing file listing UI code to use the shared render function.
• Update the checkCoreMasquerade helper to accept an absolute path parameter and append preview text to findings.
• Bump the package version from 2.1.7 to 2.1.8.

Fixed

• False positives on genuine Joomla core files: libraries/cms.php, libraries/web.config, cli/web.config, bin/web.config, and templates/system/fatal.php were flagged as core-path disguises because the loose-file allowlist backing that check was incomplete.
• False positive on .phpstorm.meta.php (and similar IDE-metadata files) shipped inside third-party libraries/vendor/* packages — the "hidden dot-file with an executable extension" check didn't distinguish these well-known benign convention files from an attacker-planted hidden file.

Added

• Directory-selection picker before scanning. Choose which areas to scan (upload/media directories, extension & template code, core & webroot, database) instead of always scanning everything.
• Core-file masquerade detection. Flags files whose path impersonates legitimate Joomla core (libraries/system.php, bin/cms.php, cli/cli.php, templates/*/network.php, hidden dot-files with executable extensions, unexpected loose files in libraries//cli/bin) even when the content itself looks harmless — a common real-world disguise technique.
• Stray/masquerade index.php detection. Any index.php outside a template's own root is expected to be Joomla's blank access-guard stub; non-stub content is now flagged. A known real-world artifact — a features/index.php planted in a template that has no such folder — is flagged unconditionally on location alone, regardless of content, since attackers can trivially fake a blank stub.
• Auto-clean for infected core/template entry files. index.php (root), administrator/index.php, api/index.php, includes/app.php, and any template's own root index.php are now protected from deletion and instead get a surgical Clean code action that strips a prepended payload (code injected before Joomla's bootstrap/access guard) while leaving 100% of the legitimate file untouched. A timestamped .bak backup is written before every repair. The same prepended-payload detection now also runs against any Joomla PHP file (core libraries, extensions), not just the four named entry points.
• Code-analysis modal. Suspicious file rows now show a short summary + a "🧬 Code Issues" button that opens a modal with the exact matched code for every triggered signature, plus a plain-language explanation of why it matched — instead of a wall of text crammed into a table cell.
• Copy-path button and a breadcrumb-styled path column (muted directory / bold filename) in the Suspicious Files table.
• Tabbed results UI replacing the old stacked-accordion layout.

Changed

• Content-signature detections are now severity-tiered per signature instead of "any match = High confidence." Patterns with a plausible legitimate explanation (e.g. a dev-config file mentioning secure.local, a legitimate extension using a zip:///phar:// stream wrapper) are now Medium ("needs manual review") instead of automatically High, so a real webshell isn't diluted next to false alarms.
• Reworked the whole admin UI: Tailwind is now scoped to the component root and preflight is disabled, so it no longer resets styling on the rest of the Joomla admin page (sidebar, post-install messages, dashboard widgets). The scan-progress overlay and floating support widget are re-parented to <body> at runtime to fix positioning broken by Joomla's own transformed sidebar-animation wrapper.

Fixed

• False positives on large legitimate photos. The <?= short-tag polyglot check previously scanned the entire binary content of image files — in megabytes of high-entropy JPEG/PNG data that 3-byte sequence turns up by pure chance. Signature scanning on images is now windowed to the first/last few KB (matching how real polyglot payloads are actually planted — prepended or appended, never buried mid-stream), and the short tag must be followed by a plausible PHP token.
• False positives on real images with mismatched-format bytes (e.g. a .jpg that's actually WebP data from an image optimizer). Image integrity checking now trusts getimagesize()'s actual format sniff as ground truth instead of a strict per-extension magic-byte match.

Added

• Code analysis modal and copy buttons for scan results.

Added

• Improved malware detection signatures and reporting.

Added

• Detection for stray index.php files outside expected locations.

Fixed

• False positives in image scans.

Added

• Image scanning, UI, and styling fixes.