CVE-2026-54329 - Snipe-IT cross-tenant accessory injection

When Full Multiple Companies Support (FMCS) is enabled, Snipe-IT through 8.6.1 lets a low-privilege authenticated API caller create accessory records inside another tenant by submitting a foreign company_id. The API path mass- assigns request data directly to the Accessory model, and that model allows company_id assignment. The web controller enforces current-user company context, but the API create path did not.

This is a tenant-boundary integrity failure. A Company A user can inject persistent inventory objects that appear legitimate to Company B.

When to use it

  • A repository deploys, packages, forks, or configures Snipe-IT <=8.6.1.
  • Full Multiple Companies Support is enabled or may be enabled by deployment configuration.
  • API callers can create accessory or adjacent inventory records with request-provided tenant keys such as company_id.
  • You need a bounded PR or triage note that upgrades Snipe-IT and proves tenant context is derived server-side.

Inputs

  • Composer files, package/image manifests, deployment manifests, SBOMs, generated reports, plugins, forks, and FMCS configuration.
  • Accessory API create code, adjacent inventory create flows, model fillable fields, API token scopes, tenant/company context, and audit logs.
  • Available tests, build, image build, deployment render, SBOM, and dependency scan commands.

Affected versions

Package Vulnerable versions Fixed versions
snipe/snipe-it <=8.6.1 8.6.2

Indicator-of-exposure

  • The repository deploys Snipe-IT with FMCS enabled.
  • API routes for accessory creation are reachable by low-privilege authenticated users or API tokens.
  • Tenant scoping relies on request-provided company_id anywhere in API create flows.
  • Accessory or adjacent inventory models allow mass assignment of tenant keys.

Quick checks:

rg -n "company_id|Accessory|fillable|mass assign|FMCS|multiple companies|api.*accessor|api.*accessories" .
composer show snipe/snipe-it

Windows:

rg -n "company_id|Accessory|fillable|mass assign|FMCS|multiple companies|api.*accessor|api.*accessories" .
composer show snipe/snipe-it

Remediation strategy

  • Upgrade Snipe-IT to 8.6.2+.
  • Enforce tenant ownership server-side in API create paths by deriving the company context from the authenticated principal instead of trusting request body input.
  • Remove tenant identifiers such as company_id from mass-assignable fields when callers should not control them.
  • Add regression tests for foreign-tenant create attempts on accessory and similar inventory endpoints.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-54329 / GHSA-pwpj-p52h-q484 in Snipe-IT. The API
accessory creation flow accepts a foreign `company_id` and lets one tenant
inject inventory into another when FMCS is enabled. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Snipe-IT, enforces tenant
  ownership server-side, adds regression tests, and documents cleanup, or
- TRIAGE.md if this repository does not control an affected Snipe-IT runtime.

## Rules

- Scope only CVE-2026-54329 and directly related tenant-boundary enforcement in
  API create flows.
- Do not create test records in real tenant inventories.
- Treat tenant IDs, inventory records, API tokens, and audit logs as sensitive.
- Do not rely on UI-only checks while leaving API mass assignment exposed.
- Do not auto-merge.

## Steps

1. Inventory every Snipe-IT package, image, manifest, and deployment controlled
   by this repository.
2. Confirm whether any deployment runs `<=8.6.1` and whether FMCS is enabled.
3. Trace the accessory API create path and identify where `company_id` or
   similar tenant keys can be mass-assigned from request bodies.
4. Search for sibling create flows with the same pattern.
5. If the repository does not control the affected runtime, stop with
   `TRIAGE.md` naming the owning team, vulnerable version, and required fixed
   version `8.6.2+`.
6. Upgrade to `8.6.2+` and refresh lockfiles, images, manifests, SBOMs, and
   deployment documentation.
7. Enforce company context from the authenticated user or token on API create
   paths; ignore or reject foreign tenant identifiers from untrusted input.
8. Remove or narrow mass-assignable tenant-key fields where callers should not
   control them.
9. Add regression tests proving a Company A caller cannot create or influence
   Company B accessory records.
10. Add a PR body section named `CVE-2026-54329 operator actions` covering:
    - versions before and after;
    - whether FMCS is enabled;
    - affected API routes reviewed;
    - whether cross-tenant records need cleanup;
    - validation that passed.
11. Run available validation: tests, build, image build, deployment render, and
    dependency/security scans.
12. Use PR title:
    `fix(sec): enforce tenant ownership in Snipe-IT accessory API`.

## Stop conditions

- No affected Snipe-IT runtime is controlled by this repository.
- FMCS is disabled everywhere and the repository cannot change the deployed
  runtime.
- Historical cross-tenant data cleanup requires customer-specific business
  review; document it in `TRIAGE.md`.
- Validation fails for unrelated pre-existing reasons; record them and stop.

Verification - what the reviewer looks for

  • No controlled Snipe-IT deployment resolves <=8.6.1.
  • API accessory creation ignores or rejects foreign company_id input.
  • Regression tests cover foreign-tenant injection attempts.
  • Operator notes address whether historical injected accessory records must be reviewed or removed.

Output contract

  • Reviewer-ready PR upgrading Snipe-IT to 8.6.2+ and refreshing lockfiles, images, manifests, SBOMs, and docs.
  • Server-side tenant ownership enforcement for accessory and sibling create flows, with tenant-key mass assignment removed or narrowed.
  • Regression tests proving foreign tenant IDs are rejected for low-privilege callers.
  • TRIAGE.md when runtime ownership, FMCS state, or historical cleanup sits outside this repository.

Watch for

  • Fixing accessories only while leaving the same tenant-key mass-assignment pattern in adjacent inventory models.
  • UI routes using safe company derivation while API routes still trust request bodies.
  • Bulk import or automation tokens that bypass the interactive company context.

References