CWE-706
Use of Incorrectly-Resolved Name or Reference
ClassIncomplete
Description
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
Hierarchy (View 1000)
Related attack patterns (CAPEC)
CAPEC-159 · CAPEC-177 · CAPEC-48 · CAPEC-641
CVEs mapped to this weakness (26)
page 2 of 2| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-35358 | Med | 0.22 | 4.4 | 0.00 | Apr 22, 2026 | The cp utility in uutils coreutils, when performing recursive copies (-R), incorrectly treats character and block device nodes as stream sources rather than preserving them. Because the implementation reads bytes into regular files at the destination instead of using mknod, device semantics are destroyed (e.g., /dev/null becomes a regular file). This behavior can lead to runtime denial of service through disk exhaustion or process hangs when reading from unbounded device nodes. | |
| CVE-2025-64750 | Med | 0.22 | 4.5 | 0.00 | Dec 2, 2025 | SingularityCE and SingularityPRO are open source container platforms. Prior to SingularityCE 4.3.5 and SingularityPRO 4.1.11 and 4.3.5, if a user relies on LSM restrictions to prevent malicious operations then, under certain circumstances, an attacker can redirect the LSM label write operation so that it is ineffective. The attacker must cause the user to run a malicious container image that redirects the mount of /proc to the destination of a shared mount, either known to be configured on the target system, or that will be specified by the user when running the container. The attacker must also control the content of the shared mount, for example through another malicious container which also binds it, or as a user with relevant permissions on the host system it is bound from. This vulnerability is fixed in SingularityCE 4.3.5 and SingularityPRO 4.1.11 and 4.3.5. | |
| CVE-2026-41402 | Med | 0.20 | 4.2 | 0.00 | Apr 28, 2026 | OpenClaw before 2026.3.31 contains a scope bypass vulnerability in webhook replay cache deduplication that allows authenticated attackers to replay messages across sibling targets using the same messageId. Attackers can exploit overly broad cache keying to bypass replay protection and deliver duplicate webhook messages to unintended targets. | |
| CVE-2026-41354 | Low | 0.17 | 3.7 | 0.00 | Apr 23, 2026 | OpenClaw before 2026.4.2 contains an insufficient scope vulnerability in Zalo webhook replay dedupe keys that allows legitimate events from different conversations or senders to collide. Attackers can exploit weak deduplication scoping to cause silent message suppression and disrupt bot workflows across chat sessions. | |
| CVE-2024-45305 | Low | 0.09 | 2.5 | 0.00 | Sep 2, 2024 | gix-path is a crate of the gitoxide project dealing with git paths and their conversions. `gix-path` executes `git` to find the path of a configuration file that belongs to the `git` installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote. In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest scope. It is believed to be very difficult to exploit this vulnerability deliberately, due to the need either to anticipate a situation in which higher-scoped configuration variables would be absent, or to arrange for this to happen. Although any operating system may be affected, users running Apple Git on macOS are much less likely to be affected. This issue has been addressed in release version 0.10.10. All users are advised to upgrade. | |
| CVE-2024-51746 | Low | 0.05 | — | 0.00 | Nov 5, 2024 | Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder. |