Which versions of Hi.Events are affected by EUVD-2026-40144?

Hi.Events promo code system (v1.9.0 and earlier) allows unlimited redemption of limited promotional codes through a validation timing gap, enabling revenue loss via unauthorized discounts.

How to fix or mitigate EUVD-2026-40144?

Within 24 hours: Identify all deployed Hi.Events instances and current promotional codes with usage limits; review transaction logs for anomalous redemption patterns (multiple orders per user/IP using same restricted code). Within 7 days: Immediately disable all time-limited and quantity-restricted promotional codes; implement synchronous usage counter validation by moving counter updates into the order completion transaction; deploy per-user rate limiting on promo code redemptions. Within 30 days: Contact Hi.Events for security update availability and timeline; conduct financial audit of all redemptions during the vulnerability window; plan production deployment of patched version once available and validated.

Hi.Events EUVD-2026-40144

Q: What is the CVSS score of EUVD-2026-40144?

EUVD-2026-40144 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-57959 HIGH

Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367)

2026-06-29 disclosure@vulncheck.com

GHSA-m75j-c5ff-9wh8

Information Disclosure

8.2

CVSS 4.0 · Vendor: vulncheck

Severity by source

Vendor (vulncheck) PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

5.3 MEDIUM

Unauthenticated network checkout flow (PR:N/AV:N); description shows reliable sequential exploitation so AC:L not AC:H; impact is limited integrity abuse of discount limits (I:L), no C or A.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 29, 2026 - 18:35 vuln.today

DescriptionCVE.org

Hi.Events through 1.9.0 contains a promo code validation vulnerability where reservation validates usage count before asynchronous UpdateEventStatisticsJob increments it, allowing attackers to redeem limited promo codes unlimited times. Attackers can sequentially reserve multiple orders with the same restricted promo code, each reading order_usage_count=0 and passing validation, then complete them all at discounted prices without concurrent requests.

AnalysisAI

Promo code usage-limit bypass in Hi.Events through version 1.9.0 lets remote attackers redeem restricted/limited promo codes an unlimited number of times by exploiting a time-of-check/time-of-use gap between synchronous reservation validation and the asynchronous UpdateEventStatisticsJob that increments the usage counter. Because validation reads order_usage_count before the background job updates it, an attacker can sequentially reserve and complete many discounted orders - no concurrent/racing requests are even required. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV; the CVSS 4.0 base score is 8.2, reflecting high integrity impact on the platform's discount/pricing controls.

Technical ContextAI

Hi.Events is an open-source, self-hostable event management and ticketing platform (PHP/Laravel backend with a React frontend). The flaw is a classic CWE-367 Time-of-Check Time-of-Use (TOCTOU) race condition, but realized through asynchronous job processing rather than thread-level concurrency: promo code redemption limits are enforced at reservation time by reading a usage counter (order_usage_count), while the actual increment of that counter is deferred to a queued background worker (UpdateEventStatisticsJob). The window between the synchronous check and the asynchronous write means multiple reservations can each observe a stale count of 0 and pass validation. This is a state-management/consistency design defect in the order workflow rather than a memory-safety or injection bug.

RemediationAI

No vendor-released patch identified at time of analysis - neither a fixed version nor a tagged release/commit is present in the provided references (only a GitHub issue and the VulnCheck advisory). Operators should monitor https://github.com/HiEventsDev/Hi.Events/issues/1223 and upgrade as soon as a fixed release is published. As specific compensating controls: enforce the promo code usage limit synchronously and atomically at reservation time (e.g., decrement remaining uses within the same database transaction using SELECT ... FOR UPDATE or an atomic conditional UPDATE) rather than relying on the asynchronous UpdateEventStatisticsJob - the trade-off is added lock contention at checkout under high load; alternatively, place a unique/row-level lock on the promo code record during reservation, or temporarily disable limited/restricted promo codes for high-value discounts until fixed (trade-off: lost promotional functionality). Reconciling completed orders against promo code limits and refunding/cancelling over-redemptions is a detective control while a fix is pending.