CVE Vulnerability Catalog

In Beta9, a tenant can attach a volume when deploying a function, endpoint, or task queue. The gateway builds the host path by joining the shared volumes root, the workspace name, and the volume identifier from the stub configuration, without checking that the identifier names a volume owned by that workspace. Parent-directory segments in the identifier collapse the joined path to the worker's filesystem root, which is bind-mounted read-write into the sandbox, allowing read and write access to the worker's files, including other tenants' volumes.

The Beta9 worker serves the sandbox file API from outside the container. getHostPathFromContainerPath turns the tenant's container path into a worker path; if the unresolved path starts with a mount destination (including the default /tmp/.beta9), the remainder is joined onto that mount's source with filepath.Join, which cleans parent-directory segments after the prefix check. A long enough run of such segments names any absolute path on the worker, and a path matching no mount is opened in the worker's filesystem, following absolute symbolic links. A tenant with a workspace token and a running sandbox can read, write, list, and delete files on the worker as root, including other tenants' files.

Beta9 turns each shell command in a tenant image definition into a Dockerfile RUN line and executes it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, and no buildah invocation passes --isolation, so the step only changes its filesystem root, keeping the worker pod's PID, network, IPC, and user namespaces, running as uid 0 with CAP_DAC_OVERRIDE. PID 1 in that procfs is the worker entrypoint, so /proc/1/root is the worker container's filesystem and is writable, containing the runc, buildah, and runsc binaries, the worker's Kubernetes service account token, and host directories mounted into the pod. Worker pods are privileged, and Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build.

A vulnerability was detected in WAVLINK WN701AE M01AE_V260105 affecting the del_staticrule function in static_route_setting.sh of the ioos Web Backend component. Manipulation of the rule_name argument leads to OS command injection. Remote exploitation is possible, and the exploit is publicly available and may be used.

A buffer overflow vulnerability has been detected in Hangzhou Xiongmai Technology P2PAPI.dll 1.3.3.32 on Windows. The issue affects the P2PAPI_Connect function in the P2P SDK component and is triggered by manipulating the String input argument. The attack requires local access, and the exploit has been publicly disclosed and may be used.

In Perl HTTP::Session versions before 0.54, the client cookie session id reaches the CHI store unfiltered, allowing memcached command injection. CR and LF characters in the session id terminate the cache command early, and the server reads the following bytes as further commands.

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.