3 ms·

Closed –> Traced –> Closed: Did a Tech Giant Panic over an HTTP/2 200 OK Bypass?

[DISCLAIMER]: This is shared strictly for educational purposes and as a case study for the security community. My goal is to discuss the logic of security response systems, not to target any individual or proprietary data. The Case: I am seeking the community's perspective on a technical disagreement. Who is at fault when a manual proof of a bypass is provided, yet the response logic remains inconsistent? The Timeline & Logic Gap: The Report: I reported a logic flaw in a payments-related sub-domain. It was initially reviewed and marked as "Triaged". The Dismissal: Shortly after, the report was marked as "Closed (Informative)". No technical explanation was provided for why the triage was reversed. The Manual Proof: I provided a manual bypass using an Admin-Token: true header, which resulted in a successful HTTP/2 200 OK response (verified in terminal logs). The Loop: Following this evidence, the report went through a "Triaged-Closed" loop. Despite the manual proof of a 200 OK status, the case remains closed without a patch. Where is the Fault? Is it the Company's fault? For dismissing a manual proof of a 200 OK bypass and relying on automated closure logic instead of verifying the vulnerability's impact. Is it the Researcher's fault? For providing evidence that contradicts the "Informative" status and expecting a technical justification for the closure. The Evidence (Screenshots): Manual Proof (HTTP/2 200 OK Bypass): https://i.ibb.co/kgMjSBBK/Whats-App-Image-2026-02-13-at-1-40-12-PM.jpg Report Status History (The Loop): https://i.ibb.co/5gsLnyJJ/Whats-App-Image-2026-02-13-at-1-43-58-PM.jpg Initial Triage Confirmation: https://i.ibb.co/K3ZCQ48/Whats-App-Image-2026-02-13-at-1-38-17-PM.jpg 48-Hour Notice Email: https://i.ibb.co/Df8GwCH0/Whats-App-Image-2026-02-13-at-1-54-37-PM.jpg Full Communication Logs: https://i.ibb.co/zTbNRFQy/Whats-App-Image-2026-02-13-at-1-38-27-PM.jpg My Question to Developers & Researchers: When a researcher proves a bypass with a 200 OK response, but the company keeps the report "Closed," is this a standard industry practice or a gap in the security response logic? Google VRP

CorporationHit 9mo ago
The core issue is an HTTP/2 Logic Bypass. Despite having security restrictions in place that should trigger a 403 or 401, the endpoint consistently returns an HTTP/2 200 OK. What's interesting is the response from the VRP: Initially Closed: Dismissed as intended behavior. Re-opened & Triaged: After I provided a more detailed proof-of-concept, it was moved to the 'Triaged' state, which usually means they acknowledge a potential issue. Closed Again: Finally closed without explaining why a restricted endpoint is leaking a 200 OK status. As a developer, this "Close-Triage-Close" loop feels like a way to avoid acknowledging a flaw in the request-handling logic. I'd love to hear if anyone else has experienced similar behavior with HTTP/2 multiplexing or header injection in this specific VRP.

CorporationHit 9mo ago

The core issue is an HTTP/2 Logic Bypass. Despite having security restrictions in place that should trigger a 403 or 401, the endpoint consistently returns an HTTP/2 200 OK. What's interesting is the response from the VRP: Initially Closed: Dismissed as intended behavior. Re-opened & Triaged: After I provided a more detailed proof-of-concept, it was moved to the 'Triaged' state, which usually means they acknowledge a potential issue. Closed Again: Finally closed without explaining why a restricted endpoint is leaking a 200 OK status. As a developer, this "Close-Triage-Close" loop feels like a way to avoid acknowledging a flaw in the request-handling logic. I'd love to hear if anyone else has experienced similar behavior with HTTP/2 multiplexing or header injection in this specific VRP.