CVE-2026-48975 in HomeBoxinfo

Summary

by MITRE • 09/21/2026

HomeBox is a home inventory and organization system. Prior to 0.26.0, MaintenanceEntryRepository.Update and MaintenanceEntryRepository.Delete in backend/internal/data/repo/repo_maintenance_entry.go use UpdateOneID(id) and DeleteOneID(id) without verifying that the maintenance entry belongs to the authenticated user's active group. An authenticated low-privileged user who knows or enumerates another tenant's maintenance-entry UUID can overwrite that record or permanently delete it. This issue is fixed in version 0.26.0.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 09/21/2026

The vulnerability identified in HomeBox versions prior to 0.26.0 represents a critical failure in access control mechanisms, specifically falling under the category of Insecure Direct Object References (IDOR). As a home inventory and organization system designed for multi-tenant environments or distinct user groups, HomeBox relies on strict isolation between different users' data sets. The core technical flaw resides within the backend implementation of maintenance entry management, particularly in the UpdateOneID and DeleteOneID methods found in the repo_maintenance_entry.go file. These functions accept a unique identifier (UUID) for a specific maintenance record and proceed to execute database operations based solely on that identifier without performing any secondary validation checks against the authenticated user's context or group membership.

From an operational perspective, this architectural oversight allows an attacker with low-privileged access to manipulate data belonging to other tenants within the same system instance. By simply knowing or enumerating the UUID of a maintenance entry associated with another user, the malicious actor can invoke these endpoints directly. The application processes the request because the user is authenticated and possesses valid session credentials, but it fails to verify that the target resource belongs to an active group owned by that specific user. Consequently, this leads to unauthorized data modification or destruction. An attacker could overwrite critical maintenance logs with false information, potentially masking security issues or creating confusion regarding asset history, or permanently delete records, resulting in a complete loss of historical data integrity for the victimized tenant.

This vulnerability aligns directly with CWE-639, which describes Authorization Bypass Through User-Controlled Key, and is also indicative of CWE-284, Improper Access Control. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior facilitates techniques related to Data Manipulation or Exfiltration depending on the attacker's intent, specifically leveraging valid credentials to access resources outside their intended scope. The lack of server-side authorization checks means that client-side restrictions are insufficient and easily bypassed by modifying API requests with arbitrary identifiers obtained through enumeration tools or simple guesswork if UUIDs follow predictable patterns.

To mitigate this vulnerability, it is imperative to implement robust object-level authorization checks within the repository layer before executing any database mutations. The application must verify that the maintenance entry identified by the provided ID exists and is explicitly associated with an active group owned by the currently authenticated user. This can be achieved by joining the maintenance entries table with a groups or users-to-groups mapping table during the query execution, ensuring that only records belonging to authorized entities are returned for update or deletion operations. Upgrading to version 0.26.0 resolves this issue as it includes the necessary fixes to enforce these access controls properly. Additionally, developers should adopt a principle of least privilege and ensure that all API endpoints perform explicit authorization checks against resource ownership rather than relying solely on user authentication status.

Responsible

GitHub M

Reservation

05/27/2026

Disclosure

09/21/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to stay up to date on a daily basis?

Enable the mail alert feature now!