PHP2Shell: Kritische PHP-Lücken (CVE-2026-109618, CVE-2026-109619) bedrohen Millionen Websites – warum Sie heute noch patchen müssen

Stand: Mittwoch, 21. Oktober 2026, 17:30 Uhr. Wir aktualisieren diesen Beitrag, sobald es Neues gibt.

Heute um 16:00 Uhr hat das PHP-Projekt außerplanmäßige Sicherheitsupdates veröffentlicht. Sie schließen zwei Lücken, die Fachleute schon jetzt zu den schwersten der letzten Jahre zählen. Unter dem Namen „PHP2Shell“ (CVE-2026-109618 und CVE-2026-109619) erlauben sie Angreifern, ohne jede Anmeldung eigenen Code auf einem Webserver auszuführen. Damit lässt sich die Website, der Webshop oder die Cloud-Anwendung auf diesem Server vollständig übernehmen. Betroffen ist praktisch jeder Server, der Webseiten mit PHP ausliefert, und das sind viele: Rund 70 Prozent aller Websites, deren Server-Technik bekannt ist, laufen mit PHP. Dazu gehört jede WordPress-Seite.

Besonders gefährlich: Erste Angriffe liefen schon, bevor es die Updates überhaupt gab, und ein fertiges Angriffswerkzeug ist öffentlich. Diesmal hilft kein WordPress-Update und kein Sicherheits-Plugin, denn die Lücke steckt eine Ebene tiefer, in PHP selbst. Schließen lässt sie sich nur auf dem Server.

Kundinnen und Kunden der SKAWINSKI GmbH benachrichtigen wir bei so gravierenden Lücken selbstverständlich direkt. Dieser Beitrag ist für alle anderen: Hier lesen Sie, was passiert ist, ob Sie betroffen sind und was Sie heute noch tun sollten.

So lesen Sie diesen Beitrag: Er ist bewusst ausführlich und richtet sich an zwei Lesergruppen. Geschäftsführung und Entscheider finden im Abschnitt „Was PHP2Shell für Ihr Unternehmen bedeutet“ alles Wichtige in verständlicher Sprache, ohne Fachchinesisch. IT-Teams und Administratoren finden Befehle, Konfigurationsbeispiele und Prüfschritte im technischen Leitfaden weiter unten.

Was ist passiert? Vom Leak zum Notfall-Patch in 24 Stunden

Die Lücken wurden im Sommer entdeckt und vertraulich an das PHP-Team gemeldet. Geplant war eine geordnete Veröffentlichung, doch Details sickerten vorzeitig durch. Die Chronologie (Uhrzeiten in österreichischer Zeit):

Einige Anbieter zogen sofort die Notbremse: Der Rechnungsdienst easybill nahm seine Plattform vorsorglich vom Netz, ebenso The SEO Framework, Hersteller eines bekannten WordPress-Plugins. Auch die Infrastruktur-Anbieter Hetzner und Exoscale haben bereits reagiert und ihre Partner informiert. Die EU-Cybersicherheitsstelle CERT-EU und das britische NCSC raten: Was sich nicht sofort aktualisieren lässt, gehört vorübergehend offline.

Wichtig für alle mit gemieteten Cloud- oder Root-Servern: Der Anbieter kümmert sich um Hardware, Netz und Rechenzentrum, nicht um das PHP auf Ihrem Server. Die Warnung Ihres Anbieters ist ein Weckruf, kein Patch. Aktualisieren müssen Sie selbst oder Ihr IT-Partner.

Laut Patchstack handelte es sich am frühen Nachmittag noch überwiegend um Abtastversuche, harte Belege für Einbrüche gab es da noch keine. Das wird nicht so bleiben: Der Sicherheitsdienstleister Sansec rechnet mit Massenausnutzung, watchTowr beobachtet bereits Angriffe auf seine Köder-Server.

Für Geschäftsführung und Entscheider: Was PHP2Shell für Ihr Unternehmen bedeutet

PHP ist die Programmiersprache, mit der der Großteil aller Websites auf dem Server erzeugt wird. Ihre Besucher sehen PHP nie, aber fast jede Kontaktanfrage, jede Bestellung und jeder Login auf einer solchen Website läuft darüber. Stellen Sie sich PHP wie das Fundament eines Gebäudes vor: PHP2Shell ist ein Riss in diesem Fundament. Wie gut Türschloss (Passwort) und Alarmanlage (Sicherheits-Plugin) sind, spielt dann keine Rolle mehr. Wer den Riss kennt, kommt hinein, und seit heute kennen ihn alle.

Was für Ihr Unternehmen auf dem Spiel steht

Die Entscheidung, die Sie heute vielleicht treffen müssen

Lässt sich ein System heute nicht aktualisieren, steht eine unbequeme Abwägung an: einige Stunden offline oder online bleiben mit einer offenen Tür, für die es ein öffentliches Angriffswerkzeug gibt. Sicherheitsbehörden wie CERT-EU raten klar dazu, solche Systeme vom Netz zu nehmen.

Unsere Einschätzung: Ein geplanter Ausfall von einigen Stunden ist fast immer billiger als ein ungeplanter von mehreren Wochen. Auf sauber betreuten Systemen dauert ein PHP-Update Minuten bis wenige Stunden, die Aufarbeitung eines Einbruchs dauert Wochen. Wenn Ihre IT heute fragt, ob sie die Website kurz offline nehmen darf, ist die richtige Antwort meistens: ja.

Was Sie nicht tun müssen: in Panik verfallen oder die Laptops Ihrer Mitarbeiter prüfen lassen. PHP2Shell betrifft Server, nicht PCs oder Handys. Wer eine Website nur besucht, ist nicht direkt betroffen.

Warum PHP2Shell so gefährlich ist

Sicherheitslücken gibt es jede Woche. Diese hier ist aus fünf Gründen anders:

Entsprechend deutlich fallen die Einschätzungen aus. Die Forscher von Wiz zählen die Lücken „zu den schwerwiegendsten, die je in PHP entdeckt wurden – und womöglich in der Geschichte der Software überhaupt“. Der bekannte Sicherheitsforscher Kevin Beaumont erwartet eine Welle von Vorfällen. Das PHP-Team bewertet beide Lücken nach CVSS 4.0 mit 9,2 von 10 Punkten. Wie die Fehler technisch funktionieren, erklären wir im technischen Leitfaden.

Unsere Einschätzung: Das ist eine der seltenen Lücken, bei denen wir nicht „zeitnah“ sagen, sondern „heute“. Die Angriffe liefen schon vor dem Patch, das Werkzeug dafür ist öffentlich, und betroffen ist die Grundlage von Millionen Websites. Wer bis zum nächsten Wartungsfenster wartet, wartet zu lange.

Bin ich betroffen?

Kurz gesagt: Wenn auf Ihrem Server PHP läuft und es heute noch nicht aktualisiert wurde, dann ja. Das betrifft weit mehr als klassische Websites:

Betroffen sind alle gängigen Betriebsarten von PHP: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei Apache mit mod_php.

Diese PHP-Versionen sind sicher

So finden Sie Ihre PHP-Version heraus

Achtung, die Versionsnummer kann täuschen. Linux-Distributionen spielen Sicherheitskorrekturen oft in die alte Versionsnummer ein. Ubuntu 24.04 zeigt nach dem Update zum Beispiel weiterhin „8.3.6“ an; entscheidend ist das Paket 8.3.6-0ubuntu0.24.04.13. Umgekehrt beweist eine aktuelle Nummer nichts, solange PHP nicht neu gestartet wurde. Bei Hosting-Paketen gilt deshalb: Lassen Sie sich das Update von Ihrem Anbieter bestätigen.

Was jetzt zu tun ist: Ihre To-do-Liste

Wenn Ihre Website bei einem Hoster oder einer Agentur liegt

Wenn Sie eigene Server betreiben

Die Kurzfassung in fünf Schritten: Bestand erfassen (alle Server, Container und Anwendungen mit PHP), aus der richtigen Quelle aktualisieren (dort, wo PHP herkommt), richtig neu starten (bei Apache mit mod_php reicht ein „graceful“-Reload nicht), kontrollieren, dass kein Prozess mehr die alte Version nutzt, und danach Übergangsmaßnahmen zurückbauen. Alle Befehle, Paketversionen und Konfigurationsbeispiele finden Sie im technischen Leitfaden weiter unten.

Heute nicht patchbar? Diese Notlösungen gibt es, und ihre Grenzen

Das PHP-Projekt ist eindeutig: „Aktualisieren ist die einzig sichere Wahl.“ Alle folgenden Maßnahmen verkleinern nur die Angriffsfläche, die Lücke schließen sie nicht. Sie sind für die Stunden gedacht, bis das Update eingespielt ist:

Was nicht hilft: Fehlermeldungen auszublenden, WordPress-, Plugin- oder Theme-Updates und Sicherheits-Plugins innerhalb der Website. Die Angriffe setzen an, bevor solche Plugins greifen können; Sansec rät deshalb ausdrücklich davon ab, sich auf den eigenen Anwendungsschutz zu verlassen.

Nach dem Update: Wurde ich schon angegriffen?

Das Update schließt die Tür. Wer schon drinnen ist, bleibt aber drinnen. Wie das in der Praxis aussieht, haben wir erst im September an einem echten Fall beschrieben: WordPress gehackt – und warum ein Backup allein nicht hilft. Prüfen Sie deshalb nach dem Patch, ob es Anzeichen eines Angriffs gibt:

Keines dieser Zeichen beweist einen Einbruch, und ihr Fehlen beweist nicht das Gegenteil. Bei Auffälligkeiten behandeln Sie den Server als möglicherweise kompromittiert. Weil die Lücke Speicherinhalte preisgeben kann, erneuern Sie dann alle Geheimnisse, die der Server kennt: Datenbank-Passwörter, Admin-Zugänge, API-Schlüssel von Zahlungs- und Mail-Diensten, die WordPress-Salts und gegebenenfalls TLS-Zertifikate. Konkrete Prüfbefehle stehen im technischen Leitfaden.

Hatten Angreifer möglicherweise Zugriff auf personenbezogene Daten, kann eine Meldung an die Datenschutzbehörde binnen 72 Stunden nötig sein. Was die DSGVO dabei verlangt, haben wir im selben Beitrag zusammengefasst. Hinweise auf Angriffe können Sie außerdem an CERT.at melden.

wp2shell im Juli, PHP2Shell im Oktober: Was wir daraus lernen

Im Juli war es „wp2shell“, eine Lückenkette im WordPress-Kern. Jetzt trifft es mit PHP2Shell die Ebene darunter. Beide Male gilt: Wer schnell aktualisiert, ist auf der sicheren Seite. Wer erst nach Wochen reagiert, räumt womöglich einen Einbruch auf. Genau so war es in dem Fall, den wir im September beschrieben haben. Sechs Lehren für jedes Unternehmen:

Auf den aktuellen Patchstand: gemeinsam mit Infrastruktur und Entwicklungspartnern

Bei einer Standard-Website mit aktuellem WordPress ist ein PHP-Update meist schnell erledigt. Schwieriger wird es bei individuellen Webanwendungen, Kundenportalen und Schnittstellen und bei allem, was noch auf PHP 8.1 oder älter läuft. Dort reicht es nicht, auf dem Server einen Schalter umzulegen: Der Code der Anwendung muss mit der neuen PHP-Version zusammenspielen. Sonst ist die Seite zwar sicher, aber kaputt.

Deshalb arbeitet die SKAWINSKI GmbH mit zahlreichen Softwareentwicklungspartnern zusammen, darunter Smaracis. Die Aufgaben sind klar verteilt: Wir kümmern uns um die Infrastruktur, also Server, Betriebssystem, Webserver und PHP. Unsere Entwicklungspartner kümmern sich um den Code der Anwendung. So bringen wir Kunden gemeinsam auf den aktuellen Patchstand:

1. Bestandsaufnahme: Welche Systeme laufen mit welcher PHP-Version, und wer hat die Anwendung entwickelt?
2. Sofortschutz: Wo das Update nicht sofort möglich ist, sichern wir die Systeme übergangsweise ab oder nehmen sie kontrolliert vom Netz.
3. Kompatibilität prüfen: Unsere Entwicklungspartner prüfen den Code auf die neue PHP-Version und passen ihn bei Bedarf an, etwa beim Umstieg von PHP 8.1 auf 8.4 oder 8.5.
4. Erst testen, dann einspielen: Update und Anpassungen laufen zuerst auf einer Testumgebung und erst danach im Live-Betrieb.
5. Automatisieren und dranbleiben: Danach sorgen automatisches Patching, Monitoring und regelmäßige Kontrollen dafür, dass der Patchstand aktuell bleibt.

Betreut schon ein eigener Entwickler oder eine Agentur Ihre Anwendung, stimmen wir uns direkt mit ihnen ab. Wichtig ist nur, dass am Ende niemand auf den anderen wartet, während der Server offen steht.

Technischer Leitfaden für IT-Teams und Administratoren

Dieser Abschnitt richtet sich an alle, die PHP-Server selbst betreiben. Die Befehle beziehen sich auf gängige Linux-Systeme; Pfade, Dienstnamen und PHP-Versionen (hier meist 8.3) passen Sie an Ihre Umgebung an. Prüfen Sie Befehle vor dem Einsatz auf Produktivsystemen.

1. Die Lücken im Detail

Beide sind Use-after-free-Fehler, ausgelöst durch einen schweren Fehler, typischerweise das Überschreiten von memory_limit, mitten in der Verarbeitung einer Anfrage. Die öffentlich beschriebenen Angriffswege laufen laut Sansec über die Verarbeitung des Upload-Fortschritts von Sitzungen (session.upload_progress), über Backtraces bei Fatal Errors (fatal_error_backtraces, neu in PHP 8.5) und über eine Typverwechslung im OPcache. Alle bekannten Auslöser nutzen multipart/form-data-Anfragen. Das öffentliche Werkzeug „PHP2Shell“ kombiniert beide Fehler zu einem Angriff ohne Anmeldung; einer der Pfade liest zusätzlich Speicher aus, ähnlich wie Heartbleed.

Daraus ergeben sich drei Eigenheiten, die für die Abwehr wichtig sind:

• Der Angriff greift vor dem Anwendungscode. PHP verarbeitet den Request-Body, bevor ein Skript startet; für mod_php ist ein Angriff vor jeglichem Anwendungscode demonstriert. Schutzmechanismen innerhalb der Anwendung, Wartungsmodi und Sicherheits-Plugins kommen deshalb zu spät.
• Kein session_start() nötig. Upload-Progress ist standardmäßig aktiv und wird beim Parsen der Anfrage ausgewertet. Auch Anwendungen ohne Sitzungen sind angreifbar.
• Langlebige Worker tragen den Zustand weiter. Apache-Prozesse mit mod_php und FPM-Worker bearbeiten viele Anfragen nacheinander. Genau das nutzt CVE-2026-109619 aus.

2. Bestandsaufnahme: Wo läuft überall PHP?

Laufende PHP- und Webserver-Prozesse:

ps -eo pid,user,cmd | grep -E 'php-fpm|lsphp|php-cgi|frankenphp|apache2|httpd' | grep -v grep

Installierte PHP-Pakete unter Debian und Ubuntu bzw. Red Hat, AlmaLinux und Rocky Linux:

dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
rpm -qa 'php*' | sort
dnf module list --enabled php

Container und Kubernetes:

docker ps --format '{{.Names}}  {{.Image}}'
kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | sort -u | grep -i php

Vergessen Sie nicht: Staging- und Testsysteme, Cron-Jobs und Queue-Worker, Container-Images in Registries und CI-Pipelines, Appliances mit Weboberfläche sowie Anwendungen wie Nextcloud, Roundcube oder phpMyAdmin, die oft nebenbei laufen.

3. Aktualisieren: Pakete und Quellen

Grundregel: Aktualisieren Sie aus derselben Quelle, aus der PHP installiert wurde. Linux-Distributionen und Anbieter mit Langzeit-Support haben die Korrekturen vorab erhalten.

Ubuntu. Korrigierte Pakete laut Canonical: 22.04 LTS php8.1 8.1.2-1ubuntu2.28, 24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13, 26.04 LTS php8.5 8.5.4-0ubuntu1.5. Für 20.04 und älter gibt es Korrekturen nur über Ubuntu Pro (ESM), etwa php7.4 7.4.3-4ubuntu2.29+esm5 für 20.04.

sudo apt update
sudo apt install --only-upgrade '?name(^php[0-9.]+$)'

Debian sowie PPA und packages.sury.org. Ausstehende PHP-Updates anzeigen und gezielt einspielen, je PHP-Version auf dem Server:

sudo apt-get update
apt list --upgradable 2>/dev/null | grep php
sudo apt-get install --only-upgrade 'php8.3*' libapache2-mod-php8.3

Den Stand für Ihre Debian-Version zeigt der Debian Security Tracker. Bei PPA- und Sury-Paketen steht im Changelog oft nur „New upstream version“; vergleichen Sie dann die Versionsnummer mit den korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Red Hat, AlmaLinux, Rocky Linux:

sudo dnf upgrade 'php*'
dnf updateinfo list --security | grep php
rpm -q --changelog php-fpm | head -5

Achtung bei RHEL 8: Ein einfaches dnf install php installiert den ausgelaufenen PHP-7.2-Stream, der keine Korrekturen mehr erhält. Remi-Pakete im SCL-Stil heißen anders (etwa php84-php-fpm) und werden mit sudo dnf upgrade 'php84-*' aktualisiert. Das Remi-Repository hatte laut PHP-Projekt am 21. Oktober aber noch keine Updates. Weichen Sie dort auf Distributionspakete aus oder bauen Sie aus dem Quellcode.

Docker und Kubernetes. Image mit docker build --pull neu bauen und die Container neu erstellen; in Kubernetes nach dem Image-Update kubectl rollout restart deployment/<name>. Die Release-Candidate-Images 8.5.12RC1 und 8.4.27RC1 enthalten die Korrektur nicht.

FrankenPHP bringt sein eigenes PHP mit: neues Release bzw. Image installieren und mit frankenphp version prüfen. Paketmanager wie apt oder dnf aktualisieren es nicht.

PHP 7.4, 8.0 und 8.1 aus dem Quellcode: Das PHP-Team stellt minimale Korrekturen in eigenen Zweigen bereit (PHP-7.4-CVE-2026-109618-109619, PHP-8.0-…, PHP-8.1-… im Repository php/php-src). Diese Notkorrektur schaltet den Upload-Fortschritt vollständig ab; Fortschrittsbalken bei Uploads funktionieren danach nicht mehr. Das ist eine Überbrückung, kein Ersatz für den Umstieg.

4. Richtig neu starten

5. Kontrollieren

Kein Prozess darf mehr ein gelöschtes, also altes PHP-Binary oder -Modul im Speicher haben. Leere Ausgabe ist das Ziel:

sudo grep -lE ' /(usr|lib|opt).*[(]deleted[)]$' /proc/[0-9]*/maps

Unter Debian und Ubuntu erledigt needrestart dasselbe komfortabler, und unter Ubuntu bestätigt der Changelog die Korrektur:

sudo needrestart -b -r l
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

Prüfen Sie geänderte PHP-Einstellungen immer über eine echte Webanfrage, die PHP-FPM bzw. Apache beantwortet, nicht auf der Kommandozeile: CLI und Webserver nutzen oft unterschiedliche Konfigurationen.

6. Übergangsmaßnahmen: Konfigurationsbeispiele

Nur für die Zeit bis zum Patch, und mit Nebenwirkungen. Uploads am Webserver sperren (bricht Datei-Uploads und manche Formulare und Checkouts; danach eine Testbestellung durchführen). nginx, in jedem server-Block, der PHP ausliefert:

if ($http_content_type ~* "multipart/form-data") { return 403; }

Apache, in jedem VirtualHost, der PHP ausliefert:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Nur Lesezugriff (nginx): Besucher können lesen, aber nicht anmelden oder bestellen.

if ($request_method !~ ^(GET|HEAD)$) { return 503; }

PHP-Einstellungen für Apache mit mod_php (php.ini oder conf.d, danach Apache vollständig neu starten):

session.upload_progress.enabled = 0
memory_limit = -1
; nur PHP 8.5:
fatal_error_backtraces = 0

Für PHP-FPM in jedem Pool, zum Beispiel /etc/php/8.3/fpm/pool.d/www.conf, danach alle Worker neu starten:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1

Zusätzlich empfiehlt das PHP-Team ein niedriges post_max_size (8M ohne Uploads, 32M mit Uploads; upload_max_filesize darunter) sowie Grenzen am Webserver oder Proxy für Anfragegröße, Anzahl der Felder, Multipart-Teile und Header, auch für Anfragen ohne brauchbares Content-Length. Wichtig:

• Die Werte gehören in die php.ini, den FPM-Pool oder die Server-Konfiguration. ini_set() und .user.ini greifen zu spät.
• memory_limit = -1 erlaubt einer einzigen Anfrage, den gesamten Arbeitsspeicher zu belegen. Begrenzen Sie den Speicher stattdessen per Container- oder cgroup-Limit, das möglichst nur den betroffenen Worker beendet, und überwachen Sie den RAM. RLIMIT_AS oder RLIMIT_DATA sollten Sie nicht verwenden: Sie können genau den verwundbaren Speicherfehler auslösen.
• Fehlermeldungen auszublenden (error_reporting, display_errors, @) hilft nicht.
• Diese Einstellungen blockieren laut PHP-Team die bestätigten Angriffswege, aber nicht alle Varianten.

Cloudflare: Im kostenlosen Tarif greift das Free Managed Ruleset automatisch. In bezahlten Tarifen muss das Cloudflare Managed Ruleset auf „Block“ stehen. Geblockte Anfragen sehen Sie unter Security → Security Analytics → Events. Wirksam ist das nur, wenn Ihr Server ausschließlich Verkehr von Cloudflare annimmt.

7. Spurensuche nach dem Patch

Speicherfehler und abgestürzte Worker in den Logs (Pfade je nach System). Gehäufte Speicherfehler kurz nach Upload-Anfragen und Worker, die mit SIGSEGV oder SIGABRT abstürzen, können auf Angriffsversuche hindeuten:

grep -h "Allowed memory size" /var/log/php*-fpm.log /var/log/apache2/error.log 2>/dev/null | tail -n 50
grep -h "exited on signal" /var/log/php*-fpm.log 2>/dev/null | tail -n 50

Neue oder geänderte PHP-Dateien, insbesondere in Upload-Verzeichnissen:

find /var/www -type f -name '*.php' -mtime -3 -ls
find /var/www -path '*/uploads/*' -name '*.php'

Unerwartete ausgehende Verbindungen von PHP- oder Webserver-Prozessen, etwa zu fremden Servern:

sudo ss -tnp state established | grep -E 'php|apache2|httpd|lsphp'

Für WordPress zusätzlich, ohne Plugins und Theme zu laden, damit möglicher Schadcode nicht mitstartet:

wp core verify-checksums --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes
wp user list --role=administrator --skip-plugins --skip-themes

Große oder fehlerhafte PHPSESSID-Cookies finden Sie nur, wenn Ihre Logs Cookies erfassen; das ist meist nicht der Fall. Bei Auffälligkeiten: Server isolieren, Beweise sichern, bevor Sie etwas löschen, und alle Geheimnisse erneuern, die der Server kennt. Dazu gehören Datenbank- und Admin-Passwörter, API-Schlüssel, die WordPress-Salts (wp config shuffle-salts) sowie TLS-Zertifikate, die Sie widerrufen und neu ausstellen lassen.

8. Nach dem Patch: zurückbauen und härten

Häufige Fragen (FAQ)

Fazit: Heute patchen, morgen prüfen, übermorgen planen

PHP2Shell ist keine Lücke, die man ins nächste Wartungsfenster schiebt. Ein Angriff braucht keine Anmeldung, die Werkzeuge sind öffentlich, und betroffen ist die Grundlage von rund 70 Prozent aller Websites mit bekannter Server-Technik. Die gute Nachricht: Die Abhilfe ist klar. Heute PHP aktualisieren und neu starten oder, wo das nicht geht, vom Netz nehmen. Morgen prüfen, ob schon jemand drinnen war. Und übermorgen dafür sorgen, dass beim nächsten Mal feststeht, wer zuständig ist, und dass Patches automatisch, kontrolliert und in Stunden statt Wochen ankommen. Das ist kein Hexenwerk, sondern Handwerk mit den richtigen Werkzeugen: automatisches Patching, IT-Automatisierung und jemand, der Probleme verhindert, statt nur auf sie zu reagieren. Genau das verstehen wir unter proaktiver IT-Betreuung.

So unterstützt Sie SKAWINSKI – Ihr IT-Partner für Patchmanagement, Server und Website-Sicherheit

Als IT-Dienstleister für den DACH-Raum unterstützt die SKAWINSKI GmbH kleine und mittlere Unternehmen dabei, kritische Lücken wie PHP2Shell schnell und kontrolliert zu schließen und danach den Überblick zu behalten: welche Systeme laufen, wer sie aktualisiert und ob die Updates wirklich angekommen sind. Mit IT-Automatisierung und automatischem Patching wird daraus ein verlässlicher Ablauf statt einer Feuerwehraktion. Das bieten wir im Rahmen unserer proaktiven IT-Betreuung, als Managed Services aus Österreich oder als IT-Betreuung für kleine Unternehmen ohne eigene IT-Abteilung.

Unsicher, ob Ihre Website schon abgesichert ist? Rufen Sie uns direkt an: +43 660 509 2494. Ob Patchstände, Backups und Zugänge in Ihrer gesamten IT wirklich stimmen, zeigt ein IT-Healthcheck: Sie erhalten in 2–3 Wochen einen Bericht mit priorisierten Maßnahmen. Für die laufende Überwachung sorgt unser kontinuierliches IT-Monitoring.

„Wir fangen da an, wo andere aufhören.“

– Robert Skawinski · SKAWINSKI GmbH

Quellen: PHP Group, Sicherheitsankündigung vom 20.10.2026 und Releases vom 21.10.2026 im php.net-Nachrichtenarchiv 2026; PHP Security Advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619); Sansec, „PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)“, 21.10.2026; Patchstack, „Major security alert: PHP vulnerable to critical RCE, attacks ongoing“, 21.10.2026; Cloudflare, „Cloudflare deploys protections against php2shell vulnerability“, 21.10.2026; Help Net Security, „PHP2Shell: Critical PHP vulnerabilities patched, update now!“, 21.10.2026; watchTowr, „PHP Remote Code Execution FAQ: CVE-2026-109618“, 21.10.2026; Canonical, „php2shell (CVE-2026-109618 and CVE-2026-109619)“; ma.ttias.be, „PHP CVE-2026-109618 and CVE-2026-109619: how to apply the patches“; netzwelt, „Kritische PHP-Lücke: EU-Behörde warnt – erste Websites gehen aus Sicherheitsgründen offline“, 21.10.2026; W3Techs, „Historical trends in the usage statistics of server-side programming languages“, Stand 27.08.2026; Art. 20 und 21 NIS2-Richtlinie (EU) 2022/2555; Art. 32 und 33 DSGVO; eigene Recherchen der SKAWINSKI GmbH (Stand 21.10.2026): erhöhtes Aufkommen bestimmter Anfragen, bisher keine betroffenen Kunden.

Dieser Beitrag wurde mit KI-Unterstützung durch die SKAWINSKI GmbH erstellt und redaktionell geprüft.