WordPress-RCE mit GPT5.6 und 25 Dollar gefunden

 (slcyber.io)
2 Punkte von GN⁺ 16 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • GPT5.6 Sol Ultra analysierte die aktuelle stabile WordPress-Version und stellte in etwas mehr als 10 Stunden eine Angriffskette fertig, die von einer SQL-Injection vor der Authentifizierung bis zur Erstellung eines Administratorkontos und zur Remote Code Execution (RCE) reicht
  • Ausgangspunkt war eine Array-Index-Fehlanpassung in der Batch API, die seit WordPress 5.6 verfügbar ist; durch die Kombination rekursiver Batch-Anfragen wurden GET-Beschränkungen und Parameterprüfungen umgangen
  • Über eine nicht validierte author_exclude-Zeichenkette wurde eine UNION-Injection ausgelöst, danach wurden manipulierte Beiträge in den In-Memory-Cache gelegt und oEmbed-Cache, Changesets, zirkuläre Referenzen und Hooks nacheinander missbraucht
  • Mit user_id: 1 in customize_changeset wurden vorübergehend Administratorrechte erlangt, per parse_request-Hook Batch-Anfragen erneut ausgeführt, ein neuer Administrator angelegt und schließlich durch den Upload einer Backdoor-Plugin-ZIP Codeausführung erreicht
  • Die anteilig berechneten Kosten eines 200-Dollar-Monatsabos bei 50 % des Wochenkontingents lagen bei etwa 25 Dollar; die menschliche Rolle dürfte sich stärker auf die übergeordnete Steuerung der Forschung verlagern, etwa Produktauswahl, Wahl der Angriffsfläche und Prompt-Anpassung

Entdeckungsprozess und Versuchsbedingungen

  • Der von OpenAI als für die Lösung der Cycle-Double-Cover-Vermutung verwendet veröffentlichte Prompt wurde für Sicherheitsforschung angepasst und GPT5.6 Sol Ultra gegeben
  • Die aktuelle stabile WordPress-Version wurde nach main/ geklont, das Verzeichnis .git entfernt und ein leeres Verzeichnis third_party/ vorbereitet, damit abhängiger Code untersucht werden konnte
  • Der Prompt wies an, bis zu 4 Agenten parallel zu nutzen und über mindestens 6 Stunden verschiedene Angriffspfade aufrechtzuerhalten
    • Untersucht wurden Eingabe-Parsing, Zeichensätze, Datei-Uploads, Fehlerbehandlung, eingebaute Pfade, Serialisierung, Caching, Race Conditions, Kryptografie, Typen und Mass Assignment
    • Verwandte Vorgehensweisen wurden registriert, und wenn Agenten sich auf bestimmte Strategien konzentrierten, wurden sie in weniger erkundete Bereiche umverteilt
    • Konkrete Bugs wurden von gegnerischen Agenten erneut verifiziert, und auch gescheiterte Pfade wurden wieder geöffnet, sobald neue Mechanismen entstanden
  • Es war untersagt, Changelogs, Unterschiede zu Patch-Versionen oder Hinweise aus dem Internet zu nutzen; neue Schwachstellen sollten allein aus dem Quellcode gefunden werden
  • Um unrealistische Konfigurationen oder Voraussetzungen zu vermeiden, die ein Angreifer nicht erfüllen kann, wurde das Ziel als „RCE vor der Authentifizierung in einer typischen Produktionsumgebung mit MySQL“ festgelegt
  • Nach etwa 6 Stunden fand das Modell eine SQL-Injection vor der Authentifizierung und reproduzierte sie innerhalb weniger Minuten auf einem Standard-WordPress-Remote-Server durch das Auslesen der Admin-E-Mail
  • Nach einer zusätzlichen Aufforderung zur Eskalation bis RCE stellte es etwa 4 Stunden später eine Kette fertig, die ohne Passwort-Cracking oder Offline-Berechnungen von einer schreibgeschützten SQL-Injection zu Administratorrechten aufstieg
  • Die gesamte Arbeitszeit betrug etwas mehr als 10 Stunden und verbrauchte 50 % des Wochenkontingents. Anteilig berechnet aus dem 200-Dollar-Monatsabo ergaben sich Kosten von rund 25 Dollar
  • Vor der Offenlegung wurde dem Betreiber über das Wochenende Zeit gegeben, WordPress zu aktualisieren; in dieser Zeit reproduzierten Calif und Hacktron die gesamte Kette unabhängig und noch vor anderen PoCs auf GitHub
  • Laufende Instanzen können unter wp2shell.com auf Verwundbarkeit geprüft werden

Validierungs-Fehlanpassung in der Batch API

  • Die in WordPress 5.6 eingeführte Batch API verarbeitet mehrere virtuelle API-Anfragen in einer einzigen Anfrage. Der Endpoint selbst ist ohne Authentifizierung erreichbar, an jede Unteranfrage werden jedoch Authentifizierungsinformationen weitergereicht
  • Normale REST-Anfragen werden in folgender Reihenfolge verarbeitet
    • has_valid_params() prüft Pflichtwerte und Gültigkeit
    • sanitize_params() bereinigt Werte
    • Der Berechtigungs-Callback wird ausgeführt
    • Der Endpoint-Callback wird ausgeführt
  • Die Batch API trennt aus Performance-Gründen Validierung und Ausführung in zwei Schleifen
    • In der ersten Schleife werden alle Anfragen validiert und bereinigt
    • In der zweiten Schleife werden die Validierungsergebnisse geprüft und Berechtigungs- sowie Endpoint-Callbacks ausgeführt
  • Die Implementierung geht davon aus, dass in $matches als Ergebnis des Route-Matchings und in $validation als Ergebnis der Prüfung jeweils dieselben Indizes zueinander gehören
  • Wenn eine fehlerhafte Anfrage in den Zweig is_wp_error($single_request) gelangt, wird zwar ein Eintrag zu $validation hinzugefügt, wegen continue jedoch keiner zu $matches
    • Danach sind alle Einträge in $matches um eine Position verschoben
    • Parameter einer Anfrage können dann nach den Regeln einer anderen Anfrage validiert und anschließend in einem ursprünglich nicht vorgesehenen Endpoint-Handler ausgeführt werden
  • Mithilfe dieser Index-Fehlanpassung lässt sich das Validierungsergebnis eines anderen Endpoints, der Parameter nicht bereinigt, auf einen Batch-fähigen Endpoint anwenden

SQL-Injection in author__not_in

  • GET /wp/v2/posts verwendet die interne Query-Variable author__not_in, um bestimmte Autoren aus den Ergebnissen auszuschließen
  • Ist der Wert ein Array, wird auf jedes Element absint angewandt und es zu einer Ganzzahl gemacht; bei einem Skalarwert wird dieser jedoch unverändert per implode zusammengesetzt und in die SQL-Klausel NOT IN eingefügt
  • Bei normalen Aufrufen muss der öffentliche Parameter author_exclude ein Integer-Array sein, daher fällt das Problem nicht auf
  • Über die Batch-Index-Fehlanpassung lässt sich die Zeichenkette author_exclude nach den Regeln von DELETE /wp/v2/posts/1, das diesen Parameter nicht erkennt, validieren und anschließend an GET /wp/v2/posts übergeben
  • Auch die Einschränkung, dass die Batch API keine GET-Unteranfragen zulässt, wird durch rekursive Batch-Aufrufe umgangen
    • Im äußeren Batch wird durch eine Index-Fehlanpassung die Prüfung von method für die innere Anfrage übersprungen
    • Im inneren Batch wird erneut eine Index-Fehlanpassung erzeugt, um die Prüfung von author_exclude zu umgehen
  • Mit einem Wert wie 0) OR 1=1 -- werden alle Beitragszeilen zurückgegeben, wodurch sich die Injektion bestätigen lässt
  • Danach können über UNION-basierte Injections Zeilen in Form von wp_posts erzeugt und beliebige Datenbankwerte exfiltriert werden
  • Passwörter, Reset-Tokens und API-Schlüssel sind in der Datenbank gehasht, daher führt Datenabfluss allein nicht zur Kontoübernahme, solange das Admin-Passwort nicht schwach ist

Manipulation des beitragsbezogenen Anfrage-Caches

  • WordPress speichert innerhalb einer Anfrage wiederholt referenzierte WP_Post-Objekte in einem In-Memory-Cache, um Datenbank-Roundtrips zu verringern
  • Gibt eine UNION-Injection gefälschte Beitragszeilen zurück, kann ein Angreifer zahlreiche Felder wie Beitrags-ID, Typ, Status, Parent-Beziehung und Inhalt mit frei gewählten Werten in den Cache bringen
  • Auch API-Antworten verarbeiten den Beitragsinhalt nachträglich, sodass mit manipuliertem Inhalt zusätzliche Codepfade ausgeführt werden können
  • Dieser Cache verschwindet am Ende der Anfrage, und die gefälschten Beiträge existieren nicht in der Datenbank; allein durch Cache-Manipulation lässt sich daher keine Persistenz über mehrere Anfragen hinweg erreichen

Erzeugen einer Datenbankzeile über den oEmbed-Cache

  • Die WordPress-Funktion embeds bettet per [embed]...[/embed] im Beitragsinhalt unterstützte entfernte Inhalte ein
  • Damit nicht jedes Mal eine HTTP-Anfrage gesendet werden muss, wird das Ergebnis als Beitrag vom Typ oembed_cache in wp_posts in der Datenbank gespeichert
  • Wird ein lokaler WordPress-Beitrag per relativem Pfad eingebettet, entfällt die HTTP-Anfrage, und es wird nicht geprüft, ob die referenzierte Beitrags-ID tatsächlich existiert
  • Selbst wenn ein nicht existierender lokaler Beitrag wie /?p=10 eingebettet wird, kann eine oembed_cache-Zeile für diese Daten erstellt werden
  • Wird die erzeugte Zeile anschließend wieder per SQL-Injection abgefragt und der Beitragstyp im Speicher zu post o. Ä. manipuliert, unterscheiden sich Datenbank- und Cache-Darstellung
  • Beim Abgleich dieser beiden Darstellungen ruft WordPress wp_update_post() auf und bevorzugt für alle außer explizit gesetzten Feldern wie ID und post_content die vom Angreifer erzeugten Speicherwerte
  • Dadurch lässt sich eine oembed_cache-Zeile in einen normalen Beitrag umwandeln; in diesem Aufruf wird post_content jedoch mit dem Embed-Ergebnis überschrieben, sodass der Angreifer den Inhalt nicht mitsteuern kann

Temporäre Administratorrechte über customize_changeset

  • Entwürfe für Theme-Anpassungen werden in wp_posts als besondere Beiträge vom Typ customize_changeset gespeichert
  • post_content enthält JSON mit den Änderungswerten und Typen je Einstellungsschlüssel sowie der Benutzer-ID, die die Änderung durchführen soll
  • Beim Anwenden eines Changesets liest WordPress die jeweilige user_id und wechselt mit wp_set_current_user() vorübergehend zum aktuellen Benutzer
  • Wendet ein Angreifer ein Changeset mit user_id: 1 an, kann er selbst in einer anonymen Anfrage kurzzeitig die Identität des Administrators nutzen
  • Der vorherige oEmbed-Abgleich überschreibt post_content, daher wird ein separater Aufrufpfad von wp_update_post() benötigt, um bösartiges Changeset-JSON zu erhalten

Beibehaltung des Inhalts über einen Parent-Zyklus

  • WordPress-Beiträge können einen Parent haben, eine zyklische Struktur mit sich selbst oder einem Unterbeitrag als Parent ist jedoch nicht erlaubt
  • Der Filter wp_insert_post_parent prüft entlang der Parent-Hierarchie auf Zyklen und ruft bei Entdeckung eines Zyklus wp_update_post() auf, um post_parent des betreffenden Beitrags auf 0 zu setzen
  • Dieser zweite Aufruf setzt nur ID und post_parent und überschreibt post_content nicht
  • Wird ein Beitrag im Speicher per SQL-Injection als customize_changeset mit sich selbst als Parent getarnt, schreibt der Zyklus-Reparaturprozess das vom Angreifer definierte bösartige Changeset-JSON in die Datenbank
  • Wird ein Changeset mit vergangenem Datum und Status future erzeugt, wendet WordPress es an und führt die vorgesehenen Einstellungsänderungen gemäß user_id: 1 mit Administratorrechten aus
  • Die Administratorrechte bleiben nur während der Changeset-Verarbeitung erhalten und fallen danach wieder auf Gastrechte zurück

Erneute Ausführung der gesamten Anfrage über einen dynamischen Hook

  • WordPress-Hooks bestehen aus Actions und Filtern und erlauben Plugins Eingriffe an vielen Punkten des Lebenszyklus wie Login, Veröffentlichung oder Script-Registrierung
  • Ändert sich der Beitragsstatus, führt WordPress eine dynamische Action der Form "{$new_status}_{$post->post_type}" aus
    • Für einen normalen Beitrag ergibt sich ein Name wie publish_post
    • Ein gefälschter Beitrag im Speicher kann Status und Typ beliebig setzen und dadurch einen gewünschten Action-Namen mit einem oder mehreren Unterstrichen bilden
  • Die Hook-Argumente sind auf die vom Angreifer gesetzte Beitrags-ID und das WP_Post-Objekt beschränkt, daher ist ein direkter sinnvoller Aufruf beliebiger Actions schwierig
  • Die Angriffskette setzt den Status auf parse und den Typ auf request, um den Hook parse_request aufzurufen
  • parse_request wird früh im Anfrage-Lebenszyklus ausgeführt; ein erneuter Aufruf verarbeitet daher die ursprüngliche Batch-API-Anfrage noch einmal vollständig von Anfang an
  • Diese erneute Verarbeitung geschieht, solange die durch das Changeset gesetzte temporäre Administratoridentität noch aktiv ist, sodass Admin-exklusive Anfragen, die beim ersten Durchlauf mangels Rechten scheiterten, im zweiten Durchlauf erfolgreich sind

Die RCE-Kette in zwei Anfragen

  • Der finale Exploit verwendet zwei HTTP-Anfragen und weist den gefälschten Beiträgen so hohe IDs zu, dass sie nicht mit echten Beiträgen kollidieren

  • Erste Anfrage: persistente Zeilen vorbereiten

    • Durch SQL-Injection wird ein gefälschter Beitrag mit drei lokalen Embeds zurückgegeben, wodurch 3 oembed_cache-Zeilen erzeugt werden, die O, C und D entsprechen
    • Alle drei Embeds verweisen auf denselben Beitrag S, nutzen aber unterschiedliche Query-Strings, um getrennte oEmbed-Cache-Hashes zu erzeugen

  • Zweite Anfrage: sechs Beiträge zusammensetzen

    • Im In-Memory-Cache werden die folgenden sechs gefälschten Beiträge aufgebaut
    • O: alter Cache mit Status/Typ publish/oembed_cache und Parent C
    • C: future/customize_changeset mit sich selbst als Parent und bösartigem Changeset-JSON
    • P: draft/page mit Parent D
    • D: parse/request mit sich selbst als Parent
    • S: publish/post, das Embed-Daten liefert
    • T: publish/post, das das äußere Embed enthält
    • Das Embed in T fragt O ab und veranlasst wegen des alten Änderungszeitpunkts eine Aktualisierung des Caches von S
    • Wird bei der Aktualisierung von O der Zyklus in Parent C erkannt, setzt WordPress den Parent von C auf 0 und schreibt dabei das im Speicher befindliche customize_changeset samt bösartigem JSON in die Datenbank
    • Das future-Changeset mit Datum in der Vergangenheit wird angewendet und veröffentlicht P mit der Administratoridentität aus user_id: 1
    • Die Aktualisierung von P entdeckt den Zyklus in Parent D, schreibt D und ruft mit manipuliertem Status und Typ die Action parse_request auf
    • Die Batch-Anfrage enthält von Anfang an eine Anfrage zur Erstellung eines neuen Administrators
    • Bei der ersten Verarbeitung scheitert sie mit Gastrechten
    • Bei der erneuten Ausführung über parse_request ist die temporäre Administratorberechtigung noch vorhanden, daher gelingt sie
    • Nach dem Login mit dem neuen Administratorkonto führt der Upload einer Backdoor-Plugin-ZIP schließlich zur Remote Code Execution

Sich verändernde Rollen in der KI-Sicherheitsforschung

  • Besonders kreative Schritte der gesamten Kette waren die Umgehung der GET-Beschränkung durch rekursive Batch-Aufrufe, das Erlangen von Administratorrechten durch die Kombination aus Cache und Changesets sowie die erneute Ausführung der Anfrage per parse_request über gefälschte Beiträge
  • Eine allgemeine Überlegenheit lässt sich daraus nicht ableiten, aber die Einschätzung lautet, dass ein Sicherheitsforscher dieselbe Kette ohne KI kaum innerhalb von 10 Stunden gefunden und fertiggestellt hätte
  • Selbst wenn der ursprüngliche Batch-Bug bereits bekannt gewesen wäre, sei fraglich, ob sich in dieser Zeit auch der Weg bis zur RCE hätte konstruieren lassen
  • GPT5.6 Sol Ultra habe gegenüber GPT5.5 deutlich bei der Fähigkeit zugelegt, mehrere voneinander getrennte Code-Gadgets zu finden und zu einer Kette zu verbinden
  • Je mehr technische Exploit-Entwicklung das Modell übernimmt, desto stärker werden sich Menschen auf die Auswahl von Produkten und Angriffsflächen, die Zeiteinteilung, die Forschungsrichtung und Korrekturen bei Fehlentwicklungen des Modells konzentrieren
  • Diese Meta-Forschungskompetenz könne KI derzeit noch nicht gut abdecken und werde mit steigender technischer Leistungsfähigkeit der Modelle voraussichtlich noch wichtiger

Verwandte Beiträge

1 Kommentare

 
GN⁺ 16 시간 전
Meinungen auf Hacker News

  • Es gibt keine Grundlage dafür, dass für diesen Exploit 500.000 Dollar gezahlt wurden oder gezahlt werden. Im Beitrag heißt es, der Prompt werde so vorsichtig überarbeitet wie die Bibel; dann könnte man diesen Prompt wohl eher für 500.000 Dollar verkaufen.
    Der Autor arbeitet bei https://www.assetnote.io/, das ein automatisiertes Scanning-AI-Produkt anbietet.

    • Gemeint ist vermutlich https://www.crowdfense.com/exploit-acquisition-program/. Zerodium bot 2021 ebenfalls bis zu 300.000 Dollar: https://www.securityweek.com/sites/default/files/images/Zero...
      Solche Broker zahlen üblicherweise keine großen Summen auf einmal aus, sondern verkaufen den Zugriff an staatliche Akteure und zahlen dann in Raten, solange der Bug ungepatcht bleibt. Das ist so strukturiert, um Weiterverkauf oder eine frühe Entwertung zu verhindern; daher dürfte es kaum jemanden geben, der bestätigen kann, ob für eine vergleichbare Schwachstelle tatsächlich der volle Betrag gezahlt wurde.
    • 500.000 Dollar wurden aus dem Titel entfernt.
    • Schon vor LLMs dürfte die Schnittmenge aus Leuten, die fähig sind, solche Schwachstellen zu finden, bereit sind, sie an Broker zu verkaufen, und zugleich dumm genug sind, in sozialen Medien ein riesiges „Bitte verhaftet mich“-Schild hochzuhalten, extrem klein gewesen sein.
      Das nächstliegende Beispiel sind Teenager aus Florida, die in Steam-Spiele Malware eingebaut haben, um Konten zu stehlen, und dann erwischt wurden. Sie wären so oder so gefasst worden, aber ohne Prahlerei in sozialen Medien hätten die Ermittlungen deutlich länger gedauert.
    • Nur weil jemand einen Macintosh, der neu 5.000 Dollar kostete, auf einem Gebrauchtmarkt für 25 Dollar gekauft hat, ergibt sich daraus nicht dieselbe Wertvergleichbarkeit.
    • „Wie die Bibel überarbeiten“ heißt vermutlich, dass man gar nichts korrigiert, selbst wenn es offensichtlich widersprüchlich oder ethisch verdorben ist.

  • Wenn man sich https://github.com/WordPress/WordPress/commit/3a640e1c5e39aa... ansieht, taucht auch 2026 noch SQL-Injection durch String-Verkettung auf.

    • Noch schlimmer ist https://developer.wordpress.org/plugins/creating-tables-with...
      Statt SQL direkt auszuführen, soll man dbDelta verwenden, verlangt werden aber extrem pingelige Formatierungsregeln: jedes Feld in eine eigene Zeile, zwei Leerzeichen zwischen PRIMARY KEY, KEY statt INDEX usw. Feldnamen dürfen weder Anführungszeichen noch Backticks verwenden, Datentypen müssen kleingeschrieben, SQL-Keywords großgeschrieben sein, und auch alle Längenparameter müssen angegeben werden.
    • Die WordPress-Codebasis ist beschämend. PHP ist inzwischen eine gute Sprache, aber WordPress missbraucht sie massiv und weigert sich, sich zu verbessern.
    • Auch die Art des Fixes ist furchtbar. Man fragt sich, ob WordPress SQL-Abfragen immer noch mit einfacher String-Verkettung und sprintf baut.
    • Dieses Wochenende habe ich auf einer produktiven Website Angriffe gesehen, die diesen Exploit ausnutzen.
      In POST- und GET-Requests steckten Payloads der Form /wp/v2/widgets?author_exclude=1%29+AND+1%3D0+UNION+ALL+SELECT....
    • Im Profil steht Principal Software Engineer @ Bluehost, WordPress Core Committer; bei solchem Code klingt „principal“ wirklich merkwürdig.

  • Ich habe genug von FOMO-Schreiberei. Es wurde nicht einfach mit 25 Dollar gefunden, sondern mit Branchenexpertise darüber, wo man hinschauen und wie man suchen muss, sowie über Jahre angesammeltem Material.
    Man sollte aufhören, diese Glücksspiel-Erzählung und die Illusion zu verbreiten, alle würden gerade eine Chance verpassen.

    • Solche Beiträge sind schädlich, ähnlich wie eine Artikel-Version von Instagram: Man postet nur den erfolgreichen Moment und lässt das ganze Leben großartig wirken. In der 25-Dollar-Rechnung fehlen nicht nur jahrelange Berufserfahrung, sondern auch zahllose Fehlschläge.
    • Auch die Kostenrechnung stimmt nicht. Es waren lediglich die Kosten der über ein Abo-Modell subventionierten Tokens, die 25 Dollar betrugen.
    • Hätte er es selbst gemacht, hätte er es wohl kaum als „kostenlos geschafft“ vermarktet; seltsam ist auch, dass allein 25 Dollar für Tokens die Wahrnehmung der Leistung verändern.

  • Überraschend ist der hohe Preis für eine bereits bekannte Schwachstelle, und womöglich stimmt er auch nicht. WordPress wird nicht umsonst oft als Remote-Root-Shell mit Blog-Funktion bezeichnet.

    • Ich verstehe immer noch nicht, warum für einen Blog statische Seiten nicht ausreichen. Zumal die meisten WordPress-Probleme durch zusätzliches Caching „gelöst“ werden.
      Ich verstehe, dass Drag-and-drop leichter zu vermitteln ist, als normalen Nutzern zu sagen, sie sollen in ein GitHub-Repository committen und mit Hugo bauen. Aus Sicherheitssicht ist es aber eine Architektur, die nur darauf wartet, dass im Core oder in einem von Tausenden Plugins eine Schwachstelle entsteht und Remote Code Execution as a Service eröffnet.
    • Um zu wissen, ob das stimmt, müsste man Threat Intelligence betreiben und Telegram-Gruppen infiltrieren, in denen Broker aktiv sind; es ist unwahrscheinlich, dass der Autor das getan hat. Vielleicht hat er allgemeine Schwachstellen mit Zero-Days verwechselt.
    • WordPress ist eines der am stärksten gehärteten Ziele überhaupt. Man könnte auch sagen: Alter Code, der sich seit Jahrzehnten kaum verändert hat, bedeutet, dass die meisten Bugs bereits gefunden und gepatcht wurden.
    • Es gibt auch Statistiken, wonach fast 50 % aller Websites im Internet WordPress verwenden; deshalb ist ein Preis von 500.000 Dollar für eine unveröffentlichte authentifizierungsfreie Zero-Day-Remote-Code-Execution nicht völlig unrealistisch.

  • Ein interessanter Beitrag, und LLM-gestützte Exploit-Findung und Disclosure sind tatsächlich ein Grund zur Sorge. Ich habe Modelle auch schon vergleichsweise schnell Code für einen Container-Escape aus einer lokalen Linux-Privilege-Escalation-Schwachstelle erstellen lassen.
    Allerdings ist erstaunlich, dass GPT-5.6 den Prompt nicht durch Sicherheitsmechanismen blockiert hat. GPT-5.5 und höher meiden offensive Security-Arbeiten eher, ähnlich wie Opus 4.7+/Fable; daher wirkt es plausibel, dass der Autor von OpenAI eine Cybersecurity-Freigabe mit gelockerten Sicherheitsmechanismen erhalten hat.

  • Auch Nicht-KI-Tools für statische Anwendungssicherheitstests (SAST) aus der Zeit vor 2020 haben viele solcher SQL-Injections gefunden; spätestens im Code-Review hätte das auffallen müssen. Ich frage mich, ob WordPress keine Code-Reviews oder SAST einsetzt

    • Dieser Angriff erfordert die Kombination mehrerer Schwachstellen, daher hätten solche Tools allein ihn wohl nicht gefunden

  • Eine meiner Websites wurde über diese Schwachstelle gehackt, zum Glück war es eine ohne Nutzer
    Der Angreifer legte zwei Admin-Konten in der Datenbank an und installierte unter wp-content/plugins/wp-core eine Web-Shell zur Remote Command Execution namens wp-core-[12 beliebige Zeichen].php. In mu-plugins platzierte er außerdem eine firewall.php-Backdoor, die per GET ?sergei einen Administrator anlegt, fügte auch eine cache-seo-helper.php-Backdoor hinzu und änderte mit fixer.php die WordPress-Versionsnummer so, dass sie wie eine gepatchte Version aussah. Am Ende habe ich beschlossen, WordPress aufzugeben

  • Gegen Ende des Beitrags wurde es schwer verständlich, als Posts plötzlich mit merkwürdigen Namen bezeichnet wurden. Ich frage mich, warum eine ID O und eine andere 0 ist und warum statt EMBED_01 oder ABCDEF einzelne Zeichen und das zufällig wirkende OCPDST verwendet wurden

    • Das sind alles Platzhalter, deren Bedeutung im Text steht. O steht für publish/oembed_cache, C für future/customize_changeset, P für draft/page, D für parse/request, S für publish/post, das Embed-Daten bereitstellt, und T für publish/post, das ein externes Embed enthält

  • Ich frage mich, ob hier unterstellt wird, dass Leute, die 500.000 Dollar zahlen würden, GPT-5.6 nicht selbst nutzen können

    • Dann sollte man sich fragen, warum derselbe Analysebeitrag nicht schon früher erschienen ist. Es braucht weiterhin Fachwissen, um LLM-Ausgaben zu prüfen und daraus tatsächlich einen gültigen Proof of Concept zu machen
      Auch ich suche mit LLMs nach Sicherheitslücken, aber man kann die Ergebnisse nicht einfach unverändert einreichen und damit fertig sein; viele versuchen genau das
    • Es erscheinen immer wieder Berichte darüber, dass Ermittlungsbehörden Cloud-LLM-Protokolle erhalten und als Beweise für Strafverfahren nutzen. Professionelle Kriminelle dürften ihre Aktivitäten wahrscheinlich über unethische, aber legale Vermittler waschen
    • Die Menschen, die Geld verdienen, und die Menschen, die den besten Code schreiben, sind nicht zwangsläufig dieselben. Auch Elon Musk hat den Raketencode nicht selbst geschrieben, sondern Leute eingestellt, die ihn schreiben

  • Ob GPT-5.6 Sol übermenschlich ist, ist keine einfache Ja-oder-nein-Frage. Computer übertreffen Menschen seit Jahrzehnten im Schach, und diesem Beitrag nach scheinen sie Menschen nun auch beim Codeverständnis überholt zu haben

    • In der Arithmetik übertreffen sie Menschen schon sehr viel länger