为何StackOverflowError值得被授予CVE漏洞编号？

近期针对Java库的漏洞报告持续增加，不少报告指出部分库提供的递归函数在处理恶意输入时，会耗尽可用栈深度并触发StackOverflowError。典型案例如CVE-2023-1370：某JSON解析器遇到嵌套深度超过栈大小的对象结构时，就会抛出该错误。

很多人会有疑问：StackOverflowError不是会直接中止当前请求吗？比如在Web容器中，触发该错误的请求会被终止，系统返回HTTP 500错误码，出错线程后续仍能处理其他请求，看起来不会影响服务整体运行。而且CVE-2023-1370的修复方案也只是改为嵌套深度达到400时抛出ParseException提前终止执行，效果和原逻辑类似：恶意输入对应的请求被终止，服务继续运行。那为什么这类情况会被当成漏洞上报？

核心原因可以归纳为以下几点：

• 线程恢复的不确定性：Java规范并未保证StackOverflowError触发后线程一定能正常恢复。这类Error属于JVM层面的严重错误，部分场景下线程可能直接崩溃，无法继续处理后续请求。若攻击者持续发送恶意请求，可能导致线程池耗尽，引发服务级别的拒绝服务（DoS）。
• 额外的资源消耗：触发StackOverflowError前，递归已经消耗了大量栈资源，JVM清理栈帧的开销远大于提前抛出业务异常。高频恶意请求会让JVM持续处于高负载的栈清理状态，间接拖慢服务响应速度，甚至引发内存、CPU等其他资源耗尽问题。
• 错误处理逻辑的破坏：StackOverflowError会绕过应用层的正常错误处理流程。比如原本应用会捕获解析异常并返回友好的错误提示，而StackOverflowError会直接触发容器的兜底错误逻辑，不仅影响用户体验，还可能泄露内部服务细节。
• 合规与安全基线要求：多数企业的安全合规标准（如OWASP Top 10）将“未限制递归深度”归类为DoS风险点。即使实际影响有限，为了符合合规要求，这类问题也需要被列为漏洞并修复。
• 边界场景的风险放大：在一些特殊部署环境中（如栈大小极小的容器、共享线程池的多租户服务），很小的嵌套深度就可能触发StackOverflowError。攻击者无需发送大量请求就能让服务异常，风险被显著放大。

内容的提问来源于stack exchange，提问作者haui