Attacker Impact
CVE-2011-0696 affects Django 1.1.x before 1.1.4 and 1.2.x before 1.2.5 [S1, S2]. When an affected Django runtime serves authenticated state-changing views, a remote attacker may be able to make a logged-in user's browser send forged AJAX-style requests that bypass the vulnerable CSRF handling [S2, S3]. The practical impact depends on the deployed Django version, session/auth model, CSRF middleware, templates, route behavior, and whether the repository dependency evidence actually reaches production.
Root Cause
Older Django CSRF protection trusted requests that appeared to be AJAX based on the X-Requested-With header [S3]. The Django security release explains that browser plugin and redirect behavior could let attackers make forged requests appear AJAX-originated, so Django changed to apply full CSRF validation to all requests and added support for the X-CSRFToken header [S3].
Concrete Fixes
- Upgrade Django to 1.1.4, 1.2.5, or preferably a current supported release [S2, S3].
- Regenerate lockfiles, rebuild the deployed virtualenv/container/image, and verify the runtime version that actually serves traffic.
- Keep
CsrfViewMiddlewareenabled, render CSRF tokens for state-changing forms, send the configured CSRF header for AJAX requests, and audit broadcsrf_exemptusage. - If Django comes from an OS package rather than PyPI, verify the host package includes a vendor backport for CVE-2011-0696.
Covered by FixVibe
FixVibe's GitHub repo scans flag Python dependency manifests and lockfiles that pin or allow Django versions in the CVE-2011-0696 affected ranges, so you can upgrade to a supported release.