GeoDirectory EUVD-2026-100899

Exploitation requires an authenticated account with subscriber-level privileges or above (PR:L), which in practice means the target site must permit user registration or the attacker must already hold credentials; the attacker then abuses the listing-submission flow, specifically the 'post_images' title field (file_info[2]), which GeoDirectory stores without sufficient sanitization and renders without output escaping. The payload executes only when another user subsequently loads the page containing the injected listing, so impact depends on victims viewing attacker-controlled content. Limiting factors: the subscriber-or-above authentication barrier (sites with registration disabled are far less exposed) and the need for a victim to visit the injected page for payload execution.

This is a realistic but moderate-priority issue rather than an emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, base 6.4 Medium) indicates network-reachable, low-complexity exploitation requiring only low privileges (subscriber-level, PR:L) with a scope change (S:C) reflecting that injected script executes in other users' browser contexts. No EPSS score, KEV listing, SSVC decision, or POC indicator was supplied in the input, so exploitation-probability and automation signals cannot be assessed; absence of these is not evidence of safety but does mean there is no confirmed active exploitation. The principal real-world constraint is the authentication requirement: an attacker must first obtain a subscriber (or higher) account, which on sites allowing open registration is trivial but on closed/invite-only sites is a meaningful barrier. There are no conflicting signals in the data - the stored-XSS description is consistent with the CVSS vector - so the main gap is simply the missing threat-intel enrichment (EPSS/KEV/POC not provided).

An attacker registers or uses an existing subscriber-level account on a site running GeoDirectory and submits a listing, injecting a malicious script payload through the 'post_images' title field (file_info[2]). Because the input is neither sanitized on storage nor escaped on output, the script is persisted and later executes in the browser of any user - including administrators - who views the affected listing page, enabling session/cookie theft or actions in the victim's context. No public exploit code was identified in the provided data.