这个是第三方 cos 的问题，不是 jfinal 内部所能控制的

因此，我升级了 cos 版本，解决了这个问题，升级 cos 到 2019.8 版本即可，具体的改进见 gitee:
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130
https://gitee.com/jfinal/cos/commit/5eb23d6e384abaad19faa7600d14c9a2f525946a

攻击者是利用请求数据格式不对，在上传文件的过程中让 cos 抛出异常，而 cos 抛出异常以后并没有删掉已经上传的一部分内容

解决思路也就极其简单：
在上传逻辑的最外层用 try catch， 在 catch 块中无条件删除所有已经上传的部分内容
https://gitee.com/jfinal/cos/commit/8d26eec61f0d072a68bf7393cf3a8544a1112130

jfinal 是不可能犯这种低极错误的，但难保第三方出问题， 所以 jfinal 诞生 8 年多以来，坚持让 jfinal 不强制依赖任何第三方，对于在部分可选功能时 provided 使用的第三方，也是极度克制的

基本就是 JDBC、reids、数据库连接池、json、文件上传这些基本功能有一个 provided 非强制依赖

多引入一个第三方，就多一个潜在风险

你再回看一下 spring boot 的引入的大量第三方，是不是细思极恐

spring boot 官方给出的一个啥正事也没干的 demo 居然需要 33 个 jar 包依赖，19 M 的体积，如果要添加 AOP、ORM、Template Engine 等常用功能，jar 量还将大量增加：
https://www.oschina.net/news/107259/jfinal-4-2-released

感谢波总

spring boot 的引入的大量第三方，细思极恐