CVE-2026-35113 in AION
Summary
by MITRE • 11/06/2026
HCL AION is affected by a vulnerability where the Cross-Origin-Opener-Policy (COOP) header was missing or insecure, allowing cross-origin documents to share a browsing context with the application. This may enable cross-window attacks, potentially resulting in unintended behavior or security impact under certain conditions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/06/2026
The identified vulnerability in HCL AION stems from an insufficient implementation of browser-side isolation mechanisms, specifically concerning the Cross-Origin-Opener-Policy header. In modern web architectures, browsers enforce a same-origin policy to prevent documents loaded from different origins from accessing each other's properties and methods. However, when cross-origin windows or tabs are opened via JavaScript functions such as window.open, they may share a common browsing context if specific isolation headers are not properly configured. The absence of the Cross-Origin-Opener-Policy header in HCL AION responses means that any page opening a new window from within the application does not establish an isolated browsing context group. Consequently, the newly opened window retains access to the opener's window object and its associated DOM elements, session data, or other sensitive client-side state information. This configuration flaw effectively bypasses intended security boundaries between different parts of the web application or external sites that might interact with it through popup windows.
This technical deficiency directly facilitates cross-window attacks where a malicious actor can exploit the shared browsing context to manipulate the parent window's behavior or extract sensitive data. For instance, if an attacker controls a page on a different origin and induces the user to open HCL AION in a new tab via this vulnerable mechanism, they could potentially read cookies, local storage contents, or other session identifiers from the opener window. Furthermore, the attacker might inject malicious scripts into the DOM of the parent window through the shared context, leading to cross-site scripting scenarios that persist across navigation events within the application. The operational impact includes potential unauthorized access to user sessions, data leakage of confidential information processed by HCL AION, and the ability to perform actions on behalf of authenticated users without their explicit consent or knowledge. Such vulnerabilities undermine the integrity and confidentiality guarantees expected from enterprise-grade applications like HCL AION, potentially leading to significant security breaches depending on the sensitivity of the data handled within the application's browsing context.
From a classification perspective, this vulnerability aligns with CWE-1021: Improper Restriction of Rendered UI Layers or Frames, as it involves an improper restriction that allows unintended interaction between different layers of user interface components across origins. It also relates to CWE-942: Permissive Cross-domain Policy with Untrusted Domains, although the specific mechanism here is through missing isolation headers rather than explicit policy files like CORS configurations. In terms of adversary tactics, this flaw supports techniques categorized under ATT&CK ID T1059: Command and Scripting Interpreter if used to inject scripts, or more broadly contributes to reconnaissance and credential access phases by allowing data exfiltration from the browsing context. The lack of proper isolation is a common oversight in web application development that fails to account for modern browser security features designed to mitigate clickjacking and cross-window scripting attacks.
To remediate this vulnerability, it is imperative to implement strict Cross-Origin-Opener-Policy headers on all HTTP responses generated by HCL AION. The recommended value for most enterprise applications is "same-origin," which ensures that any window opened from the application will not share a browsing context with windows or tabs originating from other origins. This change effectively isolates the application's session and DOM state from external pages, preventing cross-window data access even if an attacker manages to open a popup via social engineering or malicious links. Additionally, organizations should consider implementing Cross-Origin-Embedder-Policy headers to further restrict resource loading and enhance overall isolation. Security testing procedures must be updated to include automated checks for the presence and correctness of these headers in all response streams. Regular security audits focusing on browser-side protections will help ensure that such misconfigurations are detected early in the development lifecycle, thereby maintaining robust defense-in-depth strategies against cross-origin attacks targeting web-based enterprise applications.