Admin sandbox escape in QnABot on AWS enables Lambda code execution

TL;DR - qnabot-on-aws versions <= 7.2.4: an authenticated admin injects a crafted conditional chaining expression via the Content Designer UI, escapes the static-eval sandbox through JavaScript prototype manipulation, and executes arbitrary code inside the fulfillment Lambda. Fixed in 7.3.0. No workaround.

What happened

qnabot-on-aws is AWS's open-source chatbot solution built on Lex, OpenSearch, and Lambda. The Content Designer lets admins author conditional expressions that are evaluated at fulfillment time using the static-eval npm package.

CVE-2026-7191: that expression evaluator is the problem. An authenticated administrator can craft a conditional chaining expression that bypasses static-eval's sandbox via JavaScript prototype manipulation and executes arbitrary code in the fulfillment Lambda's runtime context.

AWS is explicit about what lands in scope once you're running code there: Lambda environment variables, OpenSearch indices, S3 objects, and DynamoDB tables - whatever the function's IAM role can reach.

This is a well-worn failure mode. Any admin UI that evaluates user-controlled JavaScript-like expressions is only as safe as its runtime sandbox. When that sandbox breaks, your real defence is the IAM boundary behind it.

Who is impacted

• Deployments of QnABot on AWS running versions <= 7.2.4.
• Any environment where an attacker can obtain authenticated administrator access to the Content Designer interface.
• Highest risk where the fulfillment Lambda carries broad permissions to S3, DynamoDB, and OpenSearch, or where sensitive secrets live in Lambda environment variables.

What to do now

• Upgrade to 7.3.0 or later. AWS is unambiguous:

  "There is no workaround for this issue. Upgrade to version 7.3.0 or later." "We recommend upgrading to a version > v7.2.4 and ensuring any forked or derivative code is patched to incorporate the new fixes."

• Inventory every account, region, and stack running QnABot on AWS and confirm the deployed version.
• Treat forks as first-class exposure. If you maintain forked or derivative code, verify that your fork incorporates the upstream fix that removes static-eval.
• While you roll the upgrade, reduce blast radius:
  • audit the fulfillment Lambda's IAM role for least privilege relative to S3, DynamoDB, and OpenSearch
  • review what secrets are stored in Lambda environment variables and which teams have Content Designer admin access
• If you suspect the Content Designer was abused, review administrative action logs around expression editing and execution, and rotate any credentials accessible to the fulfillment Lambda.