CVE-2026-22696General

6/9 The same findings. Multiple public documents. Three different severity classifications. Here is the finding-by-finding record: QE Identity (Finding #4) — Critical. The team maintained this as Critical in the blog post. The GHSA advisory (CVE-2026-22696) publicly classifies this as Critical. TCB Status (Finding #7) — High. The team maintained this as High in the blog post. They explicitly agreed to this classification in the Telegram group after we demonstrated that their initial evaluation was conducted against the post-fix codebase rather than the code as it existed at submission. GPU Attestation (Finding #6) and SSRF (Finding #1) — both reported as High. The team accepted both as High in their own Snapshot bounty proposal, which was filed before the bounty dispute began. The blog post reclassifies both as Low. Event Log (Finding #2) and TLS Verification (Finding #5) — We reported both as High. The team disagreed with our classification, and we settled on Medium through the shared Notion document. The shared Notion document that recorded these Medium classifications is now empty. The system timestamp shows it was last edited after Feb 8. The blog post reclassifies both as Low. On the blog post's framing: + The blog frames mutually agreed-upon security vulnerabilities as a proactive move to a more secure architecture. + The team's blog post states "the responsibility for QE validation [shifts] from the application developer to the dstack infrastructure", implying developers were expected to enforce QE validation at the application layer. + No documentation, no example, no sample implementation in dstack ever told them to. + Intel’s documentation lists QE Identity and TCB evaluation as required elements of the ECDSA verification flow. + This was not a policy decision delegated to applications. It was a missing check that every downstream consumer inherited silently.