PHP 8.2 erreicht das Supportende: So planen Sie das Update vor dem 31.12.2026

Am 31. Dezember 2026 endet die Sicherheitsunterstützung für PHP 8.2. Ab dem 1. Januar 2027 schließt das PHP-Projekt in diesem Zweig keine Lücken mehr – egal wie kritisch sie sind. Wer WordPress-Seiten, Intranet-Anwendungen, Monitoring-Oberflächen oder Ticketsysteme auf PHP 8.2 oder älter betreibt, hat jetzt noch gut zwei Monate Zeit. Dieser Beitrag zeigt, wie Sie alle PHP-Installationen finden, die richtige Zielversion wählen, die Anwendungen auf Verträglichkeit prüfen und das Update unter Windows Server mit IIS sowie unter Linux mit Apache sauber durchziehen.

Warum das Supportende so wichtig ist

PHP steckt in deutlich mehr Systemen, als in vielen Inventaren auftaucht: WordPress und andere CMS, Nextcloud, GLPI, Zabbix- und Monitoring-Frontends, Webmailer, Zeiterfassungen, Branchenlösungen, Herstellertools auf Windows-Servern und nicht zuletzt vergessene XAMPP-Installationen aus einem Testprojekt. Jede dieser Installationen ist direkt aus dem Netz oder zumindest aus dem LAN erreichbar und damit ein lohnendes Ziel.

Wie schnell Angreifer reagieren, hat CVE-2024-4577 gezeigt: Die kritische Lücke in PHP unter Windows wurde im Juni 2024 veröffentlicht, Angriffsversuche wurden bereits innerhalb von 24 Stunden registriert, und eine Ransomware-Gruppe nutzte sie kurz darauf aktiv. Behoben wurde sie nur in den damals unterstützten Zweigen. Wer zu diesem Zeitpunkt noch auf einer nicht mehr unterstützten Version saß, bekam keinen Patch.

Der PHP-Lebenszyklus im Überblick

Jeder PHP-Zweig erhält nach seiner Veröffentlichung zwei Jahre aktive Unterstützung (Fehlerbehebungen und Sicherheitsupdates) und danach zwei weitere Jahre reine Sicherheitsunterstützung. Neue Hauptversionen erscheinen jeweils gegen Ende November. Stand heute (26.10.2026) sieht der Zeitplan so aus:

Welche Zielversion ist die richtige?

• PHP 8.4 ist für die meisten Umgebungen die beste Wahl: ausgereift, von praktisch allen aktuellen Anwendungen unterstützt und mit Sicherheitsupdates bis Ende 2028.
• PHP 8.5 lohnt sich, wenn Hersteller und Plugins die Version ausdrücklich freigegeben haben. Sie bringt die längste Laufzeit (bis Ende 2029).
• PHP 8.3 nur als Zwischenschritt, wenn eine Anwendung 8.4 noch nicht unterstützt. Sie läuft bereits Ende 2027 aus – das Projekt steht dann in einem Jahr erneut an.
• PHP 8.6 erst einige Monate nach dem Erscheinen und nach Freigabe durch die Anwendungshersteller einsetzen.

Schritt 1: Alle PHP-Installationen finden

Bevor Sie aktualisieren, brauchen Sie ein vollständiges Inventar. Gerade auf Windows-Servern liegt PHP oft in Herstellerverzeichnissen, als Teil eines Software-Bundles oder in einer alten XAMPP-Installation.

Windows Server: per PowerShell im ganzen Netz suchen

Das folgende Skript fragt alle Server im Active Directory per WinRM ab, sucht auf den lokalen Laufwerken nach php.exe und php-cgi.exe und liest die Version aus den Dateieigenschaften. Die Ergebnisse landen in einer CSV-Datei.

# PHP-Inventar über alle Windows-Server (Ausführung mit Domänen-Adminrechten, WinRM aktiv)
$server = Get-ADComputer -Filter 'OperatingSystem -like "*Server*" -and Enabled -eq $true' |
          Select-Object -ExpandProperty DNSHostName

$ergebnis = Invoke-Command -ComputerName $server -ErrorAction SilentlyContinue -ScriptBlock {
    $laufwerke = Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Free -ne $null } |
                 Select-Object -ExpandProperty Root
    foreach ($lw in $laufwerke) {
        Get-ChildItem -Path $lw -Include php.exe, php-cgi.exe -Recurse -File -Force `
                      -ErrorAction SilentlyContinue |
        ForEach-Object {
            [pscustomobject]@{
                Server  = $env:COMPUTERNAME
                Pfad    = $_.FullName
                Version = $_.VersionInfo.ProductVersion
                Datum   = $_.LastWriteTime.ToString('yyyy-MM-dd')
            }
        }
    }
}

$ergebnis | Sort-Object Server, Pfad |
    Select-Object Server, Pfad, Version, Datum |
    Export-Csv -Path C:\Temp\PHP-Inventar.csv -NoTypeInformation -Encoding UTF8 -Delimiter ';'

$ergebnis | Group-Object { ($_.Version -split '\.')[0..1] -join '.' } |
    Select-Object @{n='Zweig';e={$_.Name}}, Count | Sort-Object Zweig

IIS: Welche PHP-Version nutzt welche Website?

Auf IIS-Servern verrät die FastCGI-Konfiguration, welche php-cgi.exe tatsächlich verwendet wird. Mehrere registrierte Versionen sind keine Seltenheit:

Import-Module WebAdministration
# Alle registrierten FastCGI-Anwendungen (PHP-Versionen)
Get-WebConfiguration -Filter 'system.webServer/fastCgi/application' |
    Select-Object fullPath, arguments, maxInstances, instanceMaxRequests

# Welche Handler-Zuordnung nutzt welche Site?
Get-Website | ForEach-Object {
    $site = $_.Name
    Get-WebHandler -PSPath "IIS:\Sites\$site" |
        Where-Object { $_.Path -eq '*.php' } |
        Select-Object @{n='Site';e={$site}}, Name, ScriptProcessor
}

Linux und Webhosting

php -v                                  # CLI-Version
php -r 'echo PHP_VERSION, PHP_EOL;'
ls /etc/php/                            # Debian/Ubuntu: installierte Zweige
update-alternatives --list php          # registrierte CLI-Versionen
systemctl list-units 'php*-fpm*'        # laufende PHP-FPM-Dienste
apachectl -M 2>/dev/null | grep -i php  # mod_php oder proxy_fcgi?

Schritt 2: Verträglichkeit prüfen

Zwischen 8.2 und 8.4 ändert sich im Alltag weniger als beim Sprung von 7.4 auf 8.x. Trotzdem gibt es Stolperstellen, vor allem bei älteren Eigenentwicklungen und wenig gepflegten Plugins:

So gehen Sie vor

1. Hersteller und Plugins prüfen: Unterstützt jede Anwendung die Zielversion? Bei WordPress die Angaben „Requires PHP“ und das Änderungsprotokoll der Plugins lesen.
2. Erweiterungen vergleichen: Auf dem alten System php -m ausführen und die Liste mit der neuen Installation abgleichen.
3. Statische Prüfung eigener Codes: Eigenentwicklungen mit PHP_CodeSniffer und dem Regelwerk PHPCompatibility prüfen. Achten Sie darauf, eine Version des Regelwerks zu verwenden, die Ihre Zielversion kennt.
4. Testsystem aufsetzen: Kopie der Anwendung mit Zielversion betreiben, error_reporting = E_ALL und log_errors = On setzen, alle wichtigen Funktionen durchklicken und das Fehlerprotokoll auswerten.
5. Rückweg planen: Vor dem Umstieg Sicherung von Dateien und Datenbank, alte PHP-Version zunächst parallel installiert lassen.

# Statische Kompatibilitätsprüfung einer Eigenentwicklung (Composer vorausgesetzt)
composer require --dev squizlabs/php_codesniffer phpcompatibility/php-compatibility
vendor/bin/phpcs -p ./src --standard=PHPCompatibility --runtime-set testVersion 8.4

Schritt 3: Update unter Windows Server mit IIS

Unter IIS lassen sich mehrere PHP-Versionen nebeneinander betreiben. Das macht den Umstieg einfach und den Rückweg sicher: Die neue Version wird parallel installiert und pro Website umgeschaltet.

1. Visual C++ Redistributable prüfen: Die aktuellen Builds benötigen die x64-Laufzeit „Visual C++ Redistributable 2015–2022“ (bzw. die neueste v14-Laufzeit). Ohne sie startet php-cgi.exe nicht.
2. Richtigen Build laden: Von windows.php.net die x64 Non Thread Safe (NTS)-Variante der Zielversion herunterladen. NTS ist laut PHP-Handbuch die richtige Wahl für IIS mit FastCGI. Prüfsumme (SHA256) mit der Angabe auf der Downloadseite vergleichen.
3. Parallel entpacken: z. B. nach C:\PHP\8.4. Die alte Version bleibt in C:\PHP\8.2 unangetastet.
4. php.ini übernehmen, nicht kopieren: php.ini-production als Vorlage verwenden und die Anpassungen der alten php.ini gezielt übertragen (Erweiterungen, Limits, Zeitzone, Sitzungen). Blindes Kopieren schleppt veraltete Direktiven mit.
5. FastCGI registrieren und Handler pro Site umstellen (siehe Skript unten).
6. Testen: Testseite mit phpinfo() nur kurzzeitig und nur von intern aufrufen, danach sofort löschen. Funktionstest der Anwendung, Protokolle prüfen.
7. Alte Version entfernen: Erst nach erfolgreichem Betrieb über einige Tage den alten FastCGI-Eintrag und das Verzeichnis löschen – sonst bleibt eine ungepatchte php-cgi.exe auf dem System.

Import-Module WebAdministration
$php  = 'C:\PHP\8.4\php-cgi.exe'
$site = 'Intranet'

# FastCGI-Anwendung für die neue Version anlegen
Add-WebConfiguration -Filter 'system.webServer/fastCgi' -Value @{
    fullPath = $php; maxInstances = 0; instanceMaxRequests = 10000; activityTimeout = 600
}
Add-WebConfiguration -Filter "system.webServer/fastCgi/application[@fullPath='$php']/environmentVariables" -Value @(
    @{ name = 'PHP_FCGI_MAX_REQUESTS'; value = '10000' },
    @{ name = 'PHPRC'; value = 'C:\PHP\8.4' }
)

# Handler der Site auf die neue Version umstellen
Set-WebHandler -PSPath "IIS:\Sites\$site" -Name 'PHP_via_FastCGI' -ScriptProcessor $php
# Existiert noch kein Handler:
# New-WebHandler -PSPath "IIS:\Sites\$site" -Name 'PHP_via_FastCGI' -Path '*.php' `
#   -Verb '*' -Modules FastCgiModule -ScriptProcessor $php -ResourceType Either

Restart-WebAppPool -Name (Get-Website -Name $site).applicationPool

Schritt 4: Update unter Linux mit Apache

Unter Debian und Ubuntu stehen neuere PHP-Zweige entweder in der nächsten Distributionsversion oder über etablierte Paketquellen zur Verfügung. Auch hier gilt: parallel installieren, umschalten, prüfen, dann aufräumen. Das Beispiel nutzt PHP-FPM, das gegenüber mod_php empfohlen ist.

# Zielversion parallel installieren (Modulnamen an Bedarf anpassen)
apt install php8.4-fpm php8.4-cli php8.4-mysql php8.4-xml php8.4-mbstring \
            php8.4-curl php8.4-zip php8.4-gd php8.4-intl

# Eigene Anpassungen aus /etc/php/8.2/fpm/ gezielt nach /etc/php/8.4/fpm/ übertragen
diff <(php8.2 -m) <(php8.4 -m)          # fehlende Erweiterungen erkennen

# Apache auf den neuen FPM-Pool umschalten
a2disconf php8.2-fpm
a2enconf  php8.4-fpm
apachectl configtest && systemctl reload apache2

# Nach erfolgreichem Test: alte Version entfernen
systemctl disable --now php8.2-fpm
apt purge 'php8.2*'

Bei mehreren virtuellen Hosts mit unterschiedlichen Anforderungen kann jede Site über einen eigenen SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost"-Eintrag gezielt auf eine Version gelegt werden. So lassen sich Sites einzeln migrieren.

Fallstricke aus der Praxis

Compliance-Bezug

Der Betrieb nicht mehr unterstützter Software ist in allen gängigen Regelwerken ein Befund:

• BSI IT-Grundschutz: OPS.1.1.3 Patch- und Änderungsmanagement sowie APP.3.2 Webserver und APP.3.1 Webanwendungen und Webservices verlangen zeitnahe Sicherheitsupdates und den Verzicht auf Software ohne Herstellerunterstützung.
• NIS2: Art. 21 Abs. 2 Buchst. e der NIS2-Richtlinie fordert Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen einschließlich Umgang mit Schwachstellen. Ein bekannter, ungeplanter Supportverlust ist hier kaum zu begründen.
• CIS Controls v8: Safeguard 2.2 („Ensure Authorized Software is Currently Supported“) und Control 7 (Continuous Vulnerability Management).
• ISO/IEC 27001:2022: Anhang A 8.8 (Umgang mit technischen Schwachstellen).

Fazit

Das Supportende von PHP 8.2 kommt nicht überraschend, wird aber in vielen Umgebungen übersehen, weil PHP selten als eigenes Produkt im Inventar steht. Der Weg ist überschaubar: alle Installationen finden, Zielversion PHP 8.4 (oder 8.5 mit Herstellerfreigabe) wählen, auf einer Kopie testen, parallel installieren, umschalten und die alte Version vollständig entfernen. Wer jetzt startet, ist vor dem Jahreswechsel fertig – und hat mit PHP 8.4 bis Ende 2028 Ruhe.

Quellen: php.net – Supported Versions · PHP-Handbuch – Installation unter IIS · WordPress – Requirements · The Hacker News – CVE-2024-4577 · windows.php.net – Downloads