CVE-2026-48089: CWE-285: Improper Authorization in l3montree-dev devguard
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.
AI Analysis
Technical Summary
DevGuard versions prior to 1.4.2 allow any authenticated user, regardless of organizational membership or role, to perform unauthorized write operations on public assets. This includes creating, updating, reapplying, and deleting VEX rules and other vulnerability triage data such as dependency vulnerability events, license risks, external references, and artifacts. The flaw arises from a public-read exemption in the access-control middleware that fails to enforce proper authorization on write endpoints for public assets. Version 1.4.2 contains a patch that corrects the authorization checks. Until patched, making assets private removes the public-read exemption and enforces correct authorization.
Potential Impact
Unauthorized users with valid accounts can modify critical vulnerability management data on public assets they do not belong to. This can lead to unauthorized changes in vulnerability triage, license risk data, and artifact information, potentially undermining the integrity and reliability of the vulnerability management process. The vulnerability affects the confidentiality and integrity of vulnerability data associated with public assets.
Mitigation Recommendations
A patch is available in DevGuard version 1.4.2 that fixes the improper authorization issue. Users should upgrade to version 1.4.2 or later to remediate this vulnerability. As a temporary workaround, affected assets can be set to private in the asset settings to remove the public-read exemption and restore proper authorization enforcement on write endpoints. Downstream consumers relying on public endpoints will need explicit access or must use exported file versions until the patch is applied.
CVE-2026-48089: CWE-285: Improper Authorization in l3montree-dev devguard
Description
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.
CVSS v4.0
Score 7.1high
Affected software
pkg:github/l3montree-dev/devguardRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
DevGuard versions prior to 1.4.2 allow any authenticated user, regardless of organizational membership or role, to perform unauthorized write operations on public assets. This includes creating, updating, reapplying, and deleting VEX rules and other vulnerability triage data such as dependency vulnerability events, license risks, external references, and artifacts. The flaw arises from a public-read exemption in the access-control middleware that fails to enforce proper authorization on write endpoints for public assets. Version 1.4.2 contains a patch that corrects the authorization checks. Until patched, making assets private removes the public-read exemption and enforces correct authorization.
Potential Impact
Unauthorized users with valid accounts can modify critical vulnerability management data on public assets they do not belong to. This can lead to unauthorized changes in vulnerability triage, license risk data, and artifact information, potentially undermining the integrity and reliability of the vulnerability management process. The vulnerability affects the confidentiality and integrity of vulnerability data associated with public assets.
Mitigation Recommendations
A patch is available in DevGuard version 1.4.2 that fixes the improper authorization issue. Users should upgrade to version 1.4.2 or later to remediate this vulnerability. As a temporary workaround, affected assets can be set to private in the asset settings to remove the public-read exemption and restore proper authorization enforcement on write endpoints. Downstream consumers relying on public endpoints will need explicit access or must use exported file versions until the patch is applied.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-05-20T18:40:45.833Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a359d6df198dc38c122038f
Added to database: 6/19/2026, 7:50:05 PM
Last enriched: 6/19/2026, 8:05:31 PM
Last updated: 6/20/2026, 12:06:48 AM
Views: 7
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.