CVE-2026-115400 in Crawlseo
Summary
by MITRE • 10/23/2026
crawlseo before version 0.2.5 contains a cleartext storage vulnerability that allows attackers with database read access to obtain Google OAuth access and refresh tokens stored unencrypted in the User.googleTokens column. Attackers can read the plaintext long-lived refresh tokens from a compromised or exposed Postgres database to gain indefinite, unauthenticated access to all registered users' Google Search Console data.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in crawlseo versions prior to 0.2.5 represents a critical failure in credential management and data protection mechanisms within the application's authentication workflow. Specifically, the software stores Google OAuth access tokens and refresh tokens in plaintext within the User.googleTokens column of its PostgreSQL database backend. This architectural decision exposes sensitive cryptographic material that is essential for maintaining authenticated sessions with third-party services without requiring user re-authentication. The presence of unencrypted long-lived refresh tokens constitutes a severe security flaw because these tokens serve as persistent keys to access protected resources, effectively bypassing standard authentication controls when the underlying storage medium is compromised.
From an operational perspective, this vulnerability allows attackers who have achieved read access to the database to extract valid Google OAuth credentials for all registered users. Unlike short-lived access tokens which expire quickly and require a refresh token to obtain new ones, long-lived refresh tokens can remain valid for extended periods or indefinitely depending on user settings and provider policies. Consequently, an attacker with database read privileges does not need to compromise individual user passwords or exploit additional application logic flaws to gain control over Google Search Console accounts. The ability to retrieve these plaintext tokens directly translates into the capability to impersonate legitimate users across all their associated services that rely on this specific OAuth integration.
The impact of this vulnerability is extensive and affects data confidentiality, integrity, and availability for every user utilizing crawlseo with Google Search Console integrations. Attackers can use the stolen refresh tokens to generate new access tokens at will, granting them unauthenticated access to sensitive search performance data, indexing status reports, security issues, and other proprietary metrics hosted within Google Search Console. This exposure enables malicious actors to monitor competitor strategies, steal intellectual property embedded in site configurations, or potentially inject misleading data if write permissions are also compromised through subsequent API calls facilitated by the stolen tokens. The indefinite nature of these refresh tokens means that even after a password change on the crawlseo platform, the attacker retains access until the specific Google OAuth consent is revoked manually by each affected user, creating a prolonged window of exploitation and remediation complexity.
This flaw aligns with CWE-312 Cleartext Storage of Sensitive Information, which describes scenarios where sensitive data such as passwords or cryptographic keys are stored without encryption in files, databases, or memory. Furthermore, the attack vector corresponds to ATT&CK technique T1552 Unsecured Credentials, specifically sub-technique T1552.004 Cloud Accounts, where attackers target credentials stored within cloud-based applications and services. The exploitation path typically involves initial access through database compromise via SQL injection, weak authentication on the database server itself, or misconfigured permissions that allow unauthorized read operations against application data stores.
Mitigation strategies must prioritize immediate remediation of the storage mechanism alongside broader security hygiene improvements. Developers should update crawlseo to version 0.2.5 or later where this issue has been addressed by implementing proper encryption for stored tokens using industry-standard algorithms such as AES-256-GCM with strong key management practices, ideally leveraging a dedicated secrets manager rather than application-level storage whenever possible. For organizations currently running vulnerable versions, it is imperative to rotate all affected Google OAuth credentials immediately upon detection of the vulnerability or any suspected database compromise. Users must revoke existing access grants for crawlseo within their Google Account security settings and re-authorize the connection after the vendor has patched the system. Additionally, implementing strict least-privilege principles on the PostgreSQL database layer ensures that application service accounts do not possess unnecessary read permissions beyond what is strictly required for operational functionality, thereby reducing the attack surface available to potential intruders who may have breached other perimeter defenses.