Upps! Ein SQL-Injection-Bug hat letzte Woche einen Notfall-Patch für den WordPress-Core erzwungen.
Am 17. Juli veröffentlichte WordPress eine Notfallversion, um eine nicht authentifizierte Remote Code Execution-Schwachstelle im Core zu beheben, die über eine SQL-Injection erreichbar ist, die ein anonymer Angreifer auf einer Standardinstallation ausnutzen kann. WordPress.org hat aufgrund der Schwere sogar erzwungene Auto-Updates aktiviert. Searchlight Cyber, die den Fehler gemeldet haben, schätzen, dass über 500 Millionen Websites mit WordPress laufen. Wenn Sie betroffen sind, wechseln Sie zu Version 7.0.2 und 6.9.5 für den älteren Zweig.
SQL-Injection, auch als SQLi stilisiert, ist eine alte Schwachstelle mit einer einfachen Lösung, weshalb viele annehmen, sie sei tot. Doch wie wir gerade erst wieder erfahren haben, ist sie es nicht.
SQL-Injection: Von den Anfängen bis heute
SQL-Injection und ihre Lösungen sind Teil der Grundlagenkurse der Informatik. Ich erinnere mich, vor über einem Jahrzehnt an der Universität etwas über Prompt Injection gelernt zu haben, und ehrlich gesagt ist es die einzige anwendungsbasierte Schwachstelle, an die ich mich erinnere, dass sie gelehrt wurde (ich glaube, sie sind danach zu anderen Themen übergegangen, oder ich habe danach vielleicht nicht mehr aufgepasst).
SQL-Injection wurde 1998 öffentlich von dem Forscher namens rainforest puppy dokumentiert. Die Lösung, die die meisten SQLi-Probleme behebt – Prepared Statements – wurde etwa ein Jahr später entwickelt. Die Lösung ist älter als viele Ingenieure im Unternehmen. Verwenden Sie parametrisierte Abfragen und behandeln Sie Benutzereingaben als Daten. Doch selbst mit einer vorhandenen Lösung treten SQL-Injections immer noch auf.
Basierend auf den Daten der GitHub Advisory Database, gefiltert nach CWE und gezählt pro Jahr:
Die Anzahl der SQL-Injection-Advisories stieg in jedem vollen Jahr von 2023 bis 2025 von 2.096 auf 2.850. Die drei ältesten Injection-Klassen zusammen – SQL Injection, Command Injection und Path Traversal – machen immer noch mehr als ein Zehntel aller gemeldeten Fälle aus.
OWASP verschob Injection in seinen 2025 Top 10 vom dritten auf den fünften Platz, aber nicht, weil die Probleme behoben wären. Die gesamte Kategorie Injection weist immer noch mehr gemeldete CVEs auf als jede andere, mit über 60.000 gemeldeten Fällen. Davon entfielen allein über 14.000 auf SQL Injection. Bei Mackenzies Scans von Closed-Source-Repositories wiesen 20 % der Projekte bereits beim ersten Scan mindestens eine SQL-Injection-Schwachstelle auf.
Warum SQL Injection nicht ausstirbt
Zunächst einmal, um es klarzustellen: Menschen machen Fehler beim Schreiben von Code. Das passiert. Daher wird hin und wieder eine SQLi durchrutschen. Doch die modernen Systeme, die uns helfen sollten, tun dies nicht hundertprozentig und können uns sogar dazu verleiten, andere Fehler zu machen.
Neuere Frameworks verfügen beispielsweise über Methoden zur Verhinderung von SQL Injection. ORMs wie Django, Hibernate und ActiveRecord parametrisieren standardmäßig, was viele Teams davon überzeugt, dass das Problem gelöst ist. Doch wenn jemand auf eine Raw Query zurückgreift oder eine unsichere Methode verwendet, ist der Schutz hinfällig.
Djangos CVE-2024-42005 ist ein Beispiel dafür. Zwei von Djangos eigenen Query-Methoden, die zum Auslesen von Feldern aus einer JSON-Spalte verwendet wurden, übernahmen die übergebenen Feldnamen direkt in die SQL-Abfrage, ohne sie zu bereinigen. Ein Angreifer, der einen Namen kontrollierte, konnte so einen Teil der Abfrage manipulieren, und das über eine Methode, die Teams für sicher hielten.
Andererseits ist auch sehr alter Code ein Problem, da Legacy-Code diese Schwachstellen über Jahrzehnte hinweg mitschleppt. Teams verlassen sich auf eine WAF und nehmen an (oder beten), dass sie alles abfängt. Obwohl die Lösung seit über 25 Jahren existiert, ist die konsequente Anwendung auf jede Abfrage, jeden Endpunkt und jede Legacy-Ecke jedes Mal eine Menge mühsamer Arbeit, die noch nie vollständig über jede Codebasis hinweg abgeschlossen wurde. Wie Mackenzie Jackson, unser Field CTO, es formuliert: Dies ist kein technisches Problem mehr, sondern ein Problem der Kultur, des Prozesses und der Bildung.
Und natürlich: KI.
KI schreibt auch SQLi
Die offensichtliche Hoffnung ist, dass KI-Coding-Assistenten, die über Jahrzehnte an Beispielen trainiert wurden, aufhören würden, einen Bug von 1998 zu reproduzieren. Doch wie wir wissen, schreibt KI keinen perfekten Code.
Wir können dies quantitativ betrachten. Die Studie Asleep at the Keyboard von NYU und Cornell aus dem Jahr 2021 generierte 1.689 Programme von GitHub Copilot über gängige Schwachstellenszenarien hinweg und fand heraus, dass etwa 40 % anfällig waren, wobei SQL Injection und Command Injection zu den häufigsten gehörten. Mackenzies eigener Test liegt im selben Bereich. Nachdem ein Prompt einige hundert Mal durch ChatGPT lief, waren etwa 12 % der Ergebnisse injizierbar, was nahe an der Rate im Open-Source-Bereich liegt.
Aber warum? Modelle lernen aus öffentlichem Code, der diese Schwachstellen enthält, und reproduzieren sie daher mit ähnlicher Häufigkeit. KI geht mit SQL Injection besser um als mit kontextabhängigen Bugs wie Cross-Site Scripting, wo derselbe Bericht die meisten Ausgaben als unsicher befand. KI verbessert sich ständig, daher werden diese Zahlen in sechs Monaten veraltet sein, aber wir können davon ausgehen, dass KI dies weiterhin versehentlich schreiben wird, genau wie wir.
Und jetzt schreiben mehr „Vibe-Coder“ und weniger technisch geschulte Personen Code. Sie erkennen SQL Injections seltener (wenn sie überhaupt wissen, wonach sie suchen sollen), sodass mehr Code in die Unternehmens-Codebasis gelangen kann, ohne dass geschulte Augen darauf achten, dass dieses Problem berücksichtigt wird.
Deshalb braucht man eine Absicherung
Selbst wenn Sie alles richtig machen, wie parametrisierte Abfragen überall, Allowlists für jede Eingabe, und so weiter... Sie benötigen dennoch Laufzeitschutz. Eine perfekte Bereinigung über jeden Endpunkt hinweg, für immer, ist nicht realisierbar. SQLi kann sogar in einer anfälligen Abhängigkeit auftreten, die Sie nicht kontrollieren (oder beispielsweise auf der Standardseite eines Website-Hosts), was jenseits dessen liegt, was Sie vernünftigerweise verwalten können.
Aikido Zen ist eine In-App-Firewall, die innerhalb Ihrer Anwendung läuft und Benutzereingaben überwacht, während diese sich auf eine Datensenke zubewegen, wie eine Datenbankabfrage oder einen Dateilesevorgang.
Wenn eine Angriffsnutzlast im Begriff ist, einen dieser Orte zu erreichen, blockiert Zen sie im selben Moment, mit ausreichend App-Kontext, um einen Angriff von einem Suchstring zu unterscheiden, der zufällig wie ein solcher aussieht.
Es deckt auch Schwachstellen ab, die über Abhängigkeiten entstehen, wo Ihre eigenen Coding-Standards nicht greifen. Betrachten Sie es als Laufzeit-Absicherung für den Fall, dass sicheres Coding nicht ausreicht, was in der Praxis immer der Fall ist. Zen ist RASP, das gefährliche Eingaben auf Code-Ebene versteht. Dies unterscheidet sich von einer WAF, die verdächtige Eingaben auf Netzwerkebene blockiert, was weniger präzise ist und daher dazu neigt, zu viel zu blockieren. Ich gehe in unserem Beitrag über WAF vs RASP vs ADR viel detaillierter darauf ein.
Eine In-App-Firewall wie Zen steht zwischen wp2shell und einer ungepatchten WordPress-Site. Zen wurde entwickelt, um die SQL Injection zu blockieren, auf die diese Schwachstelle angewiesen ist, sodass eine auf das Update wartende Site immer noch eine Verteidigung hatte, während der Patch ausgerollt wurde.
SQL Injections in Ihrem Dev-Branch erkennen
Die Laufzeit ist das Sicherheitsnetz, aber Prävention ist natürlich der Goldstandard. Idealerweise finden und entfernen wir alle SQL Injection im Code.
Statische Analyse wie SAST erkennt viele SQL Injections, die einfache Art, bei der Eingaben ohne parametrisierte Anweisung in eine Abfrage gelangen. Diese hier hätte sie nicht erkannt. Der WordPress-Core wird so gründlich gescannt wie kaum eine andere Software, und dieser Fehler wurde nicht entdeckt. In diesem Fall wird die Injection erst dann ausnutzbar, wenn eine fehlerhafte Batch-Anfrage die interne Buchführung von WordPress durcheinanderbringt, sodass der Wert über einen Pfad die Datenbank erreicht, der die Bereinigung umgeht. Das ist eine Cross-Request-Interaktion, die ein statischer Scanner nicht nachvollziehen kann. Das Auffinden dieser Schwachstelle dauerte ein Frontier-Modell, das vier Agenten sechs Stunden lang ausführte.
Die alltägliche Injection ist die Aufgabe Ihres Scanners. Die vergrabene, logikabhängige Art erfordert zunehmend eine KI, um sie zu finden, bevor es jemand anderes tut, was bei Aikido KI-Penetrationstests der Fall ist, wenn man sie auf den eigenen Code anwendet, so wie dieser Forscher eine auf WordPress angewendet hat. Aikido bietet kontinuierliches Penetrationstesten mit Aikido Infinite, das Ihnen helfen kann, regelmäßig nach neuen SQLi zu suchen, die sich möglicherweise durch die Code-Überprüfung schleichen könnten.
Little Bobby Tables ist immer noch lebendig und gesund. Nehmen Sie ihn ernst und sichern Sie Ihren Code, auch die langweiligen Dinge.
