Non-Custodial Signer Solution - Crossmint


Prepared by:

Halborn Logo

HALBORN

Last Updated 10/21/2025

Date of Engagement: June 4th, 2025 - July 3rd, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

26

Critical

0

High

7

Medium

8

Low

6

Informational

5


1. Summary

2. Introduction

Crossmint engaged Halborn to perform a security assessment of the Signer-Frames, Crossmint-SDK, Crossbit-main, and TEE-ts repositories. The assessment scope included these repositories, although only specific paths within some were included. Halborn was granted access to the source code to conduct security testing using automated tools and manual techniques to identify, detect, and validate potential vulnerabilities within the application.

3. Assessment Summary

The Halborn team was provided a timeline for the engagement and assigned a dedicated full-time security engineer to evaluate the security of the scoped assets. This engineer is a penetration testing expert with advanced expertise in web, mobile, reconnaissance, discovery, and infrastructure penetration testing.

The security assessment uncovered multiple vulnerabilities across the repositories, varying in severity. It is strongly recommended to remediate these issues promptly to mitigate unnecessary risks.

Seven (7) high-impact issues were identified during the assessment:

    • Host MitM and Insecure Default targetOrigin. The application accepts messages from any origin, allowing a man-in-the-middle attacker to inject or steal cross-origin data and compromise user sessions.

    • Environment Parameter Tampering via URL Override. An attacker can override configuration parameters through query strings, causing the backend to operate in an unintended environment and exposing sensitive functionality.

    • Lack of Content Security Policy and Frame-Ancestor Protection. The absence of a Content Security Policy (CSP) and clickjacking protections permits hostile iframes and arbitrary script execution, potentially leading to malware injection and data theft.

    • Potential Arbitrary JavaScript Injection. Unescaped user input is reflected into HTML, enabling execution of attacker-supplied JavaScript and full compromise of the victim’s browser session.

    • Potential Authentication Bypass with ACCESS_SECRET Unset. When the shared secret is missing, the server skips verification, allowing an unauthenticated caller to impersonate any user.

    • Log Injection and Use of X-Forwarded-For. User-controlled strings are logged without sanitization, enabling attackers to forge IP addresses, insert fake entries, and mislead incident responders.

    • Excessive Exposure of Key Shares. Key fragments are exposed in the browser memory allowing a potential attacker that has compromised the computer to extract them.

Nine (9) medium-impact issues were identified during the assessment:

    • Insecure Storage of Cryptographic Keys in localStorage. Persisting keys client-side exposes them to theft via cross-site scripting (XSS) or physical device access, undermining encryption guarantees.

    • Hard-coded and Weak Secret. The use of a static, low-entropy secret enables attackers to brute-force credentials offline within minutes.

    • Potential XSS and Reverse-Tabnabbing. Unsanitized URL parameters and unguarded target="_blank" links allow script injection and phishing attacks through malicious tabs.

    • IDOR in Public Key Derivation. Predictable identifiers permit one tenant to request another tenant’s key material, resulting in horizontal privilege escalation.

    • Lack of Rate Limiting. Unlimited authentication attempts and API requests facilitate credential-stuffing attacks and resource exhaustion.

    • Attestation Response Replay Attack. Previously captured attestation tokens can be replayed to gain illegitimate trust and bypass integrity checks.

    • Potential Timing Attack on Shared-Secret Comparison. Measurable processing time differences reveal partial key bytes, enabling gradual recovery of the secret.

    • Lack of Message Origin Validation. The application processes postMessage events without verifying the sender’s domain, allowing cross-site request forgery of privileged actions.

    • Master Keys Not Explicitly Removed from Memory. Keys remain in RAM after use, so memory dumps or crash reports could expose them to attackers.

Five (5) low-impact issues were identified during the assessment:

    • Excessive Data Shared in Attestation. The attestation payload includes unnecessary user attributes, increasing privacy risks if intercepted.

    • Missing event.source Validation Allows Same-Origin Message Spoofing. Attackers executing code within the same domain can forge trusted messages and manipulate application state.

    • Weak Randomness. Non-cryptographic random generators produce predictable tokens, reducing the effort required for brute-force attacks.

    • Excessive Error Information Exposed to Caller. Detailed stack traces and configuration values leak internal implementation details that could aid attackers.

    • Sensitive Data Logged to Console. Debug logging outputs secrets to browser consoles and monitoring tools, risking inadvertent disclosure.

Five (5) informational findings were identified during the assessment:

    • Denial of Service (DoS) via Uncontrolled Memory Allocation. Very large input sizes can cause high memory consumption, potentially crashing the service under stress conditions.

    • Documentation Issues. Incomplete or outdated security documentation may lead to insecure operational practices.

    • Potential Production DoS Bug. Concurrency flaws could allow a high-rate attacker to exhaust worker threads and degrade availability.

    • Over-Privileged ACCESS_SECRET. The shared secret grants broader access than necessary, increasing the blast radius if leaked.

    • Deterministic Generation of Master Keys (Risk Accepted). Reproducible key generation facilitates development but may weaken uniqueness across deployments; this risk has been formally accepted by stakeholders.

4. Test Approach and Methodology

Halborn employed both whitebox and blackbox methodologies according to the scope, combining manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy. Manual testing is essential to uncover flaws in logic, processes, and implementation, while automated techniques enhance coverage and quickly identify infrastructure vulnerabilities. The assessment methodology included, but was not limited to, the following phases and tools:

    • Mapping Content and Functionality of APIs and SDKs

    • Application Logic Flaws

    • Access Handling

    • Authentication and Authorization Flaws

    • Rate Limiting Tests

    • Input Handling

    • Source Code Review

    • Fuzzing of All Input Parameters

    • Logic Errors

5. Out of Scope

    • In the Signer-Frames repository, all contents except /test and /src/lib are in scope.

    • In the Crossmint-SDK repository, all contents except packages/client/rn-window and packages/client/window are in scope.

    • In the Crossbit-main repository, only the contents of libraries/products/wallets/ncs and apps/crossmint-nextjs/src/api/wallets/ncs.controller.ts are in scope.


6. RISK METHODOLOGY

Halborn assesses the severity of findings using either the Common Vulnerability Scoring System (CVSS) framework or the Impact/Likelihood Risk scale, depending on the engagement. CVSS is an industry standard framework for communicating characteristics and severity of vulnerabilities in software. Details can be found in the CVSS Specification Document published by F.I.R.S.T.
Vulnerabilities or issues observed by Halborn scored on the Impact/Likelihood Risk scale are measured by the LIKELIHOOD of a security incident and the IMPACT should an incident occur. This framework works for communicating the characteristics and impacts of technology vulnerabilities. The quantitative model ensures repeatable and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the Risk scores. For every vulnerability, a risk level will be calculated on a scale of 5 to 1 with 5 being the highest likelihood or impact.
RISK SCALE - LIKELIHOOD
  • 5 - Almost certain an incident will occur.
  • 4 - High probability of an incident occurring.
  • 3 - Potential of a security incident in the long term.
  • 2 - Low probability of an incident occurring.
  • 1 - Very unlikely issue will cause an incident.
RISK SCALE - IMPACT
  • 5 - May cause devastating and unrecoverable impact or loss.
  • 4 - May cause a significant level of impact or loss.
  • 3 - May cause a partial impact or loss to many.
  • 2 - May cause temporary impact or loss.
  • 1 - May cause minimal or un-noticeable impact.
The risk level is then calculated using a sum of these two values, creating a value of 10 to 1 with 10 being the highest level of security risk.
Critical
High
Medium
Low
Informational
  • 10 - CRITICAL
  • 9 - 8 - HIGH
  • 7 - 6 - MEDIUM
  • 5 - 4 - LOW
  • 3 - 1 - VERY LOW AND INFORMATIONAL

7. SCOPE

REPOSITORIES
(a) Repository: signer-frames
(b) Assessed Commit ID: 6f01641
(c) Items in scope:
  • All repo contents but /test and /src/lib.
(a) Repository: crossbit-main
(b) Assessed Commit ID: a2efd29
(c) Items in scope:
  • libraries/products/wallets/ncs
  • apps/crossmint-nextjs/src/api/wallets/ncs.controller.ts
(a) Repository: tee-ts
(b) Assessed Commit ID: bdfbbd5
(c) Items in scope:
  • All repo contents
(a) Repository: crossmint-sdk
(b) Assessed Commit ID: 0ce33ca
(c) Items in scope:
  • packages/client/rn-window
  • packages/client/window
(a) Repository: open-signer
(b) Assessed Commit ID: 6157d5f
(c) Items in scope:
  • The audited repos were moved into this new repository in these pull requests:
  • - https://github.com/Crossmint/open-signer/pull/2
  • - https://github.com/Crossmint/open-signer/pull/3
↓ Expand ↓
Remediation Commit ID:
Out-of-Scope: New features/implementations after the remediation commit IDs.

8. Assessment Summary & Findings Overview

Critical

0

High

7

Medium

8

Low

6

Informational

5

Impact x Likelihood

HAL-01

HAL-02

HAL-03

HAL-04

HAL-05

HAL-06

HAL-07

HAL-08

HAL-09

HAL-10

HAL-11

HAL-12

HAL-13

HAL-14

HAL-15

HAL-16

HAL-17

HAL-18

HAL-19

HAL-20

HAL-21

HAL-22

HAL-23

HAL-24

HAL-25

HAL-26

Security analysisRisk levelRemediation Date
Host MitM and Insecure Default Target OriginHighRisk Accepted - 07/10/2025
Environment Parameter Tampering via URL OverrideHighSolved - 07/01/2025
Lack of Content Security Policy and Frame Ancestor ProtectionHighSolved - 07/14/2025
Potential Arbitrary JavaScript InjectionHighSolved - 07/11/2025
Potential Authentication Bypass with ACCESS_SECRET UnsetHighSolved - 07/10/2025
Log Injection & use of x-forwarded-forHighSolved - 07/11/2025
Excessive Exposure of Key SharesHighSolved - 07/10/2025
Insecure storage of cryptographic keys in localStorageMediumSolved - 07/10/2025
Hardcoded and Weak SecretMediumSolved - 07/15/2025
Potential XSS & Potential Reverse-TabnabbingMediumSolved - 07/11/2025
IDOR in Public Key DerivationMediumNot Applicable - 07/11/2025
Lack of Rate LimitingMediumSolved - 07/14/2025
Attestation Response Replay AttackMediumSolved - 07/18/2025
Potential Timing-Attack on Shared Secret ComparisonMediumSolved - 07/09/2025
Lack of Message Origin ValidationMediumRisk Accepted - 07/11/2025
Master Keys Not Explicitly Removed from MemoryLowRisk Accepted - 07/14/2025
Too Much Data Shared in AttestationLowNot Applicable - 07/11/2025
Missing event.source Validation Allows Same-Origin Message SpoofingLowSolved - 07/11/2025
Weak RandomnessLowSolved - 07/15/2025
Excessive Error Information Exposed to CallerLowSolved - 07/11/2025
Sensitive Data Logged to ConsoleLowSolved - 07/15/2025
DoS via Uncontrolled Memory AllocationInformationalSolved - 07/16/2025
Other Documentation IssuesInformationalSolved - 07/18/2025
Potential Production DoS BugInformationalFuture Release - 07/15/2025
Too Privileged ACCESS_SECRETInformationalFuture Release - 07/15/2025
Deterministic generation of Master KeysInformationalRisk Accepted - 06/24/2025

9. Findings & Tech Details

9.1 Host MitM and Insecure Default Target Origin

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N(8.1)
Recommendation
Remediation Comment
Remediation Hash

9.2 Environment Parameter Tampering via URL Override

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N(8.1)
Recommendation
Remediation Comment
Remediation Hash

9.3 Lack of Content Security Policy and Frame Ancestor Protection

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N(8.0)
Recommendation
Remediation Comment
Remediation Hash

9.4 Potential Arbitrary JavaScript Injection

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N(7.4)
Recommendation
Remediation Comment
Remediation Hash

9.5 Potential Authentication Bypass with ACCESS_SECRET Unset

//

High

Description
Proof of Concept
Score
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N(7.4)
Recommendation
Remediation Comment
Remediation Hash

9.6 Log Injection & use of x-forwarded-for

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N(7.2)
Recommendation
Remediation Comment
Remediation Hash

9.7 Excessive Exposure of Key Shares

//

High

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N(7.1)
Recommendation
Remediation Comment
Remediation Hash

9.8 Insecure storage of cryptographic keys in localStorage

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N(6.8)
Recommendation
Remediation Comment
Remediation Hash

9.9 Hardcoded and Weak Secret

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N(6.8)
Recommendation
Remediation Comment
Remediation Hash

9.10 Potential XSS & Potential Reverse-Tabnabbing

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N(6.3)
Recommendation
Remediation Comment
Remediation Hash

9.11 IDOR in Public Key Derivation

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N(5.3)
Recommendation
Remediation Comment

9.12 Lack of Rate Limiting

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L(5.3)
Recommendation
Remediation Comment
Remediation Hash

9.13 Attestation Response Replay Attack

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N(5.3)
Recommendation
Remediation Comment
Remediation Hash

9.14 Potential Timing-Attack on Shared Secret Comparison

//

Medium

Description
Proof of Concept
Score
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N(4.8)
Recommendation
Remediation Comment
Remediation Hash

9.15 Lack of Message Origin Validation

//

Medium

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N(4.2)
Recommendation
Remediation Comment

9.16 Master Keys Not Explicitly Removed from Memory

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:H/PR:H/UI:R/S:C/C:L/I:L/A:N(3.7)
Recommendation
Remediation Comment

9.17 Too Much Data Shared in Attestation

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N(3.7)
Recommendation
Remediation Comment

9.18 Missing event.source Validation Allows Same-Origin Message Spoofing

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N(3.6)
Recommendation
Remediation Comment
Remediation Hash

9.19 Weak Randomness

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N(3.6)
Recommendation
Remediation Comment
Remediation Hash

9.20 Excessive Error Information Exposed to Caller

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N(3.5)
Recommendation
Remediation Comment
Remediation Hash

9.21 Sensitive Data Logged to Console

//

Low

Description
Proof of Concept
Score
CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N(3.5)
Recommendation
Remediation Comment
Remediation Hash

9.22 DoS via Uncontrolled Memory Allocation

//

Informational

Description
Proof of Concept
Score
Impact: 1
Likelihood: 1
Recommendation
Remediation Comment
Remediation Hash

9.23 Other Documentation Issues

//

Informational

Description
Score
Impact: 1
Likelihood: 1
Recommendation
Remediation Comment

9.24 Potential Production DoS Bug

//

Informational

Description
Proof of Concept
Score
Impact: 1
Likelihood: 1
Recommendation
Remediation Comment

9.25 Too Privileged ACCESS_SECRET

//

Informational

Description
Score
Impact: 1
Likelihood: 1
Recommendation
Remediation Comment

9.26 Deterministic generation of Master Keys

//

Informational

Description
Proof of Concept
Score
Impact: 1
Likelihood: 1
Recommendation
Remediation Comment

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.