Trudi is an MCP server that autonomous DFIR agent — SANS SIFT Workstation MCP server for incident response. Its tool list has not been published yet over stdio and sse, requires no API key, and scores 44/100 on MCPpedia's security, maintenance and efficiency rubric.
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"trudi": {
"args": [
"vllm"
],
"command": "uvx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
Autonomous DFIR agent built on the SANS SIFT Workstation. TRUDI runs a complete incident response investigation — disk triage, memory forensics, Windows artifact parsing, IOC enrichment, YARA hunting — and produces a structured analyst report with a full audit trail, without prompting for confirmation at each step.
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
uvx 'vllm' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
vLLM: Completion prompt lists fan out into unbounded engine requests
## Summary The `/v1/completions` request model accepts `prompt` as a list of text prompts or a list of token-id prompts without any outer prompt-count bound. The serving path turns each element into a separate engine input, creates one engine generator per element, merges all generators, and allocates a response slot per prompt. An authenticated API client can therefore turn one request into an attacker-chosen number of backend subrequests before any aggregate request-count budget is enforced.
vLLM has Remote DoS via Invalid Recovered Token Reinjection
## Summary A frontend-legal multi-request speculative workload can make vLLM produce an out-of-vocabulary recovered token equal to `vocab_size`, convert that value to `-1` when choosing the next live token for a request, and then feed that `-1` back into the next drafter input ids. On Qwen3 GPTQ this reaches the worker-side drafting / attention path and crashes the engine with a GPU `device-side assert`. The same issue is reachable through the public gRPC request surface by sending a specific
vLLM: OOM Denial of Service via Audio Decompression Bomb
### Summary vLLM's `/v1/audio/transcriptions` endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. Tested on vLLM v0.19.0. ### Details `SpeechToTextProcessor` rejects uploads over `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` (default 25MB) based on compressed byte length, but the audio decoder in `audio.py` accumulates all decoded frames into memory with no size limit before returning: ```python # speech_to_text.py L184-189
>= 0source →vLLM: incomplete CVE-2026-22778 fix leaks PIL repr addresses via Anthropic router
# vLLM: incomplete CVE-2026-22778 fix leaks PIL repr addresses via the Anthropic API router **Researcher:** Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research **Severity:** CVSS 3.1 5.3 (Medium) `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N` **Target:** https://github.com/vllm-project/vllm --- ## Summary The fix for CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv (PRs #31987 and #32319) introduced `sanitize_message` and applied it at four FastAPI exception-handling sites in the O
>= 0source →vLLM: GGUF dequantize kernel int truncation exposes uninitialized GPU memory in multi-tenant serving
## Summary Integer truncation of tensor dimensions in vLLM's GGUF dequantize kernels (`csrc/quantization/gguf/gguf_kernel.cu`) causes partial tensor processing. The output tensor is allocated at full size via `torch::empty` (uninitialized memory), but the dequantize CUDA kernel processes only a truncated number of elements. The unfilled portion of the output tensor retains whatever was previously in GPU memory. In multi-tenant inference deployments, this residual GPU memory may contain tensor d
>= 0.5.5source →Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in other
Compress tool outputs, logs, files, and RAG chunks before they reach the LLM. 60-95% fewer tokens, same answers. Library, proxy, MCP server.
Transport for TMCP using STDIO
The graph based agentic IDE
Buddhist canon tools: search, passages, cross-canon parallels, dictionaries — all URN-cited.
MCP Security Weekly
Get CVE alerts and security updates for Trudi and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
Threat Response Unit for Digital Investigation
Autonomous DFIR agent built on the SANS SIFT Workstation. TRUDI runs a complete incident response investigation — disk triage, memory forensics, Windows artifact parsing, IOC enrichment, YARA hunting — and produces a structured analyst report with a full audit trail, without prompting for confirmation at each step.
A separate model directs the investigation phase-by-phase, and an adversarial reviewer challenges every conclusion before it reaches the report. TRUDI only reports what survives review.
Built for the Find Evil! hackathon — SANS Institute / Devpost, April–June 2026.
This README: How it works · Prerequisites · Setup · API keys · Starting a case · Live monitoring (experimental) · What gets produced · Trace dashboard · Submission components · Tool namespaces · YARA rules · Evidence constraints · Test suite · Repository layout · License
Documentation:
| Doc | What's in it |
|---|---|
| Try It Out | Step-by-step: browse a finished run (no key) or drive a fresh investigation end-to-end |
| Architecture | Components, MCP boundary, guardrail tiers, security boundaries (Mermaid source · diagram PNG) |
| Project Description | The Devpost story — design rationale, reasoning loop, gates, curiosity budget |
| Dataset Documentation | Every case's provenance, evidence source, findings, and answer key |
| Accuracy Report | False positives, missed artifacts, hallucinations caught, confidence calibration, spoliation |
| Live-monitoring demo | (experimental) Velociraptor + victim Docker stack and the auto-protect loop walkthrough |
| Live-endpoint testing | (experimental) Read-only live.* SSH triage against a running host |
| Media | Dashboard screenshots + demo video notes |
TRUDI is a three-model system — one analyst and two independently-configured reasoning models that direct and challenge it:
Claude (primary analyst) — orchestrates the investigation, selects tools, runs them via the TRUDI MCP server, interprets output, and writes the report.
DAIR phase director (dair.*) — runs the investigation as a recursive state machine (Triage → Collect → Analyze → Scan → Report). After every tool batch, dair_assess re-reads the evidence picture, decides the next phase, and emits a bound priority_tools work order. DAIR prescribes; Claude executes. Its backend is configured independently via DAIR_BACKEND.
Adversarial reviewer (reason.*) — challenges the investigation from two directions:
Both reasoning surfaces are swappable: REASON_BACKEND and DAIR_BACKEND each accept the Claude API (default), any OpenAI-compatible endpoint, or a local Foundation-Sec-8B-Reasoning server, and may point at different models. The models exchange structured DIRECTIVES blocks that bind tool selection for the next phase. Disagreements are resolved by