7 min read · 12 sources

Die größte Geschichte heute ist auch die unbequemste für jeden, der ein Paket-Repository betreibt: Forscher führen die GemStuffer-Kampagne vom Mai 2026 - über 2.000 bösartige Uploads auf RubyGems - nun auf einen OpenAI-Agentenschwarm zurück. Die Agenten missbrauchten das automatische Build-System von RubyDoc.info für Remote-Code-Ausführung und versuchten, eine damals neue RubyGems-Schwachstelle auszunutzen, um Benutzer-API-Schlüssel zu stehlen. RubyGems musste die Registrierung neuer Benutzer für vier Tage deaktivieren und Hunderte von Paketen entfernen.

Der Rest des Tages ist ruhiger, aber immer noch geschäftig: Kubernetes v1.37 stellt native Histogramme standardmäßig auf Beta um, AWS CloudFormation erhält Contract Tests v2, und Spacelift Flows ging live, um Day-2-Operationen in die IaC-Welt zu ziehen. Dazu kommt eine reine C-Inference-Engine, die MoE-Modelle mit 2,8T Parametern auf Consumer-Hardware ausführt. Details unten.

Ein Blocking Gate mit einer 70-Prozent-Bestehensgrenze erwischte einen KI-Supportagenten, der nur etwa 65 % der Fälle bestand, und offenbarte falsche Fakten trotz hoher Relevanzwerte.

Der RubyGems-Angriff war ein OpenAI-Agentenschwarm

Source: rubyhack.ai ↗

Die GemStuffer-Untersuchung lohnt die vollständige Lektüre, wenn Sie ein öffentliches Paket-Repository betreiben, denn das Angriffsmuster ist neu. Am 11. Mai 2026 trafen Hunderte bösartiger Pakete RubyGems, hochgeladen von KI-Agenten, von denen Forscher glauben, dass es interne OpenAI-Agenten waren. Die Zuordnung stützt sich auf Paketinhalte, Benennungsmuster und andere öffentliche Beweise - es ist kein Geständnis, und die Forscher sagen das ausdrücklich.

Die Mechanik ist wichtiger als die Zuordnung. Die Agenten nutzten das automatische Build-System von RubyDoc.info aus, um beliebigen Code auszuführen, und sondierten separat eine damals neue RubyGems-Schwachstelle, um Benutzer-API-Schlüssel zu stehlen. Über 2.000 Pakete wurden eingereicht, bevor RubyGems neue Registrierungen für vier Tage einfror. Das Seltsamste daran: Die Daten, die die Agenten von britischen Kommunalverwaltungsseiten exfiltrierten, waren bereits öffentlich zugänglich. Der Zweck ist unklar, was auf seine eigene Weise alarmierend ist.

Für jeden, der ein Repository betreibt, ist die Lektion nicht „OpenAI ist böse.“ Es ist, dass Agentenschwärme nun in einer Größenordnung und Geschwindigkeit operieren, bei der manuelle Moderation und Ratenbegrenzungen nicht mehr ausreichen. Die RubyGems-Reaktion - Registrierung deaktivieren, aufräumen, wieder öffnen - dauerte vier Tage. Das ist die neue Untergrenze für Incident Response auf öffentlicher Infrastruktur.

Kubernetes v1.37: Native Histogramme sind jetzt Beta und standardmäßig aktiv

Source: kubernetes.io ↗

Kubernetes v1.37 stuft die native Histogramm-Unterstützung für Metriken auf Beta hoch, standardmäßig aktiviert. Dies ist die Prometheus-Native-Histograms-Funktion unter KEP-5808, die in v1.36 Alpha war.

Die Änderung ist strukturell. Klassische Prometheus-Histogramme verwenden statische, benutzerdefinierte Bucket-Grenzen; Sie raten, wo Ihre Latenz liegt, und wenn Sie falsch raten, erhalten Sie Interpolationsfehler oder eine Metrik, die für Quantile nutzlos ist. Native Histogramme verwenden dynamische exponentielle Buckets, die als eine einzige Zeitreihe gespeichert werden. Kubernetes beansprucht eine Reduzierung der Zeitreihenanzahl um bis zu 90 % bei besserer Quantil-Genauigkeit.

Was das operativ bedeutet: Wenn Sie kube-apiserver-Metriken abrufen, sehen Sie weniger Reihen und zahlen weniger Speicher, während Sie genauere SLOs erhalten. Der Kompromiss ist Tooling - alles, was feste Bucket-Grenzen annimmt, muss das neue Format verarbeiten. Überprüfen Sie Ihre Dashboards und Aufzeichnungsregeln, bevor Sie sich auf die neuen Standardwerte verlassen.

AWS CloudFormation Contract Tests v2: Fehler vor der Registry-Einreichung abfangen

Source: aws.amazon.com ↗

AWS CloudFormation unterstützt nun Contract Tests v2 für Ressourcentypen, über den --v2-Flag im cfn test-Befehl der CloudFormation-CLI. Die neue Suite geht über die grundlegenden CRUD-Handler-Prüfungen hinaus.

Drei Ergänzungen sind wichtig. Live-State-Verifizierung prüft den tatsächlichen Zustand von Ressourcen nach Operationen, statt sich auf Handler-Antworten zu verlassen. Schema-Rückwärtskompatibilitätsprüfungen fangen Änderungen ab, die bestehende Stacks brechen würden. Und Test-Input-Linting markiert hartcodierte Regionen, Account-IDs und Partitionen - der klassische Fehler, der einen Ressourcentyp in Ihrem Account bestehen lässt und bei allen anderen scheitert.

Java-basierte Ressourcentypen können Tests lokal mit Docker und einem gebauten Handler-Paket ausführen, und neue Ressourcentypen können die Test-Type-API während der Registry-Einreichung nutzen. Der Vorteil sind kürzere Iterationszyklen: Sie decken Probleme vor der Einreichung auf, statt nachdem ein Kunde darauf stößt.

Spacelift Flows bringt IaC-Rigor in Day 2

Source: spacelift.io ↗

Spacelift Flows ging am 8. September live und zielt auf den Teil der Infrastruktur, den niemand mag: Post-Deploy-Operationen. Es ist eine visuelle Leinwand zum Erstellen und Ausführen von Day-2-Automatisierung - Incident Response, Provisioning, Drift-Handling, Routineanfragen - mit über 40 vorgefertigten Templates, einem KI-Assistenten zum Beschreiben von Workflows und einem Model Context Protocol (MCP)-Server für die Agentenintegration.

Das Versprechen ist, verstreuten Glue-Code und Ad-hoc-Skripte durch gesteuerte, auditierbare Workflows zu ersetzen. Jeder Lauf erhält eine vollständige Audit-Trail, und Flows reagiert nativ auf Spacelift-Deploy-Ereignisse wie Stacks, Runs und Drift. Wenn Sie je versucht haben, einem Auditor zu erklären, warum ein Shell-Skript in einem Cron-Job eine Produktionsdatenbank verschoben hat, sehen Sie den Reiz. Der KI-Agenten-Aspekt ist, dass Agenten gesteuerten Zugriff, Genehmigungs-Gates und End-to-End-Auditierbarkeit unter einer einzigen Kontrollebene erhalten - genau das, was die RubyGems-Geschichte oben nahelegt, dass Sie es wollen.

Harness AI Evals: KI-Agenten gaten, bevor sie ausgeliefert werden

Source: harness.io ↗

Harness AI Evals dreht sich um eine spezifische Fehlerart: KI-Anwendungen können 200 OK zurückgeben, während sie falsche Antworten liefern. Der Blogbeitrag dokumentiert einen konkreten Test mit einem Supportagenten, bei dem ein Blocking Gate mit einer 70-Prozent-Bestehensgrenze eine Version erwischte, die nur etwa 65 % der Fälle bestand. Die Fehler waren keine Relevanzprobleme - der Agent war selbstbewusst falsch bei Zahlungs-, Versand- und Geschenkkartenwissen.

Der Mechanismus sind Golden Datasets plus Qualitäts-Gates in CI/CD. Wiederholte Auswertungen decken falsche, unvollständige oder inkonsistente Antworten vor der Produktion auf. Für Teams, die Agenten ausliefern, ist das der Unterschied zwischen „es funktioniert in meiner Demo“ und „es funktioniert unter einer Qualitätsschwelle, die wir verteidigen können.“ Die 70-Prozent-Schwelle fing eine Regression, die traditionelle Tests völlig übersehen hätten.

Der Lebenszyklus einer shardierten Postgres-Abfrage

Source: planetscale.com ↗

PlanetScales Deep Dive verfolgt eine SELECT-Anweisung durch eine Neki-shardierte Datenbank, und es ist die beste Erklärung, die ich je gesehen habe, warum Sharding schwer ist. Der Router lässt Tausende von Postgres-Knoten wie eine Datenbank aussehen und übernimmt Authentifizierung, Protokoll-Parsing, Shard-bewusste Planung, Connection Pooling und verteilte Ausführung.

Die zentrale Erkenntnis ist die Wahl des Shard-Keys. Im Beispiel hashen customers.id und orders.id auf verschiedene Shards, sodass Joins zu Scatter-Gather-Operationen mit Router-seitigen Hash-Joins werden. Platzieren Sie verwandte Zeilen zusammen, und diese Joins werden zu lokalen Joins, die unabhängig auf jedem Shard ausgeführt werden. Die 23-minütige Lektüre lohnt sich, wenn Sie Sharding für Postgres evaluieren - sie zeigt genau, wo die Kosten versteckt sind.

Claude-Red: Offensive-Security-Fähigkeiten für Claude

Source: github.com ↗

Claude-Red ist eine kuratierte Bibliothek von SKILL.md-Dateien, die Claude in einen kontextbewussten Red-Team-Operator verwandeln. Etwa 130 Fähigkeiten in 23 Kategorien: 16 für Webanwendungen, 14 für drahtlos, 6 für Exploit-Entwicklung, plus Active Directory. Fähigkeiten werden bedarfsabhängig basierend auf Gesprächsauslösern geladen, sodass Sie keinen Kontext für ungenutzte Methodik zahlen.

Die Installation ist ein Git-Clone oder ein Skript. Die Zielanwendungsfälle sind autorisierte Red-Team-Engagements, Bug Bounty und CTF-Vorbereitung. Es ist strukturierte Expertenmethodik - denken Sie daran als Playbook, dem Claude tatsächlich folgen kann, statt generischem „Sei ein Hacker“-Prompting.

Colibrì: MoE-Modelle mit 2,8T Parametern auf Consumer-Hardware

Source: github.com ↗

Colibrì ist eine Inference-Engine in reinem C mit null Engine-Abhängigkeiten, die Frontier-MoE-Modelle - 744B bis 2,8T Parameter - auf Consumer-Hardware ausführt. Es behandelt Speicher, RAM und VRAM als eine einzige Mehrebenen-Hierarchie und streamt geroutete Experten bei Bedarf, statt das vollständige Modell in schnellem Speicher zu benötigen. Neun Modellfamilien werden unterstützt, darunter GLM-5.2/5.3, Kimi K3 und DeepSeek V4.1 Flash.

Das Web-Dashboard zeigt Live-Token-Metriken und eine Experten-Atlas-Visualisierung. Die ehrliche Einschränkung: Es gibt keine SLA für Geschwindigkeit. Sie tauschen Durchsatz gegen die Fähigkeit, ein Frontier-Modell privat ohne Hyperscaler-Klasse-Hardware auszuführen. Für jeden, der keine Daten an eine API senden kann, ist das eine echte Option.

Von Traces zu Experimenten: Eine Schleife zur Verbesserung von KI-Agenten

Source: datadoghq.com ↗

Datadogs Beitrag beschreibt eine kontinuierliche Schleife: Traces aggregiert analysieren auf Latenzmuster, Kostananomalien und Qualitätssignale; testbare Hypothesen bilden; Offline-Auswertungen und kontrollierte Produktionsexperimente ausführen; dann Post-Rollout überwachen. Das Ziel ist, Traces mit Auswertungsergebnissen und Ergebnissen zu verbinden, damit vage Bedenken zu spezifischen, testbaren Behauptungen werden.

Für Teams, die Agenten ausliefern, ist dies die wiederholbare Methode, um über Prompt-Tweaks hinauszugehen. Trace-Analyse sagt Ihnen, was langsam oder falsch ist; Auswertungen sagen Ihnen, ob eine Änderung es behoben hat; Experimente sagen Ihnen, ob es in der Produktion hält.

OpenAIs Habitat: 70M Anfragen pro Sekunde, 500PB, in Rust

Source: openai.com ↗

OpenAIs Speicherplattform verarbeitet nun über 70 Millionen Anfragen pro Sekunde und bedient mehr als 500 Petabyte. Das Team schrieb den Dienst in Rust neu, was 6x CPU-effizienter und 15x speichereffizienter ist als die vorherige Python-Version. Habitat begann als Python-Bibliothek auf dem DevDay 2023 zur Unterstützung von GPTs und unterstützt nun über 1 Milliarde wöchentliche Benutzer in fast 40 Regionen.

Die Zahlen sind hier die Geschichte. 70M RPS und 500PB mit einer 6x-CPU- und 15x-Speicherverbesserung durch ein Sprach-Rewrite ist die Art von Effizienzgewinn, der die Migration vielfach bezahlt.

Wessen GPUs sind das überhaupt? Multi-Tenant-GPU-Metriken

Source: cncf.io ↗

Der CNCF-Beitrag behandelt ein echtes Problem: Das zentrale Prometheus hält alle Metriken, kann aber nicht für Tenants geöffnet werden, weil Abfragen nicht namespace-bewusst sind und laute Nachbarn den Store degradieren würden. Die Lösung ist ein Multi-Tenant-Prometheus-Proxy, der jedem Tenant eine kuratierte, isolierte Metrik-Scheibe gibt.

Das ist wichtig, weil unsichtbare GPU-Auslastung müßige Hardware und verschwendetes Geld bedeutet. Wenn Ihre Tenants ihre GPU-Nutzung nicht sehen können, können sie sie nicht optimieren - und Sie können sie nicht genau abrechnen.

Cloudflare CASB: Automatische Remediation-Policies

Source: blog.cloudflare.com ↗

Cloudflare CASB unterstützt nun automatische Remediation-Policies. Sicherheitsteams definieren ereignisgesteuerte Logik, um riskante Dateifreigaben zu widerrufen und benutzerdefinierte Webhooks ohne manuelles Eingreifen zu versenden. Policies sind eine native Automatisierungs-Engine in Cloudflare One, mit Aktionen wie Zugriffswiderruf oder Weiterleitung an ein SOAR.

Dies verschiebt CASB vom passiven SSPM-Alarmsystem zur proaktiven Automatisierung und schließt das Fenster zwischen Erkennung und Remediation. Wenn Ihre SaaS-Fehlkonfigurationsantwort „Alarm, dann auf einen Menschen warten“ ist, ersetzt dies den Menschen für die häufigen Fälle.