Hono Has 34M Weekly Downloads and One Maintainer

Hono is everywhere right now. If you’re building on Cloudflare Workers, Bun, or Deno — you’ve almost certainly used it. Fast, lightweight, TypeScript-first. 34.6 million weekly downloads. A GitHub star count in the tens of thousands.

And a single maintainer.

I ran hono through proof-of-commitment, a supply chain risk scorer that evaluates npm packages on behavioral signals — the kind of structural data that npm audit doesn’t check.

npx proof-of-commitment hono

Package   Risk            Score  Maintainers  Downloads    Age
────────────────────────────────────────────────────────
hono      🔴 CRITICAL     82     1            34.6M/wk     4.3y
  └ longevity=20 momentum=25 releases=20 maintainers=4 github=13

Score of 82 out of 100. One maintainer. 34.6 million weekly downloads per week.

The result: CRITICAL.

What CRITICAL means

CRITICAL = sole maintainer + >10M weekly downloads. That’s the structural profile of a high-value attack target — not because hono is poorly maintained (it isn’t), but because it’s concentrated risk: one person holds the npm publish key for a package that runs in millions of production environments.

This is the same structural profile behind the ua-parser-js attack (October 2021): one npm token compromised, malicious versions published, used by Facebook, Microsoft, and Google. npm audit showed zero issues beforehand. Behavioral scoring had the structural flag for years: sole maintainer, millions of downloads. The same profile applies to hono today.

The tool doesn’t predict that hono will be attacked. It identifies the conditions that make it a high-value target.

The score breakdown

The breakdown tells a more nuanced story:

• Longevity: 20/25 — 4.3 years, solid but not ancient
• Download momentum: 25/25 — 34M/week and growing fast (full marks)
• Release consistency: 20/20 — actively maintained, regular releases
• Maintainer depth: 4/15 — this is where it falls apart
• GitHub backing: 13/15 — strong

The package is well-maintained by yusukebe. It has excellent release cadence. The risk isn’t abandonment — it’s concentration. Everything that makes hono popular makes it a concentrated attack surface.

What this looks like in your project

If you have a package.json that depends on hono, run:

npx proof-of-commitment --file package.json

Or drop your package.json at getcommit.dev/audit.

You’ll likely see hono flagged CRITICAL alongside zod (160M downloads/week, 1 maintainer) and possibly chalk (412M/week, 1 maintainer). Three packages that power most modern TypeScript projects.

What to do with this

Nothing immediately needs to change. Hono is a great framework. yusukebe is an active maintainer. But:

1. Know your concentrated risk. When you have sole-maintainer packages at 10M+ downloads/week in your stack, that’s a dependency that warrants extra attention on security advisories.
2. Watch for unusual releases. The ua-parser-js attack was a malicious publish — a new version that wasn’t expected. Having awareness that a package is high-concentration means you pay closer attention when something unusual appears.
3. Consider it in your threat model. CI/CD pipelines that auto-update dependencies are particularly exposed to this class of attack.

The tool doesn’t tell you to stop using hono. It tells you that hono is structurally similar to axios — and that’s worth knowing.

---

proof-of-commitment is a zero-install CLI, GitHub Action, and MCP server for supply chain risk scoring. Try it live — pre-loaded with common packages, auto-runs on arrival.