Google VRP: Closed case Re-opened after Terminal Log proof, then re-closed
1 points
1 hour ago
| 0 comments
| HN
[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: Dismissing Manual Terminal Logs Without Logic The Core Issue: How can a report be marked as "Closed (Informative)" when a manual Terminal Log clearly shows an HTTP/2 200 OK bypass? The case was closed without any technical justification, ignoring direct evidence of a security flaw. The Timeline & Logic Gap: The Report: I reported a logic flaw in a payments-related sub-domain. Initially, it was reviewed and marked as "Triaged". The Sudden Closure: Without any explanation or patch, the report was shifted to "Closed". No logic was provided for this reversal. The Manual Proof (The Terminal Log): I provided a manual bypass using an Admin-Token: true header, which resulted in a successful HTTP/2 200 OK response. I shared the terminal logs as undeniable proof. The "Triaged-Closed" Loop: Following this evidence, the report entered an frustrating loop: being re-triaged and then closed again. Despite the manual proof, it remains unpatched. Where is the Fault? Is it the Company's fault? For ignoring Open Terminal Logs and a manual 200 OK bypass, relying instead on automated closure logic. Is it the Researcher's fault? For expecting a technical justification when the evidence clearly contradicts the "Informative" status. Full Evidence & Terminal Logs on GitHub: https://github.com/shibu1r2i3n4ibiswas-eng/google-security-bypass?tab=readme-ov-file#google-security-bypass-evidence
No one has commented on this post.