Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable API exploitable by a low-privilege authenticated account (PR:L), no user interaction, yielding cleartext credential disclosure (C:H) with no integrity or availability impact.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
2DescriptionCVE.org
Parseable before 2.9.2 contains an information disclosure vulnerability in the notification-target API endpoints that returns webhook tokens and basic-auth credentials in cleartext due to commented-out secret-masking functionality. Any authenticated user with the GetAlert action, including low-privilege reader roles, can recover credentials and internal endpoint URLs for all configured notification targets by querying GET /api/v1/targets or related endpoints.
AnalysisAI
Cleartext credential exposure in Parseable before 2.9.2 lets any authenticated user holding the GetAlert action - including low-privilege reader roles - retrieve webhook tokens, basic-auth credentials, and internal endpoint URLs for every configured notification target by calling GET /api/v1/targets. The exposure stems from secret-masking logic that was commented out, so the API serializes stored secrets verbatim. No public exploit has been identified at time of analysis, but the issue is trivially reproducible against any instance with notification targets configured and is fixed in release v2.9.2.
Technical ContextAI
Parseable is an open-source, S3-backed observability and log-analytics platform written in Rust that exposes a REST API (e.g. /api/v1/targets) for managing alerting and notification targets such as webhooks and other HTTP receivers. Notification targets persist authentication material (bearer/webhook tokens and HTTP basic-auth username:password pairs) so Parseable can call out to those endpoints. This maps to CWE-522 (Insufficiently Protected Credentials): the API response model was supposed to redact these secrets before returning target objects, but the masking code path was commented out, causing the credentials and internal endpoint URLs to be returned in plaintext. The root cause is therefore an output-serialization/authorization design defect rather than a memory-safety or injection bug - the data is correctly stored but improperly disclosed to under-privileged callers.
RemediationAI
Upgrade to the vendor-released patch: Parseable v2.9.2 (https://github.com/parseablehq/parseable/releases/tag/v2.9.2), which restores the secret-masking behaviour removed by the commented-out code (fix in PR #1698 / commit f307c4989cc9f3ff4204fd383dec7a39924e6b2a). Because the leaked secrets are downstream credentials, also rotate every webhook token and basic-auth credential configured on notification targets after upgrading, on the assumption they may already have been read by any account holding GetAlert. Until you can patch, restrict the GetAlert action and tighten role assignments so that only trusted administrators can query notification targets, and consider network-restricting access to the /api/v1/targets endpoints; the trade-off is that scoping GetAlert away from reader roles may break legitimate alert-visibility workflows for those users, and there is no configuration flag that re-enables masking without the code fix.
Same weakness CWE-522 – Insufficiently Protected Credentials
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-40159
GHSA-9cf6-6j4g-mw9r