شناسه CVE-2025-64459 :CVE
CWE-89 :CWE
yes :Advisory
منتشر شده: نوامبر 5, 2025
به روز شده: نوامبر 5, 2025
امتیاز: 9.1
نوع حمله: SQL Injection

اثر گذاری: Information Disclosure
حوزه: برنامه نویسی
برند: djangoproject
محصول: Django
وضعیتPublished :CVE
Yes :POC
وضعیت آسیب پذیری: patch شده

چکیده

آسیب‌پذیری بحرانی SQL Injection در فریم‌ورک Django از طریق پارامتر _connector در کلاس Q و متدهای QuerySet.filter()، exclude() و get() با استفاده از dictionary unpacking (kwargs) شناسایی شده است. مهاجم بدون احراز هویت می‌تواند از راه دور کوئری‌های SQL دلخواه اجرا کند و منجر به دور زدن احراز هویت، افشای اطلاعات حساس، تغییر یا حذف داده‌ها شود.

توضیحات

آسیب‌پذیری CVE-2025-64459 ناشی از خنثی‌سازی نادرست المنت‌های ویژه در دستورات SQL مطابق با CWE-89 است. این ضعف در نحوه‌ی مدیریت پارامتر داخلی _connector در کلاس Q و منطق تولید شرط‌های WHERE در فریم‌ورک Django رخ می‌دهد.

کلاس Q در Django برای ساخت شرط‌های منطقی پیچیده در بخش WHERE کوئری‌های پایگاه داده استفاده می‌شود و امکان ترکیب شرط‌ها با رابط‌های منطقی مانند AND و OR را فراهم می‌کند. به‌صورت پیش‌فرض، مقدار پارامتر _connector برابر با AND است، اما این مقدار می‌تواند به‌صورت صریح به OR یا XOR نیز تغییر داده شود تا نحوه‌ی اتصال شرط‌ها مشخص گردد.

این ضعف امنیتی زمانی ایجاد می‌شود که توسعه‌دهندگان برای ساخت فیلترهای کوئری، از بازگشایی دیکشنری (dictionary unpacking یا kwargs) و ورودی‌های کنترل‌شده توسط کاربر، مانند request.GET یا request.POST، به‌طور مستقیم در متدهایQuerySet.filter()، QuerySet.exclude()،QuerySet.get()یا سازنده‌ی کلاس Q استفاده می‌کنند؛ الگویی که در پیاده‌سازی APIهای جستجو بسیار رایج است.

در این شرایط، اگر مهاجم پارامتر _connector را به‌عنوان یک کلید در دیکشنری ورودی ارسال کند، مقدار آن مستقیماً به‌عنوان رابط‌های منطقی اتصال شرط‌ها در ساختار منطقی شرط WHERE استفاده می‌شود. این مقدار بدون انجام اعتبارسنجی کافی، در فرآیند تولید رشته‌ی نهایی SQL به کار گرفته می‌شود و به مهاجم اجازه می‌دهد بخش های مخرب SQL را تزریق کند. برای مثال، ارسال درخواستی مانند http://example.com/search?username=guest&_connector=) OR 1=1 OR (&is_active=False، باعث تولید شرطی از نوع SQL می‌شود که به دلیل وجود عبارت OR 1=1 همواره برقرار است و در نتیجه تمامی رکوردهای پایگاه داده بازگردانده می‌شوند. این وضعیت می‌تواند منجر به دور زدن احراز هویت (Authentication Bypass)، افشای اطلاعات حساس و حتی تغییر یا حذف داده‌ها شود. این آسیب‌پذیری به‌راحتی قابل خودکارسازی است و مهاجم می‌تواند تنها با ارسال پارامتر _connector همراه با الگوهای متداول تزریق SQL، حمله را از راه دور و بدون نیاز به احراز هویت اجرا کند. همچنین، کد اثبات مفهومی (PoC) به‌صورت عمومی در GitHub منتشر شده است که شامل محیط Docker، اسکریپت حمله و نمایش عملی دور زدن احراز هویت و افشای اطلاعات کاربران (از جمله حساب‌های مدیریتی) می‌باشد. انتشار عمومی این PoC، احتمال بهره‌برداری فعال و گسترده از این ضعف را به‌طور قابل توجهی افزایش داده است.

Django این آسیب‌پذیری را به‌طور کامل پچ کرده است. در نسخه‌های پچ‌شده، مقدار پارامتر _connector به‌صورت سخت‌گیرانه اعتبارسنجی می‌شود و تنها مقادیر مجاز AND، OR یا XOR پذیرفته می‌شوند. این اقدام از تزریق مقادیر دلخواه به منطق تولید SQL جلوگیری کرده و آسیب‌پذیری را به‌طور کامل برطرف می‌کند.

CVSS

Score	Severity	Version	Vector String
9.1	CRITICAL	3.1	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

لیست محصولات آسیب پذیر

Versions

Product

affected from 5.2 before 5.2.8

affected from 5.1 before 5.1.14

affected from 4.2 before 4.2.26

Django

لیست محصولات بروز شده

Versions

Product

unaffected at 5.2.8

unaffected at 5.1.14

unaffected at 4.2.26

Django

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که Django را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

Approx. Usage in .ir Domain via Google (Total Pages)	Search Query (Dork)	Product
173,000	site:.ir “Django”	Django

نتیجه گیری

این آسیب‌پذیری با شدت بحرانی امکان اجرای SQL Injection را از راه دور و بدون نیاز به احراز هویت فراهم می‌کند. در صورت بهره‌برداری موفق، مهاجم می‌تواند منجر به افشای اطلاعات حساس، تغییر یا حذف داده‌ها و دور زدن مکانیزم‌های احراز هویت شود. با توجه به انتشار عمومی PoC و ارائه پچ امنیتی رسمی، اجرای فوری اقدامات زیر برای جلوگیری از سوءاستفاده ضروری است:

به‌روزرسانی فوری: تمامی پروژه‌های مبتنی بر Django باید در اسرع وقت به نسخه‌های 2.8، 5.1.14 یا 4.2.26 به‌روزرسانی شوند. این اقدام مؤثرترین و قطعی‌ترین راهکار برای رفع آسیب‌پذیری است و باید در اولویت قرار گیرد. سایر اقدامات نقش مکمل را دارند و می‌توانند به کاهش ریسک این آسیب پذیری و مقابله با حملات مشابه کمک کنند.
بررسی و اصلاح کد: تمامی بخش‌های کد که از الگوهای Q(**kwargs)، filter(**kwargs)، exclude(**kwargs) و get(**kwargs) استفاده می‌کنند باید شناسایی و اصلاح شوند. هرگز ورودی کاربر را مستقیماً به‌صورت Dictionary Unpacking به این متدها ارسال نکنید. به‌جای آن، تنها فیلدهای مجاز را به‌صورت لیست سفید (Whitelist) تعریف کنید. برای مثال:

clean_filters = {k: v for k, v in request.GET.items() if k in allowed_filters}

# Now safe to unpack

User.objects.filter(**clean_filters)

همچنین می توان از کلاس Q به‌صورت صریح، کنترل‌شده و بدون اتکا به ورودی خام کاربر استفاده کرد.

استفاده از ORM به شیوه امن: از متدهای filter با پارامترهای ثابت یا شرطی که به‌صورت دستی و ایمن ساخته شده‌اند استفاده کنید و از بازگشایی دیکشنری از منابع غیرقابل اعتماد مانند GET و POST به‌طور کامل اجتناب نمایید.
مانیتورینگ و تشخیص: لاگ‌های پایگاه داده و کوئری‌های غیرعادی یا کُند را به‌صورت مستمر نظارت کنید. همچنین استفاده از فایروال اپلیکیشن وب (WAF) مانند ModSecurity یا Cloudflare WAF با قوانین مخصوص تزریق SQL توصیه می‌شود.
محدودسازی دسترسی شبکه: دسترسی به اپلیکیشن Django را با فایروال، شبکه‌های خصوصی مجازی (VPN) یا شبکه‌های خصوصی ابری (VPC) محدود کنید تا سطح حمله کاهش یابد.
تست نفوذ و ممیزی امنیتی: پس از اعمال به‌روزرسانی‌ها، تست نفوذ روی تمامی اندپوینت‌های مرتبط با جستجو و فیلتر انجام دهید تا اطمینان حاصل شود هیچ الگوی کدنویسی آسیب‌پذیری در سیستم باقی نمانده است.

اجرای سریع به‌روزرسانی‌ها و اصلاح الگوهای کدنویسی آسیب‌پذیر، ریسک بهره‌برداری از این آسیب‌پذیری بحرانی را به‌طور قابل توجهی کاهش داده و امنیت برنامه‌های مبتنی بر Django را در برابر حملات تزریق SQL تضمین می‌کند.

امکان استفاده در تاکتیک های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)
مهاجم با ارسال درخواست HTTP ساده به APIهای جستجو یا فیلترهای عمومی Django که از ورودی‌های کاربر در QuerySet یا Q objects استفاده می‌کنند، بدون نیاز به احراز هویت وارد سیستم می‌شود و شرط‌های WHERE را دستکاری می‌نماید. شرط کلیدی در اینجا وجود الگوی توسعه‌ای ناامن است که دیکشنری ورودی کاربر را مستقیماً unpack کرده و پارامتر _connector را بدون اعتبارسنجی بپذیرد، تا مهاجم بتواند منطق SQL را تغییر دهد و دسترسی اولیه را برقرار سازد.

Execution (TA0002)
در این فاز، مهاجم با تزریق مقدار مخرب در پارامتر _connector از طریق request.GET یا POST، کوئری SQL دلخواه را در backend اجرا می‌کند که منجر به پردازش شرط‌های دستکاری‌شده توسط ORM Django می‌گردد. لازمه موفقیت، عدم اعمال محدودیت روی مقادیر connector در سمت سرور است، به طوری که عبارات تزریقی مانند الگوهای منطقی نادرست مستقیماً به رشته SQL تبدیل شده و بدون پاکسازی اجرا گردند.

Credential Access (TA0006)
پس از اجرای کوئری مخرب، مهاجم اطلاعات احراز هویت کاربران از جمله هش رمزهای عبور، توکن‌های جلسه و جزئیات حساب‌های مدیریتی را استخراج می‌کند، زیرا شرط‌های دور زده‌شده تمام رکوردها را افشا می‌نماید. این گام وابسته به ساختار پایگاه داده است که فیلدهای حساس را در جداول کاربران ذخیره کرده و API هدف بدون pagination یا محدودیت خروجی عمل کند.

Discovery (TA0007)
مهاجم با تحلیل نتایج کوئری‌های موفق، ساختار پایگاه داده، جداول موجود، ستون‌ها و روابط بین داده‌ها را کشف می‌کند تا نقاط ضعف بعدی را شناسایی نماید. شرط لازم، قابلیت اجرای کوئری‌های متوالی بدون rate limiting یا logging مشکوک است، که اجازه می‌دهد مهاجم به تدریج schema کامل را نقشه‌برداری کرده و سرویس‌های وابسته را بیابد.

Collection (TA0009)
داده‌های حساس استخراج‌شده از پایگاه داده به صورت batch جمع‌آوری و به سرور مهاجم منتقل می‌شوند، اغلب از طریق خروجی JSON API یا دانلود مستقیم رکوردها. موفقیت این مرحله به پایداری اتصال وب و عدم وجود مکانیزم‌های دفاعی مانند WAF که الگوهای SQLi را مسدود کنند، بستگی دارد تا حجم بالایی از اطلاعات بدون اختلال گردآوری گردد.

Impact (TA0040)
بهره‌برداری از این آسیب‌پذیری محرمانگی کامل داده‌های کاربران را نابود کرده و امکان دور زدن احراز هویت، سرقت اطلاعات حساس، تغییر یا حذف رکوردهای پایگاه داده را فراهم می‌آورد؛ در نهایت سایت به ابزاری برای حملات گسترده تبدیل شده و مالک با ریسک افشای عمومی داده‌ها، نقض قوانین حریم خصوصی و از دست دادن اعتماد کاربران روبرو می‌گردد، مگر آنکه پچ Django فوراً اعمال شود.

منابع

گزارش اثبات آسیب‌پذیری CVE-2025-64459

اطلاعات آسیب‌پذیری

عنوان: امکان تزریق SQL در QuerySet و اشیای Q فریم‌ورک Django
شناسه:CVE-2025-64459
وضعیت مشاوره : Advisory / Patch Available

نمره CVSS تقریبی : CVSS v3.1: 9.1 (Critical)

محصول / نسخه‌های آسیب‌پذیر : Django Web Framework

در نسخه‌های زیر (پیش از اعمال وصله امنیتی):
◦ Django 5.1 قبل از 1.14
◦ Django 5.2 قبل از 2.8
◦ Django 4.2 قبل از 2.26
◦ نسخه‌های قدیمی‌تر (مانند 0.x، 4.1.x، 3.2.x) نیز ممکن است تحت تأثیر باشند
محیط‌های درگیر
◦ برنامه‌های تحت وب توسعه‌یافته با فریم‌ورک Django .
◦ رابط‌های برنامه‌نویسی (API) و سرویس‌هایی که از مکانیزم‌های فیلترگذاری پویا و جستجوی پیشرفته استفاده می‌کنند.
◦ سامانه‌هایی که داده‌های دریافتی از کاربر را به‌صورت مستقیم یا غیرمستقیم در لایه ORM به کار می‌گیرند.
◦ محیط‌های عملیاتی مختلف شامل محیط بهره‌برداری نهایی (Production)، محیط‌های آزمون و آماده‌سازی (Staging/Test) و معماری‌های مبتنی برمیکروسرویس (Microservice)

کامپوننت‌های آسیب‌پذیر:

Django ORM
متدهای filter()، QuerySet.exclude()، QuerySet.get()
کلاس Q برای ساخت شرط‌های منطقی
منطق تولید شرط WHERE در کوئری‌های SQL

ریشه مشکل (Root Cause Analysis)

ریشه اصلی این آسیب‌پذیری به یک نقص منطقی و اعتبارسنجی ورودی (Logic & Validation Flaw) در طراحی و پیاده‌سازی ORM فریم‌ورک Django بازمی‌گردد. پارامتر داخلی _connector که وظیفه تعیین نحوه اتصال شرط‌ها (AND / OR / XOR) را دارد، در شرایط خاصی بدون اعتبارسنجی کافی از طریق dictionary unpacking (**kwargs) مقداردهی می‌شود. در نتیجه، داده‌ای که می‌بایست صرفاً یک کنترل داخلی باشد، به سطح ورودی قابل‌کنترل توسط کاربر ارتقا یافته و مستقیماً در فرآیند تولید رشته نهایی SQL استفاده می‌شود. این طراحی، مرز ایمن بین ورودی کاربر و منطق تولید کوئری را نقض می‌کند.

بخش آسیب‌پذیر

رفتار نا امن سیستم:

پذیرش و استفاده از مقدار پارامتر داخلی _connector از ورودی‌های کاربر در فرآیند تولید کوئری SQL بدون اعتبارسنجی کافی.

نحوه سوءاستفاده مهاجم:

مهاجم بدون نیاز به انجام فرآیند احراز هویت، اقدامات زیر را انجام می‌دهد:

ارسال یک درخواست HTTP حاوی پارامتر مخرب _connector .
دستکاری منطق اتصال شروط WHERE در کوئری .
ایجاد کوئری SQL دلخواه یا استفاده از شرطی که همواره صحیح است (مانند OR 1=1) .
دسترسی غیرمجاز به اطلاعات و داده‌ها.

نقش این آسیب‌پذیری در زنجیره حمله

این آسیب‌پذیری می‌تواند به‌عنوان نقطه ورود (Initial Access) عمل کرده و زمینه‌ساز افشای داده، دور زدن احراز هویت و حملات ثانویه شود.

پیش‌نیازهای بهره‌برداری (Prerequisites)

استفاده از الگوهای توسعه ناایمن که در آن‌ها پارامترها به‌صورت پویا و از طریق سازوکار **kwargs به لایه ORM منتقل می‌شوند.
به‌کارگیری داده‌های ورودی کاربر، به‌صورت مستقیم یا غیرمستقیم، در فرآیند ساخت کوئری‌های ORM بدون اعمال محدودیت‌های کنترلی کافی.
عدم پیاده‌سازی مکانیزم‌های اعتبارسنجی سخت‌گیرانه یا فهرست مجاز (Allow-list) برای پارامترهای داخلی و کنترلی ORM.
در دسترس بودن نقاط انتهایی (Endpoints) آسیب‌پذیر از طریق رابط‌های وب یا API و امکان ارسال درخواست از سوی مهاجم.

رفتار مورد انتظار در حالت امن (Expected Secure Behavior)

در طراحی امن انتظار می‌رود:

پارامترهای داخلی ORM هرگز از ورودی کاربر مقداردهی نشوند.
مقادیر _connector صرفاً به AND، OR یا XOR محدود شوند.
ORM در مواجهه با مقادیر غیرمجاز، خطا داده و Fail-Closed عمل کند.
مرز روشنی بین داده کاربر و منطق تولید SQL حفظ شود.

راهکارها و کاهش ریسک (Mitigation / Patch Guidance)

اقدامات فوری برای کاهش ریسک

به‌روزرسانی فوری فریم‌ورک Django به نسخه‌های اصلاح‌شده و امن (1.14، 5.2.8 و 4.2.26) به‌منظور حذف کامل بردار حمله شناخته‌شده.
شناسایی و پایش کلیه نقاط انتهایی (Endpoints) که در آن‌ها از فیلترگذاری پویا یا دریافت پارامترهای کنترلی از ورودی کاربر استفاده می‌شود.
اعمال محدودیت موقت یا مسدودسازی کامل پارامتر داخلی _connector در ورودی‌های دریافتی تا زمان اعمال اصلاحات کد.

اقدامات کوتاه‌مدت / میان‌مدت برای کاهش ریسک

حذف یا بازطراحی الگوهای ناایمن مبتنی بر dictionary unpacking که داده‌های کاربر را مستقیماً به لایه ORM منتقل می‌کنند.
پیاده‌سازی مکانیزم‌های اعتبارسنجی سخت‌گیرانه مبتنی بر فهرست مجاز (Allow-list) برای تمامی پارامترهای ورودی، به‌ویژه پارامترهای کنترلی.
فعال‌سازی و تقویت لاگ‌برداری تفصیلی از خطاها و رفتارهای غیرعادی در سطح پایگاه‌داده و ORM به‌منظور تسهیل شناسایی سوءاستفاده احتمالی.

اقدامات بلندمدت برای کاهش ریسک

بازبینی و بهبود معماری امنیتی سرویس‌ها و APIها با تمرکز بر جداسازی منطق کنترلی از ورودی‌های کاربر.
افزایش سطح آگاهی تیم‌های توسعه از طریق آموزش هدفمند در زمینه سوءاستفاده‌های رایج از ORM و پیامدهای امنیتی آن.
استفاده مستمر از ابزارهای تحلیل کد (SAST) و بازبینی امنیتی چرخه توسعه نرم‌افزار به‌منظور شناسایی و حذف الگوهای پرخطر پیش از استقرار.

تشخیص و مانیتورینگ (Detection & Monitoring)

نشانه‌های تلاش برای سوءاستفاده

نشانه‌های زیر می‌توانند بیانگر تلاش برای بهره‌برداری از آسیب‌پذیری موردنظر باشند و لازم است به‌صورت مستمر پایش شوند:

افزایش غیرعادی حجم داده‌های بازگشتی در پاسخ‌های API یا درخواست‌های وب، به‌ویژه در Endpointهایی که انتظار می‌رود تنها تعداد محدودی رکورد را بازگردانند.
ثبت خطاها یا هشدارهای غیرمعمول مرتبط با اجرای کوئری‌های SQL یا ORM در لاگ‌های Django یا پایگاه‌داده، به‌خصوص خطاهایی که به ساختار شرط‌های WHERE یا ترکیب منطقی آن‌ها اشاره دارند.
مشاهده پارامترهای غیرمنتظره، ناشناخته یا کنترلی در درخواست‌های HTTP (مانند پارامتر _connector) یا مقادیری که با الگوی معمول درخواست‌های برنامه هم‌خوانی ندارند.

منابع پیشنهادی برای مانیتورینگ و پایش

به‌منظور تشخیص به‌موقع و مؤثر تلاش‌های سوءاستفاده، پایش منابع زیر توصیه می‌شود:

لاگ‌های سطح برنامه Django شامل لاگ‌های خطا، هشدار و دیباگ مرتبط با ORM و پردازش درخواست‌ها.
لاگ‌های پایگاه‌داده با تمرکز بر کوئری‌های غیرمعمول، خطاهای تکرارشونده یا کوئری‌هایی با ساختار منطقی غیرمنتظره.
راهکارهای WAF یا API Gateway مجهز به قوانین تشخیص SQL Injection و قابلیت شناسایی پارامترهای مشکوک در درخواست‌ها.
پایش رفتاری APIها از طریق مقایسه الگوی ترافیک جاری با رفتار عادی (Baseline)، به‌ویژه از نظر نوع پارامترها، حجم پاسخ‌ها و نرخ درخواست‌ها.

واکنش به حادثه (Incident Response)

اقدامات اضطراری که در صورت مشاهده نشانه‌های نفوذ باید اتخاذ شود:

ایزوله‌کردن سرویس آسیب‌پذیر یا در معرض حمله.
تحلیل و بررسی لاگ‌های برنامه وب و پایگاه‌داده.
ارزیابی میزان دسترسی یا افشای اطلاعات.
اعمال وصله‌های امنیتی و اصلاح کدهای آسیب‌پذیر.
اطلاع‌رسانی مناسب و مستندسازی کامل حادثه.

جریان حمله (Attack Flow)

در شکل ۱ جریان کلی بهره‌برداری از این آسیب‌پذیری نشان داده شده است. در این سناریو، مهاجم با ارسال درخواست HTTP شامل پارامتر _connector دستکاری‌شده، منطق ترکیب شرط‌های WHERE را تغییر داده و ORM Django را وادار به تولید کوئری SQL ناامن می‌کند. این کوئری می‌تواند تمامی رکوردها را بازگرداند یا منجر به افشای داده‌های حساس شود. فرآیند حمله بدون نیاز به احراز هویت و به‌صورت تکرارشونده قابل انجام است.

شکل 1: نمودار جریان حمله

اثبات مفهوم (PoC) — کاملاً غیرمخرب

آزمایشگاه تخصصی Vulnerbyte این آسیب‌پذیری را در محیط ایزوله بررسی کرده است. اثبات مفهوم این آسیب‌پذیری شامل موارد زیر است:

صرفاً توصیفی و آموزشی است.
شامل کد Exploitواقعی نمی‌باشد.
نشان می‌دهد که چگونه مقداردهی کنترل‌نشده _connectorمی‌تواند منجر به SQL Injectionشود.

تصویر ارائه‌شد در شکل ۲ نشان‌دهنده اثبات مفهوم (PoC) و اجرای موفقیت‌آمیز این آسیب‌پذیری در آزمایشگاه Vulnerbyte می باشد.

شکل 2: اثبات اجرای آسیب پذیری

رفع مسئولیت

این گزارش صرفاً با هدف آموزش، تحلیل فنی و ارتقای امنیت سازمانی تهیه شده است. هرگونه استفاده مخرب یا خارج از چارچوب‌های قانونی از محتوای آن ممنوع است.

منابع (References)

Django Web Framework

CVE-2025-64459 – SQL Injection via Crafted Dictionary Expansion in ORM Query Construction

Affects

Django
Supported versions:
- 5.1 prior to 5.1.14
- 5.2 prior to 5.2.8
- 4.2 prior to 4.2.26
Earlier, unsupported Django series were not evaluated and may also be affected, including:
- 5.0.x
- 4.1.x
- 3.2.x

Description

CVE-2025-64459 is a SQL injection vulnerability in the Django Object-Relational Mapper (ORM).

Under specific conditions, the ORM methods:

QuerySet.filter()
QuerySet.exclude()
QuerySet.get()
the Q() query construction class

can be abused when a suitably crafted dictionary is passed as the _connector argument using dictionary expansion (**kwargs).

Due to insufficient validation of this internal parameter, attacker-controlled input can influence how query conditions are combined, potentially leading to unsafe SQL query construction. This may allow SQL injection if untrusted input is passed directly or indirectly into these ORM APIs.

The vulnerability breaks Django’s usual ORM guarantees that protect developers from SQL injection when using high-level query interfaces.

Attack Vector

Primary Attack Vector:
Application-level / Remote (via web requests or internal API misuse)

Attack Scenario:

An application accepts user-controlled input (directly or indirectly).
The input is incorporated into a Python dictionary.
The dictionary is expanded (**dict) into Django ORM calls such as filter(), exclude(), get(), or Q(), specifically influencing the _connector argument.
Django does not sufficiently validate this parameter.
The resulting SQL query may be constructed in an unsafe manner, enabling SQL injection.

Key Characteristics:

Exploitation depends on application logic rather than default Django usage.
The vulnerability does not require raw SQL queries.
The ORM abstraction layer is bypassed due to improper internal parameter handling.
Authentication requirements depend on where the vulnerable code path is exposed.

Conditions Increasing Risk:

Dynamic query construction using dictionaries.
Passing user-supplied data into ORM keyword arguments without strict validation.
Large or complex applications with reusable query helper functions.

Observed Exploitation & Threat Activity

No widespread in-the-wild exploitation has been publicly reported at the time of disclosure.
The issue was responsibly disclosed to Django by cyberstan, and promptly patched.
Due to Django’s widespread adoption, the vulnerability is considered high-risk if misused, particularly in custom query construction patterns.

Severity & Metrics

CVSS v3.1: Moderate to High (typically 6.5 – 8.0, depending on exposure)
Attack Vector: Application / Network
Privileges Required: Context-dependent
User Interaction: None
Impact:
- Confidentiality: High
- Integrity: High
- Availability: Low

Relevant CWE:

CWE-89 – SQL Injection
CWE-20 – Improper Input Validation

Patch & Vendor Status

Django has released fixes in the following versions:
- 5.1.14
- 5.2.8
- 4.2.26

The patch introduces stricter validation and handling of internal ORM parameters to prevent misuse during dictionary expansion.

Users are strongly advised to upgrade immediately.

Mitigation & Remediation

Immediate Actions

Upgrade Django to a patched version:
- 5.1.14, 5.2.8, or 4.2.26 (depending on your branch).
Review codebases for dynamic ORM query construction using dictionaries.
Ensure untrusted input is never passed into ORM internals.

Temporary Compensating Controls

Avoid dictionary expansion (**kwargs) with untrusted or semi-trusted data in ORM calls.
Enforce strict input validation and allow-listing.
Add application-level logging for unexpected query patterns.

These mitigations reduce risk but do not replace patching.

Detection & Hunting

Indicators of Potential Abuse:

Unexpected SQL behavior from ORM-generated queries.
Database errors related to malformed query logic.
Suspicious query conditions appearing in database logs.

Recommended Monitoring:

Enable database query logging in staging or forensic contexts.
Monitor application logs for dynamically generated ORM queries.
Use static analysis tools to flag unsafe dictionary expansion patterns.

Post-Incident Response

If SQL injection is suspected:

Isolate affected application components.
Review database logs for unauthorized queries.
Rotate database credentials if exposure is possible.
Apply patched Django versions.
Conduct a code audit focusing on ORM usage patterns.

Summary Table

Category	Details
Vulnerability	SQL injection
Component	Django ORM (`QuerySet`, `Q`)
Attack Vector	Crafted dictionary expansion
Impact	Unauthorized database access
Affected Versions	Django 4.2 / 5.1 / 5.2 (pre-patch)
Fixed Versions	4.2.26, 5.1.14, 5.2.8
Severity	Moderate to High

References

Django Security Advisory – CVE-2025-64459
NVD – CVE-2025-64459
CWE-89: SQL Injection

CVE-2025-64459

Potential SQL injection via _connector keyword argument in QuerySet and Q objects