Mermaid's Song: From Flowchart to Remote Code Execution in LobeChat

Modern desktop applications are often just web browsers in a trench coat. We call it "Electron," and it's a convenient way to ship cross-platform apps without writing C++. But it comes with a terrifying caveat: if you break the glass wall between the web renderer and the underlying system, you aren't just stealing cookies—you're owning the machine.

LobeChat, a sophisticated open-source AI chat platform, fell into this exact trap. It supports "Artifacts," which are fancy ways to render content generated by LLMs or users. One such artifact type is Mermaid, a JavaScript library that turns text definitions into diagrams.

It sounds innocent enough. You type some syntax, you get a flowchart. But what happens when the renderer blindly trusts the text, and the application blindly trusts the renderer? You get CVE-2026-23733, a bug that turns a flowchart into a command shell.

The vulnerability lies deep within the Renderer component, specifically where it handles content with the MIME type application/lobe.artifacts.mermaid. The code responsible for this was frighteningly simple—too simple.

Here is the logic flaw in its raw glory:

case 'application/lobe.artifacts.mermaid': {
  // "Here, take this raw string and make it a picture."
  return <Mermaid variant={'borderless'}>{content}</Mermaid>;
}

The variable content comes directly from the message payload (user or AI generated). The Mermaid component takes this string and passes it to the underlying Mermaid.js library. The problem? Mermaid.js allows HTML in node labels for styling flexibility. For example, A["<b>Bold</b>"] renders bold text.

But Mermaid doesn't just render bold text; if you pass it A["<img src=x onerror=alert(1)>`"], it renders the image tag and fires the error handler. Because LobeChat failed to sanitize the content before handing it to the diagram engine, it created a classic Stored XSS vector. In a browser, this is bad. In Electron, it's catastrophic.

XSS is the spark, but the fuel for this fire is the Electron IPC (Inter-Process Communication) bridge. LobeChat exposes a global object to the renderer window called electronAPI. This is intended to let the UI talk to the backend (the Main process) to perform tasks like saving files or... running commands.

The application registered a controller named ShellCommandCtr in the main process, which listens for the runCommand event. And look at this beautiful, dangerous function:

@ipcClientEvent('runCommand')
async handleRunCommand({ command, ... }: RunCommandParams) {
  // ... logging logic ...
  // "Execute whatever the renderer asked for."
  const childProcess = spawn(shellConfig.cmd, shellConfig.args, ...);
  // ...
}

This function is a direct wrapper around Node.js's child_process.spawn. It doesn't check who is calling it, only that the call came from the renderer. Since our XSS executes code inside the renderer, it inherits the renderer's permissions. We can simply reach out and touch window.electronAPI, politely asking the main process to nuke the system.

Putting it all together, we don't need a complex binary exploit. We just need a valid Mermaid diagram definition that contains a JavaScript payload. The attack chain looks like this:

1. Craft the Message: Send a message containing a lobeArtifact tag.
2. Embed the Payload: Define a Mermaid graph where a node's label contains an <img> tag with an onerror event.
3. Bypass Quotes: Use String.fromCharCode to construct the payload string to avoid quotation mark escaping hell inside the Mermaid syntax.
4. Execute: When the victim views the chat, the diagram renders, the image fails to load, and the shell command executes.

Here is the functional Proof of Concept:

<lobeArtifact type="application/lobe.artifacts.mermaid">
```mermaid
graph TD;
 A["&lt;img src=x onerror='window.electronAPI.invoke(\"runCommand\", \{command: \"calc.exe\"\})'&gt;"];
```
</lobeArtifact>
````
 
> [!NOTE]
> In the actual wild exploit, we use `String.fromCharCode` (e.g., `String.fromCharCode(99,97,108,99,46,101,120,101)` for 'calc.exe') to bypass potential strict mode limitations or quote filtering in the Mermaid parser.

Why should you panic? Because this is a "zero-click" equivalent for the victim once they open the chat. If an attacker can trick an AI into generating this artifact, or if they are in a shared chat environment, the victim's machine is compromised immediately upon rendering the message.

With runCommand access, the attacker can:

• Exfiltrate Data: Zip up your SSH keys and curl them to a remote server.
• Persistence: Add a registry run key or a cron job to maintain access after the app closes.
• Ransomware: Encrypt the user's Documents folder.

The CVSS score of 6.4 feels deceptively low because of the "Local" vector, but in the context of a chat app where users download and run remote content by design, the practical risk is Critical.

The mitigation is straightforward but essential: Trust No One. The patch implemented in version 2.0.0-next.180 introduces strict sanitization before the content reaches the Mermaid component.

Developers must strip HTML tags from the user input before passing it to libraries that might interpret them. Alternatively, configuring Mermaid's securityLevel to 'strict' can prevent HTML rendering entirely, though this might break some legitimate formatting use cases.

If you are running a self-hosted instance or the local desktop app, update immediately. If you are developing an Electron app, audit every single ipcMain.handle or ipcMain.on listener. If you are exposing a generic spawn or exec wrapper to the renderer, you have built a backdoor; it's just waiting for someone to find the key.