The 'authenticated attacker' prerequisite in this CVE is essentially meaningless in practice. Usememos defaults to open registration — the barrier to exploitation is creating a free account in 30 seconds, not breaching a credential-hardened gate. Don't let the CVSS 8.5 rating or the 'authenticated' language fool you: the security boundary this creates is far weaker than the prerequisite suggests.
The real threat is pivoting to internal infrastructure. The webhook validation feature in internal/webhook/validate.go makes outbound HTTP requests to verify URLs. An attacker with a free account creates a webhook pointing at internal services — cloud metadata endpoints (169.254.169.254), internal admin panels, databases, or microservices on the same host. This isn't about stealing notes; it's about using usememos as a springboard to reach everything else that server can reach.
The patch will almost certainly be a blocklist in validate.go blocking 127.0.0.1 and a few private CIDRs. This is the standard fix for this vulnerability family, and it's historically inadequate. IPv6 loopback (::1), IPv4-mapped IPv6 addresses, and DNS rebinding have bypassed identical patches in adjacent tools. The next SSRF in usememos is already latent — probably in image preview fetching, URL unfurling, or markdown rendering, where the same developer instinct to 'verify this resource resolves' produces the same missing bounds.
Audit every outbound-fetch path in your usememos deployment, not just the webhook feature. If you're running usememos in a cloud environment with a service account attached, treat this as catastrophic until patched — the blast radius extends well beyond what the CVSS score captures.