CVE-2026-35109 in AION
Summary
by MITRE • 11/06/2026
HCL AION is affected by a vulnerability where pages served over HTTPS could be cached by the browser or intermediate proxies. Sensitive information in cached responses may be retrieved by an unauthorized user with access to the cache, potentially resulting in unintended behavior or security impact under certain conditions.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The identified vulnerability within HCL AION represents a critical misconfiguration of HTTP caching directives for resources delivered over secure transport layers. Specifically, web pages and associated assets served via HTTPS are not properly instructed to prevent storage by user agents such as browsers or intermediate network entities like reverse proxies and content delivery networks. This flaw stems from the absence or incorrect implementation of standard cache-control headers that explicitly dictate how response data should be handled during transient storage phases. In a typical secure web application, sensitive information must never persist in shared or local caches unless strictly necessary for performance optimization without compromising confidentiality. The failure to enforce these directives allows cached copies of potentially confidential responses to remain accessible beyond the intended session lifecycle, creating an avenue for unauthorized access that bypasses standard authentication and authorization controls during subsequent interactions with the cache infrastructure.
From a technical perspective, this issue aligns closely with CWE-524, which categorizes information exposure through caches as a distinct class of web application security flaws. When HTTP responses lack directives such as Cache-Control: no-store or Pragma: no-cache, browsers and proxies are permitted to store the response body in their respective storage mechanisms. For HTTPS traffic, while the transmission is encrypted in transit, the cached data exists in plaintext on disk or memory at either the client side or intermediate proxy nodes. An attacker who gains access to these cache stores can retrieve sensitive payloads that were intended for specific authenticated users only. This scenario is particularly dangerous because it effectively neutralizes the confidentiality guarantees provided by TLS encryption once the data has been decrypted and cached, exposing secrets such as session tokens, personal identifiable information, financial details, or internal application logic to any entity with read access to the cache storage medium.
The operational impact of this vulnerability extends beyond simple data leakage. It can lead to unintended behavioral anomalies within the application itself. For instance, if a user logs out but their previous responses remain cached by an intermediate proxy, subsequent requests from different users on shared network infrastructure might inadvertently receive stale or sensitive content intended for the former user. This cross-user contamination undermines the isolation principles essential for multi-tenant environments and can result in privilege escalation scenarios where lower-privileged actors gain visibility into higher-privileged data streams. Furthermore, the persistence of cached credentials or session identifiers increases the risk of account takeover attacks if an attacker successfully extracts these values from local storage or proxy logs. The severity is amplified by the fact that caching mechanisms are often optimized for performance and transparency, meaning security controls must be explicitly enforced rather than assumed to exist by default.
To mitigate this vulnerability, developers and system administrators should implement strict cache-control policies across all sensitive endpoints within HCL AION. This involves configuring HTTP response headers to include Cache-Control: no-store, which instructs browsers and proxies not to store any part of the request or response under any circumstances. Additionally, including Pragma: no-cache provides backward compatibility with older HTTP/1.0 caches that may ignore newer directives. It is also advisable to set Expires to a past date and Vary headers appropriately if dynamic content depends on authentication status. Regular security audits should verify these header configurations across all HTTPS endpoints, ensuring that static assets which do not contain sensitive data are differentiated from dynamic pages requiring strict confidentiality. Adhering to OWASP guidelines for secure caching practices will significantly reduce the attack surface associated with information exposure through cache mechanisms and restore the integrity of access controls within the application ecosystem.