AWS Security ChangesHomeSearch

AWS systems-manager: Document GetParametersByPath path-scoped authorization risks

Service: systems-manager · 2026-09-27 · Documentation medium

File: systems-manager/latest/userguide/what-is-a-parameter.md · Type: authz

Summary

Rewrites the explanation of how Parameter Store authorizes GetParametersByPath so that authorization applies to the requested path rather than each returned parameter. Adds explicit warning that a caller authorized for /a gets everything beneath it, including /a/b, even when another policy explicitly denies /a/b elsewhere, and provides mitigation instructions to deny ssm:GetParametersByPath on every ancestor path (for example /a and /) along with a link to Restricting access to specific parameters and paths.

Security assessment

This edit does not fix a product defect or reference a disclosed advisory/CVE; instead it improves accuracy of existing behavioral documentation and adds defensive IAM guidance. Because authorization is evaluated only against the supplied path, principals granted broad-path access inherit effective read rights over descendants regardless of narrower explicit denies, enabling unintended disclosure of sensitive parameters such as SecureStrings unless administrators add matching denies on ancestor paths. Documenting this least-privilege pattern reduces misconfiguration-driven credential exposure.

Evidence

+Parameter Store authorizes the `GetParametersByPath` operation against the path that you specify in the request, not against each parameter that the operation returns.

Diff

diff --git a/systems-manager/latest/userguide/what-is-a-parameter.md b/systems-manager/latest/userguide/what-is-a-parameter.md
index 49ad72675..065d970ff 100644
--- a//systems-manager/latest/userguide/what-is-a-parameter.md
+++ b//systems-manager/latest/userguide/what-is-a-parameter.md
@@ -183 +183,5 @@ Attempting to create the following parameter would fail with a `HierarchyLevelLi
-If a user has access to a path, then the user can access all levels of that path. For example, if a user has permission to access path `/a`, then the user can also access `/a/b`. Even if a user has explicitly been denied access in AWS Identity and Access Management (IAM) for parameter `/a/b`, they can still call the [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html) API operation recursively for `/a` and view `/a/b`.
+Parameter Store authorizes the `GetParametersByPath` operation against the path that you specify in the request, not against each parameter that the operation returns. A principal who is allowed to call `GetParametersByPath` for the path `/a` receives every parameter under that path, including `/a/b`. This is true even if the same policy explicitly denies access to `/a/b` for other actions.
+
+To prevent a parameter from being returned by `GetParametersByPath`, deny the `ssm:GetParametersByPath` action on every ancestor path that could include the parameter in its results. For example, to prevent `/a/b` from being returned, deny `ssm:GetParametersByPath` for both `/a` and `/`.
+
+For guidance on writing IAM policies that account for this behavior, see [Restricting access to specific parameters and paths](./ps-restrict-parameter-access.html).