Solana-Canton: Bridge Penetration Test

Summary#

Introduction#

Memora engaged Halborn to conduct a security review of their systems, beginning on August 24, 2026, and concluding on September 2, 2026. The assessment was scoped to the components shared with the Halborn team by Memora. See the Scope section for additional details.

Assessment Summary#

The Halborn Team was allocated 8 business days for this engagement, during which a full-time security engineer — with expertise in blockchain, web, and API security — conducted a comprehensive audit of the in-scope components related to Memora systems. The engineer assigned held advanced proficiency in penetration testing and web application security assessments, together with an in-depth understanding of multiple blockchain protocols.

The primary objectives of this audit were to:

• Verify that each component performs its intended functions accurately and reliably.

• Identify and assess potential security issues within the application, particularly those that could impact the management and protection of digital assets.

Additional objectives included evaluating adherence to industry best practices, confirming that robust security measures were in place, and identifying opportunities to further strengthen the overall security posture.

A source code security review of the Solana Canton Bridge (the memora-halborn-main.zip file) was conducted alongside dynamic security testing of the provided URL.

The assessment identified several security and resilience issues across the in-scope code and the deployed application. The findings ranged from High to Low-severity. No Critical-severity vulnerabilities were identified.

Overall, the most relevant risks identified were associated with the enforcement of authorization on backend routes returning account balance and transaction data, the handling of credentials used to authenticate the platform's backend processes to its ledger provider, and the effectiveness of controls intended to limit abusive request volume against the API.

The most significant observations revealed that the backend-for-frontend returned a party's exact token balance, deposit history, and redemption details to any caller supplying a syntactically valid identifier, with no verification that the caller controlled the identity being queried. Related weaknesses indicated that the OAuth client secret used to authenticate the platform's backend processes to its ledger provider could have been written to application logs in cleartext under conditions outside the application's direct control — a credential carrying the same broad read authority over ledger state that the affected processes themselves relied on. These weaknesses could result in unauthorized disclosure of any user's financial balance and activity at scale, as well as compromise of the underlying credential the platform depended on to read and act on ledger data on its own behalf.

Additional findings indicated that the application's rate-limiting control could be bypassed entirely by rotating a client-supplied header on every request, that four API routes performing sensitive backend operations enforced no rate limiting of any kind, and that the in-scope web application returned none of the standard browser-enforced security response headers.

Transaction-scenario testing was also performed against the relayer, covering attempts to duplicate deposit and redemption processing, bypass replay protections, submit ledger commands outside the relayer's intended authorization, and manipulate destination or amount validation ahead of a fund-moving action. Gas- and fee-related scenarios were tested as well, covering attempts to manipulate network-fee pricing inputs, drain the fee-payer or gas-recovery accounts, and induce mispriced or unbounded fee charges. None of the scenarios tested produced an exploitable effect.

Remediation efforts should prioritize requiring proof of identity control before returning account or balance data, eliminating the logging of raw upstream responses that may carry authentication credentials, deriving rate-limiting decisions from a signal the caller cannot control rather than a client-supplied header, and applying standard security response headers uniformly across the application to reduce the platform's overall attack surface.

Scope#

• memora-halborn-main.zip:

  • Commit ID: 8ae07061c353f5a5d10e9c9571f3ad4e1fd1e7e8

• solana-bridge.validator.dev.ipblock.obsidian.systems

Scope#