Joomla Backend nicht erreichbar. Website zeigt eine 500 Page

    Joomla Version
    kann ich nicht einsehen und weiß ich nicht genau
    PHP Version
    Unbekannt
    Hoster
    Lokal
    Link (URL) zur Seite mit dem Problem
    https://petrihaus-frankfurt.de/administrator/index.php

    :!:Hallo Zusammen,

    unsere Website zeigt aktuell eine 500 Seite (https://www.petrihaus-frankfurt.de) und ich komme auch nicht mehr ins Backend rein. Die Seite sagt mir: "Forbidden. You don't have permission to access this resource."

    Ich kann absolut nichts mehr machen und brauche dringend Hilfe.

    Liebe Grüße,

    Yasina:!:

    Du benutzt das Astroid Framework und deine Seite wurde mit grosser Wahrscheinlichkeit gehackt.

    Thema

    Astroid Framework Angriffswelle

    SICHERHEITSWARNUNG – Nutzer von Astroid Framework: Schaltet eure Websites JETZT mithilfe einer .htaccess-Datei oder einer anderen Schutzmaßnahme auf Serverebene ab.

    Derzeit gibt es eine Angriffswelle, die auf Websites mit Astroid Framework abzielt. Der Angriff installiert eine Hintertür, ein System-Plugin namens plg_system_blpayload. Wenn ihr dieses Plugin auf eurer Website findet, wurde diehre Website gehackt und ihr müsst eine saubere Sicherung wiederherstellen, die aus der Zeit vor der…
    SniperSister
    4. März 2026 um 17:35

    Hi,

    sieht leider wirklich stark nach dem aktuellen Astroid-Thema aus…

    Ich hatte vor kurzem etwas sehr Ähnliches, plötzlich 500er + kein Backend mehr erreichbar. In meinem Fall war die Seite auch kompromittiert.

    Ich würde an deiner Stelle als erstes:

    beim Hoster nachfragen, ob sie die Seite gesperrt haben
    Mails checken (Spam-Ordner auch)
    und dann schauen, ob du ein sauberes Backup hast

    Alles andere bringt meistens nicht viel, wenn da wirklich was eingeschleust wurde.

    Ist echt ärgerlich, aber leider passiert das im Moment öfter 😕

    Ich meinte die aktuellen Fälle rund ums Astroid Framework.

    Also Seiten, die plötzlich 500er werfen oder wo das Backend nicht mehr erreichbar ist, weil irgendwas eingeschleust wurde. Das scheint sich in letzter Zeit etwas zu häufen.

    Hatte ich selbst so ähnlich und hab’s auch schon ein paar Mal im Forum gesehen.

    Ich bin ja auch schon ein paar Jahre dabei, aber an eine solche Situation, dass zahlreiche Websites durch eine Sicherheitslücke in einer Joomla-Erweiterung gehackt worden sind (wie in diesem Fall das Astroid-Framework), kann ich mich nicht erinnern.

    Trotzdem hätte man dies auch verhindern können, indem man das Backend per .htaccess (und MFA) vernagelt. Wer also jetzt allzu laut schreit, hat vielleicht nicht alle sinnvollen und einfachen Sicherheitsmaßnahmen durchgeführt.

    500er-Fehler passieren häufiger, sind aber meist die Folge suboptimal durchgeführter Updates auf eine neue Joomla-Hauptversion, bei der die eine oder andere Erweiterung nicht mitspielt.

    Freundliche Grüße aus Wächtersbach, Rolf Dautrich

    Ja, da hast du schon recht.

    Ich wollte das auch gar nicht dramatisieren, sondern eher sagen, dass es aktuell einfach auffällig ist, wie oft solche Fälle gerade im Zusammenhang mit Astroid auftauchen.

    Klar, viele Dinge hätte man mit zusätzlichen Maßnahmen wie .htaccess oder MFA besser absichern können, da gebe ich dir völlig recht. Im Nachhinein ist man da ja immer schlauer.

    Die 500er selbst sind natürlich nichts Neues, aber in Kombination mit nicht mehr erreichbarem Backend wirkt es im Moment schon etwas „gehäuft“, zumindest aus meiner Wahrnehmung.

    Zitat von Rolf Dautrich

    Ich bin ja auch schon ein paar Jahre dabei, aber an eine solche Situation, dass zahlreiche Websites durch eine Sicherheitslücke in einer Joomla-Erweiterung gehackt worden sind (wie in diesem Fall das Astroid-Framework), kann ich mich nicht erinnern.

    Ich auch nicht.

    Zitat von Rolf Dautrich

    Trotzdem hätte man dies auch verhindern können, indem man das Backend per .htaccess (und MFA) vernagelt. Wer also jetzt allzu laut schreit, hat vielleicht nicht alle sinnvollen und einfachen Sicherheitsmaßnahmen durchgeführt.

    Das stimmt. Die Herkunft des Sicherheitsproblems, das aus dem Astroid Framework stammt, sollte jedoch nicht auf den Benutzer übertragen werden.

    Die Erstellung einer .htaccess-Datei für das Backend wurde zwar empfohlen, stellte jedoch keine zwingende Notwendigkeit dar.

    Oh Mann, ich denke dass zu dem Thema jetzt wirklich mehr als genug geschrieben wurde.

    Es gab in der Vergangenheit nie Sicherheitslücken in Joomla?

    Wenn es eine Sicherheitslücke gibt, wird schnell reagiert und ein Update bereitgestellt. Wenn man dann in sein Backend schaut, wird es dort auch angezeigt. Die Naivität oder Gleichgültigkeit, mit der dann User gesegnet sind und diese Updates nicht installieren oder gar nicht in Ihr Backend schauen, ist doch das weitaus größere Problem?

    Wer sich nicht um seine Seiten kümmern will oder kann bzw. keine Ahnung hat, der sollte einen HP-Baukasten verwenden oder einen Dienstleister beauftragen!

    Man kann auch "Scheduled Tasks" ("Geplante Aufgaben") benutzen. Mitgeliefert wird die Task, die nach Updates für Joomla schaut. Für Erweiterungen gibt es ebenfalls eine Task im JED von Tobias Zulauf.

    Dann bekommt man bei anstehenden Updates eine E-Mail und braucht erst dann sein Backend zu öffnen, um die Updates vorzunehmen.

    Für die Geplanten Aufgaben sollte man sich nicht auf das "Lazy Scheduling" verlassen, sondern einen Webcron einrichten; ich nutze dafür diesen Dienst.

    Freundliche Grüße aus Wächtersbach, Rolf Dautrich

    Ich hatte heute früh um 03:27 gemailt.

    Welchen Timestamp hat denn die Datei
    https://petrihaus-frankfurt.de/plugins/system…d/blpayload.xml wenn du mal per FTP Verbindung schaust?

    Im /www_logs Verzeichnis auf dem Webspace sollten sich bei Evanzo auch Access Logs befinden, die du durch die KI schieben kannst, um den Angriffszeitpunkt zu bestimmen - vorausgesetzt die reichen ausreichend lange zurück.

    Zitat von tommynatar

    und dann schauen, ob du ein sauberes Backup hast

    Sonst einfach ein Backup um Mitte Februar nehmen - da gab es nach aktuellem Infostand noch keine Astroid Angriffe.

    Da deine Website mit Sicherheit gehackt ist siehe auch:

    Die Website wurde wohl spätestens am 3.3.26 gehackt laut <creationDate> der blpayload.xml

    Das ist mir auch klar. Wollte dies Datum nur festhalten und feststellen das alle Backups dieser Website spätestens ab dem 3.3.26 mit hoher Wahrscheinlichkeit verseucht sind.

    Web-Server-Logs zu untersuchen um den Angriffszeitpunkt zu bestimmen ist natürlich besser.