AWS REX setup guide example left injectable SSM documents behind

What happened

AWS published security bulletin 2026-173-AWS on 11/06/2026 at 09:00 AM PST. It covers CVE-2026-122193, an OS command injection issue in an example from the set-up documentation for Trusted Remote Execution (REX). AWS rates the bulletin "Important (requires attention)". The bulletin also references GHSA-95g5-m242-wvhr.

REX is an open-source framework for running sandboxed scripts on managed instances. AWS describes a signed Cedar policy as "the immutable security boundary around each script run". The guide's example script created two Systems Manager documents, Rex-RO and Rex-RW, which run REX scripts on managed instances.

The flaw is in how the example script handled input parameters. A user with permission to invoke one of these SSM documents could supply crafted input that runs unintended operating system commands on the managed instance, outside the REX sandbox. AWS says the scriptArgs parameter has the same class of issue.

AWS states that no shipped REX artifact version is affected. The problem is the documentation example, and anyone who created Rex-RO or Rex-RW documents by following the guide is affected.

AWS says it has removed the example from the guide, and it recommends deleting any such SSM documents in each account and Region where the example was run. It lists no workarounds.

The AWS bulletin is the primary source. The NVD record lists a CVSS base score of 9.3 and has the status Received. NVD says the flaw might allow arbitrary commands to run as root on the managed instance, bypassing Cedar policy enforcement. Its description refers to the example provisioning script "before 2026-07-28".

Update: the GitHub advisory GHSA-95g5-m242-wvhr, published on 6 November 2026, corroborates the AWS account: the example SSM documents are the affected item, the example has been removed, there is no code patch and there are no workarounds. It repeats the remedy of deleting the documents per account and Region. It rates the issue Critical and shows a CVSS overall score of 9.9 with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, and classifies the weakness as CWE-78. Its package metadata lists rex-runner (Rust) with affected version 0.1.0 and patched version 0.1.0, while its text still says this "is not an issue in a shipped REX artifact version".

Why it matters

The point of REX is that a signed Cedar policy limits what a script run can do. This flaw sits in the delivery mechanism around that boundary. An invoker who can reach the SSM document gets commands on the host without passing through the sandbox. NVD says the flaw might allow commands to run as root. The "sandboxed remote execution" guarantee does not hold for anyone running the example documents.

The operational problem is detection. This is not a package or a release:

• npm ls, pip list, SBOMs, container scanners and version-based vulnerability tooling cannot see SSM documents in your accounts.
• GitHub's advisory metadata names rex-runner 0.1.0 as both affected and patched. Tooling that reads GitHub advisory data may flag that package. Such an alert says nothing about whether the SSM documents exist in your accounts, and a clean result does not clear you.
• There is no fixed version to upgrade to.
• Exposure is whatever SSM documents exist in your accounts, created by whoever copied the guide.
• Those documents persist after the guide changes. Removing the example from the documentation does nothing for documents already deployed.

Exposure is limited to organisations that adopted REX and used the guide's provisioning example; the sources give no adoption figures. Where REX was chosen, it was presumably chosen because remote execution on hosts was considered sensitive, so for affected organisations the impact is serious. If REX guards regulated workloads in your estate, the impact on audit and incident obligations is higher.

The severity labels now diverge. AWS rates the bulletin "Important" and publishes no score. GitHub rates it Critical with a CVSS overall score of 9.9 and a vector of network attack vector, low privileges required, no user interaction, changed scope and high impact on confidentiality, integrity and availability. NVD lists 9.3 on a record with status Received that may change. Scanners and dashboards may show 9.9, 9.3 or "Important" for the same CVE, and no source explains the difference. The action is the same whichever figure your tooling shows.

Engineering assessment

Our assessment: for any team that followed the REX setup guide, this is a high-priority cleanup that cannot be deferred to the next patch cycle, because there is no patch cycle. The fix is a manual inventory-and-delete exercise across every account and Region.

Exposure depends on who can invoke the documents, not on network reachability. The attacker must already hold permission to run the Rex-RO or Rex-RW document. That sounds limiting, but REX exists so that people with limited, policy-constrained rights can run scripts. The users granted invoke rights are likely to be the same people the Cedar policy was meant to constrain. If those permissions were scoped to operators, support staff or automation roles on the assumption that Cedar would contain them, those principals should be treated as having had host-level command execution. NVD says the flaw might allow commands to run as root. GitHub's changed-scope rating is consistent with this reading: the impact reaches beyond the component the invoker was meant to be confined to.

Multi-account and multi-Region sprawl is the real cost. AWS's instruction is explicitly per account and per Region. Organisations using AWS Organizations, landing zones or account vending may have replicated the example widely, sometimes through infrastructure-as-code that will recreate the documents on the next deploy. Deleting the documents without also removing them from Terraform, CloudFormation, CDK or bootstrap scripts will not hold.

There is also a gap in what AWS provides. Deleting the documents removes the exposure but leaves REX users without the provisioning path the guide gave them. None of the sources mentions a corrected example. Teams that still need REX must build their own SSM integration and should treat parameter handling as security-critical code. Cautiously: until AWS publishes a replacement, assume any home-grown wrapper needs independent security review.

The NVD "before 2026-07-28" wording does not align cleanly with AWS's statement that no versioned artifact is affected, and GitHub's rex-runner 0.1.0 metadata adds a second version-style signal that contradicts its own text. Do not use either the date or the package version to rule documents in or out. Documents created from the example at any time should be treated as affected unless you can show they were built differently.

Is this you?

• Has anyone in your organisation adopted AWS Trusted Remote Execution (REX)?
• Do any accounts contain self-owned SSM documents named Rex-RO or Rex-RW, or documents derived from them under another name?
• Did anyone run the REX setup guide's example provisioning script, or copy it into infrastructure-as-code, account baselines or bootstrap pipelines?
• Do any IAM principals hold permission to send commands with those documents, and were those permissions granted on the assumption that Cedar policies would constrain them?
• Do you operate multiple AWS accounts or Regions where the example may have been run separately?

If you answer yes to the second or third question, you are affected.

What to do

1. Inventory now, per account and per Region. List self-owned SSM documents and look for Rex-RO, Rex-RW or derivatives:
   • aws ssm list-documents --filters Key=Owner,Values=Self --region <region>
   • aws ssm describe-document --name Rex-RO --region <region>
   • Not vendor guidance: iterate over every enabled Region (aws ec2 describe-regions) and every account in your organisation, not just the ones you expect.
2. Delete affected documents. This is AWS's recommended remediation, repeated by NVD and the GitHub advisory: aws ssm delete-document --name Rex-RO --region <region>, and the same for Rex-RW, in each account and Region where the example was run.
3. Remove the source. Not vendor guidance: search IaC repositories, account-vending baselines and bootstrap scripts for the example script or these document names. Remove them so they are not recreated.
4. Review invoke permissions. Not vendor guidance: identify which principals could run these documents. Narrow any permissions that only existed to support them.
5. Look back. Not vendor guidance: if the documents existed, review Systems Manager command history and CloudTrail for their invocations, focusing on unusual parameter values in scriptArgs and other inputs. AWS gives no detection guidance. Treat hosts where invocations cannot be explained as needing incident review.
6. Plan the replacement. Not vendor guidance: technical leads should decide whether REX is still needed. If it is, treat every invoker-supplied parameter, including scriptArgs, as untrusted, never let it reach command execution unvalidated, and get the design reviewed before rollout.

For regulated estates in the UK, EU and Gulf, record the inventory results and deletions as evidence for your change and audit trail. See Enterprise Software Engineering for related context.

What we don't know yet

• Misuse: neither AWS, NVD nor the GitHub advisory addresses whether affected documents have been misused.
• Permissions: the sources do not say exactly which IAM permissions allow invocation or how broadly they are typically granted.
• NVD date: what "before 2026-07-28" in the NVD description refers to is unexplained, given AWS names no affected version or date.
• Package metadata: why the GitHub advisory lists rex-runner 0.1.0 as both affected and patched, while its text says no shipped artifact is affected and there is no code patch, is unexplained.
• Replacement: there is no word on a corrected example or supported provisioning method.
• Detection: the sources give no detection or forensic guidance.
• Score: GitHub shows a CVSS overall score of 9.9 (Critical), NVD lists 9.3 on a record with status Received that may change, and AWS publishes no score and rates the bulletin "Important". No source explains the difference.

The desk will check the AWS bulletin and the advisory GHSA-95g5-m242-wvhr for updates on a replacement example, detection guidance and the package metadata. It will also track the NVD record as analysis proceeds. More coverage is on the Engineering Desk news page.

Sources

• aws.amazon.com
• aws.amazon.com
• github.com
• NVD