unicorn-engine/unicorn

Unicorn adds modern reactive component functionality to your Django templates. Prior to 0.67.0, 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. This vulnerability is fixed in 0.67.0.

Unicorn Engine v1.0.3 was discovered to contain a use-after-free vulnerability via the hook function.

Unicorn Engine v2.0.0-rc7 and below was discovered to contain a memory leak via the function uc_close at /my/unicorn/uc.c.

Unicorn Engine v2.0.0-rc7 and below was discovered to contain a NULL pointer dereference via qemu_ram_free.

Unicorn Engine v2.0.0-rc7 contains memory leaks caused by an incomplete unicorn engine initialization.

An issue was discovered in split_region in uc.c in Unicorn Engine before 2.0.0-rc5. It allows local attackers to escape the sandbox. An attacker must first obtain the ability to execute crafted code in the target sandbox in order to exploit this vulnerability. The specific flaw exists within the virtual memory manager. The issue results from the faulty comparison of GVA and GPA while calling uc_mem_map_ptr to free part of a claimed memory block. An attacker can leverage this vulnerability to escape the sandbox and execute arbitrary code on the host machine.

The Unicorn framework before 0.36.1 for Django allows XSS via a component. NOTE: this issue exists because of an incomplete fix for CVE-2021-42053.

The Unicorn framework through 0.35.3 for Django allows XSS via component.name.

Unicorn Engine 1.0.2 has an out-of-bounds write in tb_flush_armeb (called from cpu_arm_exec_armeb and tcg_cpu_exec_armeb).