EUVD-2026-24511
GHSA-pm7q-rjjx-979p
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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
AC:H because non-default debug logging plus an auth failure are required; PR:H because reading application/aggregation logs presumes privileged access; C:H for full token exposure, no integrity or availability impact.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
7DescriptionGitHub Advisory
Oxia is a metadata store and coordination system. Prior to 0.16.2, when OIDC authentication fails, the full bearer token is logged at DEBUG level in plaintext. If debug logging is enabled in production, JWT tokens are exposed in application logs and any connected log aggregation system. This vulnerability is fixed in 0.16.2.
AnalysisAI
Sensitive information disclosure in Oxia (a metadata store and coordination system) prior to 0.16.2 causes the full OIDC bearer token to be written in plaintext to application logs at DEBUG level whenever authentication fails. Anyone able to read those logs - via a compromised or shared log aggregation pipeline or misconfigured log access controls - can harvest valid JWTs (header, payload, and signature) and replay them to impersonate legitimate users. No public exploit identified at time of analysis; EPSS is low at 0.05%, and CISA SSVC records exploitation status as none.
Technical ContextAI
Oxia authenticates clients using OpenID Connect (OIDC) bearer tokens (JWTs) validated at the RPC layer. The root cause is CWE-532 (Insertion of Sensitive Information into Log File): in oxiad/common/rpc/auth/interceptor.go, the validateTokenWithContext() function emits the raw token via slog.String("token", token) on the authentication-failure path, so the complete JWT - including its signature - lands in structured logs. Because JWTs are bearer credentials, possession alone grants access until expiry, making log exposure equivalent to credential leakage. The affected component is the Go package go/github.com/oxia-db/oxia (CPE cpe:2.3:a:oxia-db:oxia), and the fix redacts all but the last 8 characters of the token for correlation.
RemediationAI
Vendor-released patch: upgrade Oxia to 0.16.2, which redacts the token in log output and preserves only the last 8 characters for correlation (fix commit https://github.com/oxia-db/oxia/commit/f7259d0ebc739fc95ff19f93c823433850857416; advisory https://github.com/oxia-db/oxia/security/advisories/GHSA-pm7q-rjjx-979p). If you cannot upgrade immediately, apply the vendor workaround of ensuring DEBUG-level logging is never enabled in production - the trade-off is reduced diagnostic detail during incident investigation. As compensating controls, tighten access to application logs and any log aggregation system (least-privilege on the logging pipeline), and rotate/revoke any OIDC tokens that may already have been captured while debug logging was active, accepting the operational cost of forcing re-authentication.
Authentication bypass in Oxia (oxia-db) metadata store and coordination system prior to 0.16.2 allows an attacker holdin
Denial-of-service in Oxia (metadata store and coordination system) versions <= 0.16.1 allows a remote unauthenticated cl
Incomplete PEM parsing in Oxia's TLS subsystem silently drops all but the first certificate from CA bundle files, breaki
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today