The flaw lived in how ChatGPT trusts itself
The macOS version of ChatGPT, like most desktop AI assistants, is built from multiple components that need to talk to each other and to confirm that the component on the other end of a request is genuinely OpenAI's own code and not an impostor. That confirmation runs on digital signature checks and process-lineage verification: the app checks whether a component is signed, and separately confirms it was launched by a legitimate parent and grandparent process. Objective-See Foundation researchers found that a trusted script interpreter component inside the app would accept an untrusted script and could be manipulated into passing that script into the main ChatGPT process.
The process-lineage check was the part that should have stopped this. It is designed to confirm a component's ancestry before trusting what it sends. Researchers found they could spawn the script interpreter three separate times in sequence, satisfying the lineage requirement on a technicality while still delivering an attacker-controlled script to the core application. Patrick Wardle, the longtime macOS security researcher who leads Objective-See, described his working proof of concept as needing only about a dozen lines of code, and called the exploit itself 'insanely trivial' once the trust mechanism's gap was understood.
What an attacker would have actually gotten
Because ChatGPT's desktop app carries broad permissions by design, so it can read files, summarize documents, and increasingly act as an agent across a user's machine, a successful exploit would not have been a narrow data leak. An attacker who got a malicious script accepted by the trusted interpreter could have effectively taken over the app on the victim's machine: reading chat logs and other stored data, and reaching into connections the app itself is trusted with, such as active browser sessions.
The requests generated this way would appear to come from OpenAI's own software, because they were, in the narrow technical sense, running inside a process the operating system had already decided to trust. That is the mechanism worth sitting with. This was not malware smuggled past antivirus scanning. It was a legitimate, signed application being walked, step by step, into doing something its own trust architecture was supposed to prevent.
A pattern, not an isolated bug
Wardle has a track record here that matters for how seriously to weigh this finding. He previously found and reported a similar, since-patched flaw in the dictation feature of Meta's Muse AI assistant. He has also submitted a new finding to OpenAI concerning ChatGPT's integration with its always-on Dots assistant, which OpenAI is still reviewing, and he is slated to present on AI macOS app vulnerabilities at the Objective by the Sea security conference in November.
His framing of the underlying risk is the part enterprise buyers should take most seriously: 'Agents need a lot of access to do their job,' and, more pointedly, 'the more features, the broader the attack surface.' That is not a criticism unique to OpenAI. It is a structural description of every AI desktop agent currently shipping. The more an assistant is allowed to read, click, and act on a user's behalf, the more consequential any gap in how it verifies its own internal components becomes, and the vendor racing fastest to add agentic capability is, by definition, racing fastest to expand that surface.
OpenAI's response and what it signals
OpenAI acknowledged the flaw and logged the fix in its system change log on September 25, 2026. Company spokesperson Shane Bauer said OpenAI needs to 'move faster' on security, a candid acknowledgment worth noting given how often vendor statements on disclosed flaws lean toward minimizing scope rather than owning the gap directly. The timing is also informative on its own: the fix landed about a week before the WIRED report that made the flaw public, which suggests OpenAI had already been working the issue through its own disclosure channel before the broader write-up pushed it into view.
What the statement does not resolve is the question CTOs actually need answered: how many similar trust-boundary gaps exist in the other components of the same app, and in the agentic desktop tools from competing vendors that use broadly similar architectures. A single disclosed and patched flaw is a data point about one vendor's responsiveness. It is not evidence that the underlying class of vulnerability, trust verification between a trusted app's own internal components, has been swept for elsewhere in the same codebase or in anyone else's.
What this means for enterprise AI app approval
Most enterprise reviews of desktop AI tools stop at checking whether the binary is signed and whether the vendor has a security page. This incident shows that is necessary but nowhere near sufficient for apps that are granted system-level trust and inter-process communication privileges. A signed app can still be walked into misbehaving if the logic connecting its own components has gaps, and those gaps are invisible to a code-signing check.
Before approving any AI desktop agent for broad deployment, security teams should ask vendors directly how inter-process trust is verified between the app's own components, not only whether the app itself is signed, and whether the vendor has had independent researchers specifically probe that boundary. Wardle's research cadence against OpenAI and Meta in close succession suggests this class of bug is neither rare nor vendor-specific, and the agents your organization is rolling out this quarter almost certainly share the same architecture pattern that made this exploit possible. Procurement checklists built around code-signing and SOC 2 attestations were written for a generation of software that read and wrote files. They were not written for software that spawns its own interpreters, holds live browser sessions, and makes decisions about what to trust at runtime, and that mismatch is where the next version of this bug is most likely to surface.
-6.png?w=1024)
