Najbardziej niebezpieczny finding nie zawsze ma CVE 10.0 — czasem nie ma CVE w ogóle. 5 września 2026 Sansec opisał podatność StyleSmuggler (ataki od 4 września): unauthenticated RCE w Magento Open Source i Adobe Commerce prowadzące do trwałego backdoora. Kluczowe dla VE: pierwszy potwierdzony victim działał na Magento 2.4.6-p15 z lipcowymi i sierpniowymi aktualizacjami — security:patch-status nie wskazywał braków. Sansec odtworzył chain także na czystych 2.4.7, 2.4.8 i 2.4.9.
Użytkownik nie musi otwierać wiadomości — kod wykonuje się przy renderowaniu po stronie serwera; brak dostarczenia e-maila nie oznacza, że chain nie zadziałał.
Dlaczego patch compliance zawodzi
Typowy proces: package inventory → compare to bulletin → missing patches = 0 → compliant. Tu prowadzi to do fałszywego poczucia bezpieczeństwa: pierwszy victim był na aktualnym patch level, a vendor patcha, który scanner mógłby oznaczyć jako brakujący, jeszcze nie ma. Poprawne pytanie nie brzmi „czy system ma wszystkie poprawki?”, lecz „czy istnieje publiczna, wiarygodna wiedza o exploitable attack path, dla którego vendor nie wydał jeszcze poprawki?”.
Finding bez CVE i source Sansec
Nie warto czekać na numer — stwórz lokalny record (id: VMRT-STYLESMUGGLER-2026, type: emergent_zero_day, active_exploitation: confirmed_by_researcher, patch_available: false, source: Sansec, confidence: high); gdy pojawi się CVE, zmapuj je do istniejącego findingu (nie twórz duplikatu). Sansec to nie Adobe PSIRT, ale obserwował realne kompromisy, podał timestamp kampanii, odtworzył chain na czystych instalacjach i opublikował indicators — taki poziom evidence wystarcza do emergency response. Rozdziel: Magento Open Source affectedness: high confidence od Adobe Commerce: researcher-reported, vendor confirmation pending. Brak KEV nie ma znaczenia dla decyzji o incydencie — KEV jest wtórny wobec rzeczywistości.
Co robić bez patcha
To moment, w którym VE jest ważniejszy niż patch management. Sansec wskazuje m.in. ograniczenie/wyłączenie GraphQL dla sklepów bez reguł ochronnych. Oceniaj controls jako konkretne security properties: virtual patch/WAF (rule covers stage 1? stage 2? deployed na każdy hostname? bypass tested?), wyłączenie attack surface (GraphQL, jeśli jest warunkiem obserwowanego path), monitoring (nietypowe failed-payment events, nowe pliki PHP, procesy udające systemowe, cron persistence, outbound).
Patch nie usuwa istniejącej kompromitacji
Dla aktywnie wykorzystywanego RCE: patching = prevention of future exploitation, ale patching ≠ removal of existing compromise. Sklep wystawiony między początkiem exploitation a skutecznym controlem powinien przejść compromise assessment (procesy, persistence, porównanie filesystem z known-good, crontab/systemd, webroot/writable, logi, outbound, rotacja credentials, rozważyć rebuild). Sansec wskazuje procesy udające [kworker/u:8:0] i fc-cache oraz C2 — to hunting pivots, nie dowód czystości przy ich braku.
Największe ryzyko: false clean
Status missing security patches: 0 / CVE findings: 0 / KEV findings: 0 przy realnym stanie internet-exposed / actively exploitable / possibly compromised. To jedna z najgroźniejszych klas false negative — wynika nie z błędu skanera, lecz z ograniczenia modelu danych. Discovery musi obejmować CVE/NVD + vendor + researcher advisories + CERT + active-exploitation intelligence i umieć tworzyć finding bez CVE.
Wniosek
StyleSmuggler to moment, w którym VM przestaje być systemem do śledzenia CVE, a staje się systemem zarządzania realnym stanem podatności. CVE, CVSS, KEV i patch są metadanymi. Exploitacja jest rzeczywistością.
Powiązane na blogu
- PaperCut: aktywne ataki bez CVE i patcha — CVE nie jest kluczem VM
- MikroTrick: aktywna eksploatacja — patch ≠ compromise assessment
Źródła
- Sansec — „StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack” (05.09.2026) — sansec.io
- Sansec — Threat Research — sansec.io
Nota redakcyjna: stan informacji 8 września 2026. StyleSmuggler (Sansec): active exploitation Magento Open Source / Adobe Commerce bez publicznego CVE, wpisu KEV i potwierdzonego vendor patcha; pierwszy victim był na aktualnym patch level. Artykuł koncentruje się na tym, że „no CVE” ≠ „no vulnerability”, i na ryzyku false clean.