[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CANZ2odhBX0G_K7UEEsv0=FDWooRO3dyCd+qrvKsvZuV_ODR8vQ@mail.gmail.com>
Date: Mon, 11 May 2026 13:55:43 -0400
From: "Emiliano Solazzi G." <coma.retained@...il.com>
To: oss-security@...ts.openwall.com
Subject: CVE Request: Fail-open authentication in hathor-wallet-headless <=
0.38.0 (vendor declined to fix)
Hi,
I'm requesting a CVE and posting public disclosure for a fail-open
authentication defect in hathor-wallet-headless, the official REST
wallet daemon maintained by HathorNetwork.
Product: hathor-wallet-headless
Vendor: HathorNetwork
Affected: <= 0.38.0 (all releases)
Fixed in: None (vendor declined to fix)
Severity: Critical (CVSS v3.1 9.8 -
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-1188, CWE-276, CWE-636
Repository: https://github.com/HathorNetwork/hathor-wallet-headless
Summary
-------
In src/app.js, the API-key authentication middleware is mounted only
when config.http_api_key is truthy. The mainRouter is mounted
unconditionally on the same Express app. When http_api_key is unset
- which is the shipped default in config.js.template, config.js.docker,
and the Dockerfile that EXPOSEs 8000 - the daemon binds to 0.0.0.0
and serves every wallet endpoint (start, send-tx, simple-send-tx,
utxo-consolidation, melt-tokens, etc.) without authentication.
Anyone who can reach the listening socket can spend, mint, and melt
funds from any wallet the daemon controls.
The fix is one line: refuse to start when http_api_key is unset and
http_bind_address is non-loopback, or always require an API key.
This is the standard fail-closed pattern used by every comparable
self-hosted wallet daemon (bitcoind, geth, electrum, lnd, c-lightning).
Reproduction, defect walk-through, configuration evidence, suggested
patch, and disclosure timeline:
https://gist.github.com/emilianosolazzi/f50b2e3d5f9dec524971a89beeb33fcd
Vendor position
---------------
Reported via Immunefi 2026-04-30. Vendor (yanmartins, 2026-05-04)
closed the report stating "this is expected behavior. Wallet operators
should protect their APIs." Immunefi mediation denied. Vendor has
declined to ship a fix or a security advisory. Publishing here to
give operators a chance to audit their deployments.
A CVE-ID assignment via MITRE has been requested; CVE form submitted
2026-05-11.
--
Emiliano Solazzi
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
