| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| As part of Cisco's ongoing commitment to proactive security and product quality, Cisco has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76528 are related to protection mechanism failure and are grouped under the Common Weakness Enumeration (CWE) CWE-693. |
| In navigateUpTo of ActivityClientController.java, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In prepareWindowToDisplayDuringRelayout of WindowState.java, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible background activity launch due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In handlePackagePostInstall of InstallPackageHelper.java, there is a possible Enhanced Confirmation Mode (ECM) bypass vulnerability that allows a sideloaded application to modify the package source during a self-update due to a logic error in the code. This could lead to local escalation of privilege with User execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions of SaveUi.java, there is a possible bypass of package installation requirements due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In onStrongAuthRequiredChanged of UsbService.java, there is a possible unauthenticated enabling of USB data due to a logic error in the code. This could lead to physical escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in macOS Golden Gate 27.2. An app may be able to cause unexpected system termination. |
| Prefab UI's Generative UI sandbox runs caller-supplied Python inside Pyodide, Python compiled to WebAssembly, in a Deno subprocess. The feature is documented as isolation for untrusted code, including LLM-written UI. From prefab-ui 0.14.0 through 0.20.2 the launcher starts Deno with unrestricted --allow-read, --allow-write, and --allow-net, and the runner leaves the Deno API on the JavaScript global object. Pyodide's js module proxies that global, so the Python can call Deno.readTextFileSync and Deno.writeTextFileSync. A caller who can supply the code can read and write files as the server OS user, and can persist code execution by writing a .pth file into the server virtualenv's site-packages. The usual remote path is FastMCP's GenerativeUI provider, which registers the MCP tool generate_prefab_ui and forwards that tool's code argument into this sandbox. On a FastMCP server with no authentication configured, any client who can reach the server can call the tool. With authentication, any client allowed to call tools can. Generative UI is opt-in, and the host must have Deno installed. Confirmed on prefab-ui 0.20.2. Fixed in 0.21.0: after the runtime and Prefab sources load, the runner revokes Deno read, write, and network permission before it accepts code, the process is started with --no-prompt so a permission request cannot grant them again, and bootstrap network access is limited to cdn.jsdelivr.net. The fix is commit 030f074 (pull request 538). |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Initialize modname and offset in print_rec()
print_rec() leaves 'modname' and 'offset' uninitialized and
kallsyms_lookup() only sets them on success. When the lookup fails like
when a module is being loaded or unloaded, 'modname' holds a garbage
value, passes the 'if (modname)' check, and is dereferenced by
seq_printf().
Oops: general protection fault
RIP: 0010:string+0x48/0xe0
Call Trace:
vsnprintf+0x1f5/0x650
seq_printf+0x8e/0xb0
print_rec+0x6c/0xc0
t_show+0x4c/0x440
seq_read_iter+0x119/0x480
This can be triggered by reading available_filter_functions while a
module is being loaded or unloaded.
Initialize both variables so a failed lookup skips the module name. |
| Protection mechanism failure for some Cluster Management Toolkit for Kubernetes software before version v0.8.5 within Ring 3: User Applications may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Control Web Panel (CWP) before webpanel_version 1.12 contains an execution after redirect vulnerability in the user panel authentication flow (CWPUserIndex) that allows unauthenticated attackers to bypass authentication by exploiting a missing exit() call after a header('Location: ...') redirect. Attackers can send unauthenticated requests to continue PHP execution past the redirect, reaching user panel functionality that should require authentication. |
| Protection mechanism failure for some Intel(R) AI Containers before version v0.4.0 within Ring 3: User Applications may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Protection mechanism failure for some Intel(R) LLM Library for PyTorch within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Protection mechanism failure for some Intel Extension for TensorFlow software before version 2.15.0.3 within Ring 3: User Applications may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Protection mechanism failure for some LLM Scaler software within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| The MongoDB C# Driver writes GeoJSON extra members without checking whether their names collide with reserved GeoJSON members such as type and coordinates. An application that places user-supplied field names into these extra members can store documents with duplicate geometry fields, so the server and the driver resolve different values for the same record. Affected records can also become unreadable through the driver, interrupting application code that reads them. |
| Protection mechanism failure for some Intel(R) Data Center Attestation Primitives (Intel(R) DCAP) may allow information disclosure. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable data exposure. This result may potentially occur via network access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (high), integrity (none) and availability (none) impacts. |
| Incorrect order of security checks in Apache Wicket.
org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused.
The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them.
An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET.
As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in.
This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0.
Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener.
Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue. |
| Apache Wicket 10.10.0, 10.11.0 and 9.24.0 do not set the Content-Security-Policy headers on a page whose render request handler is wrapped in more than one IRequestHandlerDelegate. The framework unwraps only a single delegate level when deciding whether a request renders a page, so with a deeper chain, for example an application-provided delegating request mapper combined with CryptoMapper, the page is served without any CSP header even though CSP is enabled, and no error or warning is raised. The nonce-based protection Wicket applies to inline scripts and styles, together with any other CSP directives configured by the application, is thereby lost for those pages, exposing them to content injection the policy was meant to prevent. Applications on stock Wicket that do not wrap request handlers themselves are not affected. Versions before 10.10.0 and 9.24.0 handled nested delegates correctly. Users are recommended to upgrade to version 10.12.0 or 9.25.0, which fix the issue. |
