WeGIA CVE-2026-55682

Exploitation requires that the auto-prepended web/html/seguranca/sessionStart.php session handler (present on all PHP pages prior to 3.8.6) reflects the attacker-supplied PHPSESSID cookie into a Set-Cookie response. The attack is gated by victim interaction (UI:R): a legitimate user MUST authenticate while carrying the attacker-selected PHPSESSID for the hijack to succeed, so the attacker must first deliver that identifier to the victim (e.g., via a crafted link/response). It is otherwise remote and unauthenticated from the attacker's side (PR:N). The secondary internal database host disclosure occurs automatically through the cookie Domain attribute (set to DB_HOST). Limiting factors: success depends on the victim logging in under the fixed identifier, and the issue is fully remediated by upgrading to WeGIA 3.8.6, which switches to session_set_cookie_params()/session_start() with Secure, HttpOnly, and SameSite=Strict.

This is a genuine session-hijacking flaw with a moderate, conditional risk profile. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, 8.1 HIGH) is network-reachable and needs no attacker privileges, but the UI:R metric is load-bearing: exploitation is a session-fixation chain that only succeeds if a victim authenticates while using the attacker-selected PHPSESSID, so this is a targeted/social-engineering attack rather than a mass-exploitable RCE. No EPSS score, KEV listing, or published POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The affected product (WeGIA, a niche manager for charitable institutions) has a small deployment footprint, which further lowers real-world priority. Note a signal nuance: the input is tagged and classified as CWE-200 Information Disclosure, but the dominant impact per the description is authenticated session hijacking (session fixation) - the DB_HOST disclosure via the cookie Domain attribute is the secondary effect. Treat the C:H/I:H as driven by account takeover, not merely data leakage. Overall: a real bug worth patching promptly for WeGIA operators, but not a widespread-internet-scanning emergency.

An attacker crafts a link or request that seeds a victim's browser with an attacker-chosen PHPSESSID value, which the vulnerable sessionStart.php reflects back verbatim in a Set-Cookie header. The victim then logs into WeGIA under that fixed identifier, and the attacker - who already knows the identifier - reuses it to ride the now-authenticated session. No public exploit code was identified, though the fix commit publicly reveals the vulnerable Set-Cookie logic.