Is the library impacted by CVE-2026-0969?

[axeleroy]

Hello,

Since next-mdx-remote-client is a fork of next-mdx-remote, I wonder if it is impacted by the recently uncovered CVE-2026-0969, which has been fixed in version 6.0.0.

Regards,
Axel

[talatkuyuk]

Hello Axel,

Thank you for raising this.

First, this is not a new issue specific to next-mdx-remote which is not uniquely impacted. The security model is the same as all MDX integrations. The underlying concern (RCE when compiling untrusted MDX) has been known for years across all MDX integrations built on top of MDX and @mdx-js/mdx , including next-mdx-remote, next-mdx-remote-client, @next/mdx, and similar solutions.

If MDX content is not fully trusted, then Remote Code Execution (RCE) is inherently possible. This is clearly documented in MDX and related integration package documentation. The risk is intrinsic to how MDX works.

MDX supports three powerful constructs: JSX syntax, JS expressions and ESM blocks (mdxjsEsm) (import, export); If you completely block expressions, you are effectively reducing MDX to Markdown-with-JSX. That may be acceptable for some use cases, but it changes the nature of MDX itself. We should focus on blocking dangerous expressions, maybe it is the best approach.

About CVE-2026-0969 and next-mdx-remote@6, the fix in attempts to mitigate this by blocking JavaScript expressions by default. In my opinion, this approach is problematic because: It changes default MDX behavior, It enforces a policy decision at the integration layer, “Dangerous” expressions are contextual and depend on compilation/runtime strategy. If you allow arbitrary MDX from users, you must sanitize or transform it at the AST level, what next-mdx-remote did, and actually not need to be in integration layer.

Actually, the vulnerability surface exists at the plugin / AST transformation level, not at the rendering layer. So this is not something that can be solved purely at the integration boundary. The correct place to handle this is in the remark plugin chain, before compilation. For that reason, I created and published remark-mdx-remove-expressions. This plugin allows you to explicitly control JS expression handling in MDX.

The default behavior (strict mode) of remark-mdx-remove-expressions removes all MDX expressions:

import remarkMdxRemoveExpressions from "remark-mdx-remove-expressions";

{
  mdxOptions: {
    remarkPlugins: [remarkMdxRemoveExpressions]
  }
}

The safer balanced mode (recommended) removes only dangerous MDX expressions:

import remarkMdxRemoveExpressions from "remark-mdx-remove-expressions";

{
  mdxOptions: {
    remarkPlugins: [
      [remarkMdxRemoveExpressions, { onlyDangerousExpressions: true }]
    ]
  }
}

With onlyDangerousExpressions: true, the plugin:

• Strips expressions that enable remote code execution (RCE)
• Preserves safe JS expression usage when possible
• Maintains MDX usability while reducing attack surface. This gives fine-grained control instead of globally disabling MDX semantics.

The proper mitigation is to use a remark-level transformation like remark-mdx-remove-expressions. Integrating this behavior directly into next-mdx-remote-client would introduce tight coupling at the rendering layer, which I intentionally want to avoid. The core issue is not rendering, it is AST transformation and compilation policy. For that reason, I prefer keeping this concern at the plugin level, where it naturally belongs.

If this remark plugin were to be added directly into next-mdx-remote-client, it would likely take the form of explicit options such as: disableAllExpressions, disableDangerousExpressions. However, using remark-mdx-remove-expressions directly provides a cleaner separation of concerns, better testability, and avoids embedding security policy decisions into the renderer itself. Would you prefer adding built-in flags like the above, or using the dedicated plugin approach, which keeps the architecture more modular and decoupled, I want to get your opinions.

[axeleroy]

Hello, and thank you for this very detail answer.

I was aware of the risks of running untrusted JS in MDX, but I did not make the connection with the CVE until you did.

In my opinion, the "Security" section in the README provides ample information, but it is so far down that I think many people could miss it, maybe it's best to move it right bellow or above the "Installation" section?