CVE-2015-2317: Cross-Site Scripting (XSS) in Django

django Updated 02 Oct 2025

Summary

25/03/2015
Yes i
Moderate
6.1

CVE-2015-2317: The utils.http.is_safe_url function in Django before 1.4.20, 1.5.x, 1.6.x before 1.6.11, 1.7.x before 1.7.7, and 1.8.x before 1.8c1 does not properly validate URLs, which allows remote attackers to conduct cross-site scr... Affects django across 4 version ranges.

< 1.4.20 >= 1.5, < 1.6.11 >= 1.7, < 1.7.7 >= 1.8a0, < 1.8c1

Fixed in 4 releases; the minimum fixed version depends on the release line you run. How to fix ↓

Also tracked for

The same CVE-2015-2317 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.

Free scan

Check if this vulnerability affects your application

Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.

Check my app free

No signup required · Results in about 60 seconds

Sponsored Devnack Penetration testing for web, API and mobile Manual testing by engineers who build software, not an auditor's checklist. Trusted by teams at Swift and Google Talk to Devnack

Background

Django is a popular Python web framework that provides a set of tools and libraries for building web applications. It offers features such as URL routing, database abstraction, and template rendering. The vulnerability identified as CVE-2015-2317 affects versions of Django before 1.4.20, 1.5.x, 1.6.x before 1.6.11, 1.7.x before 1.7.7, and 1.8.x before 1.8c1. Django's 'utils.http.is_safe_url' function is responsible for validating URLs, but it fails to do so properly, allowing remote attackers to exploit a cross-site scripting (XSS) vulnerability by injecting control characters into a URL.

Vulnerability Detail

The vulnerability in Django's 'utils.http.is_safe_url' function enables attackers to perform cross-site scripting (XSS) attacks. By injecting control characters into a URL, an attacker can execute arbitrary JavaScript code in the context of a victim's browser. This can lead to various malicious activities, such as stealing sensitive information, modifying web page content, or performing actions on behalf of the victim. The vulnerability was first reported on March 25, 2015, and is assigned the CVE identifier CVE-2015-2317.

How To Fix

Latest published version: 6.1.2 as of 22 Oct 2026

pip install --upgrade "django==6.1.2"

Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.

If you can't move to the latest

The minimum fixed version depends on the release line you run.

  • < 1.4.20 1.4.20
    pip install --upgrade "django==1.4.20"
  • >= 1.5, < 1.6.11 1.6.11
    pip install --upgrade "django==1.6.11"
  • >= 1.7, < 1.7.7 1.7.7
    pip install --upgrade "django==1.7.7"
  • >= 1.8a0, < 1.8c1 1.8c1
    pip install --upgrade "django==1.8c1"

Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →

Workaround

If upgrading to a fixed version of Django is not immediately feasible, a temporary workaround can be implemented. Developers can manually validate URLs using a custom function that ensures the absence of control characters and performs proper URL encoding. Here is an example of a workaround function in Python:

import urllib.parse

def validate_url(url):
    encoded_url = urllib.parse.quote(url, safe=':/')
    if url != encoded_url:
        return False
    return True

This function encodes the URL and compares it with the original URL. If they differ, it indicates the presence of control characters and the URL is considered unsafe.

Conclusion

The cross-site scripting (XSS) vulnerability in Django's 'utils.http.is_safe_url' function can have serious security implications for web applications built using affected versions of Django. It is crucial to upgrade to the fixed versions or implement the provided workaround to mitigate the risk. For further assistance and support in vulnerability remediation, please contact DevNack.com.

See every vulnerability recorded for django →

Share this vulnerability

FAQ

The vulnerability allows remote attackers to execute arbitrary JavaScript code in the context of a victim's browser, potentially leading to various malicious activities such as data theft, content modification, or unauthorized actions.

Versions of Django before 1.4.20, 1.5.x, 1.6.x before 1.6.11, 1.7.x before 1.7.7, and 1.8.x before 1.8c1 are affected by this vulnerability.

Yes, the vulnerability has been fixed in Django versions 1.4.20, 1.6.11, 1.7.7, and 1.8c1. Users are advised to upgrade to these fixed versions to mitigate the risk.

Yes, a temporary workaround is to manually validate URLs using a custom function that ensures the absence of control characters and performs proper URL encoding. See the 'workaround' section for an example.

You can find more information about this vulnerability in the Django advisory database. Visit the following link: https://github.com/pypa/advisory-database/blob/main/vulns/django/PYSEC-2015-9.yaml

Related vulnerabilities

Recent vulnerabilities recorded for django.

How To Fix

Latest published version: 6.1.2 as of 22 Oct 2026

pip install --upgrade "django==6.1.2"

Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.

If you can't move to the latest

The minimum fixed version depends on the release line you run.

  • < 1.4.20 1.4.20
    pip install --upgrade "django==1.4.20"
  • >= 1.5, < 1.6.11 1.6.11
    pip install --upgrade "django==1.6.11"
  • >= 1.7, < 1.7.7 1.7.7
    pip install --upgrade "django==1.7.7"
  • >= 1.8a0, < 1.8c1 1.8c1
    pip install --upgrade "django==1.8c1"

Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →

Subscribe to Vulert on Telegram
Daily digest of new CVEs, critical and high severity, affected packages and fixes — plus a weekly roundup.
Join the channel →
Help improve this record
Report an issue or send feedback