Symfony Process CVE-2026-24739: Wenn ein Gleichheitszeichen unter Git Bash das Laufwerk leert — was DACH-Teams in der Composer-Pipeline prüfen sollten

TL;DR — 90 Sekunden

Eine Lücke in symfony/process lässt unter MSYS2/Git Bash auf Windows Argumente mit = durch die Konversionsschicht umrouten. Der Bug ist nicht spektakulär — er sitzt aber im Standard-PHP-Stack der Sylius- und TYPO3-Welt, und seine Worst-Case-Wirkung ist Datei-Löschung auf einem unbeabsichtigten Pfad. Der Fix ist ein einfacher Composer-Update, die strukturelle Lehre ist eine andere.

Was ist das Problem?

Symfony Process ist die Standard-Komponente im PHP-Universum für das Starten und Verwalten externer Prozesse. Composer nutzt sie in seinen Scripts, Sylius in seinen Build- und Deploy-Hooks, TYPO3 in seinen Console-Commands, Drupal in seinen Maintenance-Routinen, und jede produktive Symfony-Anwendung in einer dichten Schicht von Aufrufen quer durch den Stack. Sie liefert die Argument-Escape-Schicht zwischen PHP und der jeweiligen Host-Shell — auf Unix mit POSIX-Escape, auf Windows mit der CMD-Escape-Logik.

Genau in der Windows-Escape-Logik sitzt die Lücke. Symfony Process behandelt eine Reihe von Zeichen als „special" und quotet die entsprechenden Argumente. Das Zeichen = stand bisher nicht auf dieser Liste — auf nativer cmd.exe ist das auch unkritisch, weil CMD = nicht als Argument-Trenner kennt. Anders ist es unter MSYS2 und Git Bash: deren mintty- und bash-Konversionsschicht interpretiert ein = in einem unquoted Argument als Variablen-Zuweisung oder Pfad-Separator-Hinweis und kann das gesamte Argument umrouten.

Die Analyse von Symfony selbst zeigt das Beispiel präzise: wenn ein Composer-Script über symfony/process ein rmdir mit dem Pfad C:\projects\build=temp\artifacts aufruft, kann die MSYS2-Konversionsschicht dieses Argument so umformen, dass das tatsächlich gelöschte Verzeichnis ein anderes ist — bis hin zur Löschung des Inhalts eines übergeordneten Verzeichnisses oder des gesamten Laufwerks, je nach Argument-Layout des aufrufenden Scripts.

Der Bug ist klein und tief. Klein, weil die Reparatur eine Erweiterung der „special characters"-Liste um = und ein paar verwandte Zeichen ist — der Patch in symfony/symfony#63164 ist wenige Zeilen Code. Tief, weil er an einer Schicht sitzt, die die meisten PHP-Entwicklerinnen und -Entwickler als gelöst behandeln: Argument-Escape ist seit Jahren stabile Standard-Infrastruktur, und niemand prüft mehr aktiv, ob ein Composer-Script-Aufruf mit einem = im Pfad unter Git Bash dasselbe Verhalten zeigt wie unter cmd.exe. Snyk hat den Bug als Arbitrary Argument Injection klassifiziert — die Klasse stimmt, die operative Wirkung sitzt aber nicht im Argument allein, sondern im Zusammenspiel mit der MSYS2-Konversionsschicht.

Strukturell gehört CVE-2026-24739 in eine Klasse, die wir in den vergangenen Wochen mehrfach gesehen haben: stabile Stack-Bibliotheken, die an einer einzelnen Stelle eine Konsistenz-Annahme verletzen, die in der Standard-Umgebung hält und in einer Nebenumgebung bricht. Bei NGINX Rift (CVE-2026-42945, 13.05.) war es eine 18 Jahre alte Annahme über das Rewrite-Module-Verhalten. Bei node-ipc (16.05.) war es eine Annahme über die Stabilität einer Maintainer-Identität über Jahre. Bei Symfony Process ist es eine Annahme über die Universalität der CMD-Escape-Logik.

Wer ist betroffen?

Eine kompakte Übersicht über betroffene und nicht betroffene Konstellationen.

Wir betreiben in unseren Mandanten-Plattformen — TYPO3 und Sylius im DACH-Mittelstand-Korridor — den PHP-Stack durchgängig in Linux-Containern (Wolfi-OS-Basis seit Februar 2026 als Standard). Direkte produktive Betroffenheit ist bei uns damit niedrig. Die operative Linie sitzt aber an einer anderen Stelle: einzelne Mandanten haben eigene Windows-Build-Hosts für historische Pipeline-Reste, und unsere Architekturreviews stoßen regelmäßig auf Composer-Scripts, die dynamisch Pfade zusammensetzen — das ist der eigentliche Angriffsraum.

Auswirkungen

Die spektakuläre Lesart des Bugs — „Symfony Process löscht das falsche Verzeichnis" — ist korrekt, aber sie überzeichnet die typische Wirkung. Die häufigere Wirkung ist subtiler: ein Build-Pipeline-Schritt löscht ein Artefakt nicht, das er hätte löschen sollen, sodass eine spätere Build-Stage auf einen veralteten Stand zugreift. Oder umgekehrt: ein Cleanup-Script entfernt ein Verzeichnis, das benachbart zur eigentlichen Ziel-Stelle liegt, sodass nach dem Build-Lauf ein produktives Artefakt verschwunden ist. Beides ist keine Datenschutz-Lage und keine RCE, aber beides erzeugt Pipeline-Halluzinationen, die im Operations-Alltag schwer zu rekonstruieren sind.

Die Worst-Case-Variante — Löschung eines produktiven Verzeichnisses oder eines Inhalts-Volumes — setzt voraus, dass das aufrufende Script den Argument-Pfad dynamisch aus Konfigurations-Werten konstruiert und dass der Pfad ein = enthält. Im DACH-Mittelstand-Plattform-Kontext ist das selten, aber nicht ausgeschlossen: Build-Tools, die Tenant-Identifier oder Konfigurations-Keys in Pfade einsetzen, generieren regelmäßig Pfade mit = (vor allem in Base64-encoded Identifier-Schemata), und ein Cleanup-Script kann diese Pfade an symfony/process weitergeben.

Strukturell sitzt CVE-2026-24739 in der laufenden Reihe der Argument-Konsistenz-Befunde im PHP-Stack. Drei Datenpunkte verdichten diese Linie: Composer GHSA-f9f8-rm49-7jv2 vom 12.05.2026 (Token-Leak in Fehlermeldungen, weil Symfony Console ANSI-Sequenzen einfügt, die die Masking-Logik umgehen), node-ipc vom 14.05.2026 (Maintainer-E-Mail-Domain-Hijack über eine abgelaufene Domain) und die Sylius-Befünde im März (CVE-2026-31821 bis -31825, im 2.0.16/2.1.12/2.2.3-Stand stabilisiert). Die Lehre ist keine Symfony- oder Sylius-Schwäche, sondern dass die Test-Matrizen der Standard-Frameworks die Nebenumgebungen nicht systematisch abdecken — und dass Mandanten-Plattformen die Differenz tragen.

Mitigation / Sofortmaßnahmen

Der Patch ist trivial, die Operation drumherum nicht. Drei Pfade, in aufsteigender Tiefe.

Pfad 1: Composer-Lock auf Fix-Version

# In jedem PHP-Projekt mit symfony/process im Composer-Lock:
composer why symfony/process
composer require symfony/process:^7.4.5 --update-with-dependencies
# Oder analog für den jeweiligen Major-Korridor:
# 5.4.x → 5.4.51
# 6.4.x → 6.4.33
# 7.3.x → 7.3.11
# 7.4.x → 7.4.5
# 8.0.x → 8.0.5

Das composer why-Vorab ist nicht kosmetisch: Symfony Process kommt in über 80 Prozent der produktiven PHP-Projekte als transitive Abhängigkeit hinein — über symfony/console, symfony/messenger, composer/composer selbst, phpunit/phpunit, friendsofphp/php-cs-fixer und Dutzende andere. Die direkte Pin reicht nicht, wenn ein transitiver Pfad eine ältere Version festhält. composer why symfony/process zeigt den vollständigen Abhängigkeits-Baum.

Pfad 2: Windows-CI-Runner von Git Bash auf cmd.exe / PowerShell umstellen

Für GitHub Actions:

# Vorher (verwundbar, wenn PHP-Tooling läuft):
- name: Composer install
  shell: bash
  run: composer install

# Nachher:
- name: Composer install
  shell: pwsh  # oder: shell: cmd
  run: composer install

Für selbst gehostete GitLab-Runner auf Windows: Pipeline-Shell-Konfiguration vom Default-sh (das auf Windows-Hosts häufig Git Bash bedeutet) auf powershell umstellen.

# config.toml des GitLab-Runners:
[[runners]]
  name = "windows-build"
  executor = "shell"
  [runners.shell]
    shell = "powershell"

MSYS2 ist eine historische Brücke zwischen Unix-Shell-Erwartungen und Windows-Process-Modellen. Sie ist nützlich für Entwickler-Convenience, sie ist nicht produktionsreif für unbeobachtete Build-Pipelines.

Pfad 3: Audit der Composer-Scripts und Maintenance-Pfade

# In jedem PHP-Projekt:
grep -rn "Process(" --include="*.php" src/ vendor/ scripts/
# Suche nach dynamisch konstruierten Pfaden:
grep -rn "rmdir\|unlink\|del " --include="*.php" src/ scripts/
# Speziell: Pfad-Konstruktionen mit '='
grep -rEn "\\.'='\\." --include="*.php" src/ scripts/

Wer einen Treffer in einem Cleanup-Script oder einem Build-Hook findet, dokumentiert die Stelle und entscheidet: Pfad neu konstruieren (kein =), oder Symfony-Process-Aufruf durch Filesystem::remove() aus symfony/filesystem ersetzen — die Komponente nutzt intern PHP-native File-API, kennt die Konversions-Schichten der Host-Shells nicht und ist deshalb in einer breiteren Konfigurations-Matrix vorhersagbar.

Detection / Prüfung

Drei komplementäre Detection-Pfade — SCA-Tool, Pipeline-Lint, Host-Telemetrie.

Pfad 1: SCA-Tool im Composer-Lock

# Mit composer audit (eingebaut seit Composer 2.4):
composer audit --format=json | jq '.advisories[] | select(.package == "symfony/process")'

# Mit Trivy:
trivy fs --scanners vuln --severity HIGH,CRITICAL --include-dev-deps .

# Mit Snyk:
snyk test --severity-threshold=medium

Der SCA-Pfad meldet die Lücke verlässlich, sobald die GHSA-Datenbank den Eintrag ausgerollt hat (Stand 17.05.2026: verfügbar in GitHub Advisory Database und Snyk-Datenbank).

Pfad 2: Pipeline-Lint auf Git-Bash-Shells in Windows-Jobs

# YAML-Lint für GitHub Actions:
find .github/workflows -name "*.yml" -exec grep -Hn "shell: bash" {} \; | \
  xargs -I {} sh -c 'echo "Treffer: {}"; grep -B2 "shell: bash" {} | grep -E "runs-on.*windows"'

# Für GitLab CI:
grep -rEn "shell.*bash" .gitlab-ci.yml | grep -A2 "windows"

Wer hier Treffer findet, hat einen direkten Mitigations-Auftrag — auch wenn symfony/process schon gepatcht ist, ist die MSYS2-Shell in Windows-CI-Jobs eine generelle Risiko-Klasse und sollte gegen pwsh oder cmd getauscht werden.

Pfad 3: Host-Telemetrie mit Falco / Tetragon / Sysmon

Für Windows-Build-Hosts mit Sysmon, Tetragon oder vergleichbarer eBPF-Schicht:

<!-- Sysmon-Config-Snippet (Windows Event ID 1): -->
<RuleGroup name="Symfony-Process-Auditing" groupRelation="or">
  <ProcessCreate onmatch="include">
    <CommandLine condition="contains all">rmdir;=</CommandLine>
    <CommandLine condition="contains all">del;=</CommandLine>
  </ProcessCreate>
</RuleGroup>

Für Linux-Hosts (wenn PHP-Build-Container im Mandanten-Cluster laufen):

# Falco-Regel:
- rule: PHP_Process_Argument_Equals_Sign_File_Op
  desc: PHP-Prozess startet rm/rmdir mit '=' im Pfad-Argument
  condition: >
    spawned_process and proc.pname startswith "php" and
    (proc.name in ("rm", "rmdir", "unlink")) and
    proc.args contains "="
  output: "PHP-File-Op mit '=' im Pfad (proc=%proc.name args=%proc.args parent=%proc.pname)"
  priority: warning
  tags: [process, symfony, cve-2026-24739]

Tetragon-TracingPolicy als Alternative (für eBPF-native Cluster):

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: symfony-process-cve-2026-24739
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    selectors:
    - matchPIDs:
      - operator: In
        followForks: true
        values:
        - <pid_php_worker>
      matchArgs:
      - index: 1
        operator: "Contains"
        values:
        - "="

Die Telemetrie-Schicht ist optional, aber sie ist die Linie, die in Mandanten-Plattformen die Lücke zwischen „Patch installiert" und „Patch wirklich wirksam" prüfbar macht.

Betreiberempfehlung

Die Lücke ist mit medium-Kritikalität korrekt eingestuft — sie braucht keine Notfall-Eskalation, sie braucht aber eine ruhige, nicht-aufschiebende Reaktion. Vier Wenn/Dann-Bullets als Operational Decision Block:

• Sofort mitigieren, wenn Sie produktive PHP-Pipelines auf Windows-Build-Runnern unter Git Bash betreiben und der Build-Output dynamisch konstruierte Pfade in rmdir/del-Operationen einsetzt.
• Im 14-Tage-Wartungsfenster aktualisieren, wenn Ihre Pipelines auf Linux-Runnern laufen, aber lokale Entwickler-Setups unter Windows + Git Bash + Composer-Scripts produktive Konfigurations-Dateien manipulieren.
• Reine Linux-Plattform, kein direkter Handlungsdruck, aber Composer-Update im Standard-Maintenance-Sweep der nächsten Wochen mitnehmen — der Patch ist trivial, die Schicht ist stabil.
• Lokale Windows-Workstation, kein Server-Bezug, wenn der PHP-Stack nur für lokale Entwicklung läuft und keine produktiven File-Operationen über benutzerdefinierte Pfade ausgelöst werden.

Mittelstand

Composer-Update einplanen, idealerweise im Rahmen des nächsten Composer-Sweeps der laufenden Sprint-Woche. Parallel: Windows-Build-Host-Inventur — gibt es im Mandanten-Bestand noch produktive Windows-Build-Runner, die unter Git Bash laufen? Wenn ja, Shell-Konfiguration auf cmd.exe oder PowerShell ändern, idealerweise begleitet von einem Wechsel auf Linux-Container für den nächsten Pipeline-Refresh.

Enterprise

Zusätzlich: Pipeline-Audit auf Symfony-Process-basierte Datei-Operationen, mit Fokus auf Cleanup- und Deploy-Hooks. Hardening-Regel NO_MSYS2_SHELL_IN_CI in der Build-Standard-Vorlage. SBOM-Inventur der Composer-Lock-Files quer durch das Plattform-Portfolio, mit symfony/process als spezifisches Audit-Item.

Kubernetes und deklarative Stacks

Containerisierte PHP-Builds (Wolfi-OS, Debian-Slim) sind durchgängig nicht betroffen — der Container läuft Linux, MSYS2 spielt keine Rolle. Wer auf Wolfi-Basis baut: die nächste regelmäßige Image-Rebuild-Welle nimmt das symfony/process-Update mit, sobald chainguard/php den Patch pullt (Stand 17.05.2026: Composer-Lock im offiziellen Image noch nicht aktualisiert, Tracking über chainguard-images Issues zu erwarten).

Was wir konkret getan haben

Wir haben am 17. Mai am Morgen drei Schritte parallel angesetzt. Erstens eine Composer-Lock-Inventur über das gesamte Mandanten-Plattform-Portfolio: 23 Plattform-Repositories haben einen direkten oder transitiven symfony/process-Eintrag, davon zwölf in einer der verwundbaren Versionen. Die Aktualisierung läuft als Standard-Pull-Request-Welle, jede mit eigenem CI-Lauf gegen die Plattform-Tests; die ersten Merges sind bis Sonntag-Abend zu erwarten, die restlichen im Lauf der Folgewoche.

Zweitens eine Pipeline-Inventur auf MSYS2-Shells. Wir haben in keinem unserer eigenen CI-Pfade Windows-Runner mit Git Bash, weil unsere Pipeline-Architektur seit Februar 2026 durchgängig auf Linux-Wolfi-Containern über GitLab CI läuft. Bei zwei Mandanten haben wir aber historische Windows-Build-Hosts identifiziert, die für spezifische Legacy-Anwendungen weiter laufen. Die Shell-Konfiguration dieser Hosts haben wir bereits umgestellt — cmd.exe als Default, PowerShell als Eskalations-Variante. Die strukturelle Frage nach Linux-Container-Migration läuft als separater Architektur-Review-Punkt.

Drittens ein Audit der Composer-Scripts in Mandanten-Repositories. Wir haben in composer.json und in den Build-Hook-Scripts nach Process()-Aufrufen mit dynamisch konstruierten File-Pfaden gesucht. Drei Treffer in drei verschiedenen Mandanten-Plattformen — alle drei waren Cleanup-Routinen, die nach einem Build temporäre Artefakte entfernen. Die Pfade enthielten in zwei Fällen Base64-encoded Tenant-Identifier (mit = als Padding-Zeichen). Diese drei Stellen haben wir auf Filesystem::remove() aus symfony/filesystem umgestellt — die Komponente nutzt intern PHP-native File-API statt einen externen rmdir-Prozess zu starten.

Strukturell ergibt sich aus dem Lauf eine Lehre für unsere Plattform-Vorlage: dynamisch konstruierte Pfade in externen Prozessen sind eine eigene Risiko-Klasse, unabhängig vom konkreten CVE. Wir nehmen das als zusätzlichen Lint-Punkt in unsere Build-Hook-Standard-Vorlage auf — wer eine File-Operation auf einem benutzergenerierten Pfad braucht, nutzt die Filesystem-Komponente, nicht einen Process-Aufruf.

Architektur-Beobachtung am Rande: der Bug zeigt einmal mehr, dass die Standard-Test-Matrizen der großen PHP-Frameworks die MSYS2-Nebenumgebung nicht systematisch abdecken. Symfony hat in der Advisory eine ausdrückliche Warnung gegen MSYS2-basierte Shells in produktiven Pipelines ausgesprochen — was de facto eine Erweiterung der Symfony-Support-Definition ist. Wer noch produktive Pipelines unter Git Bash auf Windows-Hosts fährt, betreibt sie ab heute außerhalb der vom Hersteller adressierten Standard-Konfiguration.

Fazit

CVE-2026-24739 ist ein kleiner Bug an einer stabilen Stelle. Die operative Wirkung — Datei-Löschung an unbeabsichtigter Stelle unter einer Konfigurations-Konstellation, die viele Mandanten gar nicht fahren — ist begrenzt. Die strukturelle Wirkung — Bestätigung, dass selbst die Standard-PHP-Stack-Bibliotheken in Nebenumgebungen Konsistenz-Annahmen brechen können — ist die ehrlichere Lesart.

Die Lehre für unsere Mandanten-Plattformen ist nicht „Symfony patchen" (das ist trivial), sondern „dynamisch konstruierte Pfade in externen Prozessen sind eine eigene Risiko-Klasse". Wir haben den Lint in unserer Plattform-Vorlage ergänzt, die drei betroffenen Cleanup-Routinen auf Filesystem::remove() umgestellt und die Composer-Lock-Welle eingeleitet. Die Frage lautet nicht, ob Sie heute oder morgen patchen. Sie lautet, ob Sie wissen, welche Pipelines im Mandanten-Bestand File-Operationen über externe Prozesse mit benutzerdefinierten Pfaden auslösen.