Impact

A reflected cross-site scripting (XSS) vulnerability exists on the dynamic image URL generator view within the Wagtail admin interface. A user with a limited-permission editor account for the Wagtail admin could craft a URL that, when viewed by a user with higher privileges, could perform actions with that user's credentials. The vulnerability is present for all sites, even if they do not enable the dynamic image serve view. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches

Patched versions have been released as Wagtail 7.3.3 and 7.4.2.

Workarounds

For sites that cannot easily upgrade to a current supported version, the vulnerability can be patched by adding the following code to urls.py URL pattern declarations to override the vulnerable view. This disables the admin dynamic image preview functionality, while the public-facing dynamic image serve view still works.

python from django.http import HttpResponseBadRequest from django.urls import path from wagtail.admin import urls as wagtailadminurls

def disabledoutput(request, imageid): return HttpResponseBadRequest("", contenttype="text/plain")

urlpatterns = [ # Example where the CMS admin is at /admin/. # Add this before the Wagtail admin URLs registration, with the same sub-path. path("admin/images/<int:imageid>/generateurl/output/", disabledoutput), path("admin/", include(wagtailadminurls)), ]

Acknowledgements

Many thanks to Thibaud Colas (@thibaudcolas) for reporting this issue.

For more information

If you have any questions or comments about this advisory:

- Visit Wagtail's support channels - Email us at security@wagtail.org (view our security policy for more information).

Impact A low-level user with the "Can submit translation" permission can create translations for any page, including those they do not have permissions for.

Patches Patched versions have been released as Wagtail 7.0.8, 7.3.3, 7.4.2.

Workarounds N/A

Acknowledgements

Many thanks to @devansh3008 and @alanturing881 for reporting this issue.

For more information

If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact Due to a missing permission check on the image preview endpoint, a user with access to the Wagtail admin can preview any image. The existing data of the image object itself is not exposed. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 7.0.8, 7.3.3, 7.4.2.

Workarounds For sites that cannot easily upgrade to a current supported version, the vulnerability can be patched by adding the following code to urls.py URL pattern declarations to override the vulnerable view.

python from django.core.exceptions import PermissionDenied from django.shortcuts import getobjector404 from django.urls import path from wagtail.admin import urls as wagtailadminurls from wagtail.images.permissions import permissionpolicy from wagtail.images.views import preview

def patchedpreview(request, imageid, filterspec): image = getobjector404(getimagemodel(), id=imageid)

if not permissionpolicy.userhaspermissionforinstance(request.user, "change", image): raise PermissionDenied

return preview(request, imageid, filterspec)

urlpatterns = [ # Example where the CMS admin is at /admin/. # Add this before the Wagtail admin URLs registration, with the same sub-path. path("admin/images/<int:imageid>/preview/<str:filterspec>/", patchedpreview) path("admin/", include(wagtailadminurls)), ]

Acknowledgements Many thanks to @0x1saac and @harshakshit for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact The Documents and Images chooser's chosen endpoint incorrectly listed items for which the user has not been granted choose permission. A user with access to the Wagtail admin could see the filename and name and URLs of documents and images in those collections.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 7.0.8, 7.3.3, 7.4.2.

Workarounds N/A

Acknowledgements Many thanks to @harshakshit for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact

An authenticated admin user can trigger expensive rendition processing with purposefully crafted filter specs resulting in potentially service degradation.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 7.0.8, 7.3.3, 7.4.2.

Workarounds For sites that cannot easily upgrade to a current supported version, the vulnerability can be patched by adding the following code to urls.py URL pattern declarations to override the vulnerable view.

python from django.core.exceptions import PermissionDenied from django.http import HttpResponseBadRequest from django.shortcuts import getobjector404 from django.urls import path from wagtail.admin import urls as wagtailadminurls from wagtail.images.exceptions import InvalidFilterSpecError from wagtail.images.permissions import permissionpolicy from wagtail.images.views import preview

def patchedpreview(request, imageid, filterspec): image = getobjector404(getimagemodel(), id=imageid)

if not permissionpolicy.userhaspermissionforinstance(request.user, "change", image): raise PermissionDenied

try: filterobj = Filter(spec=filterspec) except InvalidFilterSpecError: return HttpResponseBadRequest("Invalid filter spec", contenttype="text/plain")

allowed = {"original", "width", "height", "min", "max", "fill"} if any(operation.method not in allowed for operation in filterobj.operations): return HttpResponseBadRequest("Invalid filter spec", contenttype="text/plain")

return preview(request, imageid, filterspec)

urlpatterns = [ # Example where the CMS admin is at /admin/. # Add this before the Wagtail admin URLs registration, with the same sub-path. path("admin/images/<int:imageid>/preview/<str:filterspec>/", patchedpreview) path("admin/", include(wagtailadminurls)), ]

Acknowledgements Many thanks to @0x1saac for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact

A CMS user with limited access to pages could copy a page they don't have access to to an area of the site they do. Once copied, they'd be able to view its contents, and potentially publish it. Permissions were correctly checked for the copy destination, but not for the source page.

Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

Workarounds

No workaround is available.

Acknowledgements

Wagtail thanks independent security researcher Sanjok Karki @thesanjok for reporting this issue.

For more information If there are any questions or comments about this advisory:

Visit Wagtail's support channels Send an email to security@wagtail.org (view the security policy for more information).

Impact

The Documents and Images API incorrectly listed items in private collections. A user with access to the API could see the filename and name of documents and images in private collections.

Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

Workarounds

Site owners using Wagtail's API can avoid the vulnerability by adding authentication to the Documents and Images APIs.

Acknowledgements

Wagtail thanks independent security researcher Sanjok Karki @thesanjok for reporting this issue.

For more information If there are any questions or comments about this advisory:

Visit Wagtail's support channels Send an email to security@wagtail.org (view the security policy for more information).

Impact

A CMS user with limited access to form pages could delete submissions to form pages they don't have access to by crafting a form submission to delete submissions on a page they do have access to for submissions they don't.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

Workarounds

No workaround is available.

Acknowledgements

Wagtail thanks Vishal Shukla @shukla304 for reporting this issue.

For more information If there are any questions or comments about this advisory:

Visit Wagtail's support channels Send an email to security@wagtail.org (view the security policy for more information).

Impact

A CMS user without the ability to edit a page could still access the history report for the page, potentially resulting in disclosure of sensitive information.

Patches Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

Workarounds

No workaround is available.

Acknowledgements

Wagtail thanks Seoyoung Kang @seoyoung-kang who is from AhnLab and also an independent security researcher for reporting this issue.

For more information If there are any questions or comments about this advisory:

Visit Wagtail's support channels Send an email to security@wagtail.org (view the security policy for more information).

Impact

A CMS user without the ability to edit a page could access revisions of the page through the revision compare view if they knew the primary key of two revisions. This could potentially result in disclosure of sensitive information.

Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

Workarounds

No workaround is available.

Acknowledgements

Many thanks to Seoyoung Kang @seoyoung-kang from AhnLab and an independent security researcher for reporting this issue.

For more information If there are any questions or comments about this advisory:

Visit Wagtail's support channels Send an email to security@wagtail.org (view the security policy for more information).

Impact A stored Cross-site Scripting (XSS) vulnerability exists on confirmation messages within the wagtail.contrib.simpletranslation module. A user with access to the Wagtail admin area may create a page with a specially-crafted title which, when another user performs the "Translate" action, causes arbitrary JavaScript code to run. This could lead to performing actions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 6.3.8, 7.0.6, 7.2.3 and 7.3.1.

Workarounds None

Acknowledgements

Many thanks to Guan Chenxian (@GCXWLP) for reporting this issue.

For more information

If there are any questions or comments about this advisory:

- Visit Wagtail's support channels - Email Wagtail at security@wagtail.org (view the security policy for more information).

Impact A stored Cross-site Scripting (XSS) vulnerability exists on rendering TableBlock blocks within a StreamField. A user with access to create or edit pages containing TableBlock StreamField blocks is able to set specially-crafted class attributes on the block which run arbitrary JavaScript code when the page is viewed. When viewed by a user with higher privileges, this could lead to performing actions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, and only affects sites using TableBlock.

Patches Patched versions have been released as Wagtail 6.3.8, 7.0.6, 7.2.3 and 7.3.1.

Workarounds Site owners who are unable to upgrade to the new versions can remediate the vulnerability by setting a template attribute on all TableBlock definitions, referencing a template that does not output class attributes. For example:

django <!-- For use with TableBlock(template="path/to/tableblock.html") --> <table> {% if tablecaption %} <caption>{{ tablecaption }}</caption> {% endif %} {% if tableheader %} <thead> <tr> {% for cell in tableheader %} <th scope="col">{{ cell }}</th> {% endfor %} </tr> </thead> {% endif %} <tbody> {% for row in data %} <tr> {% for cell in row %} {% if firstcolisheader and forloop.first %} <th scope="row">{{ cell }}</th> {% else %} <td>{{ cell }}</td> {% endif %} {% endfor %} </tr> {% endfor %} </tbody> </table>

Acknowledgements

Many thanks to Guan Chenxian (@GCXWLP) for reporting this issue.

For more information

If there are any questions or comments about this advisory:

- Visit Wagtail's support channels - Email Wagtail at security@wagtail.org (view the security policy for more information).

Impact Due to a missing permission check on the preview endpoints, a user with access to the Wagtail admin and knowledge of a model's fields can craft a form submission to obtain a preview rendering of any page, snippet or site setting object for which previews are enabled, consisting of any data of the user's choosing. The existing data of the object itself is not exposed, but depending on the nature of the template being rendered, this may expose other database contents that would otherwise only be accessible to users with edit access over the model. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 6.3.6, 7.0.4, 7.1.3 and 7.2.2. The new 7.3 feature release also incorporates this fix.

Workarounds No workaround is available.

Acknowledgements

Many thanks to @thxtech for reporting this issue.

For more information

If there are any questions or comments about this advisory:

- Visit Wagtail's support channels - Send an email to security@wagtail.org (view our security policy for more information).

Impact

A bug in Wagtail's parsequerystring would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, parsequerystring would take an unexpectedly large amount of time to process, resulting in a denial of service.

In an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses parsequerystring, it may be exploitable by other users (e.g. unauthenticated users).

Patches

Patched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3.

This vulnerability affects all unpatched versions from Wagtail 2.0 onwards.

Workarounds

Site owners who are unable to upgrade to a patched version can limit the length of search terms passed to parsequerystring. Whilst the performance characteristics will depend on your hosting environment, 1000 characters has been shown to still be fairly fast, without triggering this vulnerability.

No workaround is available for the Wagtail admin usage.

Acknowledgements

Many thanks to Jake Howard for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact

A user with a limited-permission editor account for the Wagtail admin can make a direct URL request to the admin view that handles bulk actions on user accounts. While authentication rules prevent the user from making any changes, the error message discloses the display names of user accounts, and by modifying URL parameters, the user can retrieve the display name for any user. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 4.1.9 (LTS), 5.0.5 and 5.1.3. The fix is also included in Release Candidate 1 of the forthcoming Wagtail 5.2 release.

Workarounds None.

Acknowledgements Many thanks to @quyenheu for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.org (view our security policy for more information).

Impact

A memory exhaustion bug exists in Wagtail's handling of uploaded images and documents. For both images and documents, files are loaded into memory during upload for additional processing. A user with access to upload images or documents through the Wagtail admin interface could upload a file so large that it results in a crash or denial of service.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. It can only be exploited by admin users with permission to upload images or documents.

Image uploads are restricted to 10MB by default, however this validation only happens on the frontend and on the backend after the vulnerable code.

Patches

Patched versions have been released as Wagtail 4.1.4 (for the LTS 4.1 branch) and Wagtail 4.2.2 (for the current 4.2 branch).

Workarounds

Site owners who are unable to upgrade to the new versions are encouraged to add extra protections outside of Wagtail to limit the size of uploaded files. Exactly how this is done will vary based on your hosting environment, but here are a few references for common setups:

- Nginx: clientmaxbodysize - Apache: LimitRequestBody - Cloudflare: Already imposes a limit of 100MB - 500MB depending on plan - CloudFront: SizeConstraint - Traefik: traefik.http.middlewares.limit.buffering.maxRequestBodyBytes

The changes themselves are deep inside Wagtail, making patching incredibly difficult.

Impact

A stored cross-site scripting (XSS) vulnerability exists on ModelAdmin views within the Wagtail admin interface. A user with a limited-permission editor account for the Wagtail admin could potentially craft pages and documents that, when viewed by a user with higher privileges, could perform actions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, and only affects sites with ModelAdmin enabled.

- For page, the vulnerability is in the "Choose a parent page" ModelAdmin view (ChooseParentView), available when managing pages via ModelAdmin. - For documents, the vulnerability is in the ModelAdmin Inspect view (InspectView) when displaying document fields.

Patches

Patched versions have been released as Wagtail 4.1.4 (for the LTS 4.1 branch) and Wagtail 4.2.2 (for the current 4.2 branch).

Workarounds

Site owners who are unable to upgrade to the new versions can disable or override the corresponding functionality.

ChooseParentView

For ChooseParentView:

- Disable ModelAdmin for all page models. - Or provide a custom view via chooseparentviewclass, with the custom view overriding the getform method.

One of those steps need to be applied for every ModelAdmin class hooked into Wagtail where the model is a Wagtail Page or sub-class. Here is an example of implementing the custom ChooseParentView with patched HTML escaping:

python from django import forms from django.utils.translation import gettext as from wagtail.contrib.modeladmin.views import ChooseParentView from wagtail.contrib.modeladmin.forms import ParentChooserForm

class PatchedPageChoiceField(forms.ModelChoiceField): """PageChoiceField with plain-text breadcrumbs to patch stored XSS.""" def labelfrominstance(self, obj): bits = [] for ancestor in ( obj.getancestors(inclusive=True).exclude(depth=1).specific(defer=True) ): bits.append(ancestor.getadmindisplaytitle()) return ' | '.join(bits)

class PatchedParentChooserForm(ParentChooserForm): """ParentChooserForm with custom parentpage to patch stored XSS.""" parentpage = PatchedPageChoiceField( label=("Parent page"), required=True, emptylabel=None, queryset=Page.objects.none(), widget=forms.RadioSelect(), )

class PatchedChooseParentView(ChooseParentView): """ChooseParentView with custom getform patch stored XSS.""" def getform(self, request): parents = self.permissionhelper.getvalidparentpages(request.user) return PatchedParentChooserForm(parents, request.POST or None)

InspectView

For InspectView:

- Remove inspectviewenabled=True or set it to False to disable the view. - Or use inspectviewfields or inspectviewfieldsexclude to prevent displaying document fields in the views. - Or provide a custom view via inspectviewclass, with the custom view overriding the getdocumentfielddisplay method.

One of those steps need to be applied for every ModelAdmin class hooked into Wagtail where inspectviewenabled=True. Here is an example of implementing the custom InspectView with patched HTML escaping:

python from django.template.defaultfilters import filesizeformat from django.utils.html import formathtml from wagtail.contrib.modeladmin.views import InspectView

class PatchedInspectView(InspectView): """InspectView with override to patch stored XSS vulnerability.""" def getdocumentfielddisplay(self, fieldname, field): """Render a link to a document""" document = getattr(self.instance, fieldname) if document: return formathtml( '<a href="{}">{} <span class="meta">({}, {})</span></a>', document.url, document.title, document.fileextension.upper(), filesizeformat(document.file.size), ) return self.modeladmin.getemptyvaluedisplay(fieldname)

Impact When notifications for new replies in comment threads are sent, they are sent to all users who have replied or commented anywhere on the site, rather than only in the relevant threads. This means that a user could listen in to new comment replies on pages they have not had editing access to, as long as they have left a comment or reply somewhere on the site.

Patches A patched version has been released as Wagtail 2.15.2 (for the current LTS), which restores the intended behaviour - to send notifications for new replies to the participants in the active thread only (editing permissions are not considered).

Workarounds New comments can be disabled by setting WAGTAILADMINCOMMENTSENABLED = False in the Django settings file.

Acknowledgements

Many thanks to Ihor Marhitych for identifying this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.io (if you wish to send encrypted email, the public key ID is 0x6ba1e1a86e0f8ce8)

Impact When the {% includeblock %} template tag is used to output the value of a plain-text StreamField block (CharBlock, TextBlock or a similar user-defined block derived from FieldBlock), and that block does not specify a template for rendering, the tag output is not properly escaped as HTML. This could allow users to insert arbitrary HTML or scripting. This vulnerability is only exploitable by users with the ability to author StreamField content (i.e. users with 'editor' access to the Wagtail admin).

Patches Patched versions have been released as Wagtail 2.11.8 (for the LTS 2.11 branch), Wagtail 2.12.5, and Wagtail 2.13.2 (for the current 2.13 branch).

Site implementors who wish to retain the existing behaviour of allowing editors to insert HTML content in these blocks (and are willing to accept the risk of untrusted editors inserting arbitrary code) may disable the escaping by surrounding the relevant {% includeblock %} tag in {% autoescape off %}...{% endautoescape %}.

Workarounds Site implementors who are unable to upgrade to a current supported version should audit their use of {% includeblock %} to ensure it is not used to output CharBlock / TextBlock values with no associated template. Note that this only applies where {% includeblock %} is used directly on that block (uses of includeblock on a block containing a CharBlock / TextBlock, such as a StructBlock, are unaffected). In these cases, the tag can be replaced with Django's {{ ... }} syntax - e.g. {% includeblock mytitleblock %} becomes {{ mytitleblock }}.

Acknowledgements Many thanks to Karen Tracey for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.io (if you wish to send encrypted email, the public key ID is 0x6ba1e1a86e0f8ce8)

Impact When saving the contents of a rich text field in the admin interface, Wagtail does not apply server-side checks to ensure that link URLs use a valid protocol. A malicious user with access to the admin interface could thus craft a POST request to publish content with javascript: URLs containing arbitrary code. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 2.11.7 (for the LTS 2.11 branch) and Wagtail 2.12.4 (for the current 2.12 branch).

Workarounds For sites that cannot easily upgrade to a current supported version, the vulnerability can be patched by adding the following code to a wagtailhooks.py module in any installed app:

python from draftjsexporter.dom import DOM from wagtail.admin.richtext.converters.htmltocontentstate import ExternalLinkElementHandler, PageLinkElementHandler from wagtail.core import hooks from wagtail.core.whitelist import checkurl

def linkentity(props): id = props.get('id') linkprops = {}

if id is not None: linkprops['linktype'] = 'page' linkprops['id'] = id else: linkprops['href'] = checkurl(props.get('url'))

return DOM.createelement('a', linkprops, props['children'])

@hooks.register('registerrichtextfeatures', order=1) def registerlink(features): features.registerconverterrule('contentstate', 'link', { 'fromdatabaseformat': { 'a[href]': ExternalLinkElementHandler('LINK'), 'a[linktype="page"]': PageLinkElementHandler('LINK'), }, 'todatabaseformat': { 'entitydecorators': {'LINK': linkentity} } })

Acknowledgements Many thanks to Kevin Breen for reporting this issue.

For more information If you have any questions or comments about this advisory:

Visit Wagtail's support channels Email us at security@wagtail.io (if you wish to send encrypted email, the public key ID is 0x6ba1e1a86e0f8ce8)

Impact When a form page type is made available to Wagtail editors through the wagtail.contrib.forms app, and the page template is built using Django's standard form rendering helpers such as form.asp (as directed in the documentation), 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; 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.

Patches Patched versions have been released as Wagtail 2.7.4 (for the LTS 2.7 branch) and Wagtail 2.9.3 (for the current 2.9 branch). In these versions, help text will be escaped to prevent the inclusion of HTML tags. 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 WAGTAILFORMSHELPTEXTALLOWHTML = True in their configuration settings.

Workarounds Site owners who are unable to upgrade to the new versions can secure their form page templates by rendering forms field-by-field as per Django's documentation, but omitting the |safe filter when outputting the help text.

Acknowledgements Many thanks to Timothy Bautista for reporting this issue.

For more information If you have any questions or comments about this advisory: Visit Wagtail's support channels Email us at security@wagtail.io (if you wish to send encrypted email, the public key ID is 0x6ba1e1a86e0f8ce8)

Impact A potential timing attack exists on pages or documents that have been protected with a shared password through Wagtail's "Privacy" controls. This password check is performed through a character-by-character string comparison, and so an attacker who is able to measure the time taken by this check to a high degree of accuracy could potentially use timing differences to gain knowledge of the password. (This is understood to be feasible on a local network, but not on the public internet.)

Privacy settings that restrict access to pages / documents on a per-user or per-group basis (as opposed to a shared password) are unaffected by this vulnerability.

Patches Patched versions have been released as Wagtail 2.7.3 (for the LTS 2.7 branch), Wagtail 2.8.2 and Wagtail 2.9.

Workarounds Site owners who are unable to upgrade to the new versions can use user- or group-based privacy restrictions to restrict access to sensitive information; these are unaffected by this vulnerability.

Impact A cross-site scripting (XSS) vulnerability exists on the page revision comparison view within the Wagtail admin interface. A user with a limited-permission editor account for the Wagtail admin could potentially craft a page revision history that, when viewed by a user with higher privileges, could perform actions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

Patches Patched versions have been released as Wagtail 2.7.2 (for the LTS 2.7 branch) and Wagtail 2.8.1 (for the current 2.8 branch).

Workarounds Site owners who are unable to upgrade to the new versions can disable the revision comparison view by adding the following URL route to the top of their project's urls.py configuration:

from django.views.generic.base import RedirectView

urlpatterns = [ url(r'^admin/pages/(\d+)/revisions/compare/', RedirectView.asview(url='/admin/')), # ... ]

Acknowledgements Many thanks to Vlad Gerasimenko for reporting this issue.

For more information If you have any questions or comments about this advisory: Visit Wagtail's support channels Email us at security@wagtail.io (if you wish to send encrypted email, the public key ID is 0x6ba1e1a86e0f8ce8)