What is the CVSS score of CVE-2026-55472?

CVE-2026-55472 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2026-55472?

Yes, a patch is available for CVE-2026-55472. Update the affected software to the latest version immediately.

Snipe-IT CVE-2026-55472

EUVD-2026-42990 MEDIUM

Incorrect Authorization (CWE-863)

2026-07-10 GitHub_M

GHSA-8w8c-8mx9-52cw

Authentication Bypass Snipe It Grokability

4.3

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

vuln.today AI

5.4 MEDIUM

PR:L confirmed by authentication requirement; I:L added over NVD score because attacker inserts records into another company's location hierarchy, constituting an integrity violation.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jul 10, 2026 - 20:02 EUVD

Analysis Generated

Jul 10, 2026 - 19:30 vuln.today

DescriptionCVE.org

Snipe-IT is an IT asset/license management system. Prior to 8.6.2, when Full Multiple Companies Support and scope_locations_fmcs are enabled, the API location creation endpoint detects an invalid parent-child company mismatch but does not return immediately, allowing creation of a child location under a parent location from a different company. This issue is fixed in version 8.6.2.

AnalysisAI

Incorrect authorization enforcement in Snipe-IT's API location creation endpoint allows an authenticated low-privilege user to create a child location under a parent location belonging to a different company, bypassing the intended multi-tenant isolation boundary. The vulnerability affects all Snipe-IT versions prior to 8.6.2 when both Full Multiple Companies Support and the scope_locations_fmcs option are simultaneously enabled. No public exploit code exists and this vulnerability is not listed in the CISA KEV catalog; real-world risk is constrained by the non-default configuration prerequisites and the requirement for authenticated access.

Technical ContextAI

Snipe-IT (CPE: cpe:2.3:a:grokability:snipe-it:*:*:*:*:*:*:*:*) is a PHP-based open-source IT asset and license management system developed by Grokability. The flaw resides in the API endpoint responsible for creating location records under the Full Multiple Companies Support (FMCS) feature, which is designed to enforce tenant isolation between discrete company entities within a single Snipe-IT instance. CWE-863 (Incorrect Authorization) describes the root cause precisely: the endpoint's validation logic detects that a requested parent-child location relationship spans two different companies, but fails to halt execution after this detection. The absence of an early return allows the record creation to proceed despite the identified mismatch. The scope_locations_fmcs setting is a secondary configuration flag that specifically governs whether location scoping is enforced per company under FMCS; both flags must be active for the vulnerable code path to be reachable.

RemediationAI

The primary fix is to upgrade Snipe-IT to version 8.6.2 or later, which is available at https://github.com/grokability/snipe-it/releases/tag/v8.6.2. The underlying code change is documented in commit 9a8cbd6e00613a726b639a97a1da71b3c54f9489 at https://github.com/grokability/snipe-it/commit/9a8cbd6e00613a726b639a97a1da71b3c54f9489. For deployments where immediate patching is not feasible, disabling either the Full Multiple Companies Support feature or the scope_locations_fmcs configuration flag eliminates the vulnerable code path entirely; note that disabling FMCS will remove company-based tenant isolation across the instance, which may be operationally unacceptable for shared environments. Restricting API access to the location creation endpoint to trusted network segments or enforcing additional role-based access controls on the API can reduce exposure as a secondary compensating control, though neither prevents exploitation by authenticated users who legitimately have API access.