The Dragon in Your Dependency Tree

SPS-TA-2026-004 · TLP:CLEAR · Basis: NousResearch/hermes-agent tag v2026.8.3 ("Herald", v0.20.0), release commit 3c27eb62, published 2026-08-03 · Assessed 2026-08-06

The Front Doors You Didn't Choose — PRC-jurisdiction attack surface in NousResearch/hermes-agent "Herald".

Follows Hiding in Plain Sight, which assessed the same gateway families against the ≤ v0.18.2 tree in July.

Issuing body

HannahLabs — Security & Pentesting Solutions (SPS), HumanAIFusion. Companion document: SPS-VA-2026-003 (full vulnerability assessment, TLP:AMBER).

---

§ 00 · Scope

Statement of scope and intent

This document assesses one dimension only of the hermes-agent "Herald" release: the code, dependencies, and network endpoints in the shipped tree that are operated by entities subject to the jurisdiction of the People's Republic of China.

It is written to be read by two audiences at once: security engineers who need file paths and line numbers, and decision-makers who need to know whether to deploy.

Three things this document is not.

It is not an allegation of malicious code. SPS conducted a targeted review of the PRC-origin adapters in this tree and found no backdoor, no covert exfiltration routine, and no deliberately hidden channel. Where we found security-relevant defects, we name them and rate them, and they are ordinary defects of the kind found in any large codebase.

It is not an argument that Chinese-authored software is inherently untrustworthy. That claim is neither technically defensible nor consistent with SPS doctrine. Our standing position, recorded in the SPS knowledge base, is that deployment posture determines safety — how a model or service is reached governs the risk, not the nationality of who wrote it. Open weights running on infrastructure you control are a fundamentally different risk object from a hosted API terminating in Shenzhen. This document is about the second category.

It is not a claim that these components are enabled by default. Most are not. That is precisely the finding.

What this document is: an argument that the Herald tree ships a large, largely undocumented set of network paths into PRC jurisdiction — six messaging-platform gateway families and nine model providers — and that the security consequence of that is real, structural, and independent of whether anyone intends to turn them on.

§ 01 · Summary

Executive summary

The hermes-agent Herald release is, in its core, a well-engineered piece of security software. SPS said so at length in the companion assessment: the approval system is frozen at import and cannot be bypassed at runtime, the SSRF proxy default-denies cloud metadata and RFC1918 space, dependencies are exact-pinned against a documented supply-chain worm event, and there is no default telemetry. The maintainers are visibly competent and visibly security-conscious.

That is what makes the finding below worth writing down.

The maintainers are visibly competent and visibly security-conscious. That is what makes the finding worth writing down.

Shipped in the same tree are:

• Six PRC-operated messaging gateway families — DingTalk (Alibaba), Feishu/Lark (ByteDance), WeCom (Tencent), Weixin (Tencent), QQ Bot (Tencent), and Yuanbao (Tencent) — with hardcoded endpoints reaching dingtalk.com, feishu.cn, larksuite.com, weixin.qq.com, sgroup.qq.com, bots.qq.com, yuanbao.tencent.com, and hunyuan.tencent.com.
• Nine PRC-operated model providers — DeepSeek, Alibaba (Qwen/DashScope), Alibaba Coding Plan, Qwen OAuth, MiniMax, StepFun, Moonshot/Kimi, Z.ai (Zhipu/GLM), and Xiaomi — several of which resolve to mainland-China endpoints, including api.moonshot.cn and open.bigmodel.cn.
• A ten-package Alibaba Cloud SDK dependency chain, pulled transitively by the DingTalk adapter, which is one of two constraints holding the project's cryptography library below a version that fixes three open CVEs.
• A compiled C extension (native/fts5_cjk/) built from vendored source into the deployed artifact.

The security argument is not that these are malicious. It is that they constitute a standing set of egress paths whose destination is a jurisdiction with compulsory data-access law, present in the artifact, absent from most threat models, and reachable by an agent whose provider and platform selection can be influenced by untrusted input.

Verdicts

§ 02 · Thesis

Reachability is the risk, not usage

The most common rebuttal to this entire class of finding is: "We don't enable those. They're inert."

SPS treats that as a non-answer, and the reasoning is worth stating precisely because it generalizes well beyond this project.

A dormant integration is not absent. When an adapter ships in the tree, four things are true simultaneously:

1. Its code is in the artifact. It is in the container image, on disk, importable. Any defect in it is a defect in your deployment.
2. Its dependencies are installed. The DingTalk adapter alone brings ten Alibaba Cloud packages into your resolved environment whether or not a single DingTalk message is ever sent.
3. Its endpoints are reachable. Unless you have explicit egress control — and most deployments do not — the DNS names and network paths resolve from your workload.
4. It is invisible to your controls. This is the compounding factor. Because nobody believes the adapter is "in use," it does not appear in the threat model, it is excluded from scanner scope, it has no dashboard, no alert, and no log review. It is the one component in the system where anomalous behavior would go unnoticed longest.

Point 4 is the one that matters. Institutional indifference toward a dormant surface is self-reinforcing: the surface is ignored because it is believed inert, and it remains unexamined because it is ignored. The dormant path is therefore not merely equal in risk to an active one — for detection purposes, it is worse.

A dormant integration is not absent. For detection purposes, it is worse.

And dormancy is not a property the operator fully controls. In an agentic system, provider and platform selection is a runtime decision. Configuration determines which adapters are available; the agent's own execution determines which are invoked. An agent that processes untrusted content — a web page, an email, a document, a repository issue — and that has the ability to select an egress path has, in principle, a path from injected instruction to chosen destination. The gap between "configured off" and "unreachable" is where this entire risk class lives.

The gap between "configured off" and "unreachable" is where this entire risk class lives.

This is what the title means. These are front doors in the building you deployed. You did not choose them, you may not know their addresses, and you are not watching them.

§ 03 · Jurisdiction

Why PRC jurisdiction is a distinct legal category

The claim that PRC-terminating endpoints warrant separate treatment is a legal claim, not a cultural one, and it rests on published statute:

• National Intelligence Law (2017), Article 7 — organizations and citizens shall support, assist, and cooperate with national intelligence work, and shall protect the secrecy of such work. There is no publicly documented mechanism by which a PRC-domiciled operator may decline or disclose such a request.
• Cybersecurity Law (2017) — data localization obligations for critical information infrastructure operators, plus security-review requirements for cross-border transfer.
• Data Security Law (2021) — a national data classification regime with state access provisions, and Article 36's restriction on providing data to foreign law-enforcement without PRC approval.

The operational consequence for a security architect is narrow and specific: for an endpoint under this jurisdiction, you cannot construct a threat model in which compelled disclosure to the state is excluded, and you cannot obtain attestable assurance to the contrary. That is not true of every jurisdiction, and it is why "just use their international endpoint" does not resolve the issue — as Section 5 develops.

This is a statement about legal reachability. It is not a statement about the engineers who build these platforms, whose technical work is frequently excellent.

§ 04 · Gateways

The six gateway families

All paths below are verified in the pinned v2026.8.3 tree.

4.1 DingTalk — Alibaba

Paths: plugins/platforms/dingtalk/, hermes_cli/dingtalk_auth.py Endpoint: https://open-dev.dingtalk.com

The lightest gateway by code volume and the heaviest by dependency consequence. Its significance is almost entirely in what it drags behind it: the Alibaba Cloud SDK chain analyzed in Section 6. A deployment that never sends a DingTalk message still carries ten Alibaba packages, and the version constraint they impose, purely by virtue of this adapter being in the manifest.

4.2 Feishu / Lark — ByteDance

Paths: plugins/platforms/feishu/, plus two reach-in tools: tools/feishu_doc_tool.py, tools/feishu_drive_tool.py Endpoints: open.feishu.cn, accounts.feishu.cn, open.larksuite.com, accounts.larksuite.com

This is the most consequential gateway in the tree, and the reason is the drive tool.

The other five gateways are messaging adapters: they send and receive conversational messages. The Feishu integration is different in kind. tools/feishu_drive_tool.py exposes the agent to the tenant's document store, not just its chat. Verified in-file:

_LIST_COMMENTS_URI = "/open-apis/drive/v1/files/:file_token/comments"
_LIST_REPLIES_URI  = "/open-apis/drive/v1/files/:file_token/comments/:comment_id/replies"

with corresponding tool schemas feishu_drive_list_comments and feishu_drive_list_comment_replies, both taking a file_token as required argument.

The other five gateways carry messages. This one reaches into the tenant's document store.

Two observations. First, file-token-scoped reach into a corporate document repository is a materially higher-value capability than message send/receive — comment threads on internal documents are precisely where deliberative, pre-decisional, and often the most sensitive organizational content accumulates. Second, and more subtly, document comments are an untrusted-input surface: content placed in a comment by any party with access to the document is content the agent may read. This is a textbook indirect prompt-injection carrier, and it sits on the same integration that provides the egress path.

An agent with this tool enabled, reading attacker-influenceable comment content from a tenant document, in a runtime where provider selection is dynamic, is the full injection-to-exfiltration chain expressed in a single integration.

4.3 WeCom / Work Weixin — Tencent

Paths: plugins/platforms/wecom/, incl. wecom_crypto.py Endpoints: qyapi.weixin.qq.com/cgi-bin/gettoken, qyapi.weixin.qq.com/cgi-bin/message/send, work.weixin.qq.com/ai/qc/gen, /generate, /query_result

Credit where due

This adapter uses defusedxml for callback parsing. The maintainers correctly anticipated XXE in the WeCom callback path and defended it. That is not a given in enterprise integration code and it should be said plainly.

Defect — non-constant-time signature comparison (CWE-208, LOW). At plugins/platforms/wecom/wecom_crypto.py:90:

if expected != msg_signature:

The callback signature is validated with Python's != operator, which short-circuits on first differing byte. The correct construction is hmac.compare_digest(). Practical exploitability across a network path is low — jitter dominates the timing signal — and SPS rates it LOW on that basis. It is included because it is real, because it is a two-character fix, and because a document that reports only what is convenient is not worth reading.

4.4 Weixin / WeChat — Tencent

Path: gateway/platforms/weixin.py Endpoints: ilinkai.weixin.qq.com, novac2c.cdn.weixin.qq.com/c2c

Consumer-WeChat surface, distinct from the enterprise WeCom adapter above. The novac2c.cdn endpoint is a content-delivery path, meaning media objects transit a PRC-operated CDN. For any deployment handling regulated content, media egress to a third-country CDN is a distinct compliance event from message-text egress, and is frequently missed in review because CDNs are mentally filed as infrastructure rather than as data recipients.

4.5 QQ Bot — Tencent

Paths: gateway/platforms/qqbot/ (adapter.py, crypto, chunked upload, keyboards) Endpoints: api.sgroup.qq.com, bots.qq.com/app/getAppAccessToken, bot.q.qq.com

And the finding that most deserves attention in this document.

gateway/platforms/qqbot/adapter.py hardcodes a mainland-China LLM endpoint as a model backend, at four separate locations — lines 21, 2218, 2220, and 2236:

baseUrl: "https://open.bigmodel.cn/api/coding/paas/v4"
...
"zai": "https://open.bigmodel.cn/api/coding/paas/v4",
"glm": "https://open.bigmodel.cn/api/coding/paas/v4",

open.bigmodel.cn is Zhipu AI's mainland platform endpoint, serving the GLM model family. The same file also references api.openai.com/v1.

Three reasons this matters more than a line in a config file.

First, it is a cross-layer bridge. This is a model provider endpoint embedded inside a messaging gateway adapter. Anyone auditing this deployment's model egress would reasonably look in plugins/model-providers/. They would not find this. It is architecturally out of place, and out-of-place things are what audits miss.

A model-provider endpoint hidden inside a messaging adapter. Out-of-place things are what audits miss.

Second, it is unambiguously mainland. The .cn domain under open.bigmodel.cn is Zhipu's domestic platform — not the api.z.ai international endpoint that appears in the model-providers directory. Whatever mitigation an operator believes they get from choosing international endpoints does not apply here.

Third, it is hardcoded, not configured. These are literals in application source, not values read from environment or config. Removing this path requires a code change, not a settings change — which means an operator who has locked down their configuration has not necessarily closed this path.

SPS rates this the single highest-priority CN finding in the tree on the basis of auditability alone.

4.6 Yuanbao — Tencent

Paths: gateway/platforms/yuanbao.py, yuanbao_media.py, yuanbao_proto.py, yuanbao_sticker.py Endpoints: bot.yuanbao.tencent.com, hunyuan.tencent.com/api/resource/download

Tencent's Hunyuan-backed assistant surface, with the broadest file footprint of the six — a full protocol implementation plus media and sticker handling.

Correcting a likely misreading, in the maintainers' favor. An automated scan of this tree will flag 169.254.169.254 — the cloud instance-metadata address — at gateway/platforms/yuanbao_media.py:222. It is not a vulnerability. It is a comment documenting a defense:

# every redirect hop so a public URL can't 302 to http://169.254.169.254/.

The maintainers recognized that a media-download path accepting remote URLs is an SSRF primitive, and that validating only the initial URL is insufficient because a redirect chain can pivot to metadata. They validate every hop. This is correct, it is the failure mode that catches most implementations, and any assessment that reported this as a finding would be wrong.

We note it because credibility in this document is the entire asset. An analyst who reports a defensive control as a vulnerability has told you nothing reliable about the controls they did report.

An analyst who reports a defensive control as a vulnerability has told you nothing reliable about the controls they did report.

§ 05 · Providers

The nine model providers — and the "-intl" problem

Verified endpoints, plugins/model-providers/:

Two structural observations.

The -intl suffix is a routing decision, not a jurisdictional one. Alibaba's dashscope-intl and coding-intl endpoints, and the .io/.ai TLDs used by MiniMax, Moonshot, StepFun and Z.ai, are frequently read by reviewers as evidence that data stays outside PRC control. They are not evidence of that. The operator remains PRC-domiciled, the API credentials are issued by a PRC entity, the account relationship is governed by PRC law, and the corporate parent is subject to Article 7. An international point of presence changes the network path and the latency; it does not change who can be compelled to produce what traverses it. Treating a hostname suffix as a compliance control is the specific error this section exists to name.

An international point of presence changes the network path. It does not change who can be compelled.

Moonshot ships both. kimi-coding carries api.moonshot.ai/v1 and api.moonshot.cn/v1 in the same provider definition. Whatever the intended selection logic, a mainland endpoint is present in the shipped configuration surface, and an operator reviewing only the international value has an incomplete picture.

Combined with §4.5, the tree therefore contains at least two direct mainland-China model endpoints — api.moonshot.cn and open.bigmodel.cn — one of which is hardcoded inside a messaging adapter.

§ 06 · Dependencies

The Alibaba SDK chain — and a correction

The DingTalk adapter transitively installs a ten-package Alibaba Cloud SDK chain, verified in uv.lock:

alibabacloud-dingtalk 2.2.42 → alibabacloud-credentials 1.0.8, alibabacloud-credentials-api 1.0.0, alibabacloud-endpoint-util 0.0.4, alibabacloud-gateway-dingtalk 1.0.2, alibabacloud-gateway-spi 0.0.3, alibabacloud-openapi-util 0.2.4, alibabacloud-tea, alibabacloud-tea-openapi, alibabacloud-tea-util.

Note the age spread: gateway-dingtalk 1.0.2 was uploaded 2023-04-25, gateway-spi 0.0.3 in 2025-02. Low-velocity transitive packages in a security-relevant credential path warrant their own scrutiny.

6.1 The cryptography constraint — stated accurately

The project pins cryptography==48.0.1. That version carries three open CVEs: CVE-2026-69248 (X.509 name-constraint bypass via wildcard DNS, fixed in 49.0.0), CVE-2026-69249 (path-building DoS, fixed in 49.0.0), and CVE-2026-69247 (PKCS#7 Bleichenbacher oracle, fixed in 50.0.0).

The maintainers documented the reason directly in pyproject.toml:87:

"cryptography==48.0.1",  # ... ==48.0.1 (not 49.x): msal and alibabacloud-tea-openapi cap <49,
                         # hindsight-api-slim needs >=48.0.1

This corrects a claim made earlier in this engagement. In verbal briefing, SPS stated that the Alibaba SDK was blocking the cryptography upgrade and that removing the CN adapters would lift the cap. That was wrong, and the correction matters.

msal is the Microsoft Authentication Library — a non-Chinese dependency required for the Teams and Azure integrations — and it caps cryptography <49 independently. Removing every Alibaba package from this tree would therefore not lift the constraint. The name-constraint bypass would remain unpatched until msal relaxes its own bound or is itself removed.

Two conclusions follow, and the second is the more important:

1. Remediation planning must target both constraints. A CN-strip that assumes it also resolves the crypto CVEs will produce a build that is measurably less compliant than its owners believe — the most dangerous kind of remediation.
2. The Alibaba chain is a real constraint, but it is not a uniquely Chinese pathology. A Microsoft library sits in exactly the same position. Transitive version capping by large-vendor SDKs is a general structural weakness of the ecosystem, and any framing that presents it as a PRC-specific problem is analytically false — and would be correctly dismissed by any reviewer who checked.

A Microsoft library sits in exactly the same position. Any framing that presents this as a PRC-specific problem is analytically false.

This is what it costs to be believed. An assessment that suppressed the msal half of that comment would have produced a cleaner narrative and a worthless document.

6.2 Vendored native code

native/fts5_cjk/ contains fts5_cjk.c, build.sh, and a vendor/ directory — a compiled C SQLite FTS5 tokenizer for CJK text, built from vendored source into the deployed artifact.

Functionally this is unremarkable: CJK requires a segmenting tokenizer, SQLite's default does not provide one, and writing an extension is the standard answer. The concern is confined to high-assurance contexts, where it is nonetheless real: compiled C in the trust boundary is a memory-safety surface (a tokenizer is by definition a parser of untrusted text), and vendored source complicates provenance attestation for any program requiring SBOM completeness or reproducible builds. For classified deployment this is a blocking item on process grounds independent of the code's quality.

§ 07 · Threat Model

How a dormant path becomes an active one

The chain requires no novel technique. Every link is documented, and none of it is specific to PRC endpoints — the endpoints determine the consequence, not the mechanism.

Stage 1 — Injection. Untrusted content enters the agent's context: a fetched web page, an inbound email, an ingested document, a repository issue, or — most directly, per §4.2 — a comment on a Feishu-hosted document. The Herald tree's own threat model acknowledges prompt injection as a residual risk (companion finding F-08).

Stage 2 — Path selection. The injected instruction influences the agent toward a tool or provider that egresses to a PRC endpoint. This does not require the attacker to know the deployment's configuration; it requires only that such a path be available, which §§4–5 establish is the default state of the shipped tree.

Stage 3 — Egress. Data leaves via a path that is, in the operator's mental model, not in use — and therefore is not on an allowlist, not in the SIEM correlation rules, not on a dashboard, and not in the review queue.

Stage 4 — Non-detection. This is where the dormancy doctrine pays its cost. The connection to api.moonshot.cn or open.bigmodel.cn is anomalous only if someone is looking. Nobody is looking at an adapter believed to be off.

Nobody is looking at an adapter believed to be off.

Aggravating factors present in this tree:

• Companion finding F-08 documents a path from prompt injection to auto-approval under cron-driven unattended execution — Stage 2 without a human in the loop.
• Companion finding F-09 notes an MCP git-bootstrap path invoking subprocess with shell=True.
• The §4.5 hardcoded endpoint is not removable by configuration, so an operator who has hardened their config has not closed it.

Mitigating factors, stated fairly

The approval system is frozen at import and genuinely non-bypassable; the Ironproxy SSRF control default-denies metadata and private ranges; the yuanbao redirect guard is correct; there is no default telemetry. Herald is not an easy target. The argument here is about a surface that persists despite good controls, because it was never scoped as a surface at all.

§ 08 · Recommendations

Recommendations

Immediate (any deployment):

Build-time (regulated / classified):

Upstream (offered constructively):

SPS's view is that R-10 is the correct long-term answer and that it costs the project very little. A monolithic tree containing every integration is a convenience for users who want one; it is an inherited liability for every user who does not.

§ 09 · Closing

Closing

The finding here is not that someone did something wrong. It is that a well-built system accumulated, through ordinary and defensible feature growth, a set of network paths into a jurisdiction with compulsory data-access law — and that the industry's habit of dismissing unused integrations as harmless leaves those paths unwatched by exactly the people who would need to watch them.

Fork-inheritance makes this worse in a way worth naming. Every downstream fork of this project inherits all six gateways and all nine providers by default, typically without any review of that decision, and often without awareness that a decision was made. The maintainers of hermes-agent chose to support these platforms. Forks did not choose; they inherited. And upstream security changes propagate to forks silently, without the advisory channel that a CVE would provide.

Forks did not choose. They inherited.

Herald's own approval system is frozen at import specifically because its authors understood that a control which can be disabled at runtime is not a control. The same reasoning applies one layer out: an egress path that exists in the artifact is an egress path, whatever the configuration says.

Check your egress. That is the whole recommendation.

§ 10 · Appendix A

Verified endpoint inventory

Messaging gateways:

open-dev.dingtalk.com
open.feishu.cn · accounts.feishu.cn · open.larksuite.com · accounts.larksuite.com
qyapi.weixin.qq.com · work.weixin.qq.com
ilinkai.weixin.qq.com · novac2c.cdn.weixin.qq.com
api.sgroup.qq.com · bots.qq.com · bot.q.qq.com
bot.yuanbao.tencent.com · hunyuan.tencent.com

Model providers:

api.deepseek.com
dashscope-intl.aliyuncs.com · coding-intl.dashscope.aliyuncs.com
portal.qwen.ai
api.minimax.io · api.minimaxi.com
api.stepfun.ai
api.moonshot.ai · api.moonshot.cn          ← mainland
api.z.ai · open.bigmodel.cn                ← mainland, hardcoded in qqbot/adapter.py
api.xiaomimimo.com

§ 11 · Appendix B

Finding index

Explicitly assessed and cleared

169.254.169.254 at yuanbao_media.py:222 — defensive redirect guard, correctly implemented. Not a finding.

WeCom callback XML parsing — uses defusedxml. Correctly defended.

No backdoor, covert channel, or deliberate exfiltration routine was identified in any PRC-origin component reviewed.

---

Prepared by HannahLabs — Security & Pentesting Solutions, HumanAIFusion. Analysis performed against pinned tag v2026.8.3. Findings are point-in-time and subject to upstream drift. This document analyzes publicly available open-source code. No access to non-public systems was involved.

SPS-TA-2026-004 · TLP:CLEAR · © 2026 HumanAIFusion & HannahLabs