PHP-Systeme im Unternehmen finden: So erstellen Sie ein vollständiges Inventar

Die Agentur hat vor drei Jahren die Unternehmenswebsite auf WordPress aufgesetzt. Irgendwann später kam der Onlineshop hinzu, betreut von einem anderen Dienstleister, gehostet auf einem anderen Server. Das interne Buchungsportal läuft noch auf einem dedizierten Hosting-Paket, das mal der frühere IT-Leiter angelegt hat. Und das Kundenformular auf der alten Subdomain? Niemand weiß mehr genau, wer das betreut.

Dieses Szenario ist im deutschen Mittelstand keine Ausnahme. Es ist die Regel. PHP-basierte Systeme entstehen über Jahre, über verschiedene Dienstleister und Hosting-Verträge — und niemand besitzt am Ende ein vollständiges Bild, was wo läuft, in welcher Version und wer dafür verantwortlich ist.

Das blieb lange ein organisatorisches Ärgernis ohne unmittelbare Konsequenz. Seit dem 21. Oktober 2026 ist es ein handfestes Sicherheitsproblem: Das PHP-Projekt hat zwei kritische Schwachstellen veröffentlicht — CVE-2026-109618 und CVE-2026-109619 — die eine nicht authentifizierte Remote-Code-Ausführung ermöglichen. Betroffen sind alle PHP-Versionen unter 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Wer seine PHP-Systeme nicht kennt, kann sie nicht patchen.

Warum ein unvollständiges PHP-Inventar ein geschäftliches Problem ist

Ein nicht erfasstes System entzieht sich systematisch drei Dingen: Monitoring, Backup und Verantwortlichkeit. Das klingt abstrakt, hat aber konkrete Folgen.

Ein nicht überwachtes System fällt aus, ohne dass eine Alarmmeldung ausgeht. Ein System ohne Backup verliert bei einem Sicherheitsvorfall Daten unwiederbringlich. Ein System ohne klare Verantwortlichkeit wird nicht gepatcht — nicht weil niemand es könnte, sondern weil niemand weiß, dass er es tun müsste.

Die aktuellen CVEs illustrieren das Risiko scharf. CVE-2026-109618 („RCE via OOM corruption", CVSS v4.0: 9.2) beschreibt, wie PHP bei Speichermangel einen Request per longjmp() abbricht und dabei ungültigen Zustand hinterlässt, der beim Request-Ende weiterverwendet wird. Für Apache mod_php ist eine Remote-Code-Ausführung über HTTP mit Standardlimits demonstriert. CVE-2026-109619 („RCE via stale global state", CVSS v4.0: 9.2) nutzt einen Use-after-free im globalen Worker-Zustand — zwei aufeinanderfolgende Requests an denselben Worker reichen aus. Für Apache mod_php und PHP-FPM sind Angriffspfade validiert.

Das Sicherheitsunternehmen watchTowr meldet nach eigenen Angaben beobachtete Ausnutzung in seinem Honeypot-Netz seit dem 21. Oktober 2026. In Fachmedien kursiert der Name „PHP2Shell" für diese Angriffskampagne.

Die einzige vollständige Abhilfe ist das Update auf eine der gepatchten Versionen — PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 — und anschließender Neustart aller PHP-Worker. Wer die Systeme nicht kennt, kann diesen Schritt nicht ausführen.

Für PHP 8.1 und ältere Versionen liefert das PHP-Projekt keine offiziellen Updates mehr. Das PHP-Security-Team hat minimale Quell-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht; ob und wann Hoster und Distributionen diese einspielen, ist individuell verschieden. Für PHP 5 gibt es keinen Patch.

Was ein vollständiges PHP-Inventar enthält

Das Ziel ist nicht eine einfache Versionsliste. Ein belastbares PHP-Inventar dokumentiert für jedes System mindestens:

Diese Felder entscheiden darüber, welche Systeme sofort gepatcht werden können, welche einen Abstimmungsprozess mit einem Dienstleister erfordern und welche abgeschaltet oder migriert werden müssen.

Wo PHP-Systeme im Unternehmen tatsächlich auftauchen

Viele IT-Verantwortliche denken beim Thema PHP zuerst an die Unternehmenswebsite. Das greift zu kurz. Diese Kategorien werden häufig übersehen:

CMS-Installationen: WordPress ist mit Abstand die häufigste PHP-Anwendung im Mittelstand — oft nicht nur für die Hauptdomain, sondern auch für Microsites, Kampagnenseiten oder Eventpages, die eine Agentur eigenständig aufgesetzt hat. Jede dieser Installationen hat eine eigene PHP-Laufzeitumgebung. Wie man die WordPress-Sicherheit systematisch behandelt, ist ein eigenes Thema; hier geht es darum, zunächst alle Instanzen zu kennen.

Onlineshops: WooCommerce läuft auf PHP, Magento 2 läuft auf PHP, OpenCart und viele ältere Shopsysteme ebenfalls. Shops wurden oft von Dienstleistern auf deren bevorzugten Hosting-Plattformen aufgesetzt und laufen dort autonom weiter, auch wenn der Dienstleister längst gewechselt wurde.

Kundenportale und Intranets: Viele dieser Systeme wurden einmalig gebaut, in Betrieb genommen und danach nur noch gepflegt, wenn ein sichtbares Problem auftrat. PHP-Updates fallen dabei regelmäßig hinten über. Gerade ältere Portale, die auf PHP 7.x oder gar 5.x laufen, sind heute nicht mehr patchbar.

Fachanwendungen von Drittanbietern: Branchensoftware, die über einen Webbrowser bedient wird und auf einem selbst gemieteten Server läuft, verwendet häufig PHP im Backend. Anbieter spezifischer Branchenlösungen arbeiten teils mit eingefrorenen PHP-Versionen, weil ihre Software sonst nicht kompatibel ist.

Hosting-Pakete mit Altbestand: Wenn ein Unternehmen über die Jahre Domains gesammelt hat, liegen auf manchen Paketen noch Installationen aus vergangenen Projekten — Test-Instanzen, alte Landingpages, Redirect-Setups mit kleinen PHP-Skripten. Diese werden selten aktiv gewartet.

Appliances und eingebettete Systeme: Manche Netzwerkgeräte, NAS-Systeme oder interne Dienste stellen Konfigurationsoberflächen über PHP bereit. Diese sind häufig öffentlich nicht erreichbar, aber intern angreifbar und werden bei Patchzyklen komplett ignoriert.

Schatten-IT: Einzelne Abteilungen oder Mitarbeiter haben PHP-Anwendungen auf Shared-Hosting-Paketen installiert, die der IT-Abteilung unbekannt sind. Ein häufiges Muster: ein Buchungskalender, ein einfaches Formular-Tool oder ein kleiner Passwort-geschützter Bereich, den die Marketingabteilung vor Jahren aufgesetzt hat. Shadow IT bei Websites und Webanwendungen ist ein strukturell unterschätztes Risiko.

PHP-Systeme im Unternehmen finden: der methodische Ablauf

PHP-Anwendungen finden sich nicht durch eine einzige Abfrage. Die Inventarisierung kombiniert mehrere Quellen, weil keine davon vollständig ist.

1. DNS und Domainverzeichnis auswerten

Der erste Schritt ist eine vollständige Liste aller Domains und Subdomains, die das Unternehmen besitzt oder betreibt. DNS-Records (A, AAAA, CNAME) zeigen, welche Hostnamen aktiv auf Server zeigen. Tools wie dig, Zonenexporte beim Registrar oder Dienste wie Screaming Frog können dabei helfen, unbekannte Subdomains sichtbar zu machen.

Wichtig: Auch intern aufgelöste Hostnamen (intranet.firma.local, erp.intern) müssen erfasst werden. Diese sind nicht öffentlich erreichbar, aber im internen Netzwerk angreifbar.

2. Hosting-Verträge und Rechnungen prüfen

Buchhaltungs- und Einkaufsunterlagen zeigen, welche Hosting-Verträge aktiv sind und bei welchen Anbietern. Jeder aktive Vertrag ist ein potenzielle PHP-Umgebung. Relevante Anbieter sind Shared-Hosting-Plattformen (Ionos, Strato, All-Inkl.), dedizierte Server bei Hetzner, AWS, Azure oder Google Cloud, sowie Managed-Hosting-Angebote spezialisierter Agenturen.

Bei Anbietern wie Plesk-basierten Hostern bieten Hoster teilweise eigene Backport-Patches an — Plesk hat für CVE-2026-109618 und CVE-2026-109619 eigene Kundeninformationen veröffentlicht. Diese Patches ersetzen jedoch kein Upgrade auf eine gepatchte PHP-Version und müssen individuell geprüft werden.

3. Technische Erkennung auf Servern

Auf Servern, auf die direkter Zugriff besteht (SSH, Control Panel), gibt php -v die installierte Version aus. Auf Systemen mit mehreren PHP-Versionen (typisch bei Managed-Hosting-Umgebungen) müssen alle Versionen geprüft werden, nicht nur die systemweite Standardversion.

Für die SAPI-Erkennung: php -r "echo php_sapi_name();" gibt den aktiven Interface-Typ zurück. Das ist relevant, weil sich der Angriffspfad für CVE-2026-109618 je nach SAPI unterscheidet — für Apache mod_php ist RCE demonstriert, für PHP-FPM, FrankenPHP und LSAPI gilt voraussichtliche Anfälligkeit auf Basis der Quellcodeanalyse, ein vollständiger Exploit ist dort nicht demonstriert.

4. phpinfo() und öffentliche Informationslecks prüfen

Manche Installationen lassen noch eine phpinfo()-Seite öffentlich zugänglich — das gibt einem Angreifer detaillierte Informationen über die Serverumgebung. Wer die eigenen Domains scannt, findet solche Lecks manchmal auf alten Testinstallationen oder vergessenen Entwicklungsumgebungen. Diese Seiten gehören sofort entfernt.

5. Anfrage bei Agenturen und Dienstleistern

Für alle extern verwalteten Systeme müssen Dienstleister aktiv nach PHP-Versionen und Patchstatus befragt werden. Eine strukturierte Anfrage sollte enthalten: Welche PHP-Version läuft aktuell? Wer ist für das Update zuständig? Bis wann erfolgt das Update auf eine gepatchte Version?

Die Antwort klärt nicht nur die technische Situation, sondern auch die Verantwortlichkeit: Wenn ein Managed-Hosting-Anbieter automatisch patcht, ist der Aufwand gering. Wenn der Vertrag nur reines Infrastruktur-Hosting vorsieht, liegt das Update beim Unternehmen oder der Agentur.

6. Agenturprojekte und Altverträge erfassen

Besonders kritisch sind Systeme, die von einer früheren Agentur gebaut und übergeben wurden, ohne dass ein klarer Wartungsvertrag existiert. Diese Systeme laufen oft auf Hosting-Paketen, die auf den früheren Dienstleister ausgestellt waren, oder auf Accounts, zu denen das Unternehmen selbst keinen vollständigen Zugang hat. Hier braucht es eine aktive Bestandsaufnahme: Welche Projekte haben wir in den letzten fünf Jahren von Agenturen erhalten? Wo sind diese Systeme heute?

Praxisbeispiel: Hypothetisches Mittelstandsunternehmen

Ein produzierendes Unternehmen mit 80 Mitarbeitern beauftragt eine technische Inventarisierung. Im Ergebnis tauchen auf:

• Die Hauptwebsite auf WordPress, bei Hoster A, PHP 8.3.34 — knapp unterhalb der gepatchten Version 8.3.36
• Ein WooCommerce-Shop auf Hoster B, PHP 8.1.29 — außerhalb des offiziellen PHP-Supports, Backport vom Hoster erforderlich
• Ein Kundenportal auf einem dedizierten Server bei Hoster C, PHP 7.4 — kein Patch verfügbar, Abschalten oder Firewall-Isolation erforderlich
• Drei vergessene WordPress-Installationen für abgelaufene Kampagnen, alle auf PHP 8.2.x, davon zwei unterhalb von 8.2.35
• Eine Buchungsseite, die eine frühere Agentur auf deren eigenem Hosting betreibt — PHP-Version unbekannt, kein direkter Zugang

Das Ergebnis ist eine priorisierte Liste: Sofort patchen, sofort isolieren, Dienstleister kontaktieren. Ohne die Inventarisierung wären vier dieser fünf Kategorien vollständig unsichtbar geblieben.

Wie PHP-Versionen die Handlungsoptionen bestimmen

Nicht jedes Update läuft gleich ab. Die Supportzeiträume laut php.net bestimmen, welche Pfade offenstehen:

PHP 8.2 läuft am 31. Dezember 2026 in den End-of-Life-Status. Wer heute noch auf 8.2 patcht, sollte die Migration auf 8.3 oder 8.4 parallel planen, um in zwei Monaten nicht wieder in dieser Situation zu stecken.

Partial-Maßnahmen wie das Erzwingen von memory_limit=-1, konservative post_max_size-Werte oder das Blockieren von Multipart-Anfragen am Reverse Proxy können das Angriffsfenster laut PHP-Advisory verkleinern. Sie sind jedoch kein vollständiger Schutz und ersetzen das Update nicht. Für Systeme, auf denen session.upload_progress.enabled=0 gesetzt ist, reduziert sich ein Angriffspfad für CVE-2026-109619 — das PHP-Projekt empfiehlt diese Einstellung auch nach dem Patch, wenn die Funktion nicht genutzt wird.

Was nach der Inventarisierung zu tun ist

Ein vollständiges Inventar ist kein Selbstzweck. Der Wert entsteht durch die strukturierte Maßnahmenliste, die daraus folgt.

Sofortmaßnahmen (innerhalb von 24–72 Stunden): Alle öffentlich erreichbaren Systeme auf unterstützten PHP-Versionen auf die gepatchten Releases aktualisieren und alle PHP-Worker neu starten. Systeme auf PHP 8.1 und älter sofort prüfen: Gibt der Hoster einen Backport-Patch? Falls nicht, ist eine Firewall-Isolation oder Abschaltung die sicherere Option.

Kurzfristige Maßnahmen (ein bis vier Wochen): Für Systeme, bei denen Dienstleister zuständig sind, verbindliche Patchtermine schriftlich vereinbaren. Vergessene oder verwaiste Installationen außer Betrieb nehmen oder in eine verwaltete Umgebung überführen. Zugangsdaten für Systeme sicherstellen, auf die bisher kein direkter Zugriff besteht.

Mittelfristige Maßnahmen (ein bis drei Monate): Systeme auf PHP 8.2 auf 8.3 oder 8.4 migrieren, bevor der Support zum 31. Dezember 2026 ausläuft. Ein dauerhaftes Inventarisierungsverfahren etablieren, damit neue Systeme automatisch erfasst werden. Wartungsverantwortlichkeiten vertraglich klären — wer patcht was, in welchem Zeitfenster?

Warum Selbst-Inventarisierung an Grenzen stößt

Für Unternehmen mit einem klaren, kleinen und selbst verwalteten Setup ist die Inventarisierung gut eigenständig machbar. Je mehr externe Dienstleister, Hosting-Plattformen und historisch gewachsene Systemlandschaften beteiligt sind, desto schneller entstehen blinde Flecken.

Typische Hürden: fehlender SSH-Zugang zu extern verwalteten Systemen, Dienstleister, die auf Anfragen zu PHP-Versionen nicht oder vage antworten, Installationen auf Hosting-Accounts, die auf ehemalige Mitarbeiter oder frühere Agenturen ausgestellt sind, und interne Fachanwendungen, deren Quellcode und Betriebsdokumentation nicht mehr vorhanden sind.

An dieser Stelle ist externe Unterstützung kein Zeichen von Schwäche, sondern eine pragmatische Entscheidung: Ein IT-Dienstleister mit Erfahrung in technischen Bestandsaufnahmen bringt die methodischen Abläufe, die Werkzeuge und die Gesprächsroutinen mit Hostern und Agenturen bereits mit. Das spart Zeit in einer Situation, in der Zeit knapp ist. Wie ein dauerhaftes Managed IT-Service-Modell dabei helfen kann, solche Inventarisierungen strukturell zu verankern, ist ein eigenes Thema — relevant wird es dann, wenn die heutige Bestandsaufnahme nicht die letzte sein soll.

Eine vollständige technische Anwendungs- und Hosting-Inventur mit priorisierter Maßnahmenliste kann helfen, alle PHP-basierten Dienste mit Eigentümer, Versionsstand, Betriebsort, Exposition und nächstem Wartungsschritt zu erfassen — und die Entscheidungsgrundlage zu schaffen, die für ein koordiniertes Patchen notwendig ist.

Für kritische PHP-Schwachstellen wie CVE-2026-109618 und CVE-2026-109619 gilt: Wer jetzt alle betroffenen Systeme kennt, kann die Risiken systematisch abarbeiten. Wer das Inventar aufschiebt, patcht möglicherweise nur die sichtbaren Systeme — und lässt die verwaisten offen. Mehr zu den Schwachstellen selbst und zur Priorisierung der Patchstrategie zeigt der Artikel zu kritischen PHP-Sicherheitslücken richtig priorisieren.

Was einen guten PHP-Inventarisierungsprozess dauerhaft trägt

Einmalige Inventarisierungen lösen das heutige Problem. Neue Systeme entstehen aber kontinuierlich — jede neue Website, jede neue Webanwendung, jedes neue Hosting-Paket ist ein potenzielle blinder Fleck in sechs Monaten.

Ein dauerhafter Prozess braucht drei Dinge: ein zentrales Inventarverzeichnis (auch eine gepflegte Tabelle reicht, wenn sie vollständig und aktuell ist), eine klare Regel, wann ein neues System eingetragen wird, und eine Routine, die das Inventar mindestens quartalsweise gegen aktive DNS-Records und Hosting-Verträge abgleicht.

Die IT-Sicherheit im Betrieb verbessert sich nicht durch bessere Absichten, sondern durch bessere Prozesse. Ein vollständiges PHP-Inventar ist einer der konkreteren und pragmatischeren Schritte, die ein mittelständisches Unternehmen ohne große Investition umsetzen kann — vorausgesetzt, jemand setzt ihn an den Anfang.

Autor: Steven Weißheimer, SW Business Solutions. Dieser Artikel basiert ausschließlich auf verifizierten Fakten aus den genannten Quellen (Stand: 22. Oktober 2026). Einschätzungen zu Angriffspfaden jenseits der explizit belegten Demonstrationen sind als solche gekennzeichnet.