Prakhar0X01

An issue exists where a configuration field, accessible to common operational roles, allows the input of arbitrary outbound request destinations without proper validation. This enables authenticated attackers to force the server to send requests to internal network addresses that are otherwise unreachable from the outside. This is a server-side request forgery (SSRF), which occurs when a server is tricked into making requests to an unintended location.

An issue exists in a record-creation endpoint that accepts the record type from the request and inserts the record while permission checks are disabled. This allows any authenticated user, regardless of their operational role, to specify a privileged record type to create privileged accounts and gain full control of the site.

An authorization bypass exists where an endpoint honors a caller-supplied flag that disables permission enforcement. Authenticated attackers can use this flag to skip permission checks and read party records that exceed their assigned role permissions.

Gitea contains an issue where the post-receive git hook handler incorrectly processes git push options on existing repositories. Users with owner or admin-collaborator access can use the undocumented push options `repo.private` and `repo.template` during a `git push` to toggle a repository's visibility between private and public or change its template status. This process occurs within the `HookPostReceive()` function in the `routers/private/hook post receive.go` file. This action bypasses standard security controls and administrative tracking, resulting in no entries in the repository audit or activity logs, no webhook events, no organization-level notifications, and no email alerts to watchers. Additionally, the use of the `UpdateRepositoryColsNoAutoTime` function suppresses the `updated at` timestamp, making the change difficult to detect. This could allow an insider threat to temporarily make a private repository public for data exfiltration or silently manipulate repository templates to affect downstream CI/CD pipelines.

Gitea contains an information disclosure issue where requests containing the `go-get` query parameter with a value of `1` bypass authentication and authorization checks. This behavior is triggered in the `httpBase()` and `EarlyResponseForGoGetMeta()` functions. When this parameter is detected in a repository path, the system returns an HTTP 200 response containing metadata tags, regardless of whether the repository is private or the user is authenticated. This allows unauthenticated attackers to confirm the existence of private repositories, enumerate private repository names through brute-force, and harvest sensitive information such as full clone URLs, owner usernames, and default branch names. This occurs because the system was designed to provide a workaround for the Go toolchain's handling of credentials, resulting in an unauthenticated endpoint for every repository.

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 authorization issue exists in the organization-level Actions REST endpoints. The endpoints `/api/v1/orgs/{org}/actions/runs` and `/api/v1/orgs/{org}/actions/jobs` only verify organization membership and token validity, failing to perform per-repository Access Control List (ACL) checks. Consequently, any authenticated organization member can enumerate workflow runs and jobs from every repository within that organization, including private repositories for which the user has no explicit access or has been denied permissions. This flaw allows an attacker to use the endpoints as a search oracle to gather sensitive metadata from private repositories, such as repository names, descriptions, clone URLs, commit SHAs, branch names, workflow filenames, commit messages, and contributor identities. This can lead to organization reconnaissance, revealing product plans, security fix windows, or internal project topologies.

A flaw exists that allows for a permanent fork pull request workflow approval gate bypass. This issue enables an attacker to circumvent the required approval process when submitting changes from a forked repository.