21. Oktober 2026 | PHP | IT-Sécherheet
Den 21. Oktober 2026 huet d'PHP-Sécherheetsteam Updates fir all nach ënnerstëtzte PHP-Versiounen verëffentlecht. Si schléissen zwou kritesch Schwaachstellen, déi als PHP2Shell bekannt gi sinn. D'BSI huet dozou eng Warnung erausginn a verlaangt, betraff Systemer onverzüglech ze patchen. Wien e Webserver mat PHP bedreift, sollt haut nach handelen. Dat gëllt och fir all déi, déi „just“ e WordPress, Nextcloud oder Joomla bedreiwen, well dës Applikatiounen op PHP lafen.
Dëse Bäitrag fässt zesummen, wat geschitt ass, wéi eng PHP-Versioune betraff sinn, wéi eng Versioun Dir elo braucht an wéi Dir a wéinege Minutte préift, ob Äre Server ofgesécher ass.
Inhalt vun dësem Bäitrag
- Wat ass geschitt? Den zäitlechen Oflaf
- Déi zwou PHP-Schwaachstellen am Iwwerbléck
- Wien ass betraff?
- Dës PHP-Versioune sinn sécher
- Sou préift an aktualiséiert Dir Äre Server
- PHP 8.1 an eeler: kee offiziellen Update
- Iwwergangsmoossnamen an d'Fro „Server offline huelen?“
- Heefeg Froen
- Ënnerstëtzung duerch Biricon IT Services
Wat ass geschitt? Den zäitlechen Oflaf
D'PHP-Sécherheetsteam huet d'Verëffentlechung vun de Korrekture vireg ugekënnegt, fir datt Hoster an Administrateuren Zäit haten, sech virzebereeden. D'Verëffentlechung selwer huet den 21. Oktober 2026 stattfonnt. D'BSI huet nach um selwechten Dag hir Warnung (Versioun 1.1) erausginn.
- 20. Oktober 2026: Viirwarnung vum PHP-Sécherheetsteam, datt um Folgedag Sécherheetsupdates erscheinen.
- 21. Oktober 2026, 14:00 UTC (16:00 Auer MESZ): D'Patches fir PHP 8.5, 8.4, 8.3 an 8.2 ginn verëffentlecht.
- 21. Oktober 2026: D'BSI warnt virun de „kriteschen Schwaachstellen, déi Webapplikatiounen weltwäit bedrohen“, an empfielt, onverzüglech ze patchen. No Angabe vun der BSI hunn grouss Hosting-Ubidder zum Deel Server virsuergend offline geholl.
Déi zwou PHP-Schwaachstellen am Iwwerbléck
Et handelt sech em zwee getrennte Feeler am PHP-Kär: CVE-2026-109618 an CVE-2026-109619. Béid kënnen no den Angabe vum PHP-Sécherheetsteam dozou féieren, datt en Ugräifer Programmcode um Server ausféiere kann, ouni sech unzemellen (unauthenticated Remote Code Execution). D'Schwaachstelle ginn mat CVSS v4.0: 9,2 (kritesch) bewäert.
| Charakteristik | Bedeitung |
|---|---|
| Kennungen | CVE-2026-109618 an CVE-2026-109619 |
| Bewäertung | CVSS v4.0: 9,2 — kritesch |
| Auswierkung | Ausféiere vu Code um Server (Remote Code Execution), ouni Umeldung |
| Ursaach 1 | Beschiedegte Späicher, wann PHP während der Veraarbechtung keen Aarbechtsspäicher méi kritt (Out-of-Memory) |
| Ursaach 2 | Veralten globalen Zoustand, deen tëscht Ufroe am Späicher stoe bleift |
| Besonnesch gefäerdet | Apache mat mod_php |
No Aschätzung vun der BSI gouf et zum Zäitpunkt vun der Verëffentlechung keng bestätegt Ugrëffer, et gouf awer onbestätegt Hiweiser op Ausnotzungsversich. Bei kriteschen Lücken an enger sou wäit verbreeter Software ass erfahrungsgemäss domat ze rechnen, datt Ugräifer d'Korrekture analyséieren an automatiséiert Ugrëffer virbereeden. D'Zäitfënster zum Patchen ass dofir kuerz.
Wien ass betraff?
Betraff ass grondsätzlech all Server, op deem PHP leeft, onofhängeg dovun, wéi PHP ugebonne ass: PHP-FPM, mod_php am Apache, php-cgi, FrankenPHP oder LiteSpeed. Am héchste ass d'Risiko laut PHP-Sécherheetsteam bei Apache mat mod_php.
D'BSI nennt ausdrécklech Applikatiounen, déi op PHP opbauen an dofir matbetraff kënne sinn:
- Content-Management-Systemer: WordPress, Drupal, TYPO3, Joomla
- Shopsystemer: Magento
- Cloud- an Dateiablag: Nextcloud
- Firewall-Uewerflächen: pfSense, OPNsense
D'Applikatioun selwer muss dofir net feelerhaft sinn. D'Lück läit a PHP, dofir hëlleft en Update vu WordPress, Nextcloud & Co. eleng net. Et muss d'PHP-Versioun um Server aktualiséiert ginn. Bei Firewalls wéi pfSense an OPNsense kënnt déi korrigéiert PHP-Versioun iwwer dem Hiersteller säin jeeweilegt Firmware-Update.
Dës PHP-Versioune sinn sécher
D'Schwaachstelle sinn an de folgende Versioune behuewen. Alles doranner gëllt als verwonnbar.
| PHP-Zweig | Mindestens erfuerderlech | Hiweis |
|---|---|---|
| PHP 8.5 | 8.5.12 | aktuellen Zweig |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Support ännert um 31. Dezember 2026 |
| PHP 8.1 an eeler | kee offiziellen Update, kuckt ënnen | |
Sou préift an aktualiséiert Dir Äre Server
1. Installéiert PHP-Versioun feststellen
Op der Kommandozeil vum Server weist php -v d'Versioun vun der Kommandozeilen-PHP. De Webserver ka eng aner PHP-Versioun benotzen. Préift dofir och d'Versioun vu PHP-FPM bzw. vum Apache-Modul, zum Beispill mat php-fpm8.3 -v oder iwwer eng Säit, déi phpinfo() ausgëtt (déi duerno direkt erëm ewechhuelen).
2. Update iwwer d'Paketverwaltung andrénge loossen
Bei Debian, Ubuntu, RHEL a Verwandten kënnt déi korrigéiert Versioun iwwer déi normal Paketverwaltung, zum Beispill apt update && apt upgrade oder dnf upgrade. Bei Friemquellen wéi dem Sury-PPA oder dem Remi-Repository erschéngen déi nei Paketer meeschtens zäitno.
apt changelog php8.3-fpm oder rpm -q --changelog php | grep CVE-2026-1096).
3. PHP-Déngscht nei starten
E Paketupdate eleng geneegt net: lafend PHP-Prozesser behalen den ale Code am Späicher. Startet PHP-FPM (systemctl restart php8.3-fpm) bzw. Apache (systemctl restart apache2) nei, a préift duerno, ob d'Prozesser nom Update gestart goufen.
4. Gehostet Websäiten
Bei Shared Hosting aktualiséiert normalerweis den Ubidder. Am Clientemenü léisst sech meeschtens d'PHP-Versioun pro Websäit astellen. Wielt do eng vun de uewe genannte séchere Versiounen, oder frot beim Ubidder no dem Stand vun de Patchen. No Angabe vun der BSI hunn eenzel Ubidder Server virsuergend vum Netz geholl. Falls Är Säit kuerz net erreechbar ass, ka dat d'Ursaach sinn.
PHP 8.1 an eeler: kee offiziellen Update
Fir PHP 8.1 an eeler gëtt et keng offiziell Sécherheetsupdates méi. Bedreiwer vun esou Systemer hunn zwou Méiglechkeeten:
- Op eng ënnerstëtzt Versioun wiesselen (recommandéiert). Wat d'Versioun méi aal ass, wat den Upassungsopwand fir Applikatioun an Erweiderunge méi grouss ass, dofir sollt e Wiessel virdrun getest ginn.
- Korrekturen zeréckportéieren. D'PHP-Sécherheetsteam huet d'Korrekture an Entwécklungszweige op GitHub zur Verfügung gestallt. Wien PHP selwer kompiléiert, ka dës Ännerungen a méi al Versioune iwwerhuelen. Dat ass eng Iwwergangsléisung a verlaangt Fachwëssen.
Och PHP 8.2 ass nëmmen nach bis den 31. Dezember 2026 ënnerstëtzt. Plangt de Wiessel op PHP 8.4 oder 8.5 dofir elo an, a verschibt en net op de Joreswiessel.
Iwwergangsmoossnamen an d'Fro „Server offline huelen?“
D'PHP-Sécherheetsteam huet mat der Ukënnegung och virleefeg Schutzmoossnamen beschriwwen. Dës reduzéieren d'Risiko, schléisse d'Lücken awer net vollstänneg. Si ersetzen den Update net a sinn nëmmen dofir geduecht, d'Zäit bis zum Update ze iwwerbrécken.
Ob e Server bis zum Update vum Netz geholl soll ginn, hänkt vu senger Bedeitung a senger Erreechbarkeet of. D'BSI féiert aus, datt grouss Ubidder dëse Schrëtt gaange sinn. Als Faustregel gëllt:
- Ëffentlech erreechbare Server, Update elo méiglech: direkt patchen, kee Ofschalten néideg.
- Ëffentlech erreechbare Server, Update net kuerzfristeg méiglech: Zougrëff aschränken (zum Beispill per Firewall just fir bekannt Adressen) oder den Déngscht temporär ofschalten, besonnesch bei
mod_php. - Just intern erreechbare Server: zäitno patchen, d'Dringlechkeet ass méi kleng.
Heefeg Froen
Muss ech WordPress, Joomla oder Nextcloud aktualiséieren?
Net wéinst dëser Lück. Si läit am PHP, net an der Applikatioun. Aktualiséiert d'PHP-Versioun um Server. Een Update vun der Applikatioun ass onofhängeg dovun trotzdem sënnvoll.
Wéi erkennen ech, ob een d'Lück scho ausgenotzt huet?
Eng sécher Ausso ass schwéier. Opfälleg sinn onbekannte PHP-Dateien am Webverzeechnes, ongewéinlech Prozesser ënner dem Webserver-Benotzer, nei Benotzerkonten oder Cronjobs an ongewéinlechen ausgoenden Datenverkéier. Bei engem konkrete Verdacht sollt de System forensesch iwwerpréift an am Zweifelsfall nei opgesat ginn.
Geet eng Web Application Firewall duer?
Eng Firewall kann bekannten Attackemuster ofänken, ass awer kee Ersatz fir d'Update. Méi iwwert d'Zesummespill vu méi Schutzschichten liest Dir an eisem Bäitrag Odoo 19 absécheren: Firewall, 2FA & Web RBL. D'Grondsätz gëllen fir all Webapplikatioun.
Ass Odoo betraff?
Nee. Odoo ass a Python geschriwwen a leeft net op PHP. Betraff wieren nëmmen PHP-Applikatiounen, déi um selwechte Server lafen.
Wou fannen ech déi offiziell Informatiounen?
D'Ukënnegung vum PHP-Sécherheetsteam fannt Dir an de News-Archiver op php.net (Androung vum 20. Oktober 2026), d'Versioune ënner php.net/downloads. D'Warnung vum BSI huet d'Nummer 2026-297981-1032 an ass op bsi.bund.de publizéiert.
Ënnerstëtzung duerch Biricon IT Services
Wann Dir net sécher sidd, wéi eng PHP-Versioun op Ärem Server leeft, oder Hëllef beim Patche braucht, ënnerstëtzen mir Iech gär: bei der Bestandsopnam vun alle PHP-Systemer, beim Installéiere vun den Updates, beim Ëmstig op eng ënnerstëtzt PHP-Versioun a bei der Kontroll op Kompromittéierung. Als IT-Déngschtleeschter betreie mir Server, Firewalls a Webapplikatiounen fir kleng a mëttelgrouss Betriber.
Stand: 21. Oktober 2026. D'Lag kann sech kuerzfristeg änneren; maassgebend sinn d'Verëffentlechunge vum PHP-Sécherheetsteam a vum BSI.