Horilla HR EUVD-2026-87371

Exploitation requires a victim who is currently authenticated to Horilla as a manager holding the attendance.change_attendance permission and who, while that session is active, is tricked into triggering a top-level request to /attendance/approve-validate-attendance-request/. It works specifically because the pre-2.0.0 endpoint accepts HTTP GET and mutates state (attendance_validated, is_validate_request_approved, approved_by) before attendance.save(), so Django never enforces CSRF, and the SameSite=Lax cookie policy still permits the cookie on top-level GET navigations. Limiting factors: requires active victim session, requires victim user interaction (clicking/visiting attacker content), only affects instances running versions below 2.0.0, and the attacker cannot choose the approving identity - impact is bounded to whatever the victim manager can approve.

This is a genuine but modest-severity CSRF flaw (CWE-352) with a coherent signal set. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:H/VA:N) and score of 5.9 (medium) align with the description: network-reachable, unauthenticated attacker (PR:N), but exploitation is gated on an attack requirement (AT:P) and active victim interaction (UI:A) - a logged-in manager holding attendance.change_attendance must be lured into a top-level request while their SameSite=Lax session cookie rides along. The root cause is confirmed in the commit diff: approve_validate_attendance_request performed state changes over HTTP GET before attendance.save(), so Django's CSRF middleware never engaged; the fix adds @require_http_methods(["POST"]) and converts hx-get to hx-post. No EPSS score was provided, there is no CISA KEV listing, and no public exploit code is referenced (the vuldb entry is an advisory, not a POC), so this is not a confirmed-exploited priority. Impact is confined to integrity of attendance records - silently approving requests and falsely attributing approvals in the audit trail - with no confidentiality or availability loss. Note the impact tension: the vendor rates VI:H, but the practical business impact (approving one class of attendance record) reads closer to a low/moderate integrity effect. Realistic priority: LOW-to-MEDIUM - patch in normal cycle; the double gate of victim authentication plus user interaction sharply limits opportunistic mass exploitation.

An attacker crafts a malicious web page or email link pointing at /attendance/approve-validate-attendance-request/<id>/ and gets a logged-in Horilla manager (with attendance.change_attendance) to open it in the same browser. Because the pre-patch endpoint accepted GET and skipped CSRF validation, the manager's SameSite=Lax session cookie is sent on the top-level navigation, silently approving the targeted attendance request under the victim's identity and stamping the audit trail with the victim as approver. No public exploit code is identified, but the technique is trivial classic CSRF once a victim is targeted.