PHP-Sicherheitsupdate einspielen (Windows)#

Am 21.10.2026 hat das PHP-Projekt zwei kritische Lücken veröffentlicht (CVE-2026-109618 und CVE-2026-109619, jeweils Remote Code Execution ohne Anmeldung, CVSS 9.2). Behoben sind sie in PHP 8.4.27, 8.3.36 und 8.2.35. Das höchste Risiko sieht das PHP-Projekt bei mod_php, und genau so betreibt der i-doit Windows Installer PHP: als Modul im Apache-Dienst Apache2.4. Jede Installation mit diesem Installer ist also betroffen.

Unter Windows gibt es keine Paketverwaltung, die PHP aktualisiert. Das Update besteht darin, die PHP-Dateien gegen den korrigierten Build von php.net zu tauschen. Die php.ini bleibt dabei erhalten. Die Schritte 1–8 beschreiben das für den i-doit Windows Installer. Für die Installation unter IIS und mit XAMPP gibt es eigene Abschnitte am Ende.

Kurzfassung#

Voraussetzungen#

• i-doit, installiert mit dem i-doit Windows Installer. Prüfen: Der Ordner C:\ProgramData\i-doit\php existiert und der Dienst Apache2.4 läuft.
• Ein Konto mit Administratorrechten und eine PowerShell als Administrator.
• Internetzugang vom Server zu downloads.php.net. Ohne Internetzugang die ZIP-Datei an einem anderen Rechner laden und auf den Server kopieren.
• Ein Wartungsfenster von wenigen Minuten. Während Apache gestoppt ist, ist i-doit nicht erreichbar.

1. Sichern#

Vor dem Update einen Snapshot der virtuellen Maschine anlegen oder mindestens die Datenbanken und den Ordner C:\ProgramData\i-doit sichern, siehe Daten sichern und wiederherstellen. Den Ordner php sichert Schritt 4 zusätzlich.

2. Ausgangsstand festhalten#

1
2

C:\ProgramData\i-doit\php\php.exe -v
Select-String C:\ProgramData\i-doit\apache-2.4\conf\httpd.conf -Pattern 'php_module|PHPIniDir'

Beispiel vor dem Update:

1
2
3

PHP 8.2.23 (cli) (built: Aug 27 2024 16:28:43) (ZTS Visual C++ 2019 x64)
LoadModule php_module "C:/ProgramData/i-doit/php/php8apache2_4.dll"
PHPIniDir "C:/ProgramData/i-doit/php"

Aus der ersten Zeile ergeben sich die beiden Angaben für den Download:

• Versionszweig (hier 8.2): Im selben Zweig bleiben. Ein Wechsel etwa von 8.2 auf 8.4 ist ein eigenes Projekt, siehe Kompatibilitätsmatrix.
• ZTS bedeutet Thread Safe. Für Apache mit mod_php ist das richtig und zwingend. Ein Non-Thread-Safe-Build (NTS) enthält weder php8apache2_4.dll noch php8ts.dll: Apache lädt danach ohne Fehlermeldung weiter die alten, verwundbaren Dateien.

3. Korrigierten Build laden und prüfen#

Die Builds stehen unter php.net/downloads (Windows) beziehungsweise im Archiv https://downloads.php.net/~windows/releases/archives/. Benötigt wird die ZIP-Datei „x64 Thread Safe“, nicht der Debug-Pack und nicht „Non Thread Safe“:

Laden und Prüfsumme vergleichen (Beispiel 8.2.35; für 8.3 oder 8.4 die beiden Variablen aus der Tabelle übernehmen):

1
2
3
4
5

$zip  = 'php-8.2.35-Win32-vs16-x64.zip'
$hash = 'cfa6000be835931961e40740bd3b51111700061d6655ddbfe5a2125807947457'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest "https://downloads.php.net/~windows/releases/archives/$zip" -OutFile "$env:TEMP\$zip" -UseBasicParsing
(Get-FileHash "$env:TEMP\$zip" -Algorithm SHA256).Hash -eq $hash

Die letzte Zeile muss True ausgeben. Bei False die Datei nicht verwenden.

4. Apache stoppen und PHP-Ordner sichern#

1
2
3
4

Stop-Service Apache2.4
$bak = "C:\ProgramData\i-doit\php-backup-$(Get-Date -Format yyyyMMdd-HHmm)"
Copy-Item C:\ProgramData\i-doit\php $bak -Recurse
$bak

Apache muss gestoppt sein, sonst sind php8ts.dll und die Erweiterungen gesperrt und lassen sich nicht überschreiben.

5. Neue PHP-Dateien entpacken#

1

Expand-Archive "$env:TEMP\$zip" -DestinationPath C:\ProgramData\i-doit\php -Force

Das ZIP von php.net enthält keine php.ini, nur die Vorlagen php.ini-development und php.ini-production. Die vorhandene php.ini bleibt deshalb unverändert, mit allen Erweiterungen, OPcache-Einstellungen und Pfaden. Zur Kontrolle:

1

(Get-FileHash C:\ProgramData\i-doit\php\php.ini).Hash -eq (Get-FileHash "$bak\php.ini").Hash

Ergibt das False, die gesicherte Datei zurückkopieren: Copy-Item "$bak\php.ini" C:\ProgramData\i-doit\php\php.ini -Force.

6. Apache starten#

1
2

Start-Service Apache2.4
Get-Service Apache2.4

Der Status muss Running lauten. Startet der Dienst nicht, zeigt C:\ProgramData\i-doit\apache-2.4\bin\httpd.exe -t den Grund.

7. Nachweis: Ist die Lücke geschlossen?#

Die Kommandozeile und der Webserver müssen beide die neue Version zeigen:

1
2
3

C:\ProgramData\i-doit\php\php.exe -v
Select-String C:\ProgramData\i-doit\apache-2.4\logs\error.log -Pattern 'configured' | Select-Object -Last 1
Get-Process httpd | ForEach-Object { $_.Modules } | Where-Object ModuleName -eq 'php8ts.dll' | Select-Object -First 1 FileVersion, FileName

Erwartete Ausgabe:

1
2
3
4
5

PHP 8.2.35 (cli) (built: Oct 20 2026 04:17:59) (ZTS Visual C++ 2019 x64)
... AH00455: Apache/2.4.55 (Win64) PHP/8.2.35 configured -- resuming normal operations
FileVersion FileName
----------- --------
8.2.35      C:\ProgramData\i-doit\php\php8ts.dll

Die dritte Zeile ist der stärkste Nachweis: Sie zeigt die PHP-Bibliothek, die der laufende Apache tatsächlich geladen hat. Die Versionsnummer muss mindestens 8.2.35, 8.3.36 oder 8.4.27 lauten. Anders als bei Linux-Distributionen gibt es unter Windows keine zurückportierten Korrekturen mit alter Versionsnummer: Die Upstream-Versionsnummer ist der Nachweis.

In i-doit zeigt zusätzlich die Verwaltung unter System Config Check die PHP-Version an.

8. i-doit prüfen#

1. http://<i-doit-host>/ im Browser öffnen und anmelden.
2. Ein beliebiges Objekt öffnen, ein Feld ändern, speichern.
3. http://<i-doit-host>/admin/ öffnen und anmelden. Die Seiten müssen ohne Fehlermeldung laden.

Im Test liefen Login, Dashboard, Objektlisten, Export und Admin Center nach dem Update ohne Fehler, die Ladezeiten waren vor und nach dem Update gleich. Ohne eingespieltes Lizenztoken verlangt i-doit nach dem Login zuerst das Token; ein Objekt lässt sich dann erst nach dessen Eingabe bearbeiten. Das ist unabhängig vom Update.

Bleibt die Seite weiß oder meldet Apache einen Fehler 500: C:\ProgramData\i-doit\apache-2.4\logs\error.log prüfen und mit C:\ProgramData\i-doit\php\php.exe -m kontrollieren, ob alle Erweiterungen geladen werden. Im Test wurden alle in der php.ini aktivierten Erweiterungen (unter anderem ldap, gd, intl, soap) vor und nach dem Update gleich geladen.

Läuft alles, können die ZIP-Datei in %TEMP% und nach einigen Tagen die Sicherung php-backup-… gelöscht werden.

Stolperfallen#

• Thread Safe, nicht NTS. Apache mit mod_php braucht den Thread-Safe-Build. Ein NTS-ZIP ersetzt die Apache-Modul-Dateien nicht: php.exe -v zeigt dann die neue Version, der Webserver läuft aber weiter mit der alten. Schritt 7 deckt das auf.
• Versionszweig nicht wechseln. Von 8.2.x auf 8.2.35, von 8.3.x auf 8.3.36, von 8.4.x auf 8.4.27. Ein Sprung auf einen anderen Zweig kann Erweiterungen und i-doit-Kompatibilität ändern.
• Apache vorher stoppen. Sonst schlägt das Entpacken mit „Zugriff verweigert“ fehl oder ersetzt nur einen Teil der Dateien, und Apache lädt danach gemischte Versionen.
• php -v allein reicht nicht. Es prüft nur die Datei auf der Platte. Erst die Zeile im Apache-Log oder die geladene php8ts.dll zeigt, dass der Webserver die neue Version nutzt (Schritt 7).
• PHPIniDir in der Anleitung für HTTPS. Wer HTTPS nach der Installationsanleitung eingerichtet hat, sollte prüfen, dass PHPIniDir in der httpd.conf auf C:/ProgramData/i-doit/php zeigt. Steht dort ein anderer Pfad, lädt PHP eventuell eine andere oder gar keine php.ini. php.exe -r "echo php_ini_loaded_file();" zeigt die verwendete Datei.
• Warnung Failed loading C:/ProgramData/i-doit/php/ext. Der i-doit Windows Installer aus dem Kundenportal schreibt eine fehlerhafte OPcache-Zeile (zend_extension ohne Dateinamen) in die php.ini. Die Meldung erscheint deshalb bei jedem php.exe-Aufruf, vor und nach dem Update gleich, und ist keine Folge des Updates. Behebung: in der php.ini die Zeile auf zend_extension=opcache ändern, opcache.enable=1 setzen und Apache neu starten.
• Rückweg nur mit dem ganzen Ordner. Die gesicherte alte php.exe lässt sich nicht neben den neuen Erweiterungen starten (Unable to load dynamic library …). Zum Zurückgehen immer den kompletten Ordner aus der Sicherung zurückkopieren, siehe Rückweg.
• Zwischenlösung bis zum Update. session.upload_progress.enabled = 0 in der php.ini mindert eine der beiden Lücken, danach Apache neu starten. Die andere Lücke bleibt offen. Den Server bis zum Update nur aus dem internen Netz erreichbar machen.

IIS (Installationsskript)#

Gilt für Installationen nach i-doit unter IIS. PHP liegt dort unter C:\PHP und läuft per FastCGI (php-cgi.exe), nicht als Apache-Modul. Deshalb wird hier der Non-Thread-Safe-Build (NTS) benötigt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

$zip  = 'php-8.2.35-nts-Win32-vs16-x64.zip'
$hash = '798ffa4b9ce22a820d57048e9695df7245bf917ed067917f256942a10918a8cc'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest "https://downloads.php.net/~windows/releases/archives/$zip" -OutFile "$env:TEMP\$zip" -UseBasicParsing
(Get-FileHash "$env:TEMP\$zip" -Algorithm SHA256).Hash -eq $hash

iisreset /stop
$bak = "C:\PHP-backup-$(Get-Date -Format yyyyMMdd-HHmm)"
Copy-Item C:\PHP $bak -Recurse
Expand-Archive "$env:TEMP\$zip" -DestinationPath C:\PHP -Force
iisreset /start

iisreset /stop beendet auch alle php-cgi.exe-Prozesse; sonst sind die Dateien gesperrt. Die php.ini und die vom Skript geladene C:\PHP\cacert.pem sind nicht im ZIP und bleiben erhalten.

Nachweis: IIS startet php-cgi.exe erst mit der ersten Anfrage. Deshalb zuerst eine Seite aufrufen, dann prüfen:

1
2
3

Invoke-WebRequest http://localhost/ -UseBasicParsing | Out-Null
C:\PHP\php.exe -v
Get-Process php-cgi | ForEach-Object { $_.Modules } | Where-Object ModuleName -eq 'php8.dll' | Select-Object -First 1 FileVersion, FileName

Erwartete Ausgabe:

1
2
3
4

PHP 8.2.35 (cli) (built: Oct 20 2026 04:20:16) (NTS Visual C++ 2019 x64)
FileVersion FileName
----------- --------
8.2.35      C:\PHP\php8.dll

Die zweite Ausgabe zeigt die PHP-Bibliothek, die der laufende FastCGI-Prozess tatsächlich geladen hat. Im Test liefen danach Login, Speichern eines Objekts und Admin Center ohne Fehler.

XAMPP#

Gilt für Installationen nach i-doit via XAMPP. PHP liegt unter C:\xampp\php und läuft wie beim Installer als Apache-Modul, also wird der Thread-Safe-Build benötigt. Ein korrigiertes XAMPP-Paket gibt es nicht: Das neueste Windows-Paket auf apachefriends.org ist weiterhin xampp-windows-x64-8.2.12-0-VS16 mit PHP 8.2.12 vom November 2023. Der Austausch des PHP-Ordners funktioniert aber.

Apache zuerst stoppen: im XAMPP Control Panel bei Apache auf Stop klicken oder, wenn Apache als Dienst läuft, Stop-Service Apache2.4. Dann:

1
2
3
4
5
6
7
8
9

$zip  = 'php-8.2.35-Win32-vs16-x64.zip'
$hash = 'cfa6000be835931961e40740bd3b51111700061d6655ddbfe5a2125807947457'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest "https://downloads.php.net/~windows/releases/archives/$zip" -OutFile "$env:TEMP\$zip" -UseBasicParsing
(Get-FileHash "$env:TEMP\$zip" -Algorithm SHA256).Hash -eq $hash

$bak = "C:\xampp\php-backup-$(Get-Date -Format yyyyMMdd-HHmm)"
Copy-Item C:\xampp\php $bak -Recurse
Expand-Archive "$env:TEMP\$zip" -DestinationPath C:\xampp\php -Force

Danach Apache wieder starten (Control Panel Start oder Start-Service Apache2.4). Die php.ini von XAMPP ist nicht im ZIP und bleibt erhalten, ebenso die Pfade auf C:\xampp\apache\bin\curl-ca-bundle.crt. Die httpd-xampp.conf lädt php8ts.dll, libpq.dll und libsqlite3.dll per LoadFile direkt aus C:\xampp\php; alle drei Dateien sind im ZIP enthalten und werden mit ersetzt.

Nachweis wie in Schritt 7, nur mit den XAMPP-Pfaden:

1
2
3

C:\xampp\php\php.exe -v
Select-String C:\xampp\apache\logs\error.log -Pattern 'configured' | Select-Object -Last 1
Get-Process httpd | ForEach-Object { $_.Modules } | Where-Object ModuleName -eq 'php8ts.dll' | Select-Object -First 1 FileVersion

Erwartet: PHP 8.2.35, Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.35 configured und 8.2.35. Im Test liefen danach Login, Speichern eines Objekts und Admin Center ohne Fehler; alle in der php.ini aktivierten Erweiterungen (darunter ldap, gd, openssl, pdo_mysql) wurden auf der Kommandozeile geladen, unter Apache alle außer curl (siehe Hinweise).

i-doit Discovery (nicht getestet)#

Das Paket i-doit Discovery (Installer mit JDisc) richtet PHP wie der i-doit Windows Installer ein, aber unter C:\ProgramData\i-doit-discovery\php und mit der httpd.conf unter C:\ProgramData\i-doit-discovery\apache-2.4\conf. Der Ablauf aus den Schritten 1–8 gilt entsprechend mit diesen Pfaden. Mangels Paket haben wir ihn nicht getestet.

Rückweg#

Webserver stoppen, den PHP-Ordner löschen und durch die Sicherung ersetzen, Webserver starten:

Den Rückweg haben wir nicht eigens getestet. Wegen der offenen Lücke ist er ohnehin nur als Notlösung sinnvoll. Besser: Snapshot zurücksetzen und die Ursache klären.

Weiterführende Links#

• PHP-Sicherheitshinweis vom 21.10.2026
• PHP 8 ChangeLog (8.4.27: GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp)
• PHP für Windows herunterladen
• Update PHP und MariaDB unter Windows
• Kritisches PHP-Sicherheitsupdate (Oktober 2026): Überblick für alle Plattformen
• Systemvoraussetzungen