Bunsink has an SSRF bypass in `validate_webhook_url`
Date: 2026-05
Affected: pip/bugsink
Attack vector: ssrf
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2026-44502
CWE: CWE-918
CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)

## Summary Bugsink’s webhook URL validation in versions 2.1.2 and earlier could be (partially) bypassed because of a mismatch in URL parsing. In some malformed URLs, Python’s standard URL parser (urllib) and the HTTP client stack (requests / urllib3) do not agree on which host is actually being targeted. That could allow a webhook URL to pass Bugsink’s outbound-host checks while the actual HTTP request is sent somewhere else. ## Impact This issue affects Bugsink’s outbound webhook integrations. An attacker who can supply or influence a webhook URL may be able to make Bugsink send an outbound HTTP POST request to a host that should have been blocked by the webhook validation logic, including loopback, private, or otherwise non-allowlisted destinations. The practical impact is limited: - this is an outbound webhook SSRF issue, not a general-purpose proxy - Bugsink does not follow redirects for these webhook requests - the request shape is constrained by how the malformed URL is normalized by the HTTP client - this does not give arbitrary control over every possible request path In other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive. ## Technical Details The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post. For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is th


Mitigations:

Architectural layers (MAESTRO):