Khoadb175

When Full Multiple Company Support is enabled, the application fails to apply company scope filtering to the 'GET /hardware/requested' endpoint. This allows authenticated users with `assets.view` permission to access pending asset requests from all companies. This flaw enables the retrieval of cross-tenant data, including requested asset names, requester display names, profile links, locations, and expected check-in dates, without requiring parameter manipulation.

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.

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.

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.