CVE-2026-3958: The Webhook Tester That Would Call Anywhere

A "send a test notification" button in ListSync's API trusts whatever URL you hand it and dutifully fires an HTTP request at it — turning a Discord convenience feature into a server-side request forgery primitive that reaches wherever the server can.

The advisory in plain English

CVE-2026-3958 (CVSS 6.3, MEDIUM) lands on Woahai321 ListSync ≤ 0.6.6, the self-hosted tool that syncs your media watchlists into Overseerr/Jellyseerr. The NVD writeup fingers requests.post inside api_server.py, in what it calls the "JSON Handler" component, and labels the bug server-side request forgery (SSRF), remotely reachable. It was reported to the project via GitHub issue #79 and — per the advisory — has not yet been answered. I cloned the repo at HEAD (b635a83, version 0.6.6) and there is no fix commit anywhere in the history: git log --all --grep for ssrf|webhook|validate|security returns nothing. So this is a deep-dive on a live defect, not a patch retrospective.

The component name is a slightly grand label for a very ordinary FastAPI route: an endpoint that accepts a JSON body and reads a URL straight out of it.

The flawed function

The whole bug fits in one handler. From api_server.py @ b635a83, L6857-6858:

@app.post("/api/notifications/test")
async def test_discord_notification(payload: dict = None):

Note the signature: payload: dict with no Pydantic model, no schema, no field validation. FastAPI's normal superpower is typed request models that constrain input; here that safety net is deliberately removed in favor of a free-form dict. That is the "JSON Handler."

The URL is then lifted verbatim from the body. api_server.py @ b635a83, L6862-6867:

        webhook_url = None
        if payload and 'webhook_url' in payload:
            webhook_url = payload['webhook_url']

        if not webhook_url:
            webhook_url = os.getenv('DISCORD_WEBHOOK_URL', '')

webhook_url is now an attacker-supplied string. There is no scheme check, no host allowlist, no "does this even look like discord.com" guard. The only fallback is an environment default if the field is absent — supply the field and you own the destination.

It is used twice. The preferred path constructs a DiscordWebhook with it (L6881), and the ImportError fallback does the thing the CVE names directly — api_server.py @ b635a83, L6948-6949:

            response = requests.post(webhook_url, json=payload, timeout=10)
            response.raise_for_status()

The server makes an outbound POST to a URL chosen by the caller. That is SSRF in its textbook form: the request originates from the server's network position, not the attacker's.

Why the check was insufficient

Because there is no check. That's the honest answer, and it's worth sitting with — SSRF bugs usually involve a bypassed validator (a regex that anchors wrong, a urlparse that disagrees with the HTTP client, a DNS-rebinding window). Here there's nothing to bypass. The string travels from JSON field to HTTP client untouched.

I wanted to confirm that "untouched" claim with dataflow rather than eyeballing, so I built a Joern CPG of the file (pysrc2cpg) and ran a reachableByFlows query from the route parameter to the requests.post call:

val src  = cpg.method.name("test_discord_notification").parameter.name("payload")
val sink = cpg.call.code(".*requests\.post.*")
sink.reachableByFlows(src)  // => FLOW COUNT: 2

The traced flow is short and damning — every node, no sanitizer between source and sink:

6858: payload                 (route parameter)
6864: payload['webhook_url']
6864: webhook_url
6948: requests.post(webhook_url, json = payload, timeout = 10)

Two flows reach the sink — payload arrives at the L6948 requests.post call via both the webhook_url argument and the json=payload argument — and Joern places no intermediate transformation node between payload['webhook_url'] and the call. That is hard evidence that the value is forwarded raw. (The DiscordWebhook constructor at L6881 sits on the preferred branch, a separate execution path, and so does not appear on this trace to the ImportError-fallback sink.)

What about access control? The route is decorated @app.post(...) with no Depends(...) auth dependency. The only middleware on the app is CORS, from api_server.py @ b635a83, L115-117, driven by get_allowed_origins() (L88). CORS is a browser-enforced policy — it governs what JavaScript in a victim's tab may read, not what a direct HTTP client may send. An attacker hitting the API socket directly is entirely unaffected by it. So if the ListSync API port is reachable by the attacker (a misconfigured reverse proxy, a shared network, a container exposed wider than intended), the endpoint answers, and SSRF is the consequence. That's why the advisory rates it remotely exploitable, and why I tag this exploitable rather than theoretical.

The practical impact of SSRF depends on what the server can see that you can't: internal admin panels, cloud instance-metadata endpoints, other containers on the bridge network, localhost-bound services. The defect hands the attacker the server as an HTTP proxy into all of it. Note too that the response path (raise_for_status, error messages echoed back in the HTTPException detail at L6961-6963) can leak status codes and error fragments back to the caller — a small but real blind-SSRF oracle. I'm describing the shape of the risk, not handing over a target list.

Corroboration, and where the generic scanner earns (and misses) its keep

Semgrep, run targeted at the file with p/python + p/security-audit, fires its ssrf-requests rule on line 6948 — the exact sink:

6948  ssrf-requests
1943  ssrf-requests
2010  ssrf-requests
2350  ssrf-requests
8173  ssrf-requests

So here the generic tooling does catch it — credit where due. But look at the four other hits. Lines 1943/2010/2350 are the Overseerr-connection probes that build a URL from data.get('overseerr_url') and requests.get it; 8173 is another fetch. Semgrep flags all calls where a non-constant string reaches a requests sink — it cannot tell you which of these is the one a remote, unauthenticated caller can actually drive end-to-end. It's pattern-matching requests.<verb>(<tainted-ish>), not reasoning about reachability or auth. The Overseerr probes arguably want the same hardening, but the CVE singles out the webhook tester because the payload→sink path is the cleanest and the route is the least guarded. Distinguishing "scanner noticed a tainted-looking call" from "this is the exploitable one" is exactly the judgment a reachableByFlows trace plus a read of the decorator gives you and a raw Semgrep line number does not. Treat the scanner hit as a lead; the CPG flow and the missing Depends are the verdict.

The lesson

Three takeaways, in increasing order of how often people forget them:

1. An outbound request to a user-controlled URL is a security decision, not a feature detail. "Test my webhook" feels benign because the intended destination is Discord. But the code doesn't encode that intent. If the destination is meant to be Discord, say so in code: validate scheme is https, resolve and reject private/link-local/loopback ranges — and then connect to that validated IP rather than re-resolving the hostname at request time, or you've just reopened the DNS-rebinding window — disable redirect-following (allow_redirects=False, or re-validate the post-redirect host), since requests.post follows 3xx by default and an allowlisted host can simply 302 you to an internal target, and ideally allowlist the discord.com / discordapp.com host set. A webhook tester has no business POSTing to 169.254.169.254 or 127.0.0.1.

2. dict is not a schema. The route throwing away FastAPI's typed-model validation in favor of payload: dict is what made the field free-form in the first place. A Pydantic model with an HttpUrl (or a custom validator) would have been the natural place to bolt the host check.

3. CORS is not authorization. A sensitive action endpoint guarded only by CORS is guarded by nothing against a direct client. Mutating/outbound-effect routes need real auth dependencies.

The depressing part is how cheap the fix is relative to the exposure: a few lines of host validation in front of one requests.post. Until the maintainers act on issue #79, operators should keep the ListSync API off any untrusted network and behind authentication — the application won't say no for them.

References

• NVD: CVE-2026-3958
• Issue report: https://github.com/Woahai321/list-sync/issues/79
• Sink — requests.post(webhook_url, ...): https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L6948
• Source — JSON webhook_url intake: https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L6862-L6867
• Route definition (no auth dependency): https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L6857-L6858
• CORS-only middleware: https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L88-L117
• VulDB: https://vuldb.com/?id.350388