Yes, in practice. MDX lets authors write Markdown that can include JavaScript expressions, imports and components, and those run when the site is built or rendered. A content pull request can therefore execute code, so it deserves review, scanning and limits on who can merge.
Markdown versus MDX
Plain Markdown is data. A converter turns it into HTML, and the worst case is odd markup. MDX is a superset that lets a file import modules and use JSX components. The upside is rich, interactive posts. The cost is that a document is no longer inert.
| Feature | Plain Markdown | MDX |
|---|---|---|
| Raw HTML | Often allowed, depends on converter | Allowed as components |
| Imports | No | Yes |
| Expressions | No | Yes |
| Runs at build time | The converter | Author code can run |
| Review burden | Low | Same as source code |
What could go wrong
- A contributor imports a module that reads environment variables during the build and writes them into a page or sends them out.
- A component embeds a third-party script that loads on every visitor's page.
- A compromised contributor account pushes a content change that looks harmless.
- A new dependency is added in the same pull request as a blog post, so it slips past reviewers who skim just the prose.
None of these are exotic. They are the normal risks of running contributed code.
A safe workflow
- Protect the main branch. Require review before merge, and do not let authors approve their own changes.
- Use code owners. Assign component folders and configuration files to engineers, and prose folders to editors. Pull requests touching both need both.
- Block dependency changes in content PRs. A rule that fails when a manifest or lockfile changes in a pull request labelled as content catches the quiet addition of a package.
- Limit imports. If your editors need five components, expose those five and lint for anything else. Fewer allowed imports means a shorter review.
- Build previews without secrets. The preview that renders the post should not receive deploy or API keys. See should preview deployments be public.
- Run static analysis on components. Code in custom components is ordinary JavaScript and benefits from the same scanning as the rest of your source.
- Review the diff for external hostnames. Any new URL in a script, iframe or image tag is a new supplier.
If you do not need MDX
If posts are mostly text and images, consider a Markdown pipeline that does not execute code and sanitizes raw HTML. You can still add a small set of shortcodes that are implemented and reviewed once.
Try it yourself
The code scan demo shows how a static analysis finding is traced to a line and explained. Try it on a sample finding and think about what a similar rule would flag in a custom MDX component.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides code and dependency scanning with policy gates on pull requests, which suits a repository where content and code share a review flow. Free scan: gold.safeguard.sh/scan.
Quick check
Can plain Markdown be dangerous too?
If the converter passes raw HTML through, a post can include script tags. Sanitize or disable raw HTML for untrusted authors.
Should writers need an engineer to merge every post?
Not for prose in a folder with no code. Use code owners so engineers review just the changes that touch components or config.
Last reviewed: 19 October 2026.
