CVE-2026-61534 to podatność, przy której sam numer CVSS może prowadzić zespół w złą stronę. GitHub klasyfikuje problem jako krytyczny dla biblioteki yayson, a mechanizm jest konkretny: kontrolowane przez atakującego pola JSON:API — w szczególności type, id i nazwy relacji — trafiają do struktur używanych jak zwykłe obiekty JavaScript. Specjalne klucze jak __proto__ mogą zmienić prototyp bazowego obiektu zamiast zostać potraktowane jak zwykły klucz. To jednak nie automatycznie „RCE w każdej aplikacji używającej yayson” — i tu zaczyna się praca VE.
__proto__ → Object.prototype pollution → process-wide side effects.Co jest faktem, a co zależy od aplikacji
Najpewniejszy skutek to globalne zanieczyszczenie stanu procesu: właściwość wstrzyknięta do Object.prototype staje się widoczna dla wielu obiektów — błędy logiki, crash, DoS, nieoczekiwane zachowanie kodu sprawdzającego property przez dziedziczenie. Czy powstanie z tego bypass autoryzacji albo RCE? Nie zakładaj tego z samego CVE — potrzebny downstream gadget: fragment aplikacji/zależności konsumujący odziedziczoną właściwość w sposób bezpieczeństwowo istotny. Attack path: untrusted JSON:API document → attacker-controlled type/id/relationship → yayson Store/LegacyStore → plain-object key assignment → __proto__ → Object.prototype pollution → process-wide side effects → (opcjonalnie) application-specific gadget → auth bypass / sensitive action / code execution. Ostatnia strzałka nie jest gwarantowana — CVSS 9.1 opisuje potencjał primitive, nie dowodzi obecności gadgetu w Twoim produkcie.
Co sprawdzić i jak naprawić
Pierwsze pytanie to nie „czy mamy yayson?”, lecz „gdzie i jak jest używany?”. Ustal: czy podatna wersja jest w runtime (nie tylko dev dependency), czy aplikacja używa Store/LegacyStore w ścieżce z niezaufanymi danymi, czy dokument JSON:API pochodzi od klienta/partnera/kolejki/upstreamu, czy są filtry specjalnych kluczy, czy proces startuje z --disable-proto=throw, czy downstream używa wzorców podatnych na prototype gadgets (merge konfiguracji, dynamiczne opcje, sprawdzanie flag przez property lookup). Remediation: upgrade do 4.3.0 (mapy odporne na specjalne klucze). Workaround (jeśli upgrade czeka): odrzucanie __proto__/constructor/prototype na granicy wejścia, --disable-proto=throw, ograniczenie ekspozycji endpointów — ale nie zamykaj bez testu, bo prototype pollution ma wiele wariantów.
Weryfikacja i osie oceny
Nie wystarczy numer w package-lock.json: runtime inventory (jaka wersja w artefakcie/kontenerze), test negatywny z dokumentem wykorzystującym specjalny klucz, sprawdzenie że po parsowaniu Object.prototype nie ma wstrzykniętej testowej właściwości, test ścieżek Store i LegacyStore, ponowna analiza transitive dependencies jeśli yayson jest bundlowany. Dla aplikacji o wysokiej wartości po patchu — variant analysis dla innych miejsc, gdzie dane JSON:API trafiają do plain-object maps. Severity wysoka/krytyczna; exploitability zależna od reachability (zaufane statyczne dane → niższe ryzyko; za publicznym API → rośnie); active exploitation — brak wiarygodnego potwierdzenia; asset context (internet-facing Node.js API, backend z operacjami uprzywilejowanymi) podnosi priorytet.
Powiązane na blogu
- Excelize: DoS z małego pliku — primitive vs realny impact
- libheif: variant analysis — jedna instancja szerszej klasy błędów
Źródła
- GHSA-325j-mg25-8q58 — github.com
- CVE-2026-61534 — cve.org
Nota redakcyjna: stan informacji 12 września 2026. CVE-2026-61534 (yayson <4.3.0, CVSS 9.1): prototype pollution przez pola JSON:API. Najpewniejszy skutek to DoS/logic corruption; eskalacja wymaga downstream gadgetu. Brak potwierdzenia active exploitation. Artykuł rozdziela primitive, reachability i impact gadget.