← All topics

vulnerability

2 captures, most recent first.

V12 @v12sec

— reposted by cts — saved image

cts reposted

V12 @v12sec · 2h
Signal's Contact Discovery automatically sends your contact list information to an SGX enclave in the cloud.

V12 broke into that enclave and leaked the key, allowing the server host to decrypt everything.

Two separate critical bugs: arbitrary read and RCE.

Here's how. [thread emoji]

[attached video, paused at 0:12, showing a dark terminal-style panel with a text overlay "reclaim for register control" partly covering some lines:]
attest       sgx local report
base         00007a2c00000000    + 001bbd20 -> g_privkey

01 client
held         generation A         tid 27    at noise allocation entry
held         guard client         tid 28    at noise allocation entry, never released
released     generation A
handle       00007a2d02778d90     from [partly covered] ... t + 56    chunk 48

02 rate limit
held         enclave_rate_limit calloc, secon[d] [partly covered]
request      7 new_e164s x 8 = 56 bytes -> calloc(1, 56) -> chunk 4[8] [partly covered]

03 split validation
held         stale retry    tid 30    between check and swap
page         00007a2d02778000    read-only
canary       passed    handle + 0x00
state cas    pending   handle + 0x08

04 close and free
held         close    tid 31    after client_free
client_t     00007a2d02778d90    freed

05 replacement
released     rate-limit
calloc       reuse freed address
sort         odd_even_msort_uint64s [partly covered by video controls]
Note from Claude Sonnet 5

Repost of a security-research thread from V12 claiming they broke into the SGX enclave used by Signal's Contact Discovery and leaked the key, via two critical bugs (arbitrary read and RCE). The attached video frame shows a terminal-style heap-exploitation timeline with a 'reclaim for register control' caption.

signalsgxenclavevulnerabilityrcecontact discoverysecurity researchv12

Andrew Curran @AndrewCurran_

— saved image

Andrew Curran @AndrewCurran_ · 7h
Update from r/Bitcoin. Claude Code can independently find the same wallet vulnerability used in this attack in eight minutes.

[embedded Reddit screenshot]
r/Bitcoin · 10h ago
Impressive-Gene-421
Are you kidding me? Claude Code found the catastrophe after being asked only to ""check for vulnerabilities and thinking for 8 minutes

1. ngu.random is wired to a software PRNG, not the hardware TRNG — CRITICAL

There are two independent RNG paths in the firmware, and only one of them reaches the STM32 TRNG.

Path A (correct). ckcc.rng_bytes() → stm32/COLDCARD_MK4/rng.c:131 random_buffer() → rng_get_or_fault() reads RNG->DR directly and raises OSError on timeout or repeats. This is what backups.py:337 uses for the backup-file password.

Path B (broken). ngu.random.* → external/libngu/ngu/random.c:73 CHIP_TRNG_32(), defined at line 24-26 as extern uint32_t rng_get(void).

It is unbelievable that some kid with an LLM just stole $100m+ because no one bothered to check the source code.

Also on GLM 5.2 (trained 16th June, no internet access).

[quoted tweet]
Andrew Curran @AndrewCurran_ · Aug 1
By the end of the year the tools available to anyone attempting this kind of attack will be vastly more capable across all devices. If there is a seam in any existing hardware, they will get their fingers in there. Attacks like this are about... [cut off]
Note from Claude Sonnet 5

X post by Andrew Curran about a Reddit r/Bitcoin post claiming Claude Code independently found, in eight minutes, the firmware RNG vulnerability (Coldcard hardware wallet, software PRNG vs hardware TRNG path confusion) reportedly used in a large ($100m+) cryptocurrency theft. Includes technical code-path details from the Reddit post and Curran's follow-up warning about future attack tooling capability.

twittercryptocurrencyhardware walletvulnerabilityclaude codecoldcardcybersecurity