CVE-2026-3958: The Webhook That Would Dial Anywhere

A "test your Discord notification" button on ListSync's dashboard API takes a webhook URL straight from the request body and hands it to requests.post — no host check, no auth gate. The server will happily knock on whatever door you name, which is the textbook shape of a server-side request forgery.

The advisory in plain English

NVD lists CVE-2026-3958 (CVSS 6.3, MEDIUM) against Woahai321 ListSync up to and including 0.6.6. ListSync is a self-hosted tool that mirrors media watchlists (IMDb, Trakt, and friends) into Overseerr/Jellyseerr. It ships a FastAPI backend, api_server.py, that powers a web dashboard. The advisory pins the defect to "the function requests.post of the file api_server.py of the component JSON Handler," and classifies it as server-side request forgery, remotely reachable. The disclosure also notes the maintainers were told via an issue and had not responded — so as of the version in front of me there is no fix commit to diff against. I confirmed that: walking the git history with git log --all --grep for ssrf, webhook, security, and friends returns nothing, and the file's last touch is the v0.6.6 release commit. This is an unpatched, as-shipped flaw, so the analysis below is of live code at HEAD b635a83, not a before/after.

SSRF is the vulnerability where you pick the destination and the server makes the request. That matters because the server usually sits somewhere your browser cannot: inside a Docker network, behind a firewall, next to a cloud metadata endpoint at 169.254.169.254. Anything the server can reach, the SSRF can reach on your behalf — using the server's network position and, often, its credentials.

The flawed function

The whole story lives in one endpoint. From api_server.py @ b635a83, L6857:

@app.post("/api/notifications/test")
async def test_discord_notification(payload: dict = None):
    """Send a test Discord notification to verify webhook configuration"""
    try:
        # Get Discord webhook URL from request body or environment
        webhook_url = None
        if payload and 'webhook_url' in payload:
            webhook_url = payload['webhook_url']

The handler accepts an untyped dict and reaches into it for a webhook_url key (api_server.py @ b635a83, L6864). There is no Pydantic model with a constrained type, no allow-list, no regex asserting the thing even looks like https://discord.com/api/webhooks/.... Whatever string arrives is the destination. A few lines later, in the fallback path that runs when the optional discord-webhook library isn't installed (api_server.py @ b635a83, L6948):

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

That's the sink the advisory names. The primary path is no safer: when the library is present, the same unvalidated webhook_url is fed to DiscordWebhook(url=webhook_url, ...) at api_server.py @ b635a83, L6881, which performs the request internally. Either way, the attacker-named URL gets dialed.

Why the check was insufficient

There are exactly two conditionals between input and request, and neither is a security check:

        if not webhook_url:
            webhook_url = os.getenv('DISCORD_WEBHOOK_URL', '')
        if not webhook_url:
            raise HTTPException(status_code=400, detail="Discord webhook URL is required...")

That api_server.py @ b635a83, L6866-L6873 logic only asks "is the string empty?" If you supply any non-empty value, you sail past both. "Non-empty" is not "is a Discord webhook." http://169.254.169.254/latest/meta-data/, http://localhost:8191/, http://overseerr:5055/api/v1/settings, http://10.0.0.5:6379/ — all non-empty, all accepted, all dispatched from inside the server's network.

I wanted to be sure the parameter actually reaches the sink rather than getting reassigned or guarded somewhere in the 80 lines between, so I built a code-property-graph dataflow model of the file and asked it to connect the dots. It found 35 distinct paths carrying webhook_url — first assigned from payload['webhook_url'] at L6864 — into the requests.post argument at L6948, with no sanitizing node in between. The source is attacker-controlled request JSON; the sink is an outbound HTTP request; the path is clean. That is SSRF, confirmed by reachability rather than by vibes.

Two design choices turn a "meh" into a "remotely exploitable." First, there is no authentication on the endpoint. The FastAPI app (api_server.py @ b635a83, L62) declares no Depends() security dependency, no API key, no bearer token — /api/notifications/test is open to anyone who can reach the port. Second, the CORS configuration is a red herring that lulls you into thinking there's a boundary. The middleware at api_server.py @ b635a83, L115 even enumerates nearly the whole 192.168.1.0/24 range (.1–.254) as allowed origins:

    for i in range(1, 255):
        default_origins.extend([
            f"http://192.168.1.{i}:3222",
            f"http://192.168.1.{i}:4222"
        ])

CORS is a browser policy. It governs whether a victim's browser will let JavaScript read a cross-origin response — it does nothing to stop a direct, scripted POST from any HTTP client, and it places zero restriction on where the server may send its own outbound request. Treating allow_origins as an access-control list is a category error, and here it guards the wrong door entirely.

What a fix should change

Since there's no upstream patch, here's the shape of the correct fix rather than a diff. The destination must be validated as data, not trusted as a command:

• Parse and constrain the URL. Require https, then assert the host is exactly discord.com / discordapp.com (or whatever the legitimate webhook domains are). A literal prefix check against the known Discord webhook base is appropriate here — this endpoint has exactly one legitimate target shape.
• Resolve once and pin the IP. Validating the hostname and then calling requests.post does not close DNS rebinding: requests re-resolves the name when it connects, so an attacker can serve a public IP at validation time and an internal one a moment later at request time. The only robust fix is to resolve the host a single time, reject the result if it lands in an RFC 1918 range, loopback, link-local (169.254.0.0/16), or an IPv6 equivalent, and then force the outbound request to connect to that pinned, validated IP (via a custom connection adapter or socket-level pinning). A separate validate-then-request always re-resolves and stays rebinding-vulnerable.
• Type the input. Replace payload: dict with a Pydantic model carrying a validated HttpUrl plus a custom validator. Untyped dict handlers are how unvalidated input sneaks in.
• Authenticate the endpoint. A test-notification action that makes outbound requests should sit behind the same auth as the rest of the dashboard, not hang open on the network.

The lesson

SSRF is rarely an exotic bug; it's almost always a URL that came from outside, used as if it came from inside. The tell here is structural and worth memorizing: an (payload: dict) handler, an if not x "validation" that only tests for emptiness, and a network call whose destination is the very thing the caller supplied. The emptiness check feels like diligence — it returns a tidy 400 — but it answers the wrong question. "Is this present?" is not "is this allowed?"

The CORS sprawl is the second lesson. Enumerating 254 LAN addresses as allowed origins looks like security effort, but it's effort spent on a control that does not constrain server-side requests at all. Defenses have to live at the layer where the danger lives. The danger here is an outbound requests.post; the defense has to be a check on that URL, right before that call — not a browser policy bolted to the front door while the back door dials out unsupervised.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-3958
• Repository: https://github.com/Woahai321/list-sync
• Endpoint & sink (HEAD b635a83, v0.6.6): https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L6857-L6873
• The requests.post sink: https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L6948
• CORS configuration: https://github.com/Woahai321/list-sync/blob/b635a833e1bb59ea51a2817bbc6d54b40ab97666/api_server.py#L115-L122
• Reporter's issue: https://github.com/Woahai321/list-sync/issues/79
• VulDB entry: https://vuldb.com/?id.350388