When we learned that the Django Software Foundation has been accepted as a mentoring organization for Google Summer of Code 2026, it marked another steady milestone in a long-standing relationship. Django first participated in GSoC in 2006, and 2026 represents our 21st consecutive year in the program. Over two decades, GSoC has become a consistent pathway for contributors to engage more deeply with Django — not just through a summer project, but often through continued involvement that extends well beyond the official coding period. For many of you reading this, this might be your first exposure to how Django’s open source ecosystem works. So before we get into applications and expectations, let’s take a step back and understand the environment you’re stepping into. Understanding the Django Ecosystem The Django Software Foundation (DSF) is the non-profit organization that supports the long-term sustainability of Django. Django itself is developed entirely in the open. Feature discussions, architectural debates, bug reports, design proposals, and code reviews all happen publicly. That openness is intentional. It allows anyone, from anywhere in the world, to participate. But it also means decisions are rarely made quickly or casually. Changes are discussed carefully. Trade-offs are evaluated. Backwards compatibility is taken seriously. If you are new, it helps to understand the main spaces where this work happens: The Django Forum is where broader discussions take place — new feature ideas, design direction, and community conversations. Django Trac is the issue tracker, where bugs, feature requests, and patches are formally recorded and reviewed. If no one is working on an issue, you can assign it yourself and start working on it. Code contributions happen through pull requests, where proposed changes are reviewed, tested, and discussed in detail before being merged. New features are proposed and discussed in the new-features repository. There is a project board view that shows the state of each proposal. For someone new, this ecosystem can feel overwhelming at first. Threads may reference decisions made years ago. Review comments can be detailed. Standards are high. That is precisely why GSoC matters to us. It provides a structured entry point into this culture, with mentorship and guidance along the way, helping contributors understand not just how to write code — but how Django evolves. Why the Django Forum Is Central Most GSoC journeys in Django begin on the Django Forum — the community’s public space for technical discussions about features, design decisions, and improvements to Django. Introducing yourself there is not a formality; it is often your first real contribution. When you discuss a project idea publicly, you demonstrate how you think, how you respond to feedback, and how you handle technical trade-offs. Questions and challenges from mentors are not barriers — they are part of the collaborative design process. Proposals that grow through open discussion on the Forum are almost always stronger than those written in isolation. What To Do If you are planning to apply for GSoC 2026 with Django, here is what we strongly encourage: Start early. Do not wait until the application window opens. Begin discussions well in advance. Engage publicly. Introduce yourself on the Forum. Participate in ongoing threads. Show consistent involvement rather than one-time activity. Demonstrate understanding(very important) Read related tickets and past discussions. Reference them in your proposal. Show that you understand the technical and philosophical context. Be realistic about scope. Ambitious ideas are welcome, but they must be grounded in technical feasibility within the GSoC timeframe. Show iteration. If your proposal evolves because of feedback, that is a positive signal. It shows adaptability and thoughtful engagement. What Not To Do Equally important are the expectations around what we will not consider. Do not submit a proposal without prior discussion. A proposal that appears for the first time in the application form, without any Forum engagement, will be at a disadvantage. Do not generate a proposal using AI and submit it as-is. If a proposal is clearly AI-generated, lacks discussion history, and shows no evidence of personal understanding, it will be rejected. We evaluate your reasoning process, not just the surface quality of the document. Do not copy previous proposals. Each year’s context is different. We expect original thinking and up-to-date understanding. Do not treat GSoC as a solo internship. Django development is collaborative. If you are uncomfortable discussing ideas publicly or receiving detailed feedback, this may not be the right fit. Do not submit empty or placeholder proposal documents. In previous years, we have received blank or near-empty submissions, which create unnecessary effort for volunteer reviewers. Such proposals will not be considered. Do not repeatedly tag or ping maintainers for reviews. Once you’ve submitted your proposal or patch, give reviewers time to respond. Maintainers are volunteers managing many responsibilities, and repeated tagging does not speed up the process. Patience and respectful follow-ups (after a reasonable interval) are appreciated. On AI Usage We recognize that AI tools are now part of many developers’ workflows. Using AI to explore documentation, clarify syntax, or organize thoughts is not inherently a problem. However, AI must not replace ownership. You should be able to clearly explain your architectural decisions, justify trade-offs, and respond thoughtfully when challenged. If you cannot defend your own proposal without external assistance, it signals a lack of readiness for this kind of work. The quality we look for is not perfect language — it is depth of understanding. I’m a First-Time Contributor to Django — What Should I Do? If this is your first time contributing to Django, start simple and start early. First, spend some time understanding how Django works as an open source project. Read a few recent discussions on the Django Forum and browse open tickets to see the kinds of problems being discussed. Next, introduce yourself on the Forum. Share your background briefly and mention what areas interest you. You don’t need to have a perfect project idea on day one — curiosity and willingness to learn matter more. Then: Read the official first time contributor guide carefully. Try setting up Django locally and run the test suite. Look for small tickets on trac (including documentation or cleanup tasks) to understand the workflow. Ask questions on the Forum or in Discord if something is unclear. Most importantly, be patient with yourself. Django is a mature and widely used framework, and it takes time to understand its design principles and contribution standards. Strong contributors are not the ones who know everything at the start — they are the ones who show up consistently, engage thoughtfully, and improve through feedback. To conclude We are excited to welcome a new group of contributors into the Django ecosystem through Google Summer of Code 2026. We look forward to thoughtful ideas, constructive discussions, and a summer of meaningful collaboration — built not just on code, but on understanding and shared responsibility.

For February 2026, we welcome Baptiste Mispelon as our DSF member of the month! ⭐ Photo by Bartek Pawlik - bartpawlik.format.com Baptiste is a long-time Django and Python contributor who co-created the Django Under the Hood conference series and serves on the Ops team maintaining its infrastructure. He has been a DSF member since November 2014. You can learn more about Baptiste by visiting Baptiste's website and his GitHub Profile. Let’s spend some time getting to know Baptiste better! Can you tell us a little about yourself? (hobbies, education, etc) I'm a French immigrant living in Norway. In the day time I work as software engineer at Torchbox building Django and Wagtail sites. Education-wise I'm a "self-taught" (whatever that means) developer and started working when I was very young. In terms of hobbies, I'm a big language nerd and I'm always up for a good etymology fact. I also enjoy the outdoor whether it's on a mountain bike or on foot (still not convinced by this skiing thing they do in Norway, but I'm trying). How did you start using Django? I was working in a startup where I had built an unmaintainable pile of custom framework-less PHP code. I'd heard of this cool Python framework and thought it would help me bring some structure to our codebase. So I started rewriting our services bit-by-bit and eventually switched everything to Django after about a year. In 2012, I bought a ticket to DjangoCon Europe in Zurich and went there not knowing anyone. It was one of the best decisions of my life: the Django community welcomed me and has given me so much over the years. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? I've been making website for more than two decades now, so I've used my fair share of various technologies and frameworks, but Django is still my "daily driver" and the one I like the best. I like writing plain CSS, and when I need some extra bit of JS I like to use Alpine JS and/or HTMX: I find they work really well together with Django. If I had magical powers and could change anything, I would remove the word "patch" from existence (and especially from the Django documentation). What projects are you working on now? I don't have any big projects active at the moment, I'm mostly working on client projects at work. Which Django libraries are your favorite (core or 3rd party)? My favorite Django library of all time is possibly django-admin-dracula. It's the perfect combination of professional and whimsical for me. Other than that I'm also a big fan of the Wagtail CMS. I've been learning more and more about it in the past year and I've really been liking it. The code feels very Django-y and the community around it is lovely as well. What are the top three things in Django that you like? 1) First of course is the people. I know it's a cliche but the community is what makes Django so special. 2) In terms of the framework, what brought me to it in the first place was its opinionated structure and settings. When I started working with Django I didn't really know much about web development, but Django's standard project structure and excellent defaults meant that I could just use things out of the box knowing I was building something solid. And more than that, as my skills and knowledge grew I was able to swap out those defaults with some more custom things that worked better for me. There's room to grow and the transition has always felt very smooth for me. 3) And if I had to pick a single feature, then I'd go for one that I think is underrated: assertQuerySetEqual(). I think more people should be using it! What is it like to be in the Ops team? It's both very exciting and very boring 😅 Most of the tasks we do are very mundane: create DNS records, update a server, deploy a fix. But because we have access and control over a big part of the infrastructure that powers the Django community, it's also a big responsibility which we don't take lightly. I know you were one of the first members of the Django Girls Foundation board of directors. That's amazing! How did that start for you? By 2014 I'd become good friend with Ola & Ola and in July they asked me to be a coach at the very first Django Girls workshop at EuroPython in Berlin. The energy at that event was amazing an unlike any other event I'd been a part of, so I got hooked. I went on to coach at many other workshops after that. When Ola & Ola had the idea to start an official entity for Django Girls, they needed a token white guy and I gladly accepted the role! You co-created Django Under the Hood series which, from what I've heard, was very successful at the time. Can you tell us a little more about this conference and its beginnings? I'm still really proud of having been on that team and of what we achieved with this conference. So many stories to tell! I believe it all started at the Django Village conference where Marc Tamlin and I were looking for ideas for how to bring the Django core team together. We thought that having a conference would be a good way to give an excuse (and raise funds) for people to travel all to the same place and work on Django. Somehow we decided that Amsterdam was the perfect place for that. Then we were extremely lucky that a bunch of talented folks actually turned that idea into a reality: Sasha, Ola, Tomek, Ola, Remco, Kasia (and many others) 💖. As a former conference organizer and volunteer, do you have any recommendations for those who want to contribute or organize a conference? I think our industry (and even the world in general) is in a very different place today than a decade ago when I was actively organizing conferences. Honestly I'm not sure it would be as easy today to do the things we've done. My recommendation is to do it if you can. I've forged some real friendships in my time as an organizer, and as exhausting and stressful as it can be, it's also immensely rewarding in its own way. The hard lesson I'd also give is that you should pay attention to who gets to come to your events, and more importantly who doesn't. Organizing a conference is essentially making a million decisions, most of which are really boring. But every decision you make has an effect when it's combined with all the others. The food you serve or don't serve, the time of year your event takes place, its location. Whether you spend your budget on fun tshirts, or on travel grants. All of it makes a difference somehow. Do you remember your first contribution in Django? I do! It was commit ac8eb82abb23f7ae50ab85100619f13257b03526: a one character typo fix in an error message 😂 Is there anything else you’d like to say? Open source is made of people, not code. You'll never go wrong by investing in your community. Claude will never love you back. Thank you for doing the interview, Baptiste !

Last month we announced our plan to adopt Contributor Covenant 3 as Django's new Code of Conduct through a multi-step process. Today we're excited to share that we've completed the first step of that journey! What We've Done We've merged new documentation that outlines how any member of the Django community can propose changes to our Code of Conduct and related policies. This creates a transparent, community-driven process for keeping our policies current and relevant. The new process includes: Proposing Changes: Anyone can open an issue with a clear description of their proposed change and the rationale behind it. Community Review: The Code of Conduct Working Group will discuss proposals in our monthly meetings and may solicit broader community feedback through the forum, Discord, or DSF Slack. Approval and Announcement: Once consensus is reached, changes are merged and announced to the community. Changes to the Code of Conduct itself will be sent to the DSF Board for final approval. How You Can Get Involved We welcome and encourage participation from everyone in the Django community! Here's how you can engage with this process: Share Your Ideas: If you have suggestions for improving our Code of Conduct or related documentation, open an issue on our GitHub repo. Join the Discussion: Participate in community discussions about proposed changes on the forum, Discord, or DSF Slack. Keep it positive, constructive, and respectful. Stay Informed: Watch the Code of Conduct repository to follow along with proposed changes and discussions. Provide Feedback: Not comfortable with GitHub? You can also reach out via conduct@djangoproject.com, or look for anyone with the Code of Conduct WG role on Discord. What's Next We're moving forward with the remaining steps of our plan: Step 2 (target: March 15): Update our Enforcement Manual, Reporting Guidelines, and FAQs via pull request 91. Step 3 (target: April 15): Adopt the Contributor Covenant 3 with proposed changes from the working group. Each step will have its own pull request where the community can review and provide feedback before we merge. We're committed to taking the time needed to incorporate your input thoughtfully. Thank you for being part of this important work to make Django a more welcoming and inclusive community for everyone!

The members of the Steering Council wanted to provide you all with a quick TL;DR of our work in 2025. First off, we were elected at the end of 2024 and got started in earnest in early 2025 with the mission to revive and dramatically increase the role of the Steering Council. We're meeting for a video conference at least monthly, you can deep dive into the meeting notes to see what we've been up to. We also have set up Slack channels we use to communicate in between meetings to keep action items moving along. One of the first things we did was temporarily suspend much of the process around DEP 10. Its heart is in the right place, but it's just too complex and cumbersome day-to-day with a primarily volunteer organization. We're slowly making progress on a revamped and simplified process that addresses our concerns. It is our goal to finish this before our terms expire. New Features Process We've moved the process for proposing new features out of the Django Forum and mailing lists to new-features Github repository. We made this change for a variety of reasons, but the largest being to reduce the workload for the Django Fellows in shepherding the process and answering related questions. Community Ecosystem Page One of our main goals is to increase the visibility of the amazing Django third-party package ecosystem. Long time Django users know which packages to use, which you can trust, and which ones may be perfect for certain use cases. However, MANY newer or more casual Django users are often unaware of these great tools and not sure where to even begin. As a first step, we've added the Community Ecosystem page which highlights several amazing resources to keep in touch with what is going on with Django, how to find recommended packages, and a sample list of those packages the Steering Council itself recommends and uses frequently. Administrative bits There has been work on better formalizing and documenting our processes and building documentation to make it much easier for the next Steering Council members. There has also been fair bit of work around helping organize Google Summer of Code participants to help ensure the projects undertaken are ones that will ultimately be accepted smoothly into Django. Another area we have focused on is a simplified DEP process. We're still formalizing this, but the idea is to have the Steering Council do the majority of the heavy lifting on writing these and in a format that is shorter/simpler to reduce the friction of creating larger more complicated DEPs. We have also been in discussions with various third parties about acquiring funding for some of the new features and updates on the horizon. It's been a productive year and we're aiming to have 2026 be as productive if not more so. We're still setting all of our 2026 goals and will report on those soon. Please reach out to the Steering Council directly if you have any questions or concerns.

Yesterday, Django issued security releases mitigating six vulnerabilities of varying severity. Django is a secure web framework, and that hasn’t changed. What feels new is the remarkable consistency across the reports we receive now. Almost every report now is a variation on a prior vulnerability. Instead of uncovering new classes of issues, these reports explore how an underlying pattern from a recent advisory might surface in a similar code path or under a slightly different configuration. These reports are often technically plausible but only sometimes worth fixing. Over time, this has shifted the Security Team’s work away from discovery towards deciding how far a given precedent should extend and whether the impact of the marginal variation rises to the level of a vulnerability. Take yesterday’s releases: We patched a “low” severity user enumeration vulnerability in the mod_wsgi authentication handler (CVE 2025-13473). It’s a straightforward variation on CVE 2024-39329, which affected authentication more generally. We also patched two potential denial-of-service vulnerabilities when handling large, malformed inputs. One exploits inefficient string concatenation in header parsing under ASGI (CVE 2025-14550). Concatenating strings in a loop is known to be slow, and we’ve done fixes in public where the impact is low. The other one (CVE 2026-1285) exploits deeply nested entities. December’s vulnerability in the XML serializer (CVE 2025-64460) was about those very two themes. Finally, we also patched three potential SQL injection vulnerabilities. One envisioned a developer passing unsanitized user input to a niche feature of the PostGIS backend (CVE 2026-1207), much like CVE 2020-9402. Our security reporting policy assumes that developers are aware of the risks when passing unsanitized user input directly to the ORM. But the division between SQL statements and parameters is well ingrained, and the expectation is that Django will not fail to escape parameters. The last two vulnerabilities (CVE 2026-1287 and CVE 2026-1312) targeted user-controlled column aliases, the latest in a stream of reports stemming from CVE 2022-28346, involving unpacking **kwargs into .filter() and friends, including four security releases in a row in late 2025. You might ask, “who would unpack **kwargs into the ORM?!” But imagine letting users name aggregations in configurable reports. You would have something more like a parameter, and so you would appreciate some protection against crafted inputs. On top of all that, on a nearly daily basis we get reports duplicating other pending reports, or even reports about vulnerabilities that have already been fixed and publicized. Clearly, reporters are using LLMs to generate (initially) plausible variations. Security releases come with costs to the community. They interrupt our users’ development workflows, and they also severely interrupt ours. There are alternatives. The long tail of reports about user-controlled aliases presents an obvious one: we can just re-architect that area. (Thanks to Simon Charette for a pull request doing just that!) Beyond that, there are more drastic alternatives. We can confirm fewer vulnerabilities by placing a higher value on a user's duty to validate inputs, placing a lower value on our prior precedents, or fixing lower severity issues publicly. The risk there is underreacting, or seeing our development workflow disrupted anyway when a decision not to confirm a vulnerability is challenged. Reporters are clearly benefiting from our commitment to being consistent. For the moment, the Security Team hopes that reacting in a consistent way—even if it means sometimes issuing six patches—outweighs the cost of the security process. It’s something we’re weighing. As always, keep the responsibly vetted reports coming to security@djangoproject.com.

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.2, Django 5.2.11, and Django 4.2.28. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible. CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler The django.contrib.auth.handlers.modwsgi.check_password() function for authentication via mod_wsgi allowed remote attackers to enumerate users via a timing attack. Thanks to Stackered for the report. This issue has severity "low" according to the Django security policy. CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI When receiving duplicates of a single header, ASGIRequest allowed a remote attacker to cause a potential denial-of-service via a specifically created request with multiple duplicate headers. The vulnerability resulted from repeated string concatenation while combining repeated headers, which produced super-linear computation resulting in service degradation or outage. Thanks to Jiyong Yang for the report. This issue has severity "moderate" according to the Django security policy. CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS Raster lookups on GIS fields (only implemented on PostGIS) were subject to SQL injection if untrusted data was used as a band index. As a reminder, all untrusted user input should be validated before use. Thanks to Tarek Nakkouch for the report. This issue has severity "high" according to the Django security policy. CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True) and truncatechars_html and truncatewords_html template filters were subject to a potential denial-of-service attack via certain inputs with a large number of unmatched HTML end tags, which could cause quadratic time complexity during HTML parsing. Thanks to Seokchan Yoon for the report. This issue has severity "moderate" according to the Django security policy. CVE-2026-1287: Potential SQL injection in column aliases via control characters FilteredRelation was subject to SQL injection in column aliases via control characters, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias(). Thanks to Solomon Kebede for the report. This issue has severity "high" according to the Django security policy. CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation QuerySet.order_by() was subject to SQL injection in column aliases containing periods when the same alias was, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation. Thanks to Solomon Kebede for the report. This issue has severity "high" according to the Django security policy. Affected supported versions Django main Django 6.0 Django 5.2 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 6.0, 5.2, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1287: Potential SQL injection in column aliases via control characters On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch The following releases have been issued Django 6.0.2 (download Django 6.0.2 | 6.0.2 checksums) Django 5.2.11 (download Django 5.2.11 | 5.2.11 checksums) Django 4.2.28 (download Django 4.2.28 | 4.2.28 checksums) The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7 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.