Beiträge aus dem Joomla! Supportforum

Joomla 6.2.0
Astroid 3.5.3
Template: tp_schule 2.7 von Joomlaplates / Cassiopeia_extended / atum
PHP 8.4.27

Hallo, ihr Helfer!
Nach dem Update von Joomla 5.4.10 auf 6.2.0 inkl. Sprachdatei wurden mir 18 Overrides zur Prüfung angezeigt. (14 beim Template tp_schule und 4 beim Admin-Template atum)
Normalerweise hake ich die als geprüft ab, da ich keine eigenen Overrides angelegt habe.
Wenn ich jedoch den Link in System > Site Templates > TP_schule / Cassiopeia oder atum anklicke, kommt folgende Fehlermeldung:

Es ist ein Fehler aufgetreten.

[…]

Zurück zum Dashboard


Alle übrigen Backend-Funktionen funktionieren einwandfrei, auch die Frontendanzeige ist ok.

System > Debug und Server > Fehler berichten > Maximum: Beides ist aktuell eingeschaltet, falls jemand schauen möchte.

Ich kann damit leider wenig anfangen, es sieht alles ruhig und friedlich aus.

Gibt es Erkenntnisse dazu?

Habt ihr Tipps / Hinweise für mich?

MfG
Ute

Hallo,

habe die Hoffnung hier Hilfe zu finden.

Problem:

Backend (Administrator) ist nicht mehr erreichbar.

Erhalte den Fehler: HTTP 500 Whoops, looks like something went wrong.

Frontend ist erreichbar und Funktioniert, Datenbank ist erreichbar, FTP ist erreichbar.



Aktiv sind die Standard-Templates (Atum, Cassiopeia) ohne Anpassungen. (keine Drittanbieter Templates installiert)

In der configuration.php habe ich den Debugger aktiviert. (public $debug = true;)

und erhalte folgenden Bericht (siehe Anhang)



Eingrenzung des Zeitraums: Problem tritt nach/seit dem PHP-Fix (php2shell) auf. Habe allerdings beim gleichen Hoster eine weitere Joomla-Webseite mit gleichem Versionsstand und dort erreiche ich das Backend. Dass die Seiten auf verschiedenen Maschinen laufen könnten ist mir durchaus klar.

Siehe:

https://www.phoca.cz/news/1532-phoc…ecurity-release



Freundliche Grüße,

Benno

Mit der neuen Version 5.2.0 der Komponente Weblinks wurde neu auch ein Plugin zum Checken der Weblinks eingeführt. Eingestellte Aufgabenparameter: HTTP Timeout (seconds): 60 (Voreinstellung Plugin=8) / Batch Size: 5 (Voreinstellung Plugin=3). Die geplante Aufgabe gibt regelmässig den Exit-Code 123 (benötigt mehr Zeit) zurück. Auffällig ist im Protokoll, dass die Prüfung jeweils nach 1-5 Sekunden abgebrochen wurde.

(Quelltext, 31 Zeilen)

In den letzten 24 Stunden ist die Prüfung 4x erfolgreich abgelaufen. Das Plugin versendet aber nicht wie vorgesehen eine E-Mail mit dem Resultat der Überprüfung.

Kann jemand dieses Problem bestätigen?

Nach den Updates der PHP-Versionen geht bei den Hostern Strato und IONOS die Kalender-Ansicht des DPCalendars nicht mehr.

Dieses Problem tritt wohl nur bei diesen Hostern auf, bei Allinkl z.B. ist es nicht reproduzierbar und Allon Moritz konnte es bei sich und seiner Umgebung auch nicht nachvollziehen.

Mittlerweile gibt es einen Beta-Patch und der wird in der nächsten Version enthalten sein.
(damit der Patch wirkt, muss Browser-seitig der Cache gelöscht werden, z.B. mit Umschalt-F5)

Die Nachfolgenden Fragen im Zitat:

[…]

wurden gestellt im zwischenzeitlich geschloßenen Ursprungsthread:

Kritische PHP-Lücken - Patch in Kürze

Da ich finde das man derlei Fragen auch beantworten sollte, habe ich nun diesen Thread hierzu erstellt.

Leicht vereinfachte Antwort:

Nein.

Die Kritischen Lücken befanden sich in PHP das sich auf dem Webhoster-Website-Server befindet.

Da es sich bei PHP um eine Art von Betriebssystem-Erweiterung des Webhoster-Website-Server-Betriebssystems handelt,

die es ermöglicht das man PHP-Programme(Software bzw. PHP-Scripte) wie z.B. Joomla nutzen kann,

ist es bei derartigen kritischen Lücken in PHP normalerweise nicht erforderlich das zusätzlich diesbezüglich auch

Sicherheitsupdates für Joomla oder Joomla-Erweiterungen erstellt und durchgeführt werden müßen.

Trotzdem mußt du natürlich Joomla und die Joomla-Erweiterungen auch zukünftig auf dem neuesten Stand halten um möglichst keine Sicherheitslücken zu haben...



Nachfolgendes Beispiel ist dir beim besseren Verständis…

Yootheme veröffentlicht morgen um 16 Uhr deutscher Zeit ein kritisches Security Update für Yootheme 5. Seitenbetreiber mit Yootheme im Einsatz sollten das Update unbedingt binnen kürzester Zeit einspielen, ich erwarte leider eine signifkante Angriffswelle.

Ich habe verschiedene Menüeinträge erstellt, die ein Schlagwort aus den Beiträgen nutzen um Bauberichte verschiedener Flug-Modelle zusammenzufassen.

Also wird beispielsweise ein Schlagwort "ASH26" verwendet, um dann alle Beiträge mit diesem Schlagwort in einem Menüeintrag aufzulisten.

Diese werden nun offenbar alphabetisch gemäß des Beitragstitel aufgelistet.

Ist hier eine chronologische Sortierung der Ergebnisse anhand des Erstellungsdatum mit Bordmitteln möglich, um z.b. den ältesten Beitrag oben zu haben, den Neuesten unten?

In den Optionen des Menüeintrages hab ich kein Sortierkriterium gefunden. Kann aber auch sein, das das anders heißt oder ich es übersehen hab.

Nach dem Update auf Joomla-Version 6.2.0 tritt beim Aufruf eines JEvents-Formulars für Benutzer ohne Weblink-Erstellrechte folgender Fehler auf:

Joomla\Plugin\EditorsXtd\Weblink\Extension\Weblink::onDisplay(): Return value must be of type ?object, none returned

Ursache scheint zu sein, dass plugins/editors-xtd/weblink/src/Extension/Weblink.php in der Methode onDisplay() keinen Wert zurückgibt, wenn der Benutzer keine com_weblinks-Rechte besitzt.

In einer älteren Version existierte am Ende der Methode:

return null;

Das Problem lässt sich reproduzieren:

• Benutzer ohne core.create/core.edit/core.edit.own auf com_weblinks → Fehler
• Benutzer mit core.create auf com_weblinks → kein Fehler

Nachdem die besonders kritischen Sicherheitslücken in PHP durch Update oder Patsch geschloßen sind wird auf php.net empfohlen:

session.upload_progress.enabled=0

zu setzen – zumindest bis zur nächsten regulären Fehlerbehebungs-Version (Bugfix-Release) –, um einen vollständigen Schutz gegen einen – wenn auch unwahrscheinlichen – RCE-Vektor (Remote Code Execution) zu gewährleisten.

Siehe auch:

https://www.php.net/

Mit Google Translate übersetz:

[…]

Wie "session.upload_progress.enabled" bei euch eingestellt ist seht ihr übrigens im Joomla-Backend bei

System -> Informationen-System-Informationen -> im Tab "PHP-Informationen" im Abschnitt(Modul) session.

Wer im Tab "PHP-Informationen" ist, gelangt auch damit dann zum Abschnitt(Modul) session :

/administrator/index.php?option=com_admin&view=sysinfo#module_session

Wenn euch nicht bekannt ist wie ihr session.upload_progress.enabled konfigurieren könnt wendet euch an euren Webhoster.

Bei manchen Webhostern genügt der Eintrag von

…