In der Vergangenheit gab es immer wieder Nutzerbeschwerden, weil Änderungen an Bestandsbildern (Bild ersetzt, Größe angepasst etc) im Backend nicht sofort sichtbar wurden, weil besagte Bilder im Browser-Cache waren. Der Timestamp hebelt den Cache aus um das Problem zu lösen.
Grundsätzlich also durchaus eine gute Idee, eventuell aber wäre es sinniger, den Timestamp an das modification Date der Datei zu binden.
wilderer wenn ich dich richtig verstehe, vermischst du hier zwei Dinge:
1. die Dateigröße der Update-Pakete
2. die Frage ob jedes neue Feature in jedem Update mit drin sein muss
Das sind völlig unterschiedliche Fragestellungen, die nichts miteinander zutun haben.
Das Dateigrößen-Thema ist ein technisches Thema, das ist mit überschaubarem Aufwand lösbar.
Die Frage, ob neue Features Core-Bestandteil sind oder nicht ist hingegen etwas völlig anderes. Dein Wunschszenario ist dabei, dass du dir quasi wie beiden Extensions genau die Core-Features aktivieren kannst, die du auf deiner Seite brauchst. Durchaus eine charmante Idee, die man mal bei der com_weblinks ausprobiert hat. Ergebnis: das ist garnicht so einfach. Denn es gibt fest verdrahtete Abhängigkeiten zwischen vielen Core-Erweiterungen, die man dafür erstmal auflösen müsste. Und da stellt sich die Frage, warum man dafür Ressourcen investieren sollte - welches Problem wird dadurch gelöst?
Offenbar bist Du dann bei einem Hoster, der nicht vom Joomla-Security-Teams über Core-Lücken informiert wird. Es wurde bei Erscheinen der Sicherheitslücke entsprechende Filterregeln verteilt, um solche Angriffe bereits auf Firewall-Ebene zu blocken.
Strato wurde informiert.
Also: um es erstmal in aller Deutlichkeit zu sagen: der Umstand, dass ein System Fehlermeldungen mit Pfaden ausgibt bedeutet an sich erstmal noch nicht, dass man die Seite erfolgreich angreifen kann. Die Fehlermeldungen geben einem Angreifer "nur" interessante Hinweise zu verwendeten Systemkomponenten, Pfadstruktur, Betriebssystem und co - diese Hinweise kann man dann nutzen, um nach anderen Lücken zu suchen bzw. sie können helfen, andere Lücken auszunutzen.
Voraussetzung für einen erfolgreichen Angriff ist dabei aber immer, dass es eben solche vorhanden Lücken überhaupt gibt. Ohne Lücke, kein erfolgreicher Angriff.
Dennoch ist es natürlich Best Practice, das Error Reporting auf Produktivsystem möglichst "stumm" zu halten. Wenn in der Joomla Konfiguration das Error Reporting deaktiivert ist, werden dabei etwaige Vorgaben auf Betriebssystemlevel überschrieben. Es wäre dann somit egal, was Ionos da eingestellt hatte.
Google entscheidet bei Recaptcha auf Grundlage des Nutzerverhaltens, ob eine explizite Aufgabe abgefragt wird, oder ob der Nutzer auch ohne Aufgabe vertrauenswürdig genug ist.
Hast du mal einen Screenshot der Meldung? Der Regex, den Joomla zur Prüfung verwendet, sollte solche Adressen eigentlich zulassen, daher wäre der ganz konkrete Kontext der Meldung sehr spannend.
Ich denke die vom Security-Team für die Hoster mitgeteilten mod-security-Regeln kann man auch mit htaccess realisieren.
Ich möchte das hier nicht veröffentlichen, weil das ggf. auch potentiellen Angreifern hilft.
Siehe Mitigation Option B:
Bin ich ab dem Update auf Joomla 4.2.8 geschützt und wenn bisher noch keine Angriffe erfolgt sind, bedeutet dies, dass die Daten über API noch nicht abgegriffen wurden? Kann ich dann auf die Passwortänderungen verzichten?
Wenn du sicher sagen kannst, das keine Daten abgegriffen worden sind dann ja, dann kann man darauf verzichten.
tatsächlich durch eine Kompromitierung passieren kan
Datenbank Daten abgreifen, eigene Verbindung zum Datenbank Server aufbauen, neuen Super User erzeugen, einloggen, backdoor installieren. Zack: Seite gehackt.
Wenn ich mal spaßeshalber quer-beet über die Server schaue sind nicht einmal 50% aller 4er-Joomla geupdated worden - trotz direkter Anspache an alle Kunden, als das Update das erste mal angekündigt wurde.
Ich habe nichts anderes erwartet...
in die Firewall? Wie wo was? Kannst Du das bitte mal näher erklären?
Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.
So, die vom Security-Team gelieferten Infos sind in die Firewall eingetragen. Damit sollte hier schon mal alles sicher sein.
Top 
danke!
Als Rheinländer muss ich mal anmerken, dass Altweiberdonnerstag 17.00 Uhr ein sehr unglücklicher Zeitpunkt ist.
Schöne Karnevalstage
Angesichts des Anteils, den das Rheinland an der Weltbevölkerung hat, ist das ein Argument mit überschaubarer Schlagkraft.
Mit der Veröffentlichung von Joomla! 4.2.8 wird u.a. eine kritische Sicherheitslücke geschlossen. Das Update erscheint voraussichtlich am 16.02.2023 um 17 Uhr (MEZ).
Das Joomla Sicherheits-Team (JSST) wurde über eine kritische Sicherheitslücke im Joomla! Core informiert. Da dies eine sehr wichtiger Sicherheitspatch ist, bereitet euch bitte darauf vor, eure Joomla Seiten am kommenden Donnerstag zu aktualisieren.
Bevor Joomla! 4.2.8 nicht veröffentlicht wurde, können wir aus mehreren Gründen keine weiteren Informationen herausgeben.
JAMP ignoriert den Page-Cache (Plugin), reagiert aber auf den anderen Cache.
Dann ist es am wahrscheinlichsten, dass das AMP Ding irgendwo die Ausführung von Joomla abbricht, bevor der Cache erzeugt werden kann.
Durch den Cache aber wird die Bedingung (.amp in der URI oder nicht) ignoriert.
Durch den Cache wird der Code, der ohne Cache dazu führt dass Modules Anywhere überhaupt ausgeführt wird, nicht mehr ausgeführt. Da hat Modules Anywhere somit in der Tat keinen Einfluss drauf.
Erzähl mal ein bisschen mehr zu dem Kontext um den es da geht. Wo wird der Code ausgeführt, was ist das für ein Plugin etc.
Der Seitencache erzeugt ein Cache-Ergebnis je URL, da ist die Logik also schlicht eine andere.
Der Leistungsschub entsteht ja eben dadurch, dass der Code nicht jedes Mal durchlaufen wird 
da geht also nur A oder B.
Dein Code wird in dieser Konstellation beim zweiten Mal garnicht mehr aufgerufen, du siehst die gecachte Ausgabe des ersten Durchlaufs.
Erklärkontext:
Es gibt zwei verschiedene Versionen des Programms „PHP“.
Die eine Version ist spezifisch für die Nutzung auf der Kommandozeile, also dem Command Line Interface (kurz CLI) gedacht.
Die andere Version soll direkt vom Webserver verwendet werden, wenn der Server die Aufgabe bekommt, einen Webseitenbesucher eine PHP Seite auszuliefern. Die Kommunikation mit dem Webserver geht dabei über das CGI Protokoll und zeichnet sich dadurch aus, dass nicht nur die Ausgabe des Scripts übergeben werden, sondern auch HTTP-Header.
Genau diese Header sieht man in Deiner Beispielausgabe. Daher lag die Vermutung nahe, dass in deinem Fall der Befehl „PHP“ auf der Kommandozeile mit der falschen Variante (nämlich CGI statt CLI) des Programms verknüpft ist.
Schau mal ob das php-cli binary verfügbar ist und Probier es damit
