Kurzfassung
In Flyto2 Core steckt vor Version 2.26.7 eine kritische Schwachstelle im Verifizierungsdienst. Angreifer können den Dienst ohne Anmeldung ansprechen, über einen offenen POST-Endpunkt SSRF auslösen und dabei ein internes Runner-Secret abgreifen. Wer die Komponente produktiv betreibt, sollte den Update-Pfad auf 2.26.7 sofort prüfen.
Was ist passiert?
Betroffen ist der separate Dienst flyto-verification in Flyto2 Core. Er nimmt Anfragen an /run entgegen, obwohl dafür keine Authentifizierung nötig ist, und lauscht dabei auf 0.0.0.0:8344. Kritisch wird es beim Callback-Mechanismus: Der Dienst nutzt eine vom Client gelieferte callback_url für einen ausgehenden POST-Request und hängt dabei den Header X-Internal-Key: $FLYTO_RUNNER_SECRET an. Genau dadurch kann ein Angreifer nicht nur SSRF auslösen, sondern auch das interne Secret nach außen ziehen.
Technische Details
Die Lücke sitzt laut Beschreibung in src/core/verification_service.py. Der Dienst prüft das Ziel offenbar nicht sauber über target_allowed und überlässt die Zieladresse dem Angreifer. Das ist ein klassisches Muster für SSRF mit Folgeeffekt: Erst landet der Request an einem vom Angreifer gewünschten Ziel, dann wird ein vertraulicher Wert im Header mitgeschickt. In diesem Fall reicht das offenbar bis zur Exfiltration des Runner-Secrets.
Der Hersteller stuft den Fehler als kritisch ein. Ein Patch ist in Version 2.26.7 enthalten. Ob ältere Neben- oder Folgeversionen außerhalb der genannten Grenze ebenfalls betroffen sind, bleibt in der Quelle offen.
Wer ist betroffen?
Betroffen sind Systeme mit Flyto2 Core vor Version 2.26.7, sofern der standalone Dienst flyto-verification aktiv ist und von außen erreichbar gemacht wurde. Für Unternehmen im DACH-Raum ist das vor allem dann relevant, wenn Flyto2 in Automatisierungs- oder Agent-Workflows eingesetzt wird und solche Dienste in produktiven Netzen stehen. Ein exponierter Port auf 8344 ist hier das eigentliche Warnsignal.
Für Privatnutzer spielt das Thema nach aktueller Quellenlage keine große Rolle. Flyto2 Core ist ein Entwicklungs- und Automatisierungsbaustein, kein typisches Consumer-Produkt.
Empfohlene Maßnahmen
Wer Flyto2 Core betreibt, sollte zuerst auf 2.26.7 oder eine neuere Version wechseln. Das hat Priorität eins. Danach gehört geprüft, ob der Dienst überhaupt nach außen erreichbar ist. Wenn nicht zwingend nötig, darf 0.0.0.0:8344 nicht offen im Netz hängen.
Administratoren sollten außerdem den Callback-Mechanismus gegen Missbrauch absichern. Dazu gehört, externe Zieladressen strikt zu begrenzen, eingehende Requests auf den Verifizierungsdienst zu beschränken und Logs auf verdächtige /run-Aufrufe sowie unerwartete ausgehende Verbindungen zu prüfen. Wer den Dienst nicht braucht, schaltet ihn ab. Das ist oft schneller und sicherer als eine halbe Härtung.
Einschätzung von CyberSecurity-News.de
Die Schwachstelle ist technisch unschön und praktisch gefährlich. Dass ein interner Secret-Wert an eine clientseitig vorgegebene Zieladresse mitgegeben wird, ist kein Randproblem, sondern ein klarer Designfehler mit direktem Missbrauchspotenzial. Für Angreifer reicht hier ein unauthentifizierter Zugriff auf den offenen Dienst.
Die Quellenlage ist allerdings knapp. Die NVD-Beschreibung liefert die technischen Eckdaten, aber keine Angaben zu aktiven Angriffen, Ausnutzung im Feld oder zu weiteren betroffenen Komponenten. Genau deshalb sollte man das Thema nüchtern behandeln: nicht dramatisieren, aber auch nicht auf die lange Bank schieben.
Fazit
Flyto2 Core vor 2.26.7 hat eine kritische Schwachstelle im Verifizierungsdienst. Unauthentifizierte SSRF plus Secret-Abfluss ist ein ernstes Paket, vor allem in Umgebungen, in denen Automatisierungskomponenten mit internen Rechten laufen. Wer die Software einsetzt, sollte jetzt patchen, den Dienstzugang prüfen und das Secret-Handling kontrollieren.
Quellenangabe
Weiterführende Quelle: NVD – CVE-2026-67426
