CVE-2025-22386

Executive Summary

CVE-2025-22386 is a medium-severity session management vulnerability in Optimizely Configured Commerce, specifically affecting the B2B storefront application. The flaw allows session tokens associated with logged-out sessions to remain active and usable, enabling an attacker with access to a stale token to impersonate a legitimate user. This is a classic Insufficient Session Expiration issue (CWE-613). The vulnerability exists in versions prior to 5.2.2408. No public proof-of-concept (PoC) or exploit code has been released, and the EPSS score is 0.0%, indicating low exploitation activity in the wild. However, the risk is elevated in environments where session tokens are not properly invalidated on the server side.

Supply Chain & Package Security

This vulnerability is not related to an open-source package (NPM, PyPI, Go, Ruby). It is a proprietary commercial application (Optimizely Configured Commerce). Therefore, supply chain package security considerations are not directly applicable. However, organizations should ensure that any third-party integrations or plugins used with Optimizely do not introduce additional session handling weaknesses.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or uncalculated. Based on the description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N) – The session token can be used over the network.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – The attacker only needs a valid session token.
• User Interaction (UI): None (N) – No user action required for exploitation.
• Scope (S): Unchanged (U) – The vulnerable component is the same as the affected component.
• Confidentiality (C): High (H) – Full access to user data.
• Integrity (I): High (H) – Ability to perform actions as the user.
• Availability (A): None (N) – No impact on availability.

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

Threat Level: Medium (due to lack of public exploits and low EPSS, but high potential impact if exploited).

Deep Dive & Mechanics

The vulnerability resides in the session management logic of Optimizely Configured Commerce's B2B storefront. When a user logs out, the application fails to properly invalidate the session token on the server side. This means that the session token remains valid in the server's session store (e.g., database, cache, or in-memory store) even after the user has explicitly ended their session.

Root Cause: The logout handler likely only clears the client-side cookie or local storage but does not delete or invalidate the server-side session record. This allows the session token to be reused until it naturally expires (if at all).

Attack Scenario:

1. A legitimate user logs into the B2B storefront and receives a session token.
2. The user performs actions and then logs out.
3. An attacker who has obtained the session token (e.g., via network sniffing, XSS, or physical access to the user's device) can reuse it to make authenticated API calls.
4. The server accepts the token because it is still stored as active in the session store.

Impact: Unauthorized access to user accounts, data theft, privilege escalation (if the session belongs to an admin), and potential business logic abuse.

Vulnerable vs. Patched Code

Since this is a proprietary application, exact code snippets are not available. However, the conceptual difference is:

Vulnerable Code (Conceptual):

// Logout handler - only clears client-side cookie
function logout(req, res) {
    res.clearCookie('session_token');
    res.redirect('/login');
}

Patched Code (Conceptual):

// Logout handler - invalidates server-side session
function logout(req, res) {
    const sessionId = req.cookies.session_token;
    sessionStore.destroy(sessionId, (err) => {
        if (err) {
            console.error('Failed to destroy session:', err);
        }
        res.clearCookie('session_token');
        res.redirect('/login');
    });
}

The patch ensures that the server-side session record is deleted upon logout, making the token immediately invalid.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• Access to a valid session token from a logged-out user (e.g., via network capture, browser storage, or social engineering).
• Target running Optimizely Configured Commerce < 5.2.2408.

Exploitation Steps:

1. Obtain a session token (e.g., from a user who just logged out).
2. Use the token in HTTP requests to the storefront API.
3. Example using curl:

   curl -X GET https://target.com/api/orders \
     -H "Cookie: session_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
   

4. If the server returns data, the token is still valid.

Automated Script (Python):

import requests

target = "https://target.com"
token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

headers = {
    "Cookie": f"session_token={token}"
}

response = requests.get(f"{target}/api/account", headers=headers)
if response.status_code == 200:
    print("Session token is still active!")
else:
    print("Token invalidated.")

Blue Team (Defensive)

Detection:

• Monitor for session tokens being used after logout events.
• Look for multiple requests from the same token across different IPs or user agents.
• Alert on any API calls made with a token that was previously associated with a logged-out session.

Prevention:

• Ensure server-side session invalidation on logout.
• Implement short session timeouts and refresh token rotation.
• Use HTTP-only, Secure, and SameSite cookies.
• Log all logout events and correlate with subsequent token usage.

Hunting Query (Splunk):

index=web_logs sourcetype=access_combined
| search "/api/*" AND cookie="*session_token*"
| transaction session_token startswith="logout" endswith="api_call"
| where duration > 0
| table _time, clientip, session_token, uri

Indicators of Compromise (IOCs)

• Session Token Reuse: A session token that is used after the user has logged out.
• Anomalous API Calls: API requests from a token that was previously seen in a logout event.
• Network Traffic: HTTP requests containing a Cookie header with a session_token value that matches a known logged-out session.
• Log Patterns: Multiple 200 OK responses for API endpoints using the same token after a logout event.

Example IOC (Log Entry):

2025-03-15 10:00:00 - LOGOUT - user: jdoe, token: abc123
2025-03-15 10:05:00 - API CALL - /api/orders, token: abc123, status: 200

Detection Engineering

YARA Rule

rule Detect_Optimizely_Session_Reuse {
    meta:
        description = "Detects session token reuse in logs indicating CVE-2025-22386 exploitation"
        author = "Valters IT"
        date = "2025-03-15"
        reference = "CVE-2025-22386"
    strings:
        $logout = /LOGOUT.*token:\s*([a-f0-9]+)/ nocase
        $api_call = /API CALL.*token:\s*([a-f0-9]+)/ nocase
    condition:
        #logout > 0 and #api_call > 0 and $logout and $api_call
}

Sigma Rule

title: Optimizely Configured Commerce Session Token Reuse
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects session token reuse after logout, indicating CVE-2025-22386 exploitation
author: Valters IT
date: 2025/03/15
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-22386
logsource:
    category: web
    product: optimizely
detection:
    selection:
        event: "logout"
    selection2:
        event: "api_call"
        token: "same as logout token"
    condition: selection and selection2
falsepositives:
    - Legitimate token refresh mechanisms
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-22386 - Optimizely Session Token Reuse";
    flow:to_server,established;
    content:"Cookie|3a| session_token="; nocase;
    pcre:"/session_token=[a-zA-Z0-9_-]+/";
    sid:1000001;
    rev:1;
    reference:cve,2025-22386;
    classtype:attempted-user;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update Optimizely Configured Commerce to version 5.2.2408 or later.
2. Session Invalidation: If patching is not immediately possible, implement a custom logout handler that destroys server-side sessions.
3. Token Rotation: Enforce short-lived session tokens (e.g., 15 minutes) with refresh token rotation.

Long-Term Measures:

• Conduct a session management audit.
• Implement multi-factor authentication (MFA) for B2B users.
• Use a Web Application Firewall (WAF) to detect and block session reuse attempts.
• Monitor logs for anomalous session activity.

Workaround:

• Configure the application to use a shorter session timeout (e.g., 5 minutes) to reduce the window of opportunity.

Valters IT
Securing Digital Frontiers