A REX setup example could run commands outside its sandbox

A setup example can leave behind a durable operational interface. On November 6, 2026, AWS disclosed CVE-2026-122193 in an example from the Trusted Remote Execution setup guide. The example created Systems Manager documents named Rex-RO and Rex-RW. A caller permitted to invoke those documents could supply input that ran unintended operating system commands on the managed instance, outside the intended REX sandbox. [1]

The wrapper handles input before the sandbox

REX is an open-source framework for sandboxed script execution on managed instances, using a signed Cedar policy as the intended security boundary around a run. The maintainer advisory says the example SSM documents mishandled caller-supplied parameters. It explicitly includes scriptArgs in the affected class of input. The vulnerability sits in the route used to launch the sandboxed work. [2]

The practical implication is easy to miss when reviewing an architecture diagram. A diagram may accurately show a restricted execution environment, while leaving its launcher as an unexamined arrow. Input still travels through that launcher before the intended workload begins. If a wrapper interprets it as an operating system command, the later sandbox policy cannot govern work that the wrapper has already started.

Imagine a hypothetical operations team giving an analyst permission to run a tightly bounded diagnostic script. The analyst’s intended authority is the diagnostic task. In this example, the vulnerable wrapper creates a separate path from invocation parameters to host commands. That changes the meaning of the permission the team thought it was granting. Reviewing only the script inside the sandbox would miss the earlier decision.

The response concerns documents created from the guide

AWS identifies the setup documentation example as the affected component. The example has been removed, and AWS recommends deleting documents created from it in every account and Region where it was run. The maintainer advisory says there is no artifact patch to apply and no workaround. The relevant deployment history is whether the example created the documents. [1] [2]

An SSM document defines actions Systems Manager performs on managed instances. AWS documents that custom documents are stored in the account and Region where they are created. They also have versions, with a default version that can change over time. That lifecycle explains why removing a web example and removing objects created from the example are separate operational events. [3]

For our hypothetical team, the useful inventory starts with its own document copies and the process that created them. A remembered test in one Region can be a clue to another account where the same setup was tried. An old experiment can be easy to overlook when the main deployment has moved on. Giving those copies an owner makes the vendor’s deletion guidance actionable.

The names Rex-RO and Rex-RW help locate what the example created. If an organization renamed or adapted a copy, our engineering interpretation is that it should review the inherited parameter handling as part of the same investigation. A new label alone says little about whether the original wrapper’s behavior survived. That review depends on the actual document content and its history.

Removing a document also changes an operational dependency

AWS’s custom-document deletion guidance describes selecting the document in Systems Manager and confirming its deletion. Applying the advisory in a working environment also requires understanding who still invokes that document. The hypothetical diagnostic team may have a scheduled job or a support procedure that refers to it. The application owner needs to account for that dependency while carrying out the vendor’s recommended removal. [4]

A useful outcome record would identify the affected copies, their accounts and Regions, the completed removal, and any callers that need a reviewed replacement path. It gives the next operator enough information to understand why an old procedure stopped working. Otherwise, a well-meaning maintenance change could recreate the same example from an archived internal note.

Our broader interpretation is that a copied setup script becomes maintained operational material as soon as people depend on what it creates. It needs an owner, a record of where it was applied and a way to find its descendants when guidance changes. The original guide may have taken minutes to follow. The generated objects can stay useful, and callable, long after everyone forgets the browser tab.

This advisory gives teams a reason to review the entire invocation path when promising bounded execution. The host launcher, parameter handling and sandbox each make decisions. A sensible acceptance review follows a request through those decisions and asks what authority each stage receives. For the withdrawn REX example, the published remedy begins with the SSM documents that the setup process left behind. [1] [2]