Severity: Low | Likelihood: Medium | Impact: Low | Type: Vulnerability | Category: Peer/Validator Threats

Details

Protocol error extraction scans arbitrary error strings for the first 0x[8-hex] and maps it to a fixed dictionary, which can misclassify non-revert errors. Control flow relies on these classifications (e.g., NoChange, AlreadySubmitted, InvalidSequenceIds), leading to masked failures or incorrect DB state. Exploitable by a malicious or compromised RPC provider crafting error messages.

The function that extracts protocol errors uses a global, unanchored regex to find the first 0x[8-hex] in any error string and maps it via a fixed dictionary. NewBlockchainError applies this to all errors and exposes helper checks (IsNoChange, IsErrPayerReportAlreadySubmitted, IsErrInvalidSequenceIDs) that drive control flow in admin updaters and the payer report submitter. Because it searches anywhere in the string (and first-match wins), unrelated 0x substrings (e.g., from addresses, hashes, or arbitrary text) can be misclassified as specific protocol errors. A malicious or compromised RPC provider can craft generic error messages that include the exact 8-hex for a desired protocol error, causing the node to treat real failures as benign or to mutate DB state incorrectly (e.g., marking a report submitted with index 0, rejecting a valid report, or masking admin update failures). The issue primarily affects a single node's operational behavior; it does not propagate network-wide.

Exploitation

Scenario 1

Malicious RPC provider injects the 8-hex for PayerReportAlreadySubmitted into a generic error during report submission. The submitter interprets the error as AlreadySubmitted and marks the report as submitted with index 0, although no on-chain submission occurred. Subsequent settlement attempts fail or no-op due to the wrong index, stalling settlement for that report on this node.

Preconditions / Assumptions:

• (a) Node uses an upstream RPC provider for settlement-chain interactions
• (b) RPC provider is malicious or compromised and can craft error messages
• (c) SubmitterWorker is running with at least one report in SubmissionPending and AttestationApproved status

Scenario 2

Malicious RPC provider injects the 8-hex for InvalidSequenceIds into a generic error during report submission. The submitter interprets the error as invalid sequence IDs and marks the report as rejected in the DB, stopping further submission attempts by this node despite the report being valid.

Preconditions / Assumptions:

• (a) Node uses an upstream RPC provider for settlement-chain interactions
• (b) RPC provider is malicious or compromised and can craft error messages
• (c) SubmitterWorker is running with at least one report in SubmissionPending and AttestationApproved status

Scenario 3

Malicious RPC provider injects the 8-hex for NoChange into a generic error during an admin update (e.g., pause status or parameter update). The admin code interprets the error as a no-op and returns nil, silently masking a real failure and leaving configuration unchanged.

Preconditions / Assumptions:

• (a) Node uses an upstream RPC provider for settlement-chain interactions
• (b) RPC provider is malicious or compromised and can craft error messages
• (c) Operator initiates an admin update transaction (e.g., pause status, parameter update)

Files impacted

• pkg/blockchain/errors.go

Lines 302-322 (tryExtractProtocolError):

func tryExtractProtocolError(e error) (message, err error) {
    re, err := regexp.Compile(
        `(0x[0-9a-fA-F]{8})`,
    )
    if err != nil {
        return nil, ErrCompileRegex
    }
    matches := re.FindStringSubmatch(e.Error())
    if len(matches) != 2 {
        return nil, ErrCodeNotFound
    }
    protocolError, exists := protocolErrorsDictionary[matches[1]]
    if !exists {
        return nil, ErrCodeNotInDic
    }
    return protocolError, nil
}