Composer opublikował 27 sierpnia 2026 advisory o arbitrary command execution przez złośliwy Perforce source URL. Composer przekazywał adres źródła bez właściwej walidacji do klienta p4, który akceptuje również rsh: i jsh: prowadzące do lokalnego wykonania poleceń.
p4 akceptuje rsh:/jsh: → local command execution.p4 w PATH, kontrola metadata source Perforce, niestandardowe repo lub niezaufany composer.lock, instalacja ze źródeł.Użytkownicy Packagist.org bez p4 nie mają tego attack path.
Dlaczego to ważne?
To exploitability zależna od narzędzia spoza dependency graph. SBOM Composera nie wystarcza — trzeba znać external binary, repo trust i tryb instalacji:
Usunięcie p4 z PATH jest łatwo weryfikowalnym compensating control, choć nie naprawia samego Composera.
Wniosek
CVE-2026-84361 pokazuje, że podatna biblioteka może być tylko jednym elementem układanki. Actionable finding powstaje dopiero po przecięciu wersji, external binary, metadata source i execution mode.
Powiązane na blogu
- Composer w CI: cache jako warunek exploitability — ten sam ekosystem, warunkowy attack path
- rust-iot: dwa CVE, jeden łańcuch — realny finding to złożenie warunków
Źródła
- Composer — GHSA-rvx4-ffvw-m9q3 (27.08.2026) — github.com/composer
- Red Hat — CVE-2026-84361 — access.redhat.com
Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-84361 (Composer, High 7.7): złośliwy Perforce source URL → local command execution przez klienta p4; wymaga p4 w PATH, kontroli metadata source, niestandardowego repo i source install. Artykuł koncentruje się na warunkowej exploitability zależnej od narzędzia spoza dependency graph.