crawlseo EUVD-2026-108165

Exploitation requires read access to the application's backend Postgres database (for example a compromised host or an exposed/misconfigured Postgres instance); the attacker then reads unencrypted Google access and refresh tokens from the User.googleTokens column in any crawlseo deployment before 0.2.5. Limiting factors: this is not exploitable over the network against the app itself - it presupposes database-level access (reflected as AV:L/PR:H), it affects only versions before 0.2.5, and tokens that users have proactively revoked via the Account page's 'Disconnect Google' action are cleared. After upgrading, existing plaintext tokens are encrypted at their next refresh or via the bundled scripts/encrypt-google-tokens.ts migration; the vendor's encryption-at-rest change is the only complete fix.

This is a post-compromise confidentiality exposure (CWE-312, cleartext storage), not a remotely triggerable flaw against the running application. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:H/UI:N, VC:H) correctly models that exploitation requires read access to the backend Postgres database - PR:H and AV:L reflect that the attacker must already hold database-level access, whether through a prior compromise or a misconfigured/exposed Postgres instance as the description states. Severity is medium (6.7) and the vuln.today Decision label is 'this_month', not act_now or emergency, so this should be scheduled, not treated as an incident. EPSS is not provided in the input and there is no CISA KEV listing, consistent with no evidence of mass exploitation. The input does include a public gist and the fix commit as references, so a public PoC reference exists; it is not verified as working exploit code. The main risk amplifier is impact rather than access: the leaked data is long-lived Google OAuth refresh tokens granting indefinite, unauthenticated access to every registered user's Search Console data, so a single database read compromises all users at once. Net assessment: a real but conditional, defense-in-depth issue - meaningful for anyone who may have exposed their Postgres instance, low urgency for well-isolated deployments.

An attacker who obtains read access to crawlseo's Postgres database - via an exposed/misconfigured instance or a prior host compromise - queries the User.googleTokens column and recovers plaintext Google OAuth access and refresh tokens. Because the refresh tokens are long-lived, the attacker gains indefinite, unauthenticated access to all registered users' Google Search Console data. A public PoC reference (a gist) is linked in the input but is not verified as working exploit code.