laravel-mongodb EUVD-2026-112255

Exploitation requires an application that uses this library's relationship query building and relies on an absence-of-related-record check (checking that no related document exists) to decide which documents a request may read, change, or delete; the related identifier involved must be of a data type that triggers the wrong-type compilation. The attacker needs an authenticated basic-privilege account (PR:L). Limiting factors: AT:P confirms the vulnerable application pattern must be present for the attack to succeed, so applications that do not gate authorization on absence-of-related-record logic are not exploitable; the failure is silent (no error), so impact depends entirely on how the application wires this check into access decisions. No special network configuration or user interaction is needed (UI:N).

This is a genuine but conditional authorization-bypass risk rather than a blanket critical. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N, score 7.7 High) tells a consistent story with the description: a network-reachable, low-privilege authenticated user (PR:L) can trigger it, but AT:P flags that success depends on conditions outside the attacker's control - here, the application must actually rely on the vulnerable relationship-absence check to make an authorization or visibility decision. Vulnerable-system impact is maximal (VC:H/VI:H/VA:H: read, modify, and delete of documents the check meant to withhold), while subsequent-system impact is none (SC/SI/SA:N), so blast radius is confined to the application's own data. No EPSS score, no CISA KEV listing, and no public exploit reference were supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today Decision label is 'this_week', which aligns with a serious-but-not-emergency posture: prioritize remediation within the week rather than treat as an immediate incident. Net: real priority for any Laravel application that gates access using absence-of-related-record logic on this library, but lower real-world urgency for deployments that do not use that pattern, since AT:P and PR:L both constrain exploitation.

In a Laravel application using the MongoDB integration library that enforces access control via a 'this request may only touch documents with no related record of type X' check (e.g. a doesntHave/whereDoesntHave-style guard), an authenticated low-privilege user sends a normal request whose related identifier is of a data type that gets compiled wrong. The absence check silently matches incorrectly and returns no error, so the user is served, can modify, or can delete documents that should have been hidden from them. No public exploit code is known; exploitation requires only a basic account and knowledge that the app relies on this check.