Ein lokales Sprachmodell sollte PHP2Shell finden. Es fand die Schwachstelle nicht. Das klingt zunächst beruhigend. Ein professioneller Angreifer muss aber nicht warten, bis ein Modell die gesamte Arbeit allein erledigt. Es reicht, wenn es ihm brauchbare Teile davon abnimmt. Läuft es bei ihm, braucht er dafür keinen Account, den ein Anbieter sperren könnte.
Providerfilter können einen Dienst schützen und Missbrauch erschweren. Gemeint sind hier die Kontrollen eines gehosteten Dienstes: von modellseitigen Ablehnungen über Telemetrie und Werkzeuggrenzen bis zur Accountsperre. Ein Threat Model, also eine begründete Vorstellung von Gegnern, Fähigkeiten, Zielen und Zugangswegen, ersetzen sie nicht.
Angenommen, ein Unternehmen stuft KI-gestützte Schwachstellenforschung als unwahrscheinlich ein, weil der eigene Assistent solche Anfragen ablehnt. Ein Gegner könnte dagegen öffentlich verfügbare Gewichte lokal mit Quellcode, Compiler, Fuzzer und Debugger verbinden. Wer seine Sicherheitsannahmen daraus ableitet, was der eigene Chatbot ablehnt, beschreibt zunächst die Regeln dieses Chatbots. Nicht die Fähigkeiten des Gegners.
Der lokale Versuch verbindet unsere Beiträge zu delegierten Angriffsschritten, zur verwundbaren PHP-Laufzeit und zur Arbeit nach dem Notfallupdate: Wie viel Kontrolle bleibt beim Modellanbieter, wenn Werkzeuge, Gewichte und Entscheidungen beim Angreifer liegen?
Der lokale Lauf scheiterte – aber nicht an allem
XDA-Redakteur Adam Conway beschreibt einen Forschungsversuch mit DeepSeek V4.1 Flash 1017 auf zwei lokalen DGX-Spark-Systemen. Über das Pi-Coding-Harness erhielt das Modell Shell- und Docker-Zugriff. Es konnte PHP aus dem Quellcode bauen, Debug-Versionen erzeugen und mit AddressSanitizer nach Speicherfehlern suchen.
Conway wusste bereits, dass kritische Lücken existierten. Das System bekam eine öffentliche Demo und Quellcode; während des Laufs lieferte er einen Hinweis auf Session Upload Progress nach, die Fortschrittsverfolgung von Uploads. Das Modell untersuchte die Verarbeitung eingehender Anfragen, vermutete über mehrere Anfragen erhaltenen Worker-Zustand und formulierte die Idee, dass Speichermangel normales Aufräumen unterbrechen könnte. Dann testete es stattdessen einen Timeout, machte Fehler in Testskripten und verließ den Ansatz nach erfolglosen Versuchen.
Besser funktionierte die Prüfung fremder Behauptungen. Nach Conways Bericht testete das System angebliche öffentliche Exploitnachweise gegen einen unveränderten und einen absichtlich veränderten PHP-Build und konnte die vorgeschlagene Erklärung verwerfen. Die eigentliche Schwachstelle reproduzierte es nicht. Einen einmaligen Worker-Crash kann Conway mangels erhaltener Logs nicht mehr zuordnen. Er taugt deshalb nicht als nachträglicher Trefferbeleg.
„Fast gefunden“ ist hier keine messbare Entfernung zum fertigen Exploit. Der Lauf lieferte weder den konkreten Schwachstellennachweis noch eine stabile Kette zur Codeausführung. Eine belastbare Zeitersparnis gegenüber menschlichen Forschern lässt sich daraus ebenfalls nicht berechnen. Sichtbar wird aber eine lokale Forschungsumgebung, in der ein Modell relevante Hypothesen bildet, reale Builds untersucht und Behauptungen experimentell prüft.
Warum die richtige Fehlerklasse trotzdem zählt
Die PHP-Advisory zur OOM-Korruption beschreibt, wie ein Abbruch wegen Speichermangels nur teilweise initialisierten Zustand hinterlassen kann, den späteres Aufräumen dennoch verarbeitet. OOM steht für Out of Memory. Die zweite Advisory behandelt unter anderem globale Worker-Verweise auf bereits freigegebenen Anfragespeicher. Verarbeitet derselbe PHP-Prozess eine weitere Anfrage, kann er solche Altlasten verwenden, bevor die normale Initialisierung sie zurücksetzt.
Das sind verwandte Fehlerklassen, keine überall identische Angriffskette. Serveranbindung, Anwendung und Zeitpunkt des Abbruchs bestimmen, welche Wege erreichbar sind. Der zentrale PHP-Fix trägt entsprechend den Titel „Avoid state corruption via bailout“ und ändert sowohl den OOM-Abbruch als auch das Zurücksetzen verschiedener globaler Zustände.
Zwischen einer passenden Hypothese und verlässlicher Codeausführung liegt erhebliche Arbeit: den beschädigten Zustand nachweisen, ihn reproduzierbar erreichen, nutzbare Speicherpreisgabe oder kontrollierbare Speicheroperationen gewinnen und eine belastbare Kette für den jeweiligen Build herstellen. Die Hypothese ersetzt diese Arbeit nicht. Sie kann aber entscheiden, wo ein Spezialist seine Zeit investiert.
Den stärkeren Gegenpart zum gescheiterten Versuch liefert Califs eigener Forschungsbericht. Ryan Austin griff gezielt alte PHP-memory_limit-Forschung auf. Sein Modell half zunächst bei Wegen zu kontrolliertem Speichermangel und anschließend bei der Suche nach unterbrechbaren Operationen. Daraus entstanden erfolgreiche RCE-Pfade, also Wege zur entfernten Codeausführung. Für die anfängliche Entdeckung seien weder ein besonderes Harness noch exklusiv verfügbare Modelle nötig gewesen. Über lokalen Betrieb sagt der Bericht nichts aus. Entscheidend war auch die menschliche Auswahl einer historischen Fehlerklasse.
Conway hätte mit besserer Steuerung deshalb nicht zwangsläufig ebenfalls einen Exploit entwickelt. Calif zeigt aber, dass menschliche Zielkenntnis und maschinelle Analyse sich in erfolgreicher Schwachstellenforschung ergänzen können. Vollautonomie ist dafür keine Voraussetzung.
Ein professioneller Gegner muss nicht auf Vollautonomie warten
Für die defensive Planung ist deshalb eine engere Annahme nützlich: Ein fachkundiges Team kann öffentlich verfügbare Gewichte lokal mit Forschungswerkzeugen verbinden, Hypothesen prüfen und Zwischenbefunde an Spezialisten übergeben. Dafür muss das Modell keine Zero-Days allein entwickeln. Welche Akteure damit welchen Aufwand und welche Erfolgsquote erreichen, ist eine eigene Frage.
Ein Team mit PHP-Erfahrung könnte etwa den Widerspruch zwischen OOM-Hypothese und Timeout-Test erkennen, einen interessanten Fehlerzustand als Artefakt sichern und reproduzierbar untersuchen. Ob das in Conways Fall gereicht hätte, bleibt offen.
Mehrere Läufe können zudem unterschiedliche Hypothesen verfolgen. Ergebnisse lassen sich sichern und gegen feste Kriterien prüfen. Ein brauchbarer negativer Befund verhindert, dass weitere Stunden in dieselbe falsche Erklärung fließen. Parallelität garantiert keinen Erfolg; ohne gute Prüfkriterien skaliert sie vor allem überzeugend klingenden Unsinn.
In „Die Agenten bauten sich eine Organisation“ haben wir beschrieben, wie Wissen einzelner Agentenläufe in einem gemeinsamen Arbeitsprozess weiterverwendet werden kann. Das belegt keine geheime Cyberforschungsorganisation. Es zeigt eine organisatorische Möglichkeit, die beim Blick auf einen einzelnen fehlgeschlagenen Lauf leicht verschwindet.
Der mögliche wirtschaftliche Vorteil beginnt dort, wo Spezialisten weniger Routinearbeit selbst erledigen müssen und mehr Ansätze prüfen können. Sie brauchen keinen künstlichen Kollegen, der alles weiß. Einer, der zuverlässig einen Teil der Arbeit übernimmt, kann bereits nützlich sein. Ob eine konkrete Aufgabenverteilung diesen Vorteil tatsächlich bringt, muss das Team prüfen.
Was ein Provider kontrolliert – und was nicht
Bei einem gehosteten Dienst liegen wichtige Hebel beim Anbieter: Accountzugang, Ratenbegrenzung, Modellversion, Missbrauchserkennung, angebotene Werkzeuge und gegebenenfalls Sperren. Diese Maßnahmen sind an den jeweiligen Dienst gebunden.
Dass sie greifen können, ist dokumentiert. Microsoft berichtete am 14. Februar 2024 über gemeinsam mit OpenAI untersuchte Plattformnutzung staatlich verbundener Akteure. Beobachtet wurden unter anderem technische Recherche und grundlegendes Scripting; die zugeordneten Accounts wurden gesperrt. Der Bericht belegt weder autonome erfolgreiche Angriffe noch lokale Inferenz durch diese Akteure. Er zeigt die Kontrollfläche eines Dienstes, nicht die Grenzen lokal betriebener Systeme.
Bei heruntergeladenen, lokal ausführbaren Gewichten ist der Modellanbieter als zentraler Vermittler nicht zwingend beteiligt. Der Betreiber bestimmt die Laufzeitumgebung und die angebundenen Werkzeuge. Für seine Prompts muss er keinen externen Modellanbieter anfragen. Ein lokales Modell kann weiterhin Anfragen verweigern; seine Schutzmechanismen verschwinden nicht automatisch. Die spätere Accountsperre eines API-Anbieters schaltet diesen lokalen Prozess aber nicht ab.
DeepSeek veröffentlicht für DeepSeek-V4.1-Flash-1017 eine offizielle Modellkarte samt Gewichten unter MIT-Lizenz und eine Anleitung zur lokalen Inferenz. Die Verfügbarkeit ist damit bestätigt, Conways konkrete Zwei-DGX-Spark-Konfiguration haben wir nicht selbst geprüft. Öffentlich verfügbare Gewichte schaffen Zugang, aber keine gleichmäßige Fähigkeit. Ein ausreichend starkes System mit brauchbarer Geschwindigkeit zu betreiben und in einen verlässlichen Forschungsprozess einzubinden, braucht Compute, Engineering und Fachwissen. Auch ein hohes Budget garantiert diesen Prozess nicht.
Ohne Anfragen beim Modellanbieter gibt es dort auch keine entsprechende Prompt-Telemetrie. Unsichtbar wird der Betrieb dadurch nicht. Beschaffung, Hosting, Netzwerkverkehr, kompromittierte Systeme oder beschlagnahmte Datenträger können Spuren liefern. Nur die zentrale Beobachtungsstelle beim KI-Dienst ist nicht zwingend beteiligt.
Welche Akteure welche lokalen Systeme betreiben, wie gut diese funktionieren und wie autonom sie arbeiten, bleibt im Einzelfall offen. Daraus lässt sich kein allgemeiner Nachweis eigener Cybermodelle bei APTs oder Ransomwaregruppen machen. Für defensive Planung ist es trotzdem vernünftig, bei technisch und finanziell fähigen Gegnern den Zugang zu öffentlich verfügbaren Gewichten vorauszusetzen. Eine fehlende öffentliche Fallbeschreibung ist keine technische Zugangssperre.
Auch das lokale Arbeitssystem bleibt nicht unverändert
Wer gegnerische Fähigkeiten bewertet, sollte auch die Veränderbarkeit des Arbeitssystems berücksichtigen. Ein professionelles Team kann technische Unterlagen per Retrieval erschließen, geprüfte Arbeitsabläufe hinterlegen und bessere Testwerkzeuge anbinden. Dafür braucht es kein neues Basismodell. Fine-Tunes und eigene Trainingsläufe sind weitere Möglichkeiten, kein Beleg für ihren Einsatz bei bestimmten Angreifern.
Auch Arbeit am Modell selbst lässt sich teilweise delegieren. Im eng begrenzten Weight-Space-Programming-Versuch analysierte ein Frontier-Modell ein kleines Qwen-Modell mit Python. Laut Versuchsprotokoll verringerten gezielte Gewichtsänderungen vor allem ein Wiederholungsproblem und verbesserten die gemessenen Ergebnisse. Ein Gemma-Folgeversuch blieb ohne vergleichbaren Erfolg.
Das ist weder ein autonom entwickelter Frontier-Nachfolger noch ein Beleg rekursiver Selbstverbesserung. Ob offene Modelle solche Aufgaben ebenso zuverlässig erledigen, bleibt unbeantwortet. Für die Gegnerbewertung zählt zunächst die begrenztere Möglichkeit: Ein Team kann Unterstützung auch bei der Anpassung seines Systems erhalten. Die Grenzen eines unveränderten Modells beschreiben deshalb nicht automatisch die Grenzen des Teams.
Regulierung hat keine Rückholfunktion
Ein kopierter Checkpoint ist kein Account. Eine spätere Änderung der Nutzungsbedingungen ersetzt seine Parameter nicht, und eine API-Sperre löscht ihn nicht von einem fremden Rechner.
Regeln können zukünftige Veröffentlichungen, den Schutz unveröffentlichter Gewichte und die Bedingungen legalen Betriebs beeinflussen. Strafverfolgung und Infrastrukturmaßnahmen können Missbrauch verteuern und stören. Welche konkreten Instrumente sinnvoll und durchsetzbar sind, muss man gesondert prüfen. Kopierbarkeit macht nicht jede Regulierung wirkungslos und nicht jede Veröffentlichung gleich riskant.
Eine erwünschte zukünftige Zugangsbeschränkung ist allerdings keine heute wirksame Grenze gegen einen Gegner, der das Material bereits besitzt. Wer beides verwechselt, plant mit einer Kontrolle, die für diesen Gegner nicht existiert.
Verteidigung braucht mehr als denselben Chatbot mit guten Absichten
Aus PHP2Shell folgt ein konkreter Arbeitsauftrag: historische Fehlerklassen und alte Forschungsbefunde pflegen, Modelle gezielt auf verwandte Initialisierungs- und Aufräumfehler ansetzen und interessante Crashes samt Build, Eingaben und Logs sichern. Befunde müssen mit positiven und negativen Kontrollen reproduzierbar werden; Fixes gehören gegen Varianten geprüft. Maschinelle Unterstützung ist daran zu messen, ob mehr Probleme belastbar bestätigt und tatsächlich geschlossen werden, nicht ob mehr Reports entstehen.
Die Warnung aus „Automatisierter Müll ist auch ein Sicherheitsproblem“ bleibt: Ungeprüfte Modellmeldungen beschleunigen zunächst die Belastung der Fachleute. Ohne reproduzierbare Befunde entsteht eine besonders geschäftige Warteschlange.
Auch defensive Agenten brauchen Grenzen. Quellcode, Tickets, Logs und Samples sind Eingaben, keine Berechtigungen. Aus weitreichender isolierter Analyse folgen keine pauschalen Produktionsrechte. Reversible Maßnahmen lassen sich eng begrenzt delegieren; destruktive Eingriffe, weitreichende Sperren und Recovery brauchen festgelegte Verantwortung und belastbare Freigaben. Wer einen Fix gefunden hat, muss außerdem wissen, welche eigenen Systeme ihn brauchen und wer ihn einspielt. Ein zusätzliches Modell repariert keine ungeklärte Zuständigkeit.
Der lokale DeepSeek-Lauf hat PHP2Shell nicht gelöst. Er ist trotzdem ein guter Anlass, eine bequeme Annahme zu verabschieden: dass die Fähigkeiten des Gegners dort enden, wo ein kommerzieller Assistent die Antwort verweigert.
Ein Provider kann seinen Dienst kontrollieren. Für unsere Systeme bleiben wir selbst zuständig.
Titelbild: KI-generiertes Symbolbild zu lokaler KI-Forschung und den Grenzen zentraler Providerkontrolle. Bild in voller Auflösung öffnen.