QR Miniapp Update

Earlier today, an attacker stole credentials from the QR miniapp and sent notifications from their apps. Users were sent to a different miniapp and encouraged to buy a fake token for $3.  

The QR team fixed this and reimbursed all users.

Shoutout to the QR team for being very quick to respond. There is no other compromise of Farcaster wallets and your funds are safe. 

What is Farcaster doing to prevent this?

Our transaction scanning prevents dangerous “send me all your money” attacks. That’s why the damage was limited to a $3 buy. 

We are also limiting miniapp notifications to redirect within the same domain. The attacker would have to compromise many more parts of the QR miniapp to pull off this attack again.

What can I do to stay safe?

If an app is asking you to do something that it normally does not, like buying a new token or claiming an airdrop, check the apps home page or the author’s page to see if it is legitimate before taking the action. If there is some doubt, ask the author over DM or in the feed before taking the action.

Not sure if this was even the issue, but a friendly reminder out there for folks (including myself): regularly audit what environment variables appear in client-side code.

NEXT_PUBLIC_*, for instance.

Vibe coding is really, really bad at this.

leader • reader • taco eater • fly eagles fly • /whiskey • /nativefun • onchain chef • previously addepar, linkedin • https://nf.td/derek

Native

Can you further explain this? Next public is supposed to be on the client side. How was an attacker able to override it?

If you wanna share a code sample, please do so.

software artist | building /outpaint | ex: @coinbase ex: bisontrails | seeker of the flow state | artivilla.com

QR coin

NEXT_PUBLIC is supposed to be client side, but some environment variables should not be prefixed with NEXT_PUBLIC.

Private keys, API secrets, etc. should all be consumed in API routes that the client-side code calls, rather than consumed directly in client-side code.

Didn't need to be rerouted. Say LegitApp has something like NEXT_PUBLIC_NOTIFICATION_API_KEY=sdfkljhsdfkljhsdklj

Attacker could get the API key from client side code, and then use that to send a notification, posing as LegitApp, that directs to their entirely separate miniapp.

I got that. I guess I was asking which key was exposed that rerouted the app.