mirror of
https://github.com/wagtail/wagtail.git
synced 2024-11-24 19:17:48 +01:00
9a5be8f180
Some link labels are changed to just the code part, because using Sphinx roles for code objects (e.g. methods, attributes) would always format the text as inline code. It's currently impossible to customize the formatting of a link's text in rST. See https://stackoverflow.com/questions/4743845
17 lines
1.5 KiB
ReStructuredText
17 lines
1.5 KiB
ReStructuredText
===========================
|
|
Wagtail 2.9.3 release notes
|
|
===========================
|
|
|
|
*July 20, 2020*
|
|
|
|
CVE-2020-15118: HTML injection through form field help text
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This release addresses an HTML injection vulnerability through help text in the ``wagtail.contrib.forms`` form builder app. When a form page type is made available to Wagtail editors, and the page template is built using Django's standard form rendering helpers such as ``form.as_p`` :ref:`(as directed in the documentation) <form_builder_usage>`, any HTML tags used within a form field's help text will be rendered unescaped in the page. Allowing HTML within help text is an intentional design decision by Django (see the docs for :py:attr:`~django.db.models.Field.help_text`); however, as a matter of policy Wagtail does not allow editors to insert arbitrary HTML by default, as this could potentially be used to carry out cross-site scripting attacks, including privilege escalation. This functionality should therefore not have been made available to editor-level users.
|
|
|
|
The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.
|
|
|
|
Site owners who wish to re-enable the use of HTML within help text (and are willing to accept the risk of this being exploited by editors) may set ``WAGTAILFORMS_HELP_TEXT_ALLOW_HTML = True`` in their configuration settings.
|
|
|
|
Many thanks to Timothy Bautista for reporting this issue.
|