Common Weakness Enumeration

CWE-209

Allowed

Generation of Error Message Containing Sensitive Information

Abstraction: Base · Status: Draft

The product generates an error message that includes sensitive information about its environment, users, or associated data.

900 vulnerabilities reference this CWE, most recent first.

GHSA-H8P7-486M-M9H4

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-05-24 17:38
VLAI
Details

IBM Security Guardium Insights 2.0.2 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 184832.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-13T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Guardium Insights 2.0.2 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 184832.",
  "id": "GHSA-h8p7-486m-m9h4",
  "modified": "2022-05-24T17:38:59Z",
  "published": "2022-05-24T17:38:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4600"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/184832"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6403463"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H9G3-2G32-4PQC

Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-22 15:31
VLAI
Details

In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload client-state processing can distinguish decrypt failures from invalid-JSON parse failures, creating an oracle that reveals protected metadata values to remote attackers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-13182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T14:17:13Z",
    "severity": "HIGH"
  },
  "details": "In Progress\u00ae Telerik\u00ae UI for AJAX prior to v2026.2.708, RadAsyncUpload client-state processing can distinguish decrypt failures from invalid-JSON parse failures, creating an oracle that reveals protected metadata values to remote attackers.",
  "id": "GHSA-h9g3-2g32-4pqc",
  "modified": "2026-07-22T15:31:22Z",
  "published": "2026-07-22T15:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13182"
    },
    {
      "type": "WEB",
      "url": "https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-rau-padding-oracle-cve-2026-13182"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H9QF-RFGJ-F3P7

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-05-24 17:38
VLAI
Details

IBM Sterling B2B Integrator Standard Edition 5.2.0.0 through 5.2.6.5_2, 6.0.0.0 through 6.0.3.2, and 6.1.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 188895.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4761"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-05T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling B2B Integrator Standard Edition 5.2.0.0 through 5.2.6.5_2, 6.0.0.0 through 6.0.3.2, and 6.1.0.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 188895.",
  "id": "GHSA-h9qf-rfgj-f3p7",
  "modified": "2022-05-24T17:38:02Z",
  "published": "2022-05-24T17:38:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4761"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/188895"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6396146"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HGJJ-FR5H-J9MV

Vulnerability from github – Published: 2022-05-24 16:48 – Updated: 2024-04-04 01:01
VLAI
Details

Pydio Cells before 1.5.0, when supplied with a Name field in an unexpected Unicode format, fails to handle this and includes the database column/table name as pert of the error message, exposing sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-12903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-20T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Pydio Cells before 1.5.0, when supplied with a Name field in an unexpected Unicode format, fails to handle this and includes the database column/table name as pert of the error message, exposing sensitive information.",
  "id": "GHSA-hgjj-fr5h-j9mv",
  "modified": "2024-04-04T01:01:44Z",
  "published": "2022-05-24T16:48:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12903"
    },
    {
      "type": "WEB",
      "url": "https://pydio.com/en/community/releases/pydio-cells/pydio-cells-150-performances-features-security"
    },
    {
      "type": "WEB",
      "url": "https://research.loginsoft.com/vulnerability/multiple-vulnerabilities-in-pydio-cells-1-4-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HHRJ-WP42-32V3

Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-02-28 22:18
VLAI
Summary
Generation of Error Message Containing Sensitive Information in microweber
Details

Generation of Error Message Containing Sensitive Information in Packagist microweber/microweber prior to 1.2.11.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "microweber/microweber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-23T15:37:01Z",
    "nvd_published_at": "2022-02-18T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "Generation of Error Message Containing Sensitive Information in Packagist microweber/microweber prior to 1.2.11.",
  "id": "GHSA-hhrj-wp42-32v3",
  "modified": "2022-02-28T22:18:00Z",
  "published": "2022-02-19T00:01:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0660"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microweber/microweber/commit/2417bd2eda2aa2868c1dad1abf62341f22bfc20a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/microweber/microweber"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/01fd2e0d-b8cf-487f-a16c-7b088ef3a291"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Generation of Error Message Containing Sensitive Information in microweber"
}

GHSA-HJ5W-45WX-H9RG

Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-05-24 19:13
VLAI
Details

The public share controller in the ownCloud server before version 10.8.0 allows a remote attacker to see the internal path and the username of a public share by including invalid characters in the URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-07T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The public share controller in the ownCloud server before version 10.8.0 allows a remote attacker to see the internal path and the username of a public share by including invalid characters in the URL.",
  "id": "GHSA-hj5w-45wx-h9rg",
  "modified": "2022-05-24T19:13:08Z",
  "published": "2022-05-24T19:13:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35947"
    },
    {
      "type": "WEB",
      "url": "https://doc.owncloud.com/server/admin_manual/release_notes.html"
    },
    {
      "type": "WEB",
      "url": "https://owncloud.com/security-advisories/cve-2021-35947"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HJG2-F45W-C566

Vulnerability from github – Published: 2026-07-06 09:30 – Updated: 2026-08-28 20:08
VLAI
Summary
Apache Camel-Undertow: The muteException consumer option defaulted to false, so a processing error returned the full Java stack trace in the HTTP response body
Details

Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component.

The camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application's internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.

Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true, or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.camel:camel-undertow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.14.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.camel:camel-undertow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.15.0"
            },
            {
              "fixed": "4.18.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.camel:camel-undertow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.19.0"
            },
            {
              "fixed": "4.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T20:08:04Z",
    "nvd_published_at": "2026-07-06T09:16:39Z",
    "severity": "MODERATE"
  },
  "details": "Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Undertow Component.\n\nThe camel-undertow HTTP server consumer exposes a muteException option that controls what is returned to the client when a route processing error occurs. This option defaulted to false, whereas the other Camel HTTP server components (camel-http / camel-jetty / camel-servlet and camel-platform-http) default it to true. With muteException=false, when a request triggers an exception during route processing the consumer writes the full Throwable stack trace into the HTTP response body as text/plain instead of returning an empty body. Any unauthenticated client that can reach the endpoint and cause a processing error - for example by sending a malformed request body, an invalid parameter, or otherwise triggering a route-internal failure - therefore receives a complete Java stack trace. Such a stack trace can disclose sensitive internal information, including credentials embedded in exception messages, internal host names and IP addresses, filesystem paths, dependency and version details, database and class names, and the application\u0027s internal structure, which an attacker can use to plan further attacks. In addition, for Rest DSL consumers the muteException option was not honoured at all: the RestUndertowHttpBinding was created with a hard-coded false, so the stack trace was returned even when muteException=true had been configured.\nThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, set muteException=true explicitly on the camel-undertow consumer (for example undertow: http://0.0.0.0:8080/api?muteException=true, or globally via the camel.component.undertow.mute-exception=true property), so that processing errors no longer return the stack trace to the client; note that on affected releases this workaround does not cover Rest DSL consumers, whose binding ignores the option until the fix is applied.",
  "id": "GHSA-hjg2-f45w-c566",
  "modified": "2026-08-28T20:08:04Z",
  "published": "2026-07-06T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56139"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/pull/23913"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/pull/23923"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/pull/23990"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/commit/6cea553aa42ed1326ac57ad800d66674bc453932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/commit/b1badb58a407e4d16c8b6bba81650d4c68e55eaf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/commit/fdcf67a00470783ccb93b948883b6a4c5275aff5"
    },
    {
      "type": "WEB",
      "url": "https://camel.apache.org/security/CVE-2026-56139.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/camel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/releases/tag/camel-4.14.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/releases/tag/camel-4.18.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/camel/releases/tag/camel-4.21.0"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/CAMEL-23651"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/05/29"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Camel-Undertow: The muteException consumer option defaulted to false, so a processing error returned the full Java stack trace in the HTTP response body"
}

GHSA-HJG4-8Q5F-X6FM

Vulnerability from github – Published: 2021-05-05 19:49 – Updated: 2023-07-05 20:17
VLAI
Summary
Action Pack contains Information Disclosure / Unintended Method Execution vulnerability
Details

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this.

redirect_to(params[:some_param])

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The FIXED releases are available at the normal locations.

Workarounds

To work around this problem, it is recommended to use an allow list for valid parameters passed from the user. For example,

private def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this,

def index
  redirect_to(params[:some_param].to_s)
end

Patches

To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

  • 5-2-information-disclosure.patch - Patch for 5.2 series
  • 6-0-information-disclosure.patch - Patch for 6.0 series
  • 6-1-information-disclosure.patch - Patch for 6.1 series

Please note that only the 5.2, 6.0, and 6.1 series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Credits

Thanks to Benoit Côté-Jodoin from Shopify for reporting this.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.3.6"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.1.3.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "fixed": "6.1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2.5"
            },
            {
              "fixed": "5.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.2.4.5"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "5.2.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-22885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-05T19:48:10Z",
    "nvd_published_at": "2021-05-27T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "Impact\n------\nThere is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the `redirect_to` or `polymorphic_url` helper with untrusted user input.\n\nVulnerable code will look like this.\n\n```\nredirect_to(params[:some_param])\n```\n\nAll users running an affected release should either upgrade or use one of the workarounds immediately.\n\nReleases\n--------\nThe FIXED releases are available at the normal locations.\n\nWorkarounds\n-----------\nTo work around this problem, it is recommended to use an allow list for valid parameters passed from the user.  For example,\n\n```ruby\nprivate def check(param)\n  case param\n  when \"valid\"\n    param\n  else\n    \"/\"\n  end\nend\n\ndef index\n  redirect_to(check(params[:some_param]))\nend\n```\n\nOr force the user input to be cast to a string like this,\n\n```ruby\ndef index\n  redirect_to(params[:some_param].to_s)\nend\n```\n\nPatches\n-------\nTo aid users who aren\u0027t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.\n\n* 5-2-information-disclosure.patch - Patch for 5.2 series\n* 6-0-information-disclosure.patch - Patch for 6.0 series\n* 6-1-information-disclosure.patch - Patch for 6.1 series\n\nPlease note that only the 5.2, 6.0, and 6.1 series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.\n\nCredits\n-------\n\nThanks to Benoit C\u00f4t\u00e9-Jodoin from Shopify for reporting this.",
  "id": "GHSA-hjg4-8q5f-x6fm",
  "modified": "2023-07-05T20:17:23Z",
  "published": "2021-05-05T19:49:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22885"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1106652"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/CVE-2021-22885.yml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/rubyonrails-security/c/NiQl-48cXYI"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210805-0009"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Action Pack contains Information Disclosure / Unintended Method Execution vulnerability"
}

GHSA-HJQ3-5XJW-J37Q

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-05-24 17:38
VLAI
Details

IBM Jazz Foundation Products could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 183189.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4544"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-08T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Jazz Foundation Products could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 183189.",
  "id": "GHSA-hjq3-5xjw-j37q",
  "modified": "2022-05-24T17:38:21Z",
  "published": "2022-05-24T17:38:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4544"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/183189"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6398742"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HJWH-XVFW-QRWJ

Vulnerability from github – Published: 2026-08-19 19:32 – Updated: 2026-08-19 19:32
VLAI
Summary
SearXNG Basic Authentication Credentials Exposed Through MCP Logs and JSON-RPC Error Responses
Details

Summary

mcp-searxng version 1.11.0 exposes SearXNG Basic Authentication credentials embedded in the SEARXNG_URL environment variable.

When the server starts in STDIO mode and an MCP client connects, the complete SEARXNG_URL, including its username and password, is sent to the client through an MCP notifications/message logging notification.

Additionally, when URL validation fails, the complete credential-bearing URL is included in the configuration error. This error is logged through MCP and returned to the client as a JSON-RPC error response.

For example, a value such as:

http://username:password@searxng.example.com

is exposed without redaction.

A connected MCP client or anyone with access to captured server logs may recover the SearXNG credentials and use them to access the configured SearXNG instance.

The issue was confirmed in:

mcp-searxng 1.11.0

Suggested severity: Medium

Details

mcp-searxng supports SearXNG Basic Authentication by embedding credentials in the URL userinfo component:

https://username:password@searxng.example.com

The project contains a redaction function named redactSearxngInstanceUrl(), but it is not used in several logging and error-handling paths.

Startup console disclosure

In src/index.ts:373-378, the server retrieves the raw SearXNG URLs and writes them directly to stderr:

const searxngInstances = getSearxngInstances();

if (searxngInstances.length > 0) {
  console.error(`🌐 SearXNG URLs: ${searxngInstances.join("; ")}`);
}

getSearxngInstances() returns the unmodified environment-variable values.

Relevant code in src/searxng-instances.ts:25-38:

export function parseSearxngUrls(
  raw: string | undefined = process.env.SEARXNG_URL
): string[] {
  if (raw === undefined) {
    return [];
  }

  return raw
    .split(";")
    .map((entry) => entry.trim())
    .filter((entry) => entry !== "");
}

export function getSearxngInstances(): string[] {
  return parseSearxngUrls();
}

MCP logging notification disclosure

After the MCP client connects, src/index.ts:388-393 sends the complete URL through the MCP logging interface:

const searxngInstances = getSearxngInstances();

logMessage(
  mcpServer,
  "info",
  `SearXNG URLs: ${
    searxngInstances.length > 0
      ? searxngInstances.join("; ")
      : "not configured"
  }`
);

logMessage() passes this value to sendLoggingMessage() in src/logging.ts:15-25:

mcpServer.sendLoggingMessage({
  level,
  data: notificationData
});

As a result, the connected MCP client receives a message containing the username and password:

{
  "method": "notifications/message",
  "params": {
    "level": "info",
    "data": {
      "message": "SearXNG URLs: http://username:password@searxng.example.com"
    }
  },
  "jsonrpc": "2.0"
}

Configuration error disclosure

The URL validation function includes the complete unredacted value in error messages.

Relevant code in src/searxng-instances.ts:44-52:

export function validateSearxngInstanceUrl(
  value: string
): string | null {
  try {
    const url = new URL(value);

    if (!["http:", "https:"].includes(url.protocol)) {
      return `SEARXNG_URL invalid protocol for "${value}": ${url.protocol}`;
    }
  } catch {
    return `SEARXNG_URL invalid format: ${value}`;
  }

  return null;
}

The validation error is aggregated by validateEnvironment() in src/error-handler.ts:175-203:

const validationError =
  validateSearxngInstanceUrl(searxngUrl);

if (validationError) {
  issues.push(validationError);
}

The complete error is then thrown from src/search.ts:689-693:

const validationError = validateEnvironment();

if (validationError) {
  logMessage(mcpServer, "error", "Configuration invalid");
  throw new MCPSearXNGError(validationError);
}

The tool handler in src/index.ts:254-260 sends the error message and stack trace through MCP logging, then rethrows it:

logMessage(
  mcpServer,
  "error",
  `Tool execution error: ${
    error instanceof Error
      ? error.message
      : String(error)
  }`,
  {
    tool: name,
    args: args,
    error:
      error instanceof Error
        ? error.stack
        : String(error)
  }
);

throw error;

Rethrowing the error causes the same unredacted credential-bearing URL to be returned in the JSON-RPC error response.

Existing redaction function is not used

The project already contains a suitable redaction function in src/searxng-instances.ts:57-69:

export function redactSearxngInstanceUrl(
  raw: string
): string {
  try {
    const url = new URL(raw);

    if (!url.username && !url.password) {
      return raw;
    }

    url.username = "";
    url.password = "";
    return url.toString();
  } catch {
    return raw.replace(
      /^([a-zA-Z][a-zA-Z0-9+.-]*:\/\/)[^/]*@/,
      "$1"
    );
  }
}

However, this function is not applied before startup logging, MCP logging, or configuration error construction.

The MCP manifest also marks SEARXNG_URL as non-secret in .mcp/server.json:20-25:

{
  "name": "SEARXNG_URL",
  "description": "URL of your SearXNG instance",
  "isRequired": true,
  "isSecret": false,
  "format": "string"
}

Because credentials may be embedded in this variable, it should be classified as a secret.

PoC

The following proof of concept uses fake credentials. A real SearXNG server is not required.

Requirements

Node.js 20 or newer
npm
mcp-searxng 1.11.0 source code

Build the application

unzip mcp-searxng-main.zip
cd mcp-searxng-main

npm ci
npm run build

Test 1: Credential disclosure through MCP logging

Create an MCP initialization request:

cat > /tmp/mcp-init.jsonl <<'EOF'
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"credential-leak-poc","version":"1.0.0"}}}
EOF

Start the server with fake credentials embedded in a valid HTTP URL:

SEARXNG_URL='http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9' \
timeout 8s node dist/cli.js \
< /tmp/mcp-init.jsonl \
2>&1 | tee credential-log-leak.txt

Search the output for the credentials:

grep -nE \
'MCP_POC_USER_7391|MCP_POC_PASS_7391' \
credential-log-leak.txt

Observed result

The complete credential-bearing URL is exposed:

SearXNG URLs: http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9

It is also delivered to the MCP client:

{
  "method": "notifications/message",
  "params": {
    "level": "info",
    "data": {
      "message": "SearXNG URLs: http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9"
    }
  },
  "jsonrpc": "2.0"
}

This confirms that a connected MCP client can recover the configured username and password without accessing the host environment.

Test 2: Credential disclosure through JSON-RPC errors

Create initialization and tool-call requests:

cat > /tmp/mcp-error-poc.jsonl <<'EOF'
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"credential-error-poc","version":"1.0.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"searxng_web_search","arguments":{"query":"credential leak test"}}}
EOF

Start the server with a credential-bearing URL that uses an unsupported protocol:

SEARXNG_URL='ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid' \
timeout 8s node dist/cli.js \
< /tmp/mcp-error-poc.jsonl \
2>&1 | tee credential-error-leak.txt

Search the response:

grep -nE \
'MCP_POC_USER_7391|MCP_POC_PASS_7391' \
credential-error-leak.txt

Observed result

The complete URL is exposed in the MCP logging notification:

Tool execution error: Configuration Issues: SEARXNG_URL invalid protocol for "ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid": ftp:

It is also returned directly in the JSON-RPC error:

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32603,
    "message": "Configuration Issues: SEARXNG_URL invalid protocol for \"ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid\": ftp:"
  }
}

The raw username and password are therefore exposed through both logging and protocol responses.

Impact

This is a sensitive credential disclosure vulnerability.

The following parties may obtain the credentials:

  1. A connected MCP client receiving logging notifications.
  2. A client capable of invoking a tool and receiving JSON-RPC errors.
  3. A user or process with access to captured stderr output.
  4. A centralized logging or monitoring system collecting application logs.
  5. Other users with access to shared log files or container logs.

The exposed credentials may allow an attacker to authenticate directly to the configured SearXNG instance.

Depending on the SearXNG deployment and the permissions associated with the account, this may allow:

  1. Unauthorized use of a private SearXNG service.
  2. Access to functionality restricted through Basic Authentication.
  3. Consumption of private server resources.
  4. Exposure of information available only to authenticated users.
  5. Further account compromise where the credentials have been reused.

The default STDIO transport limits the exposure to the connected parent MCP client and local logging environment. However, MCP clients should not receive upstream service credentials, and the project security documentation explicitly treats credentials embedded in SEARXNG_URL as secrets that must be redacted.

Suggested mitigation

Apply redactSearxngInstanceUrl() before including any SearXNG URL in console or MCP logging:

const redactedInstances = getSearxngInstances()
  .map(redactSearxngInstanceUrl);

logMessage(
  mcpServer,
  "info",
  `SearXNG URLs: ${
    redactedInstances.length > 0
      ? redactedInstances.join("; ")
      : "not configured"
  }`
);

Do not include raw configuration values in validation errors. A generic error can be returned instead:

return `SEARXNG_URL entry has an unsupported protocol: ${url.protocol}`;

For malformed URLs:

return "SEARXNG_URL contains an invalid URL";

The following additional changes are recommended:

  1. Redact URLs before writing them to stderr.
  2. Redact secrets before sending MCP logging notifications.
  3. Avoid including raw environment-variable values in exceptions.
  4. Avoid returning detailed stack traces containing secrets to MCP clients.
  5. Mark SEARXNG_URL as secret in .mcp/server.json:
"isSecret": true
  1. Add regression tests that assert usernames and passwords never appear in:

  2. stderr output

  3. MCP logging notifications
  4. JSON-RPC error responses
  5. stack traces
  6. configuration resources
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mcp-searxng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-19T19:32:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nmcp-searxng version 1.11.0 exposes SearXNG Basic Authentication credentials embedded in the `SEARXNG_URL` environment variable.\n\nWhen the server starts in STDIO mode and an MCP client connects, the complete `SEARXNG_URL`, including its username and password, is sent to the client through an MCP `notifications/message` logging notification.\n\nAdditionally, when URL validation fails, the complete credential-bearing URL is included in the configuration error. This error is logged through MCP and returned to the client as a JSON-RPC error response.\n\nFor example, a value such as:\n\n```text\nhttp://username:password@searxng.example.com\n```\n\nis exposed without redaction.\n\nA connected MCP client or anyone with access to captured server logs may recover the SearXNG credentials and use them to access the configured SearXNG instance.\n\nThe issue was confirmed in:\n\n```text\nmcp-searxng 1.11.0\n```\n\nSuggested severity: **Medium**\n\n### Details\n\nmcp-searxng supports SearXNG Basic Authentication by embedding credentials in the URL userinfo component:\n\n```text\nhttps://username:password@searxng.example.com\n```\n\nThe project contains a redaction function named `redactSearxngInstanceUrl()`, but it is not used in several logging and error-handling paths.\n\n#### Startup console disclosure\n\nIn `src/index.ts:373-378`, the server retrieves the raw SearXNG URLs and writes them directly to stderr:\n\n```typescript\nconst searxngInstances = getSearxngInstances();\n\nif (searxngInstances.length \u003e 0) {\n  console.error(`\ud83c\udf10 SearXNG URLs: ${searxngInstances.join(\"; \")}`);\n}\n```\n\n`getSearxngInstances()` returns the unmodified environment-variable values.\n\nRelevant code in `src/searxng-instances.ts:25-38`:\n\n```typescript\nexport function parseSearxngUrls(\n  raw: string | undefined = process.env.SEARXNG_URL\n): string[] {\n  if (raw === undefined) {\n    return [];\n  }\n\n  return raw\n    .split(\";\")\n    .map((entry) =\u003e entry.trim())\n    .filter((entry) =\u003e entry !== \"\");\n}\n\nexport function getSearxngInstances(): string[] {\n  return parseSearxngUrls();\n}\n```\n\n#### MCP logging notification disclosure\n\nAfter the MCP client connects, `src/index.ts:388-393` sends the complete URL through the MCP logging interface:\n\n```typescript\nconst searxngInstances = getSearxngInstances();\n\nlogMessage(\n  mcpServer,\n  \"info\",\n  `SearXNG URLs: ${\n    searxngInstances.length \u003e 0\n      ? searxngInstances.join(\"; \")\n      : \"not configured\"\n  }`\n);\n```\n\n`logMessage()` passes this value to `sendLoggingMessage()` in `src/logging.ts:15-25`:\n\n```typescript\nmcpServer.sendLoggingMessage({\n  level,\n  data: notificationData\n});\n```\n\nAs a result, the connected MCP client receives a message containing the username and password:\n\n```json\n{\n  \"method\": \"notifications/message\",\n  \"params\": {\n    \"level\": \"info\",\n    \"data\": {\n      \"message\": \"SearXNG URLs: http://username:password@searxng.example.com\"\n    }\n  },\n  \"jsonrpc\": \"2.0\"\n}\n```\n\n#### Configuration error disclosure\n\nThe URL validation function includes the complete unredacted value in error messages.\n\nRelevant code in `src/searxng-instances.ts:44-52`:\n\n```typescript\nexport function validateSearxngInstanceUrl(\n  value: string\n): string | null {\n  try {\n    const url = new URL(value);\n\n    if (![\"http:\", \"https:\"].includes(url.protocol)) {\n      return `SEARXNG_URL invalid protocol for \"${value}\": ${url.protocol}`;\n    }\n  } catch {\n    return `SEARXNG_URL invalid format: ${value}`;\n  }\n\n  return null;\n}\n```\n\nThe validation error is aggregated by `validateEnvironment()` in `src/error-handler.ts:175-203`:\n\n```typescript\nconst validationError =\n  validateSearxngInstanceUrl(searxngUrl);\n\nif (validationError) {\n  issues.push(validationError);\n}\n```\n\nThe complete error is then thrown from `src/search.ts:689-693`:\n\n```typescript\nconst validationError = validateEnvironment();\n\nif (validationError) {\n  logMessage(mcpServer, \"error\", \"Configuration invalid\");\n  throw new MCPSearXNGError(validationError);\n}\n```\n\nThe tool handler in `src/index.ts:254-260` sends the error message and stack trace through MCP logging, then rethrows it:\n\n```typescript\nlogMessage(\n  mcpServer,\n  \"error\",\n  `Tool execution error: ${\n    error instanceof Error\n      ? error.message\n      : String(error)\n  }`,\n  {\n    tool: name,\n    args: args,\n    error:\n      error instanceof Error\n        ? error.stack\n        : String(error)\n  }\n);\n\nthrow error;\n```\n\nRethrowing the error causes the same unredacted credential-bearing URL to be returned in the JSON-RPC error response.\n\n#### Existing redaction function is not used\n\nThe project already contains a suitable redaction function in `src/searxng-instances.ts:57-69`:\n\n```typescript\nexport function redactSearxngInstanceUrl(\n  raw: string\n): string {\n  try {\n    const url = new URL(raw);\n\n    if (!url.username \u0026\u0026 !url.password) {\n      return raw;\n    }\n\n    url.username = \"\";\n    url.password = \"\";\n    return url.toString();\n  } catch {\n    return raw.replace(\n      /^([a-zA-Z][a-zA-Z0-9+.-]*:\\/\\/)[^/]*@/,\n      \"$1\"\n    );\n  }\n}\n```\n\nHowever, this function is not applied before startup logging, MCP logging, or configuration error construction.\n\nThe MCP manifest also marks `SEARXNG_URL` as non-secret in `.mcp/server.json:20-25`:\n\n```json\n{\n  \"name\": \"SEARXNG_URL\",\n  \"description\": \"URL of your SearXNG instance\",\n  \"isRequired\": true,\n  \"isSecret\": false,\n  \"format\": \"string\"\n}\n```\n\nBecause credentials may be embedded in this variable, it should be classified as a secret.\n\n### PoC\n\nThe following proof of concept uses fake credentials. A real SearXNG server is not required.\n\n#### Requirements\n\n```text\nNode.js 20 or newer\nnpm\nmcp-searxng 1.11.0 source code\n```\n\n#### Build the application\n\n```bash\nunzip mcp-searxng-main.zip\ncd mcp-searxng-main\n\nnpm ci\nnpm run build\n```\n\n#### Test 1: Credential disclosure through MCP logging\n\nCreate an MCP initialization request:\n\n```bash\ncat \u003e /tmp/mcp-init.jsonl \u003c\u003c\u0027EOF\u0027\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"credential-leak-poc\",\"version\":\"1.0.0\"}}}\nEOF\n```\n\nStart the server with fake credentials embedded in a valid HTTP URL:\n\n```bash\nSEARXNG_URL=\u0027http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9\u0027 \\\ntimeout 8s node dist/cli.js \\\n\u003c /tmp/mcp-init.jsonl \\\n2\u003e\u00261 | tee credential-log-leak.txt\n```\n\nSearch the output for the credentials:\n\n```bash\ngrep -nE \\\n\u0027MCP_POC_USER_7391|MCP_POC_PASS_7391\u0027 \\\ncredential-log-leak.txt\n```\n\n#### Observed result\n\nThe complete credential-bearing URL is exposed:\n\n```text\nSearXNG URLs: http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9\n```\n\nIt is also delivered to the MCP client:\n\n```json\n{\n  \"method\": \"notifications/message\",\n  \"params\": {\n    \"level\": \"info\",\n    \"data\": {\n      \"message\": \"SearXNG URLs: http://MCP_POC_USER_7391:MCP_POC_PASS_7391@127.0.0.1:9\"\n    }\n  },\n  \"jsonrpc\": \"2.0\"\n}\n```\n\nThis confirms that a connected MCP client can recover the configured username and password without accessing the host environment.\n\n#### Test 2: Credential disclosure through JSON-RPC errors\n\nCreate initialization and tool-call requests:\n\n```bash\ncat \u003e /tmp/mcp-error-poc.jsonl \u003c\u003c\u0027EOF\u0027\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"credential-error-poc\",\"version\":\"1.0.0\"}}}\n{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\"name\":\"searxng_web_search\",\"arguments\":{\"query\":\"credential leak test\"}}}\nEOF\n```\n\nStart the server with a credential-bearing URL that uses an unsupported protocol:\n\n```bash\nSEARXNG_URL=\u0027ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid\u0027 \\\ntimeout 8s node dist/cli.js \\\n\u003c /tmp/mcp-error-poc.jsonl \\\n2\u003e\u00261 | tee credential-error-leak.txt\n```\n\nSearch the response:\n\n```bash\ngrep -nE \\\n\u0027MCP_POC_USER_7391|MCP_POC_PASS_7391\u0027 \\\ncredential-error-leak.txt\n```\n\n#### Observed result\n\nThe complete URL is exposed in the MCP logging notification:\n\n```text\nTool execution error: Configuration Issues: SEARXNG_URL invalid protocol for \"ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid\": ftp:\n```\n\nIt is also returned directly in the JSON-RPC error:\n\n```json\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 2,\n  \"error\": {\n    \"code\": -32603,\n    \"message\": \"Configuration Issues: SEARXNG_URL invalid protocol for \\\"ftp://MCP_POC_USER_7391:MCP_POC_PASS_7391@example.invalid\\\": ftp:\"\n  }\n}\n```\n\nThe raw username and password are therefore exposed through both logging and protocol responses.\n\n### Impact\n\nThis is a sensitive credential disclosure vulnerability.\n\nThe following parties may obtain the credentials:\n\n1. A connected MCP client receiving logging notifications.\n2. A client capable of invoking a tool and receiving JSON-RPC errors.\n3. A user or process with access to captured stderr output.\n4. A centralized logging or monitoring system collecting application logs.\n5. Other users with access to shared log files or container logs.\n\nThe exposed credentials may allow an attacker to authenticate directly to the configured SearXNG instance.\n\nDepending on the SearXNG deployment and the permissions associated with the account, this may allow:\n\n1. Unauthorized use of a private SearXNG service.\n2. Access to functionality restricted through Basic Authentication.\n3. Consumption of private server resources.\n4. Exposure of information available only to authenticated users.\n5. Further account compromise where the credentials have been reused.\n\nThe default STDIO transport limits the exposure to the connected parent MCP client and local logging environment. However, MCP clients should not receive upstream service credentials, and the project security documentation explicitly treats credentials embedded in `SEARXNG_URL` as secrets that must be redacted.\n\n### Suggested mitigation\n\nApply `redactSearxngInstanceUrl()` before including any SearXNG URL in console or MCP logging:\n\n```typescript\nconst redactedInstances = getSearxngInstances()\n  .map(redactSearxngInstanceUrl);\n\nlogMessage(\n  mcpServer,\n  \"info\",\n  `SearXNG URLs: ${\n    redactedInstances.length \u003e 0\n      ? redactedInstances.join(\"; \")\n      : \"not configured\"\n  }`\n);\n```\n\nDo not include raw configuration values in validation errors. A generic error can be returned instead:\n\n```typescript\nreturn `SEARXNG_URL entry has an unsupported protocol: ${url.protocol}`;\n```\n\nFor malformed URLs:\n\n```typescript\nreturn \"SEARXNG_URL contains an invalid URL\";\n```\n\nThe following additional changes are recommended:\n\n1. Redact URLs before writing them to stderr.\n2. Redact secrets before sending MCP logging notifications.\n3. Avoid including raw environment-variable values in exceptions.\n4. Avoid returning detailed stack traces containing secrets to MCP clients.\n5. Mark `SEARXNG_URL` as secret in `.mcp/server.json`:\n\n```json\n\"isSecret\": true\n```\n\n6. Add regression tests that assert usernames and passwords never appear in:\n\n   * stderr output\n   * MCP logging notifications\n   * JSON-RPC error responses\n   * stack traces\n   * configuration resources",
  "id": "GHSA-hjwh-xvfw-qrwj",
  "modified": "2026-08-19T19:32:46Z",
  "published": "2026-08-19T19:32:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ihor-sokoliuk/mcp-searxng/security/advisories/GHSA-hjwh-xvfw-qrwj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ihor-sokoliuk/mcp-searxng"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ihor-sokoliuk/mcp-searxng/releases/tag/v1.12.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SearXNG Basic Authentication Credentials Exposed Through MCP Logs and JSON-RPC Error Responses"
}

Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Mitigation
Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Mitigation MIT-33
Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Mitigation MIT-40
Implementation Build and Compilation

Strategy: Compilation or Build Hardening

Debugging information should not make its way into a production release.

Mitigation MIT-40
Implementation Build and Compilation

Strategy: Environment Hardening

Debugging information should not make its way into a production release.

Mitigation
System Configuration

Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.

Mitigation
System Configuration

Create default error pages or messages that do not leak any information.

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.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-54: Query System for Information

An adversary, aware of an application's location (and possibly authorized to use the application), probes an application's structure and evaluates its robustness by submitting requests and examining responses. Often, this is accomplished by sending variants of expected queries in the hope that these modified queries might return information beyond what the expected set of queries would provide.

CAPEC-7: Blind SQL Injection

Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the adversary constructs input strings that probe the target through simple Boolean SQL expressions. The adversary can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the adversary determines how and where the target is vulnerable to SQL Injection.