CWE-250

{
  "affected": [],
  "aliases": [
    "CVE-2022-38695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-01T08:15:32Z",
    "severity": "HIGH"
  },
  "details": "In BootRom, there\u0027s a possible unchecked command index. This could lead to local escalation of privilege with no additional execution privileges needed.",
  "id": "GHSA-3qp4-ph79-wf85",
  "modified": "2025-09-02T15:31:07Z",
  "published": "2025-09-02T15:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38695"
    },
    {
      "type": "WEB",
      "url": "https://www.nccgroup.com/research-blog/there-s-another-hole-in-your-soc-unisoc-rom-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-23560"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-09T16:16:38Z",
    "severity": "CRITICAL"
  },
  "details": "[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]\nXAPI can configure different users with different roles, using Role\nBased Access Control.  For more details, see:\n\n  https://docs.xenserver.com/en-us/xencenter/current-release/rbac-overview.html#rbac-roles\n\nThe pool-admin role is fully privileged.  Notably, users with this role\ncan also SSH into the host as root.\n\nThe other administrator roles are pool-operator, vm-power-admin and\nvm-admin, each of which are authorised to configure and manage various\naspects of the system.\n\nSome settings are inadequately restricted, and can be set by a lower\nprivilege of administrator than expected.\n\n * CVE-2026-23559: A vm-admin can set VBD.other_config:backend-local and\n   turn arbitrary files in dom0 into VDIs (virtual disks) and give said\n   disks to a VM they control.  This is an arbitrary read and/or modify\n   of files in dom0.\n\n * CVE-2026-23560: A vm-admin can set VM.other-config:is_system_domain\n   and mark a VM as a system domain.  System domains are ignored and\n   left running during certain other host/pool operations, and may be\n   hidden from view in tooling.\n\n * CVE-2026-23561: A vm-admin can set VM.other_config:storage_driver_domain\n   and mark a VM as the storage domain for a particular host storage\n   connection (PBD). Shutting down the VM can cause the PBD to be\n   erroneously marked as unplugged when it is not.\n\n * CVE-2026-23562: Configuration of PCI passthrough is normally\n   restricted to the pool-admin role.  However one API was missing this\n   check, allowing a vm-admin access to unintended host hardware.\n\n * CVE-2026-42486: A vm-admin can set the VM.platform:hvm_serial\n   parameter, which should be restricted to the pool-admin role, as it\n   can allow arbitrary dom0 file write.",
  "id": "GHSA-3rr8-7v6m-2h7r",
  "modified": "2026-07-09T18:31:50Z",
  "published": "2026-07-09T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23560"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xen.org/xsa/advisory-489.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-69783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T16:16:13Z",
    "severity": "HIGH"
  },
  "details": "A local attacker can bypass OpenEDR\u0027s 2.5.1.0 self-defense mechanism by renaming a malicious executable to match a trusted process name (e.g., csrss.exe, edrsvc.exe, edrcon.exe). This allows unauthorized interaction with the OpenEDR kernel driver, granting access to privileged functionality such as configuration changes, process monitoring, and IOCTL communication that should be restricted to trusted components. While this issue alone does not directly grant SYSTEM privileges, it breaks OpenEDR\u0027s trust model and enables further exploitation leading to full local privilege escalation.",
  "id": "GHSA-3wp7-xc34-h3f8",
  "modified": "2026-03-17T15:36:21Z",
  "published": "2026-03-16T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69783"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ComodoSecurity/openedr/issues/49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ComodoSecurity/openedr"
    },
    {
      "type": "WEB",
      "url": "https://scavengersecurity.com/posts/edr-as-rootkit-2"
    },
    {
      "type": "WEB",
      "url": "https://www.openedr.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-42943"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T03:15:26Z",
    "severity": "MODERATE"
  },
  "details": "SAP GUI for Windows may allow the leak of NTML hashes when specific ABAP frontend services are called with UNC paths. For a successful attack, the attacker needs developer authorization in a specific Application Server ABAP to make changes in the code, and the victim needs to execute by using SAP GUI for Windows. This could trigger automatic NTLM authentication, potentially exposing hashed credentials to an attacker. As a result, it has a high impact on the confidentiality.",
  "id": "GHSA-3wph-gw9m-m3mm",
  "modified": "2025-08-12T03:31:52Z",
  "published": "2025-08-12T03:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42943"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3627845"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-27110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T18:15:09Z",
    "severity": "HIGH"
  },
  "details": "Elevation of privilege vulnerability in GE HealthCare EchoPAC products",
  "id": "GHSA-3xj2-xvqh-gvp5",
  "modified": "2024-05-14T18:31:05Z",
  "published": "2024-05-14T18:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27110"
    },
    {
      "type": "WEB",
      "url": "https://securityupdate.gehealthcare.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-55077"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-07T19:15:29Z",
    "severity": "MODERATE"
  },
  "details": "Tyler Technologies ERP Pro 9 SaaS allows an authenticated user to escape the application and execute limited operating system commands within the remote Microsoft Windows environment with the privileges of the authenticated user. Tyler Technologies deployed hardened remote Windows environment settings to all ERP Pro 9 SaaS customer environments as of 2025-08-01.",
  "id": "GHSA-3xq8-gg3v-vxcw",
  "modified": "2025-08-07T21:31:08Z",
  "published": "2025-08-07T21:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55077"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2025/va-25-219-01.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-55077"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "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"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openkruise/kruise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.0"
            },
            {
              "fixed": "1.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openkruise/kruise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openkruise/kruise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-05T16:01:24Z",
    "nvd_published_at": "2024-01-03T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAttacker that has gain root privilege of the node that kruise-daemon run , can leverage the kruise-daemon pod to list all secrets in the entire cluster. After that, attackers can leverage the \"captured\" secrets (e.g. the kruise-manager service account token) to gain extra privilege such as pod modification. \n\n### Workarounds\nFor users that do not require imagepulljob functions, they can modify kruise-daemon-role to drop the cluster level secret get/list privilege \n\n### Patches\n\nFor users who\u0027re using v0.8.x ~ v1.2.x, please update the v1.3.1\nFor users who\u0027re using v1.3, please update the v1.3.1\nFor users who\u0027re using v1.4, please update the v1.4.1\nFor users who\u0027re using v1.5, please update the v1.5.2\n### References\nNone",
  "id": "GHSA-437m-7hj5-9mpw",
  "modified": "2024-01-05T16:01:24Z",
  "published": "2024-01-05T16:01:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openkruise/kruise/security/advisories/GHSA-437m-7hj5-9mpw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30617"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openkruise/kruise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kruise allows leveraging the kruise-daemon pod to list all secrets in the entire cluster"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-39261"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-26T13:15:10Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains IntelliJ IDEA before 2023.2 plugin for Space was requesting excessive permissions",
  "id": "GHSA-4386-c34j-3g38",
  "modified": "2024-04-04T06:21:48Z",
  "published": "2023-07-26T15:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39261"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-38691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-01T08:15:31Z",
    "severity": "HIGH"
  },
  "details": "In BootROM, there is a possible missing validation for Certificate Type 0. This could lead to local escalation of privilege with no additional execution privileges needed.",
  "id": "GHSA-48qx-3q6v-746v",
  "modified": "2025-09-02T15:31:07Z",
  "published": "2025-09-02T15:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38691"
    },
    {
      "type": "WEB",
      "url": "https://www.nccgroup.com/research-blog/there-s-another-hole-in-your-soc-unisoc-rom-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}