@offzen/dsh-gitea-search

If the package cannot be resolved in a local node_modules/.bin, npx auto-installs (no prompt, `-y`) the latest published dsh-gitea-search from the registry and executes it at DSH startup. The code that runs can therefore differ from the version that was reviewed here, a compromised npm account or a newer publish becomes executable without review, and startup now depends on network access.

In mode=path and mode=message the query is compiled and synchronously applied to every ls-tree path / commit subject (search_gitea with regex=true). A catastrophic-backtracking pattern blocks the single MCP event loop, so every concurrent tool call stalls until the DSH client times out. Content mode is safe because the regex is handed to `git grep` and killed by the existing timeout.

run() collects every stdout chunk into an array and concatenates before `Buffer.byteLength(body) > config.maxReadBytes` is checked, so read_gitea_file on a very large file in a mirrored repository (a contributor can push a multi-GB blob) allocates the whole blob in the MCP server and can crash it.

The `!!js` tag makes the DSH loader evaluate plugin-shipped JavaScript inside the host process at profile load time. The current expressions only read environment variables, so no abuse was found, but any future edit to this file can execute arbitrary code with DSH privileges without touching the audited .mjs sources.

Repository metadata from the Gitea/Forgejo HTTP API is used verbatim as a clone destination (and `repo.full_name` in remoteUrl). A hijacked or deliberately hostile server, or an unexpected API payload, could direct `git clone --mirror` outside the mirror directory. Normal Gitea instances validate names, so this is a hardening gap rather than a demonstrated attack.