The Privacy Hole in Your Browser Wallet

Your crypto wallet extension might be doing more than just signing transactions. A new study from researchers at KU Leuven reveals that 85 of the most popular crypto wallet extensions leak enough data to link a user’s different wallet addresses together — and track them across websites.

The findings hit at a basic promise of cryptocurrency: pseudonymity. If a wallet leaks address relationships, it becomes trivial for advertisers, analytics firms, or malicious actors to build a profile of who you are and where you spend your digital money.

That profile can get personal fast. On a website that already holds your name or email — a crypto exchange, a merchant checkout page — the leaked data can tie your real identity to every wallet address you own.

What the Researchers Found

The team tested 85 browser-based crypto wallets, examining how they communicate with websites and blockchain servers. The core problem: wallets broadcast information in ways that let outsiders link separate addresses to the same person.

This isn’t a hack. It’s a design flaw. The wallet extensions, by their normal operation, send enough metadata — address prefixes, connection patterns, timing signals — that a tracker can connect the dots.

Think of it like leaving the same fingerprints on every door you touch. Each blockchain address is meant to stand alone. But the wallet’s behavior stitches them together.

Cross-Site Tracking Without Cookies

Traditional web tracking relies on cookies. But crypto wallet extensions create a new vector. A tracker on Site A and Site B can both see the same wallet address or address-derived identifier. Suddenly, your browsing across those sites is linked — no cookies required.

The researchers found that many wallets expose address information to any website that asks for it. Some wallets even broadcast address data to third-party servers by default, without user consent.

Which Wallets Are Affected?

The study covered a broad range of popular extensions, including MetaMask, Phantom, and dozens of others. The researchers did not name every vulnerable wallet publicly, but they shared findings with developers before publication.

Some wallets have already begun patching the leaks. Others have not. The problem is structural: fixing it often requires redesigning how the wallet communicates with websites and blockchain nodes.

For users, that means the risk persists until your wallet developer ships an update. And not all updates will fully close the tracking window.

Why This Matters for Privacy

Pseudonymity is a cornerstone of crypto adoption. People use blockchain to send money, buy goods, or interact with decentralized apps without revealing their legal name. But a wallet that leaks address links undermines that entirely.

Consider a journalist receiving donations in crypto. Or a dissident funding political activism. If their wallet extension leaks address relationships, an adversary can trace the flow of funds across multiple wallets and link them to a single identity.

The tracking risk extends beyond crypto. A wallet extension that broadcasts address data to every site you visit creates a permanent fingerprint. You can clear your cookies, switch browsers, or use a VPN — but the wallet still leaks.

What You Can Do Right Now

Until wallet developers fix the issue, users have limited options. Here are practical steps to reduce exposure:

• Check for updates: Visit your wallet’s official site or extension page and install the latest version. Some developers have already released patches.
• Use separate wallets for different purposes: Keep one wallet for frequent transactions and another for privacy-sensitive use. This limits cross-wallet linking.
• Disable auto-connect features: Many wallets offer a setting to require manual approval for every site connection. Turn that on.
• Consider a hardware wallet: Hardware wallets like Ledger or Trezor offload sensitive operations from the browser, reducing the data the extension can leak.
• Use a privacy-focused browser: Browsers like Brave or Firefox with strict tracking protection can block some of the third-party requests wallets make.

None of these steps are perfect. The root cause is in the wallet’s code. But they reduce the attack surface while you wait for a permanent fix.

The Bigger Picture

The KU Leuven study is a wake-up call for the crypto industry. Browser extensions are a weak link in the privacy chain. Developers have focused on transaction security — making sure funds can’t be stolen — but have neglected data leakage.

This mirrors earlier problems in web privacy. In the early 2010s, browser extensions for password managers and ad blockers were found to leak user data. The industry eventually tightened standards. Crypto wallets need a similar reckoning.

For users, the lesson is uncomfortable but clear: your wallet extension is not just a tool. It’s a data broadcaster. And until the industry fixes the leak, you’re the one paying the privacy price.

If you use crypto wallet extensions daily, take a few minutes to review your settings and update your software. The researchers found that even a single unprotected wallet can undo all your other privacy efforts.

Inside the Vulnerability That Cost Meta $78,000

Meta has paid out a $78,000 bug bounty to a security researcher who uncovered a serious flaw in the company’s customer support infrastructure. The vulnerability, which went deeper than it first appeared, could have let attackers snoop on private conversations between users and Meta support teams.

Independent researcher Rony K Roy reported the issue in January 2026. At first glance, it looked like a minor authorization glitch. But Roy kept digging. What he found was a chain of security failures that exposed far more than he initially expected.

Meta patched the flaw in April. The company says it found no evidence that anyone had exploited it maliciously. Still, the payout — one of the larger bounties in recent memory — underscores just how dangerous the hole could have been.

From Horizon to Backend: How the Flaw Escalated

Roy initially spotted the problem in Meta Horizon Managed Solutions, an enterprise platform for managing Meta Quest devices and user accounts. That alone might have been a contained issue. But the researcher soon realized the same broken access control ran through Meta’s broader support backend.

The core problem: missing authorization checks, broken access controls, and an insecure direct object reference (IDOR) vulnerability. Chained together, these weaknesses allowed an attacker to enumerate Meta support case numbers and pull up entire support tickets.

Think about what that means. Anyone exploiting this could read email and chat exchanges between customers and Meta support. They could view case details, download files submitted through support requests, and scrape personal and contact information that users had voluntarily shared with Meta.

What an Attacker Could Have Done

The risks didn’t stop at data theft. Roy’s analysis showed that an attacker could also:

• Create support requests on behalf of organizations using Meta Horizon Managed Solutions
• Modify support workflows, including changing case statuses
• Add unauthorized subscribers to support cases

Imagine a bad actor hijacking a company’s open support ticket with Meta, altering its priority, or injecting themselves into the conversation. For enterprise customers managing fleets of Quest devices, that’s not just a privacy breach — it’s a operational security nightmare.

Roy disclosed his findings publicly last week. He told SecurityWeek that Meta had confirmed the vulnerability and paid the $78,000 bounty. Meta has not responded to requests for comment, but Roy appears on the company’s 2026 bug bounty leaderboard as one of its top researchers.

Broken Access Control: A Recurring Theme

This isn’t an exotic vulnerability. Broken access control and IDOR flaws are among the most common — and most dangerous — issues in web applications. The OWASP Top 10 has ranked broken access control as the number-one security risk for years.

What made this case notable was the scope. A seemingly minor authorization bug in a niche enterprise product turned out to be a gateway into Meta’s core support systems. It’s a reminder that security researchers often need to pull on loose threads to find the real damage.

Roy’s approach — reporting a limited-severity issue, then expanding the analysis — is exactly the kind of persistence that bug bounty programs are designed to reward. Meta’s $78,000 payout reflects that.

What This Means for Meta Users

For ordinary Facebook, Instagram, and WhatsApp users, the immediate risk is low. Meta says it patched the vulnerability before any known exploitation. But the incident raises legitimate questions about how much data Meta’s support systems hold, and how well it’s protected.

When you contact Meta support — whether about a hacked account, a billing issue, or a content takedown — you’re sharing details you probably wouldn’t post publicly. That trust is the foundation of customer support. A vulnerability like this breaks it.

Meta’s bug bounty program has long been one of the most generous in the tech industry. The company paid out over $2 million in bounties in 2025 alone. But programs like this are only as good as the researchers who find the flaws — and the company’s willingness to fix them quickly.

In this case, Meta did both. The patch came within three months of the initial report. No evidence of exploitation. A substantial bounty paid. That’s the ideal outcome.

Still, the vulnerability’s existence highlights a persistent challenge for large platforms: their attack surface is enormous. A single broken access control check in a backend API can expose millions of support records. Finding and fixing those gaps before attackers do is a never-ending race.

Roy’s $78,000 check is proof that the race is worth running.

The Quiet Heist: No Bugs, Just Broken Trust

For the past year, attackers tied to the notorious data-extortion group ShinyHunters have been pulling off a remarkably quiet heist inside Salesforce environments. Their method? It doesn’t involve a single exploit of the platform itself. No zero-days. No SQL injections.

The real vulnerability, according to new research from Microsoft, is something far more fundamental: the trust organizations place in their own OAuth connections.

These connections are the digital bridges that tie Salesforce to third-party apps, external vendors, and internal tools. And the attackers walked right over them.

Three Paths, One Goal: Steal Data, Demand Ransom

Microsoft’s threat intelligence unit mapped out three distinct intrusion paths the ShinyHunters-linked operators have used over the past year. Each path exploits a different kind of OAuth trust relationship, but the endgame is always the same — exfiltrate sensitive Salesforce data and demand a ransom.

Path 1: Compromised Third-Party App Credentials

The most common route starts outside Salesforce entirely. Attackers steal credentials for a third-party application that has an OAuth integration with the target’s Salesforce instance. Once inside that app, they use its legitimate token to access Salesforce data as if they were an authorized user.

Think of it like borrowing a friend’s badge to get into a building. You’re not breaking the lock; you’re just using someone else’s key.

Path 2: Stolen Salesforce API Tokens

In the second path, attackers go after Salesforce API tokens directly. These tokens are often stored in configuration files, shared repositories, or even plain text documents. A single leaked token can give an attacker the same access as a full-fledged admin — no password needed.

Microsoft notes that many organizations don’t rotate these tokens regularly, making them a long-lived, juicy target.

Path 3: OAuth Phishing for Consent Grants

The third path is the most social-engineered. Attackers send convincing phishing emails that trick users into granting OAuth consent to a malicious app. Once the user clicks “Allow,” the attacker’s app gets a token that can access Salesforce data on the user’s behalf.

It’s a consent trap. And it works because most users don’t read the permissions they’re granting.

Why This Matters: The Trust Blind Spot

These attacks highlight a painful truth about modern cloud security: the perimeter is dead, but many organizations still think it exists. Salesforce itself is secure. The flaws are in the ecosystem around it — the apps, the tokens, the people.

Microsoft’s report emphasizes that Salesforce data theft via OAuth abuse is not a rare edge case. It’s a growing pattern. The ShinyHunters-linked group has been at it for a year, and they show no signs of stopping.

What makes this particularly dangerous is the stealth factor. Because the attacker is using legitimate OAuth tokens, their activity often blends in with normal traffic. Security teams may not notice the exfiltration until the ransom note arrives.

What Organizations Can Do Right Now

There are concrete steps any Salesforce customer can take to reduce the risk of this kind of attack. Microsoft recommends starting with these three:

• Audit all OAuth connections — Review every third-party app with access to your Salesforce instance. Revoke anything you don’t recognize or no longer use.
• Rotate API tokens regularly — Treat tokens like passwords. Set a rotation policy and enforce it. Don’t let a token live for years.
• Train users on OAuth phishing — Teach employees to recognize consent-granting phishing attempts. A simple “Did you just approve a new app?” workflow can catch many attacks early.

For more on securing cloud platforms, check out our guide on Salesforce security best practices and learn how to prevent OAuth token abuse in your organization.

The Bigger Picture: Cloud Trust Is a Double-Edged Sword

This isn’t a Salesforce problem. It’s a cloud ecosystem problem. Every major platform — from AWS to Google Workspace — relies on OAuth trust chains. And every one of them is vulnerable to the same kind of abuse.

The ShinyHunters-linked campaign is a wake-up call. Not because the attackers are particularly sophisticated, but because they’re exploiting something so basic: the trust we extend to the apps and people around our core platforms.

That trust is essential for modern business. But without proper oversight, it’s also the easiest door to leave unlocked.