Responsible disclosure - public S3 bucket exposing JSON/config files

How it was found

Hello Twitch Security Team,

My name is █████* and I can be reached at ████. I am reporting a potential information disclosure issue I discovered which appears to be related to a publicly-listable S3 bucket containing configuration and JSON files.

Summary (short): Publicly-listable S3 bucket (█████) returning an XML ListBucketResult with multiple JSON/config files (e.g., ███, ███████, ██████████). The bucket listing and file metadata are retrievable without authentication. See attached curl output for exact results.

Files observed (examples from the listing):

• ███████ (LastModified: ████07T19███)
• ████ (LastModified: █████07T19███████)
• █████, ███, ████████, ██████ (Full curl/█████████output attached).

Steps to reproduce:

1. From an internet-connected host, request the bucket listing (example command used to obtain attached output replace host if needed):

curl ███

2. The server responds with an S3 ListBucketResult XML containing Contents entries for multiple JSON/config files (see attached output).

Observed raw output: (See attached file curl/XML output showing ListBucketResult and the Contents entries).

████

Suggested severity: Medium (information disclosure).

• If the JSON files contain secrets or PII, severity rises to High/Critical. I have not inspected object contents beyond the listing; this report covers the fact that the bucket is listable/publicly discoverable. You may want to check the objects' contents for sensitive fields.

Recommended remediation / next steps:

1. Verify whether the bucket should be publicly listable. If not, restrict ListBucket permissions and require appropriate authentication (AWS IAM or presigned URLs) for object listing and retrieval.
2. Review object ACLs and S3 bucket policy; remove any Allow statements that permit anonymous s3:ListBucket or s3:GetObject if unintended.
3. Rotate any credentials/secrets found inside these files (if any) and perform an audit for exposure.
4. Consider adding a blocking rule for public indexing (e.g., block public access at account/bucket level) and implement least-privilege access.
5. If objects must be publicly available, ensure they contain no secrets or PII and consider serving through a hardened CDN and obfuscated paths rather than a listable bucket.

PGP / sensitive data: If you prefer to exchange the contents of sensitive files or any reproduction artifacts via encrypted email, please let me know and I will follow up with your PGP key or a secure channel.

Disclosure / recognition: I would appreciate recognition for this responsible disclosure. Please list me as ██████████ (that is my handle) if you include contributors in any acknowledgements.

Thank you for your time happy to provide any additional details (object contents I retrieved, timestamps, or full curl output) if you request them via a secure channel. Please let me know a case/ticket number or expected timeline for remediation if possible.

Best regards, ████* Handle: ████████ Email: ██████

Impact

Impact / Why this is a concern:

• The bucket exposes internal configuration and versioned JSON files which may leak internal API endpoints, configuration parameters, feature flags, or other operational details useful to an attacker.
• Filenames and timestamps (example: █████ last modified ██████████07T19████████) are visible which can help fingerprint versions and rollout timelines.
• Depending on the contents of these JSON files (if they contain credentials, tokens, or PII), the impact could be high. Even if files are only config/feature flags, that may still weaken security posture.