Build1 publisherNot yet confirmed elsewhere2 min readPublished
Seven calls to a secret, with zero Secrets Manager permissions on paper
A CloudGoat walkthrough moves an API key through SNS into API Gateway and back out of Lambda. Access Analyzer and PMapper both report the user has no access.
The Engineer · Build desk

What happened
- A 2025 CloudGoat walkthrough shows an IAM user with no Secrets Manager permissions retrieving a secret in seven API calls.
- The route: an SNS topic publishes an API Gateway key, the user subscribes and reads it, and the gateway's Lambda integration returns the secret as the HTTP body.
- The topic carries no resource policy, so the user's own sns:Subscribe on Resource "*" is the only gate on subscription.
- A Z3 run over 24 API Gateway management paths finds 21 still reachable despite seven carefully chosen deny patterns.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A review that asks which principals can call secretsmanager:GetSecretValue will keep answering correctly and uselessly, because the link between the services is a value in a payload and not a...
- decision Path-by-path denial on apigateway:GET is the wrong shape to bet on; the reconnaissance an attacker actually needs sits on the mundane paths nobody thought to name.
- precedent Controls that only read resource policies will keep coming back clean, which pushes the work into asset inventory: what a channel carries has to be a recorded field, not a reviewer's assumption.
A permission graph is assembled from edges that policies name. IAM Access Analyzer and PMapper both report that the IAM user cannot read any secret in the account [4], and on the evidence those tools consume they are correct: nothing grants that user Secrets Manager access [3], and no statement anywhere joins SNS to Secrets Manager [7]. The join is an API key sitting in a message payload [6]. A key in a payload is data, and data is not an edge, so there is no node to traverse and the answer comes back clean.
The deny list is the part worth studying, because it is what a careful reviewer actually produces. The user's policy allows `apigateway:GET` on `Resource: "*"` and then denies it on seven specific patterns covering API keys, method bodies and integration internals [8]. Run those seven patterns against the 24 management paths the prover walks, and 21 stay reachable [13]: three blocked [15], which leaves 87.5 percent of the enumerated surface open [16]. The paths that matter are among the open ones. `/restapis` lists the API IDs, `/restapis/{id}/resources` lists the paths, `/restapis/{id}/stages` lists the stages, and with those three the attacker has the full URL [14]. Three calls of reconnaissance against a documented chain of seven [17]. The integration body, the thing the deny list did protect, was never on the route.
The result is awkward for the tooling that produced it. Stave's existing broad-subscribe control inspects the topic's resource policy [2], and this topic has no resource policy, which in AWS leaves the identity policy as the sole gate [9]. A control that reads resource policies has nothing to read. The SAT verdict came instead from three facts held together: the identity policy, the missing topic policy, and an annotation on the asset recording that the topic publishes an `api_key` [1], with the witness naming both the topic and the REST API the key targets [12].
One synthetic CloudGoat user in one lab account is not a fleet [18], and the modelling work here is a prover run over a writeup, not a survey of production estates [11]. What generalises is narrower and more useful than a new attack class: the grant that ends up exercised is the Lambda execution role [10], written for the function, and it becomes the effective permission set of whoever can obtain the key that fronts it. Nothing in the four service configurations is misconfigured by its own checklist [7]. The defect is the pairing of a subscribable channel with a payload that carries authentication material, and no per-service review has a place to record that pairing.
What to watch
- Whether the four queries against the remediated configuration all return UNSAT; the writeup reports only the four against the vulnerable version.
- Whether Stave reshapes its broad-subscribe control into an identity-policy-plus-annotation check instead of a resource-policy check.
- Whether anyone reproduces the seven-call chain outside the CloudGoat lab account, on a real estate with real topics.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence52
- Adoption
- Insufficient
- Hype gap+34
- Incentives72
- Confidence46
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The data-flow annotation publishes_credential_type=api_key on the topic asset is what makes this a security concern rather than a subscription pattern concern.
- [2]
Stave's existing broad-subscribe control checks the topic's resource policy, whereas this issue lives in the IAM identity policy plus the absence of a topic policy plus the data-flow fact about what the topic publishes.
- [3]
The synthetic IAM user cg-sns-user-cgidxi93qpes3g has zero permissions on Secrets Manager.
- [4]
Run through IAM Access Analyzer, and again through PMapper, the identity is confirmed to have no access: the IAM user cannot read any secret in the account.
- [6]
The chain runs through four services: SNS publishes an API key as a message payload, the user subscribes to the topic and receives the key, the key authenticates to an API Gateway, the gateway's Lambda integration reads from Secrets Manager, and the secret comes back as the HTTP response body.
- [7]
No policy connects SNS to Secrets Manager; the connection is the credential value itself, every step is individually authorized, and the compound chain is invisible to any tool that checks permissions service-by-service.
- [8]
The IAM user policy allows sns:Subscribe, sns:Receive, sns:ListTopics and apigateway:GET on Resource "*", and denies apigateway:GET on seven specific patterns covering /apikeys, method GET paths and integration paths.
- [9]
The SNS topic public-topic-cgidxi93qpes3g has no topic policy, and in AWS the IAM identity policy is the only gate when no topic policy is configured.
- [10]
The API Gateway uses API key only authentication with no IAM, Cognito or Lambda authorizer, its integration is Lambda, and the Lambda reads the target secret in Secrets Manager via its execution role, described as the standard pattern.
- [11]
A Z3 prover in stave/examples/sns-secrets-compound-chain/z3prove/ runs four queries against the writeup configuration and four against a remediated version.
- [12]
Finding 1 returns verdict SAT with witness arn:aws:sns:us-east-1:676206926638:public-topic-cgidxi93qpes3g, which publishes api_key targeting arn:aws:apigateway:us-east-1::/restapis/x93anl9mj7; subscribable plus sensitive topics scored 1 of 1.
- [13]
Z3 walks 24 known API Gateway management paths and finds 21 of them reachable under the user's allow-plus-deny policy.
- [14]
The coverage analysis marks the integration path BLOCKED while /restapis, /restapis/{id}, /restapis/{id}/resources, /restapis/{id}/stages, /restapis/{id}/deployments, /restapis/{id}/models and /restapis/{id}/authorizers are OPEN; with the /restapis, /restapis/{id}/stages and /restapis/{id}/resources calls the attacker has the full URL.
- [15]
Three of the 24 enumerated API Gateway management paths are blocked by the seven deny patterns.
- [16]
87.5 percent of the enumerated API Gateway management surface remains reachable after the deny list is applied.
- [17]
URL discovery takes three calls, against a documented full chain length of seven calls.
- [18]
A 2025 CloudGoat walkthrough by VirajMathpati documents a privilege escalation that, according to the dev.to analysis, no permission-based scanner catches.
ReportedInsufficientSource: dev.to analysis of a CloudGoat walkthrough by VirajMathpati2 sources— create a free account to open themView cited source
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toZero Permissions on Secrets Manager. Full Access to Your Secrets.
1 article · August 24, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
Entities
- StaveFollow
- CloudGoatFollow
- Z3Follow
- IAM Access AnalyzerFollow
- PMapperFollow
- Amazon SNSFollow
- Amazon API GatewayFollow
- AWS LambdaFollow
- AWS Secrets ManagerFollow
- Amazon Web ServicesFollow
- VirajMathpatiFollow