Appsmith EUVD-2026-39118

Exploitation requires an authenticated low-privileged Appsmith account (CVSS PR:L) on a version prior to 2.1 deployed via the bundled Docker image where Caddy's admin API is bound to 0.0.0.0:2019, plus a usable SSRF primitive that coerces the Appsmith server process to issue requests to that internal endpoint (e.g., abusing data-source/outbound-request features). The key limiting factor is that port 2019 is NOT published to the host by docker-compose.yml, so the attacker cannot hit it directly from the network - they must pivot through the in-container SSRF/Appsmith-server path; no end-user interaction is required (UI:N).

The published CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) reflects a network-reachable, low-complexity attack needing only low privileges, with a scope change because compromising Caddy affects a component beyond the vulnerable backend. The realistic prerequisite is twofold: a valid low-privileged Appsmith account AND a usable SSRF primitive (Appsmith's data-source/API features can be configured by low-priv users to make outbound requests, which plausibly satisfies AC:L). EPSS data was not provided and the CVE is not listed in CISA KEV, so there is no evidence of active exploitation; likewise no POC was supplied, so this should be treated as 'no public exploit identified at time of analysis' rather than an imminent mass-exploitation threat. The signals are internally consistent - network vector matches the SSRF-driven reachability - but note the listener is NOT published to the host by docker-compose, so exploitation depends on the in-container SSRF path rather than direct internet exposure of port 2019; this caveat slightly tempers the otherwise critical score. Net: a genuine high-priority issue for any internet-facing self-hosted Appsmith instance, but contingent on the SSRF chain rather than a single unauthenticated request.

A low-privileged user logs into a self-hosted Appsmith instance and configures a data source or REST API action pointing at http://0.0.0.0:2019/load, then triggers the Appsmith server to send a crafted POST containing attacker-chosen Caddy JSON configuration. Caddy accepts the unauthenticated request and reloads, handing the attacker control of the reverse proxy so they can intercept or redirect all traffic and serve malicious content. No public exploit code was identified at time of analysis, but the chain uses only built-in Appsmith functionality.