CVE-2026-75599

HomeBox is a home inventory and organization system. Prior to 0.27.0, POST /api/v1/users/register and the users.email uniqueness constraint treat email addresses as case-sensitive while HomeBox uses a case-insensitive login lookup. An unauthenticated attacker who knows a victim's email can register a differently cased variant, creating duplicate rows that cause login to return 401 for both variants and deny the victim access, while also bypassing the one-account-per-email policy.

In HomeBox prior to 0.27.0, the POST /api/v1/users/login endpoint performs password-hash verification only when the submitted username matches an existing account, while unknown usernames return immediately. Although both paths return the same 401 unauthorized response, the processing-time discrepancy allows an unauthenticated remote attacker to distinguish registered email addresses; rate limiting only reduces the number of attempts per window. This issue is fixed in version 0.27.0.

Prior to version 0.27.0, HomeBox validates generic notifier URLs with ValidateNotifierURL, but shoutrrr sends requests through http.DefaultClient.Do without a CheckRedirect policy that revalidates each Location target. An authenticated collection member can configure a permitted notifier host that redirects to loopback, link-local, cloud metadata, or another blocked destination.

HomeBox is a home inventory and organization system. Prior to 0.26.0, the default-on BlockBogonNets and BlockCloudMetadata notifier SSRF protections in backend/internal/sys/validate/notifier_url.go do not inspect IPv4 destinations embedded in the NAT64 prefixes 64:ff9b::/96 and 64:ff9b:1::/48. An authenticated user can submit a generic:// notifier through POST /v1/notifiers or POST /v1/notifiers/test, and on a Homebox instance that egresses through NAT64/DNS64, the gateway can translate an accepted IPv6 destination to cloud metadata, localhost, or another internal IPv4 host. The notifier test path returns delivery result information, and Shoutrrr propagates the response, providing feedback that can disclose retrieved metadata such as temporary credentials. Without NAT64 egress, the crafted IPv6 destination is not routable, but the guard still incorrectly classifies it as safe. This issue is fixed in version 0.26.0.

HomeBox, a home inventory and organization system, prior to 0.26.0 has a vulnerability in NotifierRepository.Update in backend/internal/data/repo/repo_notifier.go. The function updates a notifier through UpdateOneID(id) without requiring the record's user ID to match the authenticated user. An authenticated user who supplies another tenant's notifier UUID to PUT /v1/notifiers/{id} can read the returned stored url, which may contain plaintext Shoutrrr credentials for Slack, SMTP, Telegram, Pushover, or Discord, and can replace the URL to redirect the victim's notifications to an attacker-controlled webhook.

HomeBox, a home inventory and organization system, prior to 0.26.0 has a vulnerability in MaintenanceEntryRepository.Update and MaintenanceEntryRepository.Delete in backend/internal/data/repo/repo_maintenance_entry.go. The functions 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.

HomeBox is a home inventory and organization system. Prior to 0.26.0, POST /v1/groups/members invokes HandleGroupMemberAdd and GroupService.AddMember using a caller-supplied userID without requiring an owner role, an invitation token, target-user consent, or target-user notification. Any authenticated user can force another account into the caller's group, disclose the target user's email address and name through the resulting member list, and create the membership prerequisite used by a separate cross-group inventory-wipe vulnerability. This issue is fixed in version 0.26.0.

HomeBox, a home inventory and organization system, prior to 0.26.0 has a vulnerability in HandleWipeInventory in backend/app/api/handlers/v1/v1_ctrl_actions.go. The function authorizes POST /v1/actions/wipe-inventory through the global ctx.User.IsOwner value instead of the caller's role in the active group, while the active group is selected through the X-Tenant request header. Because every self-registered user who creates a group receives the global owner value, a user who is also a member of another group can select that group with X-Tenant and permanently delete its complete inventory, which is not recoverable without external backups.