CVE-2020-12827 unfixed? (`ignoreIncludes` continues to default to `false`? 🤔 )

[hartwork]

Hi!

Past vulnerability CVE-2020-12827 has come to my attention. After reading the detailed description and inspecting the two related commits…

• 21034a7
• 30e29ed

…between releases 4.6.2 and 4.6.3, my impression so far is that the issue of attacker-controlled file access has not been fixed and that the default settings are still vulnerable.

For proof (1), in version <mj-include path="/etc/passwd" /> renders an error while <mj-include path="no_such_file" /> renders a comment <!-- mj-include fails to read file [..] --> and overall rendering succeeds, so checking for the existence of files still works (provided some error feedback channel to the attacker).

What's worse (2), when adding type="css" as documented at https://documentation.mjml.io/#mj-include a la …

<mjml>
  <mj-body>
    <mj-include path="/etc/passwd" type="css" />
  </mj-body>
</mjml>

…and compiling via mjml -r demo.mjml the whole file content is included verbatim into the HTML header, and no error is produced.

So from my point of view CVE-2020-12827 is wide open by default and has never been fixed. Could you clarify and point me to what I am missing?

Thanks and best, Sebastian

CC @hannob

[iRyusa]

You're right the css version of mj-include should behave as the MJML counterpart. We did only mitigate this through a flag because mj-include was meant to be used purely in a "local" environnement as it makes no sense to be used server-side (you mostly rely on a proper template engine for this), that's why the comment is more verbose when the file exist but I get this could be a huge security concern. I think it should be disabled by default and manually enabled by the cli instead ? Maybe we could do this change in the 5.x branch.

…

On Sun, Nov 30, 2025 at 4:21 PM Sebastian Pipping ***@***.***> wrote: *hartwork* created an issue (mjmlio/mjml#3018) <#3018> Hi! Past vulnerability CVE-2020-12827 <https://github.com/advisories/GHSA-4hch-r9xf-6vfr> has come to my attention. After reading the detailed description <https://seclists.org/fulldisclosure/2020/Jun/23> and inspecting the two related commits… - 21034a7 <21034a7> - 30e29ed <30e29ed> …between releases 4.6.2 and 4.6.3 <v4.6.2...v4.6.3>, my impression so far is that the issue of attacker-controlled file access has not been fixed and that the default settings are still vulnerable. For proof (1), in version <mj-include path="/etc/passwd" /> renders an error while <mj-include path="no_such_file" /> renders a comment <!-- mj-include fails to read file [..] --> and overall rendering succeeds, so checking for the existence of files still works (provided some error feedback channel to the attacker). What's worse (2), when adding type="css" as documented at https://documentation.mjml.io/#mj-include a la … <mjml> <mj-body> <mj-include path="/etc/passwd" type="css" /> </mj-body> </mjml> …and compiling via mjml -r demo.mjml the whole file content is included verbatim into the HTML header, and no error is produced. So from my point of view CVE-2020-12827 <https://github.com/advisories/GHSA-4hch-r9xf-6vfr> is wide open by default and has never been fixed. Could you clarify and point me to what I am missing? Thanks and best, Sebastian CC @hannob <https://github.com/hannob> — Reply to this email directly, view it on GitHub <#3018>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELHTMKSZWPV3R25WLPLWD37MDOVAVCNFSM6AAAAACNTEJWUWVHI2DSMVQWIX3LMV43ASLTON2WKOZTGY3TOOJQGU3TGNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hartwork]

Hi @iRyusa thanks for your prompt reply! 👍

[..] this could be a huge security concern.

I think it should be disabled by default and manually enabled by the cli instead ?

Sounds great!

You're right the css version of mj-include should behave as the MJML counterpart.

I'm not sure I understand. Could you elaborate?

Thanks! 🙏