Zusammenfassung:
Am 28. Oktober 2026 aktivieren wir auf sämtlichen Webservern für PHP 8.2 bis 8.5 sicherere Standardwerte für PHP-Sessions. Dies ist eine Vorsichtsmassnahme im Nachgang zu PHP2Shell und bereitet auf die neuen Standardwerte von PHP 8.6 vor.
Details:
Als Vorsichtsmassnahme im Nachgang zu den kritischen PHP-Sicherheitslücken PHP2Shell (siehe Statusmeldung und Blogpost) härten wir die Session-Konfiguration von PHP. Ab dem 28. Oktober 2026 gelten auf sämtlichen Webservern für PHP 8.2, 8.3, 8.4 und 8.5 die folgenden Standardwerte:
session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_samesite = "Lax"
Es handelt sich um genau die Standardwerte, die mit dem kommenden PHP 8.6 ohnehin eingeführt werden. Mit der vorzeitigen Umstellung erhöhen wir die Sicherheit bereits jetzt und erleichtern den späteren Wechsel auf PHP 8.6.
session.use_strict_mode = 1: PHP akzeptiert nur noch Session-IDs, die auf dem Server tatsächlich existieren. Unbekannte, vom Client vorgegebene IDs werden durch eine neue ersetzt. Dies schützt vor Session Fixation.session.cookie_httponly = 1: Das Session-Cookie kann nicht mehr per JavaScript ausgelesen werden. Dies erschwert den Diebstahl von Sessions über Cross-Site-Scripting (XSS).session.cookie_samesite = "Lax": Das Session-Cookie wird bei Cross-Site-Anfragen (z.B. POST-Formulare von fremden Websites, eingebettete Inhalte in fremden iframes) nicht mehr mitgesendet, bei normalen Links von anderen Websites hingegen schon. Dies schützt vor Cross-Site Request Forgery (CSRF).Betroffen sind nur Anwendungen, die PHP-Sessions direkt mit den Standardwerten von PHP nutzen (session_start()), in der Regel also individuell entwickelte PHP-Anwendungen. Bei gängigen CMS, Shops und Frameworks wie WordPress, Joomla, Drupal, TYPO3, Contao, Shopware, Laravel oder Symfony sowie bei Anwendungen wie Nextcloud oder Roundcube sind keine Probleme zu erwarten: Sie verwenden entweder keine PHP-Sessions, verwalten ihre Sessions selbst oder sind mit diesen Einstellungen bereits kompatibel.
Mögliche Auswirkungen hat vor allem session.cookie_samesite = "Lax", z.B. bei Rücksprüngen von Zahlungsanbietern per POST (3-D Secure), Single Sign-on (SAML) oder wenn eine Website in einem iframe auf einer fremden Website eingebettet ist.
Die allermeisten Kunden sind von der Umstellung also gar nicht betroffen und müssen nichts unternehmen. Für die übrigen Fälle gibt es folgende Möglichkeiten:
session.cookie_samesite kann weiterhin selbst im Airpane Controlpanel in der PHP-Konfiguration der jeweiligen PHP-Version angepasst werden: Lax (Standard), Strict oder none (kein SameSite-Attribut, bisheriges Verhalten).session.use_strict_mode und session.cookie_httponly passen wir bei Bedarf gerne auf Anfrage über unseren Support an.ini_set() oder session_set_cookie_params().Für die Umstellung ist lediglich ein kurzer Neustart der PHP-Dienste nötig, ohne nennenswerten Unterbruch.
]]>Details:
Aufgrund der angekündigten kritischen PHP-Sicherheitsupdates (vgl. Upcoming Critical PHP Security Release), die heute um 16:00 Uhr CEST veröffentlicht werden, haben wir vorsorglich Geo-Fencing aktiviert, bis sämtliche PHP-Versionen gepatcht und unsere Systeme entsprechend aktualisiert sind.
Aktuell ist der Zugriff auf unsere Webserver nur aus der Schweiz (CH), Liechtenstein (LI) und Österreich (AT) möglich. Zugriffe aus allen anderen Ländern werden vorübergehend blockiert.
Diese Massnahme dient ausschliesslich der Vorsorge. Nach unserem aktuellen Kenntnisstand sind noch keine Exploits für die betreffenden Sicherheitslücken bekannt.
Um mögliche Sicherheitsrisiken bis zur Veröffentlichung der Updates auszuschliessen, haben wir heute um 16:00 Uhr sämtliche Webserver vorsorglich vorübergehend offline genommen. Zahlreiche andere Hosting-Unternehmen und grössere Online-Dienstleister haben ähnliche Schutzmassnahmen ergriffen.
Die neuen PHP-Versionen wurden von php.net pünktlich um 16:00 Uhr CEST veröffentlicht. Bereits kurz darauf standen auch die entsprechenden Debian-Pakete von DEB.SURY.ORG zur Verfügung. Zwischen 16:20 und 16:40 Uhr konnten wir sämtliche Webserver erfolgreich auf die neuen PHP-Versionen aktualisieren:
Seit 16:46 Uhr sind sämtliche Webserver wieder uneingeschränkt erreichbar. Gleichzeitig wurden auch die zuvor aktivierten Geo-Fencing-Einschränkungen vollständig aufgehoben.
Vielen Dank für euer Verständnis!
Wir haben heute sämtliche Webserver zusätzlich einem umfassenden Incident Review unterzogen. Dabei haben wir sämtliche verfügbaren Logfiles rückwirkend bis zum 17. Oktober auf verdächtigen Scanner-Traffic und Exploit-Versuche untersucht. Obwohl wir entsprechende Aktivitäten feststellen konnten, fanden wir keinerlei Hinweise auf eine erfolgreiche Ausnutzung der PHP-Sicherheitslücken auf unseren Webservern.
Für alle, die sich für die technischen Hintergründe von PHP2Shell und den genauen Ablauf unserer Schutzmassnahmen und Sicherheitsupdates interessieren, haben wir einen ausführlicheren Rückblick veröffentlicht:
PHP2Shell: Kritische PHP-Sicherheitsupdates erfolgreich eingespielt
Darin erläutern wir die Sicherheitslücken, unsere vorsorglichen Massnahmen und wie wir sämtliche Webserver innerhalb kürzester Zeit aktualisieren und wieder online bringen konnten.
Am 23. Oktober 2026 hat das PHP-Projekt ein ergänzendes Advisory zu Session Upload Progress veröffentlicht: Unter einer seltenen Kombination von Konfiguration und Anwendungscode besteht noch ein weiterer, unwahrscheinlicher Angriffsweg (CVE-2026-115560), der erst mit dem nächsten regulären PHP-Release behoben wird. Bis dahin empfiehlt php.net, die Option session.upload_progress.enabled zu deaktivieren.
Wir haben diese Empfehlung heute auf sämtlichen Webservern umgesetzt. Dafür war lediglich ein kurzer Neustart der PHP-Dienste nötig.
Für unsere Kunden ändert sich praktisch nichts: Datei-Uploads funktionieren wie gewohnt. Einzig eine serverseitige Fortschrittsanzeige für laufende Uploads über diese PHP-Funktion steht vorübergehend nicht zur Verfügung. Aktuelle Anwendungen wie WordPress, Nextcloud oder TYPO3 zeigen den Upload-Fortschritt ohnehin direkt im Browser an und sind davon nicht betroffen. Sobald das nächste PHP-Release mit der endgültigen Korrektur verfügbar ist, aktivieren wir die Option wieder.
]]>