Mihomo v1.19.27 必须升级吗？

如果你正在使用 Mihomo 内核，建议升级到 v1.19.27 或 GUI 已内置该版本的包。Release 写明多处异常输入会触发崩溃或内存异常，继续停在旧内核没有收益。

只更新 Clash Verge Rev 就够吗？

不一定。Clash Verge Rev 的界面版本和 Mihomo 内核版本是两件事，更新后仍要在 About、Core 或日志里确认内核显示 v1.19.27。

Stash 用户怎么看这次更新？

先看 Stash 当前内置核心或兼容层说明。只要底层处理链路依赖旧 Mihomo/Clash 兼容实现，就按内核版本和官方更新说明判断，不要只看 App Store 版本。

Mihomo v1.19.27：QUIC、SOCKS4、Trojan UDP 修复清单 | 安全更新

Mihomo v1.19.27 不是「有空再更」的小版本。MetaCubeX/mihomo 的 github.com Releases 页面显示它在 2026-06-06 发布，并把它标为 Latest 稳定版；BUG & Fix 里有 5 条和异常输入、越界读取、panic 或内存分配有关。你先看内核版本，别只看 Clash Verge Rev、Mihomo Party 或 Stash 的界面版本。

不看日志的排查都是玄学。安全更新也一样，GUI 版本号看着新，内核还停在旧包，风险照样在。

谁真的受影响？

受影响对象不是「装了某个图标的人」，而是正在跑 Mihomo 内核、或由 GUI 内置 Mihomo 核心的环境。典型位置包括桌面端的 Clash Verge Rev、Mihomo Party，自行替换核心的命令行部署，以及部分 Clash 兼容客户端。

Stash 这类移动端客户端要看它当前内置核心和更新说明。本文不假设每个 Stash 版本都直接等同于 Mihomo v1.19.27；判断口径只有一个：底层是否包含 v1.19.27 对应修复，或维护者是否声明已合入这些边界检查。

如果你符合下面任意一项，就该把这次升级排到前面：

环境	更接近的风险	先检查什么
开了 QUIC sniffer	单个异常 UDP 包可能触发崩溃	日志启动行里的 `mihomo version`
使用 DoQ	`readMsg` 越界访问	DNS 配置和核心版本
配置里仍保留 SOCKS4 入站或兼容入口	畸形输入导致内存异常增长	`listeners`、`mixed-port`、外部暴露范围
使用 Trojan UDP 转发	oversized UDP relay length field 触发 panic	Trojan 节点是否启用 UDP
使用 Vision TLS 相关链路	crafted `session_id` 长度导致越界读取	客户端核心版本和节点协议字段
GUI 自带核心但很久没更新	界面版本新、内核版本旧	About/Core/日志三处是否一致

v1.19.27 到底修了哪些坑？

官方 Release 的 BUG & Fix 把这几项写得很直。这里按触发入口翻成排查视角，不扩写成不存在的漏洞编号，也不把它们说成远程入侵结论。

Release 修复项	入口	失败形态	对普通用户的判断
`quic sniffer out-of-bounds read causes process crash via single UDP packet`	QUIC sniffer	单个 UDP 包可能让进程崩溃	开了嗅探或 QUIC 相关流量时优先升级
`socks4 readUntilNull unbounded memory allocation`	SOCKS4 读取	未设上限的内存分配	不要把旧 SOCKS4 入口暴露给不可信来源
`trojan protocol WaitReadFrom panic via oversized UDP relay length field`	Trojan UDP	oversized length field 触发 panic	Trojan UDP 用户不要停在旧内核
`readMsg in doq out-of-bounds access`	DoQ	`readMsg` 越界访问	使用 DNS-over-QUIC 时升级优先级更高
`vision TLS filter out-of-bounds read via crafted session_id length`	Vision TLS filter	构造的 `session_id` 长度触发越界读取	Vision 相关链路按内核版本核对

这张表只基于 Release notes。官方页面没有给 CVE、PoC、影响版本范围细分，也没有声明配置级缓解可以替代升级。所以这里不建议靠关某个开关赌运气；能换内核就换内核。

为什么不是等 GUI 自动更新就好？

Clash Verge Rev、Mihomo Party 这类 GUI 通常把「应用版本」和「内核版本」分开维护。你看到 App 更新，不代表内核已经同步到 v1.19.27；也可能 GUI 只是修了界面、订阅、托盘菜单或配置编辑器。

反过来也一样。有些 GUI 允许单独更新 core，界面版本没变，但内核已经变了。安全修复看的是内核，不是窗口标题。

最稳的记录方式是升级前后各留一行日志。比如重启内核后，你要看到类似下面的信息，版本号至少到 v1.19.27：

time="2026-07-08T10:16:32+08:00" level=info msg="Start initial compatible provider GLOBAL"
time="2026-07-08T10:16:32+08:00" level=info msg="Mihomo Meta v1.19.27 linux amd64 with go1.24"
time="2026-07-08T10:16:33+08:00" level=info msg="RESTful API listening at: 127.0.0.1:9090"

日志里的系统、架构和 Go 版本可能不同，关键是 Mihomo 与 v1.19.27 同时出现。只看到 Clash Verge Rev 2.x 不够。

怎么确认当前内核版本？

先用客户端自己的入口查。Clash Verge Rev 通常在 Settings、Profiles 或 About 附近能看到 Core 信息；Mihomo Party 会在核心管理或关于页面显示当前 core；命令行部署则直接看二进制输出。

命令行环境可以这样查：

mihomo -v

如果你是 GUI 内置核心，日志比命令更可靠，因为 GUI 可能调用的是应用目录里的内置二进制，不是系统 PATH 里的 mihomo。macOS 和 Linux 用户尤其要注意这个差异：终端输出的版本，未必就是 GUI 正在运行的那个核心。

下面是一段排查用 YAML，目的不是让你改配置，而是帮你定位日志和外部控制口。升级前先确认这些字段在哪里，升级后再重启内核看日志：

# ~/.config/mihomo/config.yaml 或 GUI 当前 profile 导出的 YAML
mixed-port: 7890
allow-lan: false
log-level: info
external-controller: 127.0.0.1:9090

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

dns:
  enable: true
  listen: 127.0.0.1:1053

怎么确认这一步真的生效？重启内核后看日志是否有新的启动时间，以及控制口是否仍监听在 127.0.0.1:9090。不要同时改订阅、DNS、TUN 和 core；一次只动 core，失败才知道是哪一层出问题。

GUI 内置核心滞后怎么办？

先看 GUI 是否提供「更新内核」「切换核心」「使用自定义 core」这类入口。能在 GUI 内完成就优先在 GUI 内完成，因为它会处理路径、权限和重启动作。

如果 GUI 没有同步 v1.19.27，有三种处理方式：

处理方式	适合	风险点
等 GUI 发布新版	不急、配置不暴露入口、只在本机用	等待期间仍跑旧内核
GUI 内手动更新 core	GUI 支持核心管理	下载文件和架构必须对应
临时改用命令行 Mihomo	熟悉配置路径和日志的人	GUI 规则、订阅刷新和托盘代理可能不同步

手动替换核心时，别只覆盖文件。先记下旧路径和旧版本，例如：

old core: /Applications/Clash Verge.app/Contents/Resources/mihomo
old version: v1.19.26
new version: v1.19.27
checked at: 2026-07-08

替换后做两件事：第一，重启 GUI；第二，打开日志确认它加载的是新核心。只要日志还显示旧版本，就说明 GUI 没用到你替换的那个文件。

升级后要看哪些异常日志？

升级安全修复后，先确认核心能稳定启动、订阅能正常解析、DNS 和入站端口没有变。测速可以稍后再做。下面这类日志可以接受：

level=info msg="Start initial compatible provider Proxy"
level=info msg="DNS server listening at: 127.0.0.1:1053"
level=info msg="HTTP proxy listening at: 127.0.0.1:7890"

下面这类就要停一下，不要继续叠加改配置：

level=error msg="Parse config error: proxy 0: unsupported cipher"
level=error msg="Start listener error: listen tcp 127.0.0.1:7890: bind: address already in use"
level=warning msg="core version mismatch: expected v1.19.27, got v1.19.26"

第一类是配置语法或协议字段不兼容，第二类是端口被占用，第三类才是版本没切成功。三种问题的解法完全不同，混在一起改只会把现场弄乱。

Release notes 没写的边界

本文只按 MetaCubeX/mihomo Release notes、github.com 仓库和 wiki.metacubex.one 公开信息整理，不验证 PoC，也不推断官方没写的影响范围。没有 CVE 编号的条目，不在这里强行补编号。

本文也没有测试所有 GUI 的内置核心更新节奏。Clash Verge Rev、Mihomo Party、Stash 的具体菜单位置会随版本变化；如果页面路径和你手里的版本不一致，以客户端当前 About/Core 页面、启动日志和官方发布说明为准。

如果要继续补齐现场材料，可以接着看这几页：

最后给一个最小动作：今天只做一件事，确认运行中的 Mihomo core 是否已经是 v1.19.27。确认完再考虑 GUI 升级、配置清理或协议侧调整。