CVE-2025-25182: Stroom Auth Bypass Vulnerability

CVE-2025-25182 Overview

CVE-2025-25182 is a critical authentication bypass vulnerability affecting Stroom, a data processing, storage, and analysis platform developed by GCHQ. The vulnerability exists in versions starting from 7.2-beta.53 and prior to versions 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2. When Stroom is configured with AWS Application Load Balancer (ALB) authentication and the application is accessible without going through the ALB, attackers can bypass authentication entirely. This vulnerability may also enable Server-Side Request Forgery (SSRF) attacks, potentially leading to code execution or privilege escalation through exploitation of the AWS metadata URL.

Critical Impact

Authentication bypass allows unauthorized access to Stroom systems, while SSRF capabilities may enable attackers to access AWS instance metadata, potentially compromising cloud credentials and enabling lateral movement within AWS infrastructure.

Affected Products

• Stroom versions 7.2-beta.53 to 7.2.23
• Stroom versions 7.3-beta.1 to 7.3-beta.21
• Stroom versions 7.4.0 to 7.4.3
• Stroom versions 7.5-beta.1

Discovery Timeline

• 2025-02-12 - CVE CVE-2025-25182 published to NVD
• 2025-02-12 - Last updated in NVD database

Technical Details for CVE-2025-25182

Vulnerability Analysis

This vulnerability is classified under CWE-290 (Authentication Bypass by Spoofing). The core issue arises from improper validation of authentication headers when Stroom is configured to use AWS ALB authentication integration. In a properly configured deployment, the ALB handles authentication and passes verified user identity information to the Stroom application via HTTP headers. However, when the Stroom application is directly accessible without traversing the ALB, attackers can craft requests with spoofed authentication headers that the application will trust.

The vulnerability has a network-based attack vector requiring no user interaction and no privileges, making it highly exploitable in misconfigured environments. The impact includes high confidentiality and integrity compromise with limited availability impact.

Root Cause

The root cause lies in insufficient validation of the origin of authentication assertions. Stroom trusts authentication headers without adequately verifying they originated from a legitimate ALB. When network architecture allows direct access to Stroom, bypassing the ALB, an attacker can forge these headers to impersonate any user. This trust relationship breakdown is a classic example of improper authentication validation where the application assumes network-level protections exist without enforcing them at the application layer.

Attack Vector

An attacker exploiting this vulnerability would first identify a Stroom instance that is directly accessible without going through the configured ALB. This could occur due to misconfigured network security groups, improper firewall rules, or internal network access. Once direct access is established, the attacker can craft HTTP requests with forged ALB authentication headers, such as x-amzn-oidc-accesstoken or x-amzn-oidc-data, to bypass authentication entirely.

Additionally, the SSRF component allows attackers to make server-side requests to internal resources. By targeting the AWS metadata service at http://169.254.169.254/, attackers can retrieve instance credentials, IAM role tokens, and other sensitive AWS configuration data. This can lead to significant privilege escalation within the AWS environment.

The vulnerability mechanics involve header injection and trust exploitation. Detailed technical information is available in the GitHub Security Advisory GHSA-x489-xx2m-vc43 and the associated pull request #4320.

Detection Methods for CVE-2025-25182

Indicators of Compromise

• Requests to Stroom originating from IP addresses other than the configured ALB
• Authentication headers present in requests not originating from trusted load balancer sources
• Unusual access patterns to sensitive data or administrative functions without corresponding ALB authentication logs
• Server-side requests to the AWS metadata endpoint (169.254.169.254)

Detection Strategies

• Implement network monitoring to detect direct connections to Stroom that bypass the ALB
• Configure web application firewall (WAF) rules to alert on requests containing ALB authentication headers from non-ALB sources
• Monitor AWS CloudTrail for unusual API calls that may indicate compromised instance credentials
• Enable detailed access logging in Stroom and correlate with ALB access logs to identify authentication discrepancies

Monitoring Recommendations

• Set up alerts for any requests reaching Stroom servers directly without passing through the ALB
• Monitor for SSRF indicators including outbound connections to metadata endpoints
• Implement anomaly detection for user authentication patterns and access to sensitive resources
• Review VPC flow logs for unexpected traffic patterns to Stroom instances

How to Mitigate CVE-2025-25182

Immediate Actions Required

• Update Stroom to the patched versions: 7.2.24, 7.3-beta.22, 7.4.4, or 7.5-beta.2
• Restrict network access to ensure Stroom is only accessible through the configured ALB
• Review security group and firewall configurations to prevent direct access to Stroom instances
• Audit access logs for signs of prior exploitation

Patch Information

The vulnerability has been fixed in Stroom versions 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2. The fix addresses the authentication bypass by implementing proper validation of authentication headers and their source. Detailed patch information is available in GitHub Pull Request #4320. Organizations should prioritize upgrading to the latest patched version within their release branch.

Workarounds

• Configure AWS security groups to ensure Stroom instances only accept connections from the ALB security group
• Implement IMDSv2 (Instance Metadata Service version 2) to mitigate SSRF attacks against the AWS metadata service
• Use network ACLs as an additional layer of defense to restrict direct access to Stroom
• Consider deploying Stroom within a private subnet with no direct internet accessibility

# AWS Security Group configuration to restrict access to ALB only
# Replace sg-alb-security-group with your actual ALB security group ID

aws ec2 authorize-security-group-ingress \
  --group-id sg-stroom-instance \
  --protocol tcp \
  --port 443 \
  --source-group sg-alb-security-group

# Revoke any overly permissive rules allowing direct access
aws ec2 revoke-security-group-ingress \
  --group-id sg-stroom-instance \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0