CVE
该标签下有 9 篇文章
先修哪个 CVE？CVSS、EPSS、KEV 各自衡量什么
CVSS 是严重程度，EPSS 是被利用的概率，KEV 是已确认被利用的事实，三者不能互相替代。本站对全部 1,695 个 KEV 条目的统计：64% 低于 CVSS 9，24% 低于 EPSS 0.1——“只修高分”和“EPSS 低就放着”在实际数据面前都会失效。按 KEV → 高 EPSS → 高 CVSS 排序，再用你自己的暴露面来定期限。
Next.js 和 React 的漏洞多吗？CVE 数据实际显示了什么
数据显示，React 核心几乎没有 CVE，而 Next.js 的 CVE 数量多且在增加。重要的是它们出现在哪里：集中在中间件、缓存、图片优化和 Server Actions 上，排名靠前的 CWE 是 SSRF、反序列化和授权绕过。本站的结论：不应把 Next.js 只当作前端框架。它是作为服务器运行的，所以要像防御服务器一样防御它：在访问数据处再次授权，对外部请求使用允许列表，把 Server Action 端点放在认证之后。
漏洞（CVE）处置实务：彻底修复，并持续监控复发
漏洞处置不是『修了』就完事。完成＝①扫描②修复③隔离/移交④监控四点齐备才算数。尤其在加上监控（每日变化检测）之前都算未完成——因为依赖明天又可能变得脆弱。修复内容哪怕100分，只要下一次部署就被覆盖，也等于0分。小团队靠自动变化检测和『local→push→deploy』这两条纪律就能保持安全。
osv-scanner 的安装与使用：自动找出依赖包里的 CVE
osv-scanner 是一款免费工具，扫描锁文件或容器以排查依赖中的 CVE。本文把安装、运行、CI 集成做成步骤，并理清它与 npm/pnpm audit、Dependabot 的取舍。本站的观点：哪个工具合适，取决于你的架构。多语言混用或不依赖 GitHub 就用 osv-scanner，单一 npm 用自带的 pnpm audit 就够了。
什么是 CVE？漏洞统一编号机制的原理
CVE 是给漏洞分配的全球通用标识编号（例如 CVE-2025-12345）。它让所有人能用同一个名字引用同一个漏洞，是对策与监控的起点。CVE＝名字、CVSS＝严重程度、KEV＝是否正被利用，职责各不相同。对个人而言，用机器监控来追踪才现实。
什么是 RCE（远程代码执行）——为什么它是最糟一类的漏洞
RCE 是一种让攻击者能在服务器上执行任意代码的漏洞。它不止于信息泄露，而是直接通向被接管，属于最糟一类。损害能扩散到多远，由「该进程的权限」决定。防御的关键在于迅速更新、CVE 监控、最小权限。
Equifax 信息泄露事件（2017）——未打补丁的 Apache Struts 导致 1.47 亿人泄露的原因与防御
原因是已经发布修复补丁的已知 CVE（CVSS 10.0）没有被应用到公开系统上。监控设备因证书失效导致长达 76 天都没察觉数据外带，使损失扩大。在你的环境里，要用资产盘点、补丁 SLA、机器监控、检测健全性来防止重演。
Log4Shell（CVE-2021-44228）——日志库漏洞，以及为何难以迅速确认自己是否在用
Log4j 的漏洞（CVSS 10.0）。核心问题在于经由间接依赖（传递性依赖），在不知不觉中正在使用它。日志输出这一被动处理成了攻击通道。SBOM 与依赖的机器化监控、迅速打补丁、对后续 CVE 的追踪，都是教训所在。
安全运维 Next.js：建立不在已公开CVE上掉队的机制
框架的最大风险是放任已公开的CVE。以实际运行的版本判定，用 Dependabot/osv-scanner 自动监控，尽快更新，并以最小权限运行，这四项做法是防守的关键。本站的看法：个人开发者通常缺的不是知识，而是让运维持续下去的方法；不漏看CVE的机制比速度更重要。