CWE-386
Symbolic Name not Mapping to Correct Object
Common consequences5
- Access ControlGain Privileges or Assume Identity
The attacker can gain access to otherwise unauthorized resources.
- IntegrityConfidentialityOtherModify Application DataModify Files or DirectoriesRead Application DataRead Files or DirectoriesOther
Race conditions such as this kind may be employed to gain read or write access to resources not normally readable or writable by the user in question.
- IntegrityOtherModify Application DataOther
The resource in question, or other resources (through the corrupted one) may be changed in undesirable ways by a malicious user.
- Non-RepudiationHide Activities
If a file or other resource is written in this method, as opposed to a valid way, logging of the activity may not occur.
- Non-RepudiationIntegrityModify Files or Directories
In some cases it may be possible to delete files that a malicious user might not otherwise have access to -- such as log files.
CVEs referencing this CWE2
| CVE | Description | Severity | EPSS | Flags | Modified |
|---|---|---|---|---|---|
| CVE-2024-3852 | GetBoundName could return the wrong version of an object when JIT optimizations were applied. This vulnerability affects Firefox < 125, Firefox ESR < 115.10, and Thunderbird < 115.10. | HIGH7.5 | 0.62%p46 | 2026-06-17 | |
| CVE-2026-53081 | In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C. | HIGH7.8 | 0.12%p2 | 2026-07-23 |