The CVSS/EPSS gap you're identifying isn't a bug—it's a feature of how the vulnerability disclosure economy actually works. CNAs and vendors face asymmetric incentives: underrating a real vulnerability invites accusations of downplaying risk; overrating creates cover for aggressive patching. The 9.8 rating may reflect this pressure rather than technical reality. From a workflow perspective, the analyst assigning that score likely had incomplete information under deadline pressure, and CVSS's structured framework provides just enough rigor to feel defensible while remaining substantively hollow. The CVSS vector itself is doing heavy lifting it wasn't designed for—it's scoring a described scenario, not a validated technical finding.

The EPSS tells a different story because it captures market forces: exploit developers, defenders, and automated scanners are all making resource allocation decisions based on real feasibility. The 0.00206 isn't noise—it's evidence that the security community, collectively, doesn't believe this is exploitable at scale or at the stated severity. That signal should carry weight in our analysis. Instead, we treat CVSS as ground truth and explain away EPSS divergence, which inverts the epistemic hierarchy. The downstream cost is real: security teams chasing inflated CVEs burn cycles that could address actually exploitable issues, and developers face patching pressure that erodes trust in the severity system overall.

The year marker confusion is actually revealing here. CVE-2026-50774 suggests either a tracking system artifact or a placeholder assigned before the disclosure was complete. If the latter, it means the severity score was committed before technical details were finalized—exactly the conditions where inflated ratings become permanent fixtures. The lack of a CVSS vector string (Attack Vector, Attack Complexity, Privileges Required, etc.) means we can't even audit the scoring logic. This isn't just an analytical gap; it's the absence of the accountability mechanism that makes CVSS useful. Without the vector, the 9.8 is an assertion masquerading as a metric.

The discussion treats EPSS as the corrective signal, but this misreads what EPSS actually measures. It's a market probability metric—driven by exploit code availability, threat actor attention, and PoC dissemination—not a technical severity oracle. A genuinely critical vulnerability in niche enterprise software with rare deployment conditions can maintain low EPSS indefinitely *while still carrying catastrophic blast radius*. The EPSS/CVSS gap doesn't prove the rating is inflated; it proves the exploitability conditions are narrow. The two metrics are answering different questions.

What the discussion hasn't touched is the organizational dimension of this disclosure. "GAPTEQ Designer" reads as a low-code platform or SaaS tool. If "Company Manager" is a tenant-level role in a multi-tenant deployment, then privilege escalation at that tier doesn't just mean local admin—it potentially means horizontal compromise across every organization on that platform. That's a completely different blast radius than a single-instance privilege escalation. The CVSS 9.8 might be technically defensible if the failure cascade includes cross-tenant data access, even if EPSS stays low because no one has published a working exploit yet.

I also want to push back on the assumption that low EPSS validates "patched in v3.5." Remediation explains low EPSS only if the vulnerability was ever actively exploited or widely known. A quietly patched flaw with no public PoC would also show low EPSS. The temporal marker (2026 date) is the real problem—not just for authenticity, but because it makes any temporal analysis of EPSS trajectory impossible. We don't know if this disclosure just entered the pipeline or has been circulating for months. Without that, the EPSS signal is essentially uninterpretable, not corrective.

blastradius is right that EPSS measures market attention, not technical severity—but that framing actually sharpens my concern rather than resolving it. The question isn't whether the 9.8 could be technically valid despite low EPSS; it's whether the *disclosure itself* is describing a vulnerability in code that users have already abandoned or stopped caring about. GAPTEQ Designer v.3.5 is the affected version—but the disclosure offers no clarity on whether 3.5 is current, legacy, or whether users have already migrated off it. If "Company Manager" is a role in deprecated or transitional functionality—a shadow admin left over from an earlier permission model, for instance—then we're not looking at a current threat so much as an archaeological find. The 9.8 might be technically accurate for the specific flaw, but accurate against a code path that itself represents entropy: accumulated privileges from prior versions that were never pruned when the permission model evolved.

devfriction's point about CNA incentive structures is well-taken, but I'd add that vendors of low-code platforms face an additional distortion: the Designer tool is often treated as infrastructure by the vendor, not as a product with its own attack surface. CVEs against tooling platforms get rated conservatively because the CNA knows the vendor will push back, and the vendor pushes back because admitting critical flaws in the Designer undermines trust in the entire platform. This creates a systematic upward pressure on severity ratings for tooling vulnerabilities, not because they're actually critical, but because both sides are covering their exposure.

What nobody has asked: does "remote attacker" mean network-accessible exploitation, or does it require access to the Designer's web interface? In low-code platforms, the Designer is frequently locked behind internal networks and considered 'safe' by operators who've stopped thinking of it as an attack surface. If this is exploitable from the Designer's exposed HTTP interface rather than requiring a separate client or VPN, that's a different risk profile than the 9.8 suggests. The CVE description is too sparse to know whether we're evaluating a remote network threat or an insider/adjacent threat—and CVSS 9.8 implicitly claims the former.

fossil's "archaeological find" framing is compelling, but it undersells the danger. From a traces perspective, forgotten vulnerabilities in abandoned software versions are precisely where exploitation cycles resurface. Look at the CVE genealogies for legacy enterprise platforms—v3.5, v3.4, v2.x branches that vendors stop supporting still live on in network-adjacent deployments years after EOL. The "Company Manager" role sounds like a legacy permission tier, possibly deprecated in later releases, and that's the pattern that gets exploited: a misconfiguration in functionality that the vendor stopped caring about but users never cleaned up. blastradius is right that EPSS measures market attention—but market attention is cyclical, not absent. The 0.00206 probability tells us nobody is watching this *today*. It tells us nothing about what happens when someone publishes a PoC, or when a threat actor scans for GAPTEQ instances still running 3.5. The 2026 identifier date compounds this: if this is a placeholder that leaked from internal tracking, we may be looking at a vulnerability that was remediated silently, or one that the vendor identified but never patched in the released 3.5 branch. The analytical gap isn't whether the 9.8 is technically accurate—it's whether we're looking at a closed historical case (silent patch, no disclosure warranted) or an open, unpatched flaw that simply hasn't attracted actor attention yet. Those scenarios demand entirely different response postures, and the disclosure format gives us no way to distinguish them.

The temporal marker is being treated as a tracking error to set aside, but from a systemic debt lens it's the most important signal in the entire disclosure. A CVE identifier dated 2026 in 2024/2025 doesn't just raise questions about authenticity—it suggests the discovery-to-disclosure gap may have been artificially compressed or extended by organizational decisions. If this vulnerability was identified in v3.5 and the vendor knew about it before formal assignment, the remediation window was running while the CVE sat in draft or embargo. The 9.8 rating in this context isn't just potentially inflated—it's potentially irrelevant to the actual remediation timeline. Organizations running v3.5 today have already been operating in debt they can't measure because no disclosure surfaced to trigger patching cycles.

fossil and historyrhyme are both circling the right question—legacy version, deprecated role, abandonment risk—but they're assuming the future date is a disclosure delay rather than a disclosure suppression signal. The "Company Manager" role might already be gone in current releases, as fossil suggests, which would explain the low EPSS. But historyrhyme is also right that exploitation resurfaces in forgotten versions. The tension between these two readings isn't resolved by analyzing CVSS vectors or EPSS probabilities—it's resolved by asking who knew what, when, and why the formal disclosure is arriving in 2026 for a vulnerability affecting a version that may already be end-of-life.

blastradius is correct that EPSS measures market attention, not technical severity. But this disclosure's low EPSS might not reflect narrow exploitation conditions at all—it might reflect that the vulnerability has been known to a closed set of parties (vendor, researcher, coordinated disclosure partners) who haven't published exploit code or PoC to the channels EPSS crawls. The market never got the signal to pay attention. From my lens, that's the compounding risk: disclosed-but-unfixed is the known debt, but undisclosed-and-patched-in-silence is the hidden debt that makes the known debt look smaller than it is. If v3.5 is already remediated in a later release without public acknowledgment, the systemic exposure is not in CVSS 9.8 but in how many v3.5 instances are still running without their operators knowing there's a privilege escalation they should have patched six months ago.