One Git Import, Full Code Execution: TidGi's Unpatched 9.6 Severity Flaw

When Opening a Wiki File Means Running Someone Else's Code

On July 14, 2026, GitHub's Security Advisory Database published a critical-severity disclosure for TidGi Desktop, an Electron-based note-taking application built on top of TiddlyWiki. The flaw, tracked as GHSA-9hc2-hjx8-q6pv, lets an attacker achieve full remote code execution through nothing more exotic than a Git repository import — the exact feature TidGi advertises for sharing and syncing wikis between collaborators. A victim clones or opens a booby-trapped wiki folder, TidGi boots it, and attacker-controlled JavaScript runs with complete access to Node.js — file system, shell commands, network sockets — before the user has clicked anything beyond 'Add Workspace.'

Three Ordinary Steps, One Uncontrolled Outcome

The mechanism is not a buffer overflow or a cryptographic flaw — it is a design choice working exactly as built. TiddlyWiki's module system lets any .tid file declare itself a 'startup' module. When TidGi loads a wiki, it reads every tiddler in the folder, registers any file carrying a module-type field as executable code, then runs every registered startup module automatically, with no restriction on which files are allowed to make that claim. A tiddler is meant to be a note. In this chain, a note is also a program, and the wiki loader cannot tell the difference. The advisory's proof of concept needed a few lines of embedded JavaScript and one confirmed click to reach working shell command execution, verified against TiddlyWiki 5.4.0 and Node.js v26.

Different Product, Same Trusted-Content-as-Code Pattern

TidGi and TiddlyWiki sit outside the roughly 30 web frameworks WebPulse fingerprints via HTML and HTTP signatures across its 466K+ scanned sites — this is a desktop application, not a hosted site, and no scan data corroborates or contradicts anything here. What it shares with the frameworks WebPulse does track is the underlying design pattern: content that is imported, parsed, and treated as trusted code without a sandbox boundary. That pattern recurs across plugin architectures, template engines, and CMS ecosystems industry-wide. This single disclosure is one data point, not a measured trend — but it is a clean, verified illustration of what that pattern costs when nobody has drawn the boundary yet.

The Question for Budget Signers

Desktop knowledge-management and wiki tools are typically evaluated on collaboration features, not code-execution boundaries — procurement rarely asks whether 'import a workspace' is functionally equivalent to 'run an executable.' TidGi is a personal and small-team tool rather than enterprise infrastructure, so the direct blast radius of this specific flaw is limited. But the underlying pattern — imported content executing automatically without a sandbox — recurs across tools at every scale. That pattern becomes more consequential as repository imports, clones, and builds increasingly happen without a human pausing to look first: AI coding assistants and autonomous agents routinely pull repos and open projects as steps in their own workflows. A vulnerability class built on 'imported content executes automatically' does not require a careless human click if the agent doing the importing was never designed to pause and inspect in the first place — though no evidence currently ties this specific TidGi flaw to any agent-driven exploit chain. No vendor patch is currently available for TidGi — the advisory itself suggests technical fixes (blocking module-type declarations on user tiddlers, sandboxing execution via vm.runInNewContext) that remain unapplied, and whether the maintainer has acknowledged the report or committed to a patch timeline is not publicly documented. Until a fix ships, mitigation is procedural: restrict which repositories get imported, and confirm with any similar tool whether content ingestion doubles as code execution.

What to Ask Before the Next Wiki Import