大家好，今年五月我在自己的路由器上发现了一些不错的漏洞，今天终于可以展示给大家了！
本仓库中的两个漏洞都是经过身份验证的拒绝服务（Denial of Service）漏洞！
我并不清楚这些漏洞具体是如何以及为何产生的技术细节，我们从未收到 Calix（此处的厂商）的回复，所以……耶！真有趣！
这也是我人生中第一个和第二个 CVE，买一送一，不客气。
CVE-2026-19745 是一个影响我路由器的资源关闭或释放不当（Improper Resource Shutdown or Release）导致的拒绝服务漏洞 :)
https://nvd.nist.gov/vuln/detail/CVE-2026-19745
“在 Calix GigaSpire 26.1.0 中发现了一个缺陷。受影响的是 Web 管理界面组件中文件 utilities_configurationsave.cgi 的某个未知函数。对参数 sessionKey 执行操作可导致拒绝服务。该攻击可远程发起。该漏洞利用代码已公开，可能被使用。厂商已在此披露早期被联系，但未以任何方式回应。”
VulDB 认为合适的 CWE 是 CWE-404，这让我有点惊讶，因为我原本想的是 CWE-835。 遗憾的是，我没有关于此问题为何发生的确切技术细节，但我可以告诉你，这两个 CVE 完全是我意外发现的。
5月30日：发现漏洞，起初我以为只是某种速率限制，直到我尝试在另一台电脑上使用该网站，结果发现并非如此。
5月31日：经过心理准备后，我决定即使最初判断有误，这也值得上报。
6月15日：我满16岁了，显然这对时间线非常重要。
6月24日：向 VulnDB 提交报告。
6月26日：Calix（终于）回复了我，这出乎意料，他们声称不存在漏洞，但会在下一个版本中“修补”它？？干得好，我当天也回复了，附上了证明我的报告是真实漏洞的视频证据，之后再也没有收到回复。
8月13日：VulDB 分配了 CVE 编号。
Calix 表示这是应用程序等待用户输入时超时导致的预期行为，这很可能确实是原因，但这不应该对其他任何用户产生影响。
https://github.com/user-attachments/assets/6aa509d4-ee69-4ed6-a9bb-1324f77a7036
正如时间线所示，Calix 除了因为缺乏沟通而让 CVE 得以分配之外，实际上没什么用处。据我所知，VulDB 联系了 Calix，但他们自己也没有得到回复。
我很想给你看他们给我的回复，但遗憾的是我不被允许 :( 基本上他们只是说无法复现，并且除了 traceroot 那个（见下文）之外，他们不打算修补。
https://github.com/user-attachments/assets/62c1ae62-8d52-4e97-975c-3c14ee6d8c95
我在查看浏览器界面暴露的所有端点时，注意到了 traceroot.cmd，它接受一个取消操作。
我心想，如果我直接取消一个并不存在的 traceroot 会发生什么。
我试了一下，结果整个界面似乎崩溃了，所有人都被登出，过去的 cookie 等数据也全部失效。
这就是 Calix 将要修补的那个，他们声称不存在 DoS，但它触发了一条“意外”的代码路径。
我要向 VulDB 的审核和安全团队致以崇高的敬意，他们在审核我的报告并认真对待方面做得非常出色（不像这里的某个人）。我期待未来提交更多报告！:)
附注：提交时我非常紧张，因为这是我第一次做这种事情，我非常不确定我发现的到底是不是漏洞。然而，当我在另一台电脑上对所有漏洞进行测试时，我就知道了！也就是说，我的第一台电脑扮演攻击者，而第二台电脑处于登录状态，两台电脑上都观察到了影响！
我确实认为 VulDB 的分析有些过度了（可以说是 AI 生成的），但无所谓，比如将其描述为“严重安全缺陷”，而实际上并非如此。
在时间线期间，我还发了大约2封跟进邮件，除了他们使用的邮件服务返回的错误之外，什么回复都没收到，而之前那封邮件也被无视了。
神级技术，我的天
https://nvd.nist.gov/vuln/detail/CVE-2026-19745
https://nvd.nist.gov/vuln/detail/CVE-2026-19746
