[GHSA-xcjm-wqff-m669][CVE-2026-49219] Reassess severity - namespace bypass enables unauthenticated RCE on `--enable-pipes` builds, currently rated Medium (file read only)

从链接的 GHSA 公告和引用的 ImageMagick#6339 讨论开始；未指定任何仓库文件或测试。将已发布的描述和 CVSS 与拟议的 RCE 影响及构建前提进行比较，然后确定在严重性争议解决后是否应修订公告记录。

Advisory: https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-xcjm-wqff-m669
Current CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 5.5 (Medium)
Current description: "An incorrect parsing of the filename can result in a policy bypass and read files disallowed by a security policy using a symlink."

Summary of the disagreement

I am the reporter of this advisory. The published score (AV:L … C:H/I:N/A:N, 5.5 Medium) treats the bug as a local arbitrary-read of disallowed files via symlink. That framing materially understates the impact. The same primitive - ParseNamespace silently splitting attacker-controlled filenames on "::" so that every nameless <policy domain="path" rights="none" pattern="…"/> rule is skipped - also reopens the popen filename-handler sink for builds compiled with --enable-pipes, yielding unauthenticated remote code execution as the ImageMagick process user. I supplied a working PoC for the RCE chain during disclosure.

The maintainer's position is that --enable-pipes is off by default and that enabling it carries documented risk; on that basis they decline to treat the bug as critical and frame the impact as file read only.

My position is that the severity of a policy-enforcement bug must be scored against the deployments that actually rely on that enforcement, not against the default build. --enable-pipes is widely enabled in real deployments (document-conversion pipelines, CI images, certain Windows builders), and those operators followed ImageMagick's own documented mitigation for the |cmd popen handler - the nameless <policy domain="path" rights="none" pattern="|*"/> deny rule recommended by the maintainer in ImageMagick/ImageMagick#6339. This advisory's bug silently nullifies exactly that rule. The result is unauthenticated RCE in deployments whose admins did everything the project told them to do; describing that as "file read via symlink" leaves those operators with a false sense of security and a strong incentive to defer the patch. CVSS 4.0 has a field designed for exactly this situation - Attack Requirements AT:P ("Present") - which encodes the --enable-pipes precondition honestly without erasing the RCE impact.

Why CVSS should reflect RCE, not file-read

1. The bug is in the policy enforcement engine, not in --enable-pipes. --enable-pipes is a build-time feature; ImageMagick documents the maintainer-recommended mitigation against the |cmd popen handler as exactly the nameless <policy domain="path" rights="none" pattern="|*"/> deny rule that this advisory's bug silently skips (see the maintainer's response in ImageMagick/ImageMagick#6339). Admins who followed the project's own documented mitigation are exposed.

2. CVSS Attack Requirements explicitly model this case. CVSS 4.0 AT:P ("Present") is the correct way to express a precondition like "the build was compiled with --enable-pipes." Marking AT:P scores the bug honestly without ignoring that the precondition exists - which is what the maintainer's "disabled by default" objection seems to require.

3. The published narrative is incomplete. "read files disallowed by a security policy using a symlink" describes one consequence of the bypass. The same primitive enables |cmd filename injection which leads to code execution. Listed CWEs (CWE-22, CWE-78, CWE-200, CWE-863) already acknowledge command injection (CWE-78); the CVSS vector should match.

Proposed corrections

Why this matters for downstreams

The current Medium / file-read framing is being used by distros and consumers to decide patch urgency. Several stacks ship --enable-pipes enabled (document-conversion pipelines, certain Windows builders, some CI images) and configure the documented |* deny rule. Those deployments are unauthenticated-RCE exposed but, reading this advisory, will believe their exposure is local file-read only - and may rationally choose to defer updating, since arbitrary read with local access is a much lower urgency than unauthenticated remote code execution. That is the consumer harm I am asking the database to correct.

Thanks for considering. Happy to provide the validation Dockerfiles on request.