Describe the bug
A Server-Side Request Forgery (SSRF) vulnerability exists in the storage configuration feature. By specifying a custom S3 endpoint, an attacker can make the backend server initiate requests to arbitrary URLs, including attacker-controlled or internal network addresses. This can lead to sensitive data exposure, internal network access, or further exploitation.

To Reproduce

1. Go to your project, then navigate to:
   Project Settings → Cloud Storage → Add Storage
2. Select S3 as the storage type.
3. Fill in the form with the following data:
   • Storage Title: test-ssrf
   • Bucket Name: dummy-bucket
   • Bucket Prefix: test/
   • Region Name: us-east-1
   • S3 Endpoint: https://webhook.site/<your-unique-id>
   • Access Key ID: AKIAFAKEKEY123456
   • Secret Access Key: fakeSecretKey987654321
   • (Leave Session Token blank)
   • Leave “Use pre-signed URLs” checked and Expiration at 60 minutes.
4. Submit the form.
5. Observe on your webhook.site dashboard that the backend server makes a request to your URL, including AWS-style headers and your dummy credentials.

Expected behavior
The backend should only connect to trusted, allow-listed S3 endpoints. User-supplied endpoints should not be used for backend requests without strict validation, to prevent SSRF.

Screenshots

• Screenshot of the storage configuration form with the malicious S3 endpoint.

The error message confirms the backend attempted to connect to the attacker-controlled endpoint and tried to parse the response as S3 XML. This demonstrates the SSRF vector is exploitable.

• Screenshot of the created storage entry in the UI.

• Screenshot of the webhook.site request details (headers, user-agent, query params).

Desktop (please complete the following information):

• OS: macOS 14.3 (Sonoma)
• Browser: Brave, Chrome
• Version: 125.0.6422.113

Smartphone (please complete the following information):

• Device: N/A
• OS: N/A
• Browser: N/A
• Version: N/A

Additional context

• This SSRF allows an attacker to make the backend connect to arbitrary URLs, including internal resources (e.g., AWS metadata endpoint).
• If the backend is running in a cloud environment, this could lead to credential theft or further compromise.
• Severity: High (potentially Critical if internal data is accessible).
• Recommendation: Validate and restrict the S3 endpoint field to trusted domains only.
• -The error message is expected, as the backend receives non-S3 XML from the attacker-controlled endpoint. The core risk is the backend’s willingness to connect to arbitrary URLs