The Bucket Said Yes: A Severity Plot Twist

Target, program, hostnames, rewards, and customer data are redacted. The bounty card below is the receipt.

First bounty in Ramadan alhamdulilah. But there is a plot twist.

The bug: a misconfigured S3-compatible bucket with read and write permissions. Anyone could upload any file, potentially overwrite existing ones, host malicious payloads, etc. Basically a critical issue.

To demonstrate it, I uploaded a simple benign .txt file to avoid causing any defacement or overwriting existing files. Ethical hacker move and the norm in the industry to prove the issue.

curl -X PUT -d "bug bounty PoC" \
  "https://<bucket-endpoint>/web/poc.txt"

The server accepted it. Fetching the file back worked too. No auth, no signed URL, no token.

The response: thank you, this is a valid bug, however, since you only uploaded a .txt file this isn’t a critical issue! Let’s lower that down to Medium, basically a tenth of the deserved bounty.

Me: proceeds to show full potential impact. The same PUT accepts .html, .js, .svg — anything the bucket serves. however i found that the issue was quickly resolved and there is no way to show the full impact

The bounty card: €200, Medium 5.3, CWE-284.

Lesson learnt: sometimes wearing the blackhat to show impact is necessary. The finding is not “a text file exists.” The finding is “anonymous PUT is allowed.” The file type is a detail; the access control is the vulnerability.

Update: after arguing about severity, they acknowledged the risk but changed the narrative to the bucket hosting a third-party app’s data, so it stayed Medium. Time to move on I guess.

The fix: deny anonymous PutObject/DeleteObject, block public ACLs, require signed writes, serve user content from a separate domain with Content-Disposition: attachment and nosniff, and audit existing objects for unexpected HTML/JS.

Cheers!