Die öffentliche Website gehört in die Updatefrage

Welche unserer öffentlich erreichbaren Anwendungen muss jetzt jemand mit dem Dienstleister prüfen?

Diese Frage will die Leitung bewusst nicht mit zusätzlicher Unruhe belasten, solange noch unklar ist, ob überhaupt ein Problem besteht. Sie verlangt keine technische Ferndiagnose und auch keine Entscheidung über ein Update am Telefon. Sie richtet sich an eine öffentliche Website, ein Kundenportal oder eine andere Anwendung, die Menschen von außen erreichen können: Wer klärt ihren Pflegeweg mit dem Dienstleister?

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen. Die Meldung nennt Installationen, die Webanfragen bedienen, als betroffenen Bereich. Das ist ein Anlass, die eigene Übersicht hervorzuholen oder erstmals anzulegen. Es ist kein Beleg dafür, dass die Website oder ein Portal Ihres Betriebs PHP nutzt, ungepflegt ist oder angegriffen wurde.

Ruhe ist ein guter Grund, keine Antwort

Dahinter steht kein Wegsehen. Die Leitung will, dass der Betrieb ruhig arbeiten kann und aus jeder technischen Meldung kein neues Projekt wird. Der Admin oder IT-Dienstleister will die Systeme am Laufen halten.

Zwischen diesen beiden Perspektiven liegt eine konkrete Betriebsfrage: Welche Anwendung ist von außen erreichbar, wer betreibt sie technisch, und wer bestätigt bei einer Herstellerwarnung den Pflegeweg? Bleibt diese Frage offen, kann die frühere Ruhe sie nicht beantworten. Sie sagt nur, dass bisher kein Anlass im Betrieb sichtbar geworden ist.

Was die PHP-Meldung tatsächlich hergibt

Das PHP-Projekt beschreibt in seiner Meldung vom 21. Oktober Sicherheitsupdates für PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Es nennt zwei kritische Schwachstellen, die unauthentifizierte Remote-Code-Ausführung ermöglichen können. Betroffen sind laut Projekt PHP-Installationen, die Webanfragen bedienen, etwa mit PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed.

Die Information trägt eine betriebliche Frage, aber kein Urteil über den eigenen Betrieb. Sie sagt nicht, ob Ihre öffentliche Website auf einer dieser Installationen läuft. Sie sagt auch nicht, was der Vertrag mit Ihrem Dienstleister umfasst oder ob eine Aktualisierung dort bereits geschehen ist. Wer daraus eine Gefährdung der eigenen Website ableitet, lässt genau die Klärung aus, die jetzt noch fehlt.

Die Leitung muss dafür keine PHP-Version beurteilen. Sie muss auch nicht aus einer Herstellerwarnung eine Schuldfrage für den Dienstleister machen. Ihre Aufgabe ist enger: eine Person im Betrieb hält die Frage, der Dienstleister kann für die betreffende Anwendung die technische Rückmeldung geben. So bleibt bei einer Meldung sichtbar, wer auf welcher Seite antwortet und welche Information noch fehlt.

Das kann auch zeigen, dass die Website bei einem anderen technischen Betreiber liegt oder dass mehrere Anwendungen unterschiedliche Pflegewege haben. Daraus folgt noch keine Bewertung. Es verhindert lediglich, dass die Sicherheitsmeldung an eine allgemeine Adresse geht und niemand die Anwendung zuordnen kann, um die es tatsächlich geht.

Wie ich das sehe: Vorsorge beginnt hier damit, die offene Pflegefrage sichtbar zu machen. Die frühere Ruhe belegt nicht, dass heutige Zugänge und vereinbarte Pflegewege noch zusammenpassen. Der Dienstleister kann den technischen Status erklären. Die Geschäftsführung muss entscheiden, wer die Frage im Betrieb hält und welche Rückmeldung sie erwartet.

Wenn Sie gerade den Umgang mit angekündigten Produktlebenszyklen sortieren, hilft Ihnen auch der Impuls Das Supportende gehört auf den Tisch. Bei einer aktuellen Herstellerwarnung geht es vorher um die Übersicht, welche Anwendung welchem Pflegeweg zugeordnet ist.

Wenn Leitung und Dienstleister diese Übersicht gemeinsam brauchen, kann eine gemeinsame Bestandsaufnahme mit Admin oder Dienstleister helfen. Danach kennen beide Geräte, Zugänge und Zuständigkeiten auf einem gemeinsamen Stand. Das Erstgespräch führt Michael vorher mit der Leitung allein.

Eine Liste für die offene Pflegefrage

Nehmen Sie diese Woche mit Admin oder IT-Dienstleister einen Termin für die öffentlich erreichbaren Anwendungen. Die Geschäftsführung benennt dafür eine intern entscheidungsfähige Person. Auf eine kurze Liste kommen Website, Kundenportal oder andere Anwendungen, die von außen erreichbar sein können. Zu jeder Anwendung halten Sie Zweck, technischen Betreiber und Pflegeweg fest. Dann fragen Sie, ob PHP eingesetzt wird und wer einen aktuellen Update- oder Paketstatus bestätigen kann.

Vier Fragen reichen für den Anfang:

• Welche Anwendungen sind von außen erreichbar?
• Wer betreibt jede Anwendung technisch?
• Wer bestätigt den Pflege- oder Paketstatus?
• Wen informiert der Dienstleister bei einer kritischen Herstellerwarnung, und wer entscheidet dann im Betrieb?

Diese Liste ist eine Arbeitsgrundlage, keine vollständige Methode und keine Patch-Anweisung. Sie kostet einen Termin und kann offenlegen, dass bei einer Anwendung noch niemand klar benannt ist. Danach können Sie sagen, welche öffentlich erreichbare Anwendung welchem Pflegeweg zugeordnet ist und welche Rückmeldung noch fehlt.

Sie ersetzt keine technische Prüfung und trifft keine Aussage über eine konkrete Betroffenheit.

Für die wiederkehrende Frage, wie technische Betreuung und betriebliche Verantwortung zusammenpassen, lesen Sie auch Die Firewall mit Werkseinstellungen. Dort geht es um ein Gerät, hier um den Pflegeweg einer Anwendung. Wer hält die Liste bei Ihnen so, dass eine Herstellerwarnung die richtige Person erreicht?

Quellen

• php.net

---

Michael Höner ist IT-Architekt und strategischer Sparringspartner für den Mittelstand. Er berät Unternehmen in NRW und bundesweit zu IT-Sicherheit, KI-Verantwortung und digitaler Architektur, ohne Produktprovisionen und ohne Implementierungsmandat.

Beitragsbild: KI-generiertes Bild.