CVE-2026-41513: Horilla HR Software CSRF Vulnerability

CVE-2026-41513 Overview

CVE-2026-41513 is an open redirect vulnerability [CWE-601] in Horilla, an open-source HR and CRM application. Version 1.5.0 contains notification endpoints that trust an unvalidated next parameter and redirect authenticated users to arbitrary external URLs. Attackers can craft links that originate from the trusted Horilla domain but terminate at attacker-controlled destinations. This enables phishing campaigns, credential harvesting, and social-engineering attacks that abuse the application's reputation. The flaw resides in the notifications view logic where the redirect target is not constrained to the application's own host.

Critical Impact

Authenticated users clicking trusted Horilla notification links can be silently redirected to attacker-controlled domains, enabling phishing and credential theft.

Affected Products

• Horilla HR and CRM software, version 1.5.0
• The notifications module (notifications/views.py)
• Deployments exposing notification redirect endpoints to authenticated users

Discovery Timeline

• 2026-05-12 - CVE-2026-41513 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-41513

Vulnerability Analysis

The vulnerability resides in Horilla's notification endpoints, which accept a next query parameter to determine where the user is sent after interacting with a notification. The application passes this parameter directly to a redirect response without validating that the target URL belongs to the same origin. Because the originating link is hosted on the legitimate Horilla instance, browser and email security indicators show the request as trusted. The classification corresponds to [CWE-601] Open Redirect, mapped to network-based exploitation requiring user interaction.

Root Cause

The notifications view consumes the next parameter from the HTTP request and issues an HTTP redirect without applying an allowlist or same-origin check. Django provides helpers such as url_has_allowed_host_and_scheme for exactly this purpose, but the affected code path omitted that validation. As a result, any value supplied in next — including absolute URLs pointing to external hosts — is honored.

Attack Vector

An attacker constructs a notification link of the form https://<horilla-host>/notifications/<endpoint>?next=https://attacker.example/login. The attacker delivers the link through email, chat, or any channel where Horilla URLs are expected. The victim, already authenticated to Horilla, clicks the link and is redirected to the attacker's site. The attacker page typically mimics the Horilla login screen to harvest credentials or distribute malware.

# Patch: notifications/views.py
# Source: https://github.com/horilla/horilla-hr/commit/734f0c7ed4ac96fe8615d1b592180ea8a46eb8b6
# -*- coding: utf-8 -*-
-""" Django Notifications example views """
+"""Django Notifications example views"""
from distutils.version import (  # pylint: disable=no-name-in-module,import-error
    StrictVersion,
)

The upstream commit adds host and scheme validation around the next redirect target so that only same-origin URLs are honored. Review the full diff in the GitHub commit.

Detection Methods for CVE-2026-41513

Indicators of Compromise

• Web server access logs containing requests to notification endpoints with a next parameter pointing to external hosts (any value not matching the deployment's own FQDN).
• HTTP 302 responses from Horilla notification routes with Location headers referencing third-party domains.
• Inbound emails or chat messages containing Horilla URLs with suspiciously long or encoded next query strings.

Detection Strategies

• Parse Horilla and reverse-proxy logs for requests matching /notifications/*?*next=http* where the host in next differs from the Horilla deployment host.
• Alert on outbound user redirects from Horilla to newly registered or low-reputation domains using URL reputation feeds.
• Hunt for clusters of authenticated users following the same external redirect target within a short time window.

Monitoring Recommendations

• Forward Horilla application and proxy logs to a centralized analytics platform and create a detection rule on the next parameter pattern described above.
• Monitor for credential reuse anomalies — Horilla session cookies followed shortly by failed logins from unfamiliar IP addresses.
• Track user-reported phishing emails referencing Horilla URLs and correlate against server-side redirect logs.

How to Mitigate CVE-2026-41513

Immediate Actions Required

• Upgrade Horilla beyond version 1.5.0 to a release that includes commit 734f0c7ed4ac96fe8615d1b592180ea8a46eb8b6 from the notifications module.
• Restrict access to the Horilla instance to authenticated users behind SSO or VPN where feasible to reduce phishing exposure.
• Educate HR users that legitimate Horilla notifications should never redirect them off the corporate domain.

Patch Information

The upstream fix is provided in the GitHub commit 734f0c7, referenced by GHSA-vqg4-fc32-cwvw. The patch validates the next parameter against the application's allowed hosts and scheme before issuing a redirect. Operators running Horilla 1.5.0 should apply the patched version or backport the commit if remaining on the affected branch.

Workarounds

• Deploy a reverse-proxy rule (for example in NGINX or a WAF) that drops or rewrites requests to /notifications/* when the next parameter contains an absolute URL pointing outside the deployment host.
• Use Django middleware to sanitize the next parameter with django.utils.http.url_has_allowed_host_and_scheme against request.get_host() and reject non-matching values.
• Set a strict Content-Security-Policy and Referrer-Policy to limit data leakage if a redirect does occur.

# Example NGINX rule to block external next= values on notification endpoints
location ~ ^/notifications/ {
    if ($arg_next ~* "^https?://(?!horilla\.example\.com)") {
        return 400;
    }
    proxy_pass http://horilla_upstream;
}