fix(SEC-446): disable Mercury recipes behind LD kill-switch

@anshugarg15checks n/achecks…sec-446-disable-mercury-recipes → production4 files · +56 −1updated 1w ago

▸Description · 2 noise

Description

[SEC-446] Recipe create/parse and execution both funnel into Mercury, which loads and runs user-supplied Python via exec() (mercury/parsers/recipe_parser.py parse_recipe, and the recipe bundle load + execute() in execute_recipe). This is arbitrary code execution in the Mercury runtime, reachable by any project API key — no admin, no feature flag, no allowlist today. It is not meaningfully sandboxed on this path.

This PR turns the feature off platform-wide via a new LaunchDarkly kill-switch while the parser/execution is hardened (static-AST schema extraction + routing execution through the isolated sandbox). No deploy needed to re-enable later.

Change: new LD flag mercuryRecipesEnabled ("Mercury Recipes Enabled"), global context, default false (fail-closed) — LD outage or unset flag keeps recipes disabled. Gated at every Apollo chokepoint that reaches Mercury:

parse_recipe (create/parse):

UpsertRecipeAction.execute — covers POST /api/v3/recipes/upsert + COMPOSIO_UPSERT_RECIPE / COMPOSIO_CREATE_UPDATE_RECIPE. (Sole caller of thermos.upsertRecipe.)

execute_recipe (execution) — two distinct code paths, both gated:

executeRecipe() in recipe_execution/ — tool-router / MCP path: RecipeExecutable, COMPOSIO_EXECUTE_RECIPE, and recipes/execute/{slug}.
execute_tool.ts direct path — POST /api/v3(.1)/tools/execute/{slug} calls thermos.executeTool({ tool_type: Recipe }) directly, NOT through executeRecipe(). Gated when tool_type === ExecutableType.Recipe. (This was missed in the first commit and added in the follow-up — without it the primary REST execute path stayed open.)

After this, both thermos.executeTool call sites and the sole thermos.upsertRecipe caller are behind the flag. When off, callers get a clean Recipe creation/execution is disabled error (no 500). Flip the flag to true in LD to re-enable.

Out of scope / intentionally untouched: the legacy recipe/[nanoId] path (CreateRecipeAction + recipe/execute.ts), which validates via Mercury ast_parse_function_calls (static AST, no exec) and executes in the sandbox — not part of the RCE surface. Read-only list/get endpoints are unaffected.

Note: there is currently low but non-zero production traffic on this path (observed a live parse_recipe invocation from a project API key), so this is a real exposure, not dead code.

How did I test this PR

oxlint clean on all changed files (0 warnings / 0 errors).
Enumerated every Mercury-bound recipe sink and confirmed each is gated: thermos.upsertRecipe (1 caller: UpsertRecipeAction), thermos.executeTool (2 callers: execute_tool.ts direct path + executeRecipe). No un-gated path to parse_recipe / execute_recipe remains.
Confirmed flag is fail-closed: isMercuryRecipesEnabled() returns false when the LD client is uninitialized (matches existing booleanFlag default behavior), so recipes stay disabled on LD outage/unset.
Types: early-return Err(...) values reuse error constructors already valid in each function's return union (RecipeError.InvalidRequest / RecipeError.BadRequestError, both createErrorClass(Error_400, ...)).
Post-merge: create the mercuryRecipesEnabled flag in LaunchDarkly (default OFF) before/with rollout.

🤖 Generated with Claude Code

▸ 2 bot/status comments hidden

@linear-code[bot]1w ago

Bug F2 — RCE via parse_recipe AST-filter bypass

Asset: Mercury (tool-execution lambda) — mercury/parsers/recipe_parser.py:148-203. Pre-prod local target (make run-lambda :8000), production-equivalent code path. Found during authorized internal CISO-led security audit; confirmed locally on commit 16e9b9c48d of master. Severity: Critical (P0) Bug Class: Remote Code Execution Verified: Yes — marker file /tmp/mercury_rce_F2 written by the Mercury process at 2026-05-08 14:03 IST.

Description

Mercury's POST / endpoint accepts a parse_recipe op that calls _extract_model_schemas at mercury/parsers/recipe_parser.py:148. The function uses an AST filter to keep only ClassDef nodes whose base is BaseModel or Enum, then calls exec(models_code, namespace) at line 176. The filter is bypassable because Python evaluates class-body default-arg expressions during exec(). An attacker stashes arbitrary code inside a default-value expression on a BaseModel field — the AST filter sees a benign ClassDef, but exec() runs the side-effect when constructing the class.

The FastAPI endpoint at mercury/serverless/api.py:9 has no auth. Any unauthenticated caller who can reach the lambda HTTP URL gets arbitrary Python execution. Same blast radius as F1 (full os.environ exfil in real Lambda).

How to replicate

From the mercury repo, start the local lambda server: source .venv/bin/activate && make run-lambda.
POST audit/repros/F2_rce_recipe.json to http://localhost:8000/. The envelope contains a BaseModel subclass with a default-arg expression that opens /tmp/mercury_rce_F2 for write.
Verify side-effect: ls /tmp/mercury_rce_F2 and cat /tmp/mercury_rce_F2 — file exists, contents .

loading diff…

@linear-code[bot]1w ago

Bug F2 — RCE via parse_recipe AST-filter bypass

Description

How to replicate

From the mercury repo, start the local lambda server: source .venv/bin/activate && make run-lambda.
POST audit/repros/F2_rce_recipe.json to http://localhost:8000/. The envelope contains a BaseModel subclass with a default-arg expression that opens /tmp/mercury_rce_F2 for write.
Verify side-effect: ls /tmp/mercury_rce_F2 and cat /tmp/mercury_rce_F2 — file exists, contents .

fix(SEC-446): disable Mercury recipes behind LD kill-switch

Description

How did I test this PR

Bug F2 — RCE via parse_recipe AST-filter bypass

Description

How to replicate

Description

How did I test this PR

Bug F2 — RCE via parse_recipe AST-filter bypass

Description

How to replicate

Proof of concept

Impact

Affected codebase files

Suggested patch direction

Parent / Related

OpenAPI Changelog (Production)

❌ Breaking changes