CVE-2026-115683 in Epiphany
Summary
by MITRE • 10/30/2026
A race condition in Epiphany allows a malicious website to bypass the TLS/SSL certificate warning page.
Epiphany registers the main-world script message handler "tlsErrorPage" so its internal TLS error page can implement "Accept Risk and Proceed". The handler was registered immediately before loading the error page, leaving a brief window where the previously loaded untrusted origin could still call window.webkit.messageHandlers.tlsErrorPage.postMessage(...). The only authorization check compares a numeric WebKit page id that increments predictably; an attacker can burst-guess ids and approve a certificate exception with no user click.
If a victim visits malicious site A that redirects to site B with an invalid certificate, site A can, for a few milliseconds, disable TLS certificate error warnings for host B until Epiphany is restarted, enabling man-in-the-middle or site spoofing for that host.
Upstream report: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2978 Proof of concept: https://beford.net/poc/ssl_poc.html Fix: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2245 (register handlers on LOAD_COMMITTED). No fixed release tagged yet; reporter and maintainer describe all current versions as affected. Maintainer notes the risky registration timing dates to commit 1da1caed (Epiphany 45.x era); before that the handlers were always registered and similarly reachable from web content.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability described constitutes a critical race condition within Epiphany, the default web browser for GNOME-based Linux distributions, which allows malicious websites to bypass TLS/SSL certificate warning pages. This flaw fundamentally undermines the security model intended by modern browsers, specifically the isolation between untrusted web content and privileged UI components that handle sensitive user decisions such as accepting invalid certificates. The core technical issue stems from the timing of registering a main-world script message handler named tlsErrorPage. Epiphany utilizes this handler to enable functionality within its internal TLS error page, allowing users to explicitly choose to accept risks and proceed despite certificate errors. However, the registration of this JavaScript interface occurs immediately before the error page is loaded into memory, creating a narrow but exploitable temporal window during which previously loaded web content from an untrusted origin retains access to call window.webkit.messageHandlers.tlsErrorPage.postMessage with arbitrary arguments.
The authorization mechanism designed to prevent abuse relies solely on comparing a numeric WebKit page identifier that increments predictably for each new navigation or frame creation. Because this identifier is sequential and predictable, an attacker can exploit the race condition by bursting requests containing guessed identifiers during the brief interval between handler registration and full initialization of the security checks within the error page logic. By correctly guessing the current page ID through rapid-fire postMessage calls, a malicious script can successfully invoke the accept-risk functionality without any user interaction or click event. This bypasses the intended human-in-the-loop verification process that is central to preventing man-in-the-middle attacks in web browsing contexts.
The operational impact of this vulnerability is severe for users navigating between sites where one redirects to another with an invalid certificate. If a victim visits a malicious site A which then redirects them to site B, and site B presents an invalid or self-signed TLS certificate, the code executing on site A can exploit this race condition to automatically approve the exception for host B before the user even sees the warning page. This effectively disables TLS certificate error warnings for that specific host until Epiphany is restarted by the user. Consequently, attackers can perform man-in-the-middle attacks or spoofing operations against the victim with impunity during subsequent visits to site B, as the browser will no longer warn about the invalid security posture of that domain.
This flaw maps directly to CWE-362, which describes concurrent execution race conditions where shared resources are accessed without proper synchronization, leading to unexpected behavior. In terms of offensive cyber operations and threat modeling, this vulnerability aligns with MITRE ATT&CK techniques related to browser exploitation and privilege escalation within the application context, specifically leveraging improper input validation or authorization checks in a multi-threaded environment. The ability to bypass certificate warnings is particularly dangerous as it erodes trust in the PKI system that secures web communications, potentially leading to credential theft, session hijacking, or malware distribution under the guise of legitimate traffic.
Mitigation strategies must address both immediate user actions and long-term software updates. Users should ensure they are running the latest patched version of Epiphany once a fixed release is tagged by upstream maintainers. Until then, users can mitigate risk by manually verifying certificate details for any site presenting warnings rather than relying on automatic handling mechanisms, although this does not fully eliminate the risk if redirections occur silently. From a development perspective, the fix involves altering the registration timing of message handlers to occur only after the load is committed, ensuring that no untrusted content can interact with privileged interfaces during the initialization phase. This aligns with secure coding practices that emphasize strict separation between untrusted web content and browser internals, preventing any possibility of cross-origin or same-context race conditions affecting security-critical UI components.