plaincve:~$

// threat brief

CVE-2026-108263

Astron Agent workflow code node runs without a sandbox: a low-privilege tenant can run code as root and reach other tenants' data

CVSS
9.9 CRITICAL
CISA KEV
Not listed
Weakness
CWE-95 · CWE-306 · CWE-653 · CWE-863 · CWE-1392
Topics
AI security

PlainCVE Team · Published 2026-10-12 · Updated 2026-10-13 · AI-assisted · Press brief ↓

AI review 2026-10-13 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

Astron Agent before 1.1.2 runs workflow code unsandboxed by default, letting a low-privilege tenant run code as root and reach other tenants' data.

Who is affectedOrganizations running iflytek Astron Agent before 1.1.2 (vendor wording: v1.1.1 and earlier when using the legacy unsandboxed local executor). Before 1.1.2 that executor is the default unless CODE_EXEC_TYPE was changed. Single-tenant deployments are affected too.
What happensA logged-in user with permission to create workflows can run arbitrary code as root inside the core-workflow container, then use shared service and database credentials to bypass tenant checks, read or modify other tenants' data, and disrupt shared services.
What to do nowUpgrade the deployment files and all service images together to v1.1.2; updating only the source checkout or only the workflow image is not a complete fix. The sources we reviewed list no vendor workaround other than upgrading.
Affected versionsBefore 1.1.2 (CVE record); vendor: v1.1.1 and earlier when using the legacy unsandboxed local executor
Fixed versionsv1.1.2 or later (deployment files and all service images must be updated together)
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Timeline
  • First public 2026-09-07

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check deployed image versions directly

    Where to run: on the Docker host that runs Astron Agent, as an account with docker permissions (read-only; it only lists containers on your own host and changes nothing). The vendor warns that automated vulnerability scanners may not flag this application-level issue; verify the deployed image versions explicitly. Any service still at v1.1.1 or earlier should be treated as affected.

    Read-only check
    docker ps --format '{{.Names}}\t{{.Image}}'
  2. 02Check whether the local executor is in use

    Where to run: on the deployment host, from inside the Astron Agent docker/astronAgent deployment directory (read-only; changes nothing). It searches the current directory and all subfolders, covering .env, docker-compose.yaml and config/workflow/config.env (the original report reproduced in the vendor advisory GHSA-mh3w-4q3f-2fg5 (that page contains exploit code, so PlainCVE does not link to it) says v1.1.1 sets CODE_EXEC_TYPE=local in that file). Before 1.1.2, if CODE_EXEC_TYPE is unset or set to local, the unsandboxed LocalExecutor is in use, so no matches does not mean you are safe: before 1.1.2 the code itself defaults to local.

    Read-only check
    grep -rn 'CODE_EXEC_TYPE' .
    Step 2Step 3
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Fully upgrade to v1.1.2

    Update the deployment files and all service images together; updating only the source checkout or only the workflow image is not a complete fix. In the sources we reviewed, the vendor lists no workaround besides upgrading; the mitigations on OpenCVE appear to be AI-generated, not vendor guidance.

    Step 2Step 3Step 4
  2. 02Remove CODE_EXEC_TYPE=local after upgrading

    Vendor: from v1.1.2, local is no longer supported; use the default isolated executor or a supported remote executor (E2B is optional).

    Step 2
RESPONDRespondIf you find signs of compromise
  1. 01Rotate shared service and database credentials

    PlainCVE suggestion (not vendor guidance): if you suspect someone ran code through a code node, rotate the shared credentials after upgrading, since an attacker could have obtained them, and check whether cross-tenant data was changed. No source confirms in-the-wild exploitation.

    Step 4
HARDENHardenPrevent the next one
  1. 01Keep nginx blocking the internal /workflow/v1 route

    The researchers say the bundled nginx rule is the only thing keeping this internal route from being an unauthenticated internet-facing path. PlainCVE suggests keeping it in place and watching for SSRF (server-side request forgery) issues that could reach the workflow service.

    Step 2
  2. 02Limit workflow-creation permission

    PlainCVE suggestion: the attack needs workflow-creation permission, so grant it only to accounts that truly need it.

    Step 1
Full remediation steps and notes
  1. Upgrade the deployment files and all service images to v1.1.2 together, then verify each one on the Docker host running Astron Agent (docker permissions required) with docker ps --format '{{.Names}}\t{{.Image}}'. The vendor warns that automated scanners may not flag this issue.
  2. After upgrading, remove any remaining CODE_EXEC_TYPE=local; use the default isolated executor (LangChain/Pyodide) or a supported remote executor. E2B is optional.
  3. v1.1.2 also strengthens authentication on internal Workflow and Tenant service APIs, tenant checks, credential handling and deployment isolation.
  4. In the sources we reviewed, the vendor lists no workaround besides upgrading; the mitigations on OpenCVE appear to be AI-generated, not vendor guidance.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

Astron Agent workflow code node runs without a sandbox: a low-privilege tenant can run code as root and reach other tenants' data: 1. Logs in with a low-privilege tenant account and creates a workflow with a code node → 2. With default settings, the platform picks LocalExecutor to run the code → 3. The code runs as root inside the core-workflow container → 4. Uses shared credentials to bypass tenant checks and read or modify other tenants' dataCVE-2026-108263 · Astron Agent workflow code node runs without a sandbox: a low-privilegetenant can run code as root and reach other tenants' dataAttackerYour systemLogs in with a low-privilege tenant account and creates a workflow with a code node — Requires a logged-in account with permission to create workflows. No other user has to do anything. 1Logs in with alow-privilegetenant account andcreates a workflo…With default settings, the platform picks LocalExecutor to run the code — When a code node runs, the local executor is used unless CODE_EXEC_TYPE was changed. The researchers also note that the internal /workflow/v1 route needs no authentication; the bundled nginx rule is the only thing blocking it from outside. 2With defaultsettings, theplatform picksLocalExecutor t…The code runs as root inside the core-workflow container — LocalExecutor hands the full set of Python built-ins to dynamically executed code, without the sandbox restrictions the documentation describes. 3The code runs asroot inside thecore-workflowcontainerUses shared credentials to bypass tenant checks and read or modify other tenants' data — Shared service and database credentials are available from the container, defeating application-level tenant isolation; shared services can also be disrupted. 4Uses sharedcredentials tobypass tenantchecks and read o…Attack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-108263-astron-agent-code-node-rce · CC BY 4.0
Astron Agent workflow code node runs without a sandbox: a low-privilege tenant can run code as root and reach other tenants' data: 1. Logs in with a low-privilege tenant account and creates a workflow with a code node → 2. With default settings, the platform picks LocalExecutor to run the code → 3. The code runs as root inside the core-workflow container → 4. Uses shared credentials to bypass tenant checks and read or modify other tenants' dataCVE-2026-108263 · Astron Agent workflowcode node runs without a sandbox: alow-privilege tenant can run code asroot and reach other tenants' dataLogs in with a low-privilege tenant account and creates a workflow with a code node — Requires a logged-in account with permission to create workflows. No other user has to do anything. 1AttackerLogs in with a low-privilegetenant account and creates aworkflow with a code nodeWith default settings, the platform picks LocalExecutor to run the code — When a code node runs, the local executor is used unless CODE_EXEC_TYPE was changed. The researchers also note that the internal /workflow/v1 route needs no authentication; the bundled nginx rule is the only thing blocking it from outside. 2Your systemWith default settings, theplatform picks LocalExecutor torun the codeThe code runs as root inside the core-workflow container — LocalExecutor hands the full set of Python built-ins to dynamically executed code, without the sandbox restrictions the documentation describes. 3Your systemThe code runs as root insidethe core-workflow containerUses shared credentials to bypass tenant checks and read or modify other tenants' data — Shared service and database credentials are available from the container, defeating application-level tenant isolation; shared services can also be disrupted. 4AttackerUses shared credentials tobypass tenant checks and reador modify other tenants' dataAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-108263-astron-agent-code-node-rce
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Logs in with a low-privilege tenant account and creates a workflow with a code node

    Requires a logged-in account with permission to create workflows. No other user has to do anything.

    Defense: PlainCVE suggestion: grant workflow-creation permission only to people who need it (this narrows who can attack, but does not replace upgrading).

  2. Your system

    With default settings, the platform picks LocalExecutor to run the code

    When a code node runs, the local executor is used unless CODE_EXEC_TYPE was changed. The researchers also note that the internal /workflow/v1 route needs no authentication; the bundled nginx rule is the only thing blocking it from outside.

    Defense: Upgrade to v1.1.2: the isolated LangChain/Pyodide executor becomes the default and CODE_EXEC_TYPE=local is no longer supported.

  3. Your system

    The code runs as root inside the core-workflow container

    LocalExecutor hands the full set of Python built-ins to dynamically executed code, without the sandbox restrictions the documentation describes.

    Defense: v1.1.2 rejects unsafe local code execution.

  4. Attacker

    Uses shared credentials to bypass tenant checks and read or modify other tenants' data

    Shared service and database credentials are available from the container, defeating application-level tenant isolation; shared services can also be disrupted.

    Defense: v1.1.2 also strengthens authentication on internal Workflow and Tenant service APIs, tenant checks, credential handling and deployment isolation.

Who is affected

ConditionAffected?
Astron Agent before 1.1.2 with CODE_EXEC_TYPE unchanged (default) or set to localAffected
Same versions, single-tenant deploymentStill exposed to the code-execution risk (vendor statement)
Upgraded to v1.1.2 with deployment files and all service images updatedFixed
Only the source checkout or only the workflow image updatedThe vendor says this is not a complete fix

The CVE record says “before 1.1.2”; the vendor’s release notes say “v1.1.1 and earlier, when using the legacy unsandboxed local code executor.” These don’t conflict: the vendor just adds a configuration condition, and before 1.1.2 that executor is the default.

The attacker needs a logged-in, low-privilege tenant account (a tenant is one customer’s or team’s separate space in a shared system); the vendor adds that it needs permission to create workflows.

How it works

Astron Agent lets users add “code nodes” to a workflow: steps where they write their own Python to process data. The documentation says this code runs in a sandbox (a restricted environment). But before 1.1.2, unless CODE_EXEC_TYPE was set explicitly, the platform picked LocalExecutor, which hands the full set of Python built-ins straight to the user’s code, without the sandbox restrictions the documentation describes.

The result: the code runs as root inside the core-workflow container. That container holds service and database credentials shared across tenants. With them, an attacker can bypass the application’s tenant checks, read or modify other tenants’ data, and disrupt shared services.

The researchers’ original report (reproduced in the vendor advisory GHSA-mh3w-4q3f-2fg5; that page contains exploit code, so PlainCVE does not link to it) also notes that the internal /workflow/v1 execution route needs no authentication; the bundled nginx config blocks it from outside by returning 404. So it can be used without credentials only from inside the deployment network, or through an SSRF (a flaw that makes the server send requests on the attacker’s behalf) that can reach the workflow service.

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)
# Run user code inside the platform's own process, with every built-in available
exec(user_code, {"__builtins__": FULL_BUILTINS})

The fixed approach:

Show code example(python)
if exec_type == "local":
    raise UnsupportedExecutor()  # local execution is no longer allowed
isolated_executor.run(user_code)  # hand off to an isolated executor

Weakness types: CWE-95 (eval injection), CWE-306 (missing authentication for critical function), CWE-653 (improper isolation), CWE-863 (incorrect authorization), CWE-1392 (use of default credentials).

Timeline

DateEvent
2026-07-17Researchers’ first authenticated end-to-end test run (on their own deployment)
2026-08-28Fix PR #1650 merged into main via PR #1651 (commit 848daba)
2026-09-07Maintainer publishes security advisory GHSA-mh3w-4q3f-2fg5 (first disclosure; that page contains exploit code, so PlainCVE does not link to it); v1.1.2 security release the same day, whose notes say the advisory is now public; CVE still awaiting assignment
2026-10-09CVE record published
2026-10-12Not listed in CISA KEV

Further reading

  • Scoring: the CNA (GitHub) gives CVSS 3.1 9.9 (Critical); the notes contain no separate NVD score.
  • Exploitation: as of 2026-10-12 it is not in CISA KEV; no source says whether it has been exploited in the wild or as a zero-day. vuln.today says it found no public exploit at the time of its analysis, but the researchers’ original report reproduced in the maintainer advisory GHSA-mh3w-4q3f-2fg5 (published 2026-09-07) includes a proof of concept (PoC) (that page contains exploit code, so PlainCVE does not link to it). The researchers say they tested only on their own deployments with harmless canaries and touched no iflytek or third-party system.
  • OpenCVE shows an EPSS score of 0.00432, but the same page’s AI-written analysis says EPSS is unavailable and that the issue “remains unpatched in many environments.” That analysis contradicts itself and is unsupported.
  • OSV’s version range starts at “0”; our analysis is that this only means no starting version was identified, and the version that introduced the bug is unknown.
  • The first-disclosure date follows the maintainer advisory GHSA-mh3w-4q3f-2fg5 (that page contains exploit code, so PlainCVE does not link to it), which shows 2026-09-07 (the v1.1.2 release notes from the same day also say the advisory is public; earlier than the CVE record’s 2026-10-09). The fix (release commit 189600dd691e8562bd0b9f7112727b107b8a2e10) shipped about a month before the CVE was published.
  • Reported by Noy Pearl and the Lasso Security team.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-13 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. AdvisoryCVE-2026-108263 record (CVE API) · CVE Program, 2026-10-09 · accessed 2026-10-12
  2. Patch / releaseastron-agent v1.1.2 release · iflytek (GitHub) · accessed 2026-10-12
  3. Patch / releaseastron-agent PR #1651 · iflytek (GitHub), 2026-08-28 · accessed 2026-10-12
  4. OtherOSV - CVE-2026-108263 · OSV · accessed 2026-10-12
  5. OtherOpenCVE - CVE-2026-108263 · OpenCVE · accessed 2026-10-12
  6. Otherastron-agent tag · vuln.today · accessed 2026-10-12

Press brief

In one sentence

Astron Agent is iflytek's open-source workflow platform for AI agents. Versions before 1.1.2 ran user-written code without a sandbox by default, letting a logged-in, low-privilege user with permission to create workflows run code as root inside a server container and then read or modify other tenants' data. Noy Pearl and the Lasso Security team reported the flaw, which is scored CVSS 9.9; the fixed version v1.1.2 is available. As of 2026-10-12 it was not in CISA's Known Exploited Vulnerabilities catalog.

Key facts

Severity
CVSS 3.1 9.9 (CNA: GitHub) cveawg.mitre.org
Fixed version
v1.1.2 github.com
First disclosed (maintainer advisory GHSA-mh3w-4q3f-2fg5 made public; per the v1.1.2 release notes)
2026-09-07 github.com
CVE published
2026-10-09 cveawg.mitre.org
Advisory ID (that page contains exploit code, so PlainCVE does not link to it; ID as listed in the CVE record)
GHSA-mh3w-4q3f-2fg5 cveawg.mitre.org
Reported by
Noy Pearl and the Lasso Security team github.com

Confirmed

  • Before 1.1.2 the unsandboxed LocalExecutor is the default, and a low-privilege tenant can run code as root in the core-workflow container.
  • An attacker can use shared credentials to bypass tenant checks and read or modify other tenants' data.
  • The vendor fixed it in v1.1.2 and says deployment files and all images must be updated together.
  • As of 2026-10-12 it is not listed in CISA KEV.
  • The researchers' original report reproduced in the maintainer advisory GHSA-mh3w-4q3f-2fg5 (published 2026-09-07) includes a proof of concept (PoC) (that page contains exploit code, so PlainCVE does not link to it).

Unconfirmed / disputed

  • No source says whether it has been exploited in the wild, or exploited before a patch existed.
  • OpenCVE's AI-written analysis says the issue 'remains unpatched in many environments' and EPSS is 'not available', yet the same page shows EPSS 0.00432; it contradicts itself and is unsupported.
  • The version that introduced the bug is not known.

Quotable line

The documentation promised a sandbox; the default setting simply didn't have one.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Astron Agent workflow code node runs without a sandbox: a low-privilege tenant can run code as root and reach other tenants' data". PlainCVE. https://plaincve.date/en/vulns/cve-2026-108263-astron-agent-code-node-rce (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026108263astronagentcodenoderce2026,
  title  = {Astron Agent workflow code node runs without a sandbox: a low-privilege tenant can run code as root and reach other tenants' data},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-108263-astron-agent-code-node-rce},
  note   = {Updated 2026-10-13}
}