InFlux Technologies - Account Abstraction Schnorr Signatures SDK - InFlux Technologies


Prepared by:

Halborn Logo

HALBORN

Last Updated 11/14/2025

Date of Engagement: January 2nd, 2025 - January 14th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

10

Critical

0

High

1

Medium

6

Low

2

Informational

1


1. undefined

2. Introduction

InFlux Technologies engaged Halborn to conduct a security assessment on their web application beginning on 01/02/2025 and ending on 01/15/2025. The security assessment was scoped to the source code files provided to the Halborn team.

3. Assessment Summary

The team at Halborn was provided one week and a half for the engagement and assigned a full-time security engineer to verify the security of the scoped source code application files. The security engineer is a blockchain and smart contract security expert with advanced penetration testing, smart contract hacking, and deep knowledge of multiple blockchain protocols.

The security assessment identified multiple critical areas requiring attention in the analyzed codebase, involving several issues and misconfigurations that the InFlux Technologies should address to enhance the application's security.

The lack of proper validation for external calls raised concerns about unchecked interactions with third-party contracts, potentially leading to unintended execution of malicious code.

Several medium-severity issues were also observed. The use of predictable salts during contract deployments could expose the system to collision attacks, jeopardizing address uniqueness. Additionally, the default hash function was not clearly specified, which could create inconsistencies or weaken the cryptographic integrity of the system. Sensitive information, including private keys, was potentially being stored within environment variables without sufficient protection, amplifying the risk of unauthorized access. The codebase also relied on third-party dependencies with known vulnerabilities, potentially exposing the entire project to inherited security flaws. Moreover, hardcoded transaction cost parameters may limit flexibility and could be exploited if not carefully controlled.

Furthermore, the absence of public key validation could allow unauthorized entities to submit invalid keys, increasing the likelihood of malicious transactions being accepted.

Lower-risk findings included the presence of insecure methods, which, although not actively used, could become a risk if reintroduced or overlooked in future development cycles.

Some other low severity issues involved cryptographic key handling and transaction integrity. Specifically, the potential reuse of nonces in the Schnorr signature scheme presented a substantial risk of private key leakage, compromising the overall integrity of the signing process.

Finally, an informational observation was also noted regarding the library usage, emphasizing the importance of clearly documenting and maintaining external code integrations.

Overall, while the project demonstrates solid foundations in many areas, these identified issues highlight the need for a more comprehensive approach to input validation, cryptographic hygiene, and dependency management to ensure long-term security and resilience.

It is recommended to resolve all the security issues listed in the document to improve the security health of the application and its underlying infrastructure.

4. Test Approach and Methodology

Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the penetration test... While manual testing is recommended to uncover flaws in logic, process and implementation; automated testing techniques assist enhance coverage of the solution and can quickly identify flaws in it.

The following phases and associated tools were used throughout the term of the assessment:

    • Research about the scoped source code

    • Technology stack-specific vulnerabilities and public source code assessment

    • Vulnerable or outdated software

    • Exposure of any critical information

    • Application logic flaws

    • Access Handling

    • Authentication / Authorization flaws

    • Lack of validation on inputs and input handling

    • Brute force protections

    • Sensitive information disclosure

    • Source code review

5. 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

6. SCOPE

REPOSITORY
(a) Repository: account-abstraction
(b) Assessed Commit ID: 588c582
Out-of-Scope: aa-schnorr-multisig-sdk/src/generated/typechain/*, OpenZeppelin files, Third party libraries
Out-of-Scope: New features/implementations after the remediation commit IDs.

7. Assessment Summary & Findings Overview

Critical

0

High

1

Medium

6

Low

2

Informational

1

Security analysisRisk levelRemediation Date
LACK OF EXTERNAL CALLS VALIDATIONHighRisk Accepted - 02/04/2025
PREDICTABLE SALT (COLISSION ATTACK RISK)MediumNot Applicable
UNSPECIFIED DEFAULT HASH FUNCTIONMediumSolved - 02/04/2025
SENSITIVE INFORMATION IN ENV VARSMediumRisk Accepted - 02/04/2025
VULNERABLE THIRD-PARTY DEPENDENCIESMediumRisk Accepted - 02/04/2025
LACK OF KEY VALIDATIONMediumSolved - 02/04/2025
HARDCODED TRANSACTION COSTMediumNot Applicable
NOT-USED INSECURE METHODLowRisk Accepted - 02/04/2025
POTENTIAL NONCE REUSAGE (KEY LEAKAGE RISK)LowSolved - 02/04/2025
LIBRARY USAGE RECOMMENDATIONInformationalAcknowledged - 02/04/2025

8. Findings & Tech Details

8.1 LACK OF EXTERNAL CALLS VALIDATION

//

High

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

8.2 PREDICTABLE SALT (COLISSION ATTACK RISK)

//

Medium

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

8.3 UNSPECIFIED DEFAULT HASH FUNCTION

//

Medium

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

8.4 SENSITIVE INFORMATION IN ENV VARS

//

Medium

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

8.5 VULNERABLE THIRD-PARTY DEPENDENCIES

//

Medium

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

8.6 LACK OF KEY VALIDATION

//

Medium

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

8.7 HARDCODED TRANSACTION COST

//

Medium

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

8.8 NOT-USED INSECURE METHOD

//

Low

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

8.9 POTENTIAL NONCE REUSAGE (KEY LEAKAGE RISK)

//

Low

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

8.10 LIBRARY USAGE RECOMMENDATION

//

Informational

Description
Score
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:C/C:N/I:N/A:N(0.0)
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.