Hoppla! Ein SQL-Injection-Fehler hat letzte Woche einen Notfall-Patch für den WordPress-Kern erforderlich gemacht.
Am 17. Juli veröffentlichte WordPress ein Notfall-Update, um eine Sicherheitslücke im Kern zu beheben, die die Ausführung von Code aus der Ferne ohne Authentifizierung ermöglicht. Diese Lücke ist über eine SQL-Injection erreichbar, die ein anonymer Angreifer bei einer Standardinstallation ausnutzen kann. Aufgrund der Schwere der Sicherheitslücke hat WordPress.org sogar die automatischen Updates zwangsweise aktiviert. Searchlight Cyber, das den Fehler gemeldet hat, schätzt, dass über 500 Millionen Websites mit WordPress betrieben werden. Falls Sie betroffen sind, aktualisieren Sie auf Version 7.0.2 bzw. 6.9.5 für den älteren Zweig.
SQL-Injection, auch als SQLi bezeichnet, ist eine alte Sicherheitslücke, die sich leicht beheben lässt, weshalb viele davon ausgehen, dass sie nicht mehr existiert. Doch wie uns gerade wieder vor Augen geführt wurde, ist das nicht der Fall.
SQL-Injection: Von den bescheidenen Anfängen bis heute
SQL-Injection und ihre Lösungen sind Teil der Einführungskurse in die Informatik. Ich erinnere mich, dass ich vor über einem Jahrzehnt an der Universität etwas über Prompt-Injection gelernt habe, und ehrlich gesagt ist das die einzige anwendungsbezogene Sicherheitslücke, an deren Behandlung ich mich erinnern kann (ich glaube, sie sind nach dieser Einheit zu anderen Themen übergegangen, oder vielleicht habe ich danach einfach nicht mehr aufgepasst).
SQL-Injection wurde 1998 von dem unter dem Pseudonym „rainforest puppy“ bekannten Forscher öffentlich beschrieben. Die Lösung, mit der sich die meisten SQLi-Probleme beheben lassen – „Prepared Statements“ –, wurde etwa ein Jahr später entwickelt. Diese Lösung ist älter als viele Ingenieure im Unternehmen. Verwenden Sie parametrisierte Abfragen und behandeln Sie Benutzereingaben als Daten. Doch selbst wenn es eine Lösung gibt, kommt es nach wie vor zu SQL-Injections.
Auf der Grundlage der Daten aus der GitHub Advisory Database, wobei die Sicherheitshinweise nach CWE gefiltert und pro Jahr gezählt wurden:
Die Zahl der Warnmeldungen zu SQL-Injektionen stieg von 2023 bis 2025 in jedem Kalenderjahr an, und zwar von 2.096 auf 2.850. Die drei ältesten Injektionsarten – SQL-Injektion, Befehlsinjektion und Pfadtraversierung – machen zusammen immer noch mehr als jedes zehnte gemeldete Vorfall aus.
OWASP hat „Injection“ in seiner „Top 10“-Liste für 2025 vom dritten auf den fünften Platz verschoben, jedoch nicht, weil die Probleme behoben wären. Die Kategorie „Injection“ weist insgesamt nach wie vor mehr gemeldete CVEs auf als jede andere, nämlich mehr als 60.000. Davon entfielen allein auf SQL-Injection über 14.000. Bei Mackenzies Scans von Closed-Source-Repositories wiesen 20 % der Projekte bereits beim ersten Scan mindestens eine SQL-Injection-Sicherheitslücke auf.
Warum SQL-Injection einfach nicht verschwinden will
Zunächst einmal, um das gleich aus dem Weg zu räumen: Beim Schreiben von Code unterlaufen Menschen Fehler. Das kommt vor. Daher wird hin und wieder eine SQLi durchrutschen. Aber die modernen Systeme, die uns eigentlich helfen sollten, tun dies nicht in hundert Prozent der Fälle und können sogar dazu führen, dass wir andere Fehler machen.
Beispielsweise verfügen neuere Frameworks über Methoden, die dabei helfen, SQL-Injection zu verhindern. ORMs wie Django, Hibernate und ActiveRecord parametrisieren standardmäßig, was viele Teams davon überzeugt, dass das Problem damit gelöst ist. Wenn jedoch jemand auf eine rohe Abfrage zurückgreift oder eine unsichere Methode aufruft, ist der Schutz nicht mehr gegeben.
Ein Beispiel hierfür ist die Sicherheitslücke CVE-2024-42005 in Django. Zwei von Djangos eigenen Abfragemethoden, die zum Auslesen von Feldern aus einer JSON-Spalte verwendet wurden, übergaben die übergebenen Feldnamen ungefiltert direkt an die SQL-Anweisung. Dadurch konnte ein Angreifer, der die Kontrolle über einen Feldnamen hatte, einen Teil der Abfrage manipulieren – und zwar über eine Methode, die von den Entwicklern als sicher angesehen wurde.
Auf der anderen Seite ist auch wirklich alter Code ein Problem, da Legacy-Code diese Schwachstellen über Jahrzehnte hinweg weiterträgt. Teams verlassen sich auf eine WAF und gehen davon aus (beten darum), dass diese alles abfängt. Obwohl die Lösung bereits seit über 25 Jahren existiert, ist ihre konsequente Anwendung auf jede Abfrage, jeden Endpunkt und jeden Legacy-Bereich jedes Mal eine enorme Menge mühsamer Arbeit, die noch nie vollständig in jeder Codebasis umgesetzt wurde. Wie Mackenzie Jackson, unser Field-CTO, es formuliert, ist dies kein rein technisches Problem mehr, sondern hat sich zu einer Frage der Kultur, der Prozesse und der Weiterbildung entwickelt.
Und natürlich KI.
Auch KI schreibt SLQi
Die naheliegende Hoffnung ist, dass KI-Programmierassistenten, die anhand jahrzehntelanger Beispiele trainiert wurden, einen Fehler aus dem Jahr 1998 nicht mehr reproduzieren würden. Doch wie wir wissen, schreibt KI keinen perfekten Code.
Wir können dies quantitativ betrachten. Die Studie „Asleep at the Keyboard“ aus dem Jahr 2021 der NYU und der Cornell University erzeugte mithilfe von GitHub Copilot 1.689 Programme für gängige Schwachstellenszenarien und stellte fest, dass etwa 40 % davon anfällig waren, wobei SQL-Injection und Command-Injection zu den häufigsten gehörten. Mackenzies eigener Test liegt im gleichen Bereich. Bei der mehrhundertmaligen Eingabe einer einzigen Eingabeaufforderung in ChatGPT waren etwa 12 % der Ergebnisse anfällig für Injektionen, was in etwa der Quote bei Open-Source-Projekten entspricht.
Aber warum? Modelle lernen aus öffentlich zugänglichem Code, der diese Fehler enthält, und geben sie daher in ähnlicher Häufigkeit weiter. KI geht besser mit SQL-Injection um als mit kontextabhängigen Fehlern wie Cross-Site-Scripting, bei denen laut demselben Bericht die meisten Ausgaben als unsicher eingestuft wurden. Da sich die KI ständig weiterentwickelt, werden diese Zahlen in sechs Monaten bereits überholt sein, aber wir können davon ausgehen, dass die KI solche Fehler weiterhin versehentlich produzieren wird – genau wie wir.
Und mittlerweile schreiben immer mehr „Vibe-Coder“ und weniger technisch versierte Personen Code. Sie erkennen SQL-Injektionen seltener (sofern sie überhaupt wissen, worauf sie achten müssen), sodass mehr Code in die Codebasis des Unternehmens gelangen kann, ohne dass geschulte Fachkräfte sicherstellen, dass dieses Problem berücksichtigt wird.
Deshalb braucht man einen Sicherheitsmechanismus.
Selbst wenn Sie alles richtig machen – wie zum Beispiel durchgängig parametrisierte Abfragen, Whitelists für jede Eingabe und was es sonst noch so gibt … Sie brauchen trotzdem Laufzeitschutz. Eine perfekte Sanitisierung an jedem Endpunkt, und zwar dauerhaft, gibt es nicht. Ein SQLi-Angriff könnte sogar in einer anfälligen Abhängigkeit auftreten, die Sie nicht kontrollieren (oder beispielsweise auf der Standard-Website eines Webhosts), was weit über das hinausgeht, was Sie vernünftigerweise verwalten können.
Aikido ist eine In-App-Firewall innerhalb Ihrer Anwendung läuft und Benutzereingaben überwacht, während diese an einen Datenspeicher weitergeleitet werden, beispielsweise bei einer Datenbankabfrage oder beim Lesen einer Datei.
Wenn eine Angriffs-Payload kurz davor ist, einen dieser Orte zu erreichen, blockiert Zen sie sofort – und zwar mit genügend App-Kontext, um einen Angriff von einer Suchanfrage zu unterscheiden, die zufällig so aussieht wie ein Angriff.
Es deckt auch Schwachstellen ab, die über Abhängigkeiten entstehen und an denen Ihre eigenen Codierungsstandards nicht ansetzen. Betrachten Sie es als eine Sicherheitsmaßnahme zur Laufzeit für den Fall, dass sicheres Programmieren nicht ausreicht – was in der Praxis immer der Fall ist. Zen ist ein RASP, das gefährliche Eingaben auf Code-Ebene erkennt. Dies unterscheidet sich von einer WAF, die verdächtige Eingaben auf Netzwerkebene blockiert, was weniger präzise ist und daher dazu neigt, zu viele Eingaben zu blockieren. Ich gehe in unserem Beitrag zu WAF vs. RASP vs. ADR noch viel ausführlicher darauf ein.
Eine In-App-Firewall Zen steht zwischen wp2shell und einer nicht gepatchten WordPress-Seite. Zen wurde entwickelt, um die SQL-Injection zu blockieren, auf der diese Sicherheitslücke beruht, sodass eine Seite, die noch auf das Update wartete, während der Einführung des Patches weiterhin geschützt war.
Erkennen Sie SQL-Injektionen in Ihrem Entwicklungszweig
Die Laufzeit ist das Sicherheitsnetz, aber Prävention ist natürlich der Goldstandard. Im Idealfall finden und beseitigen wir alle SQL-Injection-Schwachstellen im Code.
Statische Analysen wie SAST viele SQL-Injection-Angriffe – insbesondere die einfache Variante, bei der Eingaben direkt in eine Abfrage ohne parametrisierte Anweisung einfließen. Dieser Fall wäre damit jedoch nicht erkannt worden. Der WordPress-Kern wird so gründlich geprüft wie kaum eine andere Software, und dennoch wurde dieser Fehler übersehen. In diesem Fall wird die Injektion erst dann ausnutzbar, wenn eine fehlerhaft formatierte Batch-Anfrage die interne Verwaltung von WordPress durcheinanderbringt, sodass der Wert über einen Pfad in die Datenbank gelangt, der die Bereinigung umgeht. Das ist eine inter-Request-Interaktion, die ein statischer Scanner nicht nachverfolgen kann. Um diese Schwachstelle zu finden, war ein „Frontier“-Modell erforderlich, bei dem vier Agenten sechs Stunden lang liefen.
Die alltäglichen Aufgaben sind die Aufgabe Ihres Scanners. Bei den verborgenen, logikabhängigen Aufgaben ist zunehmend eine KI erforderlich, um sie zu finden, bevor es jemand anderes tut – was bei Aikido KI-Penetrationstests und sie auf den eigenen Code anzuwenden, so wie dieser Forscher sie auf WordPress angewandt hat. Aikido kontinuierliches Penetrationstesten Aikido kontinuierliches Penetrationstesten Aikido , mit denen Sie regelmäßig nach neuen SQLi-Schwachstellen suchen können, die möglicherweise die Code-Review umgehen.
Little Bobby Tables ist noch immer am Leben und bei bester Gesundheit. Nehmt ihn ernst und sichert euren Code – auch die langweiligen Teile.
