Wehrt bekannte Joomla-Angriffe (JCE, Novarain/Tassos, Astroid, com_ajax-LFI ...) und generische Angriffsklassen ab – zweischichtig aus einer Signaturliste: die .htaccess blockt GET-Angriffe schon vor PHP, die Echtzeit-Firewall fängt zusätzlich POST-Angriffe und nutzt neue Signaturen sofort. Dieser Schalter steuert beide.
Ein/Aus steht oben unter „Wichtigste Einstellungen“. Hier die Feinheiten:
Schnittstelle /api (Joomla 4+) durchleiten (normal, wenn die API genutzt wird) komplett sperren (empfohlen, wenn ungenutzt) nichts tun
Eine komplette /api-Sperre hätte den Joomla-Core-Leak CVE-2023-23752 (Auslesen der Konfiguration inkl. Datenbank-Zugangsdaten) von vornherein verhindert. Nur sperren, wenn keine Erweiterung die Joomla-Web-Services nutzt.
Signaturen einzeln verwalten (17) JCE Profil-Import (CVE-2026-48907) alle (auch eingeloggt) Unauthentifizierter Profil-Import im JCE-Editor - Beginn der aktuellen RCE-Kette (schaltet PHP-Uploads frei). Kein legitimer Frontend-Aufruf. JCE Webshell-Upload via plugin.rpc (CVE-2026-48907) nur Gäste Datei-Upload über den JCE-Dateibrowser (plugin.rpc, method=upload). Greift nur im Frontend; eingeloggte Autoren (legitimer Editor-Upload) bleiben unberührt. JCE Image Manager (Alt-Exploit) nur Gäste Klassischer unauthentifizierter Datei-Upload über den JCE-Bildmanager (sehr alte JCE-Versionen). Novarain / Tassos Framework (com_ajax include) alle (auch eingeloggt) CVE-2026-21627: unauthentifizierte PHP-Datei-Einbindung über plg_system_nrframework via com_ajax (task=include). Astroid Framework (AJAX-Endpunkt) alle (auch eingeloggt) CVE-2026-21628: ungeprüfter Astroid-AJAX-Endpunkt (Upload/Installation). Coarse-Match auf com_ajax + astroid. Helix3 (JoomShaper): unauth. com_ajax-Handler (Datei schreiben/löschen) nur Gäste Helix3 < 3.1.1: der Ajax-Handler onAjaxHelix3 prüfte weder Login noch Rechte. Trifft gezielt die gefährlichen Unauth-Aktionen im POST-Body: save (Layout-JSON ins aktive Template schreiben), remove (Datei löschen via Path-Traversal), import (Template-Style-Settings überschreiben) sowie upload_image/remove_image/updateFonts. Legitime Gast-Aktionen (voting, load) und eingeloggte Template-Nutzung bleiben unberührt. Fix: Helix3 3.1.1. Helix3 (JoomShaper): unauth. com_ajax-Dispatcher (Datei-Write/Delete, Style-Injektion) nur Gäste Helix3 < 3.1.1: der Front-Dispatcher (option=com_ajax mit plugin=helix3) rief onAjaxHelix3 VOR jeder Token-/Rechteprüfung auf - unauthentifiziert save/import/remove/resetLayout/updateFonts/fontVariants (Datei-Schreiben, Path-Traversal-Löschen, Template-Style-Injektion, Stored XSS). Blockt jeden GAST-Aufruf dieses Dispatchers im Frontend (Defense-in-Depth, fängt auch laufende Scans) - ergänzt die aktionsgenaue Signatur helix3-ajax um den bloßen Dispatcher-Zugriff. Eingeloggtes Template-Editing läuft im Backend hinter Auth und ist NICHT betroffen; guest-scope + waf_only. Fix: Helix3 3.1.1 (29.06.2026). NICHT mit Helix Ultimate verwechseln - eigenes Produkt, eigene Signatur helixultimate-comajax. Helix Ultimate (JoomShaper): unauth. com_ajax-Dispatcher (Menü-Write/Datei/Export) nur Gäste Helix Ultimate < 2.2.7: der com_ajax-Handler onAjaxHelixultimate (option=com_ajax mit plugin=helixultimate, Action im task-Param) lief VOR jeder Login-/Rechteprüfung - ein anonymer Angreifer konnte in die Menü-Einstellungen schreiben (Stored XSS bis in die Admin-Sitzung), Dateien per Path-Traversal beliebig löschen, einen Open Redirect auslösen und das Template ungeschützt exportieren. Blockt jeden GAST-Aufruf dieses Dispatchers im Frontend; eingeloggtes Template-/Menü-Editing läuft hinter Auth und ist NICHT betroffen (guest-scope + waf_only, FP-frei). Fix: Helix Ultimate 2.2.7 (07.07.2026). Eigenes Produkt - NICHT Helix3. com_ajax: Datei-Einbindung (generisch) alle (auch eingeloggt) Fängt unbekannte LFI-Lücken derselben Klasse ab: com_ajax mit task=include/require. Frontend. SP Page Builder: unauthentifizierter Icon-Upload (RCE) nur Gäste Zero-Day in SP Page Builder bis 6.6.1: der asset-Controller (task=asset.uploadCustomIcon) hatte keinerlei Zugriffs-/Login-Prüfung - unauthentifizierter Datei-Upload nach /media/com_sppagebuilder/assets/iconfont/ - RCE. Nur Mini-WAF (Gäste), da eingeloggte Builder den Endpunkt legitim nutzen. AcyMailing: unauth. SQL-Injection (Entity-Select Spaltenliste) nur Gäste CVE-2026-56292 (AcyMailing 6.0.0-10.11.0): der Frontend-Endpunkt EntitySelectController::loadEntityFront (option=com_acym, task=loadEntityFront) nahm die Request-Parameter columns/join_table ungeprueft in die SELECT-Spaltenliste von UserClass::getMatchingElements auf - ein anonymer Besucher konnte per Subquery beliebige DB-Tabellen (inkl. Passwort-Hashes) auslesen. Blockt GAST-Aufrufe dieses Tasks, deren columns/join_table/join-Wert ein Injektionszeichen (Klammer oder Leerzeichen) enthaelt - legitime Werte sind reine Spaltennamen (email,name,id ...) und enthalten das nie. Eingeloggte Backend-Nutzung laeuft hinter Auth (guest-scope) und ist NICHT betroffen. Fix: AcyMailing 10.11.1 (09.07.2026). Greift GET-seitig (Scanner/Massen-Exploits); vollstaendiger Schutz nur mit Update. Pfad-Klettern (kodierte Varianten) alle (auch eingeloggt) Ergänzt den Standard-Filter um Umgehungstricks: ....// , doppelte Kodierung (%252e), %c0%ae, %2e%2e%5c. PHP-Stream-Wrapper im Pfad alle (auch eingeloggt) Blockiert php:// , phar:// , data:// , expect:// u. a. direkt im angefragten Pfad. Joomla-API Konfigurations-Leak alle (auch eingeloggt) CVE-2023-23752: schützt den Endpunkt /api/.../v1/config/application auch ohne komplette API-Sperre. PHP Object Injection (serialisierte Payload) alle (auch eingeloggt) Serialisiertes PHP-Objekt in einem Parameter (O:/C:<Länge>:) - typischer Einstieg für Object-Injection/POP-Ketten. Kommt in normalen Anfragen nicht vor. PHP-Stream-Wrapper in Parameter alle (auch eingeloggt) php:// , phar:// , data:// u. a. als Parameterwert - LFI/RCE-Vektor. Ergänzt die Pfad-Variante (php-wrapper-uri). Pfad-Klettern im Parameter alle (auch eingeloggt) Mehrfaches ../ als Parameterwert - generisches Directory-Traversal/LFI in beliebigen Komponenten. Die Echtzeit-WAF blockt „alle“ -Muster auch für eingeloggte/neu registrierte Nutzer (kein legitimer Aufruf existiert); „nur Gäste“ -Muster könnten legitim genutzt werden und betreffen daher nur nicht eingeloggte Besucher. Super-User werden nie blockiert. Query-String-Signaturen lassen sich im Pfad-Test nicht simulieren, pfad-basierte schon.