Workreap Core EUVD-2026-108137

Exploitation requires an authenticated session on the target WordPress site: the CVSS vector specifies PR:L, so the attacker needs at least a low-privileged account (such as a registered Workreap marketplace user), not anonymous access. The target must be running the Workreap Core plugin at a version before 3.4.4. No user interaction is required (UI:N) and the vector is network-reachable (AV:N) once authenticated. The specific vulnerable feature, endpoint, or parameter is not described in the available sources, so the precise request needed to trigger the blind injection cannot be stated. The chief limiting factor is the authentication requirement, which restricts exploitation to users who can obtain a plugin account.

Signals are moderate and somewhat conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity flaw that nonetheless requires an authenticated account (PR:L), which materially lowers real-world exposure compared to an unauthenticated SQLi. No EPSS score, no CISA KEV listing, and no confirmed proof-of-concept were provided, 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' (not act_now/emergency), consistent with a serious but non-emergency authenticated injection flaw. The vendor-supplied C:H/I:N/A:L and S:C combination is internally questionable for a blind SQL read: confidentiality impact (C:H) is credible for blind SQLi, but the A:L availability impact and the scope-change (S:C) are not substantiated by the one-line description and should be verified with the vendor/Patchstack advisory. Overall this is a genuine high-severity issue worth near-term patching, but the authentication requirement and absence of exploitation signals argue against treating it as an immediate drop-everything emergency.

An attacker who holds a low-privileged account on a WordPress site running Workreap Core (e.g. a registered freelancer/employer user) sends crafted input to a vulnerable plugin parameter, injecting SQL that the application fails to neutralize. Because the injection is blind, the attacker infers database contents (user credentials, PII, tokens) through boolean or time-based inference rather than direct output. No public exploit code was identified at time of analysis; only a Patchstack advisory reference exists.