Threat Intelligence Database

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.

CVE-2026-42300 is a critical authentication bypass vulnerability in l3montree-dev's DevGuard software versions prior to 1.2.2. The issue arises because the SessionMiddleware accepts a client-supplied X-Admin-Token HTTP header and uses its raw string value as the authenticated userID when no Kratos session cookie is present. An unauthenticated attacker who can guess or know a target user's Kratos identity UUID can impersonate that user. If the targeted user has organization admin or owner privileges, the attacker gains full control over that organization's DevGuard resources. This vulnerability is fixed in version 1.2.2.