CVE-2026-65057: Keep SSRF Vulnerability

CVE-2026-65057 Overview

CVE-2026-65057 is an unauthenticated server-side request forgery (SSRF) vulnerability in Keep at commit 91c75e0. The flaw resides in the POST /providers/healthcheck endpoint, which accepts an attacker-controlled host value without authentication or validation. An unauthenticated attacker can send a crafted JSON payload that forces the Keep backend to issue arbitrary outbound HTTP requests. This behavior enables access to internal services, cloud instance metadata endpoints, and other resources reachable from the server. The vulnerability is tracked under CWE-918: Server-Side Request Forgery.

Critical Impact
Unauthenticated attackers can pivot into internal networks and steal cloud credentials by coercing the Keep backend to query metadata services such as 169.254.169.254.

Affected Products

Keep (keephq/keep) at commit 91c75e0
Deployments exposing the /providers/healthcheck endpoint to untrusted networks
Cloud-hosted Keep instances with access to instance metadata services

Discovery Timeline

2026-07-21 - CVE-2026-65057 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-65057

Vulnerability Analysis

Keep exposes a healthcheck endpoint at POST /providers/healthcheck that accepts a JSON body containing a host parameter. The backend uses this attacker-supplied value to construct and issue an outbound HTTP request. The endpoint requires no authentication and performs no allowlist validation on the destination. As a result, an attacker can direct the server to contact arbitrary URLs, including internal RFC1918 addresses and cloud metadata services. The vulnerability is classified under CWE-918 and carries an EPSS probability of 0.246%.

Root Cause

The root cause is missing input validation and missing authentication on the healthcheck route. The application trusts the client-provided host value and passes it directly to its HTTP client. There is no scheme restriction, no host allowlist, and no filtering of loopback, link-local, or private-network destinations. Any caller reaching the endpoint can influence the outbound request target.

Attack Vector

An attacker sends an unauthenticated HTTP POST request to /providers/healthcheck with a JSON payload whose host field references an internal or metadata target. The Keep backend then issues an outbound HTTP request to that destination and processes the response. Attackers use this primitive to enumerate internal services, retrieve AWS, Azure, or GCP instance metadata credentials, and map internal network topology. Additional technical detail is available in the VulnCheck Security Advisory and the GitHub Issue Tracker.

Detection Methods for CVE-2026-65057

Indicators of Compromise

Unauthenticated POST requests to /providers/healthcheck from unexpected source IPs.
Outbound requests from Keep backend hosts to 169.254.169.254, metadata.google.internal, or 169.254.169.254/metadata/instance on Azure.
Outbound connections from Keep to internal RFC1918 ranges that are not part of normal provider integrations.
JSON payloads to the healthcheck endpoint containing host values pointing to loopback, link-local, or private addresses.

Detection Strategies

Inspect web server and reverse proxy logs for POST requests to /providers/healthcheck and correlate with authentication state.
Monitor egress traffic from Keep application servers for connections to cloud metadata IPs and internal-only services.
Deploy web application firewall (WAF) rules that flag or block JSON bodies referencing metadata endpoints or private network ranges.

Monitoring Recommendations

Alert on any process on the Keep host initiating connections to 169.254.169.254 outside documented workflows.
Track DNS resolutions for metadata hostnames originating from Keep containers or pods.
Baseline normal healthcheck traffic volume and alert on spikes or off-hours activity.

How to Mitigate CVE-2026-65057

Immediate Actions Required

Restrict network access to the /providers/healthcheck endpoint using reverse proxy or ingress rules until a patched build is deployed.
Enforce IMDSv2 on AWS instances and require session tokens for metadata access to blunt credential theft via SSRF.
Block egress from Keep application hosts to 169.254.169.254 and other metadata endpoints unless explicitly required.
Review Keep logs for prior unauthenticated requests to the healthcheck route and investigate any anomalous egress.

Patch Information

No fixed release is referenced in the NVD entry at the time of publication. Track the GitHub Project Repository and the GitHub Issue Tracker for patch availability, and upgrade to a build that introduces authentication and host validation on /providers/healthcheck.

Workarounds

Place Keep behind an authenticating reverse proxy that requires valid credentials for the /providers/healthcheck path.
Deploy a WAF rule that rejects requests to /providers/healthcheck whose host field resolves to private, loopback, or link-local addresses.
Apply egress network policies that limit the Keep backend to known external provider endpoints only.

bash

# Example NGINX snippet restricting healthcheck to internal management network
location /providers/healthcheck {
    allow 10.0.0.0/24;   # management subnet
    deny all;
    proxy_pass http://keep_backend;
}