Beiträge von Re:Later

    Trotzdem rätselhaft die Fehlermeldung "Attempt to assign property "logoutLink" on array". Wenn man in den Code schaut, wird aus der #__session ein Array aus gefilterten Objekten ausgelesen.

    joomla-cms/administrator/modules/mod_logged/src/Helper/LoggedHelper.php at 6.1.0 · joomla/joomla-cms
    Home of the Joomla! Content Management System. Contribute to joomla/joomla-cms development by creating an account on GitHub.
    github.com

    Warum nun laut Fehlermeldung im folgenden foreach das $result ein Array sein soll??? Wie gesagt, sollte ja ein Objekt sein

    Unabhängig vom Dienstleister. Wenn ein Joomla-Kunde das wirklich will, also bestätigt, dass er das will, würde ich jedenfalls Benutzeraktivitäten von Joomla protokollieren lassen (und nicht zu oft löschen lassen), sowie eigenen FTP-Zugang und Zeugs. Diverse Backups lokal aufheben bzw. Dienstleister auffordern vor und nach Arbeit Backups anzustoßen...

    Nur so: auf o.g. Webseite marktunikat ist wohl ein Tippfehler:

    Wenn du einen Cookiewarner wie deinen verwendest, schreibt der notwendigerweise mndestens 1 Cookie selber, um die Entsheidung des Besuchers zu speichern. Das ist legitim.

    Nebenbei: Momentan kann ich mich im Warner entscheiden wie ich will. Er geht nicht weg. Kann aber auch an meinem Browser liegen, in dem JavaScript verboten ist..

    Weiters schreibt Joomla selbst ein Cookie, das aber auch legitim ist, da es ein sog. Session-Cookie ist.

    Weiter habe ich aber nicht geschaut.

    Welche Cookies warnen denn deine Checker eigentlich an?

    Hier eine Übersicht der betroffenen Erweiterungen (Das Framework nutzen ja mehrere Erweiterungen).

    Security Update: Tassos Framework Patch Released
    On January 7th, 2026, an independent security researcher, p1r0x, working with SSD Secure Disclosure, responsibly reported a vulnerability in the Tasso
    www.tassos.gr

    Hier das "CVE-2026-21627 - Extension - tassos.gr - SQL injection and Unauthenticated File Read in Novarain/Tassos Framework v4.10.14 – v6.0.37 for Joomla":

    CVE-2026-21627 - Vulnerability Details - OpenCVE

    Auch hier ist die joomlaeigene Komponente com_ajax involviert. Wenn man die als Entwickler nutzt, muss man eben auch prüfen, dass der Nutzende die entsprechenden Nutzerrechte hat.

    Grundlegend ja, denke ich mir manchml auch.

    Aber das Laden dieser Datei ist halt abhängig, ob sie existiert, nicht, ob überhaupt was drinnen steht. Früher gab es da noch eine Abfrage, ob leer. Heute nicht mehr.

    Oder kurz: Das Laden unnötiger Dateien, auch leerer, geht halt auf die Performance. Ebenso eine Abfrage, ob was drinnen steht.

    man kann es runterladen?

    Ohne Garntie von meinereiner wohl hier in einer Freeversion: https://smartslider3.com/free-joomla-slider/

    Eine der Lücken betrifft wohl auch den Revolution Slider, den es aber für Joomla schon lange nicht mehr gibt, aber seinerzeit vielen Kauftemplates beigepackt war in letztlich kostenpflichtiger Version, wenn man dann updaten musste. Bei SmartSlider weiß ich aber nicht, ob der auch als Groschangrab so eifrig beigepackt wird.

    Eh alles aufgeblasenes, unnötiges, performancefressendes Kokolores-Zeugs.

    es sei denn, ich habe es übersehen, dass es auf dieser Erweiterungsseite keinen Hinweis darauf gib

    Man muss sich halt ewig durch die protzerische EIgenWerbung auf deren Seiten quälen, um dann irgendwo einen Nebensatz zu finden.

    Du musst nichts selbst erstellen. Das bietet dein Hoster im KA bereits an

    Und v.a. wird bei All-Inkl ein traditioneller Verzeichnisschutz eingerichtet (gut für alte Säcke wie mich), der die .htaccess NICHT zerstört, wie bai manchem anderen Provider. die Joomla-htaccess, die schon vorhanden ist oder auch nicht, wird lediglich ganz am Ende um paar Zeilen mit korrekten Pfadangabe erweitert und eine zugehörige .passwd-Datei angelegt.

    Wenn ich das richtig sehe, will redirect im Adminstrator Verzeichnis auf eine index.php zugreifen und nicht auf das Bild selbst.

    Das verwechselst du wohl mit der Spalte "Bezugnehmende Seite". Das ist die Seite die du aufrufst und die will dann das Bild laden, das aber nicht aufrufbar ist. Bei einem weiteren Versuch wird es aber dann gefunden (weil du es ja dann siehst im Backend, wenn ich recht verstehe). Will sagen: Das index.php ist schon richtig und du solltest keinesfalls in der htaccess diesbzüglich irgendwas ändern..

    Vielleicht liege ich auch falsch mit dem Verzeichnisschutz als unmittelbare Ursache.

    Ich kenne das nur von Firefox, der mich im Backend immer wieder und noch mal, dann wieder nicht, nach dem Verzeichnis-Passwort fragt, obwohl ich es ja längst beim Einstieg ins Backend oder Frontend (manche sind halt komplett geschützt) eingegeben habe.

    Jedenfalls würde ich auch im JCE mal die eingestellten Pfade prüfen. Das macht man im verwendeten JCE-Profil. Eigentlich stellt man da auch nix ein und JCE verwendet den Joomla-Standard-Pfad für die Bilder.

    Die versuchen es zwar weiterhin, aber ist ja jetzt alles zu:

    WOher willst du das wissen?

    Nur um das noch mal klar zu machen. SObald die Lücke 1x ausgenutzt wurde, hilft es in den meisten Fällen gar nichts mehr sich auf einen Backend-htaccess-Schutz zu verlassen. Warum: Weil längst neue Backdoors angelegt wurden, die sonstwo und einfach erreichbar im Space herumliegen und weitere Backdoors anlegen, die die ehemalige Lücke nicht brauchen. Quasi Lawine. Siehste ja selber. Und das Vertrauen in Scanner, welcher Art auch immer, ist vielleicht eine kleine, zusätzliche Hilfe bei der Bereinigung, aber niemals ausreichend, um alles loszuwerden. Weil hochgeladene Schadcodes so mannigfaltig sein können oder längst in der DB ... usw. usf.

    Mich persönlich würde allein der Teil der Meldung

    Table '_users' doesn't exist 

    so sehr beunruhigen, dass ich die Seite erst mal radikal mit einem htacces-Verzeichnisschutz komplett sperren würde.

    Dann sehe ich, dass du bzw. das Template das Astroid-Framework verwendet. Kommt jetzt auf die Astroid-Version an, ob du vermutlich gehackt wurdest, was wohl seit Februar2026 passiert sein könnte. Man bemerkt ja das nicht immer sofort.

    Ich täte erst mal davon ausgehen.

    Siehe auch hier: Astroid Framework Angriffswelle

    Ich täte aber sagen, dass die Seite so kaputtgehackt wurde, dass ich gar nichts anfangen würde, außer alt genuges Backup hinter einem htaccess-Verzeichnisschutz! einzuspielen mit zuvor bereingtem Webspace und neuer Datenbank hinter einem htaccess-Verzeichnisschutz!! Neue Passwörter!!!! Dann Seite erst wieder öffnen.

    Eine Bereinigung ist, noch mehr, wenn schon die Datenbank betroffen ist, für Laien kaum möglich, aber auch "Könner" würden wohl mehrere Tage brauchen, wenn sie das gründlich machen. Entsprechend teuer ist das dann.

    Mein Editor blinkt ständig und ich kann einfach keinen einzigen Inhalt schreiben.

    Blinken tut er vermutlich, weil du Firefox verwendest(?) Wechsle für kurze Zeit den Browser. Dieser Bug wird mit einem Joomla-Update gefixt, das du viell. noch nicht eingespielt hast. Gibt auch irgendwo hier im Forum einen Hinweis für einen "schnellen Fix", den man installieren kann.

    Meine Frage wäre, ob Ihr denn Benutzeraktivitäten protokolliert. Menü>Benutzer>Benutzeraktivitäten (zumindest früher). UND, ob ihr denn die AKtivitäten der RegularLabs-Erweiterungen unbedingt auch protokollieren wollt/müsst.

    Zumindest würde ich testweise die zugehörigen Plugins mal deaktivieren. Gibt vielleicht weitere. Siehe Bild

    Gibt vielleicht noch weitere zu actionlog und Regular Labs.

    Jedenfalls solltet ihr das bei Regularalabs mit ANgabe Joomla- und PHP-Version sowie die Fehlerliste melden. Weil das Problem tiefer sitzt.

    Leider weiß ich nicht wo auf deren Webseite. Ich glaube, ich hab das immer über die normale email gemacht.