Tankuam Places Kompini EUVD-2026-84341

No special conditions beyond reaching the application's password-recovery endpoint: exploitation requires the recovery workflow to be exposed and the attacker to hold any valid recovery JWT, which is then reused against an arbitrary 'usuariId' because the token is not bound to that identifier. It works against the default configuration - no authentication, no privileged role, and no victim interaction are needed. The only real-world limiters are network reachability of the '/password/guardarClau/recover' endpoint and the narrow deployment of the affected product; there is no non-default feature toggle or platform prerequisite stated in the advisory.

This is a genuine high-priority vulnerability. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H = 9.3) is fully consistent with the description: an unauthenticated, network-reachable IDOR (CWE-639) in the password-recovery flow where the JWT recovery token is not bound to the 'usuariId' parameter, so an attacker simply swaps the identifier to reset any account's password, including administrative ones. All signals point to low-effort, high-impact exploitation: no privileges, no user interaction, low complexity, and complete confidentiality/integrity/availability impact over the targeted account (full takeover). There are NO conflicting signals in the vector itself - network vector matches an HTTP endpoint, and PR:N matches the explicitly 'unauthenticated attacker' language. The tempering factors are entirely outside the technical vector: EPSS is not provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced - so despite the near-critical score there is no evidence of active or widespread exploitation, and the affected product ('Tankuam Places Kompini', per the INCIBE advisory) appears to be a niche/regional application with a small deployment footprint. Net: technically a critical, trivially-exploitable account-takeover flaw, but realistic aggregate risk is bounded by the product's limited prevalence rather than by any defensive control.

An unauthenticated attacker initiates or observes the password-recovery flow, obtains any valid recovery JWT, then sends a POST to '/password/guardarClau/recover' with the 'usuariId' parameter set to a victim's (e.g. an administrator's) account ID; because the token is never checked against that ID, the server resets the chosen account's password. The attacker logs in with the new credentials and takes over the administrative account. No public proof-of-concept is referenced, but the attack requires only trivial parameter manipulation given the low-complexity, unauthenticated vector.