CVE-2025-59048

Executive Summary

CVE-2025-59048 is a critical security vulnerability in the OpenBao AWS authentication plugin (auth-aws). The flaw allows an attacker with an IAM role in an untrusted AWS account to impersonate a role with the same name in a trusted account, thereby gaining unauthorized access to the OpenBao instance. This vulnerability is particularly dangerous in multi-account AWS environments where IAM role names are not guaranteed to be unique. The CVSS score of 8.1 reflects the high impact on confidentiality and integrity, with a low attack complexity and no user interaction required. The vulnerability has been patched in version 0.1.1 of the auth-aws plugin.

Supply Chain & Package Security

This vulnerability is specific to the OpenBao project and its auth-aws plugin. OpenBao is a Go-based project, and the plugin is distributed as part of the OpenBao binary. Users should ensure they are using the latest patched version (0.1.1 or later) of the auth-aws plugin. There is no indication of a compromised package in the supply chain; the vulnerability is a logic flaw in the authentication mechanism.

CVSS Breakdown & Threat Level

• CVSS Score: 8.1 (High)
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) - The attacker needs an IAM role in an untrusted AWS account.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Changed (C) - The vulnerable component (OpenBao) is impacted, but the impact extends to the trusted AWS account's resources.
• Confidentiality (C): High (H) - Unauthorized access to secrets and data.
• Integrity (I): High (H) - Unauthorized modification of secrets or configurations.
• Availability (A): None (N) - The vulnerability does not directly impact availability.

Threat Level: High. The vulnerability is easily exploitable in multi-account AWS environments and can lead to significant data breaches.

Deep Dive & Mechanics

The vulnerability lies in the AWS IAM role authentication method within the auth-aws plugin. When an IAM role from an AWS account attempts to authenticate to OpenBao, the plugin verifies the role's identity using the sts:AssumeRole or sts:GetCallerIdentity API. However, prior to version 0.1.1, the plugin only checked the role name and did not validate the AWS account ID of the requesting role.

Attack Scenario:

1. An attacker controls an AWS account (Account B) with an IAM role named admin-role.
2. The target OpenBao instance is configured to trust IAM role admin-role from a legitimate AWS account (Account A).
3. The attacker's IAM role in Account B also has the name admin-role.
4. The attacker authenticates to OpenBao using their IAM role from Account B.
5. The auth-aws plugin sees the role name admin-role and grants access, assuming it is from the trusted Account A.
6. The attacker now has the same level of access as the legitimate admin-role from Account A.

Root Cause: The plugin did not include the AWS account ID in the identity verification logic. The fix in version 0.1.1 adds account ID validation to ensure the role is from the expected trusted account.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-0.1.1):

// Simplified vulnerable logic
func authenticateIAMRole(roleName string, callerIdentity *sts.GetCallerIdentityOutput) bool {
    // Only checks role name, not account ID
    if roleName == callerIdentity.Arn {
        return true
    }
    return false
}

Patched Code (0.1.1):

// Patched logic with account ID validation
func authenticateIAMRole(roleName string, callerIdentity *sts.GetCallerIdentityOutput, trustedAccountID string) bool {
    // Checks both role name and account ID
    if roleName == callerIdentity.Arn && trustedAccountID == callerIdentity.Account {
        return true
    }
    return false
}

The patched code now requires the AWS account ID from the GetCallerIdentity response to match the trusted account ID configured in OpenBao.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• An AWS account (untrusted) with an IAM role that has the same name as a role trusted by the target OpenBao instance.
• Network access to the OpenBao instance.
• Knowledge of the trusted role name.

Exploitation Steps:

1. Identify the trusted role name: This can be done through reconnaissance (e.g., checking OpenBao configuration if exposed, or social engineering).
2. Create an IAM role with the same name in your untrusted AWS account.
3. Authenticate to OpenBao using the AWS auth method:

   vault login -method=aws role=admin-role \
     aws_access_key_id=AKIA... \
     aws_secret_access_key=... \
     aws_security_token=...
   

4. If successful, you will receive a Vault token with the privileges of the trusted role.

Note: No public exploit code is available at this time.

Blue Team (Detection & Defense)

Detection:

• Monitor AWS CloudTrail logs for GetCallerIdentity API calls from unexpected AWS accounts.
• Look for authentication attempts to OpenBao from IAM roles that are not in the trusted account list.
• Use the following detection rules.

Defense:

• Immediately upgrade to auth-aws plugin version 0.1.1 or later.
• Ensure IAM role names are unique across all AWS accounts that interact with OpenBao.
• Implement strict network controls to limit access to the OpenBao API.
• Enable detailed logging and alerting on OpenBao authentication events.

Indicators of Compromise (IOCs)

• Authentication logs showing successful logins from an IAM role that is not from the expected AWS account.
• CloudTrail events with eventName = GetCallerIdentity from an unknown or untrusted AWS account ID.
• OpenBao audit logs with auth_type = aws and role matching a known role name but from an unexpected source.

Detection Engineering

YARA Rule

rule CVE_2025_59048_OpenBao_AWS_Auth {
    meta:
        description = "Detects exploitation attempts of CVE-2025-59048 in OpenBao AWS auth"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-59048"
    strings:
        $s1 = "vault login -method=aws" ascii wide nocase
        $s2 = "role=" ascii wide nocase
        $s3 = "aws_access_key_id" ascii wide nocase
        $s4 = "aws_secret_access_key" ascii wide nocase
    condition:
        all of ($s*) and #s1 > 0
}

Sigma Rule

title: OpenBao Cross-Account IAM Role Impersonation Attempt
id: cve-2025-59048
status: experimental
description: Detects authentication attempts to OpenBao using AWS IAM roles from untrusted accounts.
author: Valters IT
date: 2025-04-10
logsource:
    product: openbao
    service: audit
detection:
    selection:
        auth_type: "aws"
        role: "*"
    condition: selection
falsepositives:
    - Legitimate cross-account access if configured correctly.
level: high

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 8200 (msg:"CVE-2025-59048 OpenBao AWS Auth Impersonation Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/v1/auth/aws/login"; http_uri; content:"role="; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade the auth-aws plugin to version 0.1.1 or later. This is the only complete fix.
2. Audit all IAM roles in your AWS environment to ensure no duplicate role names exist across accounts that interact with OpenBao.
3. Review OpenBao audit logs for any suspicious authentication events.

Long-term Mitigations:

• Implement strict IAM role naming conventions to prevent duplicates.
• Use AWS Organizations and Service Control Policies (SCPs) to restrict cross-account role assumptions.
• Enable multi-factor authentication (MFA) for all OpenBao authentication methods.
• Regularly review and update OpenBao configurations.

Workaround (if patching is not immediately possible):

• Manually ensure that IAM role names are unique across all AWS accounts that could potentially interact with your OpenBao environment. This is not a complete fix but reduces the attack surface.

Valters IT