SafeDrop risk audit, October 2025: 12 findings across two repositories
Fidesium was asked to perform a risk audit on SafeDrop’s codebase, covering both its back end and its front end. Twelve findings were raised: 3 Critical, 2 High, 5 Medium, 2 Low and none informational. Nine of the twelve are recorded as resolved or remediated in the signed report. Both repositories scored in the low risk band, and the assessment was dated 29 and 31 October 2025. Every Critical finding was a dependency carrying a published CVE, and all three were closed by upgrade before the report was issued.
What was reviewed
| Protocol | SafeDrop |
| Category | Utility |
| Assessment dates | 29 and 31 October 2025 |
| Repository | safedrop-back and safedrop-front |
| Risk score | 12 out of 100 (31 October 2025) and 34 out of 100 (29 October 2025) |
| Test approach | Whitebox and blackbox, with automated security testing |
This engagement is an application and API audit rather than a contract audit. The scope was a web front end and a Node back end, so the risk sat in dependencies, in how the service handled errors from external APIs, and in what it logged and collected. The report’s own summary of the contract side records that the contracts are well written and secure, with only a few minor issues.
The report also carries a team risk section, which records no issues found in the founding team, a public doxxing status, and team experience rated as highly relevant.
The findings
Twelve findings were raised in total.
Critial
3
High
2
Medium
5
Low
2
Info
0
All three Critical findings and both High findings are recorded as resolved. Four of the five Medium findings are recorded as resolved or remediated. The remaining findings carry their own status in the signed report, which is linked in full at the end of this page.
| Finding | Severity | Status |
|---|---|---|
| Authorisation bypass in the Next.js version in use | Critical | Resolved |
| Input manipulation in the sha.js version in use | Critical | Resolved |
| Supply chain injection through a compromised MetaMask SDK package | Critical | Resolved |
| Privileged API responses written to logs in plaintext | High | Resolved |
| Denial of service in the multer version in use | High | Resolved |
| Binance API errors swallowed, leaving partial data | Medium | Resolved |
| API errors reported as successful but empty lookups | Medium | Resolved |
| Code injection through file upload in the @nestjs/common version in use | Medium | Resolved |
| Collection of user API credentials by the front end | Medium | Remediated |
What was fixed, and how it was verified
Three Critical findings, all in dependencies
The Next.js version running in safedrop-back was vulnerable to authorisation bypass, under CVE-2025-29927, CVE-2025-57822, CVE-2025-57752 and CVE-2025-55173. Fidesium recommended an upgrade to at least version 15.4.7. The report records that Next.js was upgraded.
The sha.js version running in safedrop-front was vulnerable to input manipulation, under CVE-2025-9288. Fidesium recommended an upgrade to at least version 2.4.12, and the report records that sha.js was upgraded.
The third was a supply chain compromise rather than a bug in SafeDrop’s own code. Two MetaMask SDK packages, @metamask/sdk and @metamask/sdk-communication-layer, had been compromised upstream, under GitHub advisory GHSA-qj3p-xc97-xw74. The risk in that class of attack is a wallet drainer reaching production through a cached package rather than through the repository. Fidesium’s recommendation was to verify that no cached copy of the affected version survived anywhere, locally or in any deployed environment, including deleting node_modules and any continuous integration caches before reinstalling. The report records that the SafeDrop team verified their deployed caches.
All three Critical findings were dependency risk, and none of them originated in code SafeDrop wrote. That is the ordinary shape of application risk in this stack, and it is the argument for running dependency analysis on every commit rather than once.
Four Medium findings, in error handling and credentials
Two findings concerned how the service treated a failing external API. Calls to the Binance API did not handle errors, so execution continued and failed calls were silently ignored, and separately an API error was returned in the same shape as a successful lookup that found nothing. A caller could not tell “we could not reach the service” from “this wallet does not exist”. Error handling was added, and API errors were separated from empty results.
The @nestjs/common version in the back end was vulnerable to code injection through file upload, under CVE-2025-29409, and was upgraded to at least version 10.4.16.
The fourth was a design finding rather than a defect. The front end collected API credentials from users. Nothing improper was being done with them, but collecting a user’s keys widens the blast radius of any other weakness, and it is indistinguishable from the pattern an attacker would use. Fidesium recommended explaining clearly why the keys were needed, defining and documenting the minimum permissions required, and using pre-defined keys instead of user-supplied ones wherever possible. The finding is recorded as remediated: SafeDrop now explains the requirement to customers and the interface carries least-privilege instructions.
Two High findings, in logging and in uploads
Privileged API responses were being written to the log as they arrived, with no validation and no sanitisation, throughout the back end. Fidesium’s recommendation was direct: do not log those responses. The report records that the SafeDrop team removed the response logging.
The multer version in the back end was vulnerable to denial of service under CVE-2025-48997 and CVE-2025-47944. Fidesium recommended an upgrade to at least version 2.0.2, and the report records that multer was upgraded.
How the assessment was run
Nine methods were applied: mapping the functionality of the API, application logic flaw analysis, access handling, authentication and authorisation flaw analysis, brute force attempts, input handling, source code review, fuzzing of every input parameter, and dependency analysis. Testing was both whitebox and blackbox, as scoped, supported by automated security testing.
The report’s own summary of the codebase is two sentences long: it is generally well written, and it does carry a handful of flaws. That is the register these reports are written in.
The wider engagement is covered separately in SafeDrop Linea airdrop audit validation, published 9 November 2025, which sets out how Fidesium verified SafeDrop’s published analysis of coordinated wallet activity in the Linea airdrop alongside the codebase review.
The signed report
The complete report is the artefact of record and it is unchanged: SafeDrop, 1 November 2025 (PDF). It carries every finding at every severity, the severity definitions, the recommendation and the action taken for each finding, and the team and contract risk overviews.
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 SafeDrop, it is not investment advice, and it does not guarantee the absence of bugs. Three of the twelve findings sat in dependencies that were safe when they were installed and unsafe by the time they were audited, which is the reason an audit dated October 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.