CVE-2026-71272 Overview
CVE-2026-71272 is a Server-Side Request Forgery (SSRF) protection bypass in Memos, an open-source note-taking application. The vulnerability resides in the safeDialContext() function within internal/webhook/webhook.go. The function validates resolved IP addresses against reserved ranges but subsequently dials the target using the original hostname. This time-of-check/time-of-use (TOCTOU) flaw [CWE-367] enables DNS rebinding attacks against the webhook dispatcher.
Critical Impact
An authenticated attacker controlling DNS for a webhook hostname can bypass SSRF protections and force the Memos server to send requests to internal network addresses, exposing internal services.
Affected Products
- Memos (usememos/memos) — webhook dispatch component
- internal/webhook/webhook.go — safeDialContext() function
- Deployments exposing outbound webhook functionality to authenticated users
Discovery Timeline
- 2026-08-05 - CVE-2026-71272 published to the National Vulnerability Database (NVD)
- 2026-08-05 - Last updated in NVD database
Technical Details for CVE-2026-71272
Vulnerability Analysis
Memos supports outbound webhooks that notify third-party endpoints of events. To prevent SSRF against internal infrastructure, the safeDialContext() function resolves the webhook hostname using net.DefaultResolver.LookupHost() and rejects addresses in reserved ranges. The check is defensive in intent but incomplete in execution.
After validation, the function calls net.JoinHostPort(host, port) and passes the original hostname to net.Dialer.DialContext(). The dialer performs its own independent DNS resolution before establishing the TCP connection. Validation and connection therefore consult DNS twice, and the two lookups can return different results.
An attacker controlling authoritative DNS for the webhook domain can serve a public IP (such as 1.1.1.1) during the validation lookup and an internal IP (such as 169.254.169.254 or 127.0.0.1) during the dial lookup. Setting a short Time-to-Live (TTL) or using round-robin responses reliably triggers the race.
Root Cause
The root cause is a classic TOCTOU flaw [CWE-367]. The security decision uses one DNS result while the sensitive operation uses a separate, later DNS result. The correct pattern is to resolve the hostname once, validate the returned addresses, and then dial the validated IP directly while preserving the original hostname only for TLS Server Name Indication (SNI) or HTTP Host headers.
Attack Vector
Exploitation requires an authenticated user with permission to configure webhooks. The attacker registers a domain, configures a DNS record with a short TTL, and points the webhook to that domain. When Memos validates the destination, the DNS server returns an allowlisted public IP. When DialContext() re-resolves the name milliseconds later, the DNS server returns an internal address such as a cloud metadata endpoint (169.254.169.254) or an internal service. Memos then issues the webhook request against the internal target, potentially exfiltrating cloud credentials or reaching services bound to loopback.
No public proof-of-concept is referenced in the advisory. The vulnerability mechanism is documented in the Memos Webhook Implementation.
Detection Methods for CVE-2026-71272
Indicators of Compromise
- Outbound HTTP requests from the Memos process to RFC1918 addresses, link-local ranges (169.254.0.0/16), or loopback
- DNS queries from the Memos host resolving external domains to internal IPs
- Webhook configurations pointing to attacker-controlled domains with unusually short TTL values
- Repeated DNS lookups for the same webhook hostname returning different address families within a short window
Detection Strategies
- Monitor egress traffic from the Memos server and alert on connections to internal ranges originating from the webhook dispatcher
- Correlate DNS query logs with process telemetry to identify hostnames returning inconsistent answers across successive lookups
- Audit webhook creation events for domains with TTL values below 60 seconds
Monitoring Recommendations
- Enable DNS query logging on the host running Memos and forward to a centralized log platform
- Instrument network policies to log denied egress attempts to metadata endpoints such as 169.254.169.254
- Review Memos audit logs for webhook additions by non-administrative accounts
How to Mitigate CVE-2026-71272
Immediate Actions Required
- Restrict webhook creation to trusted administrators until a patched release is deployed
- Block outbound traffic from the Memos host to RFC1918, link-local, and cloud metadata addresses at the network layer
- Enumerate existing webhook configurations and remove any pointing to unfamiliar external domains
Patch Information
Monitor the Memos project repository for a fixed release. The corrective pattern is to resolve the hostname once, validate the returned IPs, and pass the validated IP directly to net.Dialer.DialContext() using a custom Control function or a pre-resolved net.TCPAddr.
Workarounds
- Deploy Memos behind an egress proxy that enforces destination allowlists independent of DNS resolution
- Run Memos in a network segment with no route to internal services or cloud metadata endpoints
- Disable the webhook feature entirely if it is not required by the deployment
# Example iptables rules blocking Memos egress to internal ranges
iptables -A OUTPUT -m owner --uid-owner memos -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner memos -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner memos -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner memos -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner memos -d 127.0.0.0/8 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
