Find exposed DevOps config files

Overview

A 200 on /.docker/config.json is often the site's front end, not a Docker config. This workflow enumerates hosts and requests paths that hold Terraform state, Docker auth, npm tokens, and netrc entries. It keeps a hit only when the body is that file. Terraform state must look like state JSON. Docker config must contain an auth map. The check does not use the credentials it finds. Point it at a domain you are authorised to test, and treat a confirmed file as a secret exposure for exposure management.

Pipeline

1. subfinder enumerates hosts for the domain you set.
2. httpx probes those hosts.
3. secrets, terraform, and cicd request known paths, on at most 80 hosts. A hit requires the body to be that file.
4. report writes findings.jsonl, one row per confirmed file, plus a summary.

Inputs

• Domain. Set on the subfinder node. Hosts come from that enumeration.

Outputs

• findings.jsonl. One JSON line per confirmed config file, plus a summary.

Integrations

• Subfinder. Host enumeration.
• httpx. HTTP probe of the enumerated hosts.

Sample output

The line below is the summary from a completed run on brokencrystals.com on 2026-09-24. Fifty-seven hosts were scanned. No config file was confirmed.

kind	hosts_scanned	exposed_configs	critical	high	scanned_at
summary	57	0	0	0	2026-09-24T10:13:35Z

FAQ

Does a hit include the secret itself?

The row records that the file was confirmed. Do not paste recovered credentials into the ticket.

Why require file content?

A bare HTTP 200 is how a single-page app answers unknown paths.

How many hosts are checked?

At most 80 hosts from the subfinder output.

Where should I run it?

On a domain you are authorised to test.

Related workflows

• GitHub Secret Scanner. Reach for this when the credential is committed in a repository rather than served on a host.
• Cloud Bucket Finder. Reach for this when the config is sitting in object storage rather than on a web root.