Anthropic deckt 94 Sicherheitslücken in Open-Source auf

Was passiert

Anthropic hat durch seinen Frontier Red Team einen kritischen Trend in Open-Source-Projekten dokumentiert: 94 Fälle, in denen Software komplexe Funktionalität Unautentifizierten Nutzern offenlegt, obwohl diese deaktiviert oder unnötig sein sollten. Laut Help Net Security untersuchte Anthropic's Team 25 ausgewählte Open-Source-Projekte systematisch und nutzte Claude, um die Sicherheitsarchitektur dieser Systeme zu analysieren. Das zentrale Problem: Entwickler deaktivieren oder entfernen Sicherheitskontrollen häufig ohne explizite Warnung, was das Angriffspotenzial erheblich vergrößert.

Die Forscher fanden heraus, dass diese Sicherheitslücken typischerweise entstehen, wenn Open-Source-Projekte ihre Funktionalität erweitern, dabei aber veraltete oder redundant erscheinende Schutzmechanismen entfernen. Dies geschieht oft unbeabsichtigt im Refactoring-Prozess, wird aber nicht dokumentiert. Die Folge: Nutzer dieser Projekte verlieren Sicherheitsgarantien ohne Rückmeldung. Besonders kritisch ist dies bei Software, die in Agenten-Szenarien oder automatisierten Systemen zum Einsatz kommt. Wie Help Net Security berichtet, zeigt eine parallel durchgeführte Umfrage unter 1.100 IT- und Security-Entscheidern, dass 70 Prozent aller Organisationen KI-Agenten bereits Entscheidungen und Aktionen zulassen, die zuvor einer Freigabe durch Personen bedurften. Diese Kombination aus deaktivierten Kontrollen und erhöhter KI-Agent-Autonomie schafft ein exponentielles Risiko.

Zeitgleich warnen Forscher auf arXiv (cs.CR) vor automatisierten Red-Team-Angriffen auf Multi-Agent-Systeme mittels Reinforcement Learning, die gezielt Sicherheitslücken in LLM-basierten Agenten-Architekturen ausnutzen. Das Problem ist also nicht isoliert auf einzelne Projekte begrenzt, sondern systemisch für den gesamten KI-Infrastruktur-Stack relevant.

Warum für DACH relevant

Im deutschsprachigen Raum ist dieses Thema mit doppeltem Gewicht relevant. Zum einen verpflichtet die DSGVO Organisationen zur Dokumentation aller Verarbeitungsschritte und zur Gewährleistung angemessener technischer und organisatorischer Maßnahmen. Wenn Open-Source-Komponenten, die von DACH-Unternehmen genutzt werden, Sicherheitskontrollen ohne Warnung deaktivieren, entsteht automatisch eine Compliance-Lücke. Produktverantwortliche und Datenschutzoffiziere müssen aktiv nachvollziehen, welche Schutzmaßnahmen in ihren Software-Stacks noch wirksam sind — und das wird durch fehlende Transparenz massiv erschwert.

Zum anderen trifft dies den deutschen Mittelstand und europäische Softwareunternehmen, die zunehmend auf Open-Source-Komponenten und externe KI-Modelle setzen. Der EU AI Act (und damit auch die geltende Fassung in Deutschland und Österreich) wird voraussichtlich verschärfte Dokumentations- und Transparenzanforderungen für autonome KI-Systeme durchsetzen. Wenn Entwickler nicht mehr nachweisen können, welche Sicherheitsbarrieren in ihren Agenten-Systemen intakt sind, weil Open-Source-Dependencies diese still entfernt haben, wird die Zertifizierung und das Risikomanagement unmöglich. Besonders KI-Sicherheitstests und Pentesting-Programme (wie sie im KI-Pentesting-Kontext relevant sind) müssen daher verstärkt auf diese versteckte Entfernung von Kontrollen prüfen.

Konkret betroffen sind DACH-Organisationen, die:

• Open-Source-Abhängigkeiten in Produktionssystemen nutzen ohne regelmäßiges Sicherheits-Audit der Sourcecode-Änderungen
• KI-Agenten einsetzen, deren Infrastruktur auf nicht oder unzureichend dokumentierten Komponenten basiert
• Das Compliance-Risiko nicht erfassen, weil die fehlende Sicherheitsdokumentation von Upstream-Projekten nicht systematisch erfasst wird

Wie bei der Cairn-Missbrauch-Affäre zeigt sich auch hier: Werkzeuge zur KI-Sicherheit und Agenten-Automatisierung werden schneller eingeführt als die entsprechende Sicherheitskultur und Kontrollinfrastruktur aufgebaut werden kann.

Was du jetzt tun/wissen solltest

Der konkrete Handlungsschritt für DACH-Organisationen ist klar: Etabliere einen automatisierten Dependency-Tracking- und Sicherheits-Change-Prozess, nicht nur für Versionsübersicht, sondern speziell für Sicherheitskontrollen. Das bedeutet, dass beim Monitoring von Open-Source-Updates nicht nur "neue Version verfügbar" im Blick ist, sondern aktiv geprüft wird, ob sich in der neuen Version Sicherheitsmaßnahmen, Validierungen oder Authentifizierungsschritte geändert haben. Tools wie Software Composition Analysis (SCA) sollten um ein Modul erweitert werden, das explizit auf das Entfernen oder Abschwächen von Security-Checks hinweist.

Für Teams, die KI-Agenten betreiben: Jede Abhängigkeit sollte in einem Sicherheits-Pentesting-Prozess aufgetaucht werden — nicht nur beim initialen Setup, sondern kontinuierlich. Das Anthropic-Frontier-Red-Team hat mit seiner Analyse gezeigt, dass manuelles Code-Review und gezielte Red-Teaming-Angriffe (mit Claude oder ähnlichen Modellen) diese versteckten Schwachstellen zuverlässig offenlegen. Dies sollte nicht optional sein, sondern fester Bestandteil des Release-Prozesses, insbesondere wenn externe Agenten involviert sind.

Dokumentation ist das dritte Element: Auch wenn es aufwendig ist — jede deaktivierte Kontrolle in einer Dependency muss im Sicherheitskontext der Organisation erfasst und bewertet werden. Das ist nicht nur technisch sinnvoll, sondern auch DSGVO- und AI-Act-konform.

Quellen

• Help Net Security: Anthropic finds 94 cases where open-source projects drop security controls without warning
• arXiv cs.CR: Black-Box Red-Teaming of Multi-Agent Systems via Reinforcement Learning
• Help Net Security: AI agent permissions are outrunning security
• The Hacker News: OpenAI's GPT-6 Agent Removed Safety Monitoring, Then Falsely Denied Doing So