Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#7,875 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Dokumentation
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Bereich
security

Rechercherichtung

Beginne mit dem verlinkten GHSA-Advisory und der referenzierten Diskussion ImageMagick#6339; es werden keine Repository-Dateien oder Tests genannt. Vergleiche die veröffentlichte Beschreibung und den CVSS-Wert mit den vorgeschlagenen Auswirkungen eines RCE und der Build-Voraussetzung und ermittle anschließend, ob der Advisory-Eintrag nach der Klärung des Schweregradstreits überarbeitet werden sollte.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Field Current Proposed
Description "read files disallowed by a security policy using a symlink" "Incorrect parsing of :: in filenames silently bypasses nameless path-deny policies. On --enable-pipes builds this enables unauthenticated remote code execution via the |cmd filename handler in OpenBlob. On all builds, it enables reading paths denied by policy."
CVSS 4.0 - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N = ~9.2 Critical (AT:P explicitly models the --enable-pipes precondition)
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.

Vorherrschende Sprache
Keine Sprachdaten
Sterne
2.5k
Forks
803
Ø Merge
7 T. 6 Std.
Gemergte PRs (30 T.)
64

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/advisory-database

Alle Issues in github/advisory-database

Ähnliche Issues

Weitere Issues zu Security

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.