The CVSS 8.8 rating for CVE-2026-63046 deserves scrutiny, but not for the reason most defenders assume. The EPSS score of 0.00164 isn't evidence this vulnerability is low-risk — it's evidence of a different problem entirely.
The vulnerability lives in Apache InLong's Agent Installer ModuleManager, specifically through the ExcuteLinux.exeCmd() function. This is deployment-time tooling that bootstraps cluster configuration during installation. The argument injection flaw required two separate PRs to fix — that's the real signal hidden in the noise. Multiple execution paths accumulating command execution as a convenience layer is a code smell: it indicates the component was never treated as a security boundary, likely because developers assumed it would only ever receive pre-validated or administrator-supplied inputs.
Here's what the EPSS-CVSS gap actually measures. EPSS reflects current exploitation probability in an environment where InLong deployments are either hardened or not widely exposed. CVSS reflects theoretical severity given exploitation. Neither accounts for the supply chain vector that makes this class of vulnerability dangerous: forgotten code in long-support branches. The fix exists in 2.4.0, but versions 2.0.0 through 2.3.x are years of releases potentially still running in production with no active security ownership. That's not in the EPSS model.
More critically, there's a feedback loop operating here that the scoring doesn't capture. Each time a deployment-time vulnerability gets scored as 'high severity, low probability' and then goes unexploited, it reinforces the organizational belief that input validation in deployment tooling isn't urgent. That belief produces the next vulnerability in the same class. The two-PR fix pattern is exactly the archaeological record of decisions made when velocity won over boundary-drawing.
For defenders: if you run InLong, prioritize upgrading the Agent Installer component specifically, not just the core platform. The deployment context makes patching non-trivial — the fix wasn't a clean cherry-pick but a refactor, meaning you'll need to schedule compatibility testing. For organizations not yet deployed, ensure your deployment pipeline doesn't treat the Agent Installer as trusted infrastructure by default; architecturally, it's a chokepoint that touches cluster credentials and configuration. The risk isn't that unauthenticated attackers will exploit this directly. It's that any foothold in your deployment layer finds a command execution layer waiting to be abused.