CVE-2021-35942

The glibc wordexp function mishandles a crafted pattern: it used atoi where strtoul was needed, so an untrusted input to parse_param can trigger an out-of-bounds read that crashes the process or leaks arbitrary memory. This is a library-level flaw, so the real exposure is wherever an application passes attacker-influenced strings into wordexp for shell-style word expansion. Impact is denial of service or information disclosure, not code execution.

The practical risk of a glibc bug is entirely about reachability of the vulnerable function, and wordexp is not on most hot paths — it's a specific shell-expansion API that comparatively few programs feed untrusted input to. So while glibc is everywhere and the CVE fans out across a long list of Debian, NetApp, and other products that bundle it, the population of processes actually calling wordexp with attacker-controlled patterns is far smaller than the SBOM footprint suggests. That's why it's high, not critical, and why blanket panic is misplaced.

Our approach is dependency inventory tempered by exploitability triage. The bug rides in on countless SBOMs, so we'd track it as a glibc version item across affected NetApp and Debian-based assets, but we rank it by whether any exposed service on those hosts actually routes untrusted input into wordexp — most don't. For the majority this is a patch-on-cadence library update; the sharp end is narrow, and we'd resist letting a ubiquitous-component CVE consume attention out of proportion to its real reachable surface.