Yimmit penetration test, August 2026: 3 rounds of whitebox testing
Yimmit engaged Fidesium to run a whitebox security assessment of Yimmit Exchange. Yimmit is a centralised cryptocurrency exchange offering spot trading, swaps, staking, P2P, fiat on and off-ramps and referrals. It is built on a fork of the open-source OpenDAX stack, with Barong handling authentication and Peatio running the trading engine. The engagement included authorised live testing against the production deployment, and mainnet withdrawal flows were in scope.
Across the initial review and two re-review rounds, 95 findings were raised: 6 Critical, 14 High, 37 Medium, 31 Low and 7 informational. Seventy-five of them are recorded as resolved or remediated in the third version of the signed report, dated 12 August 2026. Five of the six Critical findings are closed. The one that remains open is a committed credential, not a defect in Yimmit’s code.
What was reviewed
| Protocol | Yimmit Exchange |
| Category | Centralised exchange (CEX) |
| Assessment dates | 4 to 28 June 2026, with re-reviews on 17 July and 4 to 12 August 2026 |
| Repository | exchange-auth (authentication and API gateway), exchange-base (trading engine), staking, exchange-castle (operator console) and frontend-ui (user trading app), all private |
| Risk score | 27 out of 100 at the August 2026 re-review, down from 71 and 36 in earlier rounds |
| Test approach | Whitebox source review, with authorised dynamic testing against the live production deployment, including mainnet withdrawal flows |
This engagement is an application and infrastructure assessment of a custodial exchange rather than a smart contract audit. Custody runs through Fireblocks, secrets through HashiCorp Vault, and identity verification through Sumsub and ShuftiPro. The internals of those providers were out of scope, and so was volumetric denial of service. The risk sat where money and identity cross service boundaries: in the deposit webhook, in the token and session layer, in how the ledger handles concurrent writes, and in credentials committed to the repositories.
The findings
Ninety-five findings were raised in total.
Critial
6
High
14
Medium
37
Low
31
Info
7
Five of the six Critical findings and thirteen of the fourteen High findings are recorded as resolved or remediated. Twenty findings remain open: one Critical, one High, ten Medium, seven Low and one informational. Four of the open findings were introduced by changes made during the engagement itself and were raised as new in the final round. Every finding carries its own status in the signed report, which is linked in full at the end of this page.
| Finding | Severity | Status |
|---|---|---|
| Unauthenticated Fireblocks deposit webhook could credit arbitrary balances | Critical | Resolved |
| Account takeover through an access-token endpoint that skipped signature verification | Critical | Resolved |
| Full user table, including password hashes and live login codes, readable by any member | Critical | Resolved |
| Hardcoded CI server admin credentials | Critical | Remediated |
| Committed inter-service signing key | Critical | Remediated |
| Committed source-control token with write access to production dependencies | Critical | Open |
Client IP spoofable through X-Forwarded-For at the gateway | High | Resolved |
| API-key replay protection effectively disabled | High | Resolved |
| Management-API signer threshold not enforced in the repository | High | Resolved |
| Missing per-action authorisation on admin endpoints | High | Resolved |
| Deposit credit not idempotent | High | Resolved |
| Unlocked P2P and escrow balance mutations | High | Resolved |
| Staking admin authorisation disabled | High | Resolved |
| Committed staking management signing key | High | Open |
| Non-atomic internal user-to-user transfer | High | Resolved |
| Authenticated SQL injection in order and trade queries | High | Resolved |
| Committed upstream exchange API credentials | High | Remediated |
| User-settable market-making flag that minted a fee surplus | High | Resolved |
| Secrets channel to Vault without certificate verification | High | Remediated |
| Spoofable client-IP header that bypassed API-key IP allowlists | High | Resolved |
What was fixed, and how it was verified
Six Critical findings: a mint, a takeover, a data leak and three secrets
The most serious finding was in the Fireblocks deposit webhook. The endpoint was public and credited a member’s balance from amounts and addresses taken straight from the request body. It had no signature check, no source restriction and no working idempotency. An attacker could mint balances with no on-chain deposit and then trade or withdraw real assets. Because the path was actively exploitable, Fidesium disclosed it to Yimmit in an urgent notice on 5 June 2026, ahead of the report. The fix verifies the Fireblocks signature over the raw request body, re-fetches the transaction from the Fireblocks API before crediting, and enforces idempotency. One edge case remains: the credited recipient is not always pinned to the verified transaction. That residual is tracked separately as a Medium finding.
The second Critical finding was an identity endpoint that decoded a caller-supplied token with signature verification switched off and then opened a session for whichever email address the token named. Live testing confirmed that a token with a garbage signature was accepted. The takeover only failed because of two unrelated bugs further along the same handler. Fixing either bug would have produced full account takeover, including of administrators. Verification is now on, the algorithm is pinned to RS256, and the endpoint no longer opens sessions.
The third was a member-facing endpoint that returned the entire user table with raw serialisation. The data included bcrypt password hashes, the live one-time codes used as the login second factor, and full personal and KYC linkage data. This was confirmed live with a standard member account. The endpoint was removed, and password hashes are now peppered with a key held outside the database.
The remaining three Critical findings were committed secrets:
- an administrator token for the CI server that builds production images
- an RSA private key used to sign inter-service messages
- a source-control token with admin and push rights over four private repositories compiled into every production build
For the first two, the values were moved out of the code, and live re-testing confirmed that production uses rotated values. Purging them from git history is recorded as outstanding.
The third secret was removed from the working tree. However, it persists in git history, and its revocation had not been confirmed at the final re-test, so it remains open. The report’s recommendation is to revoke the token, forensically audit the four repositories it could reach, and only then purge the history.
None of the three secrets findings was a code defect. Each was a credential that had been in the repository since its first commit, and each gave write access to part of the path that becomes production.
Fourteen High findings, most of them in the money path
Four High findings concerned the ledger:
- Deposit double-credit. A deposit could be credited twice, because the state check ran before the row lock.
- Unlocked P2P and escrow updates. These balance mutations were unlocked and non-atomic across columns. One management call could credit one account without fully debiting another.
- Split internal transfers. User-to-user transfers credited the receiver and debited the sender in separate transactions.
- User-settable market-making flag. An order flag meant for market making could be set by any user. It zeroed the fee on the account side while the double-entry books still recorded it, leaving a repeatable, withdrawable surplus.
All four are resolved. The fixes use row locks, single-transaction transfers and database-level non-negative balance constraints, and the flag has been removed from the user-facing parameters.
On the gateway, client IPs were taken from the leftmost X-Forwarded-For value, which an attacker controls. That let an attacker reset the one-time-code lockout and brute-force the second factor. The first fix introduced a regression: it trusted a Cloudflare client-IP header unconditionally. Live testing confirmed the origin could be reached without going through Cloudflare. That regression was raised as a separate High finding and fixed in the final round.
Several other High findings were also resolved:
- API-key nonces had been valid for roughly 317,000 years. They now expire after ten seconds and are deduplicated.
- An authenticated SQL injection in the order and trade listing queries was parameterised.
- Missing per-action checks on admin endpoints were added.
- The management-API configuration now requires two independent signers for every fund-moving scope and fails closed.
The staking service’s admin authorisation had been commented out entirely. Live testing showed the gateway’s default-deny rules happened to block the path, so the service was broken but safe, and role enforcement has been restored. The staking service’s management signing key has been moved to environment configuration. However, the key is still recoverable from git history and its rotation cannot be confirmed from the repository, so that finding remains open.
What remains open
The ten open Medium findings fall into three groups:
- Ledger and reconciliation integrity:
- the swap path’s double-entry bookkeeping is incomplete
- four separate definitions of a “house” account do not agree, which makes solvency hard to prove from the books
- the cross-service staking transfer is not idempotent on retry
- the matching engine can settle against bot orders that have already been cancelled
- Credential and session exposure:
- an API-key detail endpoint returns the secret
- the operator console’s CSRF token is readable by JavaScript
- encryption at rest in non-production environments uses a publicly derivable key
- Defence-in-depth gaps:
- dependency hygiene has no CI audit gate
- the realtime WebSocket service has no origin allowlist
- the deposit-recipient pinning residual noted above
The open Low and informational findings are mostly repository and logging hygiene. They include:
- a development key pair still tracked in the repository (live testing confirmed it is not the production signer)
- debug output in a forked secrets library
- two rate-limit rules that reference paths that do not exist
- a file mapping the audit findings that had been committed to a product repository
How the assessment was run
Twelve methods were applied:
- manual server-side source review
- threat modelling across actors, assets, trust boundaries and entry points
- authentication and session-handling analysis
- JWT and key-handling review
- derivation of the authorisation matrix from source
- review of the API-key nonce and HMAC scheme
- CVE mapping against the forked baseline and differential review against upstream
- a secrets and configuration audit covering both the working tree and git history
- dependency review against the pinned lockfiles
- authorised dynamic testing against production
- financial-flow and state-machine analysis
- concurrency and race-condition modelling
The frontends were also swept with Semgrep and CodeQL. After triage, that sweep turned up one genuine Low finding and no exploitable client-side injection.
To attribute each finding, Fidesium diffed the forks file by file against clean upstream OpenDAX baselines. The result is the report’s central conclusion. Almost every Critical and High finding sits in code Yimmit added on top of OpenDAX: the Fireblocks integration, the custom identity endpoints, the P2P, swap and internal-transfer features, and the committed configuration. The upstream core is preserved and sound, including its locked double-entry funds primitives and its deposit and withdrawal state machines. The report records thirty positive observations, among them:
- the gateway-to-engine token is verified cryptographically
- every inbound webhook other than Fireblocks was already authenticated
- swap prices are fetched server-side
- no SSRF, template-injection, command-execution or unsafe-deserialisation sinks were found
The signed report
The complete report is the artefact of record, and it is unchanged: Yimmit Exchange, 12 August 2026 (PDF). This is version 3 of the report. It carries every finding at every severity, the severity definitions, the recommendation and remediation status for each finding, the review commits for every round, and appendices on the authorisation model, the deposit and withdrawal state machine, and the identity and recovery control surface.
The report is governed by Fidesium’s terms and conditions. It assesses code quality and risk at a point in time. It is not an endorsement of Yimmit, it is not investment advice, and it does not guarantee the absence of bugs. Four of its findings were introduced by changes made while the engagement was running, and one High finding was a regression created by a fix. That is why an assessment dated August says nothing about a repository in December.
All 23 public reports are listed at audits.
Request a quote
If your product is a web application with a wallet attached rather than a set of contracts, the audit that matters is the one that reads the API surface, the error paths and the dependency tree. Fidesium’s manual smart contract audits and security services cover both, run by the engineers who built the tooling, with two rounds of fix verification included and pricing from $5,000 depending on the codebase.
Tell us what you are shipping and when, and we will scope it.