CVE-2024-29036

Executive Summary

CVE-2024-29036 is a vulnerability in Saleor Storefront, an open-source e-commerce platform. The flaw allows an unauthenticated, anonymous user to access the session data of any authenticated user due to improper caching of authentication tokens. This information disclosure vulnerability (CWE-200) has a CVSS score of 4.3 (Medium). The root cause is that the session token is leaked through the cache and can be accessed by anyone. The vendor has provided a patch in commit 579241e75a5eb332ccf26e0bcdd54befa33f4783. A workaround is to temporarily disable authentication by changing the usage of createSaleorAuthClient(). No public exploit code or PoC is available at this time.

Supply Chain & Package Security

Saleor Storefront is a JavaScript/TypeScript application typically distributed via npm or GitHub. The vulnerability exists in the authentication caching mechanism. Organizations using Saleor Storefront should verify their dependency version and ensure they are using a patched commit. The package is not directly affected by a malicious package injection, but the vulnerability itself is a logic flaw in the application code.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – The attacker does not need to be authenticated.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – Only session data (authentication tokens) are exposed.
• Integrity Impact: None (I:N) – No data modification is possible.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: Medium. The vulnerability allows session hijacking, which could lead to account takeover if the attacker can use the leaked session to impersonate a user. However, the EPSS score is 0.0%, indicating low exploitation activity in the wild.

Deep Dive & Mechanics

The vulnerability resides in the authentication caching mechanism of Saleor Storefront. When a user authenticates, the application creates an authentication client via createSaleorAuthClient(). This client stores the session token in a cache (likely a browser cache or a server-side cache) that is shared across users. Due to improper cache isolation, an anonymous user can access the cached session data of a previously authenticated user.

Root Cause: The cache key or cache scope does not include a user-specific identifier, allowing the session token to be served to any request that hits the same cache entry. This is a classic cache poisoning / information disclosure issue.

Attack Scenario:

1. A legitimate user authenticates to the Saleor Storefront.
2. The application caches the user's session token in a shared cache (e.g., a CDN or browser cache).
3. An attacker sends a request to the same endpoint without authentication.
4. The cache returns the authenticated user's session token.
5. The attacker can then use this token to impersonate the user.

Vulnerable vs. Patched Code

The patch is in commit 579241e75a5eb332ccf26e0bcdd54befa33f4783. The exact code changes are not publicly detailed, but the fix likely involves:

• Adding a cache key that includes the user ID or session ID.
• Ensuring that cached responses are not served to unauthenticated users.
• Possibly using Cache-Control: private headers to prevent shared caching.

Vulnerable Code (Conceptual):

// Vulnerable: Cache key does not include user context
const cacheKey = '/api/session';
const cachedSession = cache.get(cacheKey);
if (cachedSession) {
  return cachedSession;
}
const session = createSaleorAuthClient();
cache.set(cacheKey, session);
return session;

Patched Code (Conceptual):

// Patched: Cache key includes user ID
const cacheKey = `/api/session/${user.id}`;
const cachedSession = cache.get(cacheKey);
if (cachedSession) {
  return cachedSession;
}
const session = createSaleorAuthClient();
cache.set(cacheKey, session);
return session;

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A running Saleor Storefront instance (vulnerable version).
• A legitimate user who has authenticated.
• An attacker machine with network access to the storefront.

Steps:

1. Identify the authentication endpoint (e.g., /api/auth/session).
2. As an anonymous user, send a GET request to the endpoint:

   curl -v http://target-saleor.com/api/auth/session
   

3. If the response contains a session token (e.g., Authorization: Bearer <token>), the vulnerability is present.
4. Use the leaked token to access authenticated resources:

   curl -H "Authorization: Bearer <leaked_token>" http://target-saleor.com/api/user/profile
   

Note: No public exploit code is available. The above is a conceptual exploitation.

Blue Team (Detection & Defense)

Detection:

• Monitor for multiple requests to the same authentication endpoint from different IPs without authentication.
• Look for anomalous use of session tokens (e.g., same token used from different IPs).
• Check cache headers: If Cache-Control: public is set on authenticated responses, it is a red flag.

Defense:

• Apply the patch immediately.
• As a workaround, disable authentication by changing the usage of createSaleorAuthClient().
• Implement proper cache isolation: Use Cache-Control: private for authenticated endpoints.
• Use a CDN that respects cache scoping (e.g., Cloudflare with authenticated origin pull).

Indicators of Compromise (IOCs)

• Network: HTTP requests to /api/auth/session or similar endpoints without authentication.
• Logs: Multiple 200 OK responses to unauthenticated requests for session data.
• Cache: Presence of session tokens in shared cache (e.g., CDN logs showing cache hits for unauthenticated users).
• Token: Session tokens appearing in logs or network traffic that are not tied to a specific user session.

Detection Engineering

YARA Rule

rule CVE_2024_29036_Saleor_Session_Leak {
  meta:
    description = "Detects Saleor Storefront session token leakage in cache"
    author = "Valters IT"
    date = "2024-01-01"
    reference = "CVE-2024-29036"
  strings:
    $saleor_auth = "createSaleorAuthClient" nocase
    $session_token = /Bearer\s+[A-Za-z0-9\-._~+/]+=*/ nocase
    $cache_public = "Cache-Control: public" nocase
  condition:
    $saleor_auth and $session_token and $cache_public
}

Sigma Rule

title: Saleor Storefront Session Token Leakage
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects unauthenticated access to Saleor Storefront session endpoints
author: Valters IT
date: 2024/01/01
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2024-29036
logsource:
  category: webserver
  product: apache
  service: access_log
detection:
  selection:
    cs-method: 'GET'
    cs-uri-stem: '/api/auth/session'
    sc-status: 200
  condition: selection
falsepositives:
  - Legitimate unauthenticated users accessing public session info (if any)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-29036 Saleor Storefront Session Leak"; flow:to_server; content:"GET"; http_method; content:"/api/auth/session"; http_uri; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade to commit 579241e75a5eb332ccf26e0bcdd54befa33f4783 or later.
2. Workaround: Temporarily disable authentication by changing the usage of createSaleorAuthClient().
3. Cache Configuration: Ensure all authenticated endpoints return Cache-Control: private headers.

Long-Term Fixes:

• Implement proper cache scoping (e.g., include user ID in cache keys).
• Use server-side sessions with secure, HttpOnly cookies.
• Regularly audit dependencies for similar vulnerabilities.

Verification:

• After patching, test the endpoint as an anonymous user to ensure no session data is returned.
• Review cache logs for any unauthorized access.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert