Bitte hinterlassen Sie Ihre Kontaktdaten, wir senden Ihnen dann unsere Übersicht per E-Mail zu
ch stimme der Verarbeitung meiner persönlichen Daten zu, um personalisiertes Marketingmaterial in Übereinstimmung mit derBitte hinterlassen Sie Ihre Kontaktdaten, wir senden Ihnen dann unsere Übersicht per E-Mail zu geschützt und es gelten. Mit der Bestätigung der Anmeldung erklären Sie sich damit einverstanden, Marketingmaterial zu erhalten
Vielen Dank!

Das Formular wurde erfolgreich abgeschickt.
Weitere Informationen finden Sie in Ihrem Briefkasten.

Daten KI Mobile Finanzwesen Biowissenschaften ERP-System
Innowise logo
Über uns
Leistungen
Technologien
Branchen
Portfolio
Flash hire iconEinstellen Flash hire iconEinstellen
Kontakt Kontakt
DE
So arbeiten wir Qualitätsmanagement Management der Sicherheit Unternehmensverantwortung Führung Unsere Experten Blog Expertentipps
Kundenreferenzen Technische Partner Zertifizierungen Auszeichnungen Veranstaltungen Newsroom
Inhouse- vs. Outsourcing-Softwareentwicklung 2026: Vor- und Nachteile, Kosten und Entscheidungshilfe
Artikel lesen
Umfassende Software-Entwicklungsdienstleistungen
IT-Beratung & Consulting Webentwicklung Mobile-Entwicklung Entwicklung eingebetteter Software Maßgeschneiderte Softwareentwicklung MVP-Entwicklung Cloud-Entwicklung ERP-Entwicklung Mainframe-Support Legacy-Modernisierung
 
UI/UX-Design 3D-Design Softwaretests und QS Sicherheitstests Datenbankverwaltung DevOps DevSecOps Netzwerk IT-Personalaufstockung Dediziertes Team
Implementierung fortschrittlicher Technologien
Big Data Datenmanagement Datenanalyse Daten-Engineering Datenvisualisierung Business Intelligence Maschinelles Lernen Künstliche Intelligenz Data Science Nachhaltigkeit & ESG

Digitale Transformation Geschäftsprozess­automatisierung Robotergesteuerte Prozessautomatisierung Cybersicherheit Internet der Dinge Blockchain NFT Metaverse AR& VR
Frontend
React Angular Vue.js JavaScript
Backend
Java .NET Python PHP Rust C/C++
 
Node.js Unity Ruby Golang Unreal Engine Cobol
Mobile
iOS Android Flutter React Native Xamarin .NET MAUI
 
Swift Kotlin
Cloud
AWS Azure GCP Sharepoint
ERP-System & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Finanzwesen Bankwesen Handel Versicherungswesen E-Commerce Einzelhandel
Gesundheitswesen Pharma Bildungswesen Telekommunikation Medien & Unterhaltung
Großunternehmen Fertigung Automobilindustrie Logistik Transport Marketing Werbung
Staatliche Organisationen Energie & Versorgungsunternehmen Öl & Gas Baugewerbe Immobilien Landwirtschaft Reisen
Fallstudien
Bankwesen Finanzwesen Gesundheitswesen Pharma
E-Commerce Einzelhandel Fertigung Großunternehmen
Unsere Plattformen
Bewerbermanagementsystem (ATS) HRM-System Lernmanagementsystem (LMS) Arbeitsplatzbuchungssystem
Einheitliches KI-Finanz-Betriebssystem für Fiat-Währungen und Kryptowährungen
Fallstudie lesen
Dedizierte Entwickler einstellen
IT-Personalaufstockung Dedizierte Teams Offshore-Entwickler
Webentwickler einstellen
Angular React.js Vue.js JavaScript Ruby on Rails Full-Stack MEAN-Stack
.NET Java PHP Python Golang Cobol
Mobile-Entwickler einstellen
iOS Android Kotlin React Native Swift
Andere Ingenieure einstellen
KI Cloud AWS Azure DevOps QS
Fintech SAP Odoo Salesforce Shopify UiPath
Daten KI Mobile Finanzwesen Biowissenschaften ERP-System
Innowise logo
Über uns
Leistungen
Technologien
Branchen
Portfolio
Flash hire iconEinstellen
Kontakt aufnehmen
de Deutsch

Sprache auswählen

Mobile menu arrow iconÜber uns
Über uns
So arbeiten wir Qualitätsmanagement Management der Sicherheit Unternehmensverantwortung Führung Unsere Experten Blog Expertentipps
Kundenreferenzen Technische Partner Zertifizierungen Auszeichnungen Veranstaltungen Newsroom
Inhouse- vs. Outsourcing-Softwareentwicklung 2026: Vor- und Nachteile, Kosten und Entscheidungshilfe
Artikel lesen
Mobile menu arrow iconLeistungen
Alle Dienstleistungen
Umfassende Software-Entwicklungsdienstleistungen
IT-Beratung & Consulting Webentwicklung Mobile-Entwicklung Entwicklung eingebetteter Software Maßgeschneiderte Softwareentwicklung MVP-Entwicklung Cloud-Entwicklung ERP-Entwicklung Mainframe-Support Legacy-Modernisierung
UI/UX-Design 3D-Design Softwaretests und QS Sicherheitstests Datenbankverwaltung DevOps DevSecOps Netzwerk IT-Personalaufstockung Dediziertes Team
Implementierung fortschrittlicher Technologien
Big Data Datenmanagement Datenanalyse Daten-Engineering Datenvisualisierung Business Intelligence Maschinelles Lernen Künstliche Intelligenz Data Science Nachhaltigkeit & ESG
Digitale Transformation Geschäftsprozess­automatisierung Robotergesteuerte Prozessautomatisierung Cybersicherheit Internet der Dinge Blockchain NFT Metaverse
AR &VR
Mobile menu arrow iconTechnologien
Alle Technologien
Frontend
React Angular Vue.js JavaScript
Backend
Java .NET Python PHP Node.js Unity Ruby Golang Rust C/C++ Unreal Engine Cobol
Mobile
iOS Android Flutter React Native Xamarin .NET MAUI Kotlin Swift
Cloud
AWS Azure GCP Sharepoint
ERP-System & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Mobile menu arrow iconBranchen
Alle Industrien
Finanzwesen Bankwesen Handel Versicherungswesen E-Commerce Einzelhandel
Gesundheitswesen Pharma Bildungswesen Telekommunikation Medien & Unterhaltung
Großunternehmen Fertigung Automobilindustrie Logistik Transport Marketing Werbung
Staatliche Organisationen Energie & Versorgungsunternehmen Öl & Gas Baugewerbe Immobilien Landwirtschaft Reisen
Mobile menu arrow iconPortfolio
Portfolio
Fallstudien
Bankwesen Finanzwesen Gesundheitswesen Pharma
E-Commerce Einzelhandel Fertigung Großunternehmen
Unsere Plattformen
Bewerbermanagementsystem (ATS) HRM-System Lernmanagementsystem (LMS) Arbeitsplatzbuchungssystem
Einheitliches KI-Finanz-Betriebssystem für Fiat-Währungen und Kryptowährungen
Fallstudie lesen
Mobile menu arrow icon Einstellen
Einstellen
Dedizierte Entwickler einstellen
IT-Personalaufstockung Dedizierte Teams Offshore-Entwickler
Webentwickler einstellen
Angular React.js Vue.js JavaScript Ruby on Rails Full-Stack MEAN-Stack .NET Java PHP Python Golang Cobol
Mobile-Entwickler einstellen
iOS Android Kotlin React Native Swift
Andere Ingenieure einstellen
KI Cloud AWS Azure DevOps QS Fintech SAP Odoo Salesforce Shopify UiPath

PHP-Sicherheitscheckliste: 8 Schritte zum Aufspüren und Beheben von Sicherheitslücken

5. November 2026 19 Minuten gelesen
php icon.
Herman Samolazov, Head of Engineering..
Von Herman Samolazov
Leiter von Engineering
Verifizierter Experte
Jeder Artikel bei Innowise stammt von Autoren mit praktischer Erfahrung. Sie verstehen das Thema nicht nur theoretisch, sondern bringen auch Erkenntnisse aus konkreten Projekten ein.
7+ Jahre Erfahrung
Verifizierter Experte
7+ Jahre Erfahrung
Herman leitet Entwicklungsabteilungen und baut die Prozesse, Teamstrukturen und technischen Standards auf, die diese für ihr Wachstum benötigen. Seine Fachkenntnisse umfassen hochbelastbare Backend-Systeme, das Liefermanagement und die Führung von Entwicklungsteams.
Fachwissen
Hochlastsysteme Softwarearchitektur Datenbanken
Vorgestellt in
Medium logo.
Gespräch vereinbaren

Wichtige Erkenntnisse

  • PHP2Shell erfordert dringend ein Patch. Am 21. Oktober 2026 wurden in PHP die Schwachstellen CVE-2026-109618 und CVE-2026-109619 behoben. Beide sind kritische Laufzeit-Sicherheitslücken (CVSS v4.0: 9,2), die die Ausführung von Code aus der Ferne ohne Authentifizierung ermöglichen können.
  • Überprüfen Sie die gepatchten Versionen. Die ersten behobenen Versionen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Linux-Distributionen stellen möglicherweise dieselben Korrekturen über zurückportierte Patches bereit.
  • Priorisieren Sie betroffene PHP-Laufzeitumgebungen. Apache mod_php birgt das höchste gemeldete Risiko, aber auch PHP-FPM und andere webbasierte Konfigurationen erfordern Aufmerksamkeit. Framework-Updates und ein Composer-Audit beheben PHP2Shell nicht.
  • Beschränken Sie sich nicht darauf, PHP zu patchen. Nutzen Sie die achtstufige Checkliste, um Abhängigkeiten, Anwendungscode, Serverkonfigurationen und andere Sicherheitslücken zu überprüfen.
  • Überprüfen Sie die Korrektur in der Produktionsumgebung. Bitten Sie Ihr Team um einen Bericht, aus dem hervorgeht, welche PHP-Builds tatsächlich ausgeführt werden, welche Workloads gepatcht wurden und ob es Anzeichen für eine frühere Kompromittierung gibt.
Artikel mit KI zusammenfassen
Zu den bevorzugten Quellen hinzufügen

Laut W3Techs, PHP wird auf etwa 70 % der Websites eingesetzt, bei denen die serverseitige Sprache bekannt ist. Da PHP so weit verbreitet ist, kann eine Sicherheitslücke im Interpreter viele Websites gefährden, selbst wenn ihr eigener Code sicher ist.

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Notfall-Patches für zwei kritische Sicherheitslücken: CVE-2026-109618 und CVE-2026-109619, die zusammen als PHP2Shell bezeichnet werden. Beide wurden nach CVSS v4.0 mit 9,2 bewertet und ermöglichen die nicht authentifizierte Remote-Codeausführung. Diese Schwachstellen betreffen den internen Speicher und die Anfrageverarbeitung von PHP.

Die ersten Patches wurden in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht. Falls Ihr System eine der betroffenen Versionen verwendet, aktualisieren Sie PHP umgehend und stellen Sie sicher, dass auf Ihrem Webserver die gepatchte Version läuft. Doch damit sollte die Arbeit noch nicht beendet sein. Für Teams, die PHP-Anwendungen entwickeln und warten, darunter auch Innowises PHP-Entwicklungsspezialisten, ist die Veröffentlichung im Oktober zudem ein Anlass, Abhängigkeiten, Anwendungscode und Servereinstellungen zu überprüfen.

In diesem Leitfaden zeige ich Ihnen acht Schritte, mit denen Sie Schwachstellen in Ihrer PHP-Umgebung finden und beheben sowie sicherstellen können, dass Ihre Korrekturen in der Produktion funktionieren.

Sehen Sie sich unsere entsprechenden Dienstleistungen an

Expertenanalyse: Wie sich PHP2Shell von einer gewöhnlichen Abhängigkeits-CVE unterscheidet

Ein anfälliges Composer-Paket betrifft Code, den Ihre Anwendung verwendet. PHP2Shell ist anders. Beide Schwachstellen befinden sich im PHP-Interpreter selbst, und ein Angreifer kann sie auslösen, bevor Laravel, Symfony oder ein anderes Framework überhaupt ausgeführt wird. Das Aktualisieren von CMS-Plugins oder Composer-Abhängigkeiten führt nicht zu einer Korrektur von PHP, und „composer audit“ erkennt diese Laufzeit-Schwachstellen nicht.

Das PHP-Sicherheitsteam identifiziert Apache mod_php als die Konfiguration mit dem höchsten Risiko für CVE-2026-109618, wobei ein Angriff demonstriert wurde, der bereits vor der Ausführung des Anwendungscodes funktioniert. PHP-FPM, CGI und andere Webserver-Konfigurationen sind ebenfalls betroffen, wenngleich die Ausnutzungsbedingungen unterschiedlich sind. Forscher haben zudem die Ausnutzung von CVE-2026-109619 gegen PHP-FPM

demonstriert. Hier ist, was in den einzelnen Fällen schiefgeht:

CVEGrundursacheWarum Teams sich dafür interessieren sollten
CVE-2026-109618Wenn PHP bei der Verarbeitung einer Anfrage nicht mehr über genügend Speicherplatz verfügt, können einige interne Daten in einem ungültigen Zustand verbleiben. Wenn PHP die fehlgeschlagene Anfrage bereinigt, verwendet es möglicherweise diese Daten.Wenn PHP bei der Verarbeitung einer Anfrage nicht mehr über genügend Speicherplatz verfügt, können einige interne Daten in einem ungültigen Zustand verbleiben. Wenn PHP die fehlgeschlagene Anfrage bereinigt, verwendet es möglicherweise diese Daten.
CVE-2026-109619Ein PHP-Worker behält möglicherweise einen Verweis auf Speicherbereich bei, der nach einer früheren Anfrage freigegeben wurde. Wenn der Worker eine weitere Anfrage bearbeitet, versucht er möglicherweise, diesen alten Verweis zu verwenden.Das Problem kann sich zwischen Anfragen, die vom selben Worker bearbeitet werden, übertragen. Eine Überprüfung einzelner Anwendungsanfragen deckt es nicht unbedingt auf.

Beide Schwachstellen können zur Ausführung von Code aus der Ferne ohne Authentifizierung führen. Die Behebung muss in der PHP-Laufzeitumgebung erfolgen, nicht in den Abhängigkeiten der Anwendung.

Eine ausführlichere technische Erläuterung finden Sie in den Sicherheitshinweisen des PHP-Projekts zu CVE-2026-109618 und CVE-2026-109619.

Woher stammen PHP-Sicherheitslücken?

Wie ich bereits erwähnt habe, behebt ein Update von PHP keine Sicherheitslücken in Composer-Paketen, und ein umfassender Abhängigkeitsscan deckt keine Probleme in Ihrem eigenen Code auf. Bei der Überprüfung einer PHP-Anwendung betrachte ich vier Quellen für Sicherheitsrisiken, von denen jede ihre eigenen potenziellen Folgen hat.

KategorieBeispieleHauptrisiko
PHP-LaufzeitumgebungNicht gepatchte PHP-Versionen, Schwachstellen im Interpreter, nicht mehr unterstützte VersionenAngreifer nutzen Schwachstellen in PHP selbst aus, unabhängig davon, wie sicher die Anwendung programmiert ist
Abhängigkeiten von DrittanbieternComposer-Pakete, CMS-Plugins, FrameworksAnfälliger Code von Drittanbietern setzt Anwendungen Angriffen aus, selbst wenn Ihr eigener Code sicher ist
AnwendungscodeSQL-Injection, XSS, CSRF, unsichere Deserialisierung, fehlerhafte ZugriffskontrolleDurch Programmierfehler können Angreifer möglicherweise Daten stehlen, unbefugte Aktionen ausführen oder die Anwendung kompromittieren.
Konfiguration und InfrastrukturUnsichere PHP-Einstellungen, offengelegte Dateien, übermäßige ZugriffsrechteFehlerhafte Konfigurationen können dazu führen, dass sensible Informationen offengelegt werden oder Angreifern mehr Zugriff gewährt wird als beabsichtigt.

Beheben Sie PHP-Sicherheitslücken, bevor sie eskalieren

Experten kontaktieren

PHP-Sicherheitscheckliste: 8 wichtige Prüfschritte

Als Nächstes gehen wir acht Sicherheitsprüfungen durch, die ich bei einer bestehenden PHP-Anwendung durchführen würde. Ich würde mit der PHP-Laufzeitumgebung beginnen, die Live-Anfragen bedient, und anschließend den Code, die Abhängigkeiten und die Konfiguration auf Probleme überprüfen, die durch ein PHP-Update allein nicht behoben werden können.

Überprüfen Sie Ihre PHP-Version und Sicherheitspatches

Ermitteln Sie zunächst, welche PHP-Laufzeitumgebungen Ihre Anwendungen verwenden: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP oder LiteSpeed. Berücksichtigen Sie dabei separate FPM-Pools, Container, CLI-Installationen, Queue-Worker und geplante Jobs.

Verlassen Sie sich nicht allein auf "php -v" oder "php –ini". "php -v" zeigt die CLI-Version an, während „php –ini“ die Konfiguration anzeigt. Beides bestätigt nicht, welche PHP-Laufzeitumgebung Webanfragen bedient.

Vergleichen Sie die aktive Laufzeitumgebung und deren Konfiguration mit dem offiziellen PHP-Sicherheitshinweis, einschließlich betroffener Versionen und Bedingungen für die Sicherheitslücke. Apache mod_php weist die nachweislich größte PHP2Shell-Sicherheitslücke auf, einschließlich eines Exploit-Pfads, der bereits vor der Ausführung des Anwendungscodes genutzt werden kann. Die Sicherheitslücke bei PHP-FPM hängt von der Konfiguration und den Ausführungswegen ab. Auch andere SAPIs müssen bewertet werden, da die SAPI allein nicht ausschlaggebend dafür ist, ob eine Bereitstellung sicher ist.

Die ersten Upstream-Releases, die beide Korrekturen enthielten, waren:

PHP-ZweigErste Version mit Fehlerbehebungen
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Diese Versionen sind in den PHP-Sicherheitshinweisen für CVE-2026-109618 und CVE-2026-109619. Überprüfen Sie vor der Aktualisierung, ob neuere Sicherheitsversionen verfügbar sind.

Überprüfen Sie PHP-Patches unter Linux und in Containern

Überprüfen Sie die aktive Laufzeitumgebung. Überprüfen Sie die Konfiguration Ihres Webservers, um das PHP-Modul, den FPM-Pool oder die eingebettete SAPI zu identifizieren, die die Anfragen bearbeiten. Überprüfen Sie die Version mithilfe zugriffsbeschränkter Diagnosetools und entfernen Sie anschließend alle temporären Endpunkte. Geben Sie phpinfo() oder einen Versionsendpunkt niemals öffentlich preis.

Überprüfen Sie die installierten Pakete. Unter Ubuntu mit PHP 8.3 zeigen diese schreibgeschützten Befehle die installierten Pakete und verfügbaren Versionen an:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Passen Sie die Paketnamen an Ihren PHP-Zweig an und vergleichen Sie die installierten Versionen mit den Sicherheitshinweisen des Anbieters oder dem Paket-Changelog. Linux-Anbieter portieren möglicherweise Korrekturen in ältere PHP-Versionen zurück. Ubuntu listet beispielsweise folgende gepatchte Builds auf:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Beide enthalten trotz ihrer niedrigeren Versionsnummern die relevanten Korrekturen. Lesen Sie die Ubuntu-Sicherheitsmitteilung.

Patch anwenden und neu bereitstellen. Installieren Sie die gepatchten Pakete. Bei Containern notieren Sie den Digest des laufenden Images, aktualisieren Sie anfällige PHP-Basis-Images, erstellen Sie die betroffenen Workloads neu und stellen Sie sie erneut bereit, einschließlich der Queue-Worker.

Überprüfen Sie das Ergebnis. Starten Sie betroffene PHP-Worker neu oder ersetzen Sie sie und stellen Sie sicher, dass laufende Prozesse und Container gepatchte Builds oder verifizierte Backports des Anbieters verwenden. Notieren Sie Paketversionen, Digests der laufenden Images, Details zum Neustart und die Ergebnisse der Überprüfung.

PHP 8.1 und frühere Versionen werden vom Upstream-Entwickler nicht mehr unterstützt, obwohl einige Anbieter weiterhin Sicherheits-Backports bereitstellen. Prüfen Sie, ob Ihr installierter Build abgedeckt ist, und führen Sie ein Upgrade durch, falls dies nicht der Fall ist. Der Sicherheitssupport für PHP 8.2 endet am 31. Dezember 2026; kombinieren Sie daher jeden kurzfristigen Patch mit einem Upgrade-Plan. Den vollständigen Zeitplan für den Support finden Sie im PHP-Supportplan.

Prüfung von Abhängigkeiten und Frameworks

Beginnen Sie mit composer.lock. Darin sind die Paketversionen erfasst, von denen Ihre Anwendung abhängt, einschließlich derer, die indirekt über andere Pakete installiert wurden. Führen Sie diese beiden Befehle aus:

composer audit --locked
composer outdated

composer audit --locked vergleicht die gesperrten Versionen mit bekannten Sicherheitshinweisen und kann nicht mehr unterstützte Pakete kennzeichnen. composer outdated zeigt an, welche Updates verfügbar sind, wobei ein veraltetes Paket nicht zwangsläufig anfällig ist. Überprüfen Sie auch die Sicherheitshinweise zu Laravel oder Symfony, insbesondere wenn Ihre Framework-Version nicht mehr unterstützt wird.

Vergleichen Sie die in der Produktion eingesetzten Pakete mit den Versionen in der geprüften Lock-Datei. Bewahren Sie die Prüfungsergebnisse und das Verzeichnis der installierten Pakete zusammen mit Ihren Release-Unterlagen auf.

Wenn Sie anfällige Pakete finden, aktualisieren Sie diese auf kompatible, gepatchte Versionen und testen Sie die betroffenen Funktionen. Ersetzen Sie Bibliotheken, für die keine Sicherheitspatches mehr bereitgestellt werden. Falls Kompatibilitätsprobleme ein Framework-Upgrade verhindern, dokumentieren Sie diese sowie den erforderlichen Migrationsaufwand. Übersehen Sie dabei nicht CMS-Plugins oder Bibliotheken, die außerhalb von Composer installiert wurden.

Ein einwandfreies Composer-Audit bestätigt nicht, dass PHP2Shell behoben ist. Das Audit überprüft Composer-Pakete, während PHP2Shell eine separate Überprüfung des PHP-Interpreters und seiner Patches erfordert. Um die Anwendung selbst zu bewerten, verwenden Sie SAST zur Analyse des Quellcodes und DAST zum Testen der laufenden Anwendung.

Überprüfung von PHP und Serverkonfigurationen

Überprüfen Sie die PHP-Einstellungen, die tatsächlich von Ihrem Webserver verwendet werden, einschließlich der PHP-FPM-Pool-Überschreibungen und der geladenen Erweiterungen. Beachten Sie, dass php --ini die CLI-Konfiguration anzeigt, die von der Live-Anwendung abweichen kann.

Für die Produktion beginnen Sie mit:

display_errors = Off
log_errors = On

Speichern Sie Protokolle außerhalb öffentlich zugänglicher Verzeichnisse und beschränken Sie den Zugriff darauf. Entfernen Sie öffentliche phpinfo()-Seiten und Debug-Endpunkte und überprüfen Sie expose_php, unnötige Erweiterungen und Dateisystemberechtigungen.

Das Deaktivieren von display_errors reduziert die Offenlegung von Informationen, mildert jedoch CVE-2026-109619 nicht ab. Der anfällige Codepfad wird möglicherweise ausgeführt, bevor PHP die Fehlermeldung verarbeitet.

Vorübergehende Maßnahmen, wenn sich die PHP-Patch-Bereitstellung verzögert

Falls die Patch-Bereitstellung noch warten muss, befolgen Sie die offizielle PHP-Sicherheitshinweis für Ihre Konfiguration.

  • CVE-2026-109619: Deaktivieren Sie session.upload_progress.enabled und setzen Sie unter PHP 8.5 fatal_error_backtraces=0. Wenden Sie diese Einstellungen vor der Verarbeitung von Anfragen über die Server- oder Pool-Konfiguration an und starten Sie anschließend die betroffenen Worker neu. Andere Ausnutzungsmöglichkeiten können bestehen bleiben.

  • CVE-2026-109618: Erzwingen Sie memory_limit=-1 auf Server- oder Pool-Ebene und starten Sie die betroffenen Worker neu. Dadurch wird der vorhersehbare PHP-Fehlerpfad aufgrund der Speicherbegrenzung beseitigt, andere Zuweisungsfehler bleiben jedoch möglich. Überprüfen Sie die Anforderungslimits sowie die Speicherschutzmechanismen des Hosts oder Containers, um Denial-of-Service-Risiken zu verringern.

PHP hat außerdem einen separaten Hinweis zu CVE-2026-115560 am 23. Oktober. Es betrifft Anwendungen, die session.serialize_handler von php_binary oder php_serialize auf php mithilfe von ini_set() vor session_start() umschalten, wobei der Upload-Fortschritt aktiviert ist. Betroffene Installationen sollten den Upload-Fortschritt bis zur Bereitstellung eines Fixes deaktivieren.

Holen Sie sich einen Upgrade-Plan für die älteren PHP-Anwendungen, auf die Ihr Unternehmen angewiesen ist

Kontakt aufnehmen

Auf SQL-Injection, XSS und die Ausführung von unsicherem Code

prüfen

Eine unsachgemäße Verarbeitung von Benutzereingaben kann sensible Daten offenlegen oder Angreifern ermöglichen, schädlichen Code auszuführen. Ich empfehle Ihnen, mithilfe von Code-Reviews riskante Eingabepfade aufzuspüren und mit SAST mögliche Schwachstellen zu identifizieren. Autorisierte DAST-Tests prüfen die laufende Anwendung, während Penetrationstests dabei helfen, festzustellen, welche Schwachstellen Angreifer ausnutzen könnten. Apps, die mittels Vibe-Coding erstellt wurden, können dieselben Schwachstellen aufweisen und erfordern dieselben Überprüfungen.

SQL-Injection

Eine SQL-Injection liegt vor, wenn Benutzereingaben die Struktur einer Datenbankabfrage verändern. Überprüfen Sie, wie Ihre Anwendung Abfragen aufbaut, insbesondere in Suchformularen und Berichten.

Um Benutzereingaben von SQL-Befehlen zu trennen, verwenden Sie PDO-Prepared-Statements:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Prepared Statements halten Datenwerte von der SQL-Syntax getrennt, wie es der Platzhalter :email im Beispiel tut. Platzhalter können jedoch keine Tabellen- oder Spaltennamen darstellen. Wenn Benutzer beispielsweise einen Bericht sortieren können, wählen Sie die zulässigen Spalten aus einer in der Anwendung definierten Liste aus. Testen Sie die betroffenen Abfragen nach dem Vornehmen von Änderungen.

Cross-Site-Scripting

Cross-Site-Scripting (XSS) tritt auf, wenn eine Anwendung nicht vertrauenswürdige Daten anzeigt, die ein Browser als Code ausführen kann. Überprüfen Sie PHP-Vorlagen auf Benutzereingaben, die ohne ordnungsgemäße Escaping-Maßnahmen angezeigt werden, insbesondere wenn das automatische Escaping deaktiviert ist.

Wenn Ihre Anwendung beispielsweise den Namen eines Benutzers als HTML-Text anzeigt, verwenden Sie htmlspecialchars(), um Sonderzeichen so umzuwandeln, dass der Browser sie als Text behandelt:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

Der richtige Schutz hängt davon ab, wo die Daten erscheinen. JavaScript, URLs und HTML-Attribute erfordern kontextspezifische Prüfungen und Kodierungen. Wenn Benutzer formatiertes HTML übermitteln können, verwenden Sie einen HTML-Sanitizer, um unsichere Elemente zu entfernen und gleichzeitig die zulässige Formatierung beizubehalten.

Unsicherer Code und Befehlsausführung

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Überblick über Authentifizierung, Sitzungen und Zugriffskontrolle

Beginnen Sie mit Passwörtern. Diese sollten nicht in lesbarer Form gespeichert werden. Überprüfen Sie, ob Ihre Anwendung die Funktionen PHP „password_hash()“ und „password_verify()“ oder die entsprechenden Framework-Methoden verwendet. Achten Sie auf älteren Hash-Code, der möglicherweise nicht mehr sicher ist.

Als Nächstes prüfen Sie, was passiert, wenn sich jemand anmeldet. Die Anwendung sollte eine neue Sitzungs-ID generieren, damit eine vor der Anmeldung erhaltene ID nicht für den Zugriff auf das Konto wiederverwendet werden kann. Überprüfen Sie die Einstellung `session.use_strict_mode` sowie Cookie-Einstellungen wie „Secure“, „HttpOnly“ und „SameSite“. Testen Sie die Neugenerierung der Sitzungs-ID über Ihr Framework, auch wenn mehrere Anfragen gleichzeitig eingehen.

Testen Sie nun , ob Benutzer Daten einsehen können, die ihnen nicht gehören. Erstellen Sie zwei Testkonten, jedes mit einer eigenen Rechnung. Melden Sie sich beim ersten Konto an und ändern Sie die Rechnungs-ID in einer Anfrage auf diejenige, die zum zweiten Konto gehört. Der Server sollte den Zugriff verweigern, sofern dieser Benutzer keine Berechtigung hat.

Wiederholen Sie den Test für die Bearbeitung von Rechnungen, das Herunterladen von Dateien und API-Anfragen. Stellen Sie sicher, dass normale Benutzer keinen Zugriff auf Admin-Funktionen haben. Eine Anmeldung gewährt nicht automatisch Zugriff auf alle Datensätze. Der Server muss bei jeder Anfrage an einen geschützten Datensatz oder API-Endpunkt die Berechtigungen prüfen.

CSRF-Schutz überprüfen

Bei einem CSRF-Angriff wird der Browser eines angemeldeten Benutzers dazu verleitet, eine Aktion auszuführen, die dieser nicht autorisiert hat, beispielsweise die Änderung von Kontodaten. Überprüfen Sie zunächst Formulare und Anfragen, die Daten ändern, insbesondere solche, die über Sitzungs-Cookies authentifiziert werden.

Überprüfen Sie den CSRF-Schutz in Ihrer Laravel- oder Symfony-Anwendung und stellen Sie sicher, dass keine Routen ausgeschlossen sind. Testen Sie, sofern eine Token-Validierung erfolgt, Anfragen mit fehlenden oder ungültigen Tokens. Stellen Sie außerdem sicher, dass gefälschte Anfragen von einer anderen Website keine Benutzerdaten ändern können. Überprüfen Sie auch die SameSite-Einstellung bei Sitzungs-Cookies.

In Laravel Blade fügt @csrf ein verstecktes Token-Feld zu einem Formular hinzu:


    @csrf

In Laravel 13 gibt es ein wichtiges Detail. Die CSRF-Middleware überprüft zunächst den Sec-Fetch-Site-Header. Eine Same-Origin-Anfrage kann ohne Token durchgehen, während andere Anfragen standardmäßig auf die Token-Validierung zurückgreifen. Laravel deaktiviert den CSRF-Schutz standardmäßig auch während automatisierter Tests; stellen Sie daher sicher, dass er aktiviert ist, wenn Sie diese Schutzmaßnahmen testen.

Bei APIs spielt die Authentifizierungsmethode eine Rolle. Eine zustandslose API, die Bearer-Token in Autorisierungs-Headern verwendet, ist im Allgemeinen anderen CSRF-Risiken ausgesetzt. Wenn Ihre SPA jedoch auf Session-Cookies basiert, benötigt sie dennoch Schutz vor gefälschten Anfragen.

Sicheres Hochladen und Zugriff auf Dateien

Datei-Uploads stellen ein Sicherheitsrisiko dar, wenn Angreifer ausführbare Dateien hochladen oder auf Daten zugreifen können, auf die sie keinen Zugriff haben sollten. Überprüfen Sie, welche Dateitypen und -größen Ihre Anwendung akzeptiert, wo die hochgeladenen Dateien gespeichert werden und wer sie herunterladen darf. Testen Sie die Upload- und Download-Routen auf Path-Traversal, stellen Sie sicher, dass hochgeladene Dateien nicht als PHP ausgeführt werden können, und überprüfen Sie, ob .env, .git und Sicherungsdateien nicht öffentlich zugänglich sind.

Im Folgenden finden Sie ein PHP-Beispiel, das den MIME-Typ einer hochgeladenen Datei überprüft und diese unter einem zufällig generierten Namen speichert:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Upload fehlgeschlagen');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Nicht unterstützter Dateityp');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Upload kann nicht gespeichert werden');
}

Das Beispiel geht von einem einzelnen Datei-Upload und einem bereits vorhandenen, privaten Verzeichnis mit entsprechenden Berechtigungen aus. Die PHP-Funktion move_uploaded_file() bestätigt, dass die Quelle über den PHP-HTTP-POST-Mechanismus hochgeladen wurde.

Eine MIME-Prüfung allein reicht nicht aus, um Uploads sicher zu machen. Produktionscode benötigt außerdem vom Server erzwungene Dateigrößenbeschränkungen, Upload- und Download-Berechtigungen sowie eine Validierung des tatsächlichen Dateiinhalts. Kodieren Sie Bilder gegebenenfalls neu und ziehen Sie bei Uploads mit höherem Risiko eine Malware-Prüfung in Betracht. Speichern Sie Dateien nach Möglichkeit außerhalb des Web-Stammverzeichnisses, beschränken Sie den Zugriff auf das Dateisystem und verhindern Sie, dass hochgeladene Dateien als PHP ausgeführt werden.

Schützen Sie sensible Daten und Anmeldedaten

Offen gelegte Datenbankpasswörter, API-Schlüssel und Zugriffstoken können Angreifern Zugriff auf Ihre Anwendung oder sensible Daten verschaffen. Überprüfen Sie Ihren Quellcode und Ihren Git-Verlauf auf solche Geheimnisse. Tools wie Gitleaks können dabei helfen, diese zu finden. Stellen Sie sicher, dass .env-Dateien nicht in Git gespeichert sind oder über das Internet zugänglich sind. Überprüfen Sie außerdem, wer in CI/CD-Pipelines auf geheime Daten zugreifen kann, und überprüfen Sie Container-Images und Anwendungsprotokolle auf sensible Informationen.

Bewahren Sie Geheimnisse in einem Secrets-Manager oder einem anderen System mit eingeschränktem Zugriff auf, anstatt sie im Anwendungscode zu hinterlegen. Schränken Sie ein, wer sie einsehen oder ändern darf, und erteilen Sie jeder Anwendung nur die Berechtigungen, die sie benötigt.

Wenn eine Anmeldeinformation offengelegt wird, widerrufen oder ersetzen Sie sie und aktualisieren Sie die Dienste, die sie verwenden. Entfernen Sie offengelegte Kopien, untersuchen Sie, ob jemand sie ohne Erlaubnis verwendet hat, und verhindern Sie, dass Geheimnisse in zukünftigen Protokollen erscheinen. Das Entfernen eines Geheimnisses aus Ihrem Code deaktiviert es nicht und löscht es auch nicht aus alten Git-Commits.

Lassen Sie eine fachkundige PHP-Sicherheitsüberprüfung durchführen

Termin vereinbaren

So priorisieren, implementieren und überprüfen Sie PHP-Sicherheitskorrekturen

01
Schwachstellen priorisieren

Räumen Sie Systemen, die Angriffen ausgesetzt sind, Priorität ein. Wägen Sie den CVSS-Wert unter Berücksichtigung der PHP-SAPI, der Internetpräsenz, bestehender Schutzmaßnahmen und der Auswirkungen auf den Geschäftsbetrieb ab. Nicht gepatchte, mit dem Internet verbundene mod_php-Workloads erfordern dringende Aufmerksamkeit, während andere SAPIs noch einer Bewertung bedürfen.

02
Patches sicher bereitstellen

Erfassen Sie betroffene Anwendungen, PHP-Worker-Pools und Container-Image-Digests. Führen Sie vor der Bereitstellung Tests in der Staging-Umgebung durch und erstellen Sie einen Wiederherstellungsplan. Wenden Sie Patches auf betroffene Pakete an oder erstellen Sie Images neu, und starten Sie anschließend alle betroffenen Worker neu oder ersetzen Sie sie. WAF-Regeln und konfigurative Abhilfemaßnahmen können die Anfälligkeit gegenüber bestimmten Exploit-Pfaden verringern. Sie beheben jedoch nicht die Schwachstelle in der anfälligen Laufzeitumgebung.

03
Abhilfemaßnahmen überprüfen

Überprüfen Sie, welche PHP-Version Live-Anfragen bedient, und überprüfen Sie deren Patch-Status, einschließlich etwaiger Backports des Herstellers. Stellen Sie sicher, dass betroffene Worker neu gestartet oder ersetzt wurden, führen Sie Regressionstests durch und wiederholen Sie die zuvor fehlgeschlagene Sicherheitsprüfung. Überwachen Sie die Produktionsumgebung nach der Bereitstellung auf Fehler.

04
Mögliche Sicherheitsverletzung untersuchen

Durch das Installieren eines Patches wird die Sicherheitslücke behoben. Etwaige frühere Kompromittierungen müssen weiterhin untersucht werden. Überprüfen Sie Serverprotokolle, Abstürze von Worker-Prozessen, unbekannte Dateien und verdächtige Netzwerkaktivitäten. Bei mod_php kann PHP2Shell möglicherweise ausgeführt werden, bevor die Protokollierung der Anwendung beginnt, sodass ein Angriff auch bei sauberen Framework-Protokollen nicht ausgeschlossen werden kann. Leiten Sie Warnzeichen an das Incident-Response-Team weiter und sichern Sie die Beweise.

05
Sicherheit gewährleisten

Verfolgen Sie neue PHP- und Abhängigkeitsschwachstellen und integrieren Sie Sicherheitsprüfungen in CI/CD. Richten Sie regelmäßige Bewertungen an der Anfälligkeit der Anwendungen und den Geschäftsrisiken aus und führen Sie nach wesentlichen Änderungen oder kritischen Offenlegungen eine Neubewertung durch.

arrow-icon.arrow-icon.
01 Schwachstellen priorisieren

Räumen Sie Systemen, die Angriffen ausgesetzt sind, Priorität ein. Wägen Sie den CVSS-Wert unter Berücksichtigung der PHP-SAPI, der Internetpräsenz, bestehender Schutzmaßnahmen und der Auswirkungen auf den Geschäftsbetrieb ab. Nicht gepatchte, mit dem Internet verbundene mod_php-Workloads erfordern dringende Aufmerksamkeit, während andere SAPIs noch einer Bewertung bedürfen.

arrow-icon.arrow-icon.
02 Patches sicher bereitstellen

Erfassen Sie betroffene Anwendungen, PHP-Worker-Pools und Container-Image-Digests. Führen Sie vor der Bereitstellung Tests in der Staging-Umgebung durch und erstellen Sie einen Wiederherstellungsplan. Wenden Sie Patches auf betroffene Pakete an oder erstellen Sie Images neu, und starten Sie anschließend alle betroffenen Worker neu oder ersetzen Sie sie. WAF-Regeln und konfigurative Abhilfemaßnahmen können die Anfälligkeit gegenüber bestimmten Exploit-Pfaden verringern. Sie beheben jedoch nicht die Schwachstelle in der anfälligen Laufzeitumgebung.

arrow-icon.arrow-icon.
03 Abhilfemaßnahmen überprüfen

Überprüfen Sie, welche PHP-Version Live-Anfragen bedient, und überprüfen Sie deren Patch-Status, einschließlich etwaiger Backports des Herstellers. Stellen Sie sicher, dass betroffene Worker neu gestartet oder ersetzt wurden, führen Sie Regressionstests durch und wiederholen Sie die zuvor fehlgeschlagene Sicherheitsprüfung. Überwachen Sie die Produktionsumgebung nach der Bereitstellung auf Fehler.

arrow-icon.arrow-icon.
04 Mögliche Sicherheitsverletzung untersuchen

Durch das Installieren eines Patches wird die Sicherheitslücke behoben. Etwaige frühere Kompromittierungen müssen weiterhin untersucht werden. Überprüfen Sie Serverprotokolle, Abstürze von Worker-Prozessen, unbekannte Dateien und verdächtige Netzwerkaktivitäten. Bei mod_php kann PHP2Shell möglicherweise ausgeführt werden, bevor die Protokollierung der Anwendung beginnt, sodass ein Angriff auch bei sauberen Framework-Protokollen nicht ausgeschlossen werden kann. Leiten Sie Warnzeichen an das Incident-Response-Team weiter und sichern Sie die Beweise.

arrow-icon.arrow-icon.
05 Sicherheit gewährleisten

Verfolgen Sie neue PHP- und Abhängigkeitsschwachstellen und integrieren Sie Sicherheitsprüfungen in CI/CD. Richten Sie regelmäßige Bewertungen an der Anfälligkeit der Anwendungen und den Geschäftsrisiken aus und führen Sie nach wesentlichen Änderungen oder kritischen Offenlegungen eine Neubewertung durch.

Beispiel: Ein Produktions-Patch, der erfolgreich erscheint, es aber nicht ist

Ein Symfony-Shop läuft unter PHP 8.3 hinter Nginx und PHP-FPM. Der Administrator aktualisiert die Betriebssystempakete und führt „php -v“ aus. Der Befehl zeigt eine gepatchte Version an, sodass alles in Ordnung zu sein scheint. Allerdings überprüft „php -v“ nur die PHP-Binärdatei der Befehlszeile.

Kundenanfragen werden weiterhin über nginx an PHP-FPM-Worker weitergeleitet, die vor dem Update gestartet wurden. Hintergrundjobs laufen ebenfalls in einem separaten Container mit einer anfälligen PHP-Basisschicht. Die Pakete auf dem Server mögen zwar aktualisiert worden sein, doch diese Workloads führen weiterhin den alten Code aus.

PHP build checks for web, workers, and CLI.

Um den Patch abzuschließen, muss das Team alle betroffenen Anwendungen und Worker-Pools identifizieren, die FPM-Worker neu starten und den Queue-Container mit einem gepatchten Image erneut bereitstellen. Anschließend muss überprüft werden, ob die laufenden PHP-Prozesse korrigierte Builds oder verifizierte Backports des Anbieters verwenden.

Testen Sie das Auschecken und das Hochladen von Dateien in der Staging-Umgebung, führen Sie Smoke-Tests in der Produktion durch und wiederholen Sie die Sicherheitsprüfungen, die zuvor fehlgeschlagen sind. Der Deployment-Eintrag sollte die PHP-SAPI, die den Web-Traffic bedient, verifizierte Paketversionen oder Image-Digests, Nachweise für den Neustart und die Tests sowie den Verantwortlichen enthalten.

Ein erfolgreiches Composer-Audit ist kein Beweis dafür, dass PHP2Shell behoben wurde. Dieser Befehl überprüft Abhängigkeiten, nicht den PHP-Interpreter, der Webanfragen verarbeitet.

Überprüfen Sie die Benutzer-ID des PHP-Workers, beschreibbare Verzeichnisse, eingebundene Geheimnisse, Datenbankberechtigungen und den ausgehenden Netzwerkzugriff. Diese Faktoren bestimmen, ob ein Angreifer Anwendungsdateien ändern, Anmeldedaten auslesen oder andere Systeme erreichen könnte. Das Prinzip der geringsten Berechtigungen und Netzwerksegmentierung können den Schaden begrenzen, falls ein Worker kompromittiert wird, doch das Patchen des Interpreters bleibt weiterhin notwendig.

php -v zeigt die PHP-Version in der Befehlszeile an, kann jedoch nicht bestätigen, welcher Interpreter den Produktionsdatenverkehr bedient oder ob lang laufende Worker weiterhin die anfällige Version verwenden. Mit PHP2Shell überprüfen wir zunächst die aktive Laufzeitumgebung und analysieren anschließend die Abhängigkeiten und den Anwendungscode. Wir betrachten die Behebung erst dann als abgeschlossen, wenn wir bestätigt haben, dass die gepatchte Version tatsächlich die Produktionsanfragen verarbeitet.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Leiter für GRC, Cybersicherheit & Nachhaltigkeit

Wie Innowise Ihnen helfen kann, Ihre PHP-Anwendungen zu sichern

Bei Innowise vereinen wir PHP-Entwicklung und Sicherheitskompetenz. Unsere über 100 PHP-Entwickler haben bereits über 250 Projekte erfolgreich umgesetzt, und unsere mehr als 50 Cybersicherheitsingenieure helfen dabei, Schwachstellen zu identifizieren und zu beheben. Unsere Arbeit wird zudem durch die Zertifizierungen nach ISO/IEC 27001:2022 und ISO 9001:2015 untermauert.

Wir überprüfen Ihre PHP-Anwendungen auf Sicherheitsprobleme, einschließlich anfälliger Abhängigkeiten und veralteter Komponenten. Unsere Entwickler kümmern sich um die notwendigen Korrekturen und Upgrades, während Sicherheitsingenieure die Änderungen vor der Freigabe testen. Wenn Sie sich nicht sicher sind, wo Sie anfangen sollen, kann unser IT- Sicherheitsberatungsteam kann die Risiken bewerten und Ihnen dabei helfen, die Maßnahmen zu priorisieren.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Unsere PHP-Projekte

Neugestaltung und Neuaufbau der MedSpa Network-Website
Innowise hat die Website von MedSpa Network auf WordPress neu gestaltet und dem Team damit die Kontrolle über die täglichen Inhaltsaktualisierungen ermöglicht.
2 Monate vom Start bis zur Markteinführung
3-5 Leads pro Woche – ein Anstieg gegenüber 1 pro Monat
Fallstudie anzeigen
Kundenbewertung
Fallstudie anzeigen
Client review logo. Kundenbewertung
MedSpa Network website redesign and rebuild.
KI-Bot für die Marketingkampagne der TBC Bank
Innowise hat einen zweisprachigen Telegram-Bot entwickelt, der mithilfe von KI Selfies mit dem Fußballstar und Markenbotschafter der TBC Bank generiert.
3,000 aktive Nutzer
2 unterstützte Sprachen
Fallstudie anzeigen
Kundenbewertung
Fallstudie anzeigen
Client review logo. Kundenbewertung
AI Telegram bot..
Festlegung der Produktstrategie für die Bitcoin-Kreditplattform von Bitlendex
Innowise führte für Bitlendex eine Analysephase durch und unterstützte den Kunden dabei, ein Produktkonzept in der Frühphase in ein validiertes Geschäftsmodell und ein klar definiertes MVP umzusetzen.
1 Monat für eine umfassende Analysephase
Fallstudie anzeigen
Fallstudie anzeigen
Defining the product strategy for Bitlendex’s bitcoin lending platform.
Finanzberatung-
ssystem für Bonnfinanz
Innowise hat Bonnfinanz dabei unterstützt, ein webbasiertes Beratungs- und Verwaltungssystem aufzubauen, das mobiles Arbeiten und die direkte Interaktion mit dem Kunden ermöglicht.
Fallstudie anzeigen
Fallstudie anzeigen
Financial advisory system for Bonnfinanz..
Ladeplattform für Elektrofahrzeuge mit flexibler Abrechnung
Innowise trug zur Modernisierung der E-Mobilitätsplattform von SMART/LAB bei, indem es deren Funktionen in den Bereichen Abrechnung, Zahlung, Transaktionsmanagement und Berichterstellung verbesserte.
>50% schnellere Rechnungsstellung und Zahlungsabwicklung
Fallstudie anzeigen
Fallstudie anzeigen
EV-Ladeplattform mit flexibler Abrechnung.
Cloud-native DevOps-Transformation von FinXP
Innowise unterstützte FinXP bei der Modernisierung seiner Finanzdienstleistungsinfrastruktur durch die Migration veralteter PHP-basierter APIs und Anwendungen auf eine Cloud-native Architektur.
11 Apps wurden zu Azure App Service migriert
100% Infrastruktur als Code
Fallstudie anzeigen
Fallstudie anzeigen
FinXP’s cloud-native DevOps transformation.
Technisches SEO für E-Commerce-Plattform
Innowise hat kritische technische SEO- und Performance-Probleme auf der E-Commerce-Plattform von Officine 08 behoben.
<500 ms Server-Antwortzeit
5 Monate, um das Projekt abzuschließen
Fallstudie anzeigen
Kundenbewertung
Fallstudie anzeigen
Client review logo. Kundenbewertung
Technisches SEO für E-Commerce-Plattform.
Kontinuierliche Weiterentwicklung einer Plattform für Parfüm-Abonnements
Innowise hat Scentbird dabei unterstützt, seine Abonnementplattform zu erweitern, um neue Einkaufserlebnisse zu ermöglichen und das internationale Wachstum voranzutreiben.
4 Jahre kontinuierliche Unterstützung
Fallstudie anzeigen
Kundenbewertung
Fallstudie anzeigen
Client review logo. Kundenbewertung
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Abschließend

PHP2Shell hat eine schwerwiegende Sicherheitslücke im PHP-Interpreter selbst aufgedeckt. Framework-Updates und Abhängigkeitsprüfungen beheben Schwachstellen auf dieser Ebene nicht. Unternehmen müssen jede PHP-Laufzeitumgebung identifizieren, die Webanfragen verarbeitet, die Sicherheitsupdates installieren und sicherstellen, dass auf den Produktionsservern die gepatchten Versionen laufen.

PHP-Sicherheit erfordert zudem regelmäßige Überprüfungen des Anwendungscodes, der Konfiguration und der Zugriffskontrollen, insbesondere nach der Offenlegung kritischer Sicherheitslücken oder nach größeren Updates. Wenn Sie Hilfe bei der Bewertung Ihres Sicherheitsrisikos oder der Überprüfung der Korrekturen benötigen, bietet Innowise unter IT-Sicherheitsberatung und Cybersicherheitsbewertung von Innowise können Sie dabei unterstützen.

FAQ

Ihre Anwendung ist möglicherweise gefährdet, wenn auf Ihrem Server eine PHP-Version läuft, für die noch keine Patches für CVE-2026-109618 und CVE-2026-109619 bereitgestellt wurden. Überprüfen Sie, welche PHP-Version tatsächlich läuft und ob Ihr Hosting-Anbieter die Korrekturen bereits angewendet hat. Apache mod_php weist das höchste bestätigte Risiko auf, aber auch PHP-FPM muss überprüft werden. Da die Sicherheitslücken in PHP selbst liegen, werden sie durch ein Update von WordPress oder einem anderen Framework nicht behoben.

Korrekturen für PHP2Shell sind in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 verfügbar. Einige Linux-Anbieter haben die Patches auf ältere Versionen zurückportiert; überprüfen Sie daher die Sicherheitshinweise Ihres Anbieters. Stellen Sie sicher, dass Ihre laufenden PHP-Worker die gepatchte Version verwenden. Unter Windows installieren Sie die aktualisierten Pakete vom 26. Oktober, deren Versionsnummer auf -1 endet; diese beheben zudem eine separate Brotli-Sicherheitslücke.

Falls Sie PHP nicht sofort aktualisieren können, beschränken Sie den öffentlichen Zugriff auf betroffene Anwendungen, soweit dies möglich ist. Für Websites, die online bleiben müssen, kann Ihr Serveradministrator vorübergehende Maßnahmen aus dem PHP-Sicherheitshinweis anwenden, wie z. B. die Begrenzung der Anforderungsgröße oder die Deaktivierung des Upload-Fortschritts in Sitzungen. Testen Sie diese Änderungen, um sicherzustellen, dass die Website weiterhin funktioniert. Sie verringern lediglich das Risiko, daher ist die Installation einer gepatchten PHP-Version weiterhin dringend erforderlich.

Nein. Ein Update von PHP behebt zwar Schwachstellen in der PHP-Laufzeitumgebung, behebt jedoch keine Sicherheitsprobleme in Ihrem Anwendungscode, veralteten Plugins oder der Serverkonfiguration. Diese müssen Sie separat überprüfen und beheben.

Ich empfehle, PHP-Anwendungen mindestens einmal monatlich auf bekannte Schwachstellen zu überprüfen, wobei bei Systemen mit hohem Risiko häufigere Überprüfungen erforderlich sind. Behalten Sie PHP-Sicherheitshinweise und -Abhängigkeiten kontinuierlich im Auge und planen Sie gründlichere Überprüfungen entsprechend der Gefährdung Ihrer Anwendung und des Geschäftsrisikos ein. Nach größeren Updates oder der Bekanntgabe kritischer Sicherheitslücken sind zusätzliche Tests wichtig.

Überprüfen Sie die PHP-Sicherheitshinweise sowie die Bulletins Ihres Hosting-Anbieters oder Betriebssystemherstellers auf bekannte Sicherheitslücken. Verwenden Sie „composer audit --locked“, um Abhängigkeiten zu überprüfen, führen Sie statische Analysen und Code-Reviews durch, um Probleme auf Anwendungsebene zu finden, und nutzen Sie OWASP ZAP, um Ihre Webanwendung mit entsprechender Berechtigung zu testen. Um Sicherheitspatches zu überprüfen, kontrollieren Sie die in der Produktion ausgeführte PHP-Version sowie alle von Ihrem Anbieter zurückportierten Korrekturen.

Ja. Updates können Kompatibilitätsprobleme mit älterem Code oder Erweiterungen verursachen. Testen Sie sie in der Staging-Umgebung, bevor Sie Ihre Live-Anwendung aktualisieren, und halten Sie einen Notfallplan bereit, falls etwas nicht mehr funktioniert.

Korrelieren Sie die Protokolle des Reverse-Proxys, von Apache/nginx, PHP-FPM und EDR/Host. Achten Sie auf Worker-Abstürze, verdächtige Dateien oder Prozesse, unerwarteten ausgehenden Datenverkehr und Anzeichen für die Offenlegung von Anmeldedaten. In Anwendungsprotokollen können PHP-Laufzeit-Exploits übersehen werden, die auftreten, bevor das Framework mit der Protokollierung beginnt. Wenn Sie verdächtige Aktivitäten feststellen, leiten Sie Maßnahmen zur Vorfallreaktion ein und sichern Sie forensische Beweise.

Mehr anzeigen Weniger anzeigen

Inhaltsübersicht

Finden Sie heraus, welche PHP-Workloads zuerst ein Sicherheitsupdate benötigen

Meine PHP-Risiken bewerten

    Kontakt aufnehmen

    Vereinbaren Sie ein Gespräch oder füllen Sie das Formular aus. Wir kontaktieren Sie, sobald wir Ihre Anfrage bearbeitet haben.

    Sprachnachricht senden
    Datei beifügen
    Datei hochladen

    Sie können 1 Datei mit bis zu 2 MB anhängen. Gültige Dateiformate: pdf, jpg, jpeg, png.

    Mit dem Klicken auf Senden erklären Sie sich damit einverstanden, dass Innowise Ihre personenbezogenen Daten gemäß unserer geschützt und es gelten verarbeitet, um Ihnen relevante Informationen bereitzustellen. Mit Angabe Ihrer Telefonnummer stimmen Sie zu, dass wir Sie per Sprachanruf, SMS oder Messaging-Apps kontaktieren. Es können Gebühren für Anrufe, Nachrichten und Datenübertragung anfallen.

    Sie können Ihre Anfrage auch an folgende E-Mail-Adresse
    an contact@innowise.com
    Wie geht es weiter?
    1

    Sobald wir Ihre Anfrage erhalten und geprüft haben, melden wir uns bei Ihnen, klären erste Fragen und unterzeichnen ein NDA, um die Vertraulichkeit zu gewährleisten.

    2

    Nach genauer Prüfung Ihrer Anforderungen, Bedürfnisse und Erwartungen wird unser Team einen Projektvorschlag mit Angaben zu Arbeitsumfang, Teamgröße, Zeitaufwand und Kosten erstellen.

    3

    Wir vereinbaren einen Termin, um das Angebot gemeinsam zu besprechen und alle Details festzulegen.

    4

    Abschließend unterzeichnen wir den Vertrag und starten umgehend mit der Umsetzung Ihres Projekts.

    Fallstudien

    Blog
    Generative AI trends in 2026: key technologies and future outlook.
    Trends im Bereich der generativen KI im Jahr 2026: Schlüsseltechnologien und Zukunftsaussichten
    Entdecken Sie die wichtigsten Trends im Bereich der generativen KI im Jahr 2026. Erfahren Sie, wie verschiedene Branchen GenAI einsetzen, welche Risiken damit verbunden sind und wie es weitergeht.
    Michael Labutin
    5. November 2026
    Blog
    AI discoverability: how to get your brand found, cited, and recommended by AI.
    Auffindbarkeit durch KI: So sorgt man dafür, dass die eigene Marke von KI gefunden, zitiert und empfohlen wird
    Ihre Marke könnte bei Google gut platziert sein und dennoch für ChatGPT unsichtbar bleiben. Schauen wir uns einmal an, wie die Auffindbarkeit durch KI hier Abhilfe schaffen kann.
    Yuliya Pantsiuk
    4. November 2026
    Blog
    AI in supply chain and logistics: use cases, benefits, and implementation.
    KI in der Lieferkette und Logistik: Anwendungsfälle, Vorteile und Umsetzung
    KI erobert die Logistikbranche, und Ihre Konkurrenten wissen das. Erfahren Sie, wo sie zum Einsatz kommt, welche Einsparungen sie ermöglicht und wie Sie aufholen können.
    Philip Tikhanovich
    4. November 2026
    Blog
    AI in social media: use cases, benefits, and trends.
    KI in den sozialen Medien: Anwendungsfälle, Vorteile und Trends
    Feeds, Filter, Übersetzungen, Moderation: KI ist in den sozialen Medien allgegenwärtig. Werfen wir einen Blick hinter die Kulissen.
    Philip Tikhanovich
    30. Oktober 2026
    Blog
    AI in CRM: use cases, benefits, and implementation.
    KI im CRM: Anwendungsfälle, Vorteile und Umsetzung
    Welche KI-CRM-Funktionen sind den Hype wirklich wert? Wir beleuchten die Anwendungsfälle, Plattformen, Risiken und den ROI.
    Raman Karabach
    14. Oktober 2026
    Blog
    AI chatbots in healthcare: use cases, benefits, and implementation.
    KI-Chatbots im Gesundheitswesen: Anwendungsfälle, Vorteile und Umsetzung
    Ein Fachleitfaden zu KI-Chatbots im Gesundheitswesen: konkrete Anwendungsfälle, Vorteile und wichtige Integrationsaspekte.
    Roman Sen
    24. September 2026
    Blog
    AI in medical imaging: applications, benefits, and implementation.
    KI in der medizinischen Bildgebung: Anwendungen, Vorteile und Umsetzung
    Ein nüchterner Blick darauf, wie KI heute in der medizinischen Bildgebung eingesetzt wird.
    Aleh Yafimau
    1. September 2026
    Blog
    LLM-as-a-judge: how we evaluate AI systems at scale.
    LLM als Richter: Wie wir KI-Systeme in großem Maßstab bewerten
    Bewerten Sie die Ergebnisse von LLMs anhand strengerer Bewertungskriterien, klarerer Bewertungen und weniger blinder Flecken.
    Philip Tikhanovich
    22. Juli 2026
    Blog
    Best 10 data modernization companies in 2026.
    Die 10 besten Unternehmen für Datenmodernisierung im Jahr 2026
    Vergleichen Sie die führenden Anbieter im Bereich Datenmodernisierung und wählen Sie einen Partner für die Arbeit mit Legacy-Daten, Cloud-Daten und KI-fähigen Daten aus.
    Philip Tikhanovich
    16. Juli 2026
    Blog
    Microsoft Dynamics 365 for financial services: a complete guide.
    Microsoft Dynamics 365 für Finanzdienstleister: Ein umfassender Leitfaden
    Banken lieben Systeme. Teams hassen schlechte Systeme. Hier kann Dynamics 365 Abhilfe schaffen.
    Siarhei Sukhadolski
    13. Juli 2026
    Blog
    Best 9 ERP consulting companies in 2026.
    Die 9 besten ERP-Beratungsunternehmen im Jahr 2026
    Vergleichen Sie die neun führenden ERP-Beratungsunternehmen im Jahr 2026. Informieren Sie sich über deren Fachkompetenz und Branchenschwerpunkte und erhalten Sie Tipps zur Auswahl des für Sie passenden Partners.
    Kiryl Drabysheuski
    10. Juli 2026
    Blog
    Enterprise AI adoption trends 2026.
    Trends bei der Einführung von KI in Großunternehmen bis 2026
    Die wichtigsten KI-Trends des Jahres 2026 und wie sie Großunternehmen nachhaltig verändern.
    Philip Tikhanovich
    7. Juli 2026

    Weitere von uns abgedeckte Dienstleistungen

    Betrieb
    KIOps BPA Managed IT MLOps-Beratung RPA
    Mehr erfahren
    QS
    Testautomatisierung QS für E-Commerce-Apps ERP-Tests Penetrationstests QA-Beratung QS-Ingenieure Sicherheitstests Tests Web-App-Penetrationstests
    Mehr erfahren

    arrow