CVE-2026-75583 Overview
CVE-2026-75583 is a Server-Side Request Forgery (SSRF) guard bypass in the keeper.sh calendar module affecting versions prior to 2.18.14. The vulnerability exploits a DNS rebinding condition between the URL validation step and the outbound HTTP connection. An authenticated attacker who controls an authoritative DNS server can return a public IP during validation and a private IP during the subsequent socket-level resolution. This causes outbound requests to reach internal infrastructure such as cloud instance metadata endpoints. The issue is tracked under [CWE-918] Server-Side Request Forgery.
Critical Impact
Authenticated attackers can pivot outbound calendar (CalDAV) requests to internal network resources, including cloud metadata services, bypassing the two-phase SSRF guard.
Affected Products
- keeper.sh calendar module versions prior to 2.18.14
- @keeper.sh/calendar package CalDAV client (packages/calendar/src/providers/caldav/shared/client.ts)
- @keeper.sh/sync provider resolver (packages/sync/src/resolve-provider.ts)
Discovery Timeline
- 2026-08-19 - CVE-2026-75583 published to NVD
- 2026-08-19 - Last updated in NVD database
Technical Details for CVE-2026-75583
Vulnerability Analysis
The calendar module implements an SSRF guard that resolves a user-supplied hostname, inspects the returned IP addresses, and rejects private ranges. After validation succeeds, the guard discards the resolved addresses and hands the original hostname to the HTTP client. The HTTP client then performs its own independent DNS lookup before opening the socket. This two-phase design creates a Time-of-Check Time-of-Use (TOCTOU) window that DNS rebinding directly targets.
An attacker registers a domain whose authoritative name server returns short-TTL answers. The first query, issued by the guard, returns a public IP address that passes all allow-list checks. The second query, issued moments later by the fetch layer, returns 169.254.169.254, 127.0.0.1, or an RFC1918 address. The outbound CalDAV request reaches internal infrastructure while the guard reports success.
Root Cause
The root cause is that the SSRF guard validates hostnames rather than binding validated IP addresses to the connection. Because the two DNS resolutions are independent, the trust decision made during validation does not carry into the socket layer.
Attack Vector
Exploitation requires authentication and the ability to submit a calendar URL to the CalDAV provider. The attacker points that URL at a domain they control. The domain serves rebinding responses, causing the calendar sync worker to connect to internal endpoints such as cloud provider metadata services (http://169.254.169.254/).
// Source: https://github.com/ridafkih/keeper.sh/commit/aea1cf537b850509e802b388f38cf1482cb6291b
// Patch in packages/calendar/src/providers/caldav/shared/client.ts
// The fix rebinds outbound requests to the validated account origin,
// so a rebinding attack cannot redirect the connection to a new host.
const bindUrlToAccount = (url: string, serverUrl: string): string => {
const target = new URL(url, serverUrl);
const bound = new URL(serverUrl);
if (target.origin === bound.origin) {
return target.href;
}
bound.pathname = target.pathname;
bound.search = target.search;
return bound.href;
};
const bindRequestToAccount = (
input: string | Request | URL,
serverUrl: string
): string | Request => {
if (input instanceof Request) {
const bound = bindUrlToAccount(input.url, serverUrl);
if (bound === input.url) {
return input;
}
return new Request(bound, input);
}
return bindUrlToAccount(input.toString(), serverUrl);
};
The patch forces every outbound request to reuse the origin that was validated by the guard, closing the gap between check and use. Additional context is available in the GitHub Security Advisory and the VulnCheck Security Advisory.
Detection Methods for CVE-2026-75583
Indicators of Compromise
- Outbound connections from calendar sync workers to link-local ranges such as 169.254.169.254/32, loopback, or RFC1918 addresses.
- CalDAV account records referencing external domains whose DNS answers use unusually low TTLs (often 0 or 1 second).
- Repeated resolver queries for the same hostname within a single sync operation returning different address families.
Detection Strategies
- Correlate application-layer CalDAV request logs with resolver logs to identify hostnames that resolve to both public and private addresses in the same session.
- Alert on any HTTP request from the @keeper.sh/calendar process that targets cloud metadata endpoints or internal CIDRs.
- Instrument the fetch layer to log both the validated IP and the connected peer IP, and flag any mismatch.
Monitoring Recommendations
- Forward calendar service and DNS resolver logs to a centralized data lake for correlation and retention.
- Track egress from the workload's service account to non-approved destinations, particularly link-local metadata IPs.
- Baseline expected CalDAV endpoints per tenant and alert on new external hostnames registered by authenticated users.
How to Mitigate CVE-2026-75583
Immediate Actions Required
- Upgrade the keeper.sh calendar module to version 2.18.14 or later.
- Audit existing CalDAV account URLs for suspicious or attacker-controlled domains and revoke them.
- Block egress from calendar workers to cloud metadata addresses (169.254.169.254, fd00:ec2::254) and internal CIDRs at the network layer.
Patch Information
The fix is delivered in commit aea1cf5, titled fix(calendar): rebind DNS resolution when guard is active (#857). It introduces bindUrlToAccount and bindRequestToAccount helpers that pin every outbound request to the origin validated by the SSRF guard. See the Keeper.sh repository for release details.
Workarounds
- Enforce IMDSv2 on AWS workloads and require hop-limit 1 to blunt metadata exposure if the guard is bypassed.
- Deploy an egress proxy that resolves hostnames once and rejects connections whose resolved IP falls in private, loopback, or link-local ranges.
- Restrict authenticated user creation of CalDAV accounts to an allow-list of trusted providers until the patched version is deployed.
# Configuration example: block calendar workers from reaching cloud metadata and internal ranges
# Apply on the host running @keeper.sh/calendar (adjust user/uid as needed)
sudo iptables -A OUTPUT -m owner --uid-owner keeper \
-d 169.254.169.254/32 -j REJECT
sudo iptables -A OUTPUT -m owner --uid-owner keeper \
-d 10.0.0.0/8 -j REJECT
sudo iptables -A OUTPUT -m owner --uid-owner keeper \
-d 172.16.0.0/12 -j REJECT
sudo iptables -A OUTPUT -m owner --uid-owner keeper \
-d 192.168.0.0/16 -j REJECT
sudo iptables -A OUTPUT -m owner --uid-owner keeper \
-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.

