Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The trustedCertPool() function in the TLS configuration only parses the first PEM block from CA certificate files. When a CA bundle contains multiple certificates (e.g., intermediate + root CA), only the first certificate is loaded. This silently breaks certificate chain validation for mTLS. Impact In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with x509: certificate signed by unknown authority. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification. All versions using TLS with trustedCaFile configuration are affected. Details In common/security/tls.go, the trustedCertPool() method calls pem.Decode() only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from…
Recommended action: Upgrade to 0.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A race condition between session heartbeat processing and session closure can cause the server to panic with send on closed channel. The heartbeat() method uses a blocking channel send while holding a mutex, and under specific timing with concurrent close() calls, this can lead to either a deadlock (channel buffer full) or a panic (send on closed channel after TOCTOU gap in KeepAlive). Impact A remote client can trigger a server crash by sending rapid KeepAlive requests while a session is expiring or being closed. This is a denial-of-service vulnerability that crashes the entire data server process. All versions are affected. Details In oxiad/dataserver/controller/lead/session.go, the heartbeat() method performs a blocking s.heartbeatCh <- true send. If the channel buffer is full (size 1), this blocks while holding the session mutex, preventing close() from acquiring the lock to close the channel — a deadlock. Additionally, in sessionmanager.go, KeepAlive() releases the…
Recommended action: Upgrade to 0.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OIDC authentication provider unconditionally sets SkipClientIDCheck: true in the go-oidc verifier configuration, disabling the standard audience (aud) claim validation at the library level. This allows tokens issued for unrelated services by the same OIDC issuer to be accepted by Oxia. Impact In deployments using OIDC authentication, an attacker possessing a valid JWT token issued by the same identity provider but intended for a different service (different clientid/aud) can authenticate to Oxia. This bypasses the intended audience isolation of OAuth2/OIDC. All versions using OIDC authentication are affected. Details In oxiad/common/rpc/auth/oidc.go, both createStaticKeyVerifier() and createRemoteVerifier() set SkipClientIDCheck: true. While a custom audience check exists in Authenticate(), the library-level check — which validates the aud claim against the expected clientid — is completely bypassed. Patches Fixed by removing SkipClientIDCheck: true and setting the…
Recommended action: Upgrade to 0.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact An attacker with access to application logs (e.g., via a compromised log aggregation pipeline, shared logging infrastructure, or misconfigured log access controls) can extract valid JWT tokens and replay them to authenticate as legitimate users. All versions using OIDC authentication are affected. Details In oxiad/common/rpc/auth/interceptor.go, the validateTokenWithContext() function logs the complete token value via slog.String("token", token) when authentication fails. This includes the full JWT header, payload, and signature. Patches Fixed by redacting the token in log output — only the last 8 characters are preserved for correlation purposes. Workarounds Ensure DEBUG-level logging is never enabled in production environments.
Recommended action: Upgrade to 0.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.