Ich rate nur php ab zu schalten (oder die container oder dienste..). Ansonsten fährt der ja wieder hoch und ist sofort angreifbar während du noch nach updates suchst.
ja... Boot erfolgt dann erstmal ohne Netzwerk, dann php aus, dann netzwerk, dann updates, dann php an.
Ich rate nur php ab zu schalten (oder die container oder dienste..). Ansonsten fährt der ja wieder hoch und ist sofort angreifbar während du noch nach updates suchst.
Deshalb habe ich vor ca. 1 Stunde bei allen 5 Server bereits ein Update gemacht, dass alles was sonst so an Updates dabei ist heute Abend wenn ich die Server wieder hochfahre nicht dabei ist. Dann geht es schneller wenn dann wahrscheinlich nur PHP im Update vorhanden ist. Und ich werde nicht alle 5 Server sofort hochfahren, sondern einen nach den anderen hochfahren und dann gleich das Update machen. Mit hoher Wahrscheinlichkeit werde ich dann auch kein ssh verwenden, sondern gleich vom SCP aus auf die Konsole wechseln.
Und wenn der erste Server upgedatet ist, dann den nächsten hochfahren und das selbe Prozedere. Dies bis ich mit allen 5 Server durch bin.
Release ist da: https://www.php.net/archive/2026.php#2026-10-20-1
Ich habe vorhin quasi überall auf meinen Systemen die PHP-FPM-Systemd-Units "maskiert" und gestoppt. Wo das nicht möglich war (z.B. bei mod_php) wurde das mit dem ganzen Apache gemacht. Teilweise gibt es eigene 502 Error-Pages, vereinzelt war es mir aber auch völlig egal ob da eine Fehlermeldung vom Nginx angezeigt wird.
Lieber ein paar Stunden alles offline haben, als sich nachher zu ärgern…
sondern gleich vom SCP aus auf die Konsole wechseln
Ich übersehe vermutlich was. Meine Logik ist: du fährst die Kiste hoch, der php-code fährt mit hoch, sie ist angreifbar. Danach logst du dich ein und änderst was. Solange du nicht vorher das Netzwerk trennst bleibt das Problem ja bestehen.
Release ist da
Da is nix neues ?! Und mein APT sagt nein..
Alles anzeigenHallo zusammen,
wichtige Ankündigung:
Wir werden in den nächsten Minuten das Forum, Customer Control Panel, Plesk, CloudDNS API und Webmail vorsorglich abschalten, bis wir einen Patch haben. Das SCP bleibt online.Zudem werden wir ab der Veröffentlichung des Patches alle Webhosting Pakete (inkl. Managed Server) offline nehmen, bis wir alles durchgepatched haben. Den Zugriff auf Plesk werden wir sofort abschalten. Wir schätzen ungefähr 3-5 Stunden an Downtime für die Webhostings.
Sorry für die Unannehmlichkeiten, aber der CVE ist laut unseren Informationen, die uns offiziell und inoffiziell vorliegen, viel zu kritisch und wir gehen auf Nummer sicher. Wir arbeiten schnellstmöglich am Patching der Systeme und bringen alle wieder schnellstmöglich online.
Wir werden euch alle auf der Status Seite (https://www.netcup-status.de) auf dem Laufenden halten.
Liebe Grüße
Alex
Tipp/Idee:
Bekommt ihr das ale großen Banner auf die Startseite?
Bzw. als Vorschaltseite vor die entsprechenden Seiten? Also Forum, CCP, Plesk u.s.w.
Damit die Kunden nicht erst nach der Statusseite suchen müssen
Hah wohl doch! Das war vor 1h noch nicht da
m_ueberall Danke dir für den Newsfeed. Ganz große Liebe!
Ist echt nicht Selbstverständlich, dass jemand das so macht!
Danke!
Ich sehe nicht, wie man durch das Herunterfahren des Apachen und damit der PHP-Startmöglichkeit den ganzen Server gefährdet.
Da läuft halt jeder andere Dienst weiter.
Hier passiert um 16:00 Uhr auf Debian Trixie Folgendes:
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; }
nft add rule inet filter input tcp dport { 80, 443 } drop
Und wenn die Updates durch sind:
nft -a list chain inet filter input (und handle mit der rule suchen)
nft delete rule inet filter input handle X (X ist die Nummer des handles)
Bis dann!
Das ist ja heute wie Silvester!
Nur 20 Minuten zu früh... Und das Forum ist noch nicht abgeschaltet... Zu spät 😉
Uff 
Aktualisierung für 177 Pakete verfügbar.
Da ist wohl ein großes DANKE an Ondřej Surý fällig. 
Ich übersehe vermutlich was. Meine Logik ist: du fährst die Kiste hoch, der php-code fährt mit hoch, sie ist angreifbar. Danach logst du dich ein und änderst was. Solange du nicht vorher das Netzwerk trennst bleibt das Problem ja bestehen.
Wenn es mich innerhalb der wenigen Minuten an einem Server erwischt dann habe ich leider Pech. Mit den Servern ein paar Stunden herunterfahren habe ich auch jedenfalls mein Risiko minimiert.
Ich bin bei solch Aktionen nicht geübt. Im Nachhinein würde ich es wie folgt machen. Erst den Webserver disablen und dann den Rechner herunterfahren. Denn dann ist der Webserver noch disabled und und ich könnte in Ruhe das Update fahren.
Egal. Das nächste mal bin ich besser auf solch Situationen vorbereitet.
Schon toll, alles auf 16h anzukündigen und dann 20min vorher zu releasen ..., damit 10min vorher alles exploited werden kann. Anyway, alle updates bei mir durch
Ansonsten fährt der ja wieder hoch...
Ich z.B. habe Autostart bei allen meinen Servern abgeschaltet.
Wenn da wirklich einer mal wegen Wartungsarbeiten down geht, dann werde ich ja übers Monitoring informiert und kann ihn manuell wieder starten.
Ist mir lieber so, dann habe ich die volle Kontrolle.
Schon toll, alles auf 16h anzukündigen und dann 20min vorher zu releasen ..., damit 10min vorher alles exploited werden kann. Anyway, alle updates bei mir durch
Klar kann es in der kurzen Zeitspanne jeden von uns mit einem seiner Server erwischen. Wenn ich jedoch bedenke wie vielen einen Server überall angemietet haben und selten Update machen und Secure-Infos im Web nicht lesen und danach handeln, wird es von jenen sicherlich weit mehr Server zwecks PHP erwischen.
Schon toll, alles auf 16h anzukündigen und dann 20min vorher zu releasen ..., damit 10min vorher alles exploited werden kann
frage mich auch extrem was das soll...
Andere Sache: Forum, CCP und Webhosting funktioniert bei mir übrigens immer noch
Schon toll, alles auf 16h anzukündigen und dann 20min vorher zu releasen ..., damit 10min vorher alles exploited werden kann. Anyway, alle updates bei mir durch
War angekündigt, dass das passieren kann
