bug: 12 hour sessions no longer working when assuming role

[saintaardvark]

• I am using the latest release of AWS Vault
• I have provided my .aws/config (redacted if necessary)
• I have provided the debug output using aws-vault --debug (redacted if necessary)

Hi there -- first off, thanks for picking up aws-vault and maintaining it. It's very much appreciated.

We just switched to your fork, and it looks like newer versions do not allow us to get the 12-hour sessions we had previously; instead, we're limited to 1 hour session. The change appears to be in 7.6.0, with the merge of #75.

In version 7.5.6, aws-vault will give us a 12-hour session in the role we have configured for daily use:

$ AWS_ASSUME_ROLE_TTL=12h aws-vault-7.5.6 --debug exec 123456789012 -- echo "foo"

$ AWS_ASSUME_ROLE_TTL=12h aws-vault-7.5.6 --debug exec 123456789012 -- echo "foo"
2026/02/04 13:06:46 aws-vault v7.5.6
2026/02/04 13:06:46 Using prompt driver: terminal
2026/02/04 13:06:46 Loading config file /home/me/.aws/config
2026/02/04 13:06:46 Parsing config file /home/me/.aws/config
2026/02/04 13:06:46 [keyring] Considering backends: [secret-service]
2026/02/04 13:06:46 Using duration_seconds "12h0m0s" from AWS_ASSUME_ROLE_TTL
2026/02/04 13:06:46 profile 123456789012: using stored credentials
2026/02/04 13:06:46 profile 123456789012: using AssumeRole (with MFA)
2026/02/04 13:06:46 Setting subprocess env: AWS_REGION=us-east-1, AWS_DEFAULT_REGION=us-east-1
Enter MFA code for arn:aws:iam::123456789012:mfa/Duo: 123456
2026/02/04 13:07:15 Looking up keyring for '123456789012'
2026/02/04 13:07:16 Generated credentials ****************ABCD using AssumeRole, expires in 11h59m59.840169559s
2026/02/04 13:07:16 Setting subprocess env: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
2026/02/04 13:07:16 Setting subprocess env: AWS_SESSION_TOKEN
2026/02/04 13:07:16 Setting subprocess env: AWS_CREDENTIAL_EXPIRATION
2026/02/04 13:07:16 Exec command echo foo
2026/02/04 13:07:16 Found executable /usr/bin/echo
foo

Here, we're logging:

• using stored credentials
• using AssumeRole (with MFA)
• then we get our 12 hour session. 🥳

In version 7.6.0, we're limited to a 1 hour session:

$ AWS_ASSUME_ROLE_TTL=12h aws-vault-7.6.0 --debug exec 123456789012 -- echo "foo"

2026/02/04 13:11:23 aws-vault v7.6.0
2026/02/04 13:11:23 Using prompt driver: terminal
2026/02/04 13:11:23 Loading config file /home/me/.aws/config
2026/02/04 13:11:23 Parsing config file /home/me/.aws/config
2026/02/04 13:11:23 [keyring] Considering backends: [secret-service]
2026/02/04 13:11:23 Using duration_seconds "12h0m0s" from AWS_ASSUME_ROLE_TTL
2026/02/04 13:11:23 profile 123456789012: using stored credentials
2026/02/04 13:11:23 profile 123456789012: using GetSessionToken (with MFA)
2026/02/04 13:11:23 profile 123456789012: using AssumeRole (chained MFA)
2026/02/04 13:11:23 Setting subprocess env: AWS_REGION=us-east-1, AWS_DEFAULT_REGION=us-east-1
Enter MFA code for arn:aws:iam::123456789012:mfa/Duo: 123456
2026/02/04 13:11:27 Looking up keyring for '123456789012'
2026/02/04 13:11:27 Generated credentials ****************ABCD using GetSessionToken, expires in 59m59.207441233s
aws-vault: error: exec: Failed to get credentials for 123456789012: operation error STS: AssumeRole, https response error StatusCode: 400, RequestID: 818bc3f9-4485-4dba-be48-7425ba79191b, api error ValidationError: The requested DurationSeconds exceeds the 1 hour session limit for roles assumed by role chaining.

Here we're logging:

• using stored credentials
• using GetSessionToken (with MFA)
• using AssumeRole (chained MFA)
• then we only get a 1 hour session.

I'm guessing, then, that it's the chained MFA request which is causing this problem (and it seems to be confirmed by AWS documentation).

I've tried using the --no-session option in 7.6.0, but I get the same result:

$ AWS_ASSUME_ROLE_TTL=12h aws-vault-7.6.0 --debug exec --no-session 123456789012 -- echo "foo"

2026/02/04 13:17:09 aws-vault v7.6.0
2026/02/04 13:17:09 Using prompt driver: terminal
2026/02/04 13:17:09 Loading config file /home/me/.aws/config
2026/02/04 13:17:09 Parsing config file /home/me/.aws/config
2026/02/04 13:17:09 [keyring] Considering backends: [secret-service]
2026/02/04 13:17:09 Using duration_seconds "12h0m0s" from AWS_ASSUME_ROLE_TTL
2026/02/04 13:17:09 profile 123456789012: using stored credentials
2026/02/04 13:17:09 profile 123456789012: skipping GetSessionToken because sessions are disabled
2026/02/04 13:17:09 profile 123456789012: using GetSessionToken (with MFA)
2026/02/04 13:17:09 profile 123456789012: using AssumeRole (chained MFA)
2026/02/04 13:17:09 Setting subprocess env: AWS_REGION=us-east-1, AWS_DEFAULT_REGION=us-east-1
Enter MFA code for arn:aws:iam::123456789012:mfa/Duo: 123456
2026/02/04 13:17:13 Looking up keyring for '123456789012'
2026/02/04 13:17:13 Generated credentials ****************ABCD using GetSessionToken, expires in 59m59.29396717s
aws-vault: error: exec: Failed to get credentials for 123456789012: operation error STS: AssumeRole, https response error StatusCode: 400, RequestID: e6517583-ea86-4f03-9a18-f8d324b6b0df, api error ValidationError: The requested DurationSeconds exceeds the 1 hour session limit for roles assumed by role chaining.

(Account IDs sanitized.)

My ~/.aws/config looks like this:

[default]
region=us-east-1

[profile 123456789012]
region=us-east-1
role_arn=arn:aws:iam::123456789012:role/admin
mfa_serial=arn:aws:iam::123456789012:mfa/Duo

I've had a look through getSourceCredWithSession() in vault.go where this seems to be handled, but I'm unable to see an obvious way to disable this.

My questions:

• Is there some configuration I should be setting in ~/.aws.config or elsewhere that will disable the chained MFA request?

• If not, is it possible to add a switch that will use the old behaviour? (I definitely don't want to break things for folks that were glad to see fix(rolechaining): add missing MFA auth logic for session creds #75 merged!)

• Is this a reasonably secure thing to ask? I want to make sure I'm not missing a problem with the way we assume these roles.

Thanks again for all your work on this project!

[mbevc1]

Hi @saintaardvark !

Thanks for opening the issue and I know there are some limitations when doing role chaining. Let me look into this more in the next few days. Also based on your config chaining is not required so I think we should handle this case 🤔

[saintaardvark]

Hi @mbevc1 -- just following up on this. Is there anything I can provide that'll help here?

[mbevc1]

Oh, thanks for getting back on this one. TBH I got distracted the other day so this fell off my radar a bit, but still on my TODO 😅

Can I confirm 12h session with the same AWS config works on v7.5?

[saintaardvark]

No worries, and thank you!

Can I confirm 12h session with the same AWS config works on v7.5?

Correct -- version 7.5.6 was tested, and works just fine. The verbose/debugging output is up top.

[propilideno]

@marco @saintaardvark sorry for the delay, I was finalizing my undergraduate thesis and had very limited time recently.

Root cause: after #75, single-role profiles were incorrectly routed through GetSessionToken + AssumeRole (chained MFA), which triggered AWS’s 1-hour role-chaining limit and broke passing session duration.

This is fixed in #87, which now correctly distinguishes real role chaining from normal profile topology, so non-chained role logins keep the expected duration.

[mbevc1]

@propilideno have you pushed your changes. I've replied in the PR, but cannot see anything new there? 🤔