Perplexity Just Called Security Research “Fake News.” SquareX Fired Back Hard

Perplexity AI walked straight into a security controversy. Now both sides are claiming victory while researchers caught in the middle try to figure out who’s telling the truth.

SquareX dropped a bombshell report accusing Perplexity’s Comet browser of hiding a dangerous API. Then Perplexity called the entire report “entirely false” and blamed “fake security research.” But SquareX isn’t backing down. In fact, they claim Perplexity quietly patched the vulnerability right after their disclosure.

This isn’t just tech drama. It’s a window into how AI companies handle security disclosures when billions are at stake.

The Original Accusation: A Hidden API That Shouldn’t Exist

SquareX discovered what they called a critical vulnerability in Comet, Perplexity’s AI-powered browser. The issue? A hidden MCP API embedded in the browser’s Agentic extension.

Traditional browsers like Chrome, Safari, and Firefox explicitly prohibit extensions from executing arbitrary local commands. That’s a fundamental security principle developed over decades. But according to SquareX, Comet broke that rule.

The MCP API could trigger from the perplexity.ai webpage itself. So if an attacker compromised Perplexity’s site, they’d potentially gain access to every Comet user’s device. That’s a nightmare scenario.

Kabilan Sakthivel, researcher at SquareX, didn’t mince words. He said the approach “reverses the clock on decades of browser security principles.” Plus, unlike standard browsers, Comet allegedly didn’t obtain explicit user consent for local system access.

Perplexity’s Strong Rebuttal: “Entirely False”

Perplexity responded with both barrels. Spokesperson Jesse Dwyer called SquareX’s report “entirely false” and part of a growing “fake security research” problem.

Their defense rested on three key points. First, the vulnerability requires developer mode to be enabled. Users must manually turn it on and sideload malware themselves. So it’s not a passive threat anyone can exploit remotely.

Second, Perplexity insists they do obtain user consent. When installing local MCPs, users set up the integration themselves and specify exactly what commands to run. Moreover, any additional commands from the MCP require user confirmation.

Third, what SquareX calls a “hidden API” is actually just how Comet runs MCPs locally with permission. It’s not secret or malicious. Therefore, according to Perplexity, the entire premise is wrong.

Dwyer also dropped a procedural complaint. He said SquareX didn’t submit a proper vulnerability report. Instead, they sent a Google Doc link with no context and no access. When Perplexity requested access, SquareX never responded.

SquareX Doubles Down With New Evidence

But SquareX wasn’t done. They countered Perplexity’s response with fresh claims.

Most damning? SquareX says Perplexity made a “silent update” to Comet after their disclosure. Now the same proof-of-concept returns “Local MCP is not enabled.” In other words, Perplexity quietly fixed the issue without acknowledging the vulnerability existed.

Furthermore, SquareX claims three external researchers independently replicated the attack. That suggests the vulnerability was real and exploitable, not theoretical or impossible as Perplexity implied.

SquareX concluded on a diplomatic note. They said the silent fix is “excellent news from a security perspective” and they’re glad their research made Comet safer. However, they maintain they never heard back from Perplexity on their vulnerability disclosure submission.

Who’s Right? The Evidence Doesn’t Add Up Cleanly

Both sides present compelling arguments. Yet their stories contradict each other on basic facts.

Perplexity says SquareX sent an inaccessible Google Doc and never followed up. SquareX says they submitted a proper vulnerability disclosure and got ignored. One of these statements is false.

Similarly, Perplexity says the API requires deliberate user action with developer mode enabled. SquareX says external researchers replicated the exploit. If it requires manual malware sideloading, how did three independent researchers successfully demonstrate the attack?

Then there’s the silent update. If no vulnerability existed, why did Perplexity change Comet’s behavior shortly after SquareX’s disclosure? Companies don’t patch code that isn’t broken.

On the other hand, SquareX’s original report may have lacked nuance. Perhaps the vulnerability required specific conditions Perplexity correctly identified. But calling the entire report “fake security research” seems excessive if they fixed the underlying issue anyway.

The Bigger Problem: Transparency in AI Security

This controversy highlights a growing issue in AI development. Security researchers and AI companies increasingly clash over vulnerability disclosures.

Traditional tech companies have established processes. Bug bounty programs, coordinated disclosures, and CVE assignments create clear pathways. But AI companies often lack these structures. So researchers don’t know where to report issues or how long to wait before going public.

Moreover, AI companies face immense pressure to ship fast. Security reviews slow development. When researchers find problems, companies sometimes respond defensively rather than collaboratively. That damages trust and makes the internet less safe for everyone.

Perplexity mentioned this is SquareX’s “second time presenting false security research.” If true, that’s concerning. Security researchers have a responsibility to be accurate. False alarms waste resources and cry wolf when real threats emerge.

However, dismissing legitimate security concerns as “fake news” is equally problematic. Even if SquareX’s report had technical inaccuracies, calling it fake research rather than addressing the underlying concerns poisons the well.

What This Means for Comet Users

Should you stop using Comet? Probably not, but with caveats.

If SquareX is correct, Perplexity already fixed the vulnerability through their silent update. So current versions should be safer than the one researchers tested. Plus, even in the vulnerable version, exploiting the issue required specific conditions.

Still, this controversy raises questions about Comet’s security practices. Does Perplexity have a formal vulnerability disclosure program? Do they conduct regular third-party security audits? How quickly do they patch issues after discovery?

Traditional browsers have decades of security hardening. Comet is new. So expect more growing pains as security researchers probe its defenses. That’s normal for any new browser.

Just keep developer mode disabled unless you specifically need it. Don’t install extensions from untrusted sources. And watch for updates addressing security issues.

The Industry Needs Better Standards

AI browsers represent exciting innovation. But they can’t skip fundamental security principles in pursuit of features.

The industry needs clearer standards for AI browser security. What APIs should be allowed? How should extensions access local systems? What consent flows are acceptable? Right now, every company makes different choices.

Regulatory bodies should consider AI browser security frameworks. Not heavy-handed rules that stifle innovation. But baseline requirements that protect users while allowing experimentation. Think seat belts, not speed governors.

Security researchers also need clearer guidelines. When should they go public with AI vulnerabilities? How long should they wait for responses? What disclosure format works best for AI companies versus traditional software?

Both sides share responsibility for making this ecosystem safer. Researchers should be thorough and fair. Companies should be transparent and responsive. Users deserve both innovation and security.

For now, watch this space. The Perplexity versus SquareX dispute probably won’t end here. More evidence will emerge. Other researchers may weigh in. And we’ll learn whether Comet truly had a serious vulnerability or if SquareX got it wrong.