Wagtail 6.0.3 release notes¶

CVE-2024-32882: Permission check bypass when editing a model with per-field restrictions through wagtail.contrib.settings or ModelViewSet¶

This release addresses a permission vulnerability in the Wagtail admin interface. If a model has been made available for editing through the wagtail.contrib.settings module or ModelViewSet, and the permission argument on FieldPanel has been used to further restrict access to one or more fields of the model, a user with edit permission over the model but not the specific field can craft an HTTP POST request that bypasses the permission check on the individual field, allowing them to update its value.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, or by a user who has not been granted edit access to the model in question. The editing interfaces for pages and snippets are also unaffected.

Many thanks to Ben Morse and Joshua Munn for reporting this issue, and Jake Howard and Sage Abdullah for the fix. For further details, please see the CVE-2024-32882 security advisory.

Bug fixes¶

• Respect WAGTAIL_ALLOW_UNICODE_SLUGS setting when auto-generating slugs (LB (Ben) Johnston)

• Use correct URL when redirecting back to page search results after an AJAX search (Sage Abdullah)

• Reinstate missing static files in style guide (Sage Abdullah)

• Provide convert_mariadb_uuids management command to assist with upgrading to Django 5.0+ on MariaDB (Matt Westcott)

• Fix generic CopyView for models with primary keys that need to be quoted (Sage Abdullah)

Changes to UUID fields on MariaDB when upgrading to Django 5.0¶

Django 5.0 introduces support for MariaDB’s native UUID type on MariaDB 10.7 and above. This breaks backwards compatibility with CHAR-based UUIDs created on earlier versions of Django and MariaDB, and so upgrading a site to Django 5.0+ and MariaDB 10.7+ is liable to result in errors such as Data too long for column 'translation_key' at row 1 or Data too long for column 'uuid' at row 1 when creating or editing pages. To fix this, it is necessary to run the convert_mariadb_uuids management command (available as of Wagtail 6.0.3) after upgrading:

./manage.py convert_mariadb_uuids

This will convert all existing UUID fields used by Wagtail to the new format. New sites created under Django 5.0+ and MariaDB 10.7+ are unaffected.