CVE-2026-55454: Appsmith's Caddy Admin API Gets a 9.9 from SSRF

CVE-2026-55454 landed in the NVD on June 24 with a CVSS 9.9 — the highest possible score. The target isn’t some enterprise monolith with a sprawling attack surface. It’s Appsmith, a popular open-source platform for building internal admin panels and dashboards. The vector is clean: an authenticated low-privileged user drives an SSRF to the bundled Caddy reverse-proxy’s admin API, which has no authentication by default, and replaces the live reverse proxy configuration. One request, full admin takeover.

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Low privileges required. Low complexity. No user interaction. Changed scope with total impact across confidentiality, integrity, and availability. This is what a 9.9 looks like when it’s not Log4Shell.

The Attack Chain

Here’s the sequence, stripped to essentials:

1. Caddy runs inside the Appsmith container. It serves as the reverse proxy for the Appsmith web UI and any custom domains you’ve configured. Its admin API listens on port 2019, bound to 0.0.0.0 inside the container.

2. No authentication by default. The admin API doesn’t require a token or header unless you configure admin in Caddy’s config. Appsmith’s default docker-compose doesn’t set this, so the admin API is wide open.

3. SSRF from an Appsmith page. A low-privileged user who can load data from arbitrary URLs (via Appsmith’s datasource feature or a custom query) sends a request to http://0.0.0.0:2019/load — the admin API endpoint that accepts a full Caddy configuration and applies it live.

4. The config replacement. The POST /load endpoint replaces the entire running Caddy configuration. The attacker adds a new route, points it at an arbitrary upstream, and sets any headers they want. Now when any user visits the Appsmith domain, they hit the attacker’s upstream. Session cookies, API keys, credentials — whatever was in the original config, it’s gone.

User (low-priv) → Appsmith SSRF → http://0.0.0.0:2019/load (Caddy admin API)
                    ↓
            New Caddy config applied
                    ↓
            All traffic → attacker's upstream

The GitHub advisory notes this isn’t limited to POST /load. Any admin API endpoint (GET /config, POST /stop, POST /restart, etc.) is reachable, so you can also read the current config, stop the proxy entirely, or restart it with custom flags.

Why 9.9 and not something lower?

Two factors push this to the top of the scale:

Changed scope (S:C). The SSRF crosses the container boundary from the Appsmith application into the Caddy reverse proxy. Caddy is a separate process with different capabilities (it controls network routes, TLS certificates, and upstream connections). When the attacker replaces the Caddy config, they affect everything behind the proxy, not just the Appsmith app itself. That scope change is worth points.

Total impact (C:H, I:H, A:H). With the admin API, the attacker can:

• Redirect traffic to any upstream → full confidentiality of requests
• Inject headers, change response bodies → full integrity
• Stop the proxy entirely → full availability
• Add routes to internal services (Docker DNS) → lateral movement

CISA’s SSVC evaluation marks exploitation as POC and automatable: no, meaning the exploit exists and works but requires some per-target tuning (the exact SSRF payload depends on how Appsmith is configured). The technical impact is total.

What This Means for Your Own Containers

This isn’t just about Appsmith. The pattern — an unauthenticated admin API inside a container, reachable from an application process via SSRF — shows up in dozens of projects:

The common thread: the admin API is accessible inside the container from the application process, and the application has an SSRF to an arbitrary URL. When these two properties coexist, the admin API is on the table.

How to check your own setup

1. Is the admin API exposed to the container’s loopback? If a process inside the same container can reach http://localhost:PORT/admin, it’s reachable from SSRF.
2. Does the admin API require authentication? Check the vendor docs. Many assume you’ll put a network boundary in front of the admin port.
3. Can the app process make outbound requests? If the app fetches URLs from user input (URL shorteners, link previews, webhooks, integrations), it’s an SSRF source.

# Quick check: is port 2019 open inside the container?
docker exec <container> ss -tlnp | grep 2019

# Check what the admin API is accepting
docker exec <container> curl -s http://localhost:2019/config | head -20

The Fix

Appsmith fixed this in version 2.1. The fix enables the Caddy admin interface and binds it to a Unix socket instead of TCP port 2019, so the app process can reach it but external containers and the host network cannot. The admin API also requires the CADDY_ADMIN_TOKEN environment variable.

For organizations running Appsmith < 2.1, two quick mitigations:

1. Add a token to the admin API. Set CADDY_ADMIN_TOKEN in the docker-compose and add admin <token> to the Caddy config. The admin API now requires the Authorization: Bearer <token> header.

2. Restrict the admin listener. Change the admin binding from 0.0.0.0:2019 to a Unix socket or 127.0.0.1:2019 and ensure no other container shares the network namespace.

The Pattern, Not the CVE

CVE-2026-55454 is notable not because the vulnerability is novel — SSRF-to-admin-API chains are a staple of internal tool testing — but because it’s a reminder that container-internal network boundaries are real. The fact that the Caddy admin API is on port 2019 means nothing if the Appsmith process is in the same container and can reach localhost:2019.

When you’re testing internal tools (admin panels, dashboards, BI tools), always ask: “What admin APIs run inside this container, and can the application reach them?” The answer is usually yes, and the impact is usually total.

Further Reading

• GitHub Advisory: GHSA-8jvv-gwqg-6vjc
• NVD: CVE-2026-55454
• Caddy Admin API Documentation
• SSRF Cheat Sheet (PortSwigger)
• OWASP Top 10 — Broken Access Control