CVE Vulnerability Catalog

The Ansible keyring_info module leaks a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) into task results because the 'passphrase' output field lacks no_log protection. The passphrase is visible in logs, debug output, and fact caches.

A missing authorization vulnerability was found in the Event-Driven Ansible (EDA) websocket API. The /api/eda/ws/ansible-rulebook endpoint does not verify user permissions when processing Worker messages. Any authenticated user can send a forged message with an arbitrary activation_id to receive plaintext credentials associated with that activation, including OAuth tokens, vault passwords, and SSH keys.

FOSSBilling, a billing and client management system, has an IDOR vulnerability in versions 0.6.21 through 0.7.2, allowing authenticated clients to create support tickets referencing other clients' orders. The ticketCreateForClient() method did not verify order ownership, enabling manipulation of rel_id.

In Traefik versions from 3.7.0-ea.1 to 3.7.5, a medium severity vulnerability was found in the Kubernetes Ingress NGINX provider. When an Ingress explicitly enables BasicAuth or DigestAuth via auth-type and auth-secret annotations, but the referenced Secret cannot be resolved or parsed, Traefik logs the error, skips installing the authentication middleware, and still emits a router to the backend. This results in a protected route being published without access control, allowing unauthorized access.

Vulnerability in Traefik (versions prior to 3.6.21 and 3.7.5) in the Kubernetes Gateway provider affects the crossProviderNamespaces allowlist. For HTTPRoute rules with multiple backendRefs (WRR), Traefik incorrectly evaluates the allowlist against the target backendRef.namespace instead of the route's own namespace. This allows an HTTPRoute from a non-allowlisted namespace to reference internal Traefik services (e.g., api@internal) by pointing backendRef.namespace at an allowlisted namespace covered by a ReferenceGrant.

A vulnerability in rtk (versions before 0.42.2) allowed bypassing the permission control mechanism by hiding a second command within Bash shell constructs that were not properly split or rejected. A command starting with an allowed prefix (e.g., 'git') could contain a hidden command that executed without required user authorization.

Pi is a minimal terminal coding harness. From versions 0.74.0 to 0.78.1, temporary npm or git extension package installs used predictable paths under the operating system's temporary directory, allowing a local attacker to inject malicious code.

Pi, a minimal terminal coding harness, from version 0.74.0 to 0.78.1 stores API keys and OAuth credentials in auth.json. A race condition in the file write path could briefly create or rewrite this file with permissions derived from the process umask before tightening the file to owner-only permissions.

Pi is a minimal terminal coding harness. In versions from 0.74.0 to 0.78.1, HTML exports did not consistently reject unsafe Markdown link and image URL schemes, potentially leading to security vulnerabilities.

Pi is a minimal terminal coding harness. In versions before 0.79.0, Pi loaded project-local resources and configurations from a repository's .pi directory without asking the user to trust that repository, potentially allowing malicious code execution.

In Traefik prior to 3.7.3, a critical vulnerability in HTTP/3 (QUIC) TLS configuration selection allows unauthenticated clients to bypass router-specific mTLS enforcement. The TLS handshake fails to match wildcard host patterns (e.g., *.example.com) or case variants, falling back to a default TLS config that may not require client certificates.

In Traefik versions 3.7.0 through 3.7.3, a vulnerability in the domain-fronting protection (SNICheck) allows an unauthenticated client to bypass mutual TLS enforced by wildcard router rules. The attacker can complete a TLS handshake under permissive options for one SNI and then send an HTTP Host header targeting a wildcard-protected backend without presenting a client certificate.

In Traefik prior to versions 2.11.48, 3.6.19, and 3.7.3, a high severity vulnerability exists in the StripPrefix middleware. An unauthenticated attacker can bypass route-level authentication and authorization by using a request path containing '..' or its percent-encoded form '%2e%2e'.

In RTK (Rust Token Killer) prior to version 0.32.0, a vulnerability was found due to improper trust of project-local configuration files. The tool automatically loads .rtk/filters.toml from the working directory with highest priority and without user notification. An attacker can place a malicious filter file in a repository to selectively suppress or alter command output (including file contents, diffs, and security scan results) without detection, potentially concealing malicious code during AI-assisted development or review.

An issue in Pivotal CRM v.6.6.04.08 allows a remote attacker to execute arbitrary code via the Pivotal.Core.Common.dll and Pivotal.Engine.Client.Services.Conversion.dll components.

A vulnerability in the Ash library allows an attacker to set the value of a private action argument intended to be controlled only by trusted server-side code. The filtering of private arguments is incomplete both in the regular changeset path (for binary keys) and in the atomic path (no filtering at all).

The @rtk-ai/rtk-rewrite plugin version 1.0.0 fails to sanitize user input before passing it to a shell-backed execSync() template string, allowing arbitrary OS command injection. JSON.stringify() does not protect against shell metacharacters like $() and backticks, which are executed by /bin/sh -c.

In versions prior to 0.185.0, Daytona allowed organization role updates and deletions without verifying if the role belonged to the specified organization. An authenticated user owning any organization could modify permissions or delete a role belonging to another organization using that role's identifier.

In versions from 0.101.0 to 0.184.0, sandboxes switched from public to private could remain accessible without authentication for a short period after the change, due to a cached visibility state that was not invalidated.

In versions prior to 0.184.0, users could accept or decline organization invitations even if their email address was not verified. Daytona's authentication system did not require email verification for these actions, creating a risk of unauthorized access.