Request for Re-evaluation: HackerOne Reports #3098734, #3098743, Request for Re-evaluation: HackerOne Reports #3098734, #3098743, #3098943 #3098943 Researcher: Researcher: rayman_ (HackerOne) Date: Date: October 15, 2025 Reports: Reports: #3098734, #3098743, #3098943 Compensation Received: Compensation Received: $0 Purpose: Purpose: Request re-evaluation based on subsequent code changes Executive Summary Executive Summary Three vulnerability reports submitted to Coinbase on April 17, 2025 were closed on April 30, 2025 as "Informative" with no bounty payment. Seven days later, on May 7, 2025, Coinbase committed two code changes that directly addressed the reported issues. One commit was explicitly titled "Address ASan and UBSan findings," referencing the exact analysis methodology used in the closed reports. Both commits were made by the same author within a 44-minute period. This document presents factual evidence from public git history and HackerOne records, and respectfully requests re-evaluation of the report closures. Factual Timeline Factual Timeline April 17, 2025 - Reports Submitted April 17, 2025 - Reports Submitted Report #3098734 Report #3098734 (12:43 PM UTC): Integer overflow in operator+ function Report #3098743 Report #3098743 (12:54 PM UTC): Integer overflow in operator+= function Report #3098943 Report #3098943 (2:56 PM UTC): Unchecked array indexing in operator[] function All reports included AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) analysis demonstrating memory safety concerns. April 17, 2025 - Initial Triage April 17, 2025 - Initial Triage 3:13 PM UTC: Status changed to "Triaged" with comment "Creating ticket to validate the issue with engineering" 4:01 PM UTC: Severity downgraded from Critical (9.8) to None April 30, 2025 - Reports Closed April 30, 2025 - Reports Closed All three reports closed as "Informative" with identical closure language: "We do not see any way to exploit this in our protocols (if we are wrong, please let us know). However, we understand your concern in having low-level functions that can be misused by others. As such, in later releases, we will consider adding the size checks [or boundary checks] to make the low-level classes more robust." Payout: Payout: $0 for all three reports May 7, 2025 - Code Changes Committed May 7, 2025 - Code Changes Committed 6:11 AM PDT - Commit 4360c2097e506d7e51bd7a19c9a74b6344f254aa 6:11 AM PDT - Commit 4360c2097e506d7e51bd7a19c9a74b6344f254aa Title: "chore: Address ASan and UBSan findings (#18)" Author: Yi-Hsiu Chen Fixed undefined behavior and memory lifetime issues 6:55 AM PDT - Commit 032abd771b188319cd4ee8c3e7663e8602132b97 6:55 AM PDT - Commit 032abd771b188319cd4ee8c3e7663e8602132b97 Title: "chore: Add usage notes to core functions (#20)" Author: Yi-Hsiu Chen (same author) Added documentation warnings for operator[], operator+, operator+= Time between commits: Time between commits: 43 minutes, 58 seconds Evidence of Direct Correspondence Evidence of Direct Correspondence Comparison Table Comparison Table Report # Report # Function Function Issue Reported Issue Reported Coinbase Closure Statement Coinbase Closure Statement Documentation Added (May 7) Documentation Added (May 7) #3098943 operator[] No bounds checking "do not see any way to exploit this" "caller must ensure 0 ≤ index < size()" #3098734 operator+ No overflow checking "do not see any way to exploit this" "caller must ensure sum does not overflow" #3098743 operator+= No overflow checking "do not see any way to exploit this" "caller must ensure sum does not overflow" Report # Report # Function Function Issue Reported Issue Reported Coinbase Closure Statement Coinbase Closure Statement Documentation Added (May 7) Documentation Added (May 7) Correspondence rate: Correspondence rate: 3 out of 3 functions (100%) Direct Quotes from Coinbase Communications Direct Quotes from Coinbase Communications Report Closure Language (April 30, 2025) Report Closure Language (April 30, 2025) Identical language used for all three reports: "We do not see any way to exploit this in our protocols (if we are wrong, please let us know). However, we understand your concern in having low-level functions that can be misused by others. As such, in later releases, we will consider adding in later releases, we will consider adding the size checks [or boundary checks] to make the low-level classes more robust." Key language: "in later releases" - Indicates future, not immediate action "we will consider" - Indicates possibility, not commitment Commit Message (May 7, 2025) Commit Message (May 7, 2025) From commit 032abd771b188319cd4ee8c3e7663e8602132b97: "This PR adds informational comments and/or updates documentation to clarify that many core functions intentionally omit boundary and overflow checks. This design was a deliberate choice to maximize performance in critical code paths. Developers using these functions must be aware that the responsibility for input validation and preventing overflow or out-of-bounds errors lies with the calling code. While this approach benefits performance, misusing these functions without proper external checks could potentially lead to security vulnerabilities misusing these functions without proper external checks could potentially lead to security vulnerabilities if input is not carefully managed by the caller. These changes are for documentation and awareness purposes only and do not alter the functional behavior of the core functions. The goal is to prevent The goal is to prevent accidental misuse and ensure developers understand accidental misuse and ensure developers understand the intentional performance-security trade-off in these specific areas." Key language: "could potentially lead to security vulnerabilities" "prevent accidental misuse" "ensure developers understand" Code Changes Documentation Code Changes Documentation Report #3098943: operator[] Bounds Checking Report #3098943: operator[] Bounds Checking Before April 17, 2025: Before April 17, 2025: uint8_t buf_t::operator[](int index) const { return data()[index]; } uint8_t& buf_t::operator[](int index) { return data()[index]; } No documentation regarding bounds checking requirements. After May 7, 2025: After May 7, 2025: /** * @notes: * - The caller *must* ensure that 0 ≤ index < size() * - This function intentionally does not perform this check to increase performance. */ uint8_t buf_t::operator[](int index) const { return data()[index]; } /** * @notes: * - The caller *must* ensure that 0 ≤ index < size() * - This function intentionally does not perform this check to increase performance. */ uint8_t& buf_t::operator[](int index) { return data()[index]; } Report #3098734: operator+ Overflow Checking Report #3098734: operator+ Overflow Checking Before April 17, 2025: Before April 17, 2025: buf_t operator+(mem_t src1, mem_t src2) { buf_t out(src1.size + src2.size); memmove(out.data(), src1.data, src1.size); memmove(out.data() + src1.size, src2.data, src2.size); return out; } No documentation regarding overflow checking requirements. After May 7, 2025: After May 7, 2025: /** * @notes: * - The caller *must* ensure that the sum of the sizes does not overflow. * - This function intentionally does not perform this check to increase performance. */ buf_t operator+(mem_t src1, mem_t src2) { buf_t out(src1.size + src2.size); memmove(out.data(), src1.data, src1.size); memmove(out.data() + src1.size, src2.data, src2.size); return out; } Report #3098743: operator+= Overflow Checking Report #3098743: operator+= Overflow Checking Before April 17, 2025: Before April 17, 2025: buf_t& buf_t::operator+=(mem_t src) { int old_size = s; byte_ptr new_ptr = resize(old_size + src.size); memmove(new_ptr + old_size, src.data, src.size); return *this; } No documentation regarding overflow checking requirements. After May 7, 2025: After May 7, 2025: /** * @notes: * - The caller *must* ensure that the sum of the sizes does not overflow. * - This function intentionally does not perform this check to increase performance. */ buf_t& buf_t::operator+=(mem_t src) { int old_size = s; byte_ptr new_ptr = resize(old_size + src.size); memmove(new_ptr + old_size, src.data, src.size); return *this; } Open Source Library Context Open Source Library Context Closure Rationale Closure Rationale Coinbase stated in report closures: "We do not see any way to exploit this in our protocols in our protocols " Consideration Consideration The cb-mpc library is open source and published at github.com/coinbase/cb-mpc for use by external developers. As open-source maintainers, Coinbase has responsibility to either secure functions or document security risks for all users. Documentation status before reports: Documentation status before reports: No warnings existed for bounds checking requirements in operator[] No warnings existed for overflow checking requirements in operator+ and operator+= External developers using these functions had no documentation indicating special validation requirements Documentation status after May 7, 2025: Documentation status after May 7, 2025: Warnings added for all three functions Documentation states misuse "could potentially lead to security vulnerabilities" Commit message indicates goal is to "prevent accidental misuse" Impact Beyond Coinbase's Internal Protocols Impact Beyond Coinbase's Internal Protocols The researcher's reports identified undocumented security requirements affecting all users of the open-source library, not only Coinbase's internal implementation. The subsequent documentation improvements benefit the broader developer community. Statement Comparison Statement Comparison Closure Statement (April 30, 2025): Closure Statement (April 30, 2025): "We do not see any way to exploit this in our protocols" Context: Focuses on Coinbase's internal protocol implementation Commit Message (May 7, 2025): Commit Message (May 7, 2025): "could potentially lead to security vulnerabilities if input is not carefully managed" Context: Acknowledges broader security concerns for library users Analysis: Analysis: The closure focused on exploitability within Coinbase's specific implementation, while the subsequent commit acknowledges security concerns for general library usage. The researcher's reports addressed the latter context. Request for Re-evaluation Request for Re-evaluation Based on the evidence presented, I respectfully request re-evaluation of reports #3098734, #3098743, and #3098943. Basis for Request Basis for Request 1 Code changes were committed 7 days after report closure 2 Commit titled "Address ASan and UBSan findings" directly references the analysis methodology used in reports 3 Documentation warnings were added for all three reported functions with 100% correspondence 4 Coinbase's commit message acknowledges the functions "could potentially lead to security vulnerabilities" 5 Changes were implemented in a single 44-minute session, indicating coordinated response 6 As an open-source library, documentation improvements benefit all users, not only Coinbase Specific Requests Specific Requests 1. Re-evaluation of closure decisions: 1. Re-evaluation of closure decisions: Given the timeline and correspondence between reports and subsequent changes, I request reconsideration of whether these reports warrant compensation under Coinbase's bug bounty program guidelines. 2. Policy clarification: 2. Policy clarification: I would appreciate clarification on whether reports that identify undocumented security risks in open-source libraries, which subsequently lead to security documentation improvements, fall within scope for bug bounty compensation. 3. Industry practice consideration: 3. Industry practice consideration: Standard bug bounty practice at companies such as Google and Microsoft includes compensation for reports that lead to security improvements, even when not directly exploitable. I request consideration of this industry standard. 4. HackerOne mediation (if needed): 4. HackerOne mediation (if needed): If there is disagreement about the interpretation of these events, I am willing to participate in HackerOne's mediation process. Verification Verification All information in this document is verifiable through public records: Git Repository Access Git Repository Access git clone https://github.com/coinbase/cb-mpc.git cd cb-mpc Verify Commits Verify Commits # View commit addressing ASan/UBSan git show 4360c2097e506d7e51bd7a19c9a74b6344f254aa # View commit adding documentation git show 032abd771b188319cd4ee8c3e7663e8602132b97 # Verify timestamps git log --format="%h %ai %an %s" 4360c20 032abd7 Expected output: Expected output: 032abd7 2025-05-07 06:55:07 -0700 Yi-Hsiu Chen chore: Add usage notes to core functions (#20) 4360c20 2025-05-07 06:11:09 -0700 Yi-Hsiu Chen chore: Address ASan and UBSan findings (#18) HackerOne Reports HackerOne Reports Report #3098734: Integer Overflow in buf_t::operator+ Report #3098743: Integer Overflow in buf_t::operator+= Report #3098943: Unchecked Array Indexing in CB-MPC (Accessible to Coinbase and HackerOne staff through platform) Conclusion Conclusion The git commit history provides objective, verifiable evidence that Coinbase implemented security documentation improvements within one week of closing the researcher's reports. The commit explicitly referencing "ASan and UBSan findings" - the exact analysis tools used in the reports - combined with the 100% correspondence between reported issues and implemented warnings, indicates the researcher's work contributed value to the cb-mpc library's security posture. I respectfully request re-evaluation of whether these reports warrant compensation given the documented connection between the submissions and subsequent security improvements. Contact: Contact: Available via HackerOne platform Supporting Materials: Supporting Materials: Git commits 4360c20 and 032abd7 (publicly accessible) All information herein is factual and verifiable through public records. No assumptions or speculation are included. All information herein is factual and verifiable through public records. No assumptions or speculation are included.