Horilla Horilla HR notification endpoints allow open redirects via unvalidated next parameter

Horilla is an HR and CRM software. In 1.5.0, the notification endpoints trust the unvalidated next parameter and redirect users to arbitrary external URLs. This allows an attacker to turn trusted application links into phishing or social-engineering redirects.

• The normalized record identifies vendor horilla and product horilla-hr, with <= 1.5.0 marked affected.
• The vendor advisory confirms that 1.5.0 is affected and lists patched versions as None.
• The repository contains a fix that restricts redirects to allowed hosts, but the available evidence does not associate that commit with a specific released version.
• The status of versions or branches after 1.5.0 is not fully established by the available evidence. Do not assume that a later or parallel branch is safe solely because the fix exists in the repository.

Horilla HR notification endpoints read the next query parameter and pass its value directly to redirect() without checking whether the destination is a safe internal path. The advisory identifies the mark-all-as-read/ route in notifications/urls.py and the mark_all_as_read function in notifications/views.py; the related fix commit applies the same change to mark-as-read, mark-as-unread, and delete notification actions. The affected flow requires an authenticated user, after which the browser follows a crafted link containing an attacker-controlled next value. When the value is an external URL, the application redirects to that host instead of restricting the destination to an internal path or an allowed host. The fix adds url_has_allowed_host_and_scheme() before calling redirect() and uses iri_to_uri() for the accepted value. The full set of affected notification endpoints beyond those described in the advisory is not completely established.

The issue is reachable over the network by an authenticated user and requires that user to actively open a crafted link. The evidence supports a low-complexity attack in which the attacker places an external URL in the next parameter, the application performs the notification action, and the browser is then redirected to that URL. The record marks a public exploit, and the advisory documents a proof of concept on a local installation. The supplied evidence does not establish exploitation in an active campaign; that status should be tracked separately.

The direct technical result is an HTTP redirect to a user-controlled URL instead of keeping the user within Horilla HR. The flaw does not directly grant new privileges or alter the confidentiality, integrity, or availability of the Horilla HR system, but it can create impact on a subsequent system when a victim is sent to a malicious site. Realistic organizational consequences include more credible phishing, credential loss, or malware delivery if users continue interacting with the destination. Exploitation depends on an authenticated user and that user's interaction with the crafted link; the redirect alone does not establish server takeover.

The issue weakens trust in Horilla HR links and can make users believe they are still interacting with the application when they have actually been sent to an external website. An attacker can use the redirect to support phishing, trick users into disclosing credentials, or deliver malicious content; the downstream result depends on the victim's actions and the destination site. The notification action may complete before the browser follows the redirect, which can make the malicious link appear to perform a legitimate application action. There is no evidence that this redirect directly allows reading, modifying, or disrupting Horilla HR data.

1. Prioritize moving off affected versions. The advisory does not identify a patched release, so track the Horilla HR release that contains the fix and verify the deployed version after upgrading.
2. If deploying from source, apply the vendor's notification fix and confirm that next is checked with url_has_allowed_host_and_scheme() before redirect() is called. Do not treat the existence of a repository commit as proof that the running build includes the fix.
3. Until an update is available, stop affected notification endpoints from honoring external next values and allow only internal paths or explicitly approved hosts. This is temporary mitigation, not a replacement for updating.
4. After the change, test all four notification branches covered by the fix: mark all as read, mark as read, mark as unread, and delete. Confirm that external destinations are rejected or that the application falls back to its internal default destination.

1. Inventory Horilla HR deployments and identify the deployed version. The normalized record marks versions <= 1.5.0 as affected, and the advisory confirms that 1.5.0 is affected.
2. Inspect deployed code in notifications/urls.py and notifications/views.py for request.GET.get("next") followed by a direct redirect() using that value.
3. Confirm that every redirect branch from the notification endpoints validates next with url_has_allowed_host_and_scheme() or an equivalent allowlist check before redirecting.
4. In a test environment, review redirect responses from the affected endpoints when next is present, especially any Location header pointing to a host outside the approved set. Absence of such log evidence does not prove that a deployment is safe.
5. Review access logs for requests to notification endpoints containing next and 3xx responses whose destination is an external host. Treat this as an additional precautionary check, not as a confirmed IOC.