CVE-2026-106035 is an information exposure vulnerability in Ivanti Xtraction Cloud Sync before version 2026.4. It allows a remote authenticated attacker with low privileges to disclose partial SQL database passwords through application log files. The vulnerability does not impact integrity or availability but has a high confidentiality impact. No patch information is provided, and no known exploits are reported in the wild.
Progress Software Corporation's MarkLogic Server versions 11.x before 11.3.7 and 12.x before 12.1.0, when deployed on Azure, may log sensitive authentication information in diagnostic logs under certain configurations. This vulnerability could allow an attacker with access to these logs to gain unauthorized access to protected cloud resources. A patch is available to address this issue.
Progress Software Corporation's MarkLogic Server versions 11.0.0 up to but not including 11.3.7, and 12.0.0 up to but not including 12.1.0, may log sensitive security information in diagnostic logs under certain configurations. This could allow an attacker with access to these logs to gain unauthorized access to protected resources. The vulnerability is identified as CWE-532, involving insertion of sensitive information into log files. It has a high severity with a CVSS score of 8.1.
Insertion of sensitive information into log file in AWS Tools for PowerShell before 5.0.306 might allow local users to recover an IAM user's cleartext AWS Management Console password from command output and log artifacts.
To remediate this issue, users should upgrade to version 5.0.306 or later. After upgrading, review PowerShell transcripts and log stores for previously disclosed passwords and rotate any affected IAM console passwords.
IBM Guardium Data Protection 12.0, 12.1, and 12.2 could allow a local attacker to obtain sensitive information due to cleartext storage of sensitive information in logs.
### Summary
Pydantic AI's OpenTelemetry instrumentation supports `InstrumentationSettings(include_content=False)` to exclude message content — user prompts, model completions, tool call arguments and responses — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.
Retry prompts — the feedback messages Pydantic AI sends back to the model when its output fails validation or an output validator raises `ModelRetry` — were not covered by this setting when they were not associated with a tool call, as with structured output modes that don't use tool calls (e.g. `NativeOutput` or `PromptedOutput`) and output validators applied to text output. Their full content was recorded on model request spans even with `include_content=False`. Since validation feedback can quote invalid values from the model's response, message content that the setting was configured to withhold could reach the telemetry backend.
### Details
Retry prompts without an associated tool call were serialized into span message attributes (such as `gen_ai.input.messages` and `pydantic_ai.all_messages`) as regular text parts, and this path did not apply the `include_content` check that every other message part applies. Retry prompts tied to a tool call, and all other message content, were redacted correctly.
### Impact
This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario `include_content=False` exists for. The disclosed content is limited to retry feedback: validation error details, which can quote invalid values from the model's output, or output-validator `ModelRetry` messages.
### Who Is Affected
You are affected if you enabled instrumentation with `include_content=False` and your agent can produce retry prompts outside of tool calls: it uses a structured output mode that doesn't rely on tool calls (such as `NativeOutput` or `PromptedOutput`), or output validators on text output. You are not affected if you don't set `include_content=False`, or if all of your agent's retries come from tool calls (including the default tool-based structured output mode), which were redacted correctly.
### Remediation
Upgrade to a patched version; retry prompt content now honors `include_content=False` like all other message content. If you rely on this setting, consider reviewing previously exported traces for retry prompt content that should not have been recorded.
### Workaround for Unpatched Versions
If you cannot upgrade, scrub or drop the message attributes (`gen_ai.input.messages`, `gen_ai.output.messages`, `pydantic_ai.all_messages`) in your telemetry pipeline (for example with an OpenTelemetry Collector processor), or use tool-based structured output modes, whose retry feedback honors `include_content=False`.
### Credits
Reported privately by the University of Sydney Security Research Team (Liyi Zhou, Ziyue Wang, Strick, Maurice, Chenchen Yu), and later independently discovered and reported publicly, with a fix, by @sean-kim05.
Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. From 0.3.4 until 1.107.6 and 2.44.0, OpenTelemetry instrumentation configured with InstrumentationSettings(include_content=False) can still export sensitive agent content through exception.message and exception.stacktrace events, error status descriptions, and model_request_parameters containing instructions or the prompted_output_template. The exposed data is available to readers of the configured telemetry backend and can include tool feedback, provider error bodies, runtime instructions, and structured-output templates even though message attributes are redacted. This issue does not grant new access to agent data, and deployments that do not use include_content=False are not affected by the setting bypass. This issue is fixed in versions 1.107.6 and 2.44.0.
An information disclosure vulnerability exists in the SupportLink diagnostic collection utilities of Brocade Fabric OS versions before 10.0.1. When SupportLink is configured to use an authenticated HTTP proxy, the system stores the full proxy URL. Anyone with access to the diagnostic support bundle, such as support personnel or users with access to file shares where support bundles are stored, can extract these cleartext proxy credentials.
CVE-2026-16528 is a vulnerability in certain ASUS router models where sensitive information, specifically DDNS credentials, is inserted into system log files. This flaw allows a remote authenticated attacker to access these credentials from the logs, which could potentially enable unauthorized modification of DNS settings. The vulnerability has a high severity score of 8.4. No specific affected versions or patch information is provided in the available data.
Dell Container Storage Modules, versions prior to 1.18.0, contain(s) an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure.
Dell Container Storage Modules, versions prior to 1.18.0, contain(s) an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure.
Armatura One versions prior to 4.7.2 and 4.6.1 have a vulnerability where the backup and restore routine logs the full database connection command, including the superuser password, in plain text on the host. This exposure allows anyone with access to the server operating system to obtain credentials and potentially access the database.
Armatura One's message broker logs client connection credentials, including passwords, in plain text during normal operation. This allows any party with read access to these logs or related backups to obtain sensitive credential information. The vulnerability is identified as CWE-532 and affects versions prior to 4.6.1 and 4.7.2. The CVSS score is 4.0, indicating a medium severity issue with low impact on confidentiality and no impact on integrity or availability.
The postgresql-operator charm runs a Prometheus postgres_exporter to collect database metrics using a dedicated "monitoring" PostgreSQL user. On database connection errors, the exporter writes the monitoring user's password in cleartext to its logs. Any actor able to read those logs can recover the password, which grants read-only pg_monitor access to PostgreSQL. This is fixed in the dev track (14/edge) in revisions 1189 (arm64) and 1190 (amd64), and in the stable track (14/stable) in revisions 1216 (arm64) and 1217 (amd64).
OpenTelemetry JavaScript Contrib instrumentation libraries prior to specified versions include the database connection username in telemetry data as the db.user span attribute by default. This sensitive information is logged and sent to observability backends without requiring opt-in, potentially exposing service topology, roles, environment details, and account naming patterns. The issue is addressed in versions 0.66.0, 0.65.0, 0.67.0, 0.46.0, 0.73.0, and 0.40.0 of the respective packages.
Insertion of sensitive information into log file vulnerability in Apache APISIX.
This vulnerability can cause the unmasked header value to be written to the log sink under a certain response structure.
This issue affects Apache APISIX: 3.17.0.
Users are recommended to upgrade to version 3.18.0, which fixes the issue.
Apache Airflow's Teradata provider versions before 3.7.0 embed cloud storage credentials directly into SQL statements, which are then logged in Airflow task logs and Teradata's query logs. This exposure occurs when using the S3ToTeradataOperator or AzureBlobStorageToTeradataOperator against private buckets without a configured Teradata authorization object. The credentials appear in plaintext in Airflow logs and Teradata's DBQL query logs, posing a risk of credential leakage. Upgrading to version 3.7.0 or later prevents credentials from appearing in Airflow logs but does not remove them from Teradata's logs. Users should configure a Teradata authorization object and rotate exposed credentials.
Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets — normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner — to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected.
Incomplete property masking in the SANnav logging subsystem permits SNMP authentication and privacy passwords to be recorded in application logs under specific configuration conditions. Individuals with read access to system logs or support bundles can retrieve these credentials, leading to unauthorized read or management access to monitored switch environments
An information exposure vulnerability in the job scheduling component of SANnav allows sensitive credentials to be written to application logs in plain text. When scheduled support save jobs or related operational tasks are executed, sensitive parameters including external server passwords and archive protection keys are logged without proper masking. A local or authenticated user with access to application logs or support bundles can view these cleartext credentials, potentially leading to unauthorized access to remote backup targets or protected archives.