Export limit exceeded: 425070 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1375 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-123082 | 1 Docker | 1 Desktop | 2026-11-10 | N/A |
| Docker Desktop before version 4.94.0 could write the signed-in user's Docker Hub access token (a JWT) in cleartext to application logs and diagnostics bundles. IPC payloads that were bare JSON strings or arrays were not redacted before logging, and a Docker Desktop component logged the token when it requested it from the backend. An attacker with read access to these files could obtain the token and use it to read and modify the user's Docker Hub data as that user while the token remains valid. Docker Desktop 4.94.0 redacts these payloads. The fix does not rewrite logs written by earlier versions, which can still contain tokens after upgrading. | ||||
| CVE-2026-123372 | 1 Tmatens | 1 Compose-lint | 2026-11-10 | N/A |
| compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.22.0 until 0.32.0, compose-lint substitutes values from a sibling .env file into image fields and quotes the resolved value in CL-0004 and CL-0019 finding messages and fix text. In a workflow that writes secrets into that file and then lints untrusted pull-request content, an attacker can reference a secret variable so its whole value reaches the job log, JSON output, SARIF artifacts, and Code Scanning alerts. Fork pull requests normally lack secrets, so exploitation requires a secret-bearing workflow such as pull_request_target, same-repository branches, or a retained .env on a self-hosted runner, and the pass or fail result is unchanged. This issue is fixed in version 0.32.0. | ||||
| CVE-2026-123796 | 1 Tmatens | 1 Compose-lint | 2026-11-10 | N/A |
| compose-lint is a Docker Compose security linter that identifies dangerous misconfigurations before deployment. From 0.32.0 until 0.33.0, compose-lint's incomplete remediation for .env secret disclosure checks the 20,000-finding limit before replacing resolved values with their variable references. A pull request can combine a secret-referencing image field with aliased content that produces more than 20,000 findings, causing the early-stop path to emit already graded findings with the resolved secret value in text, JSON, SARIF, and Code Scanning output. Exploitation requires a workflow that writes secrets into the sibling .env and lints untrusted changes, and the run exits 2 unless --allow-partial-coverage is used. This issue is fixed in version 0.33.0. | ||||
| CVE-2026-102289 | 1 Zizmorcore | 1 Zizmor | 2026-11-10 | N/A |
| zizmor is a static analysis tool for CI/CD systems. In version 1.27.0, debug logging serializes the parsed application configuration with a derived Debug implementation for GitHubToken, causing credentials supplied through GH_TOKEN, GITHUB_TOKEN, ZIZMOR_GITHUB_TOKEN, --gh-token, --github-token, or --zizmor-github-token to be written to stderr in cleartext. A single -v or --verbose option or an applicable RUST_LOG directive enables the affected logging during normal online operation and --no-online-audits, while explicit --offline clears the token first. If another party can read a CI log, support artifact, terminal capture, or public bug report containing the output, the party can use the credential according to its scopes, repository access, and lifetime. This vulnerability is fixed in 1.28.0. | ||||
| CVE-2026-81209 | 1 Ibm | 2 Sterling B2b Integrator, Sterling File Gateway | 2026-11-09 | 4.9 Medium |
| IBM Sterling B2B Integrator 6.2.1.0 through 6.2.1.2_1, 6.2.2.0 - 6.2.2.1_1 and IBM Sterling File Gateway 6.2.1.0 through 6.2.1.2_1, 6.2.2.0 - 6.2.2.1_1 Standard Edition could allow a remote authenticated attacker to obtain sensitive information due to improper logging of sensitive credentials. | ||||
| CVE-2026-12737 | 1 Ibm | 2 Sterling B2b Integrator, Sterling File Gateway | 2026-11-09 | 4.4 Medium |
| IBM Sterling B2B Integrator 6.2.2.0 through 6.2.2.1_1 and IBM Sterling File Gateway 6.2.2.0 through 6.2.2.1_1 stores potentially sensitive information in log files that could be read by a local privileged user. | ||||
| CVE-2026-91163 | 1 Warp-tech | 1 Warpgate | 2026-11-09 | 3.7 Low |
| Warpgate is an open source SSH, HTTPS, and MySQL bastion host for Linux. Prior to 0.29.0, the Kubernetes protocol listener uses AcceptAnyClientCert in warpgate-protocol-kubernetes/src/server/client_certs.rs to accept certificates at the TLS layer and defer validation to warpgate-protocol-kubernetes/src/server/auth.rs, where authentication and lookup failures are rendered verbatim in an HTTP 500 response body. The Kubernetes application in warpgate-protocol-kubernetes/src/server/mod.rs lacks the outer request-logging wrapper used by the HTTP protocol, and failures in warpgate-protocol-kubernetes/src/server/handlers.rs can short-circuit before its inner log point. An unauthenticated network client can therefore induce failures and receive ASN.1/DER parser diagnostics or sea_orm database errors without the attempt being recorded in the gateway log. The disclosed information is limited to internal diagnostics, and no user-data, integrity, or availability impact is established. This issue is fixed in version 0.29.0. | ||||
| CVE-2026-54145 | 1 Tinyhumansai | 1 Openhuman | 2026-11-09 | 8.8 High |
| OpenHuman is an open-source agent harness available as a desktop application and Rust library. In affected versions before 0.57.5, the approval gate uses the JSON-RPC bearer token as an approval session identifier. This exposes the credential through persisted approval records, events, debug logs, and RPC responses, including during normal desktop operation. An attacker who obtains these artifacts can recover the token and access the core RPC interface while it remains valid. This can expose sensitive agent and integration data and permit privileged operations. Stable tokens remain usable until rotated; launch-specific tokens remain usable while the corresponding core instance is active. The fix is included in version 0.57.5. | ||||
| CVE-2026-118467 | 1 Compugroup Medical | 4 Infantia, Phronesis, Profim and 1 more | 2026-11-09 | N/A |
| Shared telemetry and logging components store or transmit patient and doctor identifiers, clinical information, and low-entropy identifiers without adequate pseudonymization or protection. | ||||
| CVE-2026-118798 | 1 Compugroup Medical | 1 Wingesfar | 2026-11-09 | N/A |
| Multiple sensitive authentication data, including credentials, OAuth-related secrets, session information, and authentication artifacts, are exposed through application logs and persistent client-side storage, enabling unauthorized access and session compromise. | ||||
| CVE-2026-63417 | 1 Armurox | 1 Logging Redactor | 2026-11-09 | N/A |
| Logging Redactor is a Python library designed to redact sensitive data in logs based on regex patterns and / or dictionary keys. Prior to 0.0.7, personally identifiable information returned by custom object __str__ or __repr__ methods is not redacted when such non-primitive objects are logged, causing sensitive values to appear in logs that are expected to mask them. This issue is fixed in version 0.0.7. | ||||
| CVE-2026-123502 | 1 Vikunja | 1 Vikunja | 2026-11-09 | 5.2 Medium |
| Vikunja before 2.7.1 contains an information exposure vulnerability that allows log readers to obtain link-share hashes because the request logger records the raw URI of the /shares/:share/auth route. Attackers with access to Vikunja or reverse proxy access logs can reuse non-expiring, non-password-protected share hashes to obtain a project JWT with read, write or admin permission. | ||||
| CVE-2026-14252 | 1 Ibm | 1 Mq | 2026-11-08 | 6.2 Medium |
| IBM MQ 9.2.0.0 through 9.2.0.44 LTS, 9.3.0.0 through 9.3.0.42 LTS, 9.4.0.0 through 9.4.0.26 LTS, 9.4.0.0 through 9.4.5.1 CD, and 10.0.0.0 through 10.0.0.5 LTS and CD stores potentially sensitive information in log files that could be read by a local user. | ||||
| CVE-2026-123512 | 1 Vikunja | 1 Vikunja | 2026-11-08 | 6.1 Medium |
| Vikunja before 2.7.1 embeds live password-reset, email-confirmation and account-deletion tokens in the URL query string of emailed links, so the full request URI, including the token, is written to Vikunja's HTTP access log and any reverse-proxy logs when a user clicks the link. Attackers with read access to those logs can replay an unredeemed password-reset token to take over the account or an account-deletion token to confirm the deletion. | ||||
| CVE-2026-123316 | 2026-11-06 | 5.5 Medium | ||
| In JetBrains Junie CLI before 26.6.29 sensitive environment variables were exposed in session event logs | ||||
| CVE-2026-121146 | 1 Tata Motors | 2 Tata Motors Ira.ev, Tata Motors Ira 2.0 | 2026-11-05 | N/A |
| This vulnerability exists in the iRA 2.0 and iRA.ev mobile applications due to the recording of authentication tokens in application logs used for development and debugging. A local attacker with an access to logs could exploit this vulnerability by retrieving and misusing the exposed session tokens. Successful exploitation of this vulnerability could allow the attacker to impersonate the associated user and gain unauthorized access to vehicle related information and services. | ||||
| CVE-2026-79656 | 1 Grafana | 2 Grafana, Grafana Enterprise | 2026-11-05 | 6 Medium |
| A user with read access to Grafana's server logs, or to a log store they are shipped to, can recover the OAuth and OIDC access, refresh and ID tokens of users who sign in through the Generic OAuth, Google or GitLab providers. Grafana writes these tokens to its logs unredacted when an access or ID token is not a valid JWT, when the ID token is missing (at debug level) or is not a string (exposure of sensitive information in log files). The exposure is bounded by the scopes granted to the configured OAuth client. | ||||
| CVE-2026-11820 | 1 Redhat | 2 Community.general, Enterprise Linux | 2026-11-05 | 6.5 Medium |
| A flaw was found in the community.general Ansible collection's nexmo module. The module constructs HTTP requests to the Vonage/Nexmo SMS API by encoding API credentials (api_key and api_secret) into URL query parameters and sending them via GET requests. This causes credentials to be exposed in web server access logs, proxy logs, HTTP Referer headers, and network monitoring tools, despite the Ansible argument specification marking these parameters as no_log. An attacker with access to any of these logging or monitoring points can obtain the full API credentials and gain unauthorized access to the victim's Vonage/Nexmo account. | ||||
| CVE-2026-11819 | 1 Redhat | 2 Community.general, Enterprise Linux | 2026-11-05 | 5.5 Medium |
| Module: plugins/modules/keyring_info.py CVSS 3.1: 5.5 MEDIUM — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Issue: The module retrieves a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) and places it directly into result["passphrase"] with no output suppression, no no_log protection, and no documentation warning. Root Cause: Line 105 (protected): keyring_password=dict(type="str", required=True, no_log=True) Line 127 (NOT protected): result["passphrase"] = passphrase Observed Output: { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } Visible via register + debug: { "keyring_result": { "changed": false, "passphrase": "MyMasterP@ssw0rd!SSH_Key_Secret" } } Impact: Master passwords, SSH key passphrases and service credentials appear in all Ansible output register: keyring_result followed by debug: var=keyring_result prints passphrase in full Ansible fact caching backends (Redis, JSON file, memcached) may persist the passphrase AWX/Tower job logs silently store the live credential Fix: module.exit_json(changed=False, passphrase=passphrase, _ansible_no_log=True) Also add a documentation warning requiring callers to use no_log: true at the task level. PoCs Fig 1: PoC execution showing passphrase in plaintext output Fig 2: Source code showing no_log=True on input (line 105) vs unprotected output (line 127) | ||||
| CVE-2026-109968 | 2 Red Hat, Redhat | 5 Enterprise Linux, Enterprise Linux, Openshift and 2 more | 2026-11-05 | 5.5 Medium |
| A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon logs LUKS disk encryption passphrases in plaintext to a log file. The log file is created without restrictive permissions, making it world-readable under the default process umask. A local attacker can read the log file to obtain the LUKS passphrase. | ||||