Thanks to the work of the Security Developer-in-Residence Seth Larson, the Python Security Response Team (PSRT) now has an approved (PEP 811). Following the new governance structure the PSRT now , has documented and , and a defined process for to balance the needs of security and sustainability. The document also clarifies the relationship between the and the PSRT. public governance document publishes a public list of members responsibilities for members admins onboarding and offboarding members Python Steering Council And this new onboarding process is already working! The PSF Infrastructure Engineer, Jacob Coffee, has just joined the PSRT as the first new non-"Release Manager" member since Seth joined the PSRT in 2023. We expect new members to join further bolstering the sustainability of security work for the Python programming language. Thanks to for their support of Python ecosystem security by sponsoring Seth’s work as the Security Developer-in-Residence at the Python Software Foundation. Alpha-Omega Security doesn't happen by accident: it's thanks to the work of volunteers and paid Python Software Foundation staff on the Python Security Response Team to triage and coordinate vulnerability reports and remediations keeping all Python users safe. Just last year the PSRT published 16 vulnerability advisories for CPython and pip, And the PSRT usually can’t do this work alone, PSRT coordinators are encouraged to involve maintainers and experts on the projects and submodules. By involving the experts directly in the remediation process ensures fixes adhere to existing API conventions and threat-models, are maintainable long-term, and have minimal impact on existing use-cases. Sometimes the PSRT even coordinates with other open source projects to avoid catching the Python ecosystem off-guard by publishing a vulnerability advisory that affects multiple other projects. The most recent example of this is PyPI’s . ZIP archive differential attack mitigation This work deserves just like contributions to source code and documentation. Seth and Jacob are developing further improvements to workflows involving “GitHub Security Advisories” to record the reporter, coordinator, and remediation developers and reviewers to CVE and OSV records to properly thank everyone involved in the otherwise private contribution to open source projects. recognition and celebration Maybe you’ve read all this and are interested in directly helping the Python programming language be more secure! The process is , you need an existing PSRT member to nominate you and for your nomination to receive at least ⅔ positive votes from existing PSRT members. similar to the Core Team nomination process You do not need to be a core developer, team member, or triager to be a member of the Python Security Response Team. Anyone with security expertise that is known and highly-trusted within the Python community and has time to volunteer or donate through their employer would make a good candidate for the PSRT. Please note that all PSRT team members and are expected to contribute meaningfully to the remediation of vulnerabilities. have documented responsibilities Being a member of the PSRT is not required and shouldn’t be to receive “early notification” of vulnerabilities affecting CPython and pip. The Python Software Foundation is a and publishes CVE and records with up-to-date information about vulnerabilities affecting CPython and pip. to be notified of vulnerabilities CVE Numbering Authority OSV

www.python.org/downloads/release/python-3150a6/ Python 3.15 is still in development. This release, 3.15.0a6, is the sixth of eight planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2026-05-05) and, if necessary, may be modified or deleted up until the release candidate phase (2026-07-28). Please keep in mind that this is a preview release and its use is recommended for production environments. Many new features for Python 3.15 are still being planned and written. Among the new major new features and changes so far: The next pre-release of Python 3.15 will be 3.15.0a7, currently scheduled for 2026-03-10. By reason of these things, then, the whaling voyage was welcome; the great flood-gates of the wonder-world swung open, and in the wild conceits that swayed me to my purpose, two and two there floated into my inmost soul, endless processions of the whale, and, mid most of them all, one grand hooded phantom, like a snow hill in the air. Thanks to all of the many volunteers who help make Python development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards as the snow slowly falls in Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower �ukasz Langa

Python 3.14.3 is the third maintenance release of 3.14, containing around 299 bugfixes, build improvements and documentation changes since 3.14.2. Some of the major new features and changes in Python 3.14 are: For more details on the changes to Python 3.14, see . What’s new in Python 3.14 The installer we offer for Windows is being replaced by our new install manager, which can be installed from  or from its . See  for more information. The JSON file available for download contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. the Windows Store download page our documentation Python 3.13.12 is  now available! Python 3.13.12 is the twelfth maintenance release of 3.13, containing around 250 bugfixes, build improvements and documentation changes since 3.13.11. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from an international releasing task force spread out over a whopping 10 timezones this time, Your release team,Thomas Wouters Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

www.python.org/downloads/release/python-3150a5/ Python 3.15 is still in development. This release, 3.15.0a5, is the fifth of eight planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2026-05-05) and, if necessary, may be modified or deleted up until the release candidate phase (2026-07-28). Please keep in mind that this is a preview release and its use is recommended for production environments. Many new features for Python 3.15 are still being planned and written. Among the new major new features and changes so far: The next pre-release of Python 3.15 will be 3.15.0a6, currently scheduled for 2026-02-10. At last it was given out that some time next day the ship would certainly sail. So next morning, Queequeg and I took a very early start. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from a still snowfully subzero Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower �ukasz Langa

www.python.org/downloads/release/python-3150a4/ Python 3.15 is still in development. This release, 3.15.0a4, is the fourth of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2026-05-05) and, if necessary, may be modified or deleted up until the release candidate phase (2026-07-28). Please keep in mind that this is a preview release and its use is recommended for production environments. Many new features for Python 3.15 are still being planned and written. Among the new major new features and changes so far: The next pre-release of Python 3.15 will be 3.15.0a5, currently scheduled for 2026-02-10. Upon this every soul was confounded; for the phenomenon just then observed by Ahab had unaccountably escaped every one else; but its very blinding palpableness must have been the cause. Thrusting his head half way into the binnacle, Ahab caught one glimpse of the compasses; his uplifted arm slowly fell; for a moment he almost seemed to stagger. Standing behind him Starbuck looked, and lo! the two compasses pointed East, and the Pequod was as infallibly going West. But ere the first wild alarm could get out abroad among the crew, the old man with a rigid laugh exclaimed, “I have it! It has happened before. Mr. Starbuck, last night’s thunder turned our compasses—that’s all. Thou hast before now heard of such a thing, I take it.” “Aye; but never before has it happened to me, sir,” said the pale mate, gloomily. Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from a snowfully subzero Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

www.python.org/downloads/release/python-3150a3/ Python 3.15 is still in development. This release, 3.15.0a3, is the third of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2026-05-05) and, if necessary, may be modified or deleted up until the release candidate phase (2026-07-28). Please keep in mind that this is a preview release and its use is recommended for production environments. Many new features for Python 3.15 are still being planned and written. Among the new major new features and changes so far: The next pre-release of Python 3.15 will be 3.15.0a4, currently scheduled for 2026-01-13. Instantly the captain ran forward, and in a loud voice commanded his crew to desist from hoisting the cutting-tackles, and at once cast loose the cables and chains confining the whales to the ship. “What now?” said the Guernsey-man, when the Captain had returned to them. “Why, let me see; yes, you may as well tell him now that—that—in fact, tell him I’ve diddled him, and (aside to himself) perhaps somebody else.” Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from an even deeper darker Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Å�ukasz Langa

Two more, just three days after the last? Yes! We found some regressions, so here’s an expedited pair of releases. They also come with some bonus security fixes. www.python.org/downloads/release/python-3142/ Python 3.14.2 is the second maintenance release of 3.14, containing 18 bugfixes, build improvements and documentation changes since 3.14.1. This is an expedited release to fix the following regressions: : Exceptions in in running programs while upgrading Python. gh-142206 : Exceptions in dataclasses without method. gh-142214 : Segmentation faults and assertion failures in insertdict. gh-142218 : Crash when using multiple capturing groups in gh-140797 And these security fixes: : Remove quadratic behavior in node ID cache clearing () gh-142145 CVE-2025-12084 : Fix a potential virtual memory allocation denial of service in http.server gh-119452 See the full . changelog www.python.org/downloads/release/python-31311/ Python 3.13.11 is the eleventh maintenance release of 3.13. This is an expedited release to fix the following regressions: : Exceptions in in running programs while upgrading Python. gh-142206 : Segmentation faults and assertion failures in insertdict. gh-142218 : Crash when using multiple capturing groups in gh-140797 And these security fixes: : Remove quadratic behavior in node ID cache clearing () gh-142145 CVE-2025-12084 : Fix a potential denial of service in http.client gh-119451 : Fix a potential virtual memory allocation denial of service in http.server gh-119452 See the full . changelog Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the . Python Software Foundation Regards from deeper darker Helsinki, Your release team, Hugo van Kemenade Thomas Wouters Ned Deily Steve Dower Å�ukasz Langa

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.