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.

833 vulnerabilities reference this CWE, most recent first.

GHSA-X9R7-5C46-9X5P

Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-01-30 21:30
VLAI
Details

IBM Sterling B2B Integrator 6.0.0.0 and 6.0.0.1 reveals sensitive information from a stack trace that could be used in further attacks against the system. IBM X-Force ID: 162803.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-4377"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-25T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling B2B Integrator 6.0.0.0 and 6.0.0.1 reveals sensitive information from a stack trace that could be used in further attacks against the system. IBM X-Force ID: 162803.",
  "id": "GHSA-x9r7-5c46-9x5p",
  "modified": "2023-01-30T21:30:43Z",
  "published": "2022-05-24T22:00:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4377"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/162083"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=ibm10887853"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108915"
    }
  ],
  "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-XCH9-H8QW-85C7

Vulnerability from github – Published: 2025-10-02 21:15 – Updated: 2025-11-05 22:07
VLAI
Summary
Canonical LXD Project Existence Determination Through Error Handling in Image Get Function
Details

Impact

The LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69

This configuration allows access without authentication:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926

This API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.

The problematic implementation is shown below.

First, in the error handling implementation of the imagesGet function below, project existence is checked within the projectutils.ImageProject function, and the err returned by the ImageProject function is directly returned to the user.

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788

When the project doesn't exist, the error is 404 (http.StatusNotFound), which is returned to the user:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/cluster/projects.mapper.go#L237-L239

On the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L1796-L1799

Reproduction Steps

  1. Send the following request without authentication to a non-existent project:
curl -k "https://lxd-host:8443/1.0/images?project=XXX-project"

Response:

{"type":"error","status":"","status_code":0,"operation":"","error_code":404,"error":"fetch project: Project not found","metadata":null}
  1. Send a request without authentication to an existing project (if a public project exists, it will be included in the response):
curl -k "https://lxd-host:8443/1.0/images?project=exist-project"

Reponse:

{"type":"error","status":"","status_code":0,"operation":"","error_code":403,"error":"Untrusted callers may only access public images in the default project","metadata":null}

Risk

The attack requires only network access to the LXD API endpoint, with no authentication needed.

The attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. This could potentially increase the exploitability of othervulnerabilities.

Additionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.

Countermeasures

It is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.

This ensures that the same error response is returned for both existing and non-existing projects, preventing determination of project existence.

Patches

LXD Series Status
6 Fixed in LXD 6.5
5.21 Fixed in LXD 5.21.4
5.0 Ignored - Not critical
4.0 Ignored - EOL and not critical

References

Reported by GMO Flatt Security Inc.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "5.21.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0"
            },
            {
              "fixed": "6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20200331193331-03aab09f5b5c"
            },
            {
              "fixed": "0.0.0-20250827065555-0494f5d47e41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-02T21:15:46Z",
    "nvd_published_at": "2025-10-02T10:15:39Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.\n\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69\n\nThis configuration allows access without authentication:\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926\n\nThis API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.\n\nThe problematic implementation is shown below.\n\nFirst, in the error handling implementation of the imagesGet function below, project existence is checked within the `projectutils.ImageProject` function, and the err returned by the `ImageProject` function is directly returned to the user.\n\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788\n\nWhen the project doesn\u0027t exist, the error is 404 (http.StatusNotFound), which is\nreturned to the user:\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/cluster/projects.mapper.go#L237-L239\n\nOn the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L1796-L1799\n\n### Reproduction Steps\n1. Send the following request without authentication to a non-existent project:\n\n```\ncurl -k \"https://lxd-host:8443/1.0/images?project=XXX-project\"\n```\n\nResponse:\n\n```json\n{\"type\":\"error\",\"status\":\"\",\"status_code\":0,\"operation\":\"\",\"error_code\":404,\"error\":\"fetch project: Project not found\",\"metadata\":null}\n```\n\n2. Send a request without authentication to an existing project (if a public project exists, it will be included in the response):\n\n```\ncurl -k \"https://lxd-host:8443/1.0/images?project=exist-project\"\n```\n\nReponse:\n\n```\n{\"type\":\"error\",\"status\":\"\",\"status_code\":0,\"operation\":\"\",\"error_code\":403,\"error\":\"Untrusted callers may only access public images in the default project\",\"metadata\":null}\n```\n\n### Risk\nThe attack requires only network access to the LXD API endpoint, with no authentication needed.\n\nThe attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. \nThis could potentially increase the exploitability of othervulnerabilities.\n\nAdditionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.\n\n### Countermeasures\nIt is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.\n\nThis ensures that the same error response is returned for both existing and non-existing\nprojects, preventing determination of project existence.\n\n### Patches\n\n| LXD Series  | Status |\n| ------------- | ------------- |\n| 6 | Fixed in LXD 6.5  |\n| 5.21 | Fixed in LXD 5.21.4  |\n| 5.0 | Ignored - Not critical |\n| 4.0  | Ignored - EOL and not critical |\n\n### References\nReported by GMO Flatt Security Inc.",
  "id": "GHSA-xch9-h8qw-85c7",
  "modified": "2025-11-05T22:07:56Z",
  "published": "2025-10-02T21:15:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/security/advisories/GHSA-xch9-h8qw-85c7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54291"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/canonical/lxd"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-4005"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Canonical LXD Project Existence Determination Through Error Handling in Image Get Function"
}

GHSA-XF64-2F9P-6PQQ

Vulnerability from github – Published: 2020-09-04 17:24 – Updated: 2020-08-31 18:59
VLAI
Summary
Information Exposure in type-graphql
Details

Versions of type-graphql prior to 0.17.6 are vulnerable to Information Exposure. The package leaks the resolver source code in an error message. It is possible to force this error when no subscription topics are provided in the request.

Recommendation

Upgrade to version 0.17.6 or later.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "type-graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T18:59:32Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Versions of `type-graphql` prior to 0.17.6 are vulnerable to Information Exposure. The package leaks the resolver source code in an error message. It is possible to force this error when no subscription topics are provided in the request.\n\n\n## Recommendation\n\nUpgrade to version 0.17.6 or later.",
  "id": "GHSA-xf64-2f9p-6pqq",
  "modified": "2020-08-31T18:59:32Z",
  "published": "2020-09-04T17:24:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MichalLytek/type-graphql/issues/489"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/1444"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Information Exposure in type-graphql"
}

GHSA-XFX3-CR74-X3CV

Vulnerability from github – Published: 2024-06-26 18:30 – Updated: 2024-11-06 14:27
VLAI
Summary
Exposure of secrets through system log in Jenkins Structs Plugin
Details

Structs Plugin provides utility functionality used, e.g., in Pipeline to instantiate and configure build steps, typically before their execution.

When Structs Plugin 337.v1b_04ea_4df7c8 and earlier fails to configure a build step, it logs a warning message containing diagnostic information that may contain secrets passed as step parameters.

This can result in accidental exposure of secrets through the default system log.

Structs Plugin 338.v848422169819 inspects the types of actual parameters before logging these warning messages, and limits detailed diagnostic information to FINE level log messages if secrets are involved. These log messages are not displayed in the default Jenkins system log.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:structs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "338.v848422169819"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-39458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-26T20:03:44Z",
    "nvd_published_at": "2024-06-26T17:15:27Z",
    "severity": "LOW"
  },
  "details": "Structs Plugin provides utility functionality used, e.g., in Pipeline to instantiate and configure build steps, typically before their execution.\n\nWhen Structs Plugin 337.v1b_04ea_4df7c8 and earlier fails to configure a build step, it logs a warning message containing diagnostic information that may contain secrets passed as step parameters.\n\nThis can result in accidental exposure of secrets through the default system log.\n\nStructs Plugin 338.v848422169819 inspects the types of actual parameters before logging these warning messages, and limits detailed diagnostic information to FINE level log messages if secrets are involved. These log messages are not displayed in the default Jenkins system log.\n",
  "id": "GHSA-xfx3-cr74-x3cv",
  "modified": "2024-11-06T14:27:40Z",
  "published": "2024-06-26T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39458"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/structs-plugin/commit/84842216981976d920b568726f8590a7b39a56a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/structs-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2024-06-26/#SECURITY-3371"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/06/26/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Exposure of secrets through system log in Jenkins Structs Plugin"
}

GHSA-XGGC-QPRG-X6MW

Vulnerability from github – Published: 2022-06-23 17:40 – Updated: 2022-06-23 17:40
VLAI
Summary
Weave GitOps leaked cluster credentials into logs on connection errors
Details

Impact

A vulnerability in the logging of Weave GitOps could allow an authenticated remote attacker to view sensitive cluster configurations, aka KubeConfg, of registered Kubernetes clusters, including the service account tokens in plain text from Weave GitOps's pod logs on the management cluster. An unauthorized remote attacker can also view these sensitive configurations from external log storage if enabled by the management cluster.

This vulnerability is due to the client factory dumping cluster configurations and their service account tokens when the cluster manager tries to connect to an API server of a registered cluster, and a connection error occurs. An attacker could exploit this vulnerability by either accessing logs of a pod of Weave GitOps, or from external log storage and obtaining all cluster configurations of registered clusters.

A successful exploit could allow the attacker to use those cluster configurations to manage the registered Kubernetes clusters.

Patches

This vulnerability has been fixed by commit 567356f471353fb5c676c77f5abc2a04631d50ca. Users should upgrade to Weave GitOps core version >= v0.8.1-rc.6 released on 31/05/2022.

Workarounds

There is no workaround for this vulnerability.

References

Disclosed by Stefan Prodan, Principal Engineer, Weaveworks.

For more information

If you have any questions or comments about this advisory: * Open an issue in Weave GitOps repository * Email us at support@weave.works

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.1-rc.5"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/weaveworks/weave-gitops"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.1-rc.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209",
      "CWE-532",
      "CWE-538"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-23T17:40:34Z",
    "nvd_published_at": "2022-06-27T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nA vulnerability in the logging of Weave GitOps could allow an authenticated remote attacker to view sensitive cluster configurations, aka KubeConfg, of registered Kubernetes clusters, including the service account tokens in plain text from Weave GitOps\u0027s pod logs on the management cluster. An unauthorized remote attacker can also view these sensitive configurations from external log storage if enabled by the management cluster.\n\nThis vulnerability is due to the client factory dumping cluster configurations and their service account tokens when the cluster manager tries to connect to an API server of a registered cluster, and a connection error occurs. An attacker could exploit this vulnerability by either accessing logs of a pod of Weave GitOps, or from external log storage and obtaining all cluster configurations of registered clusters.\n\nA successful exploit could allow the attacker to use those cluster configurations to manage the registered Kubernetes clusters.\n\n### Patches\nThis vulnerability has been fixed by commit 567356f471353fb5c676c77f5abc2a04631d50ca. Users should upgrade to Weave GitOps core version \u003e= v0.8.1-rc.6 released on 31/05/2022.\n\n### Workarounds\nThere is no workaround for this vulnerability.\n\n### References\nDisclosed by Stefan Prodan, Principal Engineer, Weaveworks.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Weave GitOps repository](https://github.com/weaveworks/weave-gitops)\n* Email us at [support@weave.works](mailto:support@weave.works)\n",
  "id": "GHSA-xggc-qprg-x6mw",
  "modified": "2022-06-23T17:40:34Z",
  "published": "2022-06-23T17:40:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/weaveworks/weave-gitops/security/advisories/GHSA-xggc-qprg-x6mw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31098"
    },
    {
      "type": "WEB",
      "url": "https://github.com/weaveworks/weave-gitops/commit/567356f471353fb5c676c77f5abc2a04631d50ca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/weaveworks/weave-gitops"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Weave GitOps leaked cluster credentials into logs on connection errors"
}

GHSA-XH3C-JH29-G5WJ

Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06
VLAI
Details

An information disclosure issue in GitLab CE/EE affecting all versions from 16.0 prior to 16.0.6, and version 16.1.0 allows unauthenticated actors to access the import error information if a project was imported from GitHub.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T03:15:10Z",
    "severity": "MODERATE"
  },
  "details": "An information disclosure issue in GitLab CE/EE affecting all versions from 16.0 prior to 16.0.6, and version 16.1.0 allows unauthenticated actors to access the import error information if a project was imported from GitHub.",
  "id": "GHSA-xh3c-jh29-g5wj",
  "modified": "2024-04-04T06:06:27Z",
  "published": "2023-07-13T03:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3362"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/415131"
    }
  ],
  "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-XHW8-46VJ-3GQ5

Vulnerability from github – Published: 2024-12-17 18:33 – Updated: 2024-12-17 18:33
VLAI
Details

IBM Security Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2.0, and 4.2.1

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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49818"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-17T18:15:24Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2.0, and 4.2.1 \n\ncould 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.",
  "id": "GHSA-xhw8-46vj-3gq5",
  "modified": "2024-12-17T18:33:50Z",
  "published": "2024-12-17T18:33:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49818"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7175067"
    }
  ],
  "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-XP9R-H4P3-87P5

Vulnerability from github – Published: 2022-05-05 00:29 – Updated: 2024-04-03 23:57
VLAI
Details

The Mijosoft MijoSearch component 2.0.1 and earlier for Joomla! allows remote attackers to obtain sensitive information via a request to component/mijosearch/search, which reveals the installation path in an error message.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-6879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-22T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Mijosoft MijoSearch component 2.0.1 and earlier for Joomla! allows remote attackers to obtain sensitive information via a request to component/mijosearch/search, which reveals the installation path in an error message.",
  "id": "GHSA-xp9r-h4p3-87p5",
  "modified": "2024-04-03T23:57:28Z",
  "published": "2022-05-05T00:29:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6879"
    },
    {
      "type": "WEB",
      "url": "https://www.htbridge.com/advisory/HTB23186"
    }
  ],
  "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-XV7H-95R7-595J

Vulnerability from github – Published: 2022-08-23 00:00 – Updated: 2022-08-30 20:24
VLAI
Summary
Incorrect implementation of lockout feature in Keycloak
Details

A flaw was found in keycloak where a brute force attack is possible even when the permanent lockout feature is enabled. This is due to a wrong error message displayed when wrong credentials are entered. The highest threat from this vulnerability is to confidentiality.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-parent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "13.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-30T20:24:22Z",
    "nvd_published_at": "2022-08-22T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in keycloak where a brute force attack is possible even when the permanent lockout feature is enabled. This is due to a wrong error message displayed when wrong credentials are entered. The highest threat from this vulnerability is to confidentiality.",
  "id": "GHSA-xv7h-95r7-595j",
  "modified": "2022-08-30T20:24:22Z",
  "published": "2022-08-23T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3513"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/7976"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3513"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1953439"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "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": "Incorrect implementation of lockout feature in Keycloak"
}

GHSA-XVH3-QGP6-M4R6

Vulnerability from github – Published: 2024-01-26 00:30 – Updated: 2024-01-26 00:30
VLAI
Details

A Missing Authentication for Critical Function vulnerability combined with a Generation of Error Message Containing Sensitive Information vulnerability in J-Web of Juniper Networks Junos OS on SRX Series and EX Series allows an unauthenticated, network-based attacker to access sensitive system information.

When a user logs in, a temporary file which contains the configuration of the device (as visible to that user) is created in the /cache folder. An unauthenticated attacker can then attempt to access such a file by sending a specific request to the device trying to guess the name of such a file. Successful exploitation will reveal configuration information.

This issue affects Juniper Networks Junos OS on SRX Series and EX Series: * All versions earlier than 20.4R3-S9; * 21.2 versions earlier than 21.2R3-S7; * 21.3 versions earlier than 21.3R3-S5; * 21.4 versions earlier than 21.4R3-S6; * 22.1 versions earlier than 22.1R3-S5; * 22.2 versions earlier than 22.2R3-S3; * 22.3 versions earlier than 22.3R3-S2; * 22.4 versions earlier than 22.4R3; * 23.2 versions earlier than 23.2R1-S2, 23.2R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-25T23:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A Missing Authentication for Critical Function vulnerability combined with a Generation of Error Message Containing Sensitive Information vulnerability in J-Web of Juniper Networks Junos OS on SRX Series and EX Series allows an unauthenticated, network-based attacker to access sensitive system information.\n\nWhen a user logs in, a temporary file which contains the configuration of the device (as visible to that user) is created in the /cache folder. An unauthenticated attacker can then attempt to access such a file by sending a specific request to the device trying to guess the name of such a file. Successful exploitation will reveal configuration information.\n\nThis issue affects Juniper Networks Junos OS on SRX Series and EX Series:\n  *  All versions earlier than 20.4R3-S9;\n  *  21.2 versions earlier than 21.2R3-S7;\n  *  21.3 versions earlier than 21.3R3-S5;\n  *  21.4 versions earlier than 21.4R3-S6;\n  *  22.1 versions earlier than 22.1R3-S5;\n  *  22.2 versions earlier than 22.2R3-S3;\n  *  22.3 versions earlier than 22.3R3-S2;\n  *  22.4 versions earlier than 22.4R3;\n  *  23.2 versions earlier than 23.2R1-S2, 23.2R2.\n\n\n",
  "id": "GHSA-xvh3-qgp6-m4r6",
  "modified": "2024-01-26T00:30:29Z",
  "published": "2024-01-26T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21619"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA76390"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.