Khoadb175

Snipe-IT versions before 8.7.0 fail to apply company scope filtering to the GET /hardware/requested endpoint when Full Multiple Company Support is enabled, allowing authenticated users with assets.view permission to read pending asset requests from all companies. Attackers can retrieve cross-tenant data including requested asset names, requester display names and profile links, locations, and expected check-in dates without parameter manipulation.

**Name of the Vulnerable Software and Affected Versions** Snipe-IT versions prior to 8.6.2 **Description** An authorization bypass occurs in checkout-acceptance report actions when Full Multiple Company Support is enabled. Authenticated users with `reports.view` permission can enumerate sequential acceptance IDs to soft-delete or trigger reminder emails for acceptances belonging to other companies. This is possible by exploiting a null check on the legacy `users.company id` column. **Recommendations** Update to version 8.6.2 or later.

**Name of the Vulnerable Software and Affected Versions** Gitea (affected versions not specified) **Description** A blind Server-Side Request Forgery (SSRF) exists when the `[oauth2 client] UPDATE AVATAR = true` setting is enabled. The issue occurs because the server fetches the avatar URL provided by an OAuth2/OIDC provider—typically the `picture` claim—using the default Go HTTP client without applying outbound host or IP restrictions. A low-privileged user who can influence their own `picture` claim can force the Gitea server to make arbitrary outbound HTTP GET requests to loopback addresses, RFC 1918 private network addresses, and IPv4 link-local addresses such as `169.254.169.254`. Technical details include: - **Vulnerable Function**: `oauth2UpdateAvatarIfNeed()` in `routers/web/auth/oauth.go` and `oauth2SignInSync()` in `routers/web/auth/oauth signin sync.go`. - **Vulnerable Variable**: `gothUser.AvatarURL`. While the issue is primarily blind because non-image responses are rejected, the impact increases if the server can reach cloud metadata services or internal services that return valid image data, which could then be stored as the user's avatar. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability. As a temporary workaround, disable the avatar synchronization feature by setting `UPDATE AVATAR = false` in the `[oauth2 client]` section of the configuration.

**Name of the Vulnerable Software and Affected Versions** Gitea (affected versions not specified) **Description** An issue exists in the OAuth2 sign-in callback that allows a deactivated user account to be reactivated when signing in through an authentication source that does not issue refresh tokens, such as GitHub or OIDC/OAuth2 sources configured without `offline access`. The system incorrectly uses an empty refresh token as a signal that an account was disabled by the auto-sync cron rather than by an administrator. Consequently, when a deactivated user signs in via these providers, the system sets `IsActive` to `true` and grants a full session, bypassing the administrator's deactivation. This affects the `handleOAuth2SignIn` function within `routers/web/auth/oauth.go`. If the deactivated account had administrative privileges, those privileges are also restored. This does not affect accounts disabled via the Prohibit Login feature. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.