DevGuard has improper authorization on public assets

Summary

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.

Timeline

1. Jun 19, 2026, 7:38 PM UTCCVE published
2. Jun 22, 2026, 5:17 PM UTCCISA SSVC assessment

   Exploitation: none · Automatable: no · Technical impact: partial

3. Jun 22, 2026, 5:17 PM UTCRecord last updated

Affected versions

• l3montree-dev devguard

  fixed in 1.4.2

• github.com/l3montree-dev/devguardGo

  fixed in 1.4.2

References 2