5 min read · 12 sources

Falls langfristig gültige GitHub‑Personal‑Access‑Tokens in CI‑Pipelines oder Entwickler‑Workstations herumschwirren, sollten sie heute Morgen rotiert werden. Eine automatisierte Kampagne namens Gheist hat systematisch kompromittierte Anmeldedaten über private und Enterprise‑Repositories verteilt, um GitHub‑Actions in ein internes Datenexfiltrations‑Netzwerk zu verwandeln.

Die Technik des Angreifers umgeht externe Command‑and‑Control‑Server vollständig. Durch das Committen von Workflows, die Geheimnisse kodieren, um das native Log‑Masking zu umgehen, und das Auslesen der rohen Logs über die GitHub‑API, läuft die Operation still innerhalb der eigenen Infrastruktur von GitHub.

Unterdessen erfährt die Infrastruktur, die Git selbst zugrunde liegt, die größte architektonische Umgestaltung ihrer Geschichte. KI‑Agenten treiben Schreibvolumen über die physischen Grenzen traditioneller Bare‑Metal‑Rechenzentren hinaus, wodurch GitHub fast sämtliche Daten in öffentliche Cloud‑Speicher migrieren muss.

Gheist drang in 13.500 Branches ein, bevor GitHubs Token‑Kontrollen ihn schließlich erwischten.

Gheist weaponisiert GitHub Actions durch base32‑Log‑Umgehung

Source: wiz.io ↗

Wiz Research hat Gheist offenbart, eine automatisierte Kampagne, die kompromittierte GitHub‑Anmeldedaten missbraucht, um Repository‑Secrets zu ernten. Seit Mitte September haben die Betreiber über 850 Konten angegriffen und mehr als 13.500 Branches erzeugt.

Die Angriffsmethodik ist einfach und effektiv. Die Automation pusht einen Branch namens ci-sync-* mit einem bösartigen Workflow unter .github/workflows/sync-check.yml. Beim Ausführen gibt der Workflow Umgebungsvariablen und Repository‑Secrets aus. Um GitHubs Standard‑Log‑Scrubber zu umgehen - dieser redaktiert Zeichenketten, die bekannten Secret‑Mustern entsprechen - kodiert die Nutzlast die ausgegebenen Werte base32, bevor sie auf stdout geschrieben werden.

Anstatt eine Auswärtsverbindung zu einem externen Server aufzubauen, was Netzwerk‑Alarme auslösen könnte, nutzt der Akteur die GitHub‑REST‑API, um die Workflow‑Ausführungs‑Logs direkt abzurufen. Während GitHub Guardrails implementierte, die die Kampagne über öffentliche Repositories abschwächten, bleiben private und Enterprise‑Repos verwundbar, wenn ein Identitäts‑Konto mit Schreib‑Zugriff kompromittiert ist. Audit‑Logs sollten sofort auf unautorisierte Branch‑Erstellungen nach dem Muster ci-sync-* geprüft werden.

GitHub migriert 99.99999 % der Repositories zu Azure für Agent‑Write‑Scale

Source: github.blog ↗

Angesichts physischer Leistungsgrenzen und Lieferketten‑Engpässe in den eigenen Rechenzentren hat GitHub eine Kopie von 99.99999 % seiner Git‑Repositories zu Azure verschoben. Die neue Topologie, die seit August 2025 in Produktion ist, teilt fünf Replikate pro Repository: drei auf Bare‑Metal und zwei in Azure, wobei Azure bereits die Hälfte des gesamten Git‑Traffics verarbeitet.

Das zentrale technische Problem war die Schreib‑Latenz. Git verwendet typischerweise repository‑weite Locks während Schreibvorgängen. In cross‑regionalen Topologien führt die Serialisierung von Writes zu einem Kollaps der Durchsatz‑Kapazität, wenn KI‑Coding‑Agenten Hunderte gleichzeitiger Branches und Pull‑Requests öffnen. GitHub löste das, indem Speicher von Compute entkoppelt und zu per‑Reference‑Quoren gewechselt wurde. Writes zu unterschiedlichen Branches oder Tags konkurrieren nicht mehr um denselben Repository‑Lock, wodurch die Latenz auf 25 ms sank und der Schreib‑Durchsatz um das 3‑ bis 4‑fache gesteigert werden konnte.

Cloudflares Q3‑Ausfalldaten zeigen physische und politische Fragilität

Source: blog.cloudflare.com ↗

Der Cloudflare Radar Q3 2026 Internet‑Disruption‑Report verzeichnete 49 größere globale Netzwerk‑Ausfälle. Während SREs immense Zeit in die Abwehr von Software‑Regressionen investieren, dominierten physische und geopolitische Fehlermodelle das Quartal.

Regierungs‑gesteuerte Abschaltungen machten 19 Vorfälle aus, darunter 18 koordinierte Blackouts im Irak, um Betrug bei nationalen Prüfungen zu verhindern. Stromnetz‑Ausfälle lösten 14 größere Störungen aus und trafen die Infrastruktur in Kuba und der Ukraine, während Naturkatastrophen für fünf Ausfälle verantwortlich waren. Für Teams, die Multi‑Region‑Architekturen bauen, erinnert dieser Befund daran, dass BGP‑Routen und redundante Transit‑Provider keinen toten Strom‑Grid oder staatlich verlegte Glasfaserkabel umgehen können.

Stoppen Sie das Kräftemessen der Kubernetes‑Autoscaler

Source: thenewstack.io ↗

Kubernetes‑Scaling‑Controller arbeiten in entkoppelten, asynchronen Reconciliation‑Loops. Kombiniert man Horizontal Pod Autoscaler (HPA), Vertical Pod Autoscaler (VPA), KEDA und Karpenter im selben Cluster, lösen diese Loops rasch Ressourcen‑Thrashing aus, wie die Analyse von The New Stack zu Autoscaler‑Kontention beschreibt.

Das Problem entsteht, weil Controller dieselben API‑Felder ohne gemeinsamen Kontext mutieren. VPA ändert CPU‑ und Memory‑Requests, um Pods zu right‑size, wodurch die Auslastungs‑Prozentsätze, die HPA zur Berechnung der Ziel‑Replica‑Zahl nutzt, verändert werden. Gleichzeitig skaliert KEDA Replicas basierend auf externen Message‑Queues, und Karpenter provisioniert oder konsolidiert zugrundeliegende EC2‑Nodes nach ausstehenden Pod‑Specs.

Diese Rennbedingungen führen zu GitOps‑Drift, Eviction‑Loops und Ressourcen‑Ping‑Pong. Kurup argumentiert, dass die Behandlung von Scaling als unabhängige Unix‑Style‑Pipes fehlerhaft ist; Plattform‑Teams benötigen autonome, prädiktive Scaling‑Engines, die Replica‑Zahlen, Pod‑Dimensionen und Node‑Kapazität in einer einzigen Entscheidungs‑Schleife berechnen.

Goldene Pfade benötigen strikte Grenzen für KI‑Agenten

Source: spacelift.io ↗

Plattform‑Teams, die interne Developer‑Portale ausrollen, passen Architekturen an, um nicht‑menschliche Mitwirkende zu unterstützen. Ein Leitfaden von Spacelift zu Golden Paths zeigt, wie Self‑Service‑Infrastructure‑Blueprints weiterentwickelt werden müssen, wenn sowohl Entwickler als auch autonome Coding‑Agenten sie nutzen.

Ein funktionaler Golden Path erfordert fünf Bausteine: standardisierte Infrastructure‑as‑Code‑Module, CI/CD‑Pipeline‑Definitionen, Policy‑as‑Code‑Guardrails, Dokumentation und einen Developer‑Portal‑Eintrag. Werden Pfade über APIs oder Model Context Protocol (MCP)‑Server für KI‑Agenten bereitgestellt, führen lose definierte Freitext‑Schnittstellen zu fehlerhaft konfigurierten Cloud‑Primitiven. Plattformen müssen typisierte Eingaben, deterministische Schemata und Least‑Privilege‑Service‑Identitäten erzwingen, damit Agenten Ressourcen wie Multi‑AZ‑Datenbanken bereitstellen können, ohne Compliance‑Guardrails zu umgehen.

Scrape‑Walls und persistente KI‑Teamkollegen über die CLI verwalten

Source: github.com ↗

Zwei neue Open‑Source‑Projekte zielen darauf ab, die Reibung für lokale und autonome Agent‑Operationen zu reduzieren:

• Agent‑Reach stellt Agenten ein einheitliches CLI bereit, um Inhalte hinter Authentifizierungs‑Walls und komplexen Web‑Properties abzurufen. Es nutzt einen lokalen headless Browser, um saubere Daten aus YouTube‑Transkripten, GitHub, Bilibili und Xiaohongshu zu extrahieren, ohne dedizierte API‑Gebühren oder eigene Scraper‑Wartung.
• OpenBot bietet einen local‑first Desktop‑Workspace zur Orchestrierung persistenter KI‑Teamkollegen über mehrere LLM‑Backends (Codex, Claude Code, Gemini, Grok). Er enthält integriertes Browsing, Agent‑zu‑Agent‑Messaging und einen optionalen OS‑Automation‑Driver. Betreiber sollten beachten, dass die aktuelle Preview mit danger-full-access und approvalPolicy: never ausgeliefert wird, was lokale Systembefehle ohne menschliche Bestätigung ausführt.

vLLM‑Tool‑Calling‑Bugs beheben und GPU‑Kosten optimieren

Source: ubicloud.com ↗

Open‑Weight‑Modelle erzeugen häufig fehlerhaftes JSON bei verschachtelten Funktionsaufrufen, was Agent‑Ausführungs‑Loops beschädigt. In einem Benchmark von Ubicloud zur vLLM‑Tool‑Call‑Accuracy scheiterte vLLM 0.28 beim Servieren von Kimi K2.6 in 8 % seiner strukturierten Tool‑Aufrufe. Das neu veröffentlichte vLLM 0.31 löst das durch ein serverseitiges constrained‑decoding‑Flag, das 100 % Schema‑Konformität auf Token‑Ebene für Kimi‑ und DeepSeek‑Architekturen erzwingt.

Bevor teurere Silizium‑Ressourcen für KI‑Workloads eingesetzt werden, sollten Plattform‑Teams auch die Wirtschaftlichkeit von Jobs prüfen. Ein operatives Handbuch zur Optimierung von Kubernetes‑GPU‑Pools empfiehlt, strenge Latenz‑, Deadline‑ und Unterbrechungs‑Toleranz‑Budgets festzulegen, bevor Node‑Gruppen erweitert werden. Gestufte Scheduling‑Fenster für Batch‑Inference glätten Spitzen‑Nutzungs‑Spikes und ermöglichen bestehenden Clustern, höhere Volumina zu absorbieren, ohne zusätzliche GPU‑Kapazität zu kaufen.

Google und Meta open‑source TorchTPU; AWS liefert Agent‑Telemetry

Source: infoq.com ↗

Abschließend die Tool‑Updates für Plattform‑ und SRE‑Teams:

• TorchTPU‑Launch: Auf der PyTorch‑Conference haben Google und Meta TorchTPU open‑sourct, ein natives Backend, das PyTorch/XLA ersetzt. Es erlaubt Engineer*innen, Ziel‑Hardware mit model.to("tpu") zu wechseln und bietet out‑of‑the‑box Support für vLLM, SGLang und TorchTitan, wobei lineares Scaling über 8.192 TPU v7x‑Chips demonstriert wird.
• Agent‑Observability auf EKS: AWS veröffentlichte ein Deep‑Dive zu Observability‑Mustern für KI‑Agenten auf Amazon EKS. Standard‑HTTP‑Health‑Checks erfassen agent‑spezifische Ausfälle wie zirkuläre Tool‑Calls, Reasoning‑Drift und Kontext‑Window‑Erschöpfung nicht. SREs müssen Traces instrumentieren, die pro‑Request‑Token‑Verbrauch, Tool‑Spans und Kosten‑Attributions‑Metriken direkt erfassen.
• Supabase scoped Access Tokens: Supabase hat scoped Personal Access Tokens eingeführt, die account‑weite Anmeldedaten ersetzen. Administratoren können nun Token‑Berechtigungen auf spezifische Projekte beschränken, strenge Ablauf‑Fenster bis zu einem Jahr setzen und den Zugriff gezielt für CI/CD‑Runs und MCP‑Tools scope‑en.