CVE WatchNov 6, 2026

CVE-2026-80301

Improper isolation in the Avast sandbox on Windows allows a local, low-privileged attacker executing inside the sandbox to access COM interf

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

0-100

Published: Nov 6, 2026 · Last modified: Nov 6, 2026 · CWE-280 · CWE-653

EPSS · 30d

Not enough EPSS history yet.

Technical description

Improper isolation in the Avast sandbox on Windows allows a local, low-privileged attacker executing inside the sandbox to access COM interfaces to the Task Scheduler service, escape containment, and execute code with elevated privileges outside the sandbox. The sandbox virtualizes file system and registry access but does not adequately restrict COM interface access to Task Scheduler. A process inside the sandbox can instantiate COM objects bound to Task Scheduler functionality and invoke methods to schedule and execute tasks on the host system. The Task Scheduler COM pathway is not blocked by the sandbox policy, allowing arbitrary code execution in the host security context. This escape vector bypasses the sandbox's intended process and file isolation boundaries and can be chained with other host-level privilege escalation techniques.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-80302—

—

——0Insufficient isolation in the Avast sandbox file virtualization layer on Windows allows a local, low-privileged attacker executing inside the sandbox to write arbitrary files outside sandbox containment and execute code on the host. The sandbox virtualizes file system operations by intercepting write requests to protected system directories. However, the virtualization implementation fails to properly validate write targets in certain edge cases, allowing writes to bypass the virtualization redirection and reach the actual host file system in protected locations. An attacker can exploit this to overwrite executable files, system libraries, or startup configurations with arbitrary content, leading to code execution with host privileges on subsequent system operations or reboot.11h CVE-2026-1136879.8 CRI

13.3%

——4Improper isolation or compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements for Implementations can create a malicious Groovy class running untrusted code on a separate Thread, thus bypassing the Groovy security sandbox. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 through 4.0.8, from 4.1.0-M0 through 4.1.3. Users are recommended to upgrade to version 4.0.9 / 4.1.4, which fix this issue.8h CVE-2026-1090839.8 CRI

12.9%

——4Improper isolation or compartmentalization vulnerability in Apache Syncope. An administrator with adequate entitlements can import arbitrary BPMN process definitions via the REST API and then start the process. When a BPMN process containing a JUEL expression is imported and started, the expression is executed directly on the server, with no sandbox. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 through 4.0.8, from 4.1.0 through 4.1.3. Users are recommended to upgrade to version 4.0.9 / 4.1.4, which fix this issue by rejecting BPMN definitions including expression attributes.8h CVE-2026-205996.7 MED

1.0%

——0In Modem, there is a possible escalation of privilege due to a missing permission check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: MOLY01790985; Issue ID: MSV-8148.4d CVE-2026-205774.4 MED

1.0%

——0In Modem, there is a possible permission bypass due to a permissions bypass. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: MOLY01880753; Issue ID: MSV-9866.4d CVE-2026-1203069.9 CRI

30.2%

——9Beta9 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. It keeps the worker pod's PID, network, IPC, and user namespaces, runs as uid 0, and holds 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. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker's Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged. Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build. The read-only proof confirmed the shared namespaces, CAP_DAC_OVERRIDE, and that the worker's runc binary is visible at /proc/1/root. Fixed in worker 0.1.756: Buildah RUN steps, including the WORKDIR mkdir, use OCI isolation with private PID, IPC, and network namespaces, and tenant ARG values are passed only into the build container.4d