scrobble.life
Value 4 Value

Security Incident @v4vapp: KeepSats Transfer via Authentication Flaw — Now Resolved

Vote for Brianoflondon's Witness KeyChain or HiveSigner

This is a value for value post: see the explanation in the footer.


v4vapp-hack-attempt-october-2026-banner.jpg

Security Incident: KeepSats Transfer via Authentication Flaw — Now Resolved

On 12 October 2026 an attacker exploited a flaw in the v4v.app authentication flow.

After signing a normal Ethereum wallet challenge that requested hive:active scope, the attacker called the token-refresh endpoint and supplied an arbitrary Hive username. The API issued a valid access token for that username while keeping the elevated scope.

With the resulting token the attacker called the KeepSats transfer endpoint. The public API used the username from the JWT as the sender; the backend then broadcast a v4vapp_transfer custom_json operation signed by the server account v4vapp. This moved 40,000 sats on the internal KeepSats ledger from one_of_my_accounts to emem0515.

No Hive posting or active keys belonging to one_of_my_accounts were presented or used, and no Lightning payment or Hive/HBD left the service. The same client first performed smaller test transfers and username switches, confirming the behaviour before the larger movement.

The authentication path that allowed a refresh to mint a token for an arbitrary username without a corresponding signature or membership check has been closed. The affected session is no longer valid and the vulnerability has been patched.

The Attacker?

I have a number of Hive account IDs and ETH addresses which were used to do this. Fortunately my alert systems were quick enough to shut this down before any funds could move out of my system, and those accounts are now all blocked permanently.

After the Attack

Repeat log on attempts:

Time (UTC) Name Source Result
13:32–13:33, four tries hiveln 186.247.41.86 Bad User, no challenge

186.247.41.86 is still showing up. Right after the restart it read KeepSats, refreshed, and logged out, then polled /v1?get_crypto=true every 10 minutes until 10:23. At 13:32–13:33, with no Referer, it asked for challenges for brianoflondon and v4vapp (clientId=audit-check-2, scope=hive:active). Those challenges were issued and never signed.

It also asked for nonexistentuser12345. It then signed in as ryum216 in 1.21s and posted a KeepSats transfer of 999,999,999 sats from ryum216 to ryum216, memo audit-overbalance. The backend returned 402 Insufficient funds. No sats moved. The same IP then called convert and invoice.

Thank you to everyone who uses v4v.app and KeepSats.


Value for Value

For the last few months while building @v4vapp I was generously supported by the DHF. Going forward I have a much more modest support which covers direct server costs and a little of my time.

If you appreciate the work I do on and around Hive, you can express this directly: upvoting posts on Hive is great. Also consider a direct donation (there's a Tip button on Hive or a Lightning Address) on all my posts.

hivebuzz-orca-120.png

Vote for Brianoflondon's Witness KeyChain or HiveSigner

v4vapp-hack-attempt-october-2026-square.jpg


Send Lightning to Me!

Comments · 5

  • @kryptonita(71)· 7d

    40.000 sats movidos con un token minteado para un username arbitrario es un fallo de autorización de manual, no un hackeo de claves. Lo que me llama la atención es el patrón previo: transfers chicos y cambios de username para testear el comportamiento antes del movimiento grande, eso es alguien que entendía el flujo. La IP 186.247.41.86 polleando /v1?get_crypto=true cada 10 minutos después del restart dice que no se fueron.

  • Is there another issue right now? V4V doesn’t recognice LN invoices and gives an error every time. I tried several invoices but always the same:

  • @databaron(62)· 12d

    Letting a refresh mint a token for any username while keeping active scope is a scary gap, so stopping it at 40,000 sats is a relief. Will refreshes now need a fresh signature, or a check that the username matches the original login?

  • @epodcaster(68)· 12d

    Sigh. If only they would use their power for good.

    Glad you were able to resolve this and block the bad actor.

  • @earnology(51)· 13d

    Good thing those alert systems caught it quickly before anything serious happened. That audit-overbalance attempt testing the limits is pretty brazen though.