Telegram-Media-Regression in OpenClaw 3.28: Downloads blockiert durch SSRF-Schutz

Key Takeaways:

• OpenClaw 3.28 blockiert durch einen neuen SSRF-Schutz ungewollt Telegram-Media-Downloads.
• Betroffen sind Bilder, PDFs und Voice-Nachrichten; reine Textnachrichten funktionieren weiterhin.
• Gängige Workarounds wie IPv6-Deaktivierung oder angepasste Hosts-Einträge greifen nicht.
• Ein Fix mit einem IPv4-Fallback-Mechanismus (Commit #45327) ist bereits in Arbeit.
• Ein Downgrade auf Version 3.24 stellt die Funktionalität sofort wieder her.

Nach dem Update auf OpenClaw 3.28 stehen Betreiber von Telegram-Bots vor einem unerwarteten Problem: Während Textnachrichten weiterhin problemlos verarbeitet werden, scheitern Downloads von Medien wie Bildern, PDFs oder Voice-Nachrichten konsequent. Bots, die auf die Analyse von Screenshots, das Parsen von Dokumenten oder die Transkription von Sprachnachrichten angewiesen sind, verlieren dadurch einen Großteil ihrer Funktionalität. Die Ursache liegt in einer verschärften Sicherheitsrichtlinie, die legitime API-Aufrufe blockiert.

Ursache: Zu aggressiver SSRF-Schutz

Verantwortlich für die Ausfälle ist der in Version 3.28 verschärfte Server-Side Request Forgery (SSRF) Schutz. Dieser Layer klassifiziert den Datei-API-Endpunkt von Telegram fälschlicherweise als interne oder reservierte IP-Adresse. In den Systemprotokollen äußert sich dies durch die Fehlermeldung Blocked: resolves to private/internal/special-use IP address.

Obwohl Telegram für die Dateiauslieferung öffentliche IPs nutzt, greift der SSRF-Guard im Kontext des Media-Fetch-Szenarios zu aggressiv ein. Laut Fehlerberichten der Community auf GitHub tritt das Problem plattformübergreifend auf – unter anderem auf macOS, Linux-Systemen und Raspberry Pis. Die Bot-Logik erkennt zwar noch Metadaten wie Dateigröße und Name, der eigentliche Download bricht jedoch ab.

Warum gängige Workarounds scheitern

Versuche, das Problem durch lokale Netzwerkanpassungen zu umgehen, bleiben wirkungslos. Weder das komplette Deaktivieren von IPv6 auf Router- oder Betriebssystemebene noch manuelle Einträge in der Hosts-Datei führen zum Erfolg. Auch Anpassungen in der OpenClaw-Konfiguration, wie das Setzen von autoSelectFamily oder das Patchen von DNS-Lookups via NODE_OPTIONS, greifen nicht.

Der Grund dafür ist architektonischer Natur: Der SSRF-Guard instanziiert einen eigenen undici-Agenten. Dieser ignoriert externe Netzwerkkonfigurationen vollständig und erzwingt eine isolierte, interne DNS-Auflösung.

Ausblick: IPv4-Fallback als Lösung

Die Entwickler haben das Problem bereits adressiert. Laut offiziellem GitHub-Repository wird mit Commit #45327 ein IPv4-Fallback-Mechanismus implementiert. Die Funktion fetchRemoteMedia erhält eine Retry-Logik: Schlägt der primäre Media-Download fehl, wird ein zweiter Versuch über eine alternative Netzwerkroute initiiert.

Gesteuert wird dies über die neue Option fallbackDispatcherPolicy, die es erlaubt, spezifisch für Telegram-Downloads einen alternativen Pfad zu definieren. Um zu verhindern, dass reguläre Fehler – wie ein legitimer HTTP 404-Status – unnötige Retrys auslösen, lässt sich das Verhalten über den Parameter shouldRetryFetchError präzise konfigurieren. Zusätzlich verbessert der Patch das Error-Reporting durch überarbeitete Fehlermeldungen und das Schwärzen sensibler Daten, was künftige Debugging-Prozesse erleichtert.

Sofortmaßnahme: Downgrade auf Version 3.24

Bis der Fix in einem offiziellen Release zur Verfügung steht, ist ein Rollback auf OpenClaw 3.24 der einzige verlässliche Weg, um die Funktionalität betroffener Telegram-Bots wiederherzustellen. Nutzerberichten zufolge löst das Downgrade das Problem sofort und vollständig.

Ein einfacher Neustart des Gateways unter der fehlerhaften Version 3.28 reicht hingegen nicht aus, da die Ursache direkt in der SSRF-Logik verankert ist. Nach der Installation der älteren Version muss das Gateway neu gestartet werden, damit die Änderungen aktiv werden.