CVE WatchOct 8, 2026

CVE-2026-94114

Symbolic name not mapping to correct class. BCEL caches attacker-controlled classes under their self-declared names without validating th

CVSS

5.9

Medium

EPSS

0.3%

p19

KEV

—

Exploit Today

0-100

Published: Oct 6, 2026 · Last modified: Oct 8, 2026 · CWE-386

EPSS · 30d

0.3%EPSS · 30 days0.3%

2026-10-072026-10-22

Technical description

Symbolic name not mapping to correct class. BCEL caches attacker-controlled classes under their self-declared names without validating the requested name, allowing subsequent lookups and name-keyed verification results to refer to a different class. This issue affects Apache Commons BCEL: before 6.13.0. Users are recommended to upgrade to version 6.13.0, which fixes the issue.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-530817.8 HIG

7.2%

——2In 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.4d