安全研究员 Eaton 打开了一个网址。一个很普通的网址——My Eicher 平台前端用到的 API 端点，用来验证用户手机号。他随手在这个路径上往回退了一级目录。在 99% 的情况下，这种做法只会返回一个 HTTP 错误。但这次，屏幕上的内容让他停下了。
映入眼帘的是一份完整的内部 API 列表。没有登录、没有鉴权，就这么赤裸裸地摊开了。
这处 API 漏洞打开了通往整个平台的大门。以此为基础，Eaton 获得了印度全境商用车辆管理系统的控制权。
My Eicher：印度商用车的「中央控制台」
My Eicher 是 VE Commercial Vehicles（沃尔沃集团与印度 Eicher Motors 的合资公司）面向印度市场推出的车队管理系统。卡车车队老板、物流运营商可以通过它在网页或手机 App 上追踪和管理旗下车辆——实时定位、查看仪表盘读数、设置地理围栏、获取行驶记录。一辆卡车的完整轨迹和状态数据，都在这个系统里流转。
图：Eaton 通过 API 路径回溯发现的内部分部 API 列表。来源：eaton-works.com
按照官方 2024 年 11 月公布的数据，该平台注册了 27.5 万辆车和 11.5 万客户。但 Eaton 从系统里拉出的数字，远不止这些。
一次「碰运气」的发现
漏洞的起点简单得令人意外。Eaton 最初是在研究 My Eicher 前端的 JavaScript 代码时，发现了一些暴露的 API 端点。其中一个用于验证手机号的 API 引起了他的注意：
https://www.myeicher.in/cepauthmgr/user/validateMobileNo
这类暴露在前端代码里的 API 本身并不稀奇——现代 Web 应用几乎都这么做。Eaton 尝试了其他几个端点，都没有什么突破。直到某天他抱着碰运气的心理，在浏览器地址栏里把路径回退到 https://www.myeicher.in/cepauthmgr/user/。
按照他的原话，「在 99% 的案例中，回退 API 路径只会得到 HTTP 错误」。但 My Eicher 的服务端把整个用户相关的 API 目录树完整地吐了出来。更致命的是，这些接口全都是无需鉴权的。
第一个被他验证的端点是「customers」。响应返回了一条完整的客户清单，包含 74.8 万条记录。随后是「users」（17.4 万条）、「persons」（18.6 万条）。每个用户的资料里，还有加密存储的密码。
图：未鉴权的 customers API 返回的 74.8 万条客户记录。来源：eaton-works.com
这些数据本身已经足够严重，但事情远没有结束。
250 万条 OTP 记录与账户接管
系统中有个专门处理 OTP（一次性验证码）的 API。Eaton 发现这个接口返回了自 2021 年以来的全部 OTP 记录，总计约 250 万条。这些 OTP 在被发送到用户手机之前，就已经明文记录在服务端的数据库中。包括发送时间和目标手机号。
Eaton 演示了完整攻陷一个账户的流程：
第一步，从用户列表中任意选择一个手机号（他选了一家大型工程公司的账户），调用 API 向该手机号发送 OTP。
第二步，通过查询 OTP API，根据手机号检索到系统为该次登录生成的验证码。
第三步，把验证码填入登录页面。三步完成，账户易主。
这套操作有一个副作用——目标用户会收到一条真实的 OTP 短信，因此会察觉异常。但 Eaton 找到了第二种接管方式：系统存在直接修改账户密码的 API 端点，可以不经过用户同意重置密码，然后直接用新密码登录。这次修改是否通知用户，他未能确认。
676,514 辆车：追踪地图上的每一个圆点
账户接管意味着车辆控制权的转移。Eaton 进入系统后看到的是实时车辆追踪地图——676,514 辆卡车和巴士在地图上以圆点标注，每一辆都可以点击查看实时位置、行驶速度和历史轨迹。他还能查看车辆的仪表盘读数，内容与驾驶员面前的仪表盘完全一致。甚至可以设置地理围栏：当某辆卡车离开指定区域时，系统自动报警。
图：Eaton 进入系统后看到的实时车辆追踪界面。来源：eaton-works.com
这意味着一个攻击者理论上可以实时追踪印度全境的卡车和巴士运输网络，监视特定车辆的行驶路线，甚至在地理围栏触发时获知车辆的精确位置。
这还没包括最敏感的部分。
76,000 份证件照：Aadhaar 卡与驾照
系统里有一组专门处理文档上传的 API。通过这些接口，Eaton 发现平台上存储了约 7.6 万份用户的证件文件。其中包括印度的 Aadhaar 卡（相当于印度居民的身份证号码系统）、驾驶执照和其他身份证明文件的电子版。这些文件以图片形式保存在系统中，可以通过 API 直接访问。
Aadhaar 卡在印度社会中与银行开户、手机卡办理、政府补贴领取等核心生活场景深度绑定。7.6 万份此类文件的泄露，意味着这些客户面临身份盗用的长期风险。
披露与修复
Eaton 在 2024 年早期就尝试过寻找 My Eicher 的漏洞，但当时没有成功。2025 年重新尝试时，才碰上了这次路径回溯的偶然发现。
2025 年 11 月 3 日，他通过 VE Commercial Vehicles 的 infosec 邮箱提交了漏洞报告。一周后无回应，他再次跟进。11 月 17 日，他追加邮件并抄送了更多相关人员。11 月 20 日，所有内部 API 已无法访问——主要的漏洞被修复了。
此后 Eaton 试图就系统中的其他安全隐患继续联系厂商，甚至尝试通过客服热线转达，但未能与真正关注此问题的人建立沟通。数月后他放弃跟进，并于 2026 年 7 月 27 日将发现公开发布。
这件事意味着什么
My Eicher 的漏洞不是某种高深的安全攻击。没有 0day 利用链，没有复杂的旁路注入。整个过程就是一个安全研究员在浏览器里多按了几下键盘，然后一路顺着暴露的 API 清单走下去。核心问题是：内部 API 的路径暴露给了前端应用，而服务端没有对来自外部对 API 路径的探测做任何限制。
理论上，只要知道 API 基地址，任何人都可以复现 Eaton 的发现。
从数据规模来看，748,363 条客户记录、676,514 辆车辆、76,000 份身份证件、约 250 万条 OTP 记录——这些数字放在一起，意味着平台的数据安全性几乎完全依赖于「攻击者不知道 API 地址」这个前提。而这个前提在系统将 API 路径硬编码到前端 JavaScript 中的那一刻起，就已经不成立了。
VE Commercial Vehicles 已经修复了主要的 API 访问漏洞，但 7.6 万份证件文件在 API 暴露期间是否被其他人获取过，这无从得知。
参考链接：
- Eaton Works: My Eicher hack
- HN 讨论 (item?id=49074670)
