The Django Software Foundation is happy to share the contributors selected for Google Summer of Code 2026.

This year, we received over 200 proposals from contributors across the world. The level of detail and thought in these proposals made the selection process both exciting and challenging.

Accepted Projects

We’re pleased to announce the following projects:

Implementing an experimental API framework for Django core

Contributor: Praful Gulani
Mentor: Andrew Miller

This project explores an approach to introducing experimental APIs in Django by modernizing DEP 2 and defining an opt-in model.

Add support for table-valued expressions in the ORM

Contributor: p-r-a-v-i-n
Mentors: Bhuvnesh Sharma, Jacob Walls

This project develops a way to join against table-valued expressions such as Subquery() or PostgreSQL functions like generate_series() within the ORM.

Unified dark mode and UI consistency for Django’s issue tracker

Contributor: Keha Chandrakar
Mentors: Saptak S, Sarah A

This project adds dark mode support to Django’s issue tracker and brings it closer in visual consistency to the main Django website.

Switch to Playwright tests for integration testing

Contributor: Varun Kasyap Pentamaraju
Mentor: Sarah Boyce

This project focuses on improving Django’s browser integration testing by transitioning from Selenium to Playwright.

Each of these projects focuses on areas of Django that we’re looking to improve over the coming months. Contributors will work closely with their mentors, participate in regular check-ins, and engage with the broader Django community.

To everyone who applied

Thank you to everyone who submitted a proposal this year.

We know the effort it takes to explore ideas, write proposals, and engage with the community. Not being selected this time does not reflect the overall quality or potential of your work.

Given the number of applications and that the program is run by a small group of volunteers, we’re not able to provide individual feedback on proposals. Selections are based on a combination of factors including alignment with project goals, feasibility within the program timeline, prior contributions, and clarity of the proposal.

We encourage you to stay involved. Many contributors to Django started in similar positions. Keep building, keep contributing, and stay connected with the community. There will always be more opportunities.

What’s next

The community bonding period has begun, and contributors will soon start working on their projects. We’ll share updates as the program progresses and highlight the work along the way.

Please join us in welcoming the selected contributors and supporting them during the program.

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.5 and Django 5.2.14. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

ASGI requests with a missing or understated Content-Length header could bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit, potentially loading large files into memory and causing service degradation.

As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on FILE_UPLOAD_MAX_MEMORY_SIZE.

This issue has severity "low" according to the Django security policy.

This issue was originally highlighted by Kyle Agronick in Trac. Thanks to Jacob Walls for following up and reporting it.

CVE-2026-35192: Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST

Response headers did not vary on cookies if a session was not modified, but SESSION_SAVE_EVERY_REQUEST was True. A remote attacker could steal a user's session after that user visits a cached public page.

This issue has severity "low" according to the Django security policy.

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: * in UpdateCacheMiddleware

Previously, django.middleware.cache.UpdateCacheMiddleware would erroneously cache requests where the Vary header contained an asterisk ('*'). This could lead to private data being stored and served.

This issue has severity "low" according to the Django security policy.

Thanks to Ahmad Sadeddin for the report.

Affected supported versions

• Django main
• Django 6.0
• Django 5.2

Resolution

Patches to resolve the issue have been applied to Django's main, 6.0, and 5.2 branches. The patches may be obtained from the following changesets.

CVE-2026-5766: Potential denial-of-service vulnerability in ASGI requests via file upload limit bypass

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

CVE-2026-35192: Session fixation via public cached pages and SESSION_SAVE_EVERY_REQUEST

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

CVE-2026-6907: Potential exposure of private data due to incorrect handling of Vary: * in UpdateCacheMiddleware

• On the main branch
• On the 6.0 branch
• On the 5.2 branch

The following releases have been issued

• Django 6.0.5 (tarball | checksums)
• Django 5.2.14 (tarball | checksums)

The PGP key ID used for this release is Sarah Boyce: 3955B19851EA96EF

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.