CVE Vulnerability Catalog

In Oray Pugongying X5 Pro up to version 7.6.1, the config_restore_ex function in /etc/openwrt_release is vulnerable to relative path traversal via manipulation of the filename argument. The attack can be launched remotely and a public exploit is available.

In Oray Pugongying X5 Pro up to version 7.6.1, the run_apis_by_json/run_async_task functions in the API Authorization component allow improper authorization. The attack can be launched remotely and a public exploit has been released.

In Gitea, when [oauth2_client].ACCOUNT_LINKING is set to auto (not the default) and registration is enabled, the link-account sign-up form looked up the existing account by the submitted user name or email instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and sign in as it without a password, including as an administrator; the link persisted for later sign-ins.

In Oray Pugongying X5 Pro up to 7.6.1, the session_get function in session.lua (Session ID Handler component) produces insufficiently random values based on the _user argument. The attack can be initiated remotely, though complexity is rated high and exploitation is considered difficult. The exploit is publicly available and the vendor did not respond to the disclosure.

In Gitea, the web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the public-only restriction of the personal access token used to authenticate. Any user holding a public-only token could send it over HTTP Basic authentication to read the profile and activity feed of limited-visibility users and organizations, which are hidden from anonymous visitors and refused on the equivalent API routes.

In Gitea, the /{username} web route accepted personal access tokens over HTTP Basic authentication without checking their scope. A token confined to an unrelated scope, such as read:issue, could read its owner's private activity through the user RSS/Atom feed and the profile activity tab, and other members' activity in a private organization through the organization feed; a public-only token could list the owner's private repositories and organizations and render private profile READMEs. For a site administrator's token this applied to every account.

In Gitea, repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed.

In Gitea, the DELETE /api/v1/orgs/{org}/repos route deletes all repositories of an organization but did not enforce the public-only restriction of access tokens: it only checked that the organization itself was public. A public-only token of an owner of a public organization could therefore permanently delete the organization's private repositories, which such a token must not reach.

In Gitea, the web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check whether the repository is archived. A user allowed to change issues of an archived repository could use the API to edit, close or delete issues, change labels and deadlines, add or delete tracked time and stopwatches, add reactions, change issue blocks, and pin issues, altering data that archiving is meant to freeze.

In Gitea 1.27.3, personal access tokens restricted to public resources (public-only) were stopped from creating repositories through POST /api/v1/user/repos and POST /api/v1/repos/migrate, but POST /api/v1/org/{org}/repos, POST /api/v1/orgs/{org}/repos, POST /api/v1/orgs and POST /api/v1/repos/{owner}/{repo}/generate still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates.

In Gitea, the OAuth2 userinfo endpoint (/login/oauth/userinfo) decided whether to limit the groups claim to public organizations by re-parsing the Authorization header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships.

In Gitea, workflows triggered by a pull request review were read from the commit named in the review's commit_id, while fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a GITEA_TOKEN with write access to the repository.

In the OCI registry's cross-repository blob mount, the target package was checked against the token's `public-only` restriction, but the source blob was checked only against the token owner's full account permissions. A `public-only` token with `write:package` scope, whose owner can read a private package and write to a public package namespace, could mount a private package's blob into the public package, after which anyone could download it.

When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry looking for `Chart.yaml` without limiting the decompressed size, and did so before checking the package size quota, which only considers the compressed upload size. A user with package write access could repeatedly upload small, highly compressed archives, making the server spend CPU time proportional to the decompressed size and degrading the availability of the Gitea instance.

The issue timeline API and the web issue page hid cross-reference events pointing at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue was linked as a dependency to an issue in an inaccessible repository, any reader of the first issue, including anonymous users of a public repository, received the linked issue's title, body, state, labels, poster and attachment names through the API, and its repository, number and title on the web page.

The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (`public-only`). A holder of such a token could list the private repositories visible to the token's owner, and that user's stars and watches of private repositories.

The `/api/v1/admin` route group did not enforce the `public-only` restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could list private organizations and all users' email addresses, create organizations, obtain runner registration tokens and create new site administrator accounts, the last of which persists after the token is revoked.

The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance.

The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping their download URLs, delete releases and tags, and create, edit or delete milestones and labels of a repository meant to be read-only.

Gitea did not reject personal access tokens restricted to public resources (`public-only`) on the organization Actions runner registration-token endpoint, and the runner registered with the resulting token was not limited to public repositories. Holding only such a token with `write:organization` belonging to an owner of a public organization, an attacker could register an organization-level runner and receive jobs of the organization's private repositories with Actions enabled, including workflow content, Actions secrets and variables, and a task token with access to the private repository.