在本次实验室中，目标是对另一个众所周知的现实世界漏洞 Log4Shell 进行分类排查。由于受影响库在企业软件中非常普遍，它是近年来被利用最广泛的漏洞之一。
我前往国家漏洞数据库（NVD）并查找了该 CVE：
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
我搜索了 CVE-2021-44228 并打开了结果页面。
阅读完描述后，我回答了几个基本问题，以了解实际面临的风险：
我在页面上找到了列出的 CVSS 评分和向量字符串：
我逐段分析了向量字符串，以了解每个部分的实际含义：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
这差不多是向量字符串能达到的最坏情况了：无需权限、无需用户交互、可通过网络远程利用，甚至能影响易受攻击组件本身之外的内容（影响范围：已改变）。这种组合正是 Log4Shell 在披露时被视为如此紧急且影响广泛的问题的部分原因。
我查看了 NVD 页面上该 CVE 的弱点枚举（Weakness Enumeration）部分。
列出的 CWE 是 CWE-917：表达式语言语句中使用的特殊元素的不当中和。通俗地说，这意味着软件接收输入并将其作为表达式的一部分进行评估，却没有事先进行适当检查，这正是攻击者能够通过普通日志消息混入恶意 JNDI 查找的原因。
我考虑了在两种不同场景下，我会将此视为较高风险还是较低风险。
场景 1：易受攻击的软件处于运行状态且可被访问。 较高风险。该漏洞允许攻击者访问和修改 EL（表达式语言）语句，直接影响机密性和完整性。
场景 2：易受攻击的软件安装在已关机且无法访问的机器上。 较低风险。如果易受攻击的软件完全无法被访问，机密性和完整性就能保持完好，因为攻击者没有任何办法与之交互。
在我迄今为止分类排查过的 CVE 中，这个漏洞尤为突出，因为攻击者利用它所需的条件极少：无需权限、无需用户交互，只需网络访问，再加上该漏洞还能影响组件本身之外的系统。它很好地解释了为什么 Log4Shell 一经披露就在整个行业引发了如此广泛的紧急应对。