Red Team Exercise

INTRODUCTION#

Makachain engaged Halborn to conduct a Red Team Exercise against MakaPay, a cross-chain cryptocurrency payment platform that enables merchants to accept payments on multiple EVM chains (Ethereum, Polygon, BSC, Base) while managing gas fees through a single balance on the MAKA chain. The assessment targeted the production deployment at app.makapay.io and its backend infrastructure.

The platform architecture consists of:

• Convex Backend (~40,000 lines): Serverless functions handling payment processing, fee calculation, referral commissions, recovery operations, vault custody, POS terminals, and Telegram bot integration. Deployed at knowing-guineapig-268.convex.cloud.

• Next.js Application (~56,000 lines): Merchant dashboard, customer payment pages, REST API routes (/api/v1/*, /api/pos/*, /api/vault/*), admin panel, and Telegram Mini App.

• Smart Contracts (Solidity/Foundry): GasTank, PaymentWalletFactory (CREATE2), TrustedOracle — deployed across MAKA chain and payment chains.

• Agents Service (Mastra): AI-driven operational tooling with Convex admin key and GitLab write access.

Authentication is provided by Clerk (JWT-based), with the Convex backend accepting tokens via the convex audience template. The platform uses a single hot wallet (GAS_TANK_PRIVATE_KEY) to sign on-chain transactions across all supported chains for payment settlement, recovery, referral payouts, and gas-tank operations.

The engagement combined source-code review of the makapay-main repository with live dynamic testing against the production environment using Burp Suite and browser-based exploitation. All Critical and High findings were confirmed with production evidence.

The MakaPay platform contains Critical vulnerabilities that allow an anonymous attacker to drain the platform's operational hot wallet without any authentication, at near-zero cost. Three independent attack paths to treasury drain were identified and confirmed on production:

1. Unauthenticated Earnings Minting: A development utility function (seedReferralEarningsForEmail) is deployed to production as a public, unauthenticated endpoint. Any anonymous caller can insert withdrawable referral earnings into any user's account by supplying their email address. We executed this 3 times on production, successfully minting 9 earnings records with zero credentials.

2. Hot-Wallet Gas Drain: A recovery function (forceProcessWithHighGas) signs on-chain transactions with the platform hot wallet using attacker-controlled gas price parameters. It is publicly callable without authentication. An attacker can set gas to extreme values (millions of gwei) and burn the hot wallet's entire ETH/POL/BNB balance in a single call.

3. Commission Fabrication: The payment creation API accepts arbitrary fee percentages and agent markup values from the client without server-side validation. An attacker sets feeAmount: 0 (collects no on-chain fee) but feePercentage: 99.99% and agentMarkupPercentage: 99.99%. On settlement, the platform computes commissions from these stored values and pays ~90% of the stated amount from its hot wallet to the attacker's referrer account. We created 100 such payments on production — all accepted without rejection.

Beyond the treasury-drain paths, the engagement uncovered a systemic authorization failure across the Convex backend: dozens of public functions that handle sensitive data or state-changing operations perform no authentication check whatsoever. This enabled confirmed production exploitation of:

• Full payment history and customer PII (email addresses) readable by any anonymous internet user

• The entire merchant referral graph and commission rates exposed without authentication

• Telegram Mini App endpoints returning any merchant's data by userId parameter

• Alchemy webhook payment-crediting function callable directly, bypassing HMAC signature verification

Overall Security Posture: CRITICAL. The platform's on-chain fund-movement logic (CREATE2 settlement) is architecturally sound — payment wallets correctly sweep to the stored merchant address. However, the off-chain accounting, commission, and operational layers that surround it are fundamentally broken from an access-control perspective. The hot wallet is the single point of failure, and multiple confirmed paths exist to drain it.

SCOPE#

The assessment covered the following components of the MakaPay platform:

METHODOLOGY#

The engagement followed a hybrid approach combining white-box source review with black-box/grey-box dynamic testing against the live production environment.

Remediation Validation#

Following the initial assessment, a remediation review of the fixes implemented by the client was performed. Each remediation was verified through dynamic testing against the live environment, using an authenticated test merchant account and a valid API key, with responses compared against a known good control call to confirm the observed behavior. Source code was not available during this stage, so verification was based on externally observable behavior. Where a recommendation extended beyond what could be observed externally.

FINDINGS SUMMARY#

The engagement identified 4 Critical, 5 High, 9 Medium, and 10 Low/Informational findings across the MakaPay platform.

Scope#