A Virtual Engineering Workbench template could run as its publisher

Publishing a development environment to a catalog sounds like filing a recipe for someone else to use. In the Virtual Engineering Workbench flaw AWS disclosed on November 2, 2026, the publishing step could do far more. CVE-2026-119085 can let a remote, authenticated actor submit a crafted template and run code with the permissions of the AWS Lambda function that publishes product versions. [1]

The publisher acts before a developer launches anything

Virtual Engineering Workbench is an open source platform that lets platform engineers define development environments and publish them for other developers to start through a portal. A catalog entry can describe a workbench with its tools and targets. The problem AWS describes is in the service that prepares a product version for the catalog. It is reachable through a CloudFormation template body sent to the product versioning API. [1] [3]

Think of a template engine as software that fills in blanks and can also interpret certain instructions. That is useful for a publisher inserting a product name or version. The risk comes when a template supplied through the API can cause the engine to evaluate instructions that the submitter was never meant to run. In this case, AWS says the code would run on the server under the publishing function's role. [1] [2]

The role is the important part. AWS Identity and Access Management gives a Lambda function an execution role that determines which AWS resources it can access and which actions it can take. AWS says this issue could expose data and resources across tenant projects. The actual reach would depend on the publishing role's permissions and the resources it can access. The advisory concerns this open source application and its publishing path. [1] [4]

In a hypothetical shared catalog, one team may be allowed to edit the environment it publishes, while the central publisher needs to work across several projects. If the team's template can run code as that publisher, the permission to update one catalog entry can lead to a much broader set of actions. A person might only see an edit button in the portal; the backend can be holding a much larger set of keys.

The May fix has to reach the running publisher

AWS identifies all commits before c146486 as affected. The fix was merged on May 4, 2026, months before the advisory. The change rejects Jinja control sequences in submitted template definitions and uses a restricted Jinja environment in the publishing handler's machine image path. AWS recommends redeploying from the latest main branch and making sure forks and derivatives include the changes. [1] [2]

AWS says there is no workaround that removes the issue. It advises limiting who can create or update product versions while a redeployment is pending. Reducing those permissions narrows who can reach the affected path. It also makes sense to check what the publishing role actually needs: limiting the resources available to the function reduces the consequences of errors in that part of the application. [1] [4]

For an operator, the useful version is the one that built the deployed publishing function. A patched checkout can sit beside an older deployment, and a fork can have a newer date without carrying a particular change. A deployment record that ties the running code to a reviewed revision answers more than a screenshot of an up to date repository.

Test the catalog from both sides of the boundary

Our takeaway for the hypothetical catalog team is to include publishing in its tenant isolation checks. A normal template still needs to produce a workbench that a developer can launch. The team also needs evidence that a product author cannot make the publisher act outside the intended boundary. A successful launch answers the first question. It gives you little evidence about the second.

The bulletin describes a possible path across projects, not a report that any particular tenant was reached. For a team assessing its deployment, the three useful facts are who could submit product versions, which publisher revision handled them, and what that function's role could reach. Together they tell a clearer story than the version date alone. [1] [2] [4]