CVE-2024-11602

What it actually does

The Feast 0.40.0 server CORS policy does not restrict Access-Control-Allow-Origin to a trusted allowlist. Any external web origin can therefore issue cross-origin requests to the API and read responses that the browser would normally keep same-origin. Combined with credentialed requests, this can disclose feature-store data, metadata, and other sensitive API payloads. Impact is confidentiality-only (CVSS C:H / I:N / A:N) with a changed scope because a third-party origin receives data that should stay inside the Feast trust boundary. User interaction is required because the victim’s browser must visit the attacker-controlled page.

Why it matters to the business

If users who can reach the Feast API also browse untrusted sites, proprietary ML features, training metadata, or other sensitive records can leak to an outsider without any stolen password. There is no reported ransomware use, the CVE is not in CISA KEV, exploit maturity is none, and EPSS remains very low (~0.003 and essentially flat over 30 days), so mass opportunistic exploitation is unlikely. Residual risk is still material wherever Feast holds regulated or competitive data and the API is reachable from browsers, especially internet-facing or loosely firewalled deployments. The issue has been public for well over a year, so unpatched 0.40.0 instances represent avoidable exposure rather than a breaking news event.

How an attack unfolds

An attacker hosts a normal web page on a domain they control. A user who is already authenticated to the Feast API (for example via session cookie) visits that page. The page’s script causes the browser to send a cross-origin request to the Feast/agentscope API. Because CORS is not limited to trusted origins, the server reflects a permissive Access-Control-Allow-Origin (and may allow credentials), so the browser delivers the API response to the attacker’s script. The attacker obtains whatever the victim’s session could read. No remote code execution, integrity change, or service outage is involved; success depends on the victim visiting the malicious page while holding a valid session and on the API returning sensitive data to that session.

How to fix it

Upgrade Feast off 0.40.0 to a release that tightens CORS, or immediately override the server CORS configuration: allowlist only explicit trusted web origins, never use Access-Control-Allow-Origin: * (especially with Access-Control-Allow-Credentials: true), do not reflect arbitrary Origin values, and restrict allowed methods and headers to what the UI actually needs. Prefer serving the API only to first-party frontends, terminate sessions with SameSite cookies, and place the API behind network controls so browsers on the public internet cannot reach it. Confirm the exact patched package version from the feast-dev/feast changelog or advisory, because no fixed version was supplied with this record. Until upgraded, deny untrusted Origin headers at the reverse proxy.

How to confirm the fix worked

From a browser or HTTP client, send preflight (OPTIONS) and actual requests with Origin set to an untrusted test domain and to a trusted domain. A fixed or mitigated instance must not return Access-Control-Allow-Origin for the untrusted origin, must not echo arbitrary Origin values, and must not pair Allow-Credentials: true with a wildcard. Repeat for authenticated endpoints. Review reverse-proxy and Feast config for an explicit origin allowlist. Inventory remaining 0.40.0 deployments and confirm they were upgraded or taken off the network. Do not use live production credentials or real feature data during these checks.

Typical attack path

1. Identify a Feast 0.40.0 (or equivalently misconfigured) API that is reachable from browsers and inspect CORS response headers for a wildcard or reflected Origin.
2. Host a web page on an untrusted origin that, when loaded by a logged-in user, issues cross-origin requests to Feast API endpoints the victim can access.
3. Lure or wait for a user with an active Feast session to open that page (phishing, watering-hole, or any site they already visit).
4. The victim’s browser sends the request, including ambient credentials if the CORS policy allows them.
5. The overly permissive CORS policy lets the browser expose the API response to the attacker’s origin, leaking feature-store or configuration data.
6. The attacker stores or exfiltrates the returned JSON/payloads; no further server-side foothold is required.

How to detect it

Exploitation is browser-driven and leaves little unique malware residue; look for evidence that untrusted web origins successfully called the API. Review Feast/agentscope HTTP access logs, reverse-proxy logs, and WAF logs for requests that include an Origin or Referer header from domains that are not your first-party UI, especially when the response was 200 and included Access-Control-Allow-Origin echoing that foreign origin or '*'. Correlate those requests with authenticated sessions and unusually large JSON responses. Hunt historical logs since publication for the same pattern. Client-side, browser history or proxy logs showing users hitting unknown sites immediately before Feast API calls from that context can support an investigation. There are no named threat actors or KEV campaigns tied to this CVE, so do not expect distinctive C2 or ransomware artifacts.

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Credentials: true
• HTTP request header Origin: not matching the first-party Feast UI host
• OPTIONS preflight to Feast/agentscope API paths followed by GET/POST from a foreign Origin
• Access log pairs of Origin: <external-domain> with 200 responses on feature-store or agentscope API routes
• Referer: https:// (unknown external host) on Feast API requests

What your security team should do

• Inventory all Feast 0.40.0 (and similarly configured) API/UI endpoints that browsers can reach and treat them as exposed until CORS is locked down or the component is upgraded.
• Apply an origin allowlist at the application or reverse proxy immediately; do not wait solely on an upstream package bump if configuration can be tightened now.
• Upgrade to a Feast release that corrects CORS once the maintainer-published fixed version is identified; pin and verify the version in CI.
• Ensure session cookies use SameSite=Lax or Strict and Secure, and avoid wildcard CORS with credentials.
• Restrict network exposure of the feature-store API to trusted networks or identity-aware proxies so untrusted pages cannot even reach it.
• Add detections for unexpected Origin values on Feast API logs; given low EPSS and no KEV/ransomware association, prioritize by data sensitivity rather than emergency patching theater.
• Re-test CORS after change control and include origin-allowlist checks in periodic configuration reviews.