Authenticated code injection enables remote command execution in Horilla HR

Horilla is an HR and CRM software. Prior to 2.0.0, HorillaListView.export_data in horilla_views/generic/cbv/views.py accepts an authenticated user's columns POST parameter, takes field_tuple[1], interpolates it into dynamic_fn_str as Python source, and passes the generated function definition to exec(). A crafted string that remains valid under ast.literal_eval can inject Python syntax into a default argument evaluated during function definition, allowing arbitrary operating-system commands to execute with the application process privileges, including root privileges in the shipped Docker image. This issue is fixed in version 2.0.0.

• The CNA/vendor advisory identifies Horilla HR versions <= 1.6.1 as affected.
• The advisory identifies version 2.0.0 as patched.
• The normalized record marks all versions < 2.0.0 as affected.
• These boundaries are not fully consistent. The status of versions after 1.6.1 but before 2.0.0 is therefore unresolved by the available evidence and should not be treated as safe without additional confirmation.

HorillaListView.export_data processes an authenticated user's columns POST parameter in the list-view export feature. The value is parsed with ast.literal_eval, after which a field from field_tuple is interpolated directly into the Python source string dynamic_fn_str. The generated function definition is passed to exec(), so attacker-controlled input can alter the syntax of the function rather than merely supply a column name. An injected expression in a function default argument is evaluated when the function is defined, allowing operating-system commands to run with the application process privileges. The confirmed precondition is an authenticated Horilla account; the advisory states that a normal user without staff or superuser privileges is sufficient. The evidence does not establish implementation details for every replacement branch beyond the statement that the fix stops building dehydrate methods from user-supplied column names.

The flaw is reachable over the network through the list-view export handler.

• The attacker needs an authenticated Horilla account, but the advisory states that a low-privileged normal user is sufficient.
• No additional user interaction is required, and the supplied assessment describes exploitation as low complexity.
• The vendor advisory is public and includes a technical reproduction, but the supplied record does not confirm exploitation in the wild or a separately tracked public exploit.
• No confirmed campaign, victim, indicator of compromise, or ransomware association is provided.

Successful exploitation permits operating-system command execution in the Horilla process environment with the privileges of the application process. In the shipped Docker image, the advisory describes those privileges as root, so the impact inside the container may include full access to resources available to that container. Organisational consequences can include loss of confidentiality for HR and CRM data, unauthorized changes to application configuration or records, and service availability disruption. Impact against the host or other systems depends on deployment configuration and is not confirmed by the evidence. Authentication is required, so the flaw does not provide anonymous direct access.

An authenticated Horilla user can turn the list-view export feature into command execution in the application's server environment. This could allow access to HR and CRM data available to the application process, modification of application state, or service disruption.

When the shipped Docker image is used, the advisory states that the container process runs as root by default, increasing the potential impact within the container. Impact beyond the container depends on deployment settings, mounted volumes, secrets, and container permissions, and is not established by the supplied evidence. The existence of the vulnerability alone does not establish that data was exposed or that a compromise occurred.

1. Upgrade Horilla HR to version 2.0.0, which the CNA/vendor advisory identifies as patched.
2. After upgrading, verify that the deployed code no longer builds dehydrate methods from user-supplied column names and no longer passes code generated from those values to exec().
3. If an upgrade cannot be completed immediately, treat deployments in unresolved version ranges as at risk and use access restrictions around the application and export functionality as a temporary compensating measure. The supplied evidence does not document another vendor-approved workaround.
4. Do not infer that versions after 1.6.1 and before 2.0.0 are safe merely because the advisory confirms that 2.0.0 is patched. Confirm the status of those branches separately.

1. Inventory Horilla HR deployments and identify the running version, including source-based installations and Docker containers.
2. Review horilla_views/generic/cbv/views.py, especially HorillaListView.export_data, to determine whether columns is still used to generate Python code and pass it to exec().
3. Review application logs for list-view export requests from low-privileged accounts, anomalous columns values, and export activity inconsistent with normal user behavior.
4. As a precautionary monitoring measure, correlate export events with the application process creating child processes or executing operating-system commands. This is not a confirmed IOC.
5. The supplied evidence does not provide a specific log event or IOC that can prove the system is safe when no suspicious activity is observed.