Looking at the replies of the tweet, it looks like the post is related to this:

https://x.com/i/status/2082919505819304343
https://www.reddit.com/r/Bitcoin/comments/1vatgl4/full_panic_one_of_my_wallets_was_drained/

But nothing is confirmed yet.

True, details are still unclear - I've updated the OP - but there's a growing amount of evidence (on twitter and reddit) seemingly pointing to coldcard.

Coldcard confirmed the vulnerability: https://x.com/COLDCARDwallet/status/2082961993070247948

I also just saw the news on the local website I usually visit
https://livecoins.com.br/usuarios-relatam-perdas-de-us-385-milhoes-em-bitcoin-em-possiveis-ataques-ligados-a-coldcard/

Coldcard has confirmed the vulnerability
I don't know if anyone here is using this wallet (but chances are, yes)

I believe the safest course of action is to move your funds to another wallet as soon as possible

Other models are partially affected: https://x.com/Nneuman/status/2082977839654093290

This disagrees with my analysis.  I believe the attack is ~32-bits harder on Mk4+ but they're still vulnerable.

Yes, you are correct. Someone posted on X about this and I just found it.

Haa! NotATether. You must have some explanation to make about this comment, like what do you mean by saying people should not use their hardware wallet to generate seed phrases? This is the first time I would ever heard such, I've been using my seed phrases that was generated with an airgapped hardware wallet, how is this not safe?

I am using Keystone 3 to be precise and what you just said scares the shit out of me, I have no bitcoin elsewhere than in my Keystone and it's been over 4 years of usage already, can you be more clearing about what you are trying to teach us with this statement of yours? I've never ever heard this before, this is scary.

The coldcard source code attempts to disable the hardware RNG support in micropython because they provide their own implementation, but the handling of the the disable flag is inconsistent.

To disable it they #define MICROPY_HW_ENABLE_RNG (0)   and this successfully disables it.

But to enable their replacement they check #ifndef MICROPY_HW_ENABLE_RNG   ---   and this is ineffective because the if(n)def directive checks only if the flag MICROPY_HW_ENABLE_RNG is defined, its value "(0)" is irrelevant and counts as defined just as any other value would.  Probably any sufficiently long-expirenced C programmer has encountered a form of this #if vs #ifdef confusion.

This inconsistency makes the coldcard firmware not use its own HWRNG support code but instead call the micropython random function.  But the micropython function has its hardware support disabled and when it is disabled it replaces it with a placebo insecure PRNG function which is seeded with part of the devices hardware id and a timer.  "Micropython: We've replaced this users randomness with Folgers Crystals, lets see if they notice".

The replacement function *looks* like good random numbers... but they're not random at all, and provide essentially no security.  However, if you were to try to judge their quality with tools like diehard you would probably get a result that they were high quality -- this the reason RNGs are such a risky part: the quality of a random stream depends on how it was created and can't be detected purely from the random values itself.

So for mk3 the attacker just needs to search the likely hwids and timer values for wallets.

For mk4+ the not-random random value from above gets xored with another instance of the same placebo function (more Folgers Crystals), initialized with a 32-bit presumably secure random value that ultimately comes from another chip inside the wallet.  The 32-bits of extra security is not enough to make it secure, but it may delay attacks by speak-and-spell wielding toddlers.

The use of "fallback" and no-security providing PRNG "whiteners" is a practice that some people have previously identified as risky due to the risk of accidentally hiding more serious bugs.  Unfortunately both the authors of micropython and coldcard itself engaged in this particular sin, and fixing either one alone wouldn't have made the error immediately obvious.  I wouldn't say that belt-and-suspenders like these are unconditionally bad, but incredible care must be taken to be sure that they aren't covering up other issues.

Take my analysis with a grain of salt: it's purely a product of personally reading the source code.  I do understand that expert AI users also independently reached the same conclusion including with validation against a disassembled firmware image, which is why I feel confident enough sharing it.

Edit: This post is also consistent with the new coldcard blogpost: https://blog.coinkite.com/entropy-technical-backgrounder/