CVE Vulnerability Catalog

A vulnerability was found in WAVLINK WN701AE 260105 in the function del_vlan_group of the ioos Web Backend. Manipulating the vlan_name argument results in OS command injection. The attack may be performed remotely and the exploit has been made public.

A vulnerability was found in WAVLINK WN553X1-B version 260403_2.0.0 affecting the sub_416B50 function in /bin/ioos. Manipulation of the file_id argument leads to OS command injection. The attack can be carried out remotely and the exploit has been publicly disclosed.

A flaw was found in WAVLINK WN553X1-B version V260403_2.0.0 affecting the sub_416D88 function in /bin/ioos (ioos Service component). Manipulation of the group_id/group_name arguments can lead to OS command injection. The attack can be executed remotely and the exploit has been published.

In the lud jsv library (versions from 0.1.0 before 0.26.2) an improper check for unusual or exceptional conditions exists in the pattern and patternProperties keywords. JSV.Helpers.RegexExt.bounded_match?/2 calls :re.run/3 without :report_errors, so exhausting the backtracking budget returns :nomatch just like a real non-match, allowing schema validation bypass. Only schemas whose regex explores a catastrophic branch before the matching branch are affected.

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.