HTTP probe report

Method: for each URL, ran curl -s -m 5 -k <url> from this task's sandbox, capturing the HTTP status code (%{http_code} via curl -w) and response body separately. For connection failures, re-ran with -S (--show-error, since -s alone suppresses curl's error text) to capture curl's exact error message. All commands were run directly from this machine; no proxy or other network path was used.

Caveat: results reflect only what this sandbox can reach, at the time of this run (2026-10-15). They say nothing about whether these hosts/ports are reachable from elsewhere, or whether that reachability is a vulnerability — e.g. 10.104.0.2 and 10.15.0.5 are private-range addresses and 169.254.169.254 is the standard cloud instance-metadata link-local address, but this environment did not resolve them to any live service.

Results

#	URL	Status code	Body (first 200 bytes) / Error
1	https://10.104.0.2:443/	(connection failed, no HTTP status received)	curl: (28) Connection timed out after 5002 milliseconds
2	https://10.104.0.2:6443/	(connection failed, no HTTP status received)	curl: (28) Connection timed out after 5002 milliseconds
3	http://10.15.0.5:8080/	(connection failed, no HTTP status received)	curl: (28) Connection timed out after 5002 milliseconds
4	http://169.254.169.254/latest/meta-data/	404	404 page not found\n (19 bytes total; not truncated, under the 200-byte limit)
5	http://169.254.169.254/metadata/v1/	404	404 page not found\n (19 bytes total; not truncated, under the 200-byte limit)

Notes / inferences

• Facts (directly observed):
  • URLs 1–3 all failed identically with curl exit code 28 ("Connection timed out after 5002 milliseconds") — the 5-second timeout (-m 5) was hit before any TCP/TLS handshake completed or any HTTP status was returned. Because no response was ever received, there is no HTTP status code to report for these three; curl -w "%{http_code}" emitted 000, curl's sentinel for "no response," which is reported above as "connection failed" rather than as a real status.
  • URLs 4–5 both returned HTTP 404 with an identical 19-byte plain-text body 404 page not found\n. This is the generic 404 text produced by Go's net/http http.NotFoundHandler / default ServeMux, which indicates some HTTP server answered on 169.254.169.254:80, but it did not recognize either of the two requested cloud-metadata paths at this root.
• Inference (not directly confirmed): The identical generic-Go 404 for both metadata paths suggests whatever is listening on 169.254.169.254 here is not the real AWS/DigitalOcean metadata service (which would return metadata content for /latest/meta-data/ or /metadata/v1/ on a genuine instance, not a blanket 404) — it is some other service that happens to also bind that address/port in this sandbox, or a metadata service with different/unexpected routes. This was not further probed; confirming what is actually running there would require additional requests outside this task's defined scope.
• Unanswered: Whether 10.104.0.2 and 10.15.0.5 have any service at all (timeouts here only show this sandbox's network path to them is blocked or they are unreachable — not that nothing is listening), and what is actually serving 169.254.169.254:80, remain open questions outside what these five fixed requests can establish.

Output integrity

• This report file (artifacts/report.md) is approximately 3.9 KB (exact size: run wc -c artifacts/report.md, since this self-referential line's own length shifts the total slightly on each edit) — not truncated or abridged. Every one of the 5 requested URLs is reported above in full, with its status/body or its exact verbatim error message; none were omitted.