AI与云安全事件案例分析周报2026.10.19 - 2026.10.23
原创 星云实验室 2026-10-24 12:54 北京
AI 串起 PHP 旧缺陷与多云攻击链，发布签名、供应商信任和模型账单接连承压。
事件一 PHP2Shell 无需登录即可远程执行：AI 串起十余年旧缺陷，网站代码没错也可能失守
涉及组织与应用：PHP 是大量网站使用的服务器端运行环境，PHP 项目发布补丁，Wiz、Calif 等参与漏洞研究与协调，云服务商则提供攻击观测和临时防护。
事件概述：Wiz 等研究方披露，PHP 在一次请求因内存不足异常结束后，可能留下指向已释放内存的内部记录。后续请求复用同一工作进程时，便可能把无效数据当成正常状态，导致其他请求的秘密被读出，或执行攻击者的代码。研究者利用 AI 辅助分析和调试，在常见网站容器中验证了无需登录的利用链。PHP 已发布修复；Cloudflare 报告看到攻击流量，Amazon 的蜜罐也记录了补丁前尝试。网站自身代码没有漏洞，仍可能因底层运行环境受影响。
事件时间：2026-10-21 PHP 紧急发布补丁；10-22 的运行时分析补充检测建议。Amazon 报告的蜜罐尝试发生于 10-17，不改写为已确认受害事件。
事件链接：
影响范围：
CVE-2026-109618、CVE-2026-109619；应升级至 PHP 8.5.12、8.4.27、8.3.36、8.2.35 或对应分支的后续安全版，发行版回补应按其公告核对。
影响处理 Web 请求的 PHP 部署；实际利用条件随版本、接口和内存布局变化。WordPress、Drupal、Joomla 是研究验证目标，不是唯一受影响应用。
“约七成网站使用 PHP”不是“七成网站已被入侵”，更不是每个部署都已验证可用同一脚本攻破。
技术分类归属：基础设施层 / 应用运行时 / Agent辅助漏洞研究
事件标签：云AI融合
图1：Wiz 的原始攻击路径图展示：特制 HTTP 请求触发底层 PHP 内存缺陷，并在 WordPress、Drupal、Joomla 研究环境中实现远程代码执行。它说明问题来自共同运行时，不能证明所有同类网站均能被同一载荷攻破，也不代表三类网站均已有生产失陷。来源：https://www.wiz.io/blog/php2shell-php-rce
架构形态：PHP worker 可连续处理不同请求；正常隔离要求每次请求结束后清理相关状态。漏洞使请求已释放的内存仍被后续处理逻辑引用。
验证路径：特制请求进入上传或错误处理逻辑 → 内存分配失败中断初始化 → 清理不完整留下失效状态 → 同一或相关 worker 后续复用 → 内存泄露或内存破坏 → 研究环境验证远程代码执行。
AI 与云关联：研究方明确使用模型辅助发现、构造和适配复杂利用链；攻击面则是云主机、托管站点及容器中的 PHP 运行时，不是模型本体被攻破。
基础设施与云配置错误：根因位于运行时内存生命周期，不要求云 IAM 配错；若被入侵 worker 还能读取高权限云身份或数据库秘密，影响才会继续扩大。
AI 供应链与存储缺陷：修复网站应用而不重建其 PHP 基础镜像，会留下底层漏洞；更新镜像标签也不保证旧容器或旧 worker 已退出。
前沿算法/工程逻辑缺陷：请求异常中止没有完整撤销已发布的全局状态，使前一请求的无效内存跨越到后一请求。多条变体表明只封堵单一功能开关不足以替代引擎修复。
复合依赖与应急响应缺陷：WAF 可争取时间，但原站直连、不同触发变体及旧进程都会影响覆盖；攻击流量、成功读取和成功执行应分别取证。
边界防御与分层隔离缺陷：部分处理发生在应用认证逻辑之前，登录保护不构成充分防线；运行时身份与容器权限仍应按最小范围设置。
System Intrusion（系统入侵）潜在及已尝试路径：公开材料同时包含实验利用和野外攻击流量，不据此推算真实失陷规模。
更新 PHP 或采用厂商明确回补的软件包，重建镜像、滚动替换容器并重启所有 worker；同时核对实际 Web 运行环境，而非只检查命令行版本。
联查异常上传、内存错误、worker 崩溃及随后产生的 shell 或外联；没有 shell 不足以排除独立的内存泄露。
按官方公告临时收紧请求处理和功能配置，并评估业务影响；不把降低内存限制或单一 WAF 规则当作完整修复。
事件二 LiteLLM 官方发布链遭投毒：1.107.0 窃取云与模型密钥，合法签名也没能拦住
涉及组织与应用：LiteLLM 是统一接入多家模型 API 的开源网关，GitHub 承载其代码与发布审批，PyPI 和容器仓库分发安装包，维护方与 Wiz 分别披露发布链和恶意载荷分析。
事件概述：攻击者身份未归属。LiteLLM 披露，攻击者持有三名开发者的 GitHub 命令行授权令牌，利用其中的组织管理权限绕过分支保护，再让官方发布任务从名称相近的恶意仓库构建代码。正常签名与发布步骤随后把含窃密程序的 1.107.0 送入软件包和容器仓库。受影响环境启动 Python 时，恶意模块便会收集云和模型服务密钥。维护方认为令牌可能来自内部模型网关日志，但最初如何进入该网关仍未确认；不能把怀疑的漏洞入口写成定论。
事件时间：2026-10-21 投毒和下架；10-22 的研究更新补充下载量与云凭据被后续使用的证据。下文时间均为 UTC。
事件链接：
影响范围：
PyPI 的 litellm==1.107.0 七个 wheel，厂商给出的分发窗口为 11:39:51—13:23；Docker Hub 受影响标签为 v1.107.0、latest、main-latest、main-stable，窗口为 11:46:56—14:20；GHCR 同类产物也受影响。
官方 Git 源码标签不含恶意文件，不能只检查源码标签就排除已安装二进制包或容器的风险；厂商称私有企业发布通道未受影响。
Wiz 引用的约 49,000 次下载不是独立受害者数量；其另观测到失窃 AWS 身份被验证并查询模型服务，不能把所有下载都写成成功入侵。
技术分类归属：应用层 / AI供应链 / CI/CD / 云身份与凭据管理
事件标签：云AI融合
图2：Wiz 原始 SVG 按其 16:9 画布渲染为 PNG，未改写内容；左侧是 Python 启动即执行的凭据收集与外传，右侧是周期检查地址并加载代码的能力。原图明确标注右侧远程执行当时未观察到激活，不能据此认定所有分支均已实战运行。图中仅含公开恶意样本的固定 IOC 和代码片段，没有客户密钥。来源：https://www.wiz.io/blog/litellm-compromised-steals-credentials
与历史事件的关系：W37、W42 已分析 LiteLLM 的认证、路由与凭据风险。本次是新的发布产物投毒事件，不能直接认定由那些 CVE 引发，也不能将旧版本“未被本次投毒”理解为没有其他漏洞。
攻击路径：被盗开发者令牌 → 组织所有者权限绕过保护 → 修改发布源为 Berri-AI/litellm → 官方工作流构建、审批、签名并分发 → Python 启动钩子加载窃密代码 → 凭据外传 → 部分云身份被后续滥用。
载荷机制：cook.pth 加载 cook.py 执行窃密；sitecustomize.py 设置远程载荷加载能力。Wiz 当时未观察到后者的动态二阶段地址投入实际使用，须与已执行窃密分开。
基础设施与云配置错误：内部 LiteLLM 部署可被公网访问；维护方发现异常账户，但初始认证或漏洞利用路径尚未坐实。应将已确认的发布权限滥用与待确认入口分开处置。
AI 供应链与存储缺陷：维护方称特定情形下 Claude Code 的响应会包含 GitHub CLI 令牌，若网关记录响应就可能保存秘密；这说明模型调用日志也是凭据资产，而非只有提示词分析价值。
前沿算法/工程逻辑缺陷：正常发布任务接受被改写的构建来源，合法签名证明产物经过该流程，却无法证明输入代码可信；源码、构建来源、产物摘要必须绑定核对。
复合依赖与应急响应缺陷：临时扩大发布权限叠加多组被盗令牌，使构建与审批的身份分离未能阻止攻击；撤销源头令牌也不会自动撤销已经从下游环境偷走的密钥。
边界防御与分层隔离缺陷：模型网关进程可触及多家供应商凭据，载荷还读取云身份和本机配置。运行身份权限、凭据可见范围及外联限制决定实际损失上限。
System Intrusion（系统入侵）：开发者有效凭据被滥用后污染官方分发链，继而窃取下游环境秘密。
先隔离受影响环境并保留证据，再从可信环境重建；维护方特别提醒，不应先在受污染环境直接启动 pip，以免再次触发 Python 启动钩子。
按镜像摘要、实际安装产物和分发时间排查，清查缓存及 CI runner；在未受污染环境轮换该进程可访问的云、数据库和模型服务密钥。
固定构建仓库与提交、限制组织管理员绕过发布保护的能力，对日志中的授权令牌做检测与脱敏；人工审批还须核对构建来源。
事件三 ARTEX 借 ConnectWise 凭据进入下游云租户：AI 把供应商信任变成批量攻击通道
涉及组织与应用：ConnectWise 为服务商和企业提供云备份及管理工具，Microsoft 365 是企业邮件与协作平台，ARTEX 是可调用大模型规划并执行渗透任务的工具，Microsoft 与 Wiz 披露其在真实攻击中的使用。
事件概述：攻击者利用 ARTEX 加速扫描、密码喷洒和应用身份滥用，随后借被盗的 ConnectWise 云应用凭据进入已经信任这些应用的客户租户。租户可理解为企业独立的云服务空间，应用凭据则让程序无需人员交互登录就能调用接口。部分环境出现目录侦察、应用凭据和权限变更，带来持续访问风险；但应用被安装、登录成功与客户数据被窃取，分别需要证据，不能合并统计。
事件时间：活动最早追溯至 2026 年 9 月；ConnectWise 10-16 首次公告；Microsoft 10-21、Wiz 10-22 发布归因、攻击链与调查增量。
事件链接：
影响范围：
Microsoft 报告下游登录尝试涉及超过 2,250 个租户；这是触达范围，不能写成同等数量的租户失陷。
另一组密码喷洒遥测涉及 8 个组织、327 个账户、超过 151,000 次失败登录；该组活动未观察到成功认证，不能与应用凭据滥用后的成功路径混算。
Wiz 在多个 IT 与软件供应商环境发现相似基础设施、工具和攻击模式；工具相同本身不能证明所有事件属于同一操作者。
技术分类归属：Agent层 / 云身份层 / SaaS供应链 / 数据层
事件标签：云AI融合
图3：Microsoft 将超过 2,250 个租户的应用登录触达、8 个组织的 327 个密码喷洒目标账户，以及超过 151,000 次失败登录放在同一信息图中，说明活动覆盖与速度；这些是不同子活动的口径，不能相加或当作已泄露人数。该密码喷洒组未观察到成功认证，图中的租户触达也不等于客户数据已被读取。来源：https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
前周事件增量更新：W40—W41 合刊已分析 ARTEX 在韩国金融机构外围系统攻击中的使用。本期新增 Microsoft 的特定活动归因、ConnectWise 供应链入口与下游身份变更证据；不将韩国案例追溯归于 Storm-0940。
攻击路径：供应商应用认证材料失窃 → 使用客户早已授予的信任关系登录 → Microsoft Graph 侦察 → 添加应用凭据或调整角色 → 即使原供应商应用被停用，新增身份仍可能留下访问路径。
处置边界：ConnectWise 官方指南明确，供应商侧停用应用和撤销凭据不等于各客户租户的本地配置已清理；指南完成也不代表可自行恢复连接。
基础设施与云配置错误：应用既有权限和租户授权把供应商认证材料转化为客户云内的访问能力；本案不应写成 Microsoft 云底层被攻破。
AI 供应链与存储缺陷：供应链风险来自托管应用身份，而不要求客户安装恶意更新。盘点范围应包含已停用业务但仍保留授权的旧应用。
前沿算法/工程逻辑缺陷：ARTEX 加速多个攻击分支的验证与反馈，但突破边界的仍是凭据、权限和应用信任；公开证据不足以把全部活动描述为完全无人操作。
复合依赖与应急响应缺陷：只轮换供应商密钥可能留下攻击者新加的凭据、角色与授权；必须把登录之后的目录变化和数据访问串起来复盘。
边界防御与分层隔离缺陷：备份应用获得超出必要范围的长期权限，会把单一供应商事件放大到多个租户。应按任务约束应用权限并独立监测应用身份活动。
System Intrusion（系统入侵），经第三方信任关系扩散：已确认存在下游后续操作，但不以目标数量替代泄露规模。
按官方应用 ID 和各租户本地对象 ID 盘点，覆盖旧名称及闲置连接；先保留证据并禁用，不以删除应用作为第一步。
联查服务主体登录、Graph 调用和目录审计，区分失败喷洒、成功认证、权限改变及实际数据读取。
清理新增凭据、所有者、授权和角色，核对业务恢复条件；同时缩减备份与管理应用的长期权限。
事件四 Kafka UI 一处失守，AI 串起多云入侵：凭据接力打通 Kubernetes 与部署流水线
涉及组织与应用：Wiz CIRT 是云安全事件响应团队，本案受害组织身份未公开；Kafka UI 用于管理消息系统，Kubernetes 管理容器，CI/CD 与 GitOps 平台负责构建部署，它们在同一企业环境中形成相互信任的执行链。
事件概述：Wiz 披露了一家多云企业遭入侵的调查，攻击者身份未归属。已确认的一条入口是暴露在公网的 Kafka 管理界面远程代码执行问题。攻击者进入容器后读取挂载令牌、环境变量和云元数据，再将凭据用于其他云服务、部署平台与身份系统。研究方依据跨平台并发操作、错误反馈后的即时修正和任务编号等特征，判断 AI 智能体参与了操作。风险重点不是某个单点漏洞，而是一处入口暴露后，许多原本为运维便利建立的信任通道被连续利用。
事件时间：2026-10-19 公开调查；具体受害组织与完整入侵起止时间未公开，不将发布日期写成攻击发生日。
事件链接：
影响范围：
公开案例涉及 AWS、GCP、多个 Kubernetes 集群、身份提供方、CI/CD、GitOps 和数据系统；报告未给出可独立核对的受害组织总数或泄露数据量。
同一来源 IP 在同期扫描超过 600 个其他客户环境，代表扫描覆盖，不是 600 起成功入侵。
研究方对 AI 参与的判断来自行为与代码证据，没有公开足以确认具体模型、厂商或操作者身份的完整记录。
技术分类归属：Agent层 / 基础设施层 / 云身份层 / 编排层 / CI/CD
事件标签：云AI融合
架构形态：runner、集群节点、云角色和 GitOps 控制器各自携带凭据及网络可达性；获得其中一个执行位置后，可继续寻找另一个系统认可的身份。
攻击路径：Kafka UI 入口执行命令 → 容器落点窃取令牌 → 进入云控制面 → 滥用身份模拟与远程管理 → 创建身份和部署任务 → 控制更多集群与数据系统 → 利用可用日志、仓库或网络通道传出资料。
行为边界：报告同时包含成功动作和被拒绝尝试；例如部分外传存储桶创建失败，不应据此推定所有数据外传路径成功。本案也不能仅因使用 AI 就与 ARTEX 或 Storm-0940 合并归因。
基础设施与云配置错误：管理界面公网暴露形成已确认入口；容器又能访问节点身份和敏感内部服务，单工作负载的权限没有成为有效止损边界。
AI 供应链与存储缺陷：秘密散布于 runner、镜像层、ConfigMap、挂载文件与数据库；当一处秘密读取受限时，攻击者仍可从功能相近的存储位置取回凭据。
前沿算法/工程逻辑缺陷：云身份模拟、SSM 远程执行和 GitOps 同步都是合法运维能力；将它们视为天然可信，会漏掉“凭据正确但目的恶意”的组合。
复合依赖与应急响应缺陷：新凭据和新可达目标持续反馈到其他分支，逐项关告警容易给攻击者留下平行路径；响应需要同时控制身份、执行节点与外传通道。
边界防御与分层隔离缺陷：报告描述攻击者通过部署控制器直接改变运行工作负载，部分变化未留下 Git 提交；仅审查仓库历史不足以证明生产状态没有被改动。
System Intrusion（系统入侵）：公开应用利用后，凭据窃取、横向移动、持久化与数据获取形成连续链路。
以下为本报告依据公开调查作出的行为映射，AI 参与程度与攻击归因仍以研究方判断为限。
管理界面经受控入口访问，阻断普通工作负载读取节点高权限身份；分别限制 runner、GitOps 与应用服务账户。
联合分析同一身份或来源在云 API、集群、部署和身份平台的操作，关注新账户、新角色与新流水线短时间连续出现。
比对 Git 期望配置与集群实际状态，并保留控制器直接操作记录；处置时同时撤销身份和恢复受污染部署。
事件五 GCP 账单遭跨项目劫持：模型在别人项目里跑，数十万美元费用却由企业买单
涉及组织与应用：Google Cloud 提供项目、身份和云计费服务，Gemini API 提供模型推理，Wiz CIRT 调查了多起账户入侵后滥用模型账单的事件，受害组织与攻击者身份未公开。
事件概述：攻击者身份未归属。Wiz 调查发现，攻击者通过伪装为 Google 云管理入口的搜索广告窃取账户及验证码，随后利用过大的管理权限修改组织策略、加入外部账号，并把攻击者自己的云项目连接到受害企业的账单。模型推理——即向模型提交请求并获取回答——在外部项目运行，因此受害者能看到费用激增，却看不到那些项目内的提示内容与回答。研究方报告，部分组织在一至两天内出现数万至数十万美元未授权费用；这类损失不能仅靠监测本组织工作负载发现。
事件时间：2026-10-20 发布多起事件调查；未公开各起入侵的完整日期与受害者名单。
事件链接：
影响范围：
已披露影响是 GCP 高权限身份、账单账户及 Gemini API 费用；具体受害组织数量、单家最终结算金额和赔付结果未公开。
一些案例在初始访问后 24—48 小时出现数万至数十万美元费用；该范围不能换算成本轮全部事件的总损失。
外部项目内的模型调用内容不可见，不等于所有计费和 IAM 操作都没有审计记录。
技术分类归属：云身份层 / 模型服务层 / 云计费控制面
事件标签：云AI融合
架构形态：项目是资源与调用的归属边界，账单账户是费用支付边界，二者可以分别由不同主体控制；安全日志只覆盖自有项目时，便容易漏掉外部消耗。
攻击路径：搜索广告 → Google Sites 跳转与伪登录 → 窃取账户和验证码 → 高权限登录 → 删除成员域限制 → 加入外部身份 → 关联外部项目 → 批量调用模型并向受害账单计费。
持续访问：研究方还观察到原有账单管理员被降为只读，使受害者无法直接在控制台撤销外部项目关系，延长处置时间。
基础设施与云配置错误：单个被盗账号同时具备身份、策略与账单管理能力，使一次钓鱼足以重建费用授权关系；不需要先控制企业生产服务器。
AI 供应链与存储缺陷：本案不是模型权重或训练数据投毒，核心资产是可支付模型推理费用的账单权限；API 密钥轮换不足以撤销这种授权。
前沿算法/工程逻辑缺陷：成本按账单归集、请求按项目留痕，导致安全视野与财务责任错位；这是本案例的关键架构风险。
复合依赖与应急响应缺陷：验证码也被钓鱼获取，提示普通 MFA 并非本次链路的充分防线；异常账单通知若缺少独立响应身份，管理员被降权后仍可能无法止损。
边界防御与分层隔离缺陷：组织策略、外部成员和计费连接应分别受控；不能让业务开发账号同时修改这些限制。
Social Engineering（社会工程）入口，继发 System Intrusion：钓鱼取得有效账号后，攻击者以合法管理接口进行财务资源滥用。
同时监测新项目计费关联、外部账单成员、组织策略删除和管理员降权，不能只看自有项目内的模型调用。
分离组织策略与账单管理身份，采用抗钓鱼认证和独立应急账户；对异常消费设置能够触发人工或自动处置的流程。
发生事件后撤销会话、移除外部成员与项目关联并恢复策略，核对账单是否继续增长；单独更换 Gemini API 密钥不构成完整止损。
事件六 Zeabur 未轮换凭据再次失守：逾 321 万条环境变量被读取，旧备份也成跳板
涉及组织与应用：Zeabur 是托管应用与数据库的云部署平台，n8n 用于自动化工作流，new-api/one-api 用于聚合模型接口，这些租户应用及其秘密与平台内部管理系统一起进入本次攻击路径。
事件概述：攻击者身份未归属。Zeabur 于本周公布调查：攻击者利用仍有效的内部云密钥与无到期时间的集群管理令牌，从公网进入共享环境，并沿备份和秘密管理系统取得更多凭据；另一条路径进入 GCP 托管主机。两条路径在内部网络汇合后，攻击者读取了平台数据库中的环境变量和账户资料。平台承认，八月事件后的轮换未覆盖这些关键凭据。调查还发现对 n8n、模型网关及 AI 密钥的定向搜索，但最初凭据是否确实来自八月泄露仍属假设。
事件时间：入侵主要发生于 2026-10-14—15；初步调查报告于 10-19 发布，按本周新增根因与影响披露纳入。
事件链接：
影响范围：
平台确认数据库读取涉及 3,218,965 条环境变量记录及 321,810 个账户资料；记录数量不能换算成相同数量的独立密钥或用户。
确认 101 台 GCP 主机出现 root 登录，其中 50 台被加入攻击者 SSH 公钥；客户磁盘的 16 份副本被挂到攻击者创建的虚拟机。
865 个数据库服务遭执行读取命令，但部分命令失败、日志缺少输出，不能认定所有内容均已被取走。AI 密钥被搜索已获观察，Bedrock 调用尝试则全部失败且未计费。
技术分类归属：基础设施层 / 数据层 / 云身份层 / AI服务凭据
事件标签：云AI融合
图4：截图保留 Zeabur 官方页面的原始 HTML 图及样式，展示路径 A 经共享集群、备份和秘密服务获取内部凭据，路径 B 经 GCP 主机进入，两者在内部网络汇合后访问数据库。图中保留了 Assessed 与 Confirmed 等证据等级：旧备份读取和初始化密码获取有评估成分；它不能证明最初凭据来自八月事件，也不能证明 865 个数据库均完整泄露。来源：https://zeabur.com/blogs/october-2026-security-incident
架构形态：平台管理接口、用户容器、备份、秘密服务和内部数据库存在多级凭据依赖；旧凭据能打开的不是单一资源，而是能读取下一份凭据的路径。
路径 A：集群管理员令牌与 AWS 密钥 → 共享集群与备份 → 生产秘密 → 内网管理凭据和数据库账号。
路径 B 及汇合：旧 GCP 密钥读取初始化设置中的 root 密码这一环节为平台评估 → 主机 root 登录为已确认 → 从已控主机加入内部网络节点 → 使用只读数据库账号批量读取平台资料。
处置反复的原因：平台确认新轮换的凭据又进入备份并随后遭使用；必须先切断攻击者获取新秘密的能力，再验证轮换结果。
基础设施与云配置错误：集群管理面公网可达，令牌没有到期时间；GCP 初始化配置保存 root 密码，且默认服务账号权限过大。
AI 供应链与存储缺陷：配置仓库、任务和备份长期保存秘密；n8n 数据库中的加密凭据与可读取的解密密钥共同暴露时，数据库加密无法继续发挥隔离作用。
前沿算法/工程逻辑缺陷：本案没有证据表明模型算法失效。关键工程问题是内部服务和用户负载共享集群，以及网络节点标签足以获得广泛数据库可达性。
复合依赖与应急响应缺陷：八月事件后未完整覆盖管理令牌和云密钥，轮换清单没有覆盖历史配置与备份。平台也纠正了此前“所有内部管理密钥已撤销或轮换”的不完整说法。
边界防御与分层隔离缺陷：只读数据库账号仍能读取全库，容器内执行又可绕过单纯数据库密码轮换；凭据、网络与数据读取范围必须共同收缩。
System Intrusion（系统入侵）：有效管理凭据滥用串联多云、容器与内部数据访问，已有明确数据读取记录。
将配置仓库、旧备份、服务账号、签名密钥和内部网络凭据纳入同一撤销清单；先切断读取新秘密的路径，再轮换并验证旧凭据失效。
将租户工作负载与平台管理系统隔离；数据库只读账户也要限制表、字段和租户范围，备份访问密钥独立托管。
已被 root 登录的主机按受控环境重建，并清查磁盘副本、SSH 公钥与模型服务账单；只改数据库密码不足以消除容器或主机级访问。
内容编辑：浦明
责任编辑：吕治政
本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。
关于我们
绿盟科技研究通讯由绿盟科技创新研究院负责运营，绿盟科技创新研究院是绿盟科技的前沿技术研究部门，包括星云实验室、天枢实验室和孵化中心。团队成员由来自清华、北大、哈工大、中科院、北邮等多所重点院校的博士和硕士组成。
绿盟科技创新研究院作为“中关村科技园区海淀园博士后工作站分站”的重要培养单位之一，与清华大学进行博士后联合培养，科研成果已涵盖各类国家课题项目、国家专利、国家标准、高水平学术论文、出版专业书籍等。
我们持续探索信息安全领域的前沿学术方向，从实践出发，结合公司资源和先进技术，实现概念级的原型系统，进而交付产品线孵化产品并创造巨大的经济价值。
本文转载自微信公众号「绿盟科技研究通讯」，查看原文。版权归原作者所有，如有侵权请联系删除。