CVE-2026-55637

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.

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.

A vulnerability was found in WAVLINK WL-WN530BE1-A V251117 in the con_check_read_finish function of /protocol.csp. Manipulation of the group_name/IP-FROM argument leads to command injection. The attack can be launched remotely and the exploit has been publicly disclosed.

A flaw was found in WAVLINK WL-WN530HG4B (version M_V260724) in the port_forward function of /cgi-bin/wapi.cgi. Manipulation of the Name argument leads to OS command injection. The attack can be performed remotely and a public exploit is available.

A vulnerability was detected in WAVLINK WN579X3-D (version V250402) in the port_forward function of /cgi-bin/wapi.cgi. Manipulation of the Name argument results in OS command injection. The attack may be performed remotely and the exploit is publicly available.

A security vulnerability was detected in WAVLINK WL-WN579A3-A (version 2026-03-10-94f93d4) in the set_wzdgwMesh function of /cgi-bin/adm.cgi, within the Initial Setup Wizard component. Manipulation of the wlan_ssid argument leads to OS command injection. The attack can be carried out remotely and the exploit has been publicly disclosed.