Caddy Reverse Proxy
PassAudited by VirusTotal on May 11, 2026.
Overview
Type: OpenClaw Skill Name: caddy-reverse-proxy Version: 1.0.0 This skill is classified as suspicious due to several high-risk practices and potential vulnerabilities, although without clear evidence of intentional malicious behavior. Key indicators include the explicit instruction in `reference.md` to use a 'long-lived `vcp_*` token (no expiration)' for the Vercel API, which significantly increases the impact of a token compromise. Additionally, `reference.md` details running Caddy as a macOS LaunchDaemon that 'runs as root' for port 443, a high-privilege configuration, or granting `cap_net_bind_service` via `sudo setcap` on Linux. The skill also involves creating system-level persistence mechanisms (LaunchDaemons/systemd services) and, in `OPENCLAW.md`, instructs setting `allowInsecureAuth: true` for the OpenClaw gateway, a security downgrade.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A local dev app could become reachable directly on its raw port, bypassing Caddy, TLS, and any proxy-level controls.
For a same-host Caddy route using localhost, binding the app to all interfaces is broader than needed and may expose the app directly on LAN, Tailscale, or public interfaces outside Caddy's HTTPS/proxy boundary.
Designed for Tailscale-only access (no public exposure)... reverse_proxy to localhost:<port> ... **Bind to 0.0.0.0** so Caddy can proxy to it.
Bind apps to 127.0.0.1/localhost when Caddy runs on the same machine; use 0.0.0.0 only with a firewall or container/network design that explicitly requires it.
If the gateway is exposed more broadly than intended or a token leaks, access to the control UI may be easier than with device-key authentication.
The OpenClaw gateway integration intentionally weakens the normal device-auth boundary for proxied control UI clients. It is disclosed and purpose-aligned, but it affects a sensitive agent gateway interface.
`allowInsecureAuth: true` — The gateway normally requires device-key authentication... This setting allows token-only authentication.
Use this setting only when required, keep the gateway restricted to trusted Tailscale/private clients, tightly limit allowedOrigins and trustedProxies, and revert the setting if proxying no longer needs it.
If this token is exposed, someone could potentially alter DNS records or interfere with certificate issuance for the configured domain.
A Vercel DNS token is expected for DNS-01 certificate automation, but it is a long-lived credential with DNS-account impact and should be treated as sensitive.
**Vercel API Token:** Create a long-lived `vcp_*` token... no expiration — must be revoked if exposed.
Use the least-privileged token available, store it in a file with restrictive permissions, avoid pasting it into shell history, and revoke/rotate it if exposed.
A future plugin change or compromised dependency could affect the Caddy binary users build and run.
The guide asks users to build a custom Caddy binary from an external GitHub plugin without pinning a commit or version. This is normal for custom Caddy builds but has provenance and repeatability risk.
xcaddy build --with github.com/caddy-dns/vercel
Pin plugin versions or commits, review the plugin source, and build from trusted repositories.
Caddy and app services may continue running in the background until explicitly disabled.
The documentation creates long-running services that start automatically and may survive logout. This persistence is expected for a reverse proxy, but users should understand it.
RunAtLoad ... KeepAlive ... Restart=always ... systemctl --user enable --now caddy ... loginctl enable-linger $(whoami)
Only enable persistent services you want running continuously, and document how to stop, disable, or remove them.