Ubuntu has issued an advisory on January 14:
https://ubuntu.com/security/notices/USN-7205-1

The Openwall URL lists - with good URLs for the patches & new versions:
* Django 5.1
* Django 5.0
* Django 4.2
but not 4.1.

The Ubuntu URL mentions 3:4.2.x  2:3.2.12  2:2.2.12
"An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions clean_ipv6_address and is_valid_ipv6_address are vulnerable, as is the django.forms.GenericIPAddressField form field. (The django.db.models.GenericIPAddressField model field is not affected.)"

Assignee: bugsquad => python

Suggested advisory:
========================

The updated package fixes security vulnerabilities:

An issue was discovered in Django 4.2 before 4.2.14 and 5.0 before 5.0.7. urlize and urlizetrunc were subject to a potential denial of service attack via certain inputs with a very large number of brackets. (CVE-2024-38875)

An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. The django.contrib.auth.backends.ModelBackend.authenticate() method allows remote attackers to enumerate users via a timing attack involving login requests for users with an unusable password. (CVE-2024-39329)

An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. Derived classes of the django.core.files.storage.Storage base class, when they override generate_filename() without replicating the file-path validations from the parent class, potentially allow directory traversal via certain inputs during a save() call. (CVE-2024-39330)

An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. get_supported_language_variant() was subject to a potential denial-of-service attack when used with very long strings containing specific characters. (CVE-2024-39614)

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent. (CVE-2024-41989)

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize() and urlizetrunc() template filters are subject to a potential denial-of-service attack via very large inputs with a specific sequence of characters. (CVE-2024-41990)

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize and urlizetrunc template filters, and the AdminURLFieldWidget widget, are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters. (CVE-2024-41991)

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. QuerySet.values() and values_list() methods on models with a JSONField are subject to SQL injection in column aliases via a crafted JSON object key as a passed *arg. (CVE-2024-42005)

An issue was discovered in Django 5.1 before 5.1.1, 5.0 before 5.0.9, and 4.2 before 4.2.16. The urlize() and urlizetrunc() template filters are subject to a potential denial-of-service attack via very large inputs with a specific sequence of characters. (CVE-2024-45230)

An issue was discovered in Django v5.1.1, v5.0.9, and v4.2.16. The django.contrib.auth.forms.PasswordResetForm class, when used in a view implementing password reset flows, allows remote attackers to enumerate user e-mail addresses by sending password reset requests and observing the outcome (only when e-mail sending is consistently failing). (CVE-2024-45231)

An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities. (CVE-2024-53907)

An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (CVE-2024-53908)

An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions clean_ipv6_address and is_valid_ipv6_address are vulnerable, as is the django.forms.GenericIPAddressField form field. (CVE-2024-56374)

References:
https://www.openwall.com/lists/oss-security/2024/07/09/3
https://www.djangoproject.com/weblog/2024/jul/09/security-releases/
https://bugs.mageia.org/show_bug.cgi?id=33387
https://www.cve.org/CVERecord?id=CVE-2024-38875
https://www.cve.org/CVERecord?id=CVE-2024-39329
https://www.cve.org/CVERecord?id=CVE-2024-39330
https://www.cve.org/CVERecord?id=CVE-2024-39614
https://openwall.com/lists/oss-security/2024/08/06/2
https://www.openwall.com/lists/oss-security/2024/09/03/3
https://openwall.com/lists/oss-security/2024/12/04/3
https://bugs.mageia.org/show_bug.cgi?id=33507
https://www.cve.org/CVERecord?id=CVE-2024-41989
https://www.cve.org/CVERecord?id=CVE-2024-41990
https://www.cve.org/CVERecord?id=CVE-2024-41991
https://www.cve.org/CVERecord?id=CVE-2024-42005
https://www.cve.org/CVERecord?id=CVE-2024-45230
https://www.cve.org/CVERecord?id=CVE-2024-45231
https://www.cve.org/CVERecord?id=CVE-2024-53907
https://www.cve.org/CVERecord?id=CVE-2024-53908
https://www.openwall.com/lists/oss-security/2025/01/14/2
https://ubuntu.com/security/notices/USN-7205-1
========================

Updated package in core/updates_testing:
========================
python3-django-4.1.13-1.2.mga9

from SRPM:
python-django-4.1.13-1.2.mga9.src.rpm

Assignee: python => qa-bugs
Version: Cauldron => 9
Status: NEW => ASSIGNED
Blocks: (none) => 33387, 33507
Whiteboard: MGA9TOO => (none)
Status comment: Fixed upstream in 5.1.5 and patches available from Ubuntu => (none)
Source RPM: python-django-5.1.4-1.mga10.src.rpm, python-django-4.1.13-1.1.mga9.src.rpm => python-django-4.1.13-1.1.mga9.src.rpm

RH x86_64

installing python3-django-4.1.13-1.2.mga9.noarch.rpm from //home/katnatek/qa-testing/x86_64
Preparing...                     ##################################################################################################
      1/1: python3-django        ##################################################################################################
      1/1: removing python3-django-4.1.13-1.1.mga9.noarch
                                 ##################################################################################################

Ref bug#32944 comment#3

django-admin startproject mysite
tree mysite
mysite
├── manage.py
└── mysite
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

2 directories, 6 files

python manage.py migrate
python: can't open file '/home/katnatek/qatest/manage.py': [Errno 2] No such file or directory

cd mysite/
python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying sessions.0001_initial... OK

python manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
February 04, 2025 - 19:54:44
Django version 4.1.13, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

The result open http://127.0.0.1:8000/ in browser is as described
Give Ok

Whiteboard: (none) => MGA9-64-OK
CC: (none) => andrewsfarm

Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2025-0039.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED