Garita MCP

Garita MCP — 远程服务

这会将 Garita MCP 从“人类打开的页面”转变为“AI Agent 可直接调用的服务”。它提供了 30 个任何 MCP 客户端都可以调用的工具：

• audit_mcp_server — 审计 MCP 服务的清单（与在 garita-mcp.html 中测试的引擎相同，版本 4，经过 3 轮攻击），并返回 0 到 100 的评分。

• simulate_approval — 判断是否应自动批准 Agent 的操作，或将其暂缓以供人工审核。

• detect_poisoned_tool_descriptions（Garita Escudo）— 分析 MCP 工具的一个或多个描述文本，查找隐藏或注入的指令（不可见字符、Unicode 隐写术、同形异义字符、多层 HTML 实体、伪装的隐藏指令、要求向用户隐瞒操作或操纵其他工具的指令、重定向数据的指令，或仅在审批完成且获得凭据/SSH 访问权限后才触发的指令）。它使用的引擎与在 garita-tools/garita-escudo/tool.html 中测试的引擎相同（版本 4，经过 4 轮攻击），并移植到了 Node（lib/escudo.js）——规则相同、解码顺序相同、评分相同，只返回 JSON 而非 HTML。

• check_known_vulnerabilities — 通过查询开放数据库 OSV.dev（免费，无需 API 密钥），检查某个包（npm、PyPI、Go、crates.io、Maven、RubyGems 等）是否存在已知且已公开的漏洞。它会返回每个漏洞的官方 CVE（如果存在）、严重程度、日期和链接。与其他工具不同，此工具依赖外部服务（OSV.dev）——如果该服务出错或无响应，此调用不会扣除任何使用次数或点数（会自动退款，参见 lib/vulnerabilidades.js 和 licensing.refundUse），因为客户端没有收到任何实际结果。

• detect_tool_rug_pull — 比较同一 MCP 服务清单的两个版本（你之前批准的版本和当前版本），并在已批准工具的文本发生变化时发出警告。它能检测被称为“MCP Tool Rug-Pull”的已知模式（归类为 ATR-2026-00581、OWASP Agentic ASI02/ASI05、MITRE ATLAS AML.T0053/T0051/T0104）：某个工具在获批时看似无害，但其描述之后被重新定义，加入危险指令。detect_poisoned_tool_descriptions 检查的是某个时间点的快照；此工具则检查自上次以来是否发生变化——二者互为补充。构建于 lib/rugpull.js，并复用 Garita Escudo 引擎来分析变化内容。

• detect_poisoned_config_files — 第六个工具（2026-09）。分析代码 Agent 会加载并立即信任、且不经过任何审批步骤的配置/指令文件（AGENTS.md、CLAUDE.md、.cursorrules、“skills” 文件等）——这是与 MCP 清单完全不同的渠道，detect_poisoned_tool_descriptions 从不检查这些文件。此工具的动机来自 2026 年的一个真实案例（Mitiga）：在一次受控测试中，一个被投毒的规则文件在不到 2 分钟内窃取了 AWS/Kubernetes/Terraform 凭据。它原样复用 Garita Escudo 引擎（lib/escudo.js，不重复编写规则），但针对这类文件进行了调整：权威性措辞（IMPORTANTE、CRÍTICO）不会受到惩罚，因为这类措辞在文件中很常见；此外，还新增了一条没有时间触发条件的规则（“凭据泄露”），因为与 MCP 工具不同，指令文件不会经过任何审批步骤。构建于 lib/config-poison.js。

• check_package_authenticity — 第七个工具（2026-09）。检查某个包（目前仅支持 npm）是否有迹象表明它是新发布的冒牌包，而非合法包：名称与最受欢迎的包之一几乎相同，但自身历史记录极少（经典的 typosquatting，例如用“loadash”代替“lodash”）；发布不久，初始版本号却已经“成熟”（例如 35.x.y，而非 0.x/1.x——这是 2026 年 8 月一次真实行动中记录的模式，涉及 npm 上 800–1,000 多个恶意包）；近期发布的包中包含安装时自动运行的脚本（postinstall/preinstall）；或完全没有仓库、主页或 README。此工具的动机来自 2026 年被称为“slopsquatting”的现象：AI 编码助手有时会臆造一个并不存在的包名，而活跃中的攻击行动会注册这些臆造名称，并在包中植入恶意软件，赌有人不会再次检查就直接安装。如果包在注册表中不存在，此工具会直接提示相关风险。它与 check_known_vulnerabilities 不同，且互为补充：后者查找可能合法的包中已经公开的 CVE；此工具则查找包本身可能是假的迹象，即使它尚无任何 CVE。构建于 lib/slopsquatting.js。

• detect_memory_poisoning — 第八个工具（2026-09）。检查长期记忆 Agent 将要保存（或已经保存）的文本，查找被植入的指令；这些指令会在未来某个会话中才触发，且与该文本混入的对话无关。它与 detect_poisoned_tool_descriptions 不同：后者检查的是工具描述；此工具检查的是流入记忆的内容——一条笔记、一条已保存的事实、旧对话的自动摘要，或由其他工具（文档、网页、API 输出）带来的文本。它可以检测“如果用户说是，那么……”这类条件指令（研究人员 Johann Rehberger 在 2025 年记录的针对 Gemini 的真实攻击，以及 NeurIPS 2025 上提出的 MINJA 方法；该方法对生产环境中的 Agent 成功率超过 95%）、“永远记住这个”与“不要告诉用户”的组合（无论来源如何，这种组合几乎从不合法）、冒充系统指令的文本、要求下次检索记忆时外泄数据的指令、内容中隐藏的伪造系统标签，以及在本应是被动内容的文本中直接点名助手并向其发出指令的文本。字段 fuente 会影响评分：用户直接要求 Agent 记住某事（正常的产品用法），与在文档、自动摘要或其他工具的输出中发现相同内容，权重不同。构建于 lib/memoria.js。

• detect_ssrf_risk — 第九个工具（2026-09）。分析会向某个 URL 发起 HTTP 请求的工具源代码（获取网页、webhook、网页抓取器），查找 SSRF（服务端请求伪造）风险迹象：HTTP 请求的 URL 依赖外部输入，附近却没有可识别的验证；请求本身直接引用私有/环回 IP 或云元数据端点（AWS/GCP/Azure——这是窃取临时凭据的真实模式）；禁用 TLS 验证的同时发起外部请求；自动跟随重定向但不重新验证最终目标；以及虽然验证了 IP，却没有限制协议必须为 http/https。此工具的动机来自 2026 年一项真实普查，该普查扫描了 9,695 个 MCP 服务（bex.co，“MCP Vulnerability Census”）：SSRF 占发现的 4,982 个问题中的 8.5%（422 例）；在存在安全问题的服务中，60% 有至少一个问题，而其中只有 8.5% 真正使用 OAuth。这是一种基于文本模式的静态分析（不执行任何内容），采用与 Garita Escudo 相同的方法。构建于 lib/ssrf.js。

• detect_path_traversal_risk — 第十个工具（2026-09）。分析会根据 Agent 传入的路径读取、写入或删除文件的工具源代码（打开文档、保存附件、导出报告），查找路径穿越风险迹象：文件操作的路径依赖外部输入，附近却没有可识别的验证来防止转义序列（“../”）；操作本身直接引用系统敏感路径（/etc/passwd、SSH 密钥、凭据文件）；以及没有明确拒绝绝对路径——即使过滤了“../”序列，直接使用绝对路径仍可能逃出允许的目录。此工具的动机来自 2026 年对 9,695 个 MCP 服务进行扫描的普查；路径穿越是实际漏洞中规模最大的类别：任意文件访问占发现的 4,982 个问题中的 17.7%（880 例），高于拒绝服务、命令注入或 SSRF。真实案例：Excel MCP 服务中的 CVE-2026-40576（CVSS 9.4，严重级），其路径函数既允许绝对路径，也允许“../”序列，且不会将路径解析到允许的目录下。采用与 detect_ssrf_risk 相同的静态分析方法。构建于 lib/traversal.js。

• detect_command_injection_risk — 第十一个工具（2026-09）。分析会根据 Agent 传入的输入执行操作系统命令的工具源代码（文件名、搜索参数或任何参数），查找命令注入风险迹象：始终调用 shell 的函数（exec、execSync、os.system、os.popen、shell_exec、passthru、system 及其等价函数）接收依赖外部输入的参数，附近却没有可识别的验证或转义；仅在满足条件时调用 shell 的函数（Node 的 spawn/execFile、Python 的 subprocess.run/Popen/call）只有明确带有 shell:true/shell=True 选项时才会被标记为风险——没有此选项时，参数数组会直接执行，不经过任何 shell 解释器，因此不会被标记为风险；“下载并执行”模式（curl/wget 直接通过管道连接到 bash/sh）；以及没有任何可识别的 shell 元字符过滤（;、&&、|、反引号、$()、>、<）——只检查命令第一个 token 的允许命令列表，会放过在该 token 后串联的任何内容。此工具的动机来自 2026 年对 9,695 个 MCP 服务进行扫描的普查；命令注入是实际漏洞中规模第二大的类别，占发现的 4,982 个问题中的 9.6%（476 例），仅次于任意文件访问。真实案例：mcp-shell 中的 CVE-2026-55581/55582/55580（CVSS 最高 8.6），其“安全模式”只会将命令的第一个 token 与白名单进行比对；以及 mcp-remote 中的 CVE-2025-6514（CVSS 9.6，严重级）。采用与 detect_ssrf_risk 和 detect_path_traversal_risk 相同的静态分析方法。构建于 lib/command-injection.js。

• detect_sql_injection_risk — 第十二个工具（2026-09）。分析会根据 Agent 传入的输入执行 SQL 查询的工具源代码（用户名、搜索过滤条件或任意标识符），查找两种不同的风险迹象：（1）经典的注入模式——执行原始 SQL 的调用（.query、.execute、.raw、.exec_driver_sql、mysqli_query 及其等价函数）通过拼接或插值变量/外部输入来构造查询，而非使用预编译参数，且附近没有可识别的转义函数；（2）Garita 特有、由真实案例促成的模式：代码（或其注释/描述）声称该工具“只读”，但没有迹象表明此限制在数据库层面真正生效——这正是 Datadog Security Labs 在 Anthropic 的 Postgres 参考 MCP 服务中发现的情况，其中“只读”限制仅存在于 Agent 读取的文本中，而非真实权限设置中。此工具的动机来自 2026 年一项对 9,695 个 MCP 服务进行扫描的真实普查：SQL 注入占发现的 4,982 个问题中的 4.2%（211 例）。CVE-2026-7206（sqlite-mcp）和 CVE-2025-66335（Apache Doris MCP Server）中也记录了此类问题。采用与 detect_ssrf_risk、detect_path_traversal_risk 和 detect_command_injection_risk 相同的静态分析方法。构建于 lib/sql-injection.js。

• detect_token_passthrough_risk — 第十三个工具（2026-09）。分析会处理调用者授权令牌的中间件或 MCP 工具源代码，查找 MCP 规范明确禁止的“令牌透传”（困惑代理）反模式：服务不得接受或转发并非为其签发的令牌。此工具查找四种迹象：（1）中间件在没有可识别的授权验证之前就放行请求（next()/call_next()）——这是 CVE-2026-48039（Meta Ads MCP，CVSS 9.1，严重级）背后的确切模式；其中 dispatch() 转发请求时没有验证 Authorization 标头，导致运营者的长期令牌泄露；（2）将传入请求的令牌原样转发到另一个出站调用，既不重新验证，也不重新签发自己的令牌；（3）验证 JWT（jwt.verify/jwt.decode）但不验证 audience/aud 声明，因此无法区分为此服务签发的令牌与为任何其他服务签发的令牌；（4）将令牌放在 URL 参数中，而非标头中，导致令牌暴露在日志和 Referer 标头中。同样的未经验证转发模式也出现在 CVE-2025-6514（mcp-remote，CVSS 9.6）和 CVE-2026-27826（MCP Atlassian，CVSS 8.2）中。采用与 detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk 和 detect_sql_injection_risk 相同的静态分析方法。构建于 lib/token-passthrough.js。

• detect_hardcoded_secrets_risk — 第十四个工具（2026-09）。分析源代码或配置文件（包括 mcpServers 的 env 块或 .env 文件），查找未从环境变量或密钥管理器读取、而是以明文形式直接写入的凭据：（1）格式可识别的真实凭据字符串（OpenAI、AWS、GitHub、Slack、Google 的密钥，或 PEM 私钥标头）；（2）名称表示凭据的变量或配置项（api_key、secret、token、password 等）在代码中直接赋有字面值；（3）类似 .env 的行将字面值赋给名称表示凭据的环境变量；（4）具有硬编码备用值（“fallback”）的环境变量，从一开始就违背了使用环境变量的目的。此工具的动机来自 Hush Security 于 2026 年 9 月发布的一份真实报告，该报告扫描了 GitHub 上约 82,000 个公开 MCP 配置文件：12% 的凭据字段嵌入了字面密钥，其中 53% 拥有整个组织级别的访问权限，55% 不符合任何已知的令牌格式。Trend Micro 也记录了此类问题（19,402 个 MCP 服务中有 48% 存在不安全的密钥存储），并将其归类为 OWASP MCP Top 10 中的 MCP01。它能识别常见占位符/示例值（“your-api-key-here”、“changeme”、AWS 官方示例密钥），以避免将其标记为风险。采用与 detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk、detect_sql_injection_risk 和 detect_token_passthrough_risk 相同的静态分析方法。构建于 lib/hardcoded-secrets.js。

• detect_insecure_deserialization_risk — 第十五个工具（2026-09）。分析会对数据（AI 模型、配置文件、已保存对象）进行反序列化的 MCP 工具源代码，查找读取数据时可能执行任意代码的函数：（1）没有任何安全变体的函数（pickle.load/loads、cPickle、marshal.loads、dill.loads、joblib.load、PHP 的 unserialize()）；（2）只有在未使用安全选项时才危险的函数——yaml.load() 未设置 Loader=yaml.SafeLoader（或使用 yaml.safe_load()），以及 torch.load() 未设置 weights_only=True；（3）重建对象时会执行系统命令的 __reduce__/__reduce_ex__ 方法——这是恶意 pickle 载荷的经典特征。此工具的动机来自 ModelCache 中的 CVE-2025-45146（CVSS 9.8，严重级）；ModelCache 是一个面向 Agent/LLM 的缓存库，会对未经验证的字节调用 torch.load()。此外，CVE-2025-32434（CVSS 9.3）表明，在 PyTorch 2.6.0 之前的版本中，仅设置 weights_only=True 甚至也不足以确保安全。它能将受限的 Unpickler（RestrictedUnpickler/find_class）识别为已采取实际预防措施的迹象。采用与 detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk、detect_sql_injection_risk、detect_token_passthrough_risk 和 detect_hardcoded_secrets_risk 相同的静态分析方法。构建于 lib/deserialization.js。

• detect_toxic_flow_risk — 第十六个工具（2026-09）。与其他一次分析一个代码函数的检测工具不同，此工具会分析 MCP 服务的完整清单——与 audit_mcp_server 一样——查找多个工具间危险的能力组合：一个工具读取私有/敏感数据（本地文件、数据库、凭据、私有仓库）或外部不可信内容（电子邮件、网页、公开 issue/ticket、附件），另一个工具可以向外部发送/发布数据（电子邮件、HTTP、webhook、创建公开评论或 issue、上传附件），但其输入架构中没有任何必需（required）的确认字段——每个工具单独来看都可能描述得十分完善，也没有任何问题；风险在于它们的组合（“困惑代理”/“致命三角”）。如果完整的三个要素同时存在，即私有数据 + 不可信内容 + 出站渠道，此工具会标记为更严重。此工具的动机来自 CVE-2026-77255（mcp-atlassian，CVSS 8.6，2026 年 9 月）——某个工具的附件参数可以读取任意本地文件，并将其上传到 Jira ticket——、EchoLeak/CVE-2025-32711（Microsoft 365 Copilot，CVSS 9.3，第一个真实的零点击提示词注入漏洞），以及 Invariant Labs 报告的 GitHub MCP 服务案例（“Toxic Flow Analysis”）。它与 audit_mcp_server（清单总体评分）和 detect_poisoned_tool_descriptions（单个描述中隐藏的文本）互为补充——它检查 Agent 同时可用的工具之间如何交互。构建于 lib/toxic-flows.js。

• detect_ssti_risk — 第十七个工具（2026-09）。分析会编译模板的工具源代码（Jinja2、EJS、Handlebars、Pug、Mustache、lodash 或 LangChain 的 PromptTemplate），查找非开发者编写的模板来源——外部变量/输入被用作模板文本，而不是作为数据填入固定模板。这类模板引擎大多允许在模板中调用方法和遍历对象属性，因此攻击者控制的模板可能导致服务器执行任意代码（SSTI）——这与 XSS 不同，任何 HTML 分析器都无法覆盖此类问题。它还会检测 Garita 特有的虚假安全感：代码声称已通过“转义输出”受到保护（autoescape=True、html.escape、MarkupSafe）——这是真正防御 XSS 的措施，但与此处无关，因为代码执行发生在编译模板时，早于任何输出可供转义。它能将 Jinja2 沙盒环境（SandboxedEnvironment）识别为实际的缓解措施。此工具的动机来自 Dynaconf 中的 CVE-2026-33154（CVSS 8.1）；Dynaconf 是一款被 AI/Agent 应用广泛使用的配置库。其他案例包括：Agenta-AI（一款 LLM 评估平台）因自定义评估器的 Jinja2 模板而出现 SSTI 漏洞；以及最常用的 Agent 框架 LangChain 本身因提示词模板中的属性访问而出现注入漏洞。采用与 detect_sql_injection_risk、detect_command_injection_risk 和 detect_insecure_deserialization_risk 相同的静态分析方法。构建于 lib/ssti.js。

• detect_dynamic_code_risk（动态代码防护）——第十八个工具（2026-09）。分析源代码，查找不可信动态代码执行（CWE-95）：eval()、JS 的 Function() 构造函数、Python 的 exec()，以及 Node 的 vm 模块变体（vm.runInContext/runInNewContext/runInThisContext）在接收开发者未编写的文本时被调用的情况——例如变量、模型的回答、从 RAG 工作流中检索的文档或工具参数，而不是固定文本。还会检测“隐式 eval”模式：setTimeout()/setInterval() 接收字符串而非函数引用。还会检测 Garita 特有的虚假安全感：使用 vm2 库“沙箱化”执行并非真正的缓解措施——vm2 自 2023 年起因多次有记录的严重沙箱逃逸而被官方弃用（CVE-2023-32314、CVE-2023-37903、CVE-2023-37466）；该工具会将 isolated-vm（基于 V8 Isolate 的真正隔离）识别为有效的缓解措施。该工具由 CVE-2026-26030（CVSS 9.8，2026 年 2 月）引出：在 Microsoft Semantic Kernel 中，向量存储（InMemoryVectorStore）过滤器将索引文档中检索到的内容——RAG 工作流中的投毒数据，而非直接的用户输入——直接插入通过 eval() 求值的表达式，导致 Agent 进程中出现完全的 RCE。采用与 detect_ssti_risk 相同的静态分析方法，且与 detect_command_injection_risk 检测的是不同类型的漏洞：后者调用外部 shell（CWE-78），而此处是在 Agent 自身的解释器／引擎中直接求值代码。构建于 lib/dynamic-code.js。

• detect_dns_rebinding_risk（DNS 重绑定防护）——第十九个工具（2026-09）。分析用于构建 MCP 服务 HTTP/SSE 传输层的代码（StreamableHTTPServerTransport/SSEServerTransport 构造函数，或 /mcp 路由的注册代码），检查在处理传入请求前是否缺少对 Origin（或 Host）请求头的验证——没有这项验证，受害者访问的恶意网页就能让浏览器直接与该服务通信；该服务通常运行在 localhost，浏览器会将其当作可信的 MCP 客户端（“DNS 重绑定”）。此外，还会检测 Garita 特有的一种常见误解：认为只将服务绑定到 localhost/127.0.0.1 就能提供保护——这并不能防止重绑定，因为攻击者可以注册一个域名，先让它解析到自己的服务器，再更改 DNS，使其解析到 127.0.0.1；唯一真正有效的防御措施是根据明确的允许列表验证 Origin 请求头。此工具的设计源于 2026 年反复出现的一种模式：该模式在三种不同语言的三种 MCP SDK/实现中被独立发现：Rust 官方 SDK rmcp 中的 CVE-2026-42559（CVSS 8.8）、Java SDK 中的 CVE-2026-35568，以及 mysql-mcp-server（Python）中的 CVE-2026-59971。采用与 detect_ssrf_risk 和 detect_command_injection_risk 相同的静态分析方法。构建于 lib/dns-rebinding.js。

• detect_missing_auth_risk（身份验证哨兵）——第二十个工具（2026-09）。分析用于构建 MCP 服务 HTTP/SSE 传输层的代码（StreamableHTTPServerTransport/SSEServerTransport，或 /mcp、/sse、/messages 路由的注册代码），检查在分发请求前是否完全缺少任何身份验证（CWE-306）——没有登录、没有 API 密钥、没有令牌，任何知道 URL 的人都能调用该服务的工具。此问题不同于 detect_dns_rebinding_risk：前者的问题在于请求来自何处；而这里的问题是完全没有验证请求者的身份。这是 2026 年 MCP CVE 中最常见的模式：GitLab 的 MCP 服务中存在 CVE-2026-44895（CVSS 9.1，严重），该服务没有身份验证且 CORS 完全开放——任何人都可以使用操作员的令牌调用其 86 个工具（包括删除仓库）；Azure MCP Server（Microsoft，CVE-2026-32211）、deepseek-mcp-server（CVE-2026-55605）、NetLicensing-MCP（CVE-2026-54446）、obsidian-web-mcp（CVE-2026-54618）和 mcp-documentation-server（CVE-2026-54504）也确认存在相同模式（CWE-306）。此外，还会检测 Garita 特有的一条规则：如果在缺少身份验证的同时，CORS 也完全开放（Access-Control-Allow-Origin: * 或未限制来源的 cors()），风险会显著加剧——这正是 CVE-2026-44895 可被利用的确切组合。构建于 lib/missing-auth.js。

• detect_mcp_stdio_launch_risk（MCP 启动防护（STDIO））——第二十一款工具（2026-10）。分析用于通过 stdio 传输建立 MCP 客户端连接的代码（TypeScript 的 StdioClientTransport、Python 的 StdioServerParameters），查找依赖外部输入且未使用允许启动器列表的 command 字段——构建连接时，操作系统会立即执行该命令，此时 MCP 协议尚未进行任何验证；这与 HTTP/SSE 传输不同，后者会进行身份验证或来源验证。这是 2026 年在四款官方 MCP SDK（Python、TypeScript、Java、Rust）中确认的设计缺陷。查找四种信号：(1) 动态 command 附近没有可识别的允许启动器列表验证；(2) 存在“重新水合”缺口——文件中的某处确实会根据白名单进行验证，但所分析的启动操作来自之前已保存或加载的配置，在真正启动时没有重新验证（这是 CVE-2026-30623 修复前的同类模式）；(3) 通过直接执行标志绕过——命令确实属于合理的启动器白名单（python、node 等），但其参数包含值不固定的 -c/-e/--eval，因此攻击者无须选择命令，只需选择该已获允许的命令要执行的代码；(4) 注释或文本中存在虚假的安全感——“如果不是有效的 MCP 服务，协议就会失败”，却没有意识到操作系统命令在到达该验证之前就已执行。真实案例：CVE-2026-30623（LiteLLM）——一个“测试连接”端点将用户自己传入的 command 直接交给启动器，没有将其限制为已知二进制文件的白名单；修复方案是按基本名称设置白名单（{npx, uvx, python, python3, node, docker, deno}）。CVE-2026-22688（Tencent WeKnora，CVSS 9.9）中也记录了同类模式，该模式出现在没有管理员访问控制的 /test 端点中。它与 detect_command_injection_risk 不同，但互为补充：后者涵盖通过 shell 进行的传统命令注入；本工具涵盖 MCP SDK 契约本身的缺陷，即使完全没有 shell 也会存在。构建于 lib/mcp-stdio.js。

• detect_redos_risk（反 ReDoS 防护）——第二十二款工具（2026-10）。分析会编译或应用正则表达式的工具/Agent 源代码，查找：(1) 具有“嵌套量词”形式的模式（灾难性回溯，例如 (a+)+、(\s*\w+)*、(a|a)*），被用于非固定文本输入，且附近没有可识别的长度上限、带超时的引擎或安全库（re2、safe-regex、recheck）——一个精心构造的字符串就可能让整个 Agent 进程挂起（ReDoS，CWE-1333）；(2) 从非固定文本（即不是开发者编写的固定文本）而是从变量动态编译的正则表达式（RegExp()/new RegExp()/re.compile()）——调用工具的人可以直接注入灾难性模式，或彻底改变验证逻辑。此工具的设计缘由是 CVE-2026-0621（CVSS 7.5）：存在漏洞的模式位于单个可在无需身份验证的情况下访问的格式验证函数中，一个请求就足以耗尽进程线程。它能识别直接包装在安全引擎构造函数（new RE2(...)）中的恶意正则表达式，并将其视为有效缓解措施。与 detect_dynamic_code_risk 和 detect_ssti_risk 采用相同的静态分析方法。构建于 lib/redos.js。

• detect_session_hijack_risk（会话劫持防护）——第 23 个工具（2026-10）。分析查找或生成客户端会话的代码，检测以下问题：（1）仅凭请求携带的标识符解析会话（sessions[id]/.get(id)/.findOne({id})），之后不再将任何所有者/主体字段（userId/owner/accountId）与当前发起请求的人进行比较——任何拿到该 ID 的人（通过猜测、从日志中窃取或拦截）都能完全继承其他客户端的会话（CWE-384）；（2）使用低熵方式生成会话标识符（仅用 Math.random()、Date.now()/time.time()，或递增计数器），而不是使用加密安全的生成器（crypto.randomBytes/randomUUID、secrets.token_hex），因此可被暴力猜出。它能识别显式的所有者比较，或经过签名和验证的令牌（jwt.verify、crypto.timingSafeEqual）作为真实关联；并能区分读取查询（有风险）和创建会话的写入操作（sessions[id] = {...}，单独来看没有风险）。与 CVE-2026-52869 背后的模式相同。采用与 detect_missing_auth_risk 和 detect_token_passthrough_risk 相同的静态分析方法。在 lib/session-hijack.js 中实现。

• detect_oauth_audience_confusion_risk（OAuth 受众混淆防护）——第 24 个工具（2026-10）。比 detect_token_passthrough_risk（它只查看 “audience”/“aud” 是否在附近出现，这只是表面信号）更深入地分析服务端自有的 OAuth/JWT 令牌验证器：检测验证确实存在但存在隐蔽缺陷的情况——（1）验证受配置标志（config.checkAudience、options.strictMode）控制，且该标志可能被关闭；（2）“不匹配”分支只记录警告，而不拒绝请求（没有 throw/return/res.status）；或（3）catch() 块会吞掉库检测到不匹配后抛出的错误；同时也检测完全没有任何受众检查的情况。在前三种情况下，代码“有”一项验证，匆忙阅读的人会以为它有效，但实际上它会放行发给其他服务器的令牌（通过受众混淆造成的困惑代理问题）。与 CVE-2026-14541 背后的模式相同。采用与 detect_token_passthrough_risk 和 detect_missing_auth_risk 相同的静态分析方法。在 lib/oauth-audience.js 中实现。

• detect_unbounded_allocation_risk（无界分配防护）——第 25 个工具（2026-10）。分析代码以查找内存/CPU 耗尽风险（CWE-770）：（1）将整个请求体或文件读入内存，但未配置任何大小上限（express.json()/bodyParser 中没有 limit，手动累积 req.on('data') 流时没有大小检查，或使用非固定路径读取文件前没有调用 fs.statSync()）；（2）数组/缓冲区分配（new Array()/Buffer.alloc()），或循环，其大小/迭代次数直接来自变量，且事前没有任何上限（Math.min/与最大值比较）——一条消息或一个大数值就可能耗尽 Agent 进程的内存或 CPU。与 CVE-2026-14539 背后的模式相同。采用与 detect_dynamic_code_risk 和 detect_ssrf_risk 相同的静态分析方法。在 lib/unbounded-allocation.js 中实现。

• detect_cross_client_leak_risk（跨客户端泄漏风险防护）——第二十六个工具（2026-10）。分析用于构建 MCP 服务 HTTP 传输的代码，查找：（1）在模块级（任何路由处理器之外）声明的 McpServer/Server 实例，并在处理器中与 StreamableHTTPServerTransport 一起复用——不同客户端连接共享同一个服务，可能导致一个客户端的状态/响应泄漏给另一个客户端；以及（2）在模块级声明、并在 registerTool/tool 回调中引用的可变状态（let/var）——在此处跨请求持久存在的任何变量，实际上都是不应存在的客户端间共享状态。该工具的设计动因是 MCP 官方 TypeScript SDK 中的 CVE-2026-25536（CVSS 7.1，影响 v1.10.0–v1.25.3 版本）：在多个客户端之间复用单个 McpServer 实例与 StreamableHTTPServerTransport，会导致一个客户端的响应状态泄漏给另一个客户端——该问题被列为 OWASP MCP Top 10 中的 MCP10（“上下文注入与过度共享”）。通过计算处理器范围，区分真正位于模块级的实例/变量与在每个处理器内部重新创建的实例/变量（安全）。在 lib/cross-client-leak.js 中实现。

• detect_sampling_hijack_risk（Sampling 劫持风险防护）——第二十七个工具（2026-10）。分析处理来自 MCP 服务的传入 Sampling 请求的客户端/HOST 端代码（setRequestHandler(CreateMessageRequestSchema, ...) 或字面方法名 'sampling/createMessage'）——这是 MCP 的一项功能，允许服务请求客户端的模型生成补全，而不是反过来。查找：（1）处理 Sampling 请求时，在将内容发送给模型之前没有任何可识别的人工审核/批准步骤，尽管 MCP 规范本身建议执行此步骤；（2）隐蔽的工具调用——同一处理器根据生成的补全调用 callTool/executeTool，且未获得用户的明确批准，这是最严重的攻击途径；以及（3）未设置长度/token 上限（maxTokens/max_tokens），导致在用户不知情的情况下过度消耗计算资源/额度（“资源盗用”）。这类问题记录于 Unit42（Palo Alto Networks）的一项调查中，该调查于 2026 年 10 月 16 日再次报告，针对一款代码副驾驶类应用，并展示了全部三种攻击途径：资源盗用、对话劫持和隐蔽工具调用。采用与 detect_toxic_flow_risk 和 detect_missing_auth_risk 相同的静态分析方法。在 lib/sampling-hijack.js 中实现。

• detect_output_schema_ssrf_risk（输出架构防护）——第二十八个工具（2026-10）。分析客户端代码是否使用 Python 的 jsonschema 库验证 MCP 工具的 outputSchema/inputSchema，并检查是否存在以下风险：（1）通过 jsonschema.validate/Draft*Validator/validator_for 验证来自不可信 MCP 服务的架构，却没有使用任何 Registry/Resolver 来限制外部引用（$ref/$dynamicRef/$id）的解析——恶意服务可能迫使客户端向任意 URL 发起 SSRF 请求（CWE-918）；（2）在 async def 函数中发起同步网络调用（urllib.request.urlopen/requests.get-post-put-delete），既没有设置 timeout，也没有将调用交给单独的线程（asyncio.to_thread/run_in_executor）——一个始终不响应的“拖延”端点就能冻结整个进程的事件循环及其所有任务和并发会话，造成拒绝服务。此工具受到 MCP 官方 Python SDK（PyPI 上的 mcp 包，版本 1.10.0-1.29.1 和 2.0.0-2.1.1）中的 CVE-2026-116686（CVSS 6.5，CWE-918）启发；该漏洞已在 1.30.0/2.2.0 中修复，方法是仅解析文档自身内部的引用。采用与 detect_ssrf_risk 和 detect_redos_risk 相同的静态分析方法。实现位于 lib/output-schema-ssrf.js。

• detect_excessive_agency_risk（过度代理护盾）——第 29 个工具（2026-10）。与分析源代码的工具不同，该工具分析 MCP 服务的清单——与 audit_mcp_server 和 detect_toxic_flow_risk 一样，但一次只检查一个工具——以查找“过度代理”（OWASP LLM06）：工具名称或描述表明该工具可执行不可逆或高价值操作（转账、提款、付款、擦除、删除、关闭），但其输入架构中没有任何必填（required）确认字段，和／或金额／数量字段没有最大值限制（maximum/exclusiveMaximum）——没有任何机制能阻止单次调用转移任意大的金额，也没有任何机制能确保操作在执行前经过审核。该工具的设计直接受到 2026 年 10 月 Binance 遭黑客攻击事件的启发（损失 63 亿美元，是加密货币史上最大的一起盗窃案）：根据 Binance 自身的初步说法和 TRM Labs 的分析，一台设备／一份凭据遭到入侵后，攻击者便控制了有权批准提款的系统，且无需任何独立审批或单笔交易上限即可发出提款指令——这正是该工具要在 MCP 工具的输入架构中查找的设计模式，以免此类事件发生在涉及 AI Agent 的场景中。沿用 detect_toxic_flow_risk 的“真实触发器与文本声明”区分原则：单独的“请求审批”工具不算真正的缓解措施。构建于 lib/excessive-agency.js。

• detect_call_spoofing_risk（调用伪造护盾）——第 30 个工具（2026-10）。该工具分析 Agent 侧的编排代码（负责解读模型响应的层），查找从响应自由文本中提取工具调用的做法（例如 TOOL_CALL: 标记、```json 代码块或 <tool_call> 标签），而不是只从 API 的专用结构化字段（tool_calls/function_call/tool_use）中读取工具调用；只有模型真正调用了原生函数调用机制时，这些字段才会被填充。问题在于，自由文本可能包含任何进入模型上下文的内容——上传的文档、网页、先前工具的结果——如果其中已有看起来像工具调用的内容，而模型只是“重复”了它（因为有人要求模型总结、引用或翻译这些内容），编排器就无法区分重复出现的模式和模型的真实决策。这就是 “照我说的重复一遍”（"Repeat-After-Me"）攻击。GBHackers 在 2026 年 10 月的一项研究记录了针对 6 种广泛使用的 Agent 框架的此类攻击：LangGraph、Microsoft Agent Framework、Google ADK 2.0、AutoGen、AWS Strands 和 CrewAI。在这 6 种框架中，编排层都依赖对模型输出进行文本／正则表达式解析，而没有要求使用结构化函数调用 API。采用与 detect_sampling_hijack_risk 相同的基于文本模式的静态分析方法。构建于 lib/call-spoofing.js。

这 30 个工具都需要访问密钥（提供免费使用次数，之后需购买额度）——请参阅下文“访问密钥收费”一节。网页（garita-mcp.html、garita-escudo/tool.html）仍然免费且不受限制，此要求仅适用于此服务。

开始之前：它与网页有何不同

网页（garita-mcp.html）由用户在浏览器中打开，无需任何内容持续运行即可独立工作。这不一样：这是一个程序，必须始终在某台拥有公开地址（URL）的服务器上运行，其他系统才能通过互联网调用它。这意味着需要准备一些网页不需要的东西：

1. 需要将它“发布”到托管服务（Render，免费，见下文）。
2. 需要一个小型数据库，在重启后仍能记住访问密钥及其额度（Upstash，免费，见下文）。
3. 要真正收取额度费用，需要 CoinGate 账户（与你已为 Garita Labs 选择的账户相同）。
4. 你需要 GitHub、Render、Upstash 和 CoinGate 账户——它们都有免费计划，满足我们的需求时都不需要信用卡；但启用真实模式（而非测试模式）时，CoinGate 除外。

发布步骤（使用 Render，免费，无需信用卡）

1. 创建 GitHub 账户（如果你还没有）：访问 github.com，点击“Sign up”，按步骤使用你的邮箱注册。

2. 将此文件夹上传到新建的代码仓库：

• 在 github.com 上点击“New repository”（绿色按钮）。
• 为代码仓库命名，例如 garita-mcp-server。可以设为私有或公开，没有影响。
• 按照 GitHub 的说明“upload existing files”（上传现有文件），将此文件夹中的所有文件拖到页面上（server.js、package.json、lib/ 文件夹、此 README.md 以及 .gitignore——不要上传 node_modules 文件夹（如果有的话），不需要；test-*.js 也不必上传，不过上传了也没关系）。

**3. 创建 Render 账户：**访问 render.com，点击“Get Started”，你可以直接使用 GitHub 账户注册（更简单，只需点击一次）。

4. 创建服务：

• 在 Render 控制面板中，点击“New +”→“Web Service”。
• 连接你刚上传的 garita-mcp-server 代码仓库。
• Render 会自动检测到这是 Node.js 项目。保留它建议的设置（Build command：npm install，Start command：npm start）。
• 选择 Free 计划。
• 暂时不要点击“Create Web Service”——先向下滚动到此页面的“Environment Variables”部分，并完成下一步，这样服务启动时就已经配置好了。

使用访问密钥付费（免费调用次数 + 购买的额度）

每位客户端都会获得一把访问密钥（以 gar_ 开头的一长串文本）。每把密钥的前 5 次调用免费——仅限一次，之后不会重置。用完后，调用三十种工具中的任意一种（audit_mcp_server、simulate_approval、detect_poisoned_tool_descriptions、check_known_vulnerabilities、detect_tool_rug_pull、detect_poisoned_config_files、check_package_authenticity、detect_memory_poisoning、detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk、detect_sql_injection_risk、detect_token_passthrough_risk、detect_hardcoded_secrets_risk、detect_insecure_deserialization_risk、detect_toxic_flow_risk、detect_ssti_risk、detect_dynamic_code_risk、detect_dns_rebinding_risk、detect_missing_auth_risk、detect_mcp_stdio_launch_risk、detect_redos_risk、detect_session_hijack_risk、detect_oauth_audience_confusion_risk、detect_unbounded_allocation_risk、detect_cross_client_leak_risk、detect_sampling_hijack_risk、detect_output_schema_ssrf_risk、detect_excessive_agency_risk、detect_call_spoofing_risk）都会消耗 1 个额度。额度用完后，服务会返回一条说明如何购买更多额度的消息——需要收费时，绝不会放行未付费的调用。例外情况：如果 check_known_vulnerabilities 或 check_package_authenticity 因其查询的外部服务（OSV.dev 或 npm 注册表）无响应而失败，则会自动退还该次调用/额度——让客户端为自身无过错的故障付费是不公平的。

除此之外，每把密钥每天还有50 次调用的上限（lib/licensing.js 中的常量 DAILY_CALL_LIMIT，可轻松调高或调低），即使密钥还有充足额度也照常适用——这是一项独立的保护措施，旨在避免 Agent 因循环错误而在几分钟内一下子耗光所有购买的额度。该上限每天自动重置，无需你做任何操作。

企业套餐（见下方套餐表）是个例外：除了增加额度，还会永久将密钥标记为不受每日上限限制（lib/licensing.js 中的 unlimitedDaily）——适用于 Agent 会以高且稳定的调用量使用工具的客户端。在这种情况下，每天 50 次的上限会成为实际的业务限制，而不是防止滥用的保护措施。该标记一旦授予，就无法通过代码撤销（即使之后额度用完也一样）——只能通过购买该套餐或在 Upstash 手动授予（见下文）。

这需要在服务端配置两项内容：一个用于记录密钥及其额度的位置（Upstash），以及用于处理付款的 CoinGate 连接。

5. 在 Upstash 创建免费数据库（用于记录密钥和额度）

如果不配置，服务每次重启或休眠时都会“忘记”所有密钥和额度——这对于真正收费来说不可接受，因此此步骤不可省略。

1. 前往 upstash.com 并创建免费账户（可以使用 GitHub 账户）。
2. 在控制面板中创建一个新数据库：“Create Database” → 输入名称（例如 garita-licencias）→ 类型选 Redis → 选择距离 Render 服务端最近的区域 → 选择 Free 套餐。
3. 在已创建的数据库中找到 “REST API” 部分（或“Connect” → “REST API”）。你会看到需要复制的两个值：
   • UPSTASH_REDIS_REST_URL
   • UPSTASH_REDIS_REST_TOKEN

6. 创建 CoinGate 账户并获取 API 令牌

如果你在为 Garita Labs 选择 CoinGate 时已经创建了账户，可以重复使用。

1. 若要先在不涉及真实资金的情况下进行测试：在 sandbox.coingate.com 创建账户（这是独立于真实账户的测试副本）。
2. 在该账户的控制面板中，找到 “API Apps” 或 “Integrations” → 创建一个新 App → 随后会获得一个 API Token。这是测试用的 COINGATE_API_TOKEN。
3. 准备收取真实资金时，在 coingate.com 重复同样的流程（真实账户，包含身份验证），并改用另一个令牌——这是两个账户和两个完全独立的令牌，互不混用。
4. 在同一个 App 的 “Callbacks” 或 “Webhooks” 设置中，确保格式设为 JSON（而不是 form-encoded）——服务端需要这种格式。

7. 在 Render 中配置环境变量

返回 Render 的服务创建页面（如果已经创建服务，则前往 “Environment”），添加以下变量：

变量	值
UPSTASH_REDIS_REST_URL	从 Upstash 复制的值
UPSTASH_REDIS_REST_TOKEN	从 Upstash 复制的值
COINGATE_API_TOKEN	CoinGate App 的令牌（测试时用 sandbox 令牌，准备好正式收款时用真实令牌）
COINGATE_ENV	测试期间设为 sandbox，正式收款时设为 live
PUBLIC_BASE_URL	Render 提供给你的公开 URL，例如 https://garita-mcp-server.onrender.com（如果还不知道，可以先留空，等 Render 提供 URL 后再添加——没有此变量时，服务端会自行推断 URL，但手动填写更可靠）
ANTHROPIC_API_KEY	只有在想启用 Vigía 时才需要（参见下文 “Vigía” 一节）——你自己的 Anthropic API 密钥，不是客户端的密钥。没有此变量时，服务端的其余部分（通过 /mcp 提供的 30 个工具）仍会正常运行；只有 /vigia/analizar 会返回 503，提示缺少此配置。
VIGIA_MODEL	可选——Vigía 使用的 Claude 模型（默认为 claude-sonnet-4-5-20250929）。如果 Anthropic 发布了更新或更便宜的模型，可以修改此项，无需改动代码。

点击 “Create Web Service”（如果服务已创建，则保存变量——Render 会自动重启）。

8. 等待几分钟。 完成后，Render 会提供类似 https://garita-mcp-server.onrender.com 的 URL。如果你在得知最终 URL 之前就填写了 PUBLIC_BASE_URL，请再次进入 “Environment”，将其改为完全匹配的 URL，然后保存（Render 会自动重启）。

9. 测试是否正常： 在浏览器中打开该 URL——你应该会看到端点列表。看到列表就说明已经发布成功。

信用包和价格

信用包在 lib/coingate.js 中定义，可随时在那里调整：

套餐	使用次数	价格	额外权益
basico	50 次	5 USD
pro	300 次	25 USD
empresarial	5,000 次	300 USD	永久取消该密钥每天 50 次的使用上限

CoinGate 会按价格收取手续费（1%）——上表价格未扣除手续费，这是客户支付的金额。

客户端如何获取密钥并购买额度

1. 获取免费密钥： POST https://tu-servidor.onrender.com/crear-llave（不带请求体）。返回密钥，并提醒用户妥善保存——如果丢失，之后无法找回（只能重新创建一把，从头开始获得另外 5 次免费使用）。
2. 使用密钥： 连接 MCP 服务时，在请求中发送请求头 Authorization: Bearer gar_...，并附上该密钥。
3. 查询剩余额度： GET https://tu-servidor.onrender.com/consultar-llave?apiKey=gar_... ——返回免费使用次数、额度，以及当天已使用次数与每日上限。
4. 额度用完后购买额度： POST https://tu-servidor.onrender.com/comprar-creditos，请求体为 { "apiKey": "gar_...", "pack": "basico" }（也可以是 "pro"，或 "empresarial"，后者还会取消每日上限）。返回一个 CoinGate payment_url（用户在该页面使用加密货币付款）和一个 orderId——CoinGate 确认付款后，服务端会自动为密钥充值，无需你手动操作。

如果付款确认需要较长时间

加密货币付款的确认通常需要时间——从几分钟到更久不等，具体取决于当时该币种网络的拥堵程度。这并非任何环节出错：在付款确认前，密钥都不会获得额度。

CoinGate 会在付款确认后自动发送通知（webhook）。如果因为某些原因，我们的服务端没有及时收到通知（例如 Render 在免费方案下处于“休眠”状态），CoinGate 会在几天内自动重试发送，因此已确认的付款几乎不会丢失。

如果用户发消息询问“我已经付款了，为什么还没收到额度？”，你可以立即（无需等待下次重试）通过以下方式检查实际状态：GET https://tu-servidor.onrender.com/verificar-pago?orderId=EL_ORDERID_QUE_DEVOLVIÓ_/comprar-creditos。如果 CoinGate 已确认付款，这个请求会立即为密钥充值；如果付款仍处于“确认中”状态，响应会告知你，无需采取其他操作，只需等待。

手动发放密钥（例如，发给直接联系你的用户）

如果你想绕过 CoinGate，直接赠送某人额度（作为礼遇或延长试用），可以通过 Upstash 网页控制台（“Data Browser”或“CLI”选项卡）直接调用数据库，使用以下命令：

SET garita:key:gar_LO-QUE-SEA {"freeUsesRemaining":0,"credits":100,"createdAt":"2026-01-01T00:00:00.000Z"}

（将 gar_LO-QUE-SEA 替换为你自行创建并发送给用户的密钥，将 100 替换为你想赠送的额度）。如需同时赠送“empresarial”条件（无每日上限），请在同一个 JSON 中添加 "unlimitedDaily":true。

Agent 如何连接

任何 MCP 客户端（Claude 或其他客户端）都可以通过将此 URL 添加为“远程 MCP 服务”（有时称为“连接器”）来连接，指向 https://tu-servicio.onrender.com/mcp，并发送 header Authorization: Bearer <llave>，其中的密钥可通过 /crear-llave 获取。连接后，Agent 会看到这三十个工具（audit_mcp_server、simulate_approval、detect_poisoned_tool_descriptions、check_known_vulnerabilities、detect_tool_rug_pull、detect_poisoned_config_files、check_package_authenticity、detect_memory_poisoning、detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk、detect_sql_injection_risk、detect_token_passthrough_risk、detect_hardcoded_secrets_risk、detect_insecure_deserialization_risk、detect_toxic_flow_risk、detect_ssti_risk、detect_dynamic_code_risk、detect_dns_rebinding_risk、detect_missing_auth_risk、detect_mcp_stdio_launch_risk、detect_redos_risk、detect_session_hijack_risk、detect_oauth_audience_confusion_risk、detect_unbounded_allocation_risk、detect_cross_client_leak_risk、detect_sampling_hijack_risk、detect_output_schema_ssrf_risk、detect_excessive_agency_risk 和 detect_call_spoofing_risk），并且可以自行调用，无需任何人打开任何内容——每次调用都会自动消耗一次免费使用次数或一个额度；如果额度用完，错误消息本身会告诉 Agent（或负责配置的人）如何获取更多额度。

Vigía — 专用 Agent（Escalón 1 /“Centinela Básico”）

POST /vigia/analizar 是一项不同于 /mcp 的服务：它不会像 /mcp 那样暴露 30 个彼此独立的工具，让外部 Agent 决定调用哪个；相反，它会提供 Garita Labs 自有的 Agent（名为“Vigía”——而不是“Centinela”，以免与工具 20 的商品名称“Centinela de Autenticación”冲突），由它自行决定针对客户端发送的内容使用 30 个工具中的哪些，整合结果，并用西班牙语以通俗易懂的语言回复，提供按优先级排序的报告和修复建议。它面向没有安全技术背景的客户端，也可直接集成到工作流（机器人、CI/CD 流水线）中，无需手动编排 30 个工具。

调用方式：

POST https://tu-servidor.onrender.com/vigia/analizar
Content-Type: application/json
Authorization: Bearer gar_... (o mandá "apiKey" en el cuerpo)

{ "mensaje": "Revisá este código: ..." }

返回：

{
  "informe": "...(el análisis en español, listo para mostrarle al cliente)...",
  "herramientasUsadas": [ { "herramienta": "detect_command_injection_risk", "entrada": {...}, "ok": true }, ... ],
  "licenciaAgotada": false,
  "vueltas": 2
}

设计原则（已与业务方明确达成一致）： Vigía 绝不会直接修改或应用客户端代码或系统中的更改，即使客户端明确要求也不例外——它只进行分析、解释并提出修复建议。经人工审批后应用更改，将留待未来的一个阶段（“Centinela Enterprise”）。

收费方式： Vigía 决定调用的每个实际工具，收费方式都与客户端直接通过 /mcp 调用完全相同——使用同一套 licensing.checkAndConsume()/refundUse()，不另设收费系统。目前尚未单独收费的是 Vigía 自身用于推理（决定调用哪些工具并撰写报告）的 Claude token 成本——这部分暂由 Garita Labs 承担，同时还在考虑如何衡量和收费（目前讨论的方案是额外提供月度订阅）。在向大量客户端提供 Vigía 之前，必须先决定这件事，以免运营亏损。

正常运行所需条件： 必须在 Render 中配置环境变量 ANTHROPIC_API_KEY（请参阅上方的变量表）——这是 Garita Labs 的 Anthropic 密钥，不是客户端的密钥。未配置时，端点会返回 503 和清晰的错误信息，而不会崩溃；服务器的其余部分仍可正常运行。

包含的安全限制： 每个请求的推理和工具调用最多进行 6 轮（避免 Agent 不断循环而无法结束，也控制成本）；输入“消息”最多 20.000 个字符；如果客户端许可证在分析过程中用尽，就会立即停止并通知客户端，而不是继续反复尝试（并不断失败）。

关于 Render 免费套餐的一点说明

Render 免费套餐会在服务 15 分钟未使用后让它“休眠”，下次收到调用时需要大约一分钟才能唤醒。对于适度使用来说，这完全没问题；如果之后变成持续使用的服务，就应该改用付费套餐，避免它“休眠”。

上传前在本地测试所有内容（可选，用于验证更改）

npm install
node server.js

如果没有配置 Upstash 变量，服务器会以内存模式启动（会显示醒目的警告）——这适合免费测试完整流程，但服务器重启后所有内容都会丢失。服务器运行后：

• node test-heuristics.js — 测试规则引擎本身（不启动服务）。包含第 5 轮攻击（2026-09），这是本服务端移植版特有的：将科学计数法写成字符串、扩展不可见字符列表，以及用 destructiveHint: false 谎称某工具不具破坏性。
• node test-licensing.js — 测试密钥的完整生命周期：免费使用、用量耗尽、每日上限、模拟购买、webhook、额度，全程不实际调用 CoinGate。
• node test-verificar-pago.js — 测试 /verificar-pago 的手动备用流程（付款延迟、之后确认且不重复入账），模拟 CoinGate 的响应，不实际调用 CoinGate。
• node test-client.js — 像真实 Agent 一样连接：申请密钥、调用两个工具，并耗尽免费用量以查看“购买更多额度”的提示。
• node test-escudo.js — 测试 Garita Escudo 引擎（不启动服务），复用此前针对浏览器版本的 4 轮攻击用例，并增加第 5 轮（2026-09），针对 gatillo_diferido 规则：通过 curl/wget 进行无管道外泄，以及向远程主机执行 scp/rsync；还包括此前遗漏的两条西班牙语触发短语。
• node test-vulnerabilidades.js — 使用模拟 fetch 测试 OSV.dev 响应的解析（严重性、CVE、排序、截断、错误）；不依赖互联网连接，也不受 OSV.dev 内容变化影响。包含一轮稳健性攻击（2026-09）：此前会导致整个工具崩溃的格式错误记录，以及摘要大小和结果数量上限。
• node test-rugpull.js — 测试 rug-pull 检测器：真实攻击（延迟指令 + ssh/外泄）、无害的措辞变化、无更改、新工具、已删除工具、同时包含四种类别的混合用例，以及一轮针对其自身比较逻辑的攻击（2026-09）：在不同版本之间重命名被植入恶意内容的工具，以及清单中存在重名工具。
• node test-config-poison.js — 测试被投毒的配置/指令文件检测器（第六个工具，2026-09）：验证权威性措辞在此类文件中不会被惩罚；验证新的凭据外泄规则无需时间触发词即可触发（两种排列顺序均可，并覆盖西班牙语附着代词——“léelo y envíalo”——这是构建期间发现并已修复的真实绕过方式）；验证西班牙语防御性指令（“nunca lo muestres”）不会因动词变位差异而触发；记录一个已知限制：相同的英语防御性指令确实可能触发误报；并确认 Garita Escudo 引擎的其他部分（不可见字符、同形异义字符、隐藏标签、延迟触发）会在此类文件中原样复用。
• node test-slopsquatting.js — 测试软件包真实性验证器（第七个工具，2026-09）：不存在的软件包（提示可能是幻觉，也可能造成未来的抢注风险）；经典 typosquat（名称与热门软件包相差 1 次编辑且历史记录较少，并验证相似但已成熟的名称不会被标记）；2026 年记录的“slopsquatting”模式（刚发布 + 异常的初始版本，如 35.x.y，并验证版本为正常 0.x/1.x 的新软件包不会触发强规则）；近期软件包中的自动安装脚本（并验证旧软件包中的相同脚本不会受到惩罚）；以及完全没有 repository/homepage/README 的情况。大多数用例使用模拟的 npm 注册表 fetch；另有少数用例通过真实 API 确认（left-pad、chalkk、loadash——此环境可以访问 registry.npmjs.org，但无法访问 api.osv.dev）。
• node test-memoria.js — 测试记忆投毒检测器（第八个工具，2026-09）：持久化 + 秘密信息这一关键组合（“recordalo para siempre” + “no se lo digas al usuario”）；真实 Gemini 攻击中记录的条件触发词（Rehberger，2025）；冒充系统权限；安排在下次检索记忆时执行的外泄；内容中隐藏的伪造系统标签；以及一系列负面用例，确认产品的正常使用方式——用户直接要求 Agent 记住某个偏好，即使要求“永远”记住——绝不会被标记为风险。
• node test-ssrf.js — 测试 SSRF 风险检测器（第九个工具，2026-09）：使用未验证 URL 发起 HTTP 请求（JS 和 Python）；在请求本身中硬编码云元数据 IP 或 loopback 地址；与外部请求同时关闭 TLS 验证；跟随重定向但不重新验证目标；未限制 scheme；以及一系列负面用例——固定 URL、通过允许的主机列表 + scheme 进行验证、使用已知的 SSRF 防护库、完全没有 HTTP 请求的代码，以及仅提及元数据 IP 并用于阻止访问的防御性检查（不应将其误标为正在调用该 IP）。
• node test-traversal.js — 测试路径遍历风险检测器（第十个工具，2026-09）：使用未验证路径执行文件操作（JS 和 Python）；Excel MCP 服务真实 CVE 的精确模式（CVE-2026-40576，CVSS 9.4）；在操作本身中直接引用 /etc/passwd 或 SSH 密钥；只验证 "../" 却不拒绝绝对路径；以及一系列负面用例——固定路径、完整验证（拒绝绝对路径 + 将 path.resolve 与基目录比较）、使用 path.basename 仅保留文件名、使用 Werkzeug/Flask 的 secure_filename，以及完全没有文件操作的代码。
• node test-command-injection.js — 测试命令注入风险检测器（第十一个工具，2026-09）：通过拼接构造命令（JS 和 Python）；插值 template literal；使用显式 shell:true 和变量命令的 spawn/execFile；CVE-2026-55581 的精确模式（允许命令列表只检查第一个 token）；“下载并执行”模式（curl | bash）；以及一系列负面用例——固定命令、使用参数数组且不带 shell=True 的 subprocess.run/execFile（安全写法）、使用 shlex.quote 转义，以及结合元字符过滤的完整允许列表。
• node test-sql-injection.js — 测试 SQL 注入风险检测器（第十二个工具，2026-09）：通过拼接构造查询（JS 和 Python，包括插值 f-string）；直接在查询中插入表名；Datadog Security Labs 发现的精确模式（声称“只读”却未实际应用任何限制）；以及一系列负面用例——参数化查询（$1、带元组的 %s）、使用 connection.escape() 转义，以及通过 SET TRANSACTION READ ONLY 实际实现的“只读”。
• node test-token-passthrough.js — 测试 OAuth token 转发风险检测器（第十三个工具，2026-09）：允许请求未经授权检查就通过的 Express/FastAPI 中间件（CVE-2026-48039 模式）；将传入的 Authorization header 直接转发到出站调用；将 token 捕获到变量后转发而未重新签发自己的 token；jwt.verify 未验证 audience；将 token 暴露为 URL 参数；以及一系列负面用例——在调用 next() 前显式进行验证的中间件、转发前通过 exchangeToken() 重新签发 token、已验证 audience 的 jwt.verify，以及使用自己的服务 token 而非传入 header 的出站调用。
• node test-hardcoded-secrets.js — 测试明文硬编码密钥检测器（第十四个工具，2026-09）：格式可识别的 OpenAI API key、AWS 访问密钥、含有字面量 token 的 MCP 配置 env 块（Hush Security 报告中的精确模式）、含密码的 .env 行、直接粘贴在代码中的 PEM 私钥、process.env.X || '...' 中硬编码的备用值；以及一系列负面用例——从环境变量读取密钥、MCP 配置中的 ${...} 引用、常见占位符（“your-api-key-here”、“changeme”），以及包含“EXAMPLE”的 AWS 官方示例密钥。
• node test-deserialization.js — 测试不安全反序列化检测器（第十五个工具，2026-09）：对请求字节调用 pickle.loads；调用未设置 weights_only=True 的 torch.load（CVE-2025-45146/ModelCache 模式）；未使用安全 Loader 的 yaml.load；对 $_POST 调用 PHP 的 unserialize()；包含 os.system 的 __reduce__ 方法（pickle payload）；以及一系列负面用例——yaml.safe_load、使用 Loader=yaml.SafeLoader 的 yaml.load、设置了 weights_only=True 的 torch.load、RestrictedUnpickler/find_class，以及 json.loads（它不会反序列化对象，只处理数据）。
• node test-toxic-flows.js — 测试有害流程检测器（第十六个工具，2026-09）：mcp-atlassian 模式（读取本地文件 + 未经批准上传附件）；EchoLeak 模式（不可信邮件 + 私有日历 + 自动渲染 → 完整三重风险）；Invariant Labs/GitHub 模式（公开 issue + 私有 repo + 创建评论 → 完整三重风险）；单个工具同时具备两种能力；多个未经批准的输出工具造成的影响；schema 中已设为必填（required）且确实能缓解风险的批准字段；同一字段存在但未设为必填（无法缓解风险）；以及一系列负面用例——仅读取、仅输出、不会被误认为输出工具的 list_comments/get_comments，以及与主题无关的工具。
• node test-ssti.js — 测试模板注入检测器（第十七个工具，2026-09）：Flask 的 render_template_string、Jinja2 的 Environment().from_string()、LangChain 的 PromptTemplate(template=...) 和 .from_template()、ejs.render、Handlebars.compile、lodash 的 _.template；将“转义输出”的声明作为防御措施时的组合情况（评分高于未作此声明的情况）；以及一系列负面用例——开发者编写的固定文本、SandboxedEnvironment、带固定占位符的 PromptTemplate，以及完全没有模板编译的代码。
• node test-dynamic-code.js — 测试动态代码防护盾（第十八个工具，2026-09）：对检索内容调用 eval()（CVE-2026-26030 模式）；通过拼接构造 Function()；vm.runInContext/runInNewContext；Python 的 exec()；对动态字符串调用 setTimeout/setInterval（“隐式 eval”）；将 vm2 用作虚假缓解措施（评分高于未作此声明的情况）；同时出现多个非字面量 sink；以及一系列负面用例——开发者编写的固定文本、引用函数的 setTimeout，以及真正实现隔离的 isolated-vm。
• node test-dns-rebinding.js — 测试 DNS Rebinding 防护盾（第十九个工具，2026-09）：StreamableHTTPServerTransport/SSEServerTransport 和 Express/FastAPI 的 /mcp 路由未验证 Origin header；声称“只监听 localhost”就足以保护（评分高于未作此声明的情况）；同时存在多个未经验证的端点；以及一系列负面用例——显式验证 req.headers.origin、可识别的 validate_origin() 函数，以及在端点附近使用的 ALLOWED_ORIGINS 列表。
• node test-missing-auth.js — 测试身份验证哨兵（第二十个工具，2026-09）：StreamableHTTPServerTransport/SSEServerTransport 和 Express/FastAPI 的 /mcp、/sse、/messages 路由完全没有身份验证；与完全开放的 CORS 结合后会加重风险（CVE-2026-44895 的精确复现）；同时存在多个未经身份验证的端点；以及一系列负面用例——显式验证 Authorization header、Garita 服务本身已使用的 checkAndConsume() 函数、FastAPI 的 request.headers.get("authorization")，以及可识别的 requireAuth() 中间件。
• node test-mcp-stdio.js — 测试 MCP 启动防护盾（STDIO）（第二十一个工具，2026-10）：StdioClientTransport（TS）和 StdioServerParameters（Python）使用未经验证的动态 command；JS 简写属性 { command, args }；两处未经验证的构造比单处造成更低评分；“重新水合”漏洞（在另一函数中验证，却从已保存的配置启动，并配有避免将其误判为完全缺少验证的专用控制用例）；通过 -c 标志和白名单命令绕过（CVE-2026-30623 模式），以及使用字面量脚本的控制用例；“MCP 协议会失败”带来的虚假安全感；以及一系列负面用例——字面量命令、通过具名常量验证，以及在同一表达式中使用 basename(command) not in <列表> 进行验证（Python）。
• node test-redos.js — 测试 Anti-ReDoS 防护盾（第二十二个工具，2026-10）：对不设上限的 req.body 使用 (a+)+；通过 texto.match(re) 使用 (\s*\w+)*；使用具有重叠分支的 (a|ab)+；根据变量构造 RegExp(x)/re.compile(x)（CVE-2026-0621 模式）；Python 的 re.match() 使用灾难性字面量模式和变量主题文本；恶意正则表达式与动态正则表达式结合后导致评分进一步降低；定义了恶意正则表达式但未确认实际调用（中等风险）；以及一系列负面用例——仅对固定文本应用、通过长度上限缓解、使用安全引擎 RE2 包装、使用字符串字面量调用 RegExp()，以及没有嵌套量词的简单正则表达式。
• node test-session-hijack.js — 测试会话劫持防护盾（第二十三个工具，2026-10）：sessions[id]/.get(id) 未绑定所有者；使用 Math.random() 生成标识符或使用递增计数器；二者结合后会加重风险；以及一系列负面用例——显式比较 userId 与 req.user、使用 jwt.verify 签名并验证的 token、创建新会话（写入，而非有风险的查询），以及使用 crypto.randomBytes 生成的标识符。
• node test-oauth-audience.js — 测试 OAuth 受众混淆防护盾（第二十四个工具，2026-10）：受配置标志控制的受众验证；不匹配但只记录日志而不拒绝的比较；使用 catch() 静默处理 jwt.verify(..., {audience}) 抛出的受众错误；完全没有受众检查；以及一系列负面用例——无条件验证并通过 throw 拒绝、使用库的 audience 选项并在 catch 中重新抛出错误，以及使用 res.status(403) 响应的分支。
• node test-unbounded-allocation.js — 测试无界分配防护盾（第二十五个工具，2026-10）：未设置 limit 的 express.json()；手动累积 stream 但不检查大小；使用动态路径调用 fs.readFileSync 且不检查；未设置上限的 new Array(变量数量)/Buffer.alloc(size)；由外部变量限制且没有上限的 for 循环；同时出现两类风险时会加重评分；以及一系列负面用例——配置了 limit、检查 stream 大小、读取前调用 fs.statSync、在分配语句中使用 Math.min()、在循环前设置显式上限，以及由固定数字限制的循环。
• node test-cross-client-leak.js — 测试客户端间数据泄漏防护盾（第二十六个工具，2026-10）：在模块级声明并在 handler 中与 StreamableHTTPServerTransport 一同复用的 McpServer/Server 实例（CVE-2026-25536 模式）；在模块级声明的可变状态（let/var）被 registerTool 的 callback 引用；同时出现两类风险时会加重评分；以及一系列负面用例——在每个 handler 内重新创建实例/状态、未在任何 handler 中复用的模块级 const 声明，以及不包含任何风险模式的代码。
• node test-sampling-hijack.js — 测试 Sampling 劫持防护盾（第二十七个工具，2026-10）：未经过人工批准就处理 sampling 请求（setRequestHandler(CreateMessageRequestSchema, ...) / 'sampling/createMessage'）；同一 handler 中未经批准就隐蔽调用工具（callTool）；即使已有批准，仍未设置 token 上限（maxTokens/max_tokens）；以及一系列负面用例——经过批准 + 不调用工具 + 已配置 token 上限、不包含任何 sampling handler 的代码，以及不会被误认为 sampling 的其他 MCP 请求 handler。
• node test-output-schema-ssrf.js — 测试输出 schema 防护盾（第二十八个工具，2026-10）：使用 jsonschema.validate/Draft7Validator 验证不可信的 outputSchema/inputSchema，但未使用 Registry（CVE-2026-116686 模式）；在 async def 函数中调用未设置 timeout 的同步网络请求（urllib.request.urlopen/requests.get）；两类风险结合后会加重评分；以及一系列负面用例——使用显式 Registry 进行验证、使用开发者定义的固定 schema、设置了 timeout 的调用，以及委派到单独线程的调用（asyncio.to_thread）。
• node test-excessive-agency.js — 测试过度自主防护盾（第二十九个工具，2026-10）：转账/提款/删除工具未要求任何确认字段（required）；已触发的工具中金额字段未设置最大上限（maximum/exclusiveMaximum）；两类风险结合后会加重评分；验证同一清单中独立的“请求批准”工具不能算作有效缓解措施；以及一系列负面用例——要求确认 + 设置金额上限，以及不执行任何不可逆或高价值操作的工具。
• node test-call-spoofing.js — 测试调用伪造防护盾（第三十个工具，2026-10）：代码根据模型自由文本响应中的模式（TOOL_CALL:、```json 块）执行工具（callTool/execute_tool），却从不读取 API 的结构化字段；代码同时读取结构化字段时仍执行同样操作（由于文本路径仍然存在，因此风险依旧很高）；执行模式本身与其他模式结合时比单独出现执行模式评分更低；仅扫描文本、不触发执行且不读取结构化字段（中等风险）；将文本扫描作为可能的备用方案，同时正确读取结构化字段，但未连接到执行逻辑（中等风险）；以及一系列负面用例——只读取结构化字段且完全不解析自由文本、注释中单独出现“TOOL_CALL”而附近没有解析逻辑，以及与工具调用无关的代码。 上面的四轮“2026-09”攻击已在总结该轮攻击的技术说明中有更详细的记录（逐条发现，并附有修复前后的示例）。第七至第三十个工具（check_package_authenticity、detect_memory_poisoning、detect_ssrf_risk、detect_path_traversal_risk、detect_command_injection_risk、detect_sql_injection_risk、detect_token_passthrough_risk、detect_hardcoded_secrets_risk、detect_insecure_deserialization_risk、detect_toxic_flow_risk、detect_ssti_risk、detect_dynamic_code_risk、detect_dns_rebinding_risk、detect_missing_auth_risk、detect_mcp_stdio_launch_risk、detect_redos_risk、detect_session_hijack_risk、detect_oauth_audience_confusion_risk、detect_unbounded_allocation_risk、detect_cross_client_leak_risk、detect_sampling_hijack_risk、detect_output_schema_ssrf_risk、detect_excessive_agency_risk、detect_call_spoofing_risk）是在该技术说明之后添加的，因此未收录其中——其设计和测试记录在本 README 及各自的 lib/*.js/test-*.js 中。

如果之后修复了 garita-mcp.html 中的问题

注意：此服务器与作为 Artifact 发布的网页不会实时共享代码——它们是同一引擎的两个独立副本。如果之后的某个会话中在 garita-mcp.html 中发现并修复了另一个问题，也必须将同样的修复带到此处的 lib/heuristics.js 中，然后重新发布（只需将修复后的文件上传到 GitHub——Render 会自动重新部署）。

关于 Garita Escudo

Garita Escudo 已在此服务器中拥有自己的工具（detect_poisoned_tool_descriptions，见上文），无需另设服务器。网页（garita-escudo/tool.html）也仍然免费且不受限制，作为无需通过 MCP 服务即可使用同一引擎的另一种方式。