What are the signs that a VS Code extension is mishandling attacker-controlled Markdown?

What the warning signs actually tell you about the extension boundary

The clearest signs are not visual glitches, they are trust-boundary mistakes. If an extension turns repository text into Markdown without treating the input as hostile, it is effectively giving workspace content a path into UI surfaces that users assume are safe. That matters because hover cards, previews, and webviews often inherit richer rendering behavior than plain text.

A second warning sign is inconsistency. If the extension sanitises some fields but still permits raw Markdown constructs in others, the safety model is probably ad hoc rather than deliberate. That usually means the author is reasoning about what looks harmless instead of enforcing a single rule for all attacker-controlled content.

Extensions become especially suspect when they compose Markdown by string interpolation. That pattern usually means the developer is mixing trusted chrome with untrusted payloads, so a malicious repository can influence links, images, formatting, or embedded content in ways the UI was not meant to expose.

Where the failure usually shows up in VS Code

The most common failure points are the places where text gets promoted into richer rendering contexts: hover providers, issue or diff previews, completion documentation, and webviews. If the extension passes data straight through from the workspace, issue tracker, or remote repository metadata into one of those surfaces, the rendering path is probably too permissive.

Look for code that enables “trusted” rendering by default, or that assumes Markdown from a repository is equivalent to authored documentation. In practice, attacker-controlled Markdown can be used to mislead users, inject unexpected links, or make malicious content look like part of the extension’s own interface. The rendering engine is not the problem by itself, the problem is granting it trust without validating the source.

Partial sanitisation is another strong signal. If an extension removes one risky construct but still allows the rest of the Markdown grammar, the attacker can often reshape the message in ways the developer did not anticipate. That is why the real question is not “was some filtering applied”, but “did the extension reduce the content to plain text or a tightly bounded subset before rendering”.

Risk and Threat Considerations

When attacker-controlled Markdown is rendered with elevated trust, the risk is user deception, unsafe navigation, and content injection into surfaces the user assumes are extension-authored. In a developer tool, that can turn an ordinary repository artifact into a delivery mechanism for phishing, malicious links, or misleading operational guidance.

Failure mechanism: The extension treats untrusted workspace data as Markdown-safe, preserves rich constructs such as links or embedded formatting, and renders them in UI components that users trust more than raw file content.

Impact: Users may follow attacker-supplied links, misread repository context, or accept malicious content as legitimate extension output, increasing the chance of credential theft, malicious workflow actions, or downstream compromise.

Practitioner Guidance

What to verify: Check whether every Markdown-rendering path has an explicit trust decision and whether attacker-controlled data is reduced to plain text or a narrowly allowed subset before it reaches hover, preview, or webview surfaces. If the extension relies on “sanitisation” but still accepts raw Markdown from the repository, treat that as a design defect, not a tuning issue.

Common mistake: Developers often secure the obvious path, such as one preview widget, while leaving other rendering sinks untouched. For this class of bug, the important test is whether any sink can be reached with untrusted Markdown and a permissive renderer, because a single overlooked path is enough to preserve the attack surface.

Practitioner takeaway: The safest default is to assume workspace Markdown is hostile until it has been explicitly downgraded to inert text or validated against a strict policy, because “mostly sanitised” is usually still exploitable.

Related resources from NHI Mgmt Group

• What are the signs that a VS Code extension strategy is becoming unmanageable?
• What are the signs that a VS Code extension may be unsafe or misused?
• What breaks when a public-facing cloud app can execute attacker-controlled code?
• What breaks when a malicious VS Code extension can inherit a GitHub session silently?