Common Weakness Enumeration

CWE-532

Allowed

Insertion of Sensitive Information into Log File

Abstraction: Base · Status: Incomplete

The product writes sensitive information to a log file.

1739 vulnerabilities reference this CWE, most recent first.

GHSA-7RCJ-2493-83X3

Vulnerability from github – Published: 2026-06-23 21:30 – Updated: 2026-07-15 15:32
VLAI
Details

A flaw was found in foreman-mcp-server. This component utilizes two distinct logging mechanisms that can expose sensitive session and authentication data. One mechanism logs session identifiers, which are treated as authentication credentials, at an informational level. The other, when debug logging is enabled, incompletely sanitizes HTTP request headers, leading to the cleartext logging of sensitive information such as authorization tokens and API keys. This vulnerability can result in a confidentiality breach, as sensitive authentication data is persisted in plain text within container logs, increasing the risk if logs are forwarded to a centralized platform.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-9073"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-23T21:17:03Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in foreman-mcp-server. This component utilizes two distinct logging mechanisms that can expose sensitive session and authentication data. One mechanism logs session identifiers, which are treated as authentication credentials, at an informational level. The other, when debug logging is enabled, incompletely sanitizes HTTP request headers, leading to the cleartext logging of sensitive information such as authorization tokens and API keys. This vulnerability can result in a confidentiality breach, as sensitive authentication data is persisted in plain text within container logs, increasing the risk if logs are forwarded to a centralized platform.",
  "id": "GHSA-7rcj-2493-83x3",
  "modified": "2026-07-15T15:32:43Z",
  "published": "2026-06-23T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9073"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:28405"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:28438"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-9073"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480151"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7RVG-GJGP-95J7

Vulnerability from github – Published: 2023-10-26 03:30 – Updated: 2023-11-03 15:33
VLAI
Details

An issue was discovered by Elastic whereby sensitive information is recorded in Kibana logs in the event of an error. The issue impacts only Kibana version 8.10.0 when logging in the JSON layout or when the pattern layout is configured to log the %meta pattern. Elastic has released Kibana 8.10.1 which resolves this issue. The error object recorded in the log contains request information, which can include sensitive data, such as authentication credentials, cookies, authorization headers, query params, request paths, and other metadata. Some examples of sensitive data which can be included in the logs are account credentials for kibana_system, kibana-metricbeat, or Kibana end-users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-31422"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-26T02:15:08Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered by Elastic whereby sensitive information is recorded in Kibana logs in the event of an error. The issue impacts only Kibana version 8.10.0 when logging in the JSON layout or when the pattern layout is configured to log the %meta pattern. Elastic has released Kibana 8.10.1 which resolves this issue. The error object recorded in the log contains request information, which can include sensitive data, such as authentication credentials, cookies, authorization headers, query params, request paths, and other metadata. Some examples of sensitive data which can be included in the logs are account credentials for kibana_system, kibana-metricbeat, or Kibana end-users.",
  "id": "GHSA-7rvg-gjgp-95j7",
  "modified": "2023-11-03T15:33:54Z",
  "published": "2023-10-26T03:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31422"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-8-10-1-security-update/343287"
    },
    {
      "type": "WEB",
      "url": "https://www.elastic.co/community/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7VVM-24CG-QMW6

Vulnerability from github – Published: 2022-05-13 01:21 – Updated: 2022-05-13 01:21
VLAI
Details

Under certain conditions SAP HANA Extended Application Services, version 1.0, advanced model (XS advanced) writes credentials of platform users to a trace file of the SAP HANA system. Even though this trace file is protected from unauthorized access, the risk of leaking information is increased.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-0266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-15T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "Under certain conditions SAP HANA Extended Application Services, version 1.0, advanced model (XS advanced) writes credentials of platform users to a trace file of the SAP HANA system. Even though this trace file is protected from unauthorized access, the risk of leaking information is increased.",
  "id": "GHSA-7vvm-24cg-qmw6",
  "modified": "2022-05-13T01:21:13Z",
  "published": "2022-05-13T01:21:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0266"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/2724713"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=510922943"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106988"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7W4X-4H67-PGMV

Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2025-05-09 16:32
VLAI
Summary
Invalid HTTP requests in Reactor Netty HTTP Server may reveal access tokens
Details

Reactor Netty HTTP Server, in versions 1.0.11 - 1.0.23, may request log headers in some cases of invalid HTTP requests. The logged headers may reveal valid access tokens to those with access to server logs. This may affect only invalid HTTP requests where logging at WARN level is enabled.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.projectreactor.netty:reactor-netty-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.11"
            },
            {
              "fixed": "1.0.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-20T18:40:50Z",
    "nvd_published_at": "2022-10-19T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Reactor Netty HTTP Server, in versions 1.0.11 - 1.0.23, may request log headers in some cases of invalid HTTP requests. The logged headers may reveal valid access tokens to those with access to server logs. This may affect only invalid HTTP requests where logging at WARN level is enabled.",
  "id": "GHSA-7w4x-4h67-pgmv",
  "modified": "2025-05-09T16:32:54Z",
  "published": "2022-10-20T12:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31684"
    },
    {
      "type": "PACKAGE",
      "url": "https://search.maven.org/artifact/io.projectreactor.netty/reactor-netty-http"
    },
    {
      "type": "WEB",
      "url": "https://tanzu.vmware.com/security/cve-2022-31684"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Invalid HTTP requests in Reactor Netty HTTP Server may reveal access tokens"
}

GHSA-7WXJ-7H8H-WM4H

Vulnerability from github – Published: 2024-05-02 12:30 – Updated: 2026-04-28 21:35
VLAI
Details

Insertion of Sensitive Information into Log File vulnerability in Jordy Meow WP Media Cleaner.This issue affects WP Media Cleaner: from n/a through 6.7.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-33922"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-02T11:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information into Log File vulnerability in Jordy Meow WP Media Cleaner.This issue affects WP Media Cleaner: from n/a through 6.7.2.",
  "id": "GHSA-7wxj-7h8h-wm4h",
  "modified": "2026-04-28T21:35:01Z",
  "published": "2024-05-02T12:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33922"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/media-cleaner/wordpress-wp-media-cleaner-plugin-6-7-2-sensitive-data-exposure-via-log-file-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7X6J-P2WP-QWWF

Vulnerability from github – Published: 2025-07-09 21:31 – Updated: 2025-07-09 21:31
VLAI
Details

Dell PowerFlex Manager VM, versions prior to 4.6.2.1, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the system with privileges of the compromised account.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-09T19:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Dell PowerFlex Manager VM, versions prior to 4.6.2.1, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the system with privileges of the compromised account.",
  "id": "GHSA-7x6j-p2wp-qwwf",
  "modified": "2025-07-09T21:31:17Z",
  "published": "2025-07-09T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36599"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000342158/dsa-2025-279-security-update-for-dell-powerflex-manager-platform-pfmp-proprietary-code-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7XGW-6QF3-7W59

Vulnerability from github – Published: 2026-05-14 18:24 – Updated: 2026-05-14 18:24
VLAI
Summary
dbt MCP Server Logs Tool Arguments Including SQL Queries and Credentials in Plaintext Without Redaction When File Logging Is Enabled
Details

Discovered through manual source code review. Verified by PoC execution against a local dbt-mcp v1.15.1 installation.

Summary

DbtMCP.call_tool() in src/dbt_mcp/mcp/server.py logs the complete raw arguments dictionary at INFO level on every tool invocation (line 67) and again at ERROR level if the call raises an exception (lines 77–79). No field is redacted before logging. When the documented DBT_MCP_SERVER_FILE_LOGGING=true feature is enabled, these log records are written to dbt-mcp.log in the project root directory as plaintext. Sensitive data — raw SQL queries, --vars payloads carrying credentials, node selectors — persists on disk indefinitely with no automatic rotation or deletion.

Details

Vulnerable log statements (server.py):

# Line 67 — emitted before every tool execution
logger.info(f"Calling tool: {name} with arguments: {arguments}")

# Lines 77–79 — emitted if the tool raises an exception (double-logging on failure)
logger.error(
    f"Error calling tool: {name} with arguments: {arguments} "
    f"in {end_time - start_time}ms: {e}"
)

arguments is the raw Python dict received from the MCP client. It is string-interpolated directly into the log message. On a tool call that raises an exception, the same dict is logged twice — once at INFO and once at ERROR.

File logging is activated by DBT_MCP_SERVER_FILE_LOGGING=true (a documented feature in the project README). The log file location is resolved by configure_file_logging(), which walks up the directory tree from __file__ looking for .git or pyproject.toml, falling back to $HOME. Arguments are also emitted to stderr by the default stream handler regardless of file logging state.

PoC

MCP client script — triggers real tool calls and verifies log file contents:

#!/usr/bin/env python3
# poc4_tool_args_logged.py
# Vulnerable code: src/dbt_mcp/mcp/server.py line 67, 77-79
# configure_file_logging(): src/dbt_mcp/telemetry/logging.py

import logging
from pathlib import Path

LOG_FILENAME = "dbt-mcp.log"

def configure_file_logging(log_level: int = logging.INFO) -> Path:
    """Reproduction of configure_file_logging() from telemetry/logging.py."""
    module_path = Path(__file__).resolve().parent
    home = Path.home().resolve()
    for candidate in [module_path, *module_path.parents]:
        if (candidate / ".git").exists() or (candidate / "pyproject.toml").exists() or candidate == home:
            repo_root = candidate
            break
    log_path = repo_root / LOG_FILENAME
    root_logger = logging.getLogger()
    root_logger.setLevel(log_level)
    file_handler = logging.FileHandler(log_path, encoding="utf-8")
    file_handler.setLevel(log_level)
    file_handler.setFormatter(
        logging.Formatter("%(asctime)s %(levelname)s [%(name)s] %(message)s")
    )
    root_logger.addHandler(file_handler)
    return log_path

log_path = configure_file_logging()
server_logger = logging.getLogger("dbt_mcp.mcp.server")

# Exact log statements from server.py line 67 and line 77-79
name = "show"
arguments = {"sql_query": "SELECT ssn, credit_card_number, salary FROM customers WHERE id = 42", "limit": 5}
server_logger.info(f"Calling tool: {name} with arguments: {arguments}")

name2 = "run"
arguments2 = {"node_selection": "sensitive_model", "vars": '{"db_password": "hunter2", "api_key": "sk-prod-abc123xyz"}', "is_full_refresh": False}
server_logger.info(f"Calling tool: {name2} with arguments: {arguments2}")

# Verify file contents
lines = log_path.read_text(encoding="utf-8").splitlines()
poc_lines = [l for l in lines if "dbt_mcp.mcp.server" in l]
print(f"[log file: {log_path}]")
for line in poc_lines:
    print(f"  {line}")

keywords = ["ssn", "credit_card_number", "salary", "db_password", "api_key"]
found = [kw for kw in keywords if any(kw in l for l in poc_lines)]
if found:
    print(f"\n[CONFIRMED] Sensitive keywords in plaintext log: {found}")
    print(f"[CONFIRMED] No redaction applied. File persists at {log_path}")

Expected log file entries:

2026-04-27 ... INFO [dbt_mcp.mcp.server] Calling tool: show with arguments:
  {'sql_query': 'SELECT ssn, credit_card_number, salary FROM customers', 'limit': 5}

2026-04-27 ... INFO [dbt_mcp.mcp.server] Calling tool: run with arguments:
  {'node_selection': 'sensitive_model',
   'vars': '{"db_password":"hunter2","api_key":"sk-prod-abc123"}',
   'is_full_refresh': False}

[CONFIRMED] Sensitive keywords in plaintext log: ['ssn', 'credit_card_number', 'salary', 'db_password', 'api_key']
[CONFIRMED] No redaction applied.

image

Impact

Directly proven by this PoC:

  • When DBT_MCP_SERVER_FILE_LOGGING=true, the full arguments dict of every tool call — including sql_query, vars, and node_selection — is written to dbt-mcp.log in plaintext on every invocation.
  • A tool call that raises an exception produces two log entries with the same sensitive content (INFO + ERROR double-logging).
  • The log file has no automatic rotation, expiry, or access restriction beyond filesystem permissions.

Combined with Advisory 3 (telemetry), a single show tool call containing PII produces one telemetry transmission to dbt Labs and one (or two, on failure) persistent log entries on disk.

Remediation

redact known-sensitive argument values before logging:

_LOG_REDACT = frozenset({"sql_query", "vars"})

def _safe_args(arguments: dict) -> dict:
    return {k: "***redacted***" if k in _LOG_REDACT else v
            for k, v in arguments.items()}

# server.py line 67:
logger.info(f"Calling tool: {name} with arguments: {_safe_args(arguments)}")

# server.py lines 77-79:
logger.error(
    f"Error calling tool: {name} with arguments: {_safe_args(arguments)} "
    f"in {end_time - start_time}ms: {e}"
)

log argument keys only:

logger.info(f"Calling tool: {name} with argument keys: {list(arguments.keys())}")

File logging: Consider reducing the default log level for the file handler to WARNING so that normal-operation INFO records (which include arguments) are not persisted. Sensitive content would only appear in file logs on error.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "dbt-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44969"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T18:24:44Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "*Discovered through manual source code review. Verified by PoC execution against a local dbt-mcp v1.15.1 installation.*\n\n### Summary\n\n`DbtMCP.call_tool()` in `src/dbt_mcp/mcp/server.py` logs the complete raw `arguments` dictionary at `INFO` level on every tool invocation (line 67) and again at `ERROR` level if the call raises an exception (lines 77\u201379). No field is redacted before logging. When the documented `DBT_MCP_SERVER_FILE_LOGGING=true` feature is enabled, these log records are written to `dbt-mcp.log` in the project root directory as plaintext. Sensitive data \u2014 raw SQL queries, `--vars` payloads carrying credentials, node selectors \u2014 persists on disk indefinitely with no automatic rotation or deletion.\n\n### Details\n\n**Vulnerable log statements (`server.py`):**\n\n```python\n# Line 67 \u2014 emitted before every tool execution\nlogger.info(f\"Calling tool: {name} with arguments: {arguments}\")\n\n# Lines 77\u201379 \u2014 emitted if the tool raises an exception (double-logging on failure)\nlogger.error(\n    f\"Error calling tool: {name} with arguments: {arguments} \"\n    f\"in {end_time - start_time}ms: {e}\"\n)\n```\n\n`arguments` is the raw Python dict received from the MCP client. It is string-interpolated directly into the log message. On a tool call that raises an exception, the same dict is logged twice \u2014 once at INFO and once at ERROR.\n\nFile logging is activated by `DBT_MCP_SERVER_FILE_LOGGING=true` (a documented feature in the project README). The log file location is resolved by `configure_file_logging()`, which walks up the directory tree from `__file__` looking for `.git` or `pyproject.toml`, falling back to `$HOME`. Arguments are also emitted to stderr by the default stream handler regardless of file logging state.\n\n### PoC\n\n**MCP client script \u2014 triggers real tool calls and verifies log file contents:**\n\n```python\n#!/usr/bin/env python3\n# poc4_tool_args_logged.py\n# Vulnerable code: src/dbt_mcp/mcp/server.py line 67, 77-79\n# configure_file_logging(): src/dbt_mcp/telemetry/logging.py\n\nimport logging\nfrom pathlib import Path\n\nLOG_FILENAME = \"dbt-mcp.log\"\n\ndef configure_file_logging(log_level: int = logging.INFO) -\u003e Path:\n    \"\"\"Reproduction of configure_file_logging() from telemetry/logging.py.\"\"\"\n    module_path = Path(__file__).resolve().parent\n    home = Path.home().resolve()\n    for candidate in [module_path, *module_path.parents]:\n        if (candidate / \".git\").exists() or (candidate / \"pyproject.toml\").exists() or candidate == home:\n            repo_root = candidate\n            break\n    log_path = repo_root / LOG_FILENAME\n    root_logger = logging.getLogger()\n    root_logger.setLevel(log_level)\n    file_handler = logging.FileHandler(log_path, encoding=\"utf-8\")\n    file_handler.setLevel(log_level)\n    file_handler.setFormatter(\n        logging.Formatter(\"%(asctime)s %(levelname)s [%(name)s] %(message)s\")\n    )\n    root_logger.addHandler(file_handler)\n    return log_path\n\nlog_path = configure_file_logging()\nserver_logger = logging.getLogger(\"dbt_mcp.mcp.server\")\n\n# Exact log statements from server.py line 67 and line 77-79\nname = \"show\"\narguments = {\"sql_query\": \"SELECT ssn, credit_card_number, salary FROM customers WHERE id = 42\", \"limit\": 5}\nserver_logger.info(f\"Calling tool: {name} with arguments: {arguments}\")\n\nname2 = \"run\"\narguments2 = {\"node_selection\": \"sensitive_model\", \"vars\": \u0027{\"db_password\": \"hunter2\", \"api_key\": \"sk-prod-abc123xyz\"}\u0027, \"is_full_refresh\": False}\nserver_logger.info(f\"Calling tool: {name2} with arguments: {arguments2}\")\n\n# Verify file contents\nlines = log_path.read_text(encoding=\"utf-8\").splitlines()\npoc_lines = [l for l in lines if \"dbt_mcp.mcp.server\" in l]\nprint(f\"[log file: {log_path}]\")\nfor line in poc_lines:\n    print(f\"  {line}\")\n\nkeywords = [\"ssn\", \"credit_card_number\", \"salary\", \"db_password\", \"api_key\"]\nfound = [kw for kw in keywords if any(kw in l for l in poc_lines)]\nif found:\n    print(f\"\\n[CONFIRMED] Sensitive keywords in plaintext log: {found}\")\n    print(f\"[CONFIRMED] No redaction applied. File persists at {log_path}\")\n```\n\n**Expected log file entries:**\n\n````\n2026-04-27 ... INFO [dbt_mcp.mcp.server] Calling tool: show with arguments:\n  {\u0027sql_query\u0027: \u0027SELECT ssn, credit_card_number, salary FROM customers\u0027, \u0027limit\u0027: 5}\n\n2026-04-27 ... INFO [dbt_mcp.mcp.server] Calling tool: run with arguments:\n  {\u0027node_selection\u0027: \u0027sensitive_model\u0027,\n   \u0027vars\u0027: \u0027{\"db_password\":\"hunter2\",\"api_key\":\"sk-prod-abc123\"}\u0027,\n   \u0027is_full_refresh\u0027: False}\n\n[CONFIRMED] Sensitive keywords in plaintext log: [\u0027ssn\u0027, \u0027credit_card_number\u0027, \u0027salary\u0027, \u0027db_password\u0027, \u0027api_key\u0027]\n[CONFIRMED] No redaction applied.\n````\n\n\u003cimg width=\"3798\" height=\"462\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b4c23a93-b3d3-4b7f-ba46-3d4a324d609f\" /\u003e\n\n### Impact\n\n**Directly proven by this PoC:**\n\n- When `DBT_MCP_SERVER_FILE_LOGGING=true`, the full `arguments` dict of every tool call \u2014 including `sql_query`, `vars`, and `node_selection` \u2014 is written to `dbt-mcp.log` in plaintext on every invocation.\n- A tool call that raises an exception produces **two** log entries with the same sensitive content (INFO + ERROR double-logging).\n- The log file has no automatic rotation, expiry, or access restriction beyond filesystem permissions.\n\nCombined with Advisory 3 (telemetry), a single `show` tool call containing PII produces one telemetry transmission to dbt Labs **and** one (or two, on failure) persistent log entries on disk.\n\n### Remediation\n\n**redact known-sensitive argument values before logging:**\n\n```python\n_LOG_REDACT = frozenset({\"sql_query\", \"vars\"})\n\ndef _safe_args(arguments: dict) -\u003e dict:\n    return {k: \"***redacted***\" if k in _LOG_REDACT else v\n            for k, v in arguments.items()}\n\n# server.py line 67:\nlogger.info(f\"Calling tool: {name} with arguments: {_safe_args(arguments)}\")\n\n# server.py lines 77-79:\nlogger.error(\n    f\"Error calling tool: {name} with arguments: {_safe_args(arguments)} \"\n    f\"in {end_time - start_time}ms: {e}\"\n)\n```\n\n**log argument keys only:**\n\n```python\nlogger.info(f\"Calling tool: {name} with argument keys: {list(arguments.keys())}\")\n```\n\n**File logging:** Consider reducing the default log level for the file handler to `WARNING` so that normal-operation INFO records (which include arguments) are not persisted. Sensitive content would only appear in file logs on error.",
  "id": "GHSA-7xgw-6qf3-7w59",
  "modified": "2026-05-14T18:24:44Z",
  "published": "2026-05-14T18:24:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-mcp/security/advisories/GHSA-7xgw-6qf3-7w59"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dbt-labs/dbt-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-mcp/releases/tag/v1.17.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "dbt MCP Server Logs Tool Arguments Including SQL Queries and Credentials in Plaintext Without Redaction When File Logging Is Enabled"
}

GHSA-8234-4CCX-5XMR

Vulnerability from github – Published: 2025-07-23 00:30 – Updated: 2025-10-02 18:30
VLAI
Details

A potential security vulnerability has been identified in the Poly Clariti Manager for versions prior to 10.12.2. The vulnerability could potentially allow a privileged user to retrieve credentials from the log files. HP has addressed the issue in the latest software update.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-43485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-23T00:15:25Z",
    "severity": "MODERATE"
  },
  "details": "A potential security\nvulnerability has been identified in the Poly Clariti Manager for versions\nprior to 10.12.2. The vulnerability could potentially allow a privileged\nuser to retrieve credentials from the log files. HP has addressed the issue in\nthe latest software update.",
  "id": "GHSA-8234-4ccx-5xmr",
  "modified": "2025-10-02T18:30:56Z",
  "published": "2025-07-23T00:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43485"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_12781425-12781447-16/hbsbpy04037"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-824R-MJCW-Q34M

Vulnerability from github – Published: 2025-10-07 09:30 – Updated: 2026-04-08 18:33
VLAI
Details

The WP Reset plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.05 via the WF_Licensing::log() method when debugging is enabled (default). This makes it possible for unauthenticated attackers to extract sensitive license key and site data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-10645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-07T09:15:32Z",
    "severity": "MODERATE"
  },
  "details": "The WP Reset plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.05 via the WF_Licensing::log() method when debugging is enabled (default). This makes it possible for unauthenticated attackers to extract sensitive license key and site data.",
  "id": "GHSA-824r-mjcw-q34m",
  "modified": "2026-04-08T18:33:56Z",
  "published": "2025-10-07T09:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10645"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3364169"
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2025-10645"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/86741f4a-8700-45dd-8998-b3f0387c27ed?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-829V-PH86-CW55

Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33
VLAI
Details

Cloud Foundry Log Cache, versions prior to 1.1.1, logs its UAA client secret on startup as part of its envstruct report. A remote attacker who has gained access to the Log Cache VM can read this secret, gaining all privileges held by the Log Cache UAA client. In the worst case, if this client is an admin, the attacker would gain complete control over the Foundation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-1264"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-05T21:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Cloud Foundry Log Cache, versions prior to 1.1.1, logs its UAA client secret on startup as part of its envstruct report. A remote attacker who has gained access to the Log Cache VM can read this secret, gaining all privileges held by the Log Cache UAA client. In the worst case, if this client is an admin, the attacker would gain complete control over the Foundation.",
  "id": "GHSA-829v-ph86-cw55",
  "modified": "2022-05-13T01:33:25Z",
  "published": "2022-05-13T01:33:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1264"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2018-1264"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design Implementation

Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.

Mitigation
Distribution

Remove debug log files before deploying the application into production.

Mitigation
Operation

Protect log files against unauthorized read/write.

Mitigation
Implementation

Adjust configurations appropriately when software is transitioned from a debug state to production.

CAPEC-215: Fuzzing for application mapping

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.