iotexproject / iotexproject/iotex-safe-web-core
Dependency advisories: 130 open, only 1 is client-reachable and unfixed
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Dependabot reports **130 unique open advisories** on this fork. The raw counts look
alarming, but most of them are not describing code that runs anywhere near a user.
Split by whether the package actually reaches the browser:
| | critical | high | medium | low |
|---|---|---|---|---|
| **in the shipped bundle** | 1 | 4 | 11 | 4 |
| build-time only | 4 | 40 | 52 | 14 |
And of the 5 critical/high that *are* in the bundle, 4 are Next.js server-side
issues that a static export cannot reach. The real client-side list is short.
## How "in the shipped bundle" was determined
Not from `package.json`. Dependabot's `runtime` scope only means "in `dependencies`",
which for a static export still covers plenty of code webpack never bundles — that is
why the raw numbers mislead here.
Instead, from the published source maps of the live site, which list every
`node_modules` path webpack actually pulled in:
```bash
for C in $(curl -s https://safe.iotex.io/ | grep -oE '/_next/static/chunks/[^"]+\.js' | sort -u); do
curl -fsS "https://safe.iotex.io${C}.map" -o "$(echo $C | tr / _).map"
done
# then collect node_modules/((@scope/)?pkg) from each map's "sources" array
```
208 distinct packages are actually present in the bundle. Cross-referencing that set
against the Dependabot list produces the table above.
## What actually warrants action
**`js-cookie` — CVE-2026-46625 (high), fixed in 3.0.7, we ship <= 3.0.5.**
Per-instance prototype hijack in `assign()` enabling cookie-attribute injection.
This is the one high-severity advisory in the bundle that is genuinely client-side
and genuinely reachable. Smallest useful fix in this repo.
**`bn.js` — CVE-2026-2739 (medium), fixed in 4.12.3.** Infinite loop. In-bundle and
on the crypto path, which raises its practical weight above "medium" for a wallet
UI. Note `next.config.mjs` aliases `bn.js` to a specific copy, so a naive bump may
not move what is bundled — verify against the source maps afterwards.
**`elliptic` — CVE-2025-14505 (low), no patched version available.** Risky
cryptographic primitive implementation. Nothing to bump to; tracking only, but worth
knowing it sits on the signing path.
**`@babel/runtime` (CVE-2025-27789) and `joi` (CVE-2026-48038)** — both medium, both
straightforward transitive bumps.
## What does not warrant action
**The four Next.js advisories** — CVE-2025-29927 (middleware authorization bypass),
CVE-2026-64645 (SSRF via rewrites), CVE-2026-44573 (i18n middleware/proxy bypass),
CVE-2024-51479 (authorization bypass). Every one requires the Next.js **server** to
be running. This app is `next build && next export`, uploaded to Cloudflare Pages as
static files: there is no middleware, no proxy, and no server-side rewrite handling
at request time. The `rewrites()` entry in `next.config.mjs` does not survive export.
They will keep showing as critical/high on the dashboard, which is worth writing down
somewhere so the next person does not have to re-derive it under time pressure.
**The 110 build-time-only advisories** (`tar`, `minimatch`, `brace-expansion`,
`js-yaml`, `ajv`, `form-data`, `ws`, `@solana/web3.js`, cypress' dependencies, ...).
These matter for build integrity — a malicious version could tamper with the output —
but that is a supply-chain concern answered by lockfile discipline and pinning, not
the same urgency as shipped client code.
## The underlying problem
This fork sits at `safe-wallet-web` 1.14.0 on Next 12.2.0, roughly three years behind
upstream. Most of this list is a symptom. Individual bumps are worth doing for the
short in-bundle list above, but the durable fix is a rebase onto a newer upstream,
which is a project rather than a patch and needs its own plan.
Note also the Node ceiling any dependency work runs into early: the prod deploy
workflow documents that `secp256k1@4.0.4` requires Node >= 18 while the build is
pinned to Node 16 (forced by `ts-node@10.8.2` in postinstall).
## Suggested next step
Bump `js-cookie`, `bn.js`, `@babel/runtime`, `joi` — the four in-bundle,
patch-available advisories — and verify against the source maps afterwards that the
bundled copies actually moved. Leave the Next.js ones documented as not-applicable
rather than suppressed, so the reasoning survives.
---
Filed from a security review of `safe.iotex.io` on 2026-07-27.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Review package.json and next.config.mjs first, then inspect the production deploy workflow for the Node 16 constraint. Bump the four named in-bundle dependencies, run `next build && next export`, and compare the resulting published source maps to confirm the bundled copies moved. Document the Next.js advisories as not applicable rather than suppressing them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nextjs, node.js, typescript, webpack
- Domain
- build-system, frontend, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100