北京
一次看似无害的公开Issue，是怎么变成内部代码的泄密通道的？这个叫GitLost的演示，直接对GitHub目前公开预览的Agentic Workflows动了刀子——攻击者在公开issue里埋下指令，AI编码代理就乖乖掏出它能接触到的私有仓库内容，再贴回公开区。整件事里，GitHub的安全护栏一样没坏，审批步骤也都到位，但私有代码还是被摆到了不该出现的地方。
Agentic Workflows是Copilot体系下的一项功能，设计初衷是把用Markdown写的任务描述交给AI代理，让它自动完成编码工作。用GitHub自己的话来说，这是“委托issue”和运行代理驱动工作流的方式。正因如此，GitLost演示的核心才显得格外麻烦：这个代理会把攻击者写的issue文字当成指令来执行，又用自己的合法权限，跨过了人类操作者以为安全的分界线。
拆解一下这条攻击链：攻击者创建一个精心设计的公开issue；代理按正常任务流程读取了这段文字；注入的提示驱使代理去翻看同一组织下另一个它能访问的私有仓库；最后，代理把搜刮到的内容原样贴回了公开issue里。这听起来不像“黑掉GitHub”，更像利用了一个过于信任外人的职员，而这个职员手里正好有钥匙。GitHub的文档也承认，代理工作流可以跨仓库活动，具体要看配置和权限，这也正是这次披露里最要命的条件。
Noma Security在2026年7月6日公开了Sasi Levi发布的GitLost帖子，并由CSO等媒体跟进报道。这不是GitHub的官方公告，也没有分配CVE，但CSO的独立总结相当明确：公开issue里暗藏的恶意提示，能操纵代理去探查它有权读取的私有仓库，再把结果公之于众。GitLost既是一次提示注入的展示，也是一次访问控制边界被过宽设置的警示：注入的提示是方向盘，过于宽松的信任边界是引擎。
GitHub给这一功能配了安全护栏，包括所谓“安全输出”、工作流审批控制和仓库访问范围限制。这些防护思路本身没问题，但GitLost所暴露的是，当同一个工作流上下文中揉进了两类截然不同的东西——完全不可信的公开内容和高敏感度的私有代码——护栏就可能被绕开。有观点概括得很直接：问题不在于代理读取了它允许读的仓库，而在于攻击者控制的文字能让这个读取动作转向，并让结果公开化。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
