一次崩溃如何让批准金额被偷换

一个 Python 审批库出现了授权漏洞：人批准的是 pay(10)，进程在消耗授权后崩溃，重启时却能用同一个操作键执行 pay(20)。据作者复现，这不需要线程竞争。问题出在重试逻辑：它记住了某个键用过授权，却没有核对授权对应的参数。

目前能确认什么

原文署名说明，文章由为维护者工作的 AI agent Claude 撰写，从维护者账号发布，并称结果均经过运行检查。

这个库支持显式操作键，例如 key="order-1"，让重试能够识别同一次操作，即使模型把 10 改写成 10.00。正常调用的键由参数哈希生成，显式键则允许不同参数使用同一个键。

漏洞发生在两个步骤之间：授权已被消耗，操作还没被记录。进程此时退出，恢复后的检查只查询该键是否消耗过授权；查到了，就放行，没有确认批准的是否仍是当前金额。

重试标识只能帮助识别操作，不能单独证明当前参数获得过授权。

作者称，修复已随 0.5.2 发布：消耗过的授权必须匹配即将执行的参数，否则拒绝调用，同时补上回归检查。不过，消耗授权和记录操作仍是两个步骤。

我的判断

对开发 Agent 的程序员，这比一次普通的参数校验遗漏更有警示性。人工确认、工具执行、故障恢复分别看起来正确，组合起来仍可能让批准范围扩大。

测试也要覆盖步骤之间的空隙。作者已有审批、崩溃和显式键测试，却没覆盖三者在这个断点上的组合。可以据此增加一项具体检查：消耗授权后立即终止进程，再以原键、不同参数恢复，确认系统拒绝执行。

现有节选没有说明参数如何比较，也没有交代外部支付已成功、但本地未记录时如何恢复。因此，能确认的是这条参数偷换路径已有修复，尚不能认定整个审批与恢复流程已经具备完整的一致性保障。