「CVSS 10.0 的 RCE」——这是漏洞新闻里最让人神经紧绷的一句话。本站从零开始解说：为什么 RCE 是「最糟一类」，它和其他漏洞究竟有何不同。
它和其他漏洞究竟有何不同
许多漏洞的被害是有限的。RCE 因为「在服务器本体上运行命令」，量级完全不同。下面拿三个有代表性的漏洞来比较。
| 漏洞 | 代码运行的地方 | 主要被害 | 一般严重度 |
|---|---|---|---|
| XSS | 用户的浏览器 | 窃取会话、篡改画面 | 中～高 |
| SQLi | 数据库 | 读出、篡改数据 | 高 |
| RCE | 服务器本体 | 接管、横向扩散、全部 | 最糟（可达 10.0 级） |
为什么是最糟一类
攻击者能在服务器上执行命令，就意味着那个进程能做的一切，攻击者都能做。
RCE 成立（任意代码执行）
.env 窃取密钥被害范围由「那个进程的权限」决定。正因如此，**容器化、最小权限、隔离（把爆炸半径降到最小）**才有效。若以 root 运行就会全盘沦陷，若以非特权用户＋隔离运行就能把被害关在小范围内。
多数并非「自己的 bug」，而是来自「已知的洞」
RCE 不仅来自自己写出的 bug，更多时候是来自所用框架或库的已知漏洞。历史上的重大事故，也大多是 RCE。
- Log4Shell（CVE-2021-44228）：经由日志组件的 RCE，曾让全世界震动。
- Equifax（CVE-2017-5638）：未打补丁的 Struts RCE，波及 1.47 亿人。
- 放任 CVSS 10.0 而被踩的故事：把已公开的 RCE 放任了数月。
用户能做的防御
不要放任已公开的 CVE（最大的防御）
用机器监控 CVE（Dependabot / osv-scanner），并迅速更新到修复版本。RCE 大半都源于「放任已知的洞不管」。
按实际运行版本来判定
不要看清单里的下限标注，而要按实际正在运行的版本来衡量危险。相信标注会让你误判危险度。
把爆炸半径降到最小
以非特权用户运行，隔离容器与网络。万一被踩，也能把被害关在小范围内。
不要把输入直接交给执行系统
不要让外部输入直通到 shell 命令、deserialization 或模板求值。这是不自己制造出 RCE 的基本功。
接下来阅读
FAQ
QRCE 和常见漏洞（如 XSS）有什么不同？
XSS 等主要在「用户的浏览器内」作恶，而 RCE 能在「服务器本体」上运行任意程序。它会波及服务器的权限、数据和其他服务，因此一般来说最为严重。
QRCE 的被害能扩散到多大范围？
扩散范围取决于「被攻击时正在运行的那个进程的权限」。如果以 root 或较大权限运行，被害将极其惨重；若以非特权用户＋容器隔离运行，就能把被害关在小范围内。所以最小权限和隔离才有效。
Q用户（开发者）这一侧该如何防御 RCE？
除了不让自己写出 RCE 漏洞（例如不把输入直接交给执行系统）之外，最大的防御是「不要放任所用框架/库已公开的 RCE 不管」。CVE 监控和迅速更新是关键。