Forum Discussion

1P_Phil's avatar
1P_Phil
Icon for Moderator rankModerator
17 days ago

.env accessed?: Lesson learned from a drained crypto wallet

A user on X recently lost their entire crypto wallet after installing a malicious extension in Cursor.ai. The extension accessed their .env file, extracted private keys, and sent them to an attacker’s server. The wallet was drained within 27 minutes.

Sadly a hard lesson to learn from.

What steps would you recommend to secure their setup?

Read - https://x.com/0xzak/status/1955265807807545763?s=46&t=WQd8UVBBGk_pyHB3pNwGsA 

discussion
secrets management
security

1 Reply

  • chris__hayes's avatar
    chris__hayes
    Occasional Contributor
    16 days ago

    Yeah, I had a similar thing happen in relation to leaking my `OPENAI_API_KEY`. Might've been this: https://socket.dev/blog/npm-is-package-hijacked-in-expanding-supply-chain-attack

    If it really was that trojan, I could've lost SSH keys as well. But, luckily was already using 1Password for everything SSH.

    Got me to move my env vars into 1Password in conjunction with 1Password CLI's `op read`. Set up aliases on CLI tools that need a env variable, to have 1Password load the env var first. This avoids a 1Password prompt every time you pop open a terminal.

    Considering more people are going to look to 1Password to more securely store their local env vars, please consider fixing this issue - "Copy secret reference" inconsistent behavior/bugs | 1Password Community.

    Honestly, with the security of your device, it's impossible to personally verify the security of everything you install. With the amount of trust involved, it seems better to prepare your damage limitation than to believe an air tight solution is possible.