CVE-2025-55162
Executive Summary
CVE-2025-55162 is a vulnerability in the Envoy proxy's OAuth2 filter that leads to insufficient session expiration. When the filter is configured with __Secure- or __Host- prefixed cookie names, it fails to append the required Secure attribute to the Set-Cookie header during logout operations. Modern browsers, adhering to RFC 6265, ignore such invalid deletion requests, causing the session cookie to persist. This allows a user to remain logged in after believing they have logged out, creating a session hijacking risk, particularly on shared computers. The vulnerability affects Envoy versions below 1.32.10, 1.33.0 through 1.33.6, 1.34.0 through 1.34.4, and 1.35.0. Patches are available in versions 1.32.10, 1.33.7, 1.34.5, and 1.35.1.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Envoy is a widely used open-source L7 proxy and communication bus, often deployed as a sidecar proxy in service meshes (e.g., Istio, Consul Connect). The vulnerability is in the OAuth2 filter, which is a core component for authentication. Organizations using Envoy in their infrastructure should treat this as a high-priority supply chain risk, as it directly impacts session management and user authentication. The fix requires updating the Envoy binary or container image.
CVSS Breakdown & Threat Level
- CVSS Score: 6.3 (Medium)
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
- Attack Vector (AV): Network - The vulnerability can be exploited remotely.
- Attack Complexity (AC): Low - No special conditions are required.
- Privileges Required (PR): None - No authentication needed to trigger the logout failure.
- User Interaction (UI): Required - The victim must perform a logout action.
- Scope (S): Unchanged - The vulnerable component and the affected resource are the same.
- Confidentiality (C): Low - Limited information disclosure (session persistence).
- Integrity (I): Low - Limited ability to maintain a session after logout.
- Availability (A): Low - Limited impact on availability (session not terminated).
Threat Level: Medium. The vulnerability requires user interaction (logout) and is primarily a risk on shared computers. However, it can lead to unauthorized access to user accounts and data.
Deep Dive & Mechanics
The Envoy OAuth2 filter manages user sessions by setting cookies. When a user logs out, the filter is supposed to delete the session cookie by sending a Set-Cookie header with an expiration date in the past. According to RFC 6265, cookies with names prefixed with __Secure- or __Host- must have the Secure attribute set. The vulnerability arises because the filter's logout logic iterates through configured cookie names to generate deletion headers but does not check for these prefixes. Consequently, it fails to append the Secure attribute to the Set-Cookie header during deletion.
Modern browsers, when receiving a Set-Cookie header for a __Secure- or __Host- prefixed cookie without the Secure attribute, treat the header as invalid and ignore it. This means the session cookie is never deleted, and the user remains logged in. The next user of the same browser can then access the original user's account and data.
Root Cause: The logout function in the OAuth2 filter does not properly construct the Set-Cookie header for cookies with __Secure- or __Host- prefixes. It omits the Secure attribute, which is mandatory for such cookies.
Vulnerable vs. Patched Code
Vulnerable Code (Conceptual):
// In the logout handler, for each configured cookie name:
std::string cookie_header = name + "=; Path=/; Max-Age=0; HttpOnly";
// Missing: Secure attribute for __Secure- and __Host- prefixed cookies
Patched Code (Conceptual):
// In the logout handler, for each configured cookie name:
std::string cookie_header = name + "=; Path=/; Max-Age=0; HttpOnly";
if (name.find("__Secure-") == 0 || name.find("__Host-") == 0) {
cookie_header += "; Secure";
}
The patch adds a check for the __Secure- and __Host- prefixes and appends the Secure attribute to the Set-Cookie header when these prefixes are present.
Exploitation & Lab Setup
Red Team (Exploitation)
Prerequisites:
- An Envoy proxy (vulnerable version) configured with the OAuth2 filter and
__Secure-or__Host-prefixed cookie names. - A user who authenticates via the OAuth2 filter and then logs out.
Exploitation Steps:
- Setup: Deploy a vulnerable Envoy instance with OAuth2 filter configured to use
__Secure-sessionas the cookie name. - Authenticate: Have a victim user log in to the application through the Envoy proxy. The OAuth2 filter will set a session cookie named
__Secure-session. - Logout: The victim user clicks the logout button. The Envoy OAuth2 filter sends a
Set-Cookieheader to delete the cookie, but without theSecureattribute. - Session Persistence: The browser ignores the invalid deletion header, and the session cookie remains.
- Hijack: An attacker, using the same browser (e.g., on a shared computer), can access the application and will still be authenticated as the victim user.
No public exploit code is available for this CVE.
Blue Team (Detection & Defense)
Detection:
- Monitor for
Set-Cookieheaders in HTTP responses that attempt to delete__Secure-or__Host-prefixed cookies but lack theSecureattribute. - Look for anomalous session activity, such as sessions that persist after a logout event.
- Use the detection rules provided in the Detection Engineering section.
Defense:
- Immediate: Update Envoy to a patched version (1.32.10, 1.33.7, 1.34.5, or 1.35.1).
- Mitigation: If patching is not immediately possible, avoid using
__Secure-or__Host-prefixed cookie names in the OAuth2 filter configuration. Use standard cookie names instead. - Workaround: Implement a server-side session invalidation mechanism that does not rely solely on cookie deletion. For example, maintain a blacklist of invalidated session tokens on the backend.
Indicators of Compromise (IOCs)
- Network:
- HTTP response headers containing
Set-Cookie: __Secure-orSet-Cookie: __Host-without theSecureattribute. - Example:
Set-Cookie: __Secure-session=; Path=/; Max-Age=0; HttpOnly(missingSecure).
- HTTP response headers containing
- Logs:
- Envoy access logs showing logout requests followed by continued authenticated requests from the same client IP.
- Application logs showing session IDs that were supposed to be invalidated but are still active.
- Endpoint:
- Browser cookie storage showing
__Secure-or__Host-prefixed cookies that persist after a logout action.
- Browser cookie storage showing
Detection Engineering
YARA Rule
rule CVE_2025_55162_Envoy_OAuth2_Session_Expiration {
meta:
description = "Detects Set-Cookie headers for __Secure- or __Host- prefixed cookies without the Secure attribute"
author = "Valters IT"
date = "2025-04-10"
cve = "CVE-2025-55162"
strings:
$cookie_prefix = /Set-Cookie:\s*(__Secure-|__Host-)[^;]+/
$secure_attr = /;\s*Secure/
condition:
$cookie_prefix and not $secure_attr
}
Sigma Rule
title: CVE-2025-55162 - Envoy OAuth2 Filter Session Expiration Bypass
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP responses where a Set-Cookie header for a __Secure- or __Host- prefixed cookie lacks the Secure attribute.
author: Valters IT
date: 2025-04-10
logsource:
category: webserver
product: envoy
detection:
selection:
response_headers|contains: 'Set-Cookie: __Secure-'
exclusion:
response_headers|contains: '; Secure'
condition: selection and not exclusion
falsepositives:
- Legitimate cookies that are not meant to be deleted (but this rule targets deletion headers)
level: high
Suricata Rule
alert http any any -> any any (msg:"CVE-2025-55162 - Envoy OAuth2 Filter Session Expiration Bypass"; flow:to_client; content:"Set-Cookie"; http_header; pcre:"/Set-Cookie:\s*(__Secure-|__Host-)[^;]+/i"; pcre:"!/;\s*Secure/i"; sid:10000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Patch: Upgrade Envoy to version 1.32.10, 1.33.7, 1.34.5, or 1.35.1 (or later).
- Configuration Change: If patching is delayed, reconfigure the OAuth2 filter to use cookie names without the
__Secure-or__Host-prefixes. This reduces the attack surface but may weaken cookie security. - Server-Side Invalidation: Implement a server-side session blacklist or token revocation mechanism to ensure sessions are invalidated even if the cookie is not deleted.
Long-Term Measures:
- Code Review: Review all cookie handling code in the OAuth2 filter to ensure compliance with RFC 6265.
- Testing: Add unit and integration tests that verify correct
Set-Cookieheader construction for all cookie name prefixes. - Monitoring: Deploy the detection rules provided in this report to monitor for exploitation attempts.
Valters IT
DevSecOps & Cyber Threat Intelligence