Invalid security token in request

[jcitalan]

[Bug] S3 authentication regression in Cyberduck 9.3.1 (44136)

Summary

Cyberduck 9.3.1 (44136) fails to list or access S3 buckets using valid AWS Access Key / Secret Key credentials. Downgrading to 9.2.4 resolves the issue immediately without any configuration changes, confirming a version-specific regression.

---

Environment

Field	Value
OS	macOS 15.7.3
Cyberduck	9.3.1 (44136)
Auth method	Access Key + Secret Key
Endpoint	s3.amazonaws.com
Region	us-east-1
STS / AssumeRole	Not used

---

Steps to reproduce

1. Install Cyberduck 9.3.1 (44136)
2. Create a new S3 connection using standard Access Key + Secret Key
3. Set endpoint to s3.amazonaws.com
4. Attempt to list buckets or open an existing bucket

Expected: Buckets list normally and are accessible.

Actual: Connection fails — buckets are not listed and cannot be accessed.

---

Verification

The same credentials work correctly in all of the following:

• AWS CLI — aws s3 ls --profile <profile> succeeds
• Cyberduck 9.2.4 — full bucket access after downgrade, zero config changes
• Another macOS machine — same credentials with Cyberduck 9.2.4, no issues

---

Screenshots

First screenshot: initial login attempt. Second screenshot: error shown when retrying the connection without re-entering credentials.

Notes

• The issue is deterministic — it occurs on every attempt with 9.3.1 and never with 9.2.4.
• This suggests a regression in the S3 authentication or request signing flow introduced in the 9.3.x release line.

[dkocher]

Please include the transcript from the log ouput.

[jcitalan]

Cyberduck S3 Connection Issue Investigation

Log Files

No relevant output was written to cyberduck.log.

According to the documentation:

Log output can be found in the cyberduck.log file in
~/Library/Logs/Cyberduck
Select Show in Cyberduck → Preferences → Connection to reveal the log file.

However, in this case nothing was written there during the failing attempts.

Transcript Capture

Instead, I captured the HTTP transcript using:

log stream --predicate '(process == "Cyberduck") && (category == "transcript")' --level info

This successfully logged the request/response flow. I am attaching:

• cyberduck_transcript.txt → Cyberduck 9.3.1 (09 Dec 2025) — failing version

• cyberduck_transcript_v9.2.4.txt → Cyberduck 9.2.4 — working version

Observed Difference Between Versions

9.3.1 (Failing)

Initial request:

GET / HTTP/1.1
Host: s3.amazonaws.com

Response:

HTTP/1.1 307 Temporary Redirect
Location: https://aws.amazon.com/s3/

Cyberduck then follows the redirect and performs:

GET /s3/ HTTP/1.1
Host: aws.amazon.com

Response:

HTTP/1.1 200 OK
Content-Type: text/html

This results in an HTML response from the AWS website instead of an XML response from Amazon S3.

9.2.4 (Working)

Initial request:

GET / HTTP/1.1
Host: s3.amazonaws.com  

Response:

HTTP/1.1 200 OK
Content-Type: application/xml
Server: AmazonS3

The expected XML response is returned and buckets are listed correctly.

Observation

The only change between tests:

• Same macOS version
• Same credentials
• Same endpoint
• Same network
• Same IAM configuration
• Only Cyberduck version differs

9.2.4 receives a proper XML response from Amazon S3.
9.3.1 receives a 307 redirect to aws.amazon.com/s3/ and follows it, leading to an HTML page.

This may indicate a change in how redirects or S3 endpoint resolution are handled in 9.3.x.

I am not certain whether this is related to recent internal changes, but the behavior difference is reproducible and version-specific.

[dkocher]

Can you enable the Debug option for the log output in Preferences → Connection and provide cyberduck.log.

[dkocher]

The 307 Temporary Redirect response is caused by the request missing Authorization.