#  Sicherheitslücken im Web: Warum sie dazugehören – und wie man richtig damit umgeht

    Details    Geschrieben von: [Lukas Jardin](https://www.djumla.de/autoren/lukas-jardin)    Veröffentlicht: 21. Oktober 2026

  ![](https://www.djumla.de/images/insights/Extended_LTS.png)

 **Kurz zusammengefasst:** Die aktuellen kritischen PHP-Schwachstellen sind kein Einzelfall, sondern Normalzustand. Software wird von Menschen gemacht, also enthält sie Fehler. Entscheidend ist nicht, ob eine Lücke auftritt, sondern wie schnell und strukturiert darauf reagiert wird – vom Hersteller, vom Hoster und von Ihnen als Website-Betreiber. Dieser Ratgeber erklärt, wie der Umgang mit Sicherheitslücken hinter den Kulissen funktioniert, warum dieses Thema bei uns tief in der DNA steckt und was Sie konkret tun können, um beim nächsten Vorfall gut vorbereitet zu sein.

  ## Der Anlass: zwei kritische Lücken in PHP

Aktuell beschäftigt die Branche eine außerplanmäßige Sicherheitsveröffentlichung der PHP-Entwickler. Betroffen ist die Verarbeitung bestimmter Datenübertragungen an den Server – konkret sogenannte Multipart-POST-Requests, also genau das, was passiert, wenn jemand ein Formular absendet oder eine Datei hochlädt. Beschrieben wird ein Weg, über den sich ohne vorherige Anmeldung Code auf dem Server ausführen lässt, und die Schwachstellen wurden als kritisch eingestuft. Da PHP auf einem Großteil aller Websites läuft, ist die potenzielle Reichweite enorm. Konkret geht es um: [CVE-2026-109618 (9.2) und CVE-2026-109619 (9.2)](https://cert.europa.eu/publications/security-advisories/2026-018).

Das Unangenehme an dieser Lage: Zum Zeitpunkt der Vorankündigung stand noch kein Patch bereit, während zu den Lücken bereits Details und Proof-of-Concept-Code öffentlich kursierten. Genau solche Situationen – Lücke bekannt, Fix noch nicht verfügbar – sind der Härtetest für jeden Sicherheitsprozess.

Doch so unangenehm der Einzelfall ist: Er ist nichts Außergewöhnliches. Und das ist der eigentliche Punkt dieses Beitrags.

  ## Sicherheitslücken sind keine Ausnahme, sondern Normalzustand

Es gibt eine Vorstellung, die sich hartnäckig hält: Eine Sicherheitslücke sei ein Skandal, ein Beweis für schlechte Arbeit, ein Versagen. Diese Vorstellung ist nachvollziehbar – aber sie ist falsch, und sie ist gefährlich, weil sie zu den falschen Schlüssen führt.

Moderne Websites sind komplexe Systeme. Ein typisches Joomla-Projekt besteht nicht aus „einer Software“, sondern aus einem Stapel voneinander abhängiger Schichten:

- dem **Betriebssystem** des Servers
- dem **Webserver** (Apache, nginx)
- der **Programmiersprache** PHP
- der **Datenbank** (MySQL/MariaDB)
- dem **Content-Management-System** selbst (Joomla)
- **Templates** wie YOOtheme Pro
- einem **Dutzend oder mehr Erweiterungen** von verschiedenen Anbietern
- und den unzähligen **Bibliotheken**, die in all dem stecken

Das sind in Summe Millionen Zeilen Code, geschrieben von tausenden Menschen über zwei Jahrzehnte. Dass darin Fehler stecken, ist keine Frage der Sorgfalt, sondern der Statistik. Jede dieser Schichten kann morgen eine kritische Lücke haben.

Deshalb lautet die realistische Frage nicht: *„Wie verhindere ich, dass es jemals eine Lücke gibt?“* – sondern: *„Wie bin ich organisiert, wenn die nächste kommt?“*

  ## Wie wird mit Sicherheitslücken im Web eigentlich umgegangen?

Hinter einer Meldung wie „kritische Lücke, bitte sofort updaten“ steckt ein eingespieltes Verfahren, das die meisten Anwender nie zu sehen bekommen. Es lohnt sich, es zu kennen – denn wer den Prozess versteht, kann die Dringlichkeit einer Meldung besser einschätzen.

### 1. Entdeckung und vertrauliche Meldung (Responsible Disclosure)

Lücken werden von Sicherheitsforschern, Entwicklern, Agenturen oder aufmerksamen Anwendern gefunden. Der gute Weg ist nicht der Tweet, sondern die vertrauliche Meldung an das zuständige Sicherheitsteam. Fast alle größeren Projekte haben dafür eine eigene Adresse und eine veröffentlichte Security Policy. Beim Joomla-Projekt übernimmt das das **Joomla! Security Strike Team (JSST)**, dessen Verfahren öffentlich dokumentiert ist.

Dieses Prinzip heißt *Responsible Disclosure* oder *Coordinated Disclosure*: Der Finder gibt dem Hersteller Zeit, das Problem zu beheben, bevor Details öffentlich werden. Im Gegenzug wird er in der späteren Veröffentlichung namentlich genannt – Anerkennung statt Alleingang.

### 2. Verifikation und Bewertung

Das Sicherheitsteam prüft: Ist die Meldung reproduzierbar? Welche Versionen sind betroffen? Was kann ein Angreifer tatsächlich erreichen? Daraus ergibt sich eine Einstufung, üblicherweise über den **CVSS-Score** (eine Skala von 0 bis 10). Dabei zählt nicht nur der theoretische Schaden, sondern auch, wie leicht die Lücke ausnutzbar ist: Braucht es einen Login? Admin-Rechte? Oder genügt eine anonyme Anfrage von außen? Letzteres ist der Worst Case – und genau die Konstellation der aktuellen PHP-Lücken.

Parallel wird eine **CVE-Nummer** beantragt. Das ist die weltweit eindeutige Kennung einer Schwachstelle (Format: CVE-Jahr-Nummer), damit alle Beteiligten über dasselbe Problem sprechen.

### 3. Entwicklung des Fixes unter Embargo

Jetzt wird es heikel. Der Fix muss entwickelt und getestet werden – und zwar möglichst ohne dass dabei durchsickert, worum es geht. Denn sobald die Art der Lücke bekannt ist, beginnt ein Wettlauf: Angreifer brauchen oft nur Stunden, um einen funktionierenden Exploit zu bauen, während Website-Betreiber Tage brauchen, um zu updaten.

Deshalb arbeiten Sicherheitsteams unter **Embargo**: kleiner Kreis, keine öffentlichen Code-Commits mit verräterischen Kommentaren, Vorankündigung des Release-Termins ohne inhaltliche Details. Genau dieses Muster war bei der aktuellen PHP-Veröffentlichung zu beobachten – und ebenso, was passiert, wenn das Embargo bricht und Informationen vorzeitig an die Öffentlichkeit gelangen. Dann müssen Teams ihre Zeitpläne vorziehen und Betreiber mit Übergangsmaßnahmen arbeiten.

### 4. Veröffentlichung von Patch und Advisory

Zum vereinbarten Zeitpunkt erscheinen Fix und Sicherheitshinweis gemeinsam. Das Advisory nennt betroffene Versionen, Schweregrad, CVE-Nummer und die empfohlene Maßnahme – aber bewusst **keine Schritt-für-Schritt-Anleitung** zur Ausnutzung.

### 5. Mitigation, wenn kein Patch verfügbar ist

Manchmal klafft eine Lücke zwischen Bekanntwerden und Patch. Dann greifen **Übergangsmaßnahmen** (Mitigations): das Abschalten einer betroffenen Funktion, Filterregeln in Webserver oder Firewall, im Extremfall die vorübergehende Abschaltung eines Dienstes. Das ist unbequem, kostet unter Umständen Umsatz – ist aber in aller Regel die günstigere Variante gegenüber einem kompromittierten Server mit abgeflossenen Kundendaten.

**Wichtig zu wissen: Mitigations sind ein Notbehelf, kein Ersatz für den Patch.**

### 6. Die Verantwortungsgrenze: Core vs. Erweiterungen

Ein Punkt, der in der Praxis viel Verwirrung stiftet: Ein Projekt-Sicherheitsteam ist für den eigenen Code zuständig. Das JSST betreut Joomla-Core und Framework – Lücken in **Erweiterungen und Templates von Drittanbietern** liegen in der Verantwortung des jeweiligen Herstellers.

Das ist relevant, weil ein großer Teil realer Einbrüche nicht über den Core läuft, sondern über eine veraltete Erweiterung, die vor vier Jahren installiert und seither nie aktualisiert wurde. Ein aktuelles Joomla auf einem veralteten Erweiterungs-Fundament ist wie eine Sicherheitstür in einer Wand aus Pappe.

  ## Das Thema IT-Security ist bei djumla kein Nebenschauplatz

An dieser Stelle wird es persönlich. Sicherheit ist bei uns kein Service-Baustein, den man dem Angebot hinzufügt, weil es sich gut liest – sie ist ein Teil unserer Arbeitsidentität.

Unser Geschäftsführer [**David Jardin ist seit 2014 Mitglied im Joomla! Security Strike Team und leitet dieses Team als Team Lead**](https://magazine.joomla.org/issues/2022/july-2022/meet-the-team-joomla-security-strike-team). Er sitzt also auf der anderen Seite des oben beschriebenen Prozesses: bei der Verifikation eingehender Meldungen, bei der Bewertung von Schweregraden, bei Entscheidungen über Embargos und Veröffentlichungszeitpunkte, bei der Formulierung von Advisories.

Was das für unsere Kund:innen praktisch bedeutet:

- **Wir verstehen Meldungen, statt sie zu übersetzen.** Wenn ein Advisory erscheint, können wir aus eigener Erfahrung einschätzen, ob „kritisch“ bedeutet „heute Abend“ oder „diese Woche“ – und ob ein konkretes Projekt überhaupt betroffen ist.
- **Wir kennen die Lage oft früh.** Die Arbeit in Sicherheitsstrukturen bedeutet Zugang zu einem Netzwerk, in dem sich relevante Entwicklungen schnell herumsprechen. Dass bei der aktuellen PHP-Lage der Hinweis zu behördlichen Empfehlungen aus Österreich über Kolleg:innen zu uns kam und nicht über die Tagespresse, ist kein Zufall, sondern Ergebnis dieser Vernetzung.
- **Wir haben eine klare Haltung bei unbequemen Entscheidungen.** Wer einmal gesehen hat, wie ein kompromittierter Server aussieht und was die Aufräumarbeiten kosten, diskutiert nicht lange über einen Tag eingeschränkte Formularfunktion.
- **Wir bauen Projekte mit dieser Brille.** Sicherheitsüberlegungen fließen in Architektur, Erweiterungsauswahl und Hosting-Empfehlung ein – nicht erst in den Wartungsvertrag.

Wir sagen das nicht, um uns auf die Schulter zu klopfen. Wir sagen es, weil die Frage „Woher weiß ich, ob meine Agentur das Thema ernst nimmt?“ für Laien schwer zu beantworten ist – und weil nachprüfbares Engagement in offenen Sicherheitsstrukturen einer der wenigen belastbaren Indikatoren dafür ist.

  ## Ihre Checkliste: gut vorbereitet auf die nächste Lücke

Die nächste kritische Schwachstelle kommt. Vielleicht in drei Wochen, vielleicht in acht Monaten. Wer die folgenden Punkte geklärt hat, erlebt sie als handhabbare Aufgabe statt als Krise.

1. **Klären Sie Zuständigkeiten – schriftlich.**Wer spielt Joomla-Updates ein? Wer Erweiterungen? Wer ist für PHP und Serverkonfiguration verantwortlich? Wer wird nachts angerufen? Die unangenehme Wahrheit: Bei vielen Websites lautet die Antwort auf mindestens eine dieser Fragen „niemand“ – und das merkt man erst, wenn es brennt.
2. **Halten Sie alles aktuell – inklusive der Erweiterungen.**Updates sind kein Komfortthema. Besonders kritisch sind Erweiterungen, deren Hersteller die Entwicklung eingestellt haben: Für die wird es nie einen Patch geben. Solche Komponenten gehören ersetzt, nicht geduldet.
3. **Nutzen Sie eine aktuelle, unterstützte PHP-Version.**PHP-Versionen haben ein definiertes Lebensende. Läuft Ihre Seite auf einer Version ohne Sicherheitssupport, bekommen Sie Patches schlicht nicht mehr – egal wie schnell Ihre Agentur reagiert.
4. **Wählen Sie Ihr Hosting bewusst.**Hier liegt ein oft unterschätzter Hebel. Im klassischen Shared Hosting bei Großanbietern können weder Sie noch Ihre Agentur serverseitige Schutzmaßnahmen umsetzen – Sie sind vollständig auf das Reaktionstempo des Providers angewiesen. Bei verwalteten oder eigenen Servern lassen sich Mitigations innerhalb von Minuten greifen. Das ist eine Kosten-Kontrolle-Abwägung, die man einmal bewusst treffen sollte, statt sie dem Zufall zu überlassen.
5. **Backups: automatisiert, extern, getestet.**Ein Backup, das noch nie zurückgespielt wurde, ist eine Hoffnung, kein Backup. Wichtig ist außerdem die Aufbewahrungsdauer: Kompromittierungen bleiben manchmal wochenlang unentdeckt. Wer nur sieben Tage vorhält, stellt im Zweifel die bereits infizierte Version wieder her.
6. **Richten Sie Monitoring ein.**Dateiänderungs-Überwachung, Uptime-Checks und die Google Search Console kosten wenig und verkürzen die Entdeckungszeit drastisch.
7. **Halten Sie Informationskanäle offen.**Abonnieren Sie die Sicherheitsmeldungen Ihres CMS und die Statusseite Ihres Hosters. Und: Lesen Sie die Mails Ihrer Agentur zu diesem Thema. Ja, auch die langen.
8. **Minimieren Sie die Angriffsfläche.**Jede nicht genutzte Erweiterung, jedes alte Testverzeichnis, jeder vergessene Admin-Zugang ist eine zusätzliche Tür. Deinstallieren ist sicherer als deaktivieren.

 ## Woran Sie einen Vorfall erkennen – und was dann zu tun ist

**Typische Warnsignale für eine kompromittierte Website sind:**

- Inhalte, Seiten oder Benutzerkonten, die niemand angelegt hat
- Weiterleitungen auf fremde oder dubiose Seiten – häufig nur für Besucher von Suchmaschinen oder nur auf Mobilgeräten
- unerklärliche Performance-Einbrüche
- Warnmeldungen von Google oder Hinweise der Search Console
- Spam-Versand über Ihre Domain, Beschwerden von Empfängern
- plötzliche Fehlermeldungen, weiße Seiten, veränderte Dateien

**Im Ernstfall gilt:**

1. Nicht in Panik löschen. Spuren sind wertvoll, um Einbruchsweg und Umfang zu bestimmen.
2. Website vom Netz nehmen oder in Wartungsmodus setzen, um Besucher zu schützen.
3. Forensisches Backup des aktuellen Zustands anlegen – vor jeder Bereinigung.
4. Alle Passwörter und Zugangsdaten ändern: Backend, FTP/SSH, Datenbank, Hosting-Panel.
5. Fachliche Hilfe holen. Eine Bereinigung, die nur sichtbaren Schadcode entfernt, aber die Hintertür übersieht, führt zuverlässig zum zweiten Vorfall.
6. Datenschutz prüfen. Bei möglichem Abfluss personenbezogener Daten können Meldepflichten mit engen Fristen bestehen.

 ## Der aktuelle Stand in der Joomla-Welt: Die Zahlen steigen – aber anders, als man denkt

Wie sehr sich die Lage verändert hat, lässt sich an den registrierten CVE-Einträgen für das Joomla-Ökosystem ablesen. Unser Geschäftsführer David Jardin hat diese Entwicklung auf der **Joomla World Conference** vorgestellt – und die Kurve ist eindeutig.

 ![Balkendiagramm der registrierten CVEs im Joomla-Ökosystem von 2020 bis 2026, getrennt nach Core und Drittanbieter-Erweiterungen. Während die Core-Werte über Jahre im niedrigen zweistelligen Bereich liegen, steigen die Drittanbieter-Werte 2025 und besonders 2026 stark an.](https://www.djumla.de/images/insights/Export_Chart_CVE-IDs_Joomla.png)Registrierte CVEs im Joomla-Ökosystem 2020–2026, getrennt nach Core und Drittanbieter-Erweiterungen.In den Jahren 2020 bis 2024 bewegte sich die Zahl der Schwachstellen im Joomla-Core im niedrigen zweistelligen Bereich: 7 CVEs im Jahr 2020, 24 im Jahr 2021, danach 24 bzw. 14 pro Jahr. Bei Erweiterungen und Templates von Drittanbietern sah es zunächst noch unauffälliger aus – 2020 und 2021 keine Einträge, 2022 eine Handvoll, 2023 waren es 35, 2024 wieder nur sechs.

Dann kippte das Bild. 2025 vervielfacht sich die Zahl der Drittanbieter-CVEs auf 44, während der Core weiterhin bei unter zehn Meldungen (7) lag. Und 2026 explodierten die Zahlen regelrecht: rund 290 CVEs für Erweiterungen von Drittanbietern – mehr als in allen Vorjahren zusammen – und mit etwa 60 Einträgen auch ein Rekordwert für den Core (Stand Oktober 2026). Für das Gesamtjahr 2026 werden über 500 registrierte CVE-IDs im Joomla-Umfeld erwartet.

  Registrierte CVE-IDs im Joomla-Ökosystem 2020–2026, getrennt nach Core und Drittanbieter-Erweiterungen
| Bereich | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026 |
|---|---|---|---|---|---|---|---|
| Core | 7 | 24 | 13 | 6 | 18 | 7 | 62 |
| 3rd Party | 0 | 0 | 3 | 25 | 6 | 44 | 294 |
| Gesamt | 7 | 24 | 16 | 31 | 24 | 51 | 356 |

Diese Zahlen lassen sich leicht falsch lesen. Sie bedeuten nicht, dass Joomla über Nacht unsicher geworden ist. Sie bedeuten vor allem zwei Dinge: Erstens wird systematischer gesucht und sauberer dokumentiert als früher. Eine CVE-Nummer ist ein Zeichen dafür, dass eine Lücke gefunden, gemeldet und behoben wurde – nicht dafür, dass sie ausgenutzt wurde. Zweitens verschiebt sich das Verhältnis deutlich: Der Großteil der Meldungen betrifft nicht den Core, sondern Erweiterungen von Drittanbietern. Genau dort, wo viele Betreiber am seltensten aktualisieren.

Ein wesentlicher Treiber dieser Entwicklung ist künstliche Intelligenz – und zwar auf beiden Seiten. Zum einen entsteht heute deutlich mehr Code in deutlich kürzerer Zeit, oft von Menschen, die sich mit Sicherheitsfragen nicht im Detail beschäftigen; mehr Code bedeutet statistisch mehr Fehler. Zum anderen ist das automatisierte Durchsuchen von Software nach Schwachstellen drastisch einfacher geworden. Was früher Spezialwissen und Wochen Arbeit verlangte, erledigt heute ein gut angeleitetes Werkzeug in Stunden. Beides zusammen sorgt dafür, dass uns das Thema dauerhaft begleiten wird.

Und noch eine Einordnung ist wichtig: Das ist kein Joomla-Problem. Die gleiche Entwicklung zeigt sich bei WordPress, TYPO3, Drupal, bei Shopsystemen, bei Betriebssystemen, bei Bibliotheken und bei kommerzieller Individualsoftware. Wer das Thema für ein spezifisches Defizit eines einzelnen Systems hält, wird beim Wechsel auf ein anderes nur die Namen in den Advisories austauschen – nicht die Notwendigkeit, strukturiert damit umzugehen.

  ## Fazit

Sicherheitslücken sind kein Zeichen schlechter Software, sondern ein Merkmal komplexer Software. Was den Unterschied macht, ist die Reaktionsfähigkeit: etablierte Meldewege, funktionierende Sicherheitsteams, schnelle Patches – und auf Betreiberseite klare Zuständigkeiten, aktuelle Systeme, belastbare Backups und ein Hosting, das Handlungsspielraum lässt.

Die aktuellen PHP-Lücken werden gepatcht. Dann folgt die nächste Meldung, und die danach. Gut aufgestellt zu sein bedeutet nicht, unverwundbar zu sein – es bedeutet, dass der nächste Vorfall ein Arbeitstag bleibt und kein Desaster wird.

   ![Portrait David Jardin](https://www.djumla.de/images/team/portrait_david_jardin_square.webp)David Jardin - Geschäftsführung## Wir unterstützen Sie gerne

Sie möchten wissen, wie Ihre Website im Bereich Secuity dasteht?

- **Security- und Status-Check:** Wir prüfen Ihre Seite, bewerten Versionsstände von Joomla, Erweiterungen und PHP und zeigen konkrete Risiken auf.
- **Bereinigung kompromittierter Joomla-Installationen:** Wir identifizieren Einbruchsweg und Schadcode, räumen gründlich auf und schließen die Lücke, über die der Zugriff erfolgte.
- **Laufende Wartung:** Updates, Monitoring und Backups in verlässlicher Routine – inklusive schneller Reaktion, wenn ein kritisches Advisory erscheint.
- **Hosting- und Architekturberatung:** Damit Sie beim nächsten Vorfall selbst handeln können, statt auf Ihren Provider zu warten.

Schreiben Sie uns oder rufen Sie an. Lieber einmal zu früh gefragt als einmal zu spät.

[Jetzt Security-Beratung anfragen ](https://www.djumla.de/kontakt)

  ### Weiterführende Quellen

- **Joomla! Security Strike Team – Prozesse und Meldewege:** [developer.joomla.org/security.html](https://developer.joomla.org/security.html)
- **Joomla! Security Centre (Sicherheitsmeldungen):** [developer.joomla.org/security-centre.html](https://developer.joomla.org/security-centre.html)
- **Joomla! Volunteers Portal – Security Strike Team:** [volunteers.joomla.org/teams/security-strike-team](https://volunteers.joomla.org/teams/security-strike-team)
- **Security Policy des Joomla-CMS auf GitHub:** [github.com/joomla/joomla-cms/security/policy](https://github.com/joomla/joomla-cms/security/policy)
- **PHP News-Archiv (offizielle Release- und Sicherheitsankündigungen):** [php.net/archive](https://www.php.net/archive)
- **Golem.de zur aktuellen PHP-Schwachstelle:** golem.de – [„Noch kein Patch verfügbar: Kritische PHP-Lücken gefährden unzählige Webserver“](https://www.golem.de/news/noch-kein-patch-verfuegbar-kritische-php-luecken-gefaehrden-unzaehlige-webserver-2610-214332.html)
- **BSI – Empfehlungen für Website-Betreiber:** [bsi.bund.de](https://www.bsi.bund.de)
- **CVE-Programm (Datenbank aller registrierten Schwachstellen):** [cve.org](https://www.cve.org)