CVE-2025-25182: Understanding the Critical Authentication Bypass in Stroom

Executive Summary

CVE-2025-25182 is a critical security vulnerability affecting Stroom, a data processing, storage, and analysis platform widely used in enterprise environments. Classified as CWE-290: Authentication Bypass by Spoofing, this flaw occurs when Stroom is misconfigured with AWS Application Load Balancer (ALB) Authentication Integration. It permits attackers to bypass authentication, which may also lead to Server-Side Request Forgery (SSRF) attacks. Furthermore, SSRF abuse can result in Remote Code Execution (RCE) or privilege escalation by accessing the AWS metadata endpoint. The vulnerability has been assigned a CVSS score of 9.4 (Critical) and poses a high risk to data confidentiality, integrity, and availability.

Affected setups include Stroom installations starting from versions 7.2-beta.53 and prior to 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2. If the application is exposed directly instead of through an ALB, the vulnerability may be exploited. Critical patches have been released and must be applied to secure systems against exploitation.

Technical Details

The vulnerability resides in the AWS ALB Authentication Integration within Stroom's OpenID configuration module, which is responsible for delegating identity verification to AWS ALBs using signed JWT tokens. Exploitation of this issue is possible under the following conditions:

1. Misconfiguration: The Stroom application is exposed directly to a network without strictly routing requests via an authenticated ALB.
2. ALB Signature Validation Flaw: When a JWT signed by AWS ALB is received, the system does not validate the "signer" field of the token properly to verify that it originates from an expected AWS resource.

Affected Components

• OpenID Configuration: The flaw lies in how expected AWS ALB signer ARNs are validated during token verification.
• Versions Impacted:
  • Stroom 7.2-beta.53 and earlier.
  • Versions prior to 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2.

Evidence of Exploitation

Exposed Stroom systems may display the following characteristics if exploited:

• Unexpected Authentication Successes: Requests authenticated successfully despite invalid or manipulated JWTs crafted by attackers.
• Internal SSRF Attempts: The application connects to sensitive endpoints, such as http://169.254.169.254 (AWS Instance Metadata Service), which attackers can exploit for token extraction or privilege escalation.

Root Cause Analysis

The core issue arises due to improper validation of the JWT signer claim during authentication with AWS ALB. Specifically:

1. JWT Header Weakness: The signer property in the JWT header is supposed to denote the ARN of the AWS ALB performing token signing. However, older versions of Stroom lacked a mechanism to validate that the provided value adhered to pre-configured allowed ARNs.
2. Absence of Expected Signer Prefix Check: Without verifying signer prefixes, an attacker could supply arbitrary values, bypassing authentication safeguards.

Below is an annotated example of the issue:

Vulnerable Code Snippet

In the getAwsPublicKeyUri function, JWT signer validation was incomplete:

static String getAwsPublicKeyUri(final JwsParts jwsParts) {
    final Map<String, String> headerValues = jwsParts.getHeaderValues(
            SIGNER_HEADER_KEY,
            OpenId.KEY_ID,
            null);

    final String signer = headerValues.get(SIGNER_HEADER_KEY);

    // Signer validation omitted!
    final String keyId = headerValues.get(OpenId.KEY_ID);
    return LogUtil.message(
        "https://public-keys.auth.elb.{}.amazonaws.com/{}",
        signer.split(":")[3], keyId
    );
}

The above implementation makes no effort to validate that signer begins with a pre-configured ARN prefix. This omission allows untrusted, attacker-crafted signers to proceed unchecked.

Mitigation in Root Cause (Post-Patch)

The patched implementation explicitly checks signer values against a whitelist of allowed prefixes included in the configuration. See the Patch Analysis section for details.

Patch Analysis

The critical patches released in versions 7.2.24, 7.3-beta.22, 7.4.4, and 7.5-beta.2 fix the flaw by introducing rigorous signer validation logic. The following is an overview and detailed breakdown of the patch, derived from the source code diff:

Key Changes

Validation of ALB Signer Prefixes

The patch introduces a new configuration property, expectedSignerPrefixes, to define allowed ALB ARNs. During token parsing, signers are verified against this list.

File: StandardJwtContextFactory.java

+ private static final Pattern AMZN_REGION_PATTERN = Pattern.compile("^[a-z0-9-]+$");

 static String getAwsPublicKeyUri(final JwsParts jwsParts, final Set<String> expectedSignerPrefixes) {
     final String signer = jwsParts.getHeaderValue(SIGNER_HEADER_KEY);

+    // Ensure signer starts with an allowed prefix
+    final boolean isAllowedSigner = expectedSignerPrefixes.stream()
+          .anyMatch(prefix -> signer != null && signer.startsWith(prefix));
+    if (!isAllowedSigner) {
+          throw new RuntimeException("Invalid ALB JWT signer detected.");
+    }

     return LogUtil.message("https://public-keys.auth.elb.{}.amazonaws.com/{}", 
          extractAwsRegionFromSigner(signer), keyId);
 }

Configuration Property Introduced

A new field expectedSignerPrefixes is added to the OpenID configuration to store a whitelist of trusted ARNs.

File: AbstractOpenIdConfig.java

+ @JsonProperty("expectedSignerPrefixes")
+ private final Set<String> expectedSignerPrefixes;

 public Set<String> getExpectedSignerPrefixes() {
      return expectedSignerPrefixes;
 }

Exploitation Techniques

Attack Vector

An attacker with network visibility to a misconfigured Stroom instance can bypass authentication by:

1. Crafting a JWT with an invalid signer value.
2. The application does not validate the signer, accepting the JWT as legitimate.
3. Gaining unauthorized access, which may extend to command execution if SSRF attacks are feasible.

Proof-of-Concept (PoC)

Below is a simplified example:

1. Craft JWT:
   Use a tool like jwt.io to create a JWT with an arbitrary signer such as arn:malicious:loadbalancer.

2. Simulating a Direct Request:

   curl -X GET "http://stroom-vulnerable.com/api" \
        -H "Authorization: Bearer <jwt>"
   

3. Results:
   If unpatched, the above request will bypass authentication.

Real-World Scenarios

• SSRF & Metadata Access: Redirecting Stroom to AWS metadata service to retrieve sensitive environment credentials.
• Privilege Escalation: Compromise of user tokens to escalate privileges within a cloud environment.

Mitigation Strategies

1. Apply Patches

Upgrade to one of the following safe versions:

• 7.2.24
• 7.3-beta.22
• 7.4.4
• 7.5-beta.2

2. Implement Configuration Best Practices

• Ensure all Stroom traffic passes through an authenticated ALB.
• Configure the expectedSignerPrefixes property to explicitly whitelist trusted ALB ARNs:

  security.authentication.openId.expectedSignerPrefixes:
    - "arn:aws:elasticloadbalancing:<region>:<account_id>:"
  

3. Block Metadata Access

Restrict access to http://169.254.169.254 using firewall rules or equivalent network controls.

Timeline of Discovery and Disclosure

References

• GitHub Pull Request #4320
• GitHub Security Advisory GHSA-x489-xx2m-vc43
• Stroom Official Repository

Secure your systems today and stay safe from CVE-2025-25182!