Common Weakness Enumeration

CWE-670

Allowed-with-Review

Always-Incorrect Control Flow Implementation

Abstraction: Class · Status: Draft

The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.

228 vulnerabilities reference this CWE, most recent first.

GHSA-49M5-2838-Q2RV

Vulnerability from github – Published: 2022-05-17 19:57 – Updated: 2024-09-06 19:52
VLAI
Summary
Ansible unsafe evaluation of some strings
Details

Ansible prior to 1.5.4 mishandles the evaluation of some strings.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2014-2686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-07T20:34:37Z",
    "nvd_published_at": "2020-01-09T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Ansible prior to 1.5.4 mishandles the evaluation of some strings.",
  "id": "GHSA-49m5-2838-q2rv",
  "modified": "2024-09-06T19:52:27Z",
  "published": "2022-05-17T19:57:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/998793fd0ab55705d57527a38cee5e83f535974c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ansible/ansible"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/ansible/PYSEC-2020-198.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!searchin/ansible-project/1.5.4/ansible-project/MUQxiKwSQDc/id6aVaawVboJ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ansible unsafe evaluation of some strings"
}

GHSA-4CHV-4C6W-W254

Vulnerability from github – Published: 2026-02-17 21:29 – Updated: 2026-02-19 21:56
VLAI
Summary
The rs-soroban-sdk #[contractimpl] macro calls inherent function instead of trait function when names collide
Details

Impact

The #[contractimpl] macro contains a bug in how it wires up function calls.

In Rust, you can define functions on a type in two ways: - Directly on the type as an inherent function: rust impl MyContract { fn value() { ... } } - Through a trait rust impl Trait for MyContract { fn value() { ... } }

These are two separate functions that happen to share the same name. Rust has rules for which one gets called. When you write MyContract::value(), Rust always picks the one defined directly on the type, not the trait version.

The bug is that #[contractimpl] generates code that uses MyContract::value() style calls even when it's processing the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function.

This means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously: 1. A impl Trait for MyContract block is defined with one or more functions, with #[contractimpl] applied. 2. A impl MyContract block is defined with one or more identically named functions, without #[contractimpl] applied.

If the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function.

For example:

#[contract]
pub struct Contract;

impl Contract {
    /// Inherent function — returns 1.
    /// Bug: The macro-generated WASM export is wired up to call this function.
    pub fn value() -> u32 {
        1
    }
}

pub trait Trait {
    fn value(env: Env) -> u32;
}

#[contractimpl]
impl Trait for MyContract {
    /// Trait implementation — returns 2.
    /// Fix: The macro-generated WASM export should call this function.
    fn value() -> u32 {
        2
    }
}

Patches

The problem is patched in soroban-sdk-macros version 25.1.1. The fix changes the generated call from <Type>::func() to <Type as Trait>::func() when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists.

Users should upgrade to soroban-sdk-macros >= 25.1.1 and recompile their contracts.

Workarounds

If upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.1.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk-macros"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 23.5.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk-macros"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 22.0.9"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "soroban-sdk-macros"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "22.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T21:29:05Z",
    "nvd_published_at": "2026-02-19T20:25:43Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe `#[contractimpl]` macro contains a bug in how it wires up function calls.\n\nIn Rust, you can define functions on a type in two ways:\n- Directly on the type as an inherent function:\n  ```rust\n  impl MyContract {\n      fn value() { ... }\n  }\n  ```\n- Through a trait\n  ```rust\n  impl Trait for MyContract {\n      fn value() { ... }\n  }\n  ```\n\nThese are two separate functions that happen to share the same name. Rust has rules for which one gets called. When you write `MyContract::value()`, Rust always picks the one defined directly on the type, not the trait version.\n\nThe bug is that `#[contractimpl]` generates code that uses `MyContract::value()` style calls even when it\u0027s processing the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function.\n\nThis means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously:\n1. A `impl Trait for MyContract` block is defined with one or more functions, with `#[contractimpl]` applied.\n2. A `impl MyContract` block is defined with one or more identically named functions, without `#[contractimpl]` applied.\n\nIf the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function.\n\nFor example:\n\n```rust\n#[contract]\npub struct Contract;\n\nimpl Contract {\n    /// Inherent function \u2014 returns 1.\n    /// Bug: The macro-generated WASM export is wired up to call this function.\n    pub fn value() -\u003e u32 {\n        1\n    }\n}\n\npub trait Trait {\n    fn value(env: Env) -\u003e u32;\n}\n\n#[contractimpl]\nimpl Trait for MyContract {\n    /// Trait implementation \u2014 returns 2.\n    /// Fix: The macro-generated WASM export should call this function.\n    fn value() -\u003e u32 {\n        2\n    }\n}\n```\n\n### Patches\n\nThe problem is patched in `soroban-sdk-macros` version **25.1.1**. The fix changes the generated call from `\u003cType\u003e::func()` to `\u003cType as Trait\u003e::func()` when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists.\n\nUsers should upgrade to `soroban-sdk-macros` **\u003e= 25.1.1** and recompile their contracts.\n\n### Workarounds\n\nIf upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.",
  "id": "GHSA-4chv-4c6w-w254",
  "modified": "2026-02-19T21:56:47Z",
  "published": "2026-02-17T21:29:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/security/advisories/GHSA-4chv-4c6w-w254"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26267"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/pull/1729"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/pull/1730"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/pull/1731"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stellar/rs-soroban-sdk/commit/e92a3933e5f92dc09da3c740cf6a360d55709a2b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stellar/rs-soroban-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "The rs-soroban-sdk #[contractimpl] macro calls inherent function instead of trait function when names collide"
}

GHSA-4G58-P6WM-2VF3

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

In updateCapabilities of ConnectivityService.java, there is a possible incorrect network state determination due to a logic error in the code. This could lead to biasing of networking tasks to occur on non-VPN networks, which could lead to remote information disclosure, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-179053823

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-0517"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-21T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "In updateCapabilities of ConnectivityService.java, there is a possible incorrect network state determination due to a logic error in the code. This could lead to biasing of networking tasks to occur on non-VPN networks, which could lead to remote information disclosure, with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-179053823",
  "id": "GHSA-4g58-p6wm-2vf3",
  "modified": "2022-05-24T19:05:44Z",
  "published": "2022-05-24T19:05:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0517"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2021-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4HG4-9MF5-WXXQ

Vulnerability from github – Published: 2023-09-04 16:39 – Updated: 2026-09-17 19:24
VLAI
Summary
incorrect order of evaluation of side effects for some builtins
Details

Impact

The order of evaluation of the arguments of the builtin functions uint256_addmod, uint256_mulmod, ecadd and ecmul does not follow source order. • For uint256_addmod(a,b,c) and uint256_mulmod(a,b,c), the order is c,a,b. • For ecadd(a,b) and ecmul(a,b), the order is b,a.

Note that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on.

Patches

https://github.com/vyperlang/vyper/pull/3583

Workarounds

When using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-41052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-04T16:39:49Z",
    "nvd_published_at": "2023-09-04T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe order of evaluation of the arguments of the builtin functions `uint256_addmod`, `uint256_mulmod`, `ecadd` and `ecmul` does not follow source order.\n\u2022 For `uint256_addmod(a,b,c)` and `uint256_mulmod(a,b,c)`, the order is `c,a,b`.\n\u2022 For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`.\n\nNote that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. \n\n### Patches\nhttps://github.com/vyperlang/vyper/pull/3583\n\n### Workarounds\nWhen using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects.",
  "id": "GHSA-4hg4-9mf5-wxxq",
  "modified": "2026-09-17T19:24:13Z",
  "published": "2023-09-04T16:39:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-4hg4-9mf5-wxxq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41052"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/3583"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/78fa8dd8f91ba0cb26277eeffb585c68c83e7daa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-168.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "incorrect order of evaluation of side effects for some builtins"
}

GHSA-4V9Q-CGPW-CF38

Vulnerability from github – Published: 2022-06-06 21:23 – Updated: 2024-11-19 16:17
VLAI
Summary
Multiple evaluation of contract address in call in vyper
Details

Impact

when a calling an external contract with no return value, the contract address could be evaluated twice. this is usually only an efficiency problem, but if evaluation of the contract address has side effects, it could result in double evaluation of the side effects.

in the following example, Foo(msg.sender).bar() is the contract address for the following call (to .foo()), and could get evaluated twice

interface Foo:
    def foo(): nonpayable
    def bar() -> address: nonpayable

@external
def do_stuff():
    Foo(Foo(msg.sender).bar()).foo()

Patches

6b4d8ff185de071252feaa1c319712b2d6577f8d

Workarounds

assign contract addresses to variables. the above example would change to

@external
def do_stuff():
    t: Foo = Foo(msg.sender).bar()
    t.foo()

References

For more information

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-06T21:23:58Z",
    "nvd_published_at": "2022-06-09T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nwhen a calling an external contract with no return value, the contract address could be evaluated twice. this is usually only an efficiency problem, but if evaluation of the contract address has side effects, it could result in double evaluation of the side effects.\n\nin the following example, `Foo(msg.sender).bar()` is the contract address for the following call (to `.foo()`), and could get evaluated twice\n\n```vyper\ninterface Foo:\n    def foo(): nonpayable\n    def bar() -\u003e address: nonpayable\n\n@external\ndef do_stuff():\n    Foo(Foo(msg.sender).bar()).foo()\n```\n\n### Patches\n6b4d8ff185de071252feaa1c319712b2d6577f8d\n\n### Workarounds\nassign contract addresses to variables. the above example would change to\n```vyper\n@external\ndef do_stuff():\n    t: Foo = Foo(msg.sender).bar()\n    t.foo()\n```\n\n### References\n\n### For more information\n",
  "id": "GHSA-4v9q-cgpw-cf38",
  "modified": "2024-11-19T16:17:52Z",
  "published": "2022-06-06T21:23:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-4v9q-cgpw-cf38"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29255"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/6b4d8ff185de071252feaa1c319712b2d6577f8d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2022-43053.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Multiple evaluation of contract address in call in vyper"
}

GHSA-4VC8-PG5C-VG4X

Vulnerability from github – Published: 2024-06-12 19:41 – Updated: 2024-12-20 17:49
VLAI
Summary
Keycloak's improper input validation allows using email as username
Details

Keycloak allows the use of email as a username and doesn't check that an account with this email already exists. That could lead to the unability to reset/login with email for the user. This is caused by usernames being evaluated before emails.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-12T19:41:05Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "Keycloak allows the use of email as a username and doesn\u0027t check that an account with this email already exists. That could lead to the unability to reset/login with email for the user. This is caused by usernames being evaluated before emails.",
  "id": "GHSA-4vc8-pg5c-vg4x",
  "modified": "2024-12-20T17:49:09Z",
  "published": "2024-06-12T19:41:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-4vc8-pg5c-vg4x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3754"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/f9708037383aa98741e4850447de64dc4a0d4b4e"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3754"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1999196"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak\u0027s improper input validation allows using email as username"
}

GHSA-4WVX-XQJP-P7G6

Vulnerability from github – Published: 2026-09-29 15:31 – Updated: 2026-10-02 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Check write tracking in all address spaces

kvm_gfn_is_write_tracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other.

Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and eventually triggering the BUG in pte_list_remove().

[invert direction of the conditional. - Paolo]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-98164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T13:17:53Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/mmu: Check write tracking in all address spaces\n\nkvm_gfn_is_write_tracked() checks only the supplied memslot, but page\ntracking is per-address-space and shadow pages are shared across all\naddress spaces.  With SMM, a GFN can therefore be write-tracked in one\naddress space and appear untracked through the other.\n\nCheck the supplied slot first, then the slot for the other address space.\nThis ensures all callers honor write tracking regardless of the active\naddress space.  In particular, it prevents mmu_try_to_unsync_pages() from\nmarking an upper-level shadow page unsync and eventually triggering the\nBUG in pte_list_remove().\n\n[invert direction of the conditional. - Paolo]",
  "id": "GHSA-4wvx-xqjp-p7g6",
  "modified": "2026-10-02T21:31:57Z",
  "published": "2026-09-29T15:31:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98164"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/09aa68552d2542cc6c23edd1568ac265dc5d886f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0f38453cdb2e17566ccb7c0f3dabd5bd21caca26"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/429b6f43b4d8c98988fdca99e02dc156134e3d77"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c0a9bd5fca0b5f2dea32b0fc31350e71e8648112"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8636c8f9f95d0fd1e2f6f1cad0d5757aa6f212a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec8fcaf354c1cbb36755d48e9f5a00c9591349e5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4WWW-5P9H-95MH

Vulnerability from github – Published: 2025-04-15 03:30 – Updated: 2025-04-28 14:27
VLAI
Summary
http-proxy-middleware can call writeBody twice because "else if" is not used
Details

In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-proxy-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "2.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-proxy-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32996"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-16T15:23:58Z",
    "nvd_published_at": "2025-04-15T03:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because \"else if\" is not used.",
  "id": "GHSA-4www-5p9h-95mh",
  "modified": "2025-04-28T14:27:14Z",
  "published": "2025-04-15T03:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32996"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/pull/1089"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/commit/020976044d113fc0bcbbaf995e91d05e2829a145"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chimurai/http-proxy-middleware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/releases/tag/v2.0.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/releases/tag/v3.0.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "http-proxy-middleware can call writeBody twice because \"else if\" is not used"
}

GHSA-52QP-GWWH-QRG4

Vulnerability from github – Published: 2021-06-21 17:10 – Updated: 2021-06-16 20:15
VLAI
Summary
Missing Handler in @scandipwa/magento-scripts
Details

Impact

After changing the function from synchronous to asynchronous there wasn't implemented handler in the start, stop, exec and logs commands, effectively making them unusable.

Patches

Version 1.5.3 contains patches for the problems described above.

Workarounds

Upgrade to patched or latest (recommended) version npm i @scandipwa/magento-scripts@1.5.3 or npm i @scandipwa/magento-scripts@latest.

References

New releases always available here: https://github.com/scandipwa/create-magento-app/releases

For more information

If you have any questions or comments about this advisory: * Open an issue in create-magento-app

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@scandipwa/magento-scripts"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.1"
            },
            {
              "fixed": "1.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-16T20:15:07Z",
    "nvd_published_at": "2021-06-14T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAfter changing the function from synchronous to asynchronous there wasn\u0027t implemented handler in the [start](https://docs.create-magento-app.com/getting-started/available-commands/start), [stop](https://docs.create-magento-app.com/getting-started/available-commands/stop), [exec](https://docs.create-magento-app.com/getting-started/available-commands/exec) and [logs](https://docs.create-magento-app.com/getting-started/available-commands/logs) commands, effectively making them unusable.\n\n### Patches\n[Version 1.5.3](https://github.com/scandipwa/create-magento-app/releases/tag/%40scandipwa%2Fmagento-scripts%401.5.3) contains patches for the problems described above.\n\n### Workarounds\nUpgrade to patched or latest (recommended) version `npm i @scandipwa/magento-scripts@1.5.3` or `npm i @scandipwa/magento-scripts@latest`.\n\n### References\nNew releases always available here: https://github.com/scandipwa/create-magento-app/releases\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [create-magento-app](https://github.com/scandipwa/create-magento-app/issues)\n",
  "id": "GHSA-52qp-gwwh-qrg4",
  "modified": "2021-06-16T20:15:07Z",
  "published": "2021-06-21T17:10:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/scandipwa/create-magento-app/security/advisories/GHSA-52qp-gwwh-qrg4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32684"
    },
    {
      "type": "WEB",
      "url": "https://github.com/scandipwa/create-magento-app/commit/89115db7031e181eb8fb4ec2822bc6cab88e7071"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing Handler in @scandipwa/magento-scripts"
}

GHSA-53JR-W5F7-RV64

Vulnerability from github – Published: 2026-09-17 15:32 – Updated: 2026-09-17 15:32
VLAI
Details

In the MISP sachertortephp library, the Xml::build() static method in lib/Cake/Utility/Xml.php contains a logic error in the conditional that gates network-based XML fetching. The original condition was written as: $options['readFile'] && strpos($input, 'http://') === 0 || strpos($input, 'https://') === 0. Because PHP's && operator has higher precedence than ||, the expression is evaluated as ($options['readFile'] && strpos($input, 'http://') === 0) || strpos($input, 'https://') === 0. As a result, when a caller explicitly sets the readFile option to false to disable file and URL reading, an input string beginning with https:// still satisfies the condition and triggers a network fetch via HttpSocket (configured to follow up to 10 redirects). The http:// branch is correctly gated by the readFile flag, but the https:// branch is not. An attacker who can influence the $input parameter passed to Xml::build() can therefore force the application to issue an outbound HTTPS request to an attacker-controlled or internal URL, even though the caller intended to suppress all remote reads. The fetched response is parsed as XML and may be returned to the caller, enabling information disclosure from internal services or external targets. This constitutes a Server-Side Request Forgery (SSRF) weakness with an information-disclosure impact. The vulnerability requires that the code path in Xml::build() be reachable with attacker-controlled input and that the readFile option be set to false (or the caller expects it to be false).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-92932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T13:17:01Z",
    "severity": "MODERATE"
  },
  "details": "In the MISP sachertortephp library, the Xml::build() static method in lib/Cake/Utility/Xml.php contains a logic error in the conditional that gates network-based XML fetching. The original condition was written as: $options[\u0027readFile\u0027] \u0026\u0026 strpos($input, \u0027http://\u0027) === 0 || strpos($input, \u0027https://\u0027) === 0. Because PHP\u0027s \u0026\u0026 operator has higher precedence than ||, the expression is evaluated as ($options[\u0027readFile\u0027] \u0026\u0026 strpos($input, \u0027http://\u0027) === 0) || strpos($input, \u0027https://\u0027) === 0. As a result, when a caller explicitly sets the readFile option to false to disable file and URL reading, an input string beginning with https:// still satisfies the condition and triggers a network fetch via HttpSocket (configured to follow up to 10 redirects). The http:// branch is correctly gated by the readFile flag, but the https:// branch is not. An attacker who can influence the $input parameter passed to Xml::build() can therefore force the application to issue an outbound HTTPS request to an attacker-controlled or internal URL, even though the caller intended to suppress all remote reads. The fetched response is parsed as XML and may be returned to the caller, enabling information disclosure from internal services or external targets. This constitutes a Server-Side Request Forgery (SSRF) weakness with an information-disclosure impact. The vulnerability requires that the code path in Xml::build() be reachable with attacker-controlled input and that the readFile option be set to false (or the caller expects it to be false).",
  "id": "GHSA-53jr-w5f7-rv64",
  "modified": "2026-09-17T15:32:12Z",
  "published": "2026-09-17T15:32:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/sachertortephp/commit/1c2da20cbe3f1e2a91458fe9a017823b7273fdac"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/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:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.