A transit engagement identifies server-side request forgery that can reach cloud instance metadata endpoints. How should impact be framed without exploit steps?
Select an answer to reveal the explanation.
Short Explanation
Tricking the server into asking the cloud "who am I?" can spill temporary keys — that is a big deal. SSRF to metadata is a critical impact class; describe the risk class, not a recipe. It is not a missing favicon and it is not a hardware-console requirement.
Full Explanation
When a transit engagement identifies server-side request forgery that can reach cloud instance metadata endpoints, impact should be framed as a critical class: metadata services may expose temporary credentials or instance identity material that enable further cloud compromise. Discuss impact classes without publishing exploit step recipes.
Calling SSRF-to-metadata cosmetic because metadata never holds credentials is incorrect for common cloud designs. Equating any SSRF to a missing favicon.ico trivializes severity. Metadata access does not imply the tester must pivot only via physical console cables.
Exam caveat: severity depends on reachability (link-local metadata, internal admin ports) and what credentials or services are exposed; not all SSRF is equal, but metadata reach is high impact.
Operational check: within RoE, demonstrate that the application server can be induced to request the metadata address or an agreed safe internal canary, capture proof of reachability, and stop short of abusing retrieved secrets beyond agreed evidence. Recommend egress controls and metadata hop limits for transit cloud workloads. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.