CVE-2026-48089
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 14 — wyżej niż 14% wszystkich znanych CVE
Streszczenie
DevGuard przed wersją 1.4.2 pozwala na nieautoryzowane modyfikacje reguł VEX przez uwierzytelnionych użytkowników, w tym tych z innych organizacji, na publicznych zasobach. Użytkownicy mogą tworzyć, aktualizować, ponownie stosować i usuwać reguły VEX oraz inne powiązane zdarzenia związane z podatnościami.
Ocena ryzyka
Organizacje mogą być narażone na nieautoryzowane zmiany w zarządzaniu podatnościami, co może prowadzić do błędnych decyzji dotyczących bezpieczeństwa i potencjalnych naruszeń danych.
Rekomendacja
Zaleca się aktualizację do wersji 1.4.2, która zawiera poprawkę. Alternatywnie, należy zmienić widoczność dotkniętych zasobów z publicznych na prywatne, aby przywrócić odpowiednią autoryzację.
Oryginalny opis (angielski, źródło NVD)
DevGuard provides vulnerability management for the full software supply chain. Prior to 1.4.2, on a DevGuard API instance with one or more public assets, any authenticated user — including users from a different organization with no membership or role in the affected org/project — can create, update, reapply, and delete VEX rules on those public assets. The same flaw affects the other vulnerability-triage write endpoints exposed under a public asset, including VEX rule create / update / reapply / delete; dependency-vuln event creation (accept / reject / mitigate decisions), batch event creation, vuln sync, and mitigation; license risk creation; external reference writes; and/or artifact creation and license refresh. The attacker needs a valid account on the instance, but no membership in the victim organization, project, or asset is required. Version `v1.4.2`contains a patch. As a workaround, make affected assets non-public. In the asset settings, switch visibility from public to private. This removes the public-read exemption in the access-control middleware and restores correct authorization on all write endpoints for that asset. Downstream consumers that previously relied on the public `vex.json` / `sbom.json` endpoints will need to be granted explicit access or must receive an exported file version until the patched release is deployed.

