Description

HomeBox is a home inventory and organization system. Prior to 0.26.0, NotifierRepository.Update in backend/internal/data/repo/repo_notifier.go 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. This issue is fixed in version 0.26.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-21T18:17:08.557Z",
  "pubdate": "2026-09-21T18:17:08.557Z",
  "executiveSummary": "HomeBox versions prior to 0.26.0 are susceptible to an Insecure Direct Object Reference (IDOR) vulnerability within the notifier management functionality.\nThe vulnerability originates from a failure to perform adequate authorization checks during update operations, specifically in the NotifierRepository.Update function.\nAn authenticated attacker can manipulate the system to modify or exfiltrate sensitive notification configurations belonging to other users or tenants.\nSuccessful exploitation allows an attacker to retrieve plaintext notification credentials (e.g., Slack, SMTP, Telegram, Pushover, or Discord) and hijack notification traffic by replacing stored webhook URLs with attacker-controlled endpoints.\nThe vulnerability requires an authenticated session, but bypasses cross-tenant isolation protections, posing a significant risk to data confidentiality and integrity within multi-user or multi-tenant deployments.\nRemediation requires an immediate upgrade to version 0.26.0 or later to implement strict user-ID ownership validation on repository update operations.",
  "technicalDetails": "The vulnerability exists within the backend/internal/data/repo/repo_notifier.go file, specifically in the NotifierRepository.Update function. The root cause is the usage of UpdateOneID(id) without validating that the authenticated requester possesses the necessary permissions or ownership over the target notifier resource.\nIn the affected versions, the application logic fails to cross-reference the provided notifier UUID with the requester's user ID. Consequently, the backend performs the database update operation based solely on the resource ID supplied in the request.\nThe attack flow proceeds as follows: 1) An authenticated attacker identifies the UUID of a target notifier belonging to another tenant or user. 2) The attacker crafts a PUT request to the /v1/notifiers/{id} endpoint, substituting the {id} with the discovered target UUID. 3) Upon processing the request, the backend application fails to enforce authorization boundaries, allowing the attacker to access the full record. 4) The API response returns the stored notification configuration, including sensitive plaintext URLs or authentication credentials associated with services like Slack, SMTP, Telegram, Pushover, or Discord.\nFurthermore, the attacker can modify the notifier configuration. By submitting a modified payload in the PUT request, the attacker can overwrite the webhook URL. This redirection forces the victim's system to send future notifications—which may contain sensitive home inventory data or system alerts—directly to an attacker-controlled listener.\nThis vulnerability effectively bypasses the multi-tenancy logical isolation provided by the application. Because the affected NotifierRepository method lacks an owner-check predicate (e.g., WHERE user_id = ?), the application layer implicitly trusts the client-provided ID parameter. This pattern constitutes a classic IDOR vulnerability where object access control is absent at the controller/repository interaction layer.\nPost-exploitation, an attacker gains unauthorized access to credentials used for external communication platforms. This can lead to further downstream attacks, such as account takeover or internal reconnaissance based on the notifications sent from the HomeBox instance. The flaw remains exposed to any authenticated user who can enumerate or guess valid notifier UUIDs within the environment."
}