n8n 2.47.6、2.47.7、2.48.3 Beta、2.48.4 Beta、3.2.2预发布与1.123.96为何要分别校验参数和权限？

在n8n中，参数编码与权限检查解决的是不同问题：前者限制请求怎样组成，后者决定谁能使用账户、凭据或网络能力。2.47.6、2.48.3 Beta和3.2.2预发布覆盖这组四项漏洞的修复，1.123.96仅列在其中两项；后续2.47.7正式版与2.48.4 Beta的执行记录脱敏调整，不能替代对安全修复起点的区分。

资源ID进入URL时，业务值与路径结构不能混在一起

GHSA-c772-hjfp-gfc2的关键，是多个集成节点将记录、表或资源ID放入API路径时没有编码。相对路径片段可能改变同一外部服务内的目标端点。工作流若从Webhook请求体等外部输入中取得这些参数，节点的已存凭据就可能被用于原设计之外的资源。

这说明即使凭据仍保存在服务器，未经约束的数据仍可能改变特权请求的含义。披露中的影响包括超出预期的读取、修改和删除，而不是泛指任意域名都可由参数替换。相应补丁起点是1.123.96、2.47.6、2.48.3 Beta和3.2.2预发布。

一个凭据标识为什么不能自动代表使用授权

GHSA-h59h-rf6m-7jp5中，激活工作流会使用触发器上的凭据注册外部服务，但没有核验发布工作流的用户能否访问该凭据。成员知道另一用户的凭据ID，就可能激活引用它的触发器，创建或删除外部Webhook，并把相应资源事件送入自己的流程。

标识对象与授权使用对象必须分开。问题并不等于所有凭据明文都被公开，也不能仅用ID不容易猜测来判断安全。此项同样列出1.123.96、2.47.6、2.48.3 Beta和3.2.2预发布作为修复版本。

自定义网络目标仍应服从访问边界

GHSA-g333-hr44-g82p是另一类请求边界问题。AWS Bedrock Chat Model和Embeddings AWS Bedrock节点使用AWS凭据中设置的自定义运行端点时，请求未经过SSRF保护。能够创建AWS凭据的成员，可能使请求抵达内部或受限地址，并在节点错误中看到响应开头。

它与资源ID的相对路径问题不同：这里涉及运行端点及网络访问控制，限定了节点与成员能力。补丁起点为2.47.6、2.48.3 Beta和3.2.2预发布，不能把1.123.96在另两项中的补丁身份移用于本项。

较高权限也不能绕过所有者账户保护

高危GHSA-q8rc-7m84-mfvj涉及自定义实例角色。使用自定义角色功能、并持有用户管理权限的成员，可能利用未受同等保护的密码重置链接或角色变更操作，接管实例所有者账户或改变其角色，从而完全控制实例。这不是无身份前提的匿名攻击。

相应补丁为2.47.6、2.48.3 Beta和3.2.2预发布，披露没有列入1.x补丁。所有者双因素认证和收紧自定义角色权限属于临时防护，不能说已经完整消除漏洞。

修复范围与发行渠道要同时成立

正式2.47分支的起点是2.47.6，2.47.7属于后续补丁；2.48.3与2.48.4均为Beta，3.2.2也标为预发布，不能因其数字更大就默认作为稳定生产升级目标。1.123.96仅明确修复API路径和触发器凭据这两项。

这四项问题共同强调权限边界，却不具有相同利用前提。公开披露没有提供已在野利用的证据，也没有已知CVE编号；不能把可能影响写成已经发生的数据泄露，或用一项临时缓解替代全部修复。