Common Weakness Enumeration

CWE-426

Allowed-with-Review

Untrusted Search Path

Abstraction: Base · Status: Stable

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

892 vulnerabilities reference this CWE, most recent first.

GHSA-3WVX-JRH2-66C7

Vulnerability from github – Published: 2024-10-16 18:31 – Updated: 2024-10-16 18:31

Details

Untrusted Search Path vulnerability in OpenText™ Application Lifecycle Management (ALM),Quality Center allows Code Inclusion. The vulnerability allows a user to archive a malicious DLLs on the system prior to the installation.

This issue affects Application Lifecycle Management (ALM),Quality Center: 15.00, 15.01, 15.01 P1, 15.01 P2, 15.01 P3, 15.01 P4, 15.01 P5, 15.51, 15.51 P1, 15.51 P2, 15.51 P3, 16.00, 16.01 P1.

Severity

5.3 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/S:N/AU:N/V:D/RE:L/U:Clear

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-32266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-16T17:15:13Z",
    "severity": "MODERATE"
  },
  "details": "Untrusted Search Path vulnerability in OpenText\u2122 Application Lifecycle Management (ALM),Quality Center allows Code Inclusion. The vulnerability allows a user to archive a malicious DLLs on the system prior to the installation. \u00a0\n\nThis issue affects Application Lifecycle Management (ALM),Quality Center: 15.00, 15.01, 15.01 P1, 15.01 P2, 15.01 P3, 15.01 P4, 15.01 P5, 15.51, 15.51 P1, 15.51 P2, 15.51 P3, 16.00, 16.01 P1.",
  "id": "GHSA-3wvx-jrh2-66c7",
  "modified": "2024-10-16T18:31:44Z",
  "published": "2024-10-16T18:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32266"
    },
    {
      "type": "WEB",
      "url": "https://portal.microfocus.com/s/article/KM000024386?language=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:N/R:X/V:D/RE:L/U:Clear",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3XVG-X47J-X75W

Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2024-09-09 21:00

Summary

Ansible Improper Input Validation vulnerability

Details

In ansible it was found that inventory variables are loaded from current working directory when running ad-hoc command which are under attacker's control, allowing to run arbitrary code as a result.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

8.5 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5"
            },
            {
              "fixed": "2.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-10874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T18:08:29Z",
    "nvd_published_at": "2018-07-02T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "In ansible it was found that inventory variables are loaded from current working directory when running ad-hoc command which are under attacker\u0027s control, allowing to run arbitrary code as a result.",
  "id": "GHSA-3xvg-x47j-x75w",
  "modified": "2024-09-09T21:00:14Z",
  "published": "2022-05-13T01:07:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10874"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/pull/42067"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/44874addc7ea136f83c67d5869047ece02645fdb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/1f80949f964a946773f9d3ac1899535bd2cc2b8e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/10d6fe6c98cfee9a7be0fea6102ba5dec951aec7"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20201130165946/http://www.securitytracker.com/id/1041396"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4072-1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/ansible/PYSEC-2018-81.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ansible/ansible"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10874"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1596528"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2018-10874"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:0054"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2585"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2321"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2166"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2152"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2151"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2150"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2018:3788"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ansible Improper Input Validation vulnerability"
}

GHSA-423P-G724-FR39

Vulnerability from github – Published: 2026-05-11 15:59 – Updated: 2026-06-09 02:00

Summary

CloudNativePG's metrics exporter allows privilege escalation to PostgreSQL superuser and OS RCE

Details

Impact

The CloudNativePG metrics exporter opens its PostgreSQL connection as the postgres superuser via the pod-local Unix socket, then demotes the session with SET ROLE pg_monitor. SET ROLE changes only current_user; session_user remains postgres. That residual superuser identity is the foothold for the rest of the chain.

Any SQL expression evaluated inside the scrape session can invoke RESET ROLE to recover real superuser privileges, then use COPY ... TO PROGRAM to spawn an OS-level subprocess as the postgres user inside the primary pod. The READ ONLY transaction flag does not block this; it gates writes to database state, not external processes.

Two exploitation paths follow from this root cause.

Path 1: custom metric queries with unqualified identifiers (all supported releases)

A database user who owns a schema on the search_path of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the session_user = postgres scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (≤30 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference.

Although search_path shadowing of unqualified identifiers is the most direct case, the underlying bug is that any expression evaluated inside the scrape session is a superuser code path. Other exploitable shapes include user-defined functions, operators or casts resolved during the scrape, joins or subqueries against user-owned tables and views, and index expressions or RLS policies on read-touched objects.

Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required)

The pg_extensions metric shipped in default-monitoring.yaml used an unqualified current_database() call and ran against every user database (target_databases: '*'). Any non-superuser who owns a user database (including the default app role created by bootstrap.initdb) could shadow current_database() and trigger the full escalation chain against a stock CNPG deployment on the first scrape after the shadow was planted.

Combined impact

The chain yields privilege escalation from a low-privileged database role (e.g. the default app role) to PostgreSQL superuser, plus arbitrary OS command execution as the postgres user inside the primary pod, all within one scrape interval. A web application SQL injection vulnerability in an app backed by a CNPG cluster is therefore sufficient to pivot to database-pod RCE.

Who is impacted

All deployments on any supported release with default monitoring enabled are affected by Path 2.
All deployments on any supported release that use custom metric queries containing unqualified catalog references are affected by Path 1.
Multi-tenant platforms that allow customers to supply or influence custom metric query bodies are at the highest risk for Path 1.

Patches

Three separate patches address the vulnerability.

Patch 1: PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples"

Schema-qualifies all unqualified pg_catalog function and view references in the shipped default-monitoring.yaml and in documentation examples. This closes Path 2 in operator-shipped configuration and removes the unqualified-identifier attack surface from all operator-shipped metric queries. Operators who clone or copy default-monitoring.yaml into custom monitoring ConfigMaps, or have copy-pasted unqualified queries elsewhere, must re-qualify those queries themselves.

Backported to all currently supported releases:

v1.29.x (x ≥ 1)
v1.28.x (x ≥ 3)

Patch 2: "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping"

Introduces a dedicated cnpg_metrics_exporter PostgreSQL role (granted pg_monitor, no superuser privileges) and maps it in pg_ident.conf via peer authentication on the local Unix socket, following the same pattern already used for cnpg_pooler_pgbouncer. The metrics exporter connects as this role instead of postgres, so session_user is never a superuser and RESET ROLE has no escalation effect. This eliminates the root cause entirely.

Demoting the session at the SQL level (via SET SESSION AUTHORIZATION pg_monitor) is not sufficient: the privilege check for SET SESSION AUTHORIZATION is whether the authenticated user is a superuser, not the current session_user. With the connection still authenticated as postgres, any SQL in the session can run RESET SESSION AUTHORIZATION and recover the original superuser identity. This is the same recovery primitive as RESET ROLE, one layer up. Only changing the authenticated user closes the loop.

With this change in place, the original chain breaks at every step: RESET ROLE and RESET SESSION AUTHORIZATION cannot recover superuser, and COPY ... TO PROGRAM requires a privilege pg_monitor does not grant. As defense in depth, the monitoring transaction also prepends pg_catalog to the connection's search_path, so unqualified catalog identifiers cannot resolve to user-planted shadow objects.

This patch changes the connection identity but not how queries are evaluated. Custom metric queries within pg_monitor's scope (catalog reads, pg_stat_* views, settings) continue to work without modification. Queries that previously relied on superuser-level access (reading user-owned tables not granted to cnpg_metrics_exporter, or superuser-only catalogs such as pg_authid or pg_subscription) will fail and need explicit GRANT statements to cnpg_metrics_exporter.

The role is created and maintained with PASSWORD NULL; any password set out-of-band is cleared on the next reconcile, so the role cannot be authenticated by password regardless of operator pre-creation.

For replica clusters, upgrade the source primary cluster before any replica clusters that consume from it. The cnpg_metrics_exporter role is created on the source primary and replicates downstream; a replica cluster upgraded first will scrape against a missing role until the source primary upgrades or the role is created manually (see the monitoring documentation).

The patch will be backported to all currently supported releases:

v1.29.x (x ≥ 1)
v1.28.x (x ≥ 3)

Workarounds

If upgrading immediately is not possible:

Schema-qualify all identifiers in custom metric queries. Use explicit pg_catalog. prefixes for all catalog functions and views (e.g. pg_catalog.current_database(), pg_catalog.now()). This is a partial mitigation: it closes the search_path-shadowing shape in operator- and user-supplied metric bodies, but other expression shapes (user-defined functions, operators or casts; joins or subqueries on user-owned tables and views; RLS policies on read-touched objects) remain superuser code paths until Patch 2 lands.
Restrict database ownership. Ensure only fully trusted roles own user databases in scraped clusters. The exploit requires the ability to plant an object on the metrics exporter's search_path in a scraped database, typically by owning the database (and therefore public via pg_database_owner) or by holding CREATE on a schema already reachable through search_path.

PG <15 caveat: public grants CREATE to PUBLIC by default before PostgreSQL 15, so any authenticated role in a scraped database can plant a shadow object regardless of ownership.
Limit the scope of target_databases: '*' queries. Avoid target_databases: '*' unless every database in the cluster, and every role that owns one, is fully trusted. Where possible, restrict target_databases to specific, known-safe databases.
Do not expose metric query SQL to untrusted users. Multi-tenant platforms that allow customers to supply or influence custom metric query bodies should treat this as a critical trust boundary until the architectural fix is released.

References

Fix (Patch 1): PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples"
Fix (Patch 2): "dedicated cnpg_metrics_exporter role with pg_ident.conf peer mapping"
Reported by: Mehmet Ince

Severity

9.9 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

9.4 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudnative-pg/cloudnative-pg"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.28.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cloudnative-pg/cloudnative-pg"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.29.0"
            },
            {
              "fixed": "1.29.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-271",
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T15:59:12Z",
    "nvd_published_at": "2026-05-28T17:16:30Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe CloudNativePG metrics exporter opens its PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket, then demotes the session with `SET ROLE pg_monitor`. `SET ROLE` changes only `current_user`; `session_user` remains `postgres`. That residual superuser identity is the foothold for the rest of the chain.\n\nAny SQL expression evaluated inside the scrape session can invoke `RESET ROLE` to recover real superuser privileges, then use `COPY ... TO PROGRAM` to spawn an OS-level subprocess as the `postgres` user inside the primary pod. The `READ ONLY` transaction flag does not block this; it gates writes to database state, not external processes.\n\nTwo exploitation paths follow from this root cause.\n\n#### Path 1: custom metric queries with unqualified identifiers (all supported releases)\n\nA database user who owns a schema on the `search_path` of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the `session_user = postgres` scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (\u226430 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference.\n\nAlthough `search_path` shadowing of unqualified identifiers is the most direct case, the underlying bug is that any expression evaluated inside the scrape session is a superuser code path. Other exploitable shapes include user-defined functions, operators or casts resolved during the scrape, joins or subqueries against user-owned tables and views, and index expressions or RLS policies on read-touched objects.\n\n#### Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required)\n\nThe `pg_extensions` metric shipped in `default-monitoring.yaml` used an unqualified `current_database()` call and ran against every user database (`target_databases: \u0027*\u0027`). Any non-superuser who owns a user database (including the default `app` role created by `bootstrap.initdb`) could shadow `current_database()` and trigger the full escalation chain against a stock CNPG deployment on the first scrape after the shadow was planted.\n\n#### Combined impact\n\nThe chain yields privilege escalation from a low-privileged database role (e.g. the default `app` role) to PostgreSQL superuser, plus arbitrary OS command execution as the `postgres` user inside the primary pod, all within one scrape interval. A web application SQL injection vulnerability in an app backed by a CNPG cluster is therefore sufficient to pivot to database-pod RCE.\n\n#### Who is impacted\n\n- All deployments on any supported release with default monitoring enabled are affected by Path 2.\n- All deployments on any supported release that use custom metric queries containing unqualified catalog references are affected by Path 1.\n- Multi-tenant platforms that allow customers to supply or influence custom metric query bodies are at the highest risk for Path 1.\n\n### Patches\n\nThree separate patches address the vulnerability.\n\n#### Patch 1: PR #10576 \"schema-qualify catalog references in default monitoring queries and documentation samples\"\n\nSchema-qualifies all unqualified `pg_catalog` function and view references in the shipped `default-monitoring.yaml` and in documentation examples. This closes Path 2 in operator-shipped configuration and removes the unqualified-identifier attack surface from all operator-shipped metric queries. Operators who clone or copy `default-monitoring.yaml` into custom monitoring `ConfigMap`s, or have copy-pasted unqualified queries elsewhere, must re-qualify those queries themselves.\n\nBackported to all currently supported releases:\n\n- **v1.29.x** (x \u2265 1)\n- **v1.28.x** (x \u2265 3)\n\n#### Patch 2: \"dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping\"\n\nIntroduces a dedicated `cnpg_metrics_exporter` PostgreSQL role (granted `pg_monitor`, no superuser privileges) and maps it in `pg_ident.conf` via peer authentication on the local Unix socket, following the same pattern already used for `cnpg_pooler_pgbouncer`. The metrics exporter connects as this role instead of `postgres`, so `session_user` is never a superuser and `RESET ROLE` has no escalation effect. This eliminates the root cause entirely.\n\nDemoting the session at the SQL level (via `SET SESSION AUTHORIZATION pg_monitor`) is not sufficient: the privilege check for `SET SESSION AUTHORIZATION` is whether the *authenticated* user is a superuser, not the current `session_user`. With the connection still authenticated as `postgres`, any SQL in the session can run `RESET SESSION AUTHORIZATION` and recover the original superuser identity. This is the same recovery primitive as `RESET ROLE`, one layer up. Only changing the authenticated user closes the loop.\n\nWith this change in place, the original chain breaks at every step: `RESET ROLE` and `RESET SESSION AUTHORIZATION` cannot recover superuser, and `COPY ... TO PROGRAM` requires a privilege `pg_monitor` does not grant. As defense in depth, the monitoring transaction also prepends `pg_catalog` to the connection\u0027s `search_path`, so unqualified catalog identifiers cannot resolve to user-planted shadow objects.\n\nThis patch changes the connection identity but not how queries are evaluated. Custom metric queries within `pg_monitor`\u0027s scope (catalog reads, `pg_stat_*` views, settings) continue to work without modification. Queries that previously relied on superuser-level access (reading user-owned tables not granted to `cnpg_metrics_exporter`, or superuser-only catalogs such as `pg_authid` or `pg_subscription`) will fail and need explicit `GRANT` statements to `cnpg_metrics_exporter`.\n\nThe role is created and maintained with `PASSWORD NULL`; any password set out-of-band is cleared on the next reconcile, so the role cannot be authenticated by password regardless of operator pre-creation.\n\nFor replica clusters, upgrade the source primary cluster before any replica clusters that consume from it. The `cnpg_metrics_exporter` role is created on the source primary and replicates downstream; a replica cluster upgraded first will scrape against a missing role until the source primary upgrades or the role is created manually (see the monitoring documentation).\n\nThe patch will be backported to all currently supported releases:\n\n- **v1.29.x** (x \u2265 1)\n- **v1.28.x** (x \u2265 3)\n\n### Workarounds\n\nIf upgrading immediately is not possible:\n\n1. **Schema-qualify all identifiers in custom metric queries.** Use explicit `pg_catalog.` prefixes for all catalog functions and views (e.g. `pg_catalog.current_database()`, `pg_catalog.now()`). This is a partial mitigation: it closes the `search_path`-shadowing shape in operator- and user-supplied metric bodies, but other expression shapes (user-defined functions, operators or casts; joins or subqueries on user-owned tables and views; RLS policies on read-touched objects) remain superuser code paths until Patch 2 lands.\n\n2. **Restrict database ownership.** Ensure only fully trusted roles own user databases in scraped clusters. The exploit requires the ability to plant an object on the metrics exporter\u0027s `search_path` in a scraped database, typically by owning the database (and therefore `public` via `pg_database_owner`) or by holding `CREATE` on a schema already reachable through `search_path`.\n\n    *PG \u003c15 caveat:* `public` grants `CREATE` to `PUBLIC` by default before PostgreSQL 15, so any authenticated role in a scraped database can plant a shadow object regardless of ownership.\n\n3. **Limit the scope of `target_databases: \u0027*\u0027` queries.** Avoid `target_databases: \u0027*\u0027` unless every database in the cluster, and every role that owns one, is fully trusted. Where possible, restrict `target_databases` to specific, known-safe databases.\n\n4. **Do not expose metric query SQL to untrusted users.** Multi-tenant platforms that allow customers to supply or influence custom metric query bodies should treat this as a critical trust boundary until the architectural fix is released.\n\n### References\n\n- Fix (Patch 1): PR #10576 \"schema-qualify catalog references in default monitoring queries and documentation samples\"\n- Fix (Patch 2): \"dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping\"\n- Reported by: Mehmet Ince",
  "id": "GHSA-423p-g724-fr39",
  "modified": "2026-06-09T02:00:27Z",
  "published": "2026-05-11T15:59:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudnative-pg/cloudnative-pg/pull/10576"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudnative-pg/cloudnative-pg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.28.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.29.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CloudNativePG\u0027s metrics exporter allows privilege escalation to PostgreSQL superuser and OS RCE"
}

GHSA-427P-PPG4-CG5Q

Vulnerability from github – Published: 2025-10-03 15:31 – Updated: 2025-10-03 15:31

Details

Unity Editor 2019.1 through 6000.3 could allow remote attackers to exploit file loading and Local File Inclusion (LFI) mechanisms via a crafted local application because of an Untrusted Search Path. This could permit unauthorized manipulation of runtime resources and third-party integrations. The issue could affect applications built using Unity and deployed across Android, Windows, macOS, and Linux platforms.

Severity

8.4 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-59489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-88"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-03T14:15:45Z",
    "severity": "HIGH"
  },
  "details": "Unity Editor 2019.1 through 6000.3 could allow remote attackers to exploit file loading and Local File Inclusion (LFI) mechanisms via a crafted local application because of an Untrusted Search Path. This could permit unauthorized manipulation of runtime resources and third-party integrations. The issue could affect applications built using Unity and deployed across Android, Windows, macOS, and Linux platforms.",
  "id": "GHSA-427p-ppg4-cg5q",
  "modified": "2025-10-03T15:31:17Z",
  "published": "2025-10-03T15:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59489"
    },
    {
      "type": "WEB",
      "url": "https://flatt.tech/research/posts/arbitrary-code-execution-in-unity-runtime"
    },
    {
      "type": "WEB",
      "url": "https://unity.com/security#security-updates-and-patches"
    },
    {
      "type": "WEB",
      "url": "https://unity.com/security/sept-2025-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42WG-HM62-JCWG

Vulnerability from github – Published: 2025-06-16 15:32 – Updated: 2025-10-29 16:05

Summary

Apache Tomcat installer for Windows has an untrusted search path vulnerability

Details

Untrusted Search Path vulnerability in Apache Tomcat installer for Windows. During installation, the Tomcat installer for Windows used icacls.exe without specifying a full path.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0 through 10.1.41, from 9.0.23 through 9.0.105.

Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.

Severity

4.8 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M1"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.23"
            },
            {
              "fixed": "9.0.106"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M1"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.23"
            },
            {
              "fixed": "9.0.106"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M1"
            },
            {
              "fixed": "11.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.0"
            },
            {
              "fixed": "10.1.42"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.23"
            },
            {
              "fixed": "9.0.106"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-49124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-29T16:05:26Z",
    "nvd_published_at": "2025-06-16T15:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Untrusted Search Path vulnerability in Apache Tomcat installer for Windows. During installation, the Tomcat installer for Windows used icacls.exe without specifying a full path.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0 through 10.1.41, from 9.0.23 through 9.0.105.\n\nUsers are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.",
  "id": "GHSA-42wg-hm62-jcwg",
  "modified": "2025-10-29T16:05:26Z",
  "published": "2025-06-16T15:32:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/28726cc2e63bed68771f5eb0f65a78dc7080571823"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/c56456cda8151c9504dfb7985700824559d769a7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/e0e07812224d327a321babb554f5a5758d30cc49"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/lnow7tt2j6hb9kcpkggx32ht6o90vqzv"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.42"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11.0.8"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.106"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/06/16/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Tomcat installer for Windows has an untrusted search path vulnerability"
}

GHSA-43HQ-PCF3-M3QM

Vulnerability from github – Published: 2022-05-17 00:15 – Updated: 2022-05-17 00:15

Details

Untrusted search path vulnerability in Media Go version 3.2.0.191 and earlier allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-10891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-01T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in Media Go version 3.2.0.191 and earlier allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory.",
  "id": "GHSA-43hq-pcf3-m3qm",
  "modified": "2022-05-17T00:15:22Z",
  "published": "2022-05-17T00:15:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10891"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN08517069/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43RJ-H44P-4J25

Vulnerability from github – Published: 2024-09-10 06:30 – Updated: 2024-09-10 06:30

Details

SAP BusinessObjects Business Intelligence Platform allows a high privilege user to run client desktop applications even if some of the DLLs are not digitally signed or if the signature is broken. The attacker needs to have local access to the vulnerable system to perform DLL related tasks. This could result in a high impact on confidentiality and integrity of the application.

Severity

5.8 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-45281"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T05:15:12Z",
    "severity": "MODERATE"
  },
  "details": "SAP BusinessObjects Business Intelligence Platform allows a high privilege user to run client desktop applications even if some of the DLLs are not digitally signed or if the signature is broken. The attacker needs to have local access to the vulnerable system to perform DLL related tasks. This could result in a high impact on confidentiality and integrity of the application.",
  "id": "GHSA-43rj-h44p-4j25",
  "modified": "2024-09-10T06:30:48Z",
  "published": "2024-09-10T06:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45281"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3425287"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43WV-9CR7-P3PG

Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2022-06-03 00:00

Details

DLL Injection Vulnerability in McAfee Agent (MA) for Windows prior to 5.6.6 allows local users to execute arbitrary code via careful placement of a malicious DLL.

Severity

6.7 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-7315"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-10T10:15:00Z",
    "severity": "MODERATE"
  },
  "details": "DLL Injection Vulnerability in McAfee Agent (MA) for Windows prior to 5.6.6 allows local users to execute arbitrary code via careful placement of a malicious DLL.",
  "id": "GHSA-43wv-9cr7-p3pg",
  "modified": "2022-06-03T00:00:34Z",
  "published": "2022-05-24T17:27:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7315"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10325"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-45FW-QRX2-RJ7M

Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23

Details

In Python 3.8.4, sys.path restrictions specified in a python38._pth file are ignored, allowing code to be loaded from arbitrary locations. The ._pth file (e.g., the python._pth file) is not affected.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-15801"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-17T03:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Python 3.8.4, sys.path restrictions specified in a python38._pth file are ignored, allowing code to be loaded from arbitrary locations. The \u003cexecutable-name\u003e._pth file (e.g., the python._pth file) is not affected.",
  "id": "GHSA-45fw-qrx2-rj7m",
  "modified": "2022-05-24T17:23:51Z",
  "published": "2022-05-24T17:23:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15801"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/pull/21495"
    },
    {
      "type": "WEB",
      "url": "https://bugs.python.org/issue41304"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200731-0003"
    }
  ],
  "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-45WP-5CWW-89VW

Vulnerability from github – Published: 2022-05-17 01:17 – Updated: 2022-05-17 01:17

Details

Multiple untrusted search path vulnerabilities in the installer in Synology Cloud Station Backup before 4.2.5-4396 on Windows allow local attackers to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) shfolder.dll, (2) ntmarta.dll, (3) secur32.dll or (4) dwmapi.dll file in the current working directory.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-11157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-30T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple untrusted search path vulnerabilities in the installer in Synology Cloud Station Backup before 4.2.5-4396 on Windows allow local attackers to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) shfolder.dll, (2) ntmarta.dll, (3) secur32.dll or (4) dwmapi.dll file in the current working directory.",
  "id": "GHSA-45wp-5cww-89vw",
  "modified": "2022-05-17T01:17:21Z",
  "published": "2022-05-17T01:17:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11157"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/support/security/Synology_SA_17_50_Cloud_Station_Backup"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation

Architecture and Design Implementation

Strategy: Attack Surface Reduction

Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.

Mitigation

Implementation

When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.

Mitigation

Implementation

Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.

Mitigation

Implementation

Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.

Mitigation

Implementation

Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.

CAPEC-38: Leveraging/Manipulating Configuration File Search Paths

This pattern of attack sees an adversary load a malicious resource into a program's standard path so that when a known command is executed then the system instead executes the malicious component. The adversary can either modify the search path a program uses, like a PATH variable or classpath, or they can manipulate resources on the path to point to their malicious components. J2EE applications and other component based applications that are built from multiple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker.

← Back to the CWE list

CWE-426

Untrusted Search Path

Impact

Path 1: custom metric queries with unqualified identifiers (all supported releases)

Path 2: stock default-monitoring.yaml (all supported releases, no custom metrics required)

Combined impact

Who is impacted

Patches

Patch 1: PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples"

Patch 2: "dedicated cnpg_metrics_exporter role with pg_ident.conf peer mapping"

Workarounds

References

Mitigation

Mitigation

Mitigation

Mitigation

Mitigation

CAPEC-38: Leveraging/Manipulating Configuration File Search Paths

Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required)

Patch 2: "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping"