Makawallet Red Team Exercise

INTRODUCTION#

The MakaChain team engaged Halborn to assess the MakaWallet mobile application and its supporting backend API. The original assessment used the June 2026 source archives retained in Sources and combined manual source review with targeted proof-of-concept checks.

The review examined key management and secure storage, authentication and authorization, transaction construction and signing, WalletConnect and the in-app dApp browser, backend services, chain indexers, and deployment configuration.

Repository References#

The delivery scope identifies the following repository heads, verified on September 15, 2026:

• makawallet-api (master): 7854ad71b4fbe1ec99c38f4139f8eb5c3e228819

• makapay (main): d8fe3d8f8d0ae03a8e7d2a10df395d7764c081b6

• maka-wallet (master): 57a0da5746ab7f7474587a4f0c8e4687550ee8d1

MakaPay was assessed in a separate engagement, documented in the MakaPay assessment report. Its 32 findings are separate from this report's 66 MakaWallet and API findings.

Assessment and Remediation Revisions#

The September 12, 2026 remediation review used API revision 15dc70db5e845a44b0afc4cad2e2c28337ddae15 and wallet revision 57a0da5746ab7f7474587a4f0c8e4687550ee8d1. The current API is three commits newer; the wallet revision is unchanged. The current repository references do not imply that all later changes, MakaPay submodules, production deployments, or release artifacts were assessed. Original findings describe the audit baseline; each finding's remediation state and notes describe the subsequent review and remaining issues.

Technical Profile#

Assessment baseline: This section describes the June 2026 audit baseline. Subsequent changes and remaining issues are recorded in the findings; current repository references do not extend this architectural review to later revisions.

Document Purpose#

This section describes what the MakaWallet platform is, how it is implemented, and which architectural characteristics are most relevant to the assessment. It is the implementation and architecture baseline that supports the attack-surface and threat-model sections; it is not itself a findings report.

System Overview#

MakaWallet is a multi-chain, non-custodial wallet. The mobile application is the security-critical component: it generates the recovery phrase, derives EVM and Solana keys, holds the private material on-device, and signs and broadcasts transactions. The backend provides read and convenience services (balances, transaction history, token metadata, fee estimation, an address book, push notifications, and a referral and promotions program) and indexes on-chain activity for the addresses users track.

Trust Boundaries#

The principal trust boundaries are the device boundary (on-device secret storage and the app lock), the client-to-backend boundary (the REST API and the bridge and swap gateways), the wallet-to-dApp boundary (WalletConnect and the in-app browser provider), and the backend-to-database and backend-to-RPC boundaries. Several findings arise because data crossing these boundaries (backend-supplied calldata, RPC URLs, token metadata, and chain configuration) is trusted without validation, and because the affected client-to-backend operations lacked identity and authorization checks at the audit baseline.

Attack Surface#

Assessment baseline: The attack surfaces and control weaknesses below describe the June 2026 audit baseline. Later fixes and remaining exposure are recorded in each finding's remediation state and notes.

Document Purpose#

This section enumerates the points where untrusted input enters the platform and the interfaces an attacker can reach. It frames where the findings concentrate.

Backend REST API#

Every user-scoped endpoint is reachable over the network and is keyed by an attacker-suppliable identifier (wallet_address, owner_address, or seed_hash) with no authentication. This includes balances, full transaction history, the address book, favorites, mute state, push-token registration, and the entire referral and promotions surface. Because wallet addresses are public on-chain, any internet host can target any user.

WalletConnect, dApp Browser, and Injected Provider#

The wallet exposes signing to external dApps over WalletConnect v2 and through the in-app browser, which injects a provider bound to the user's address into every page it loads. The signing prompts present little detail about what is being signed, and the browser can be opened on an attacker-chosen URL through the makawallet:// deep-link scheme. This is the primary path by which a malicious or compromised dApp reaches the signing flow.

Admin Panel and Token Registration#

The admin panel is gated by a single static password with a hardcoded default, and the unauthenticated POST /tokens/custom endpoint writes attacker-controlled token metadata into the global catalog that the admin panel later renders. Together these form an unauthenticated path to stored cross-site scripting in the admin session and to app-wide token-list poisoning.

Backend-Controlled Configuration#

RPC URLs, explorer URLs, and token metadata are supplied by the backend and consumed by the wallet with no validation or allow-listing. A malicious or tampered chain list influences RPC selection, the in-app browser, and, with no transport pinning, the data that drives signing.

Transport#

All fund-affecting network calls (the REST API, the bridge gateway, deBridge, and RPC) use plain TLS with no certificate or public-key pinning, so a network attacker who can present a trusted certificate can tamper with responses.

Device-Local Surface#

On a lost, stolen, rooted, or malware-infected device, the relevant surfaces are SecureStore (where the encryption key is stored next to the ciphertext), unencrypted AsyncStorage, the four-digit passcode (no lockout), the clipboard, and the secret-display screens (no screenshot protection).

Chain Indexers and Jobs#

The publishers ingest attacker-influenceable on-chain data and write the activities table, and the notification job delivers messages whose content is partly attacker-controlled. The unauthenticated wallet-tracking endpoint lets anyone enroll arbitrary addresses for indexing.

Threat Model#

Assessment baseline: This threat model reflects the June 2026 implementation and the assumptions used for that assessment. The scenarios below are historical baseline observations; subsequent remediation is recorded in the findings. Later repository changes and the separate MakaPay engagement are not covered by this threat model.

What the Platform Must Protect#

The central security questions are whether the platform keeps users' keys and funds safe, whether it lets only the rightful owner read and modify their data, and whether a user can understand and control what they sign.

Threat Actors Considered#

• Remote unauthenticated attacker: any internet host calling the backend API. At the audit baseline, affected API operations lacked caller identity and ownership checks.

• Malicious or compromised dApp: a site or WalletConnect peer that the user connects to or is steered to, which then requests signatures or transactions.

• Network attacker: a party positioned to intercept TLS (for example with a mis-issued or rogue certificate) or to hijack DNS, given the absence of certificate pinning.

• Malicious or compromised backend or third party: the MakaChain gateway, the deBridge API, or the provider RPC, whose responses the wallet trusts and signs.

• Attacker with device access or local malware: a thief or malware with file-system or screen-capture access to an unlocked or compromised device.

• Supply-chain attacker: a party that compromises the OTA update channel or the prebuilt native module, both of which can introduce code into the wallet process.

Key Trust Assumptions That Do Not Hold#

The platform implicitly trusts that callers of the API are who they claim to be, that backend-supplied calldata and configuration are honest, and that the transport cannot be tampered with. The original findings identify specific paths where these assumptions were not enforced, making the corresponding attack scenarios reachable at the audit baseline.

Assessment Summary#

Results Overview#

The original assessment identified 66 findings: 1 Critical, 3 High, 28 Medium, 22 Low, and 12 Informational. Of these, 48 concerned the wallet and 18 concerned the backend API. MakaPay's separate 32 findings are not included in these totals.

Original Assessment Themes#

In the assessed baseline, missing API authentication and ownership checks exposed user data and allowed unauthorized changes. Unescaped custom-token metadata created a stored-XSS path into the admin panel. Wallet findings concerned incomplete signing information, trust in external transaction data and web content, on-device key protection, seed-derived identifiers, and transport and deployment controls.

The assessment did not identify SQL injection in the reviewed backend queries or defects in the examined wallet entropy-generation and BIP39-handling paths. These observations apply only to the implementation and paths examined.

Remediation Review#

As checked on September 16, 2026, Halborn's recorded dispositions are: 18 Solved, 6 Partially Solved, 3 Not Solved, 27 Risk Accepted, 10 Acknowledged, 1 Future Release, and 1 Not Applicable. Risk acceptance, acknowledgement, and deferral do not represent implemented fixes.

For this review, Solved means the remediation addresses the principal risk of the original finding. Remaining risks and unimplemented recommendations are retained in each remediation comment; this classification does not mean every weakness has been eliminated. Seven findings were closed on this basis: HAL-001, HAL-003, HAL-008, HAL-027, HAL-052, HAL-053, and HAL-056.

The three Not Solved findings are HAL-013 (bridge transaction validation), HAL-015 (authentication at seed retrieval), and HAL-026 (admin authentication). The six Partially Solved findings are HAL-002, HAL-006, HAL-014, HAL-020, HAL-025, and HAL-029. Their remaining signing, clipboard, deep-link and promotion-integrity risks are described in the remediation notes.

The September 16 focused review checked the relevant source at API revision 7854ad71b4fbe1ec99c38f4139f8eb5c3e228819 and wallet revision 57a0da5746ab7f7474587a4f0c8e4687550ee8d1, with isolated checks using mocked external and native interfaces. It did not establish deployed configuration, device behavior, or private release-artifact equivalence, and was not a full assessment of all later changes. The WalletConnect permission fix was verified in commit 4e3b695934f53761b0db4b186415920acc48a13e. MakaPay's findings and remediation conclusions remain in its separate report.

Scope#