Summary
HomeBox contains an authorization flaw in notifier updates that may let an authenticated user access and modify another tenant's notifier by supplying its identifier. The returned notifier URL may expose plaintext service credentials, while modification can redirect notifications to an attacker-controlled destination.
Affected context
The issue occurs in HomeBox deployments that use notifier records for services such as Slack, SMTP, Telegram, Pushover, or Discord. Risk is present when an authenticated user's request can identify a notifier owned by another tenant and the update operation does not verify ownership before returning or changing the stored URL.
Exploit preconditions
- Attack surface: Authenticated HTTP API access to notifier management
- Required access: A valid HomeBox user account and knowledge of, or ability to obtain, another notifier's identifier
- Trigger point: Updating a notifier through the notifier API
- Why exploitation is possible: The update operation uses the supplied record identifier without enforcing that the notifier belongs to the authenticated user's tenant
Why this happens
The underlying bug is an object-level authorization failure. The repository update path authorizes access by notifier identifier alone instead of combining that identifier with the authenticated user's or tenant's scope. This maps primarily to CWE-639, Authorization Bypass Through User-Controlled Key. Because notifier URLs may contain plaintext credentials, the same authorization failure can also expose sensitive authentication data associated with external notification services, relating to CWE-522.
Potential impact
- An attacker may read notifier URLs containing service credentials
- An attacker could redirect a victim's notifications to an endpoint they control
- External messaging or email accounts may be accessed or misused
- Notification confidentiality and integrity may be compromised
- Other tenants' notifier configurations could be altered
General mitigation guidance
Mitigation generally focuses on enforcing tenant-aware authorization at every
object access and update boundary.
Common defensive patterns include:
- Scope notifier lookups and updates by both record identifier and authenticated tenant
- Apply server-side ownership checks before returning any notifier data
- Avoid returning plaintext secrets in API responses, and store sensitive values using protected secret-handling mechanisms
- Use opaque, non-sequential identifiers as defense in depth rather than as the authorization control
- Apply least privilege to service integrations and restrict where notification endpoints may send data
- Record and review cross-tenant authorization failures and sensitive configuration changes
How teams detect issues like this
Detection can combine:
- Static analysis and code review checks for repository operations that use a user-controlled identifier without an ownership or tenant predicate
- Tests that attempt cross-tenant reads and updates for every object-management endpoint
- API policy checks requiring authorization before serialization of sensitive fields
- Audit monitoring for notifier changes, destination-domain changes, and repeated authorization failures
- Automated review tools that flag direct object lookups and updates lacking an authenticated-scope constraint
