CVE-2026-25193
Insertion of Sensitive Information into Log File (CWE-532) in some Command Centre Service installers could lead to Service Account credentia
CVSS
8.1
High
EPSS
0.1%
p3
KEV
—
Exploit Today
1
0-100
Published: May 25, 2026 · Last modified: Aug 17, 2026 · CWE-532
0.1%EPSS · 30 days0.1%
2026-09-282026-10-26
Insertion of Sensitive Information into Log File (CWE-532) in some Command Centre Service installers could lead to Service Account credentials exposure. Mitigating Factor: Only sites that install Command Centre Services with a custom Service Account (not the default Network Service account) are potentially impacted. Mitigation: For sites concerned about exposure, the recommended action is to change the Service Account password. They can also delete any installer log files, usually found in %programdata%\Gallagher\Command Centre.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-117341——
——0In affected versions of Octopus Server, creating a user invitation writes the invitation code to the audit event log. When the invitation is linked to a space, a user in that space with appropriate permissions could read the code from the audit event. Successfully exploiting this by redeeming the unclaimed invitation could allow the user to escalate privileges however this is dependant on the permissions assigned for the invited user.6hCVE-2026-1168146.5 MED—
——0OpenPanel before 3.0.0 contains an information exposure vulnerability that writes database connection URLs and email template data to standard output logs. Users with log access can obtain database credentials from migration startup logs and password-reset tokens logged when SMTP_HOST and RESEND_API_KEY are unset.17hCVE-2026-1122504.4 MED7.4%
——2A vulnerability has been identified in
BRAIN2 versions up to and including version 3.09. Under specific installation
conditions, the password of a Windows service account may be written in
cleartext to a setup log file. The issue occurs when Microsoft SQL Server
access is configured using Integrated Security and the Windows account intended
to run the BRAIN2 MainService is specified during execution of the BRAIN2
installation wizard. The setup log file is stored in the
temporary directory of the Windows administrator performing the installation.
This directory is not accessible to standard Windows users and can generally
only be accessed by users with administrative privileges. Successful exploitation could result in the
disclosure of credentials belonging to the configured BRAIN2 service account.1dCVE-2026-115885—1.4%
——0The LangGraph CLI is the official command-line interface for LangGraph. From 0.4.15 until 0.4.32, langgraph deploy --verbose passes a temporary registry push token on standard input to docker login --password-stdin, but the CLI subprocess helper prints command input in verbose mode. Anyone who can read resulting CI logs or terminal recordings before the token's maximum 12-hour expiration can pull deployment images or push images to that deployment's image repository. Deployments without --verbose and remote image builds are not affected, and the token alone cannot update a deployment to execute a pushed image. This issue is fixed in version 0.4.32.23hCVE-2026-54711—4.7%
——1pghoard is a PostgreSQL backup daemon and restore tooling that stores backup data in cloud object stores. Prior to version 2.7.1, when using .pgpass, database connection information including the username and password will be logged at the debug level. This issue has been patched in version 2.7.1.4dCVE-2026-105963—43.2%
——13Externally-Generated Error Message Containing Sensitive Information vulnerability in plug_crypto in elixir-plug plug_crypto allows an unauthenticated remote attacker to expose the secret key base through application logs via a wrong-typed argument. Every public function in Plug.Crypto validates argument types in a function-head guard. A failed guard makes the Erlang VM raise FunctionClauseError with the actual argument values in the top stack frame, so the secret key base, a derived key, or the value an API key is compared against lands in that frame. The library's rescue blocks and Plug.Crypto.prune_args_from_stacktrace/1 only reach exceptions raised inside a function body, so they never see a guard failure. Plug.Cowboy and Bandit write the frame to the error log and attach it as crash_reason Logger metadata, which error trackers forward.
Two entry points take request data. Plug.Crypto.verify/4 exposes the secret key base when the token is neither a binary nor nil, which Phoenix.Token.verify/4 reaches because it forwards the token unguarded. Plug.Crypto.secure_compare/2 exposes the other operand when one side is not a binary, as happens when a missing request header yields nil. Reading the leaked value needs separate access to the logs or the error tracker, so the request alone does not disclose the secret to the attacker.
This issue affects plug: from 1.6.3 before 1.7.0; plug_crypto: from 1.0.0 before 2.2.1.4d