HDA was hacked, and here's what you need to know

What companies usually don’t disclose: someone hacked us! (And they left empty-handed)

If you’re running vulnerable versions of react-server, assume you’ve been targeted too. The real question is: what was taken?

In our case: nothing useful. Not because we got lucky, but because we built HDA to make intrusion unrewarding. This week’s React Server Components vulnerability (a critical pre-auth RCE) turned a lot of internet-facing apps into soft targets overnight.

We saw malicious activity hit an analytics-facing entry point, so we did what you hope you never need to do:

• isolated the affected system
• collected forensic data
• rotated credentials/access
• validated downstream services and boundaries

But here’s what we want our users to know: If someone gets in… what can they actually walk away with?

In most products, “analytics” quietly means: Who you are + what you do + a stable identifier (so someone can target you later). That’s exactly what we refuse to build.

At Health Data Avatar, we intentionally minimise and anonymise what’s sent to analytics before it ever leaves our environment. It lets us answer operational questions (“is login slow?”, “is a page erroring?”) without collecting anything that would be useful to an attacker, or, frankly, to an over-curious growth team. Yes, it makes debugging harder. Yes, it’s less “optimised”. And yes. in moments like this, it’s why attackers end up with noise, not your personal information.

Lesson (especially for health apps, and sensitive data in general):

• Build for when you get hacked, not if.
• Design systems so the prize isn’t worth stealing.

Security folks: if you’re running React Server Components / related stacks, patch and review exposure.