本文详解 OkHttp 间接引入的 org.jetbrains.kotlin:kotlin-stdlib 中 createTempDir/createTempFile 函数权限宽松漏洞（CVE-2021-40576）的本质、实际影响范围及可行缓解策略，强调风险需结合使用场景评估，而非盲目升级或排除。
本文详解 okhttp 间接引入的 `org.jetbrains.kotlin:kotlin-stdlib` 中 `createtempdir`/`createtempfile` 函数权限宽松漏洞（cve-2021-40576）的本质、实际影响范围及可行缓解策略，强调风险需结合使用场景评估，而非盲目升级或排除。
在使用 Snyk 等工具扫描 Maven 项目时，你可能会看到类似如下告警：
Vulnerable module: org.jetbrains.kotlin:kotlin-stdlib Introduced through: com.squareup.okhttp3:okhttp@4.10.0
该问题源于 Kotlin 标准库中 kotlin.io.createTempDir() 和 kotlin.io.createTempFile() 这两个函数（自 Kotlin 1.4.21 起被标记为 @Deprecated）。其根本风险在于：默认创建的临时目录/文件采用宽松的文件系统权限（如 rwxrwxrwx 或 rw-rw-rw-），可能导致本地未授权用户读取敏感内容——前提是这些临时文件中确实存有敏感数据（如 API 密钥、用户凭证、加密密钥等）。
⚠️ 关键前提：漏洞 ≠ 实际可利用风险
该漏洞属于“潜在暴露面”，是否构成真实威胁，完全取决于你的代码（及所用依赖）是否调用了上述函数，以及调用后是否写入了需保密的数据。OkHttp 本身并未使用这两个函数（官方已确认），因此它只是“携带”了存在该函数的 kotlin-stdlib，而非主动触发风险。
如何判断你的项目是否真正受影响？
请执行以下三步检查：
- 静态扫描调用点：在项目源码及所有直接/传递依赖中搜索 createTempDir( 和 createTempFile(（注意大小写和包名 kotlin.io）；
- 审查调用上下文：若存在调用，确认是否向生成的临时文件/目录中写入了敏感信息（如 FileWriter, ObjectOutputStream, writeBytes() 等）；
- 验证权限控制：检查调用后是否显式设置了安全权限（例如通过 setReadable(false, false)、setWritable(false, false) 或 Java NIO 的 Files.setPosixFilePermissions()）。
示例：不安全写法（应避免）
val tempDir = kotlin.io.createTempDir() // 默认权限可能为 777
val secretFile = tempDir.resolve("token.txt")
secretFile.writeText("eyJhbGciOi...") // 敏感内容明文写入
// ❌ 未限制权限 → 风险成立示例：安全替代方案（推荐）
// ✅ 使用 Java NIO 创建带严格权限的临时目录
val tempDir = Files.createTempDirectory("myapp", PosixFilePermissions.asSet(
PosixFilePermission.OWNER_READ,
PosixFilePermission.OWNER_WRITE,
PosixFilePermission.OWNER_EXECUTE
))
// ✅ 或使用 Kotlin 的 createTempFile 并立即设置权限
val tempFile = kotlin.io.createTempFile()
tempFile.setReadable(false, false) // 禁止其他用户读取
tempFile.setWritable(false, false) // 禁止其他用户写入
tempFile.writeText("safe-content") // 即使写入也无泄露风险能否通过 Maven “修复”该漏洞？
简短回答：不能通过常规依赖管理“一键修复”，但可通过合理手段有效管控风险。
| 方法 | 可行性 | 说明 |
|---|---|---|
| 升级 kotlin-stdlib 到“无此函数”版本 | ❌ 不可行 | 该函数自 Kotlin 1.4 引入，后续所有稳定版均保留（仅标记为 @Deprecated），官方暂无移除计划。 |
| Maven |
❌ 危险且无效 | OkHttp 4.x 已不再强依赖 Kotlin；但若项目本身是 Kotlin 项目，排除会导致编译失败或运行时 NoClassDefFoundError。 |
| 强制指定更高版本 kotlin-stdlib | ⚠️ 无实质改善 | 如 |
| 禁用 Snyk 对该漏洞的告警（需充分评估） | ✅ 可行 | 若经上述三步确认无调用或无敏感数据写入，可在 .snyk 文件中忽略该规则："ignore": ["SNYK-JAVA-ORGJETBRAINSKOTLIN-2331819"] |
✅ 最务实的解决方案是：
- 保持 kotlin-stdlib 与项目 Kotlin 编译器版本一致（如 Kotlin 1.9.x 项目使用 kotlin-stdlib:1.9.20）；
- 在代码中*彻底避免使用 `kotlin.io.createTemp**，改用 Java NIO 的Files.createTempDirectory()/Files.createTempFile()`，并显式设置 POSIX 权限；
- 对历史代码进行审计，替换所有不安全调用；
- 将该检查纳入 CI 流程（如使用 Detekt 规则 ForbiddenMethodCall 拦截 kotlin.io.createTempDir）。
总结：这不是 Kotlin 应用的“普遍漏洞”，而是可控的使用风险
❌ 错误认知：“所有 Kotlin 项目都因 kotlin-stdlib 而带毒。”
✅ 正确认知：“只要不调用问题函数，或调用后未存敏感数据/已加固权限，即无实质风险。”
OkHttp 作为纯 Java 实现的 HTTP 客户端，自身不使用 Kotlin I/O 函数，因此其引入 kotlin-stdlib 属于“被动携带”。真正的责任边界在于你的业务代码如何使用临时文件资源。与其耗费精力尝试“删除标准库”，不如建立安全编码规范：默认信任 Java NIO 的权限可控性，拒绝使用未经加固的 Kotlin 便捷函数——这既是合规要求，更是工程健壮性的体现。
