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

Start with the linked GHSA advisory and the referenced ImageMagick#6339 discussion; no repository files or tests are named. Compare the published description and CVSS with the proposed RCE impact and build precondition, then determine whether the advisory record should be revised after the severity dispute is resolved.

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.