Individual skill

cloud-s3-exposure

Find and prove misconfigured cloud object storage (S3/GCS/Azure Blob). Load when assets load from *.s3.amazonaws.com, storage.googleapis.com, *.blob.core.windows.net, bucket-looking hostnames, or "bucket". Signals: public-read/list, unauthenticated writes, predictable bucket names.

skills/cloud/cloud-s3-exposure/SKILL.md

Read pinned source

Source commit ee0e0c50d2f6d941a14b73dd85a2b470d0ab976e

What was checked

Matches the observed repository HEAD: Yes
Scanner rules are current: No
Repository scan complete: No
Skill scan complete: Yes
Observed behavior: Not checked yet
Last checked: Nov 7, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings): 27
Repository last updated: Oct 14, 2026
License: MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

agent-skills Repository topic
ai-agents Repository topic
ai-security Repository topic
application-security Repository topic
blue-team Repository topic
bug-bounty Repository topic
claude-code Repository topic
codex Repository topic
detection-engineering Repository topic
gemini Repository topic
engineering Derived category

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files

SKILL.mdcore · 2,334 bytes
detection.mddoc · 3,218 bytes

Read excerpt


# Cloud object-storage misconfiguration

## When it applies
The app stores files in S3/GCS/Azure Blob and the bucket's ACL/policy is too open — public
listing, public read of private objects, or (worst) unauthenticated write.

## Why it works
Object-storage ACLs are easy to get wrong: "public" gets applied at the bucket level, or an
IAM policy grants `s3:ListBucket`/`GetObject`/`PutObject` to `*`. Predictable names
(`companyname-backups`, `-assets`, `-dev`) make discovery trivial.

## Method
1. **Find bucket names**: from asset URLs, JS, DNS CNAMEs, and permutations of the org name
   (`company`, `company-prod`, `company-backups`, region suffixes).