mirror of
https://github.com/jgm/pandoc.git
synced 2026-08-25 17:56:32 +00:00
MANUAL.txt: Rewrite "A note on security."
Clarify the risks of using pandoc in a web service and explain how to do so more safely. Note some specific vulnerabilities with the pdf-engine `wkhtmltopdf`. This incorporates the suggestions made in #11262 and also benefits from a report by Kai Aizen.
This commit is contained in:
John MacFarlane
+73
-34
@@ -8048,38 +8048,73 @@ set at startup. For full documentation, see the [pandoc-lua] man page.
|
||||
writer could in principle do anything on your file system. Please
|
||||
audit filters and custom writers very carefully before using them.
|
||||
|
||||
2. Several input formats (including LaTeX, Org, RST, and Typst)
|
||||
support `include` directives that allow the contents of a file to be
|
||||
included in the output. An untrusted attacker could use these
|
||||
to view the contents of files on the file system. (Using the
|
||||
`--sandbox` option can protect against this threat.)
|
||||
2. If you want to use pandoc in a web application that accepts
|
||||
untrusted user input, you should be aware that running pandoc in
|
||||
this context requires special precautions, or you risk exfiltration
|
||||
of the contents of local files, or worse. In particular:
|
||||
|
||||
3. Several output formats (including RTF, FB2, HTML with
|
||||
`--self-contained`, EPUB, Docx, and ODT) will embed encoded
|
||||
or raw images into the output file. An untrusted attacker
|
||||
could exploit this to view the contents of non-image files on the
|
||||
file system. (Using the `--sandbox` option can protect
|
||||
against this threat, but will also prevent including images in
|
||||
these formats.)
|
||||
- Several input formats (including LaTeX, Org, RST, and Typst)
|
||||
support `include` directives that allow the contents of a file to be
|
||||
included in the output. An untrusted attacker could use these
|
||||
to view the contents of files on the file system. Using the
|
||||
`--sandbox` option will protect against this threat.
|
||||
|
||||
4. In reading HTML files, pandoc will attempt to include the
|
||||
contents of `iframe` elements by fetching content from the
|
||||
local file or URL specified by `src`. If untrusted HTML is
|
||||
processed on a server, this has the potential to reveal anything
|
||||
readable by the process running the server. Using the `-f html+raw_html`
|
||||
will mitigate this threat by causing the whole `iframe`
|
||||
to be parsed as a raw HTML block. Using `--sandbox` will also
|
||||
protect against the threat.
|
||||
- Several output formats (including RTF, FB2, HTML with
|
||||
`--self-contained`, EPUB, Docx, and ODT) will embed encoded
|
||||
or raw images into the output file. An untrusted attacker
|
||||
could exploit this to view the contents of non-image files on the
|
||||
file system. Using the `--sandbox` option will protect
|
||||
against this threat, but will also prevent including images in
|
||||
these formats.
|
||||
|
||||
5. If your application uses pandoc as a Haskell library (rather than
|
||||
shelling out to the executable), it is possible to use it in a mode
|
||||
that fully isolates pandoc from your file system, by running the
|
||||
pandoc operations in the `PandocPure` monad. See the document
|
||||
[Using the pandoc API](https://pandoc.org/using-the-pandoc-api.html)
|
||||
for more details. (This corresponds to the use of the `--sandbox`
|
||||
option on the command line.)
|
||||
- In reading HTML files, pandoc will attempt to include the
|
||||
contents of `iframe` elements by fetching content from the
|
||||
local file or URL specified by `src`. If untrusted HTML is
|
||||
processed on a server, this has the potential to reveal
|
||||
anything readable by the process running the server or to
|
||||
enable server-side request forgery (SSRF) attacks
|
||||
([CVE-2025-51591]). To mitigate such attacks, use
|
||||
`--sandbox` or `-f html+raw_html` (which causes the whole
|
||||
`iframe` to be parsed as a raw HTML block).
|
||||
|
||||
6. Pandoc's parsers can exhibit pathological performance on some
|
||||
- Using pandoc with `--pdf-engine` introduces additional risks,
|
||||
which cannot be mitigated by using `--sandbox`.
|
||||
For example, in `wkhtmltopdf` the `footer-html` and `header-html`
|
||||
metadata fields will be passed directly to `wkhtmltopdf`
|
||||
as `--footer-html` and `--header-html` arguments, and by using
|
||||
a `file:` URIs with these, one could exfiltrate local files.
|
||||
In addition, using `--pdf-engine=wkhtmltopdf` with `-f html+raw_html`
|
||||
enables an SSRF vulnerability in wkhtmltopdf ([CVE-2022-35583]).
|
||||
Note that [`wkhtmltopdf`) is
|
||||
[deprecated](https://wkhtmltopdf.org/status.html) and
|
||||
its authors recommend not to use it with any untrusted input.
|
||||
However, there may be similar issues with other pdf-engines.
|
||||
Anyone including a pdf-engine in a pandoc command run on
|
||||
untrusted input should audit the engine carefully and
|
||||
carefully control the use of `--pdf-engine-opt`.
|
||||
|
||||
Here are some alternatives for safe use of pandoc in a web
|
||||
application:
|
||||
|
||||
- Use `pandoc server` to spin up a local web server, and have your
|
||||
application make requests to it. The server runs in sandboxed mode
|
||||
and will not be able to read files or use filters.
|
||||
|
||||
- Use the WASM version of pandoc. This allows the use of Lua filters,
|
||||
but everything runs in an isolated WASM sandbox.
|
||||
|
||||
- Use `pandoc --sandbox`. However, be aware that the sandbox function
|
||||
only affects readers and writers, and security issues can arise if
|
||||
you use it together with `--filter` or `--pdf-engine`.
|
||||
|
||||
3. The HTML generated by pandoc is not guaranteed to be safe.
|
||||
If `raw_html` is enabled for the Markdown input, users can
|
||||
inject arbitrary HTML. Even if `raw_html` is disabled,
|
||||
users can include dangerous content in URLs and attributes.
|
||||
To be safe, you should run all HTML generated from untrusted
|
||||
user input through an HTML sanitizer.
|
||||
|
||||
4. Pandoc's parsers can exhibit pathological performance on some
|
||||
corner cases. It is wise to put any pandoc operations under
|
||||
a timeout, to avoid DOS attacks that exploit these issues.
|
||||
If you are using the pandoc executable, you can add the
|
||||
@@ -8089,12 +8124,16 @@ set at startup. For full documentation, see the [pandoc-lua] man page.
|
||||
to pathological performance than the `markdown` parser, so
|
||||
it is a better choice when processing untrusted input.
|
||||
|
||||
7. The HTML generated by pandoc is not guaranteed to be safe.
|
||||
If `raw_html` is enabled for the Markdown input, users can
|
||||
inject arbitrary HTML. Even if `raw_html` is disabled,
|
||||
users can include dangerous content in URLs and attributes.
|
||||
To be safe, you should run all HTML generated from untrusted
|
||||
user input through an HTML sanitizer.
|
||||
5. If your application uses pandoc as a Haskell library (rather than
|
||||
shelling out to the executable), it is possible to use it in a mode
|
||||
that fully isolates pandoc from your file system, by running the
|
||||
pandoc operations in the `PandocPure` monad. See the document
|
||||
[Using the pandoc API](https://pandoc.org/using-the-pandoc-api.html)
|
||||
for more details. (This corresponds to the use of the `--sandbox`
|
||||
option on the command line.)
|
||||
|
||||
[CVE-2025-51591]: https://nvd.nist.gov/vuln/detail/CVE-2025-51591
|
||||
[CVE-2022-35583]: https://nvd.nist.gov/vuln/detail/CVE-2022-35583
|
||||
|
||||
# Authors
|
||||
|
||||
|
||||
Reference in New Issue
Block a user