CWE-669

{
  "affected": [],
  "aliases": [
    "CVE-2018-17791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-21T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Newgen OmniFlow Intelligent Business Process Suite (iBPS) 7.0 has an \"improper server side validation\" vulnerability where client-side validations are tampered, and inappropriate information is stored on the server side and fetched from the server every time the user visits the D, creating business confusion. In the worst case, all available resources are consumed while processing the data, resulting in unavailability of the service to legitimate users. This occurs because non-editable parameters can be modified by manually editing a disabled form field within the developer options.",
  "id": "GHSA-jwh6-mwxg-x75j",
  "modified": "2024-04-04T01:44:23Z",
  "published": "2022-05-24T16:54:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17791"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/cve/CVE-2018-17791"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/154061/OmniDoc-7.0-Input-Validation.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-56675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-30T18:15:50Z",
    "severity": "LOW"
  },
  "details": "The EKEN video doorbell T6 BT60PLUS_MAIN_V1.0_GC1084_20230531 periodically sends debug logs to the EKEN cloud servers with sensitive information such as the Wi-Fi SSID and password.",
  "id": "GHSA-jwvx-8mrf-4v7m",
  "modified": "2025-09-30T18:30:25Z",
  "published": "2025-09-30T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56675"
    },
    {
      "type": "WEB",
      "url": "https://httpscolonforwardslashforwardslashwwwdotzoltanbalazsdotcom.com/2025/07/15/eken-wifi-leak.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siderolabs/talos"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:38:02Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA vulnerability in the Linux kernel\u0027s algif_aead subsystem (CVE-2026-31431, \"copy.fail\") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. \n\nThe exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod.\n\n### Impact\n\nAn attacker with the ability to deploy a Kubernetes pod on an affected node can:\n\n1. Corrupt the page-cache of /usr/sbin/nft in the containerd snapshot layer shared between the attacker\u0027s pod and the kube-proxy DaemonSet. Because containerd reuses XFS page-cache pages across overlayfs mounts sharing the same lower layer, the corruption is immediately visible to all containers using that image layer \u2014 including privileged system DaemonSets.\n2. Execute arbitrary code inside kube-proxy \u2014 a privileged DaemonSet running on every node with all Linux capabilities (privileged: true) and host network access \u2014 the next time kube-proxy invokes nft as part of its nftables reconciliation loop (typically within seconds).\n3. At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.\n4. Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin.\n\n### Patches\n\nUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in  Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards.\n\n### Workarounds\n\nThere are multiple workarounds available based on the situation, but we really recommend to upgrade.\n\n#### Option 1 - Change kernel arguments\n\nAdd a kernel argument with `initcall_blacklist=algif_aead_init` by upgrading Talos to the same version.\n\n\u003e Note: this either requires setting `machine.kernel.extraKernelArgs` if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See [Boot Assets](https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/boot-assets)\n\n#### Option 2 - Deploy all workload pods with a seccomp profile denying  creating `AF_ALG` socket creation\n\n`patch.yaml`\n\n```yaml\nmachine:\n  seccompProfiles:\n    - name: copy-fail-block.json\n      value:\n        defaultAction: SCMP_ACT_ALLOW\n        syscalls:\n          - names:\n              - socket\n            action: SCMP_ACT_ERRNO\n            args:\n              - index: 0\n                value: 38\n                op: SCMP_CMP_EQ\n```\n\nApply this patch to all machines in the cluster and set this for all the pod spec:\n\n```yaml\n...\nspec:\n      securityContext:\n        seccompProfile:\n          type: Localhost\n          localhostProfile: profiles/copy-fail-block.json\n```\n\n#### Option 3 - Block the syscall in runtime with a eBPF program\n\nSee [copy-fail-blocker](https://github.com/cozystack/copy-fail-blocker), this can be applied to a running system without a reboot, but it has to run before any other workloads are scheduled after a reboot. \n\n### References\n\n* https://copy.fail/\n* https://xint.io/blog/copy-fail-linux-distributions\n* https://github.com/theori-io/copy-fail-CVE-2026-31431\n* https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC",
  "id": "GHSA-m38g-vww2-mvgx",
  "modified": "2026-06-08T23:43:27Z",
  "published": "2026-05-07T02:38:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siderolabs/talos/security/advisories/GHSA-m38g-vww2-mvgx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siderolabs/talos"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theori-io/copy-fail-CVE-2026-31431"
    },
    {
      "type": "WEB",
      "url": "https://xint.io/blog/copy-fail-linux-distributions"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Talos Linux has a local privilege escalation from untrusted workloads"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "32.0.0.0rc1"
            },
            {
              "last_affected": "32.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "31.0.0.0rc1"
            },
            {
              "last_affected": "31.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "30.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-19T20:27:55Z",
    "nvd_published_at": "2026-02-18T18:24:33Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova\u0027s Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with use_cow_images=False) are affected.",
  "id": "GHSA-m4f3-qp2w-gwh6",
  "modified": "2026-02-21T06:30:15Z",
  "published": "2026-02-18T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/nova/commit/3eba22ff09c81a61750fbb4882e5f1f01a20fdf5"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/nova/+bug/2137507"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/nova"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/02/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/02/17/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenStack Nova calls qemu-img without format restrictions for resize "
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "18.0.0"
            },
            {
              "last_affected": "31.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "32.0.0"
            },
            {
              "fixed": "32.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nova"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "33.0.0"
            },
            {
              "last_affected": "33.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T18:39:21Z",
    "nvd_published_at": "2026-06-16T20:16:41Z",
    "severity": "MODERATE"
  },
  "details": "## Affects\n\n- Nova: \u003e=18.0.0 \u003c31.3.1, \u003e=32.0.0 \u003c32.2.1, \u003e=33.0.0 \u003c33.0.2\n\n\n## Description\nErichen from the Institute of Computing Technology, Chinese Academy of \nSciences reported that Nova\u0027s server create API does not strip internal \nscheduler hints. An authenticated user can bypass Placement resource \nclaims and scheduling constraint enforcement, including availability \nzone, host aggregate, and image trait restrictions. The resulting \ninstance has no Placement allocation, which can lead to compute node \nresource exhaustion and cross-tenant data persistence on NVMe devices \nafter instance deletion. Deployments running Nova 18.0.0 or later are \naffected.\n\n\n\n## Patches\n\n- https://review.opendev.org/993604 (2025.1/epoxy)\n- https://review.opendev.org/993603 (2025.2/flamingo)\n- https://review.opendev.org/993602 (2026.1/gazpacho)\n- https://review.opendev.org/993601 (2026.2/hibiscus)\n\n\n## Credits\n- Erichen from Institute of Computing Technology, Chinese Academy of \nSciences (CVE-2026-46448)",
  "id": "GHSA-mfg3-p6m3-gjgr",
  "modified": "2026-06-17T18:39:21Z",
  "published": "2026-06-16T21:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46448"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/nova/+bug/2151252"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/nova"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/993601"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/993602"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/993603"
    },
    {
      "type": "WEB",
      "url": "https://review.opendev.org/993604"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/06/16/5"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/16/5"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenStack Nova: Nova scheduler hint injection bypasses Placement resource claims and scheduling constraints"
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-15892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-120",
      "CWE-669"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-22T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in apply.cgi on D-Link DAP-1520 devices before 1.10b04Beta02. Whenever a user performs a login action from the web interface, the request values are being forwarded to the ssi binary. On the login page, the web interface restricts the password input field to a fixed length of 15 characters. The problem is that validation is being done on the client side, hence it can be bypassed. When an attacker manages to intercept the login request (POST based) and tampers with the vulnerable parameter (log_pass), to a larger length, the request will be forwarded to the webserver. This results in a stack-based buffer overflow. A few other POST variables, (transferred as part of the login request) are also vulnerable: html_response_page and log_user.",
  "id": "GHSA-mh3c-hpgm-9fqj",
  "modified": "2023-04-26T21:30:35Z",
  "published": "2022-05-24T17:24:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15892"
    },
    {
      "type": "WEB",
      "url": "https://research.loginsoft.com/bugs/classic-stack-based-buffer-overflow-in-dlink-firmware-dap-1520"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10169"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-21531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-30T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dell Unisphere for PowerMax versions prior to 9.2.1.6 contain an  Authorization Bypass Vulnerability.  A local authenticated malicious user with monitor role may exploit this vulnerability to perform unauthorized actions.",
  "id": "GHSA-mmrw-4h5c-2pv5",
  "modified": "2022-05-24T17:49:21Z",
  "published": "2022-05-24T17:49:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21531"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000184565"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.0.0-rc1"
            },
            {
              "fixed": "26.0.0-rc3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "23.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-20T17:59:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Moby is an open source container framework originally developed by Docker Inc. as Docker. It is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. As a batteries-included container runtime, Moby comes with a built-in networking implementation that enables communication between containers, and between containers and external resources.\n\nMoby\u0027s networking implementation allows for creating and using many networks, each with their own subnet and gateway. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters, and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\n\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses (typically from a non-routable [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet). The root network namespace (hereafter referred to as the \u0027host\u0027) serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\n\nContainers on an _internal_ network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\n\nIn addition to configuring the Linux kernel\u0027s various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery (looking up other containers on the network by name), and resolution of names from an upstream resolver.\n\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver (by default, the host\u0027s configured resolver). This request is made from the container network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\n\nAs a consequence of this design, containers solely attached to _internal_ network(s) will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\n\nMany systems will run a local forwarding DNS resolver, typically present on a loopback address (`127.0.0.0/8`), such as systemd-resolved or dnsmasq. Common loopback address examples include `127.0.0.1` or `127.0.0.53`. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host\u0027s configured resolver, as they cannot reach these addresses on the host loopback device.\n\nTo bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` will detect this scenario and instead forward DNS requests from the host/root network namespace. The loopback resolver will then forward the requests to its configured upstream resolvers, as expected.\n\n## Impact\n\nBecause `dockerd` will forward DNS requests to the host loopback device, bypassing the container network namespace\u0027s normal routing semantics entirely, _internal_ networks can unexpectedly forward DNS requests to an external nameserver.\n\nBy registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. For example, if the domain `evil.example` was registered, the authoritative nameserver(s) for that domain could (eventually and indirectly) receive a request for `this-is-a-secret.evil.example`.\n\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\n\n## Patches\n\nMoby releases 26.0.0-rc3, 25.0.5 (released) and 23.0.11 (to be released) are patched to prevent forwarding DNS requests from internal networks.\n\n## Workarounds\n\n-   Run containers intended to be solely attached to _internal_ networks with a custom upstream address (`--dns` argument to `docker run`, or API equivalent), which will force all upstream DNS queries to be resolved from the container network namespace.\n\n## Background\n\n- yair zak originally reported this issue to the Docker security team.\n-  PR \u003chttps://github.com/moby/moby/pull/46609\u003e was opened in public to fix this issue, as it was not originally considered to have a security implication.\n- [The official documentation](https://docs.docker.com/network/drivers/ipvlan/#:~:text=If%20the%20parent,the%20network%20completely) claims that \"the `--internal` flag that will completely isolate containers on a network from any communications external to that network,\" which necessitated this advisory and CVE.",
  "id": "GHSA-mq39-4gv4-mvpx",
  "modified": "2024-03-20T17:59:52Z",
  "published": "2024-03-20T17:59:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-mq39-4gv4-mvpx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/46609"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moby\u0027s external DNS requests from \u0027internal\u0027 networks could lead to data exfiltration"
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-1048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-669"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-21T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka \u0027Windows Print Spooler Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1070.",
  "id": "GHSA-mvfv-8xhv-cj53",
  "modified": "2022-05-24T17:18:22Z",
  "published": "2022-05-24T17:18:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1048"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1048"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158222/Windows-Print-Spooler-Privilege-Escalation.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/159217/Microsoft-Spooler-Local-Privilege-Elevation.html"
    }
  ],
  "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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.3.48"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ElrondNetwork/elrond-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-46173"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-30T16:57:11Z",
    "nvd_published_at": "2022-12-28T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nProcessing issue, nodes are affected when trying to process a cross-shard relayed transaction with a smart contract deploy transaction data. The problem was a bad correlation between the transaction caches and the processing component. If the above-mentioned transaction was sent with more gas than required, the smart contract result (SCR transaction) that should have returned the leftover gas, would have been wrongly added to a cache that the processing unit did not consider. The node stopped notarizing metachain blocks. The fix was actually to extend the SCR transaction search in all other caches if it wasn\u0027t found in the correct (expected) sharded-cache. \n\n### Patches\nAll versions \u003e= v1.3.50 will contain this patch\n\n### Workarounds\nFor the moment there is no workaround\n\n### References\nN/A\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [elrond-go main repo](https://github.com/ElrondNetwork/elrond-go)\n",
  "id": "GHSA-p228-4mrh-ww7r",
  "modified": "2022-12-30T16:57:11Z",
  "published": "2022-12-30T16:57:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ElrondNetwork/elrond-go/security/advisories/GHSA-p228-4mrh-ww7r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46173"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ElrondNetwork/elrond-go/pull/4718"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ElrondNetwork/elrond-go/commit/39d7ddcb08bb34217dab6daef7cd9d287fb8cab3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ElrondNetwork/elrond-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Elrond-GO processing: fallback search of SCRs when not found in the main cache"
}