DevGuard CVE-2026-48089
HIGH
GHSA-6p54-fw2f-q7gf
Severity by source
Network-reachable API, any low-privileged authenticated account suffices (PR:L), no UI; scope changes since the integrity impact lands on downstream consumers of public VEX/SBOM, confidentiality and availability unaffected.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
2DescriptionCVE.org
Impact
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
- 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.
Security impact is primarily to integrity of the vulnerability picture of public assets: an attacker can mark CVEs as false-positive, silence vulnerabilities, attach misleading justifications, or delete legitimate triage rules - undermining the trustworthiness of every consumer of the affected asset's VEX/SBOM output. Because public assets are by definition consumed by third parties (downstream users, supply-chain consumers, the published vex.json/sbom.json), the blast radius extends to anyone relying on that data.
Private assets are not affected by this advisory: the public-read exemption that enables the bypass does not apply to them, and access remains correctly gated by organization/project membership. The private setting is only relevant in DevGuard itself - there is no impact given when you have an open-source project on e.g. GitLab/GitHub and a private DevGuard asset connected.
Patches
Version v1.4.2contains a patch. Users should upgrade to the patched release as soon as it is available.
Workarounds
If developers cannot upgrade their applications immediately:
- They should 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.jsonendpoints will need to be granted explicit access or must receive an exported file version until the patched release is deployed.
Resources
Fixed commit: https://github.com/l3montree-dev/devguard/commit/1be88ec1309a5dc0566e35a23bdc4ea3ecd11417
Credit
DeevGuard thanks @philipflohr (awesome-it.de) for finding and responsibly reporting this vulnerability!
Articles & Coverage 1
AnalysisAI
Broken authorization in DevGuard (l3montree-dev/devguard) versions prior to v1.4.2 allows any authenticated user on the instance - including users with no membership in the victim organization, project, or asset - to perform vulnerability-triage write operations against public assets, undermining the integrity of published VEX and SBOM data. The flaw stems from a public-read exemption in the access-control middleware that incorrectly extended to write endpoints. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires (1) a valid authenticated user account on the target DevGuard instance running a version below 1.4.2 - open registration or any tenant on a shared/community instance is sufficient, no membership in the victim's organization, project, or asset is needed; (2) the target organization must own at least one asset whose visibility is configured to public in DevGuard asset settings (the public-read exemption is the bypass condition); and (3) the attacker must reach the API over the network. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | No CVSS vector or EPSS score was published in the input, so prioritization must rely on the advisory narrative and code diff. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker registers a normal user account on a target DevGuard instance that hosts public assets, then issues authenticated API calls against the public asset's VEX/dependency-vuln/artifact write endpoints to mark exploitable CVEs as false-positive or delete legitimate triage rules. Downstream supply-chain consumers fetching the published vex.json then ignore the silenced vulnerabilities, leaving them exposed; no published proof-of-concept is required because the patch diff itself documents the exact unprotected routes. |
| Remediation | Vendor-released patch: v1.4.2 - upgrade the DevGuard server to v1.4.2 or later as described in the GHSA advisory at https://github.com/l3montree-dev/devguard/security/advisories/GHSA-6p54-fw2f-q7gf, which adds the DisallowPublicRequests middleware and asset-scoped RBAC on triage write routes per commit 1be88ec1309a5dc0566e35a23bdc4ea3ecd11417. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Verify if DevGuard is deployed and note the current version. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
More from same product – last 7 days
Stored cross-site scripting and account integrity abuse in GitLab Enterprise Edition versions 13.1.4 through 18.10.7, 18
Stored cross-site scripting in GitLab Enterprise Edition's Analytics Dashboard allows an authenticated developer-role us
Account takeover in GitLab Enterprise Edition versions 15.5 through 19.0.2 allows an authenticated group Owner to hijack
Denial of service in GitLab CE/EE versions 12.10 through 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 allows un
Uncontrolled resource consumption in GitLab CE/EE's file upload processing pipeline enables any authenticated user to tr
Share
External POC / Exploit Code
Leaving vuln.today