Telerik MAUI 重定向漏洞深度剖析：CVE-2026-124705 协议处理器劫持链路与修复实战

导语：本次披露的 Telerik MAUI 重定向漏洞（CVE-2026-124705，CVSS 7.8）并非一次普通的输入校验疏漏，而是发生在富文本与 PDF 渲染组件内部的“协议信任边界”失守——攻击者只需投递一份精心构造的文档，即可借用户一次点击拉起操作系统上任意已注册的协议处理器。作为长期负责客户端与混合架构安全评审的架构师，我认为这条链路值得被完整拆解，因为它暴露的是整个 .NET MAUI 生态中“内容渲染层默认信任链接”的系统性设计惯性。

一、漏洞全景：Telerik MAUI 重定向漏洞的基本画像

根据 GitHub Advisory Database 与 NVD 的联合披露，In Progress® Telerik® UI for .NET MAUI 在 16.0.0 版本之前，存在一处不可信 URL 重定向（Untrusted URL Redirection）缺陷。其影响面覆盖两个核心控件：RadRichTextEditor 的超链接处理逻辑，以及 RadPdfViewer 的链接注解（Link Annotation）处理逻辑。攻击者无需任何认证凭据，仅需构造一份包含非白名单 URI Scheme 的文档或 PDF，诱导用户打开并点击链接，即可触发漏洞。

二、攻击链路拆解：从恶意文档到任意协议处理器

要理解 Telerik MAUI 重定向漏洞的危害本质，必须把视角下沉到 .NET MAUI 的 URI 处理模型。RadRichTextEditor 与 RadPdfViewer 在渲染超链接时，会解析文档中嵌入的 URI，并在用户点击时调用平台层的链接打开能力。问题在于：组件默认没有对 URI Scheme 做白名单约束，而是将文档中声明的任意 Scheme 直接透传给操作系统的协议处理器分发器。

flowchart TD
    subgraph 投递层 ["攻击投递与诱导层 (Delivery Tier)"]
        A["攻击者构造恶意文档 / PDF"] --> B["嵌入非白名单 URI Scheme 链接"]
        B --> C["邮件附件 / 协作平台 / 下载站点投递"]
    end
    subgraph 渲染层 ["内容渲染与解析层 (Render Tier)"]
        C --> D["用户打开文档 (RadRichTextEditor / RadPdfViewer)"]
        D --> E["解析超链接与 Link Annotation"]
    end
    subgraph 信任层 ["URI 信任决策层 (Trust Decision Tier)"]
        E --> F{"是否校验 URI Scheme 白名单"}
        F -->|"未校验 (漏洞版本)"| G["直接透传任意 Scheme"]
        F -->|"已校验 (16.0.0+)"| H["拦截并降级为安全提示"]
    end
    subgraph 执行层 ["操作系统协议分发层 (OS Handler Tier)"]
        G --> I["OS 协议处理器分发器"]
        I --> J["拉起任意已注册协议处理器"]
        J --> K["以攻击者可控参数执行"]
    end
  

2.1 关键攻击面：为什么 Scheme 是信任边界

URI Scheme 是操作系统层面的“能力路由表”。当应用把 file:、ms-appinstaller:、search-ms:、smb:、ms-msdt: 等 Scheme 原样交给系统时，实际等于把“调用哪个可执行程序、传什么参数”的决策权交给了文档作者。历史上大量 Windows 协议处理器劫持事件（如 Follina 利用 ms-msdt:）都遵循同一模式：渲染组件不做 Scheme 收敛，系统分发器照单全收。

• RadRichTextEditor 路径：文档中的超链接在点击时触发 URI 打开逻辑，未对 Scheme 做 allowlist 过滤。
• RadPdfViewer 路径：PDF 的 Link Annotation（/URI 动作）在渲染层被解析后直接透传，同样缺少 Scheme 校验。
• 共同根因：两个控件共享同一套“链接打开”抽象，而该抽象默认信任文档内容，未建立“内容不可信”的安全假设。

三、修复方案：从组件升级到应用层纵深防御

官方修复版本为 16.0.0，核心变更是在链接打开前引入 URI Scheme 白名单校验。但作为架构师，我不会把安全边界完全押在第三方组件的单点修复上。针对 Telerik MAUI 重定向漏洞，我推荐“升级 + 应用层拦截 + 内容来源管控”的三层防御模型。

3.1 第一层：强制升级至 16.0.0 及以上

升级是修复该 CVE 的必要条件。请在 NuGet 包管理中显式锁定版本，避免传递依赖回退到旧版本。

# 查看当前项目引用的 Telerik MAUI 版本
dotnet list package | grep -i telerik

# 升级核心组件包至 16.0.0 及以上
dotnet add package Telerik.Maui.Controls --version 16.0.0
dotnet add package Telerik.Maui.Controls.Compatibility --version 16.0.0

# 验证升级结果
dotnet list package | grep -i telerik

3.2 第二层：应用层 URI Scheme 白名单拦截

无论组件是否已修复，都应在应用层建立统一的链接打开网关。核心原则：只放行明确需要的 Scheme，其余一律拦截并提示。以下为 .NET MAUI 中的落地实现参考。

using System;
using System.Collections.Generic;
using Microsoft.Maui.ApplicationModel;

namespace App.Security;

public static class SafeUriLauncher
{
    // 仅放行业务明确需要的 Scheme，按需最小化
    private static readonly HashSet<string> AllowedSchemes = new(StringComparer.OrdinalIgnoreCase)
    {
        "http", "https", "mailto", "tel"
    };

    public static async Task<bool> TryOpenAsync(string? rawUri)
    {
        if (string.IsNullOrWhiteSpace(rawUri)) return false;

        if (!Uri.TryCreate(rawUri, UriKind.Absolute, out var uri))
            return false;

        // 关键：Scheme 白名单校验，阻断 file:/ms-*/search-ms:/smb: 等危险协议
        if (!AllowedSchemes.Contains(uri.Scheme))
        {
            // 记录审计日志，便于威胁狩猎
            System.Diagnostics.Debug.WriteLine($"[SECURITY] Blocked URI scheme: {uri.Scheme}");
            return false;
        }

        // 可选：对 http/https 再做域名白名单或信誉校验
        await Launcher.Default.OpenAsync(uri);
        return true;
    }
}

3.3 第三层：内容来源管控与渲染隔离

• 来源标记：对来自外部（邮件、上传、第三方接口）的文档打上“不可信”标签，渲染时禁用自动链接激活，改为“点击后二次确认”。
• 沙箱预览：高敏感场景下，PDF/富文本预览运行在受限容器或 WebView 沙箱中，链接点击事件由宿主拦截后再决策。
• 审计埋点：对所有被拦截的非白名单 Scheme 记录日志，纳入 SIEM 威胁狩猎规则，可提前发现定向钓鱼攻击。

四、验证与回归：确认 Telerik MAUI 重定向漏洞已闭环

修复完成后，必须做可验证的回归测试，而不是“升级完就认为安全”。建议构造最小化测试用例，覆盖两个受影响控件与典型危险 Scheme。

// 1. RadRichTextEditor：构造含危险 Scheme 的富文本，点击链接应被拦截
// 2. RadPdfViewer：构造含 /URI (file: 或 ms-*) 的 PDF Link Annotation，点击应被拦截
// 3. 正常 https 链接应可正常打开，确保白名单未误伤业务

[Theory]
[InlineData("file:///C:/Windows/System32/calc.exe", false)]
[InlineData("ms-msdt:/id PCWDiagnostic", false)]
[InlineData("search-ms:query=secret", false)]
[InlineData("smb://attacker/share", false)]
[InlineData("https://www.telerik.com", true)]
[InlineData("mailto:support@example.com", true)]
public async Task UriScheme_Should_Be_Filtered(string uri, bool expected)
{
    var result = await SafeUriLauncher.TryOpenAsync(uri);
    Assert.Equal(expected, result);
}

五、架构反思：内容渲染层的“默认信任”必须终结

Telerik MAUI 重定向漏洞给整个客户端生态敲响的警钟，远不止一个 CVE。它揭示了一个反复出现的架构反模式：渲染组件把“展示内容”与“执行能力”耦合在一起。超链接在语义上是“展示”，但在实现上却直接调用了操作系统的“执行”入口。只要这个耦合存在，任何富文本/PDF/邮件渲染组件都可能成为协议处理器劫持的跳板。

我的建议是把“链接打开”抽象为应用内的受控能力网关（Capability Gateway），所有渲染组件产出的 URI 都必须经过该网关裁决。这样，无论未来是 Telerik 还是其他组件再次出现类似 Telerik MAUI 重定向漏洞，应用层都有一道稳定、可审计、可演进的防线。安全不是组件的一个开关，而是架构中的一条边界。