CVE-2026-118598 in Epiphany
Summary
by MITRE • 10/31/2026
A logic error in Epiphany's site permission handling can cause camera and microphone access to be granted when the user only approves a different permission.
In src/ephy-window.c, set_permission() stores the user's Allow/Deny choice after a WebKit permission dialog. Types CLIPBOARD and WEBSITE_DATA_ACCESS are not stored by ephy_permission_is_stored_by_permissions_manager(), so control fell into an else-if that was written as:
} else if (EPHY_PERMISSION_TYPE_ACCESS_WEBCAM_AND_MICROPHONE) {
Because that expression is a non-zero enum constant, the branch always ran for those types and wrote EPHY_PERMISSION_PERMIT for both ACCESS_WEBCAM and ACCESS_MICROPHONE for the site origin. The user only saw a Clipboard or Website Data Access dialog.
A malicious site that obtains approval for clipboard or third-party storage access can afterwards use getUserMedia without a further camera/microphone prompt, exposing audiovisual confidentiality.
Requirements: the victim must visit a malicious page and click Allow on a clipboard or website-data-access prompt.
Affected: Epiphany >= 45.0 (bug present at least through 51.x). Fixed: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2249 (commit 480c3648). Upstream: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2976 Reporter acknowledgment: Fernando Munoz
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability described is a critical logic error within the Epiphany web browser, specifically located in the site permission handling mechanism found in src/ephy-window.c. This flaw allows an attacker to bypass user consent for sensitive hardware access by exploiting how different permission types are processed and stored. The core issue stems from a faulty conditional statement that incorrectly evaluates non-camera/microphone permissions as if they were requests for webcam or microphone access. When a user interacts with a WebKit permission dialog, the set_permission function is invoked to record their choice of Allow or Deny. However, due to an oversight in the code structure, certain permission types such as CLIPBOARD and WEBSITE_DATA_ACCESS are not properly stored by the ephy_permission_is_stored_by_permissions_manager function. This causes control flow to fall into a subsequent else-if block that was intended exclusively for handling webcam and microphone permissions.
The technical flaw lies in the condition used within this fallback branch, which is written as if (EPHY_PERMISSION_TYPE_ACCESS_WEBCAM_AND_MICROPHONE). In C programming, enum constants are typically represented by non-zero integer values. Consequently, this expression always evaluates to true regardless of the actual permission type being processed. As a result, whenever a user approves access for clipboard or website data storage, the browser erroneously writes an EPHY_PERMISSION_PERMIT status for both ACCESS_WEBCAM and ACCESS_MICROPHONE associated with that site origin. This means the browser internally records that the user has granted camera and microphone permissions even though they only interacted with dialogs requesting less sensitive privileges like clipboard access or third-party storage usage.
From a security perspective, this vulnerability leads to a significant breach of audiovisual confidentiality. A malicious website can exploit this logic error by first prompting the user for permission to access the system clipboard or store data in web storage. Once the victim clicks Allow on these benign-looking prompts, the browser incorrectly logs that camera and microphone access has been permitted. Subsequently, the attacker's script can invoke the getUserMedia API without triggering any further user consent dialogs. This allows the malicious site to silently capture audio and video from the user's environment, exposing private conversations, visual surroundings, and potentially sensitive personal information without the victim's knowledge or explicit approval for those specific actions.
This vulnerability aligns with CWE-20 Improper Input Validation as it involves incorrect handling of input parameters leading to unintended behavior in permission management. It also maps to MITRE ATT&CK technique T1567 Exploit Public-Facing Application, where an attacker leverages a flaw in the application's logic to gain unauthorized access to resources. Additionally, it relates to CWE-284 Improper Access Control because the system fails to correctly enforce user consent boundaries for specific resource types. The operational impact is severe as it undermines the fundamental trust model of web browsers regarding privacy and security prompts, allowing stealthy surveillance capabilities through standard web technologies.
Mitigation strategies primarily involve applying the upstream fix provided by the GNOME project, which corrects the conditional logic in src/ephy-window.c to properly distinguish between different permission types before granting access rights. Users should ensure their Epiphany browser is updated to a version greater than 45.0 where this bug has been addressed, specifically looking for versions that include commit 480c3648 or later from the merge request 2249. Until an update can be applied, users should exercise extreme caution when granting any permissions on untrusted websites and consider using browser extensions or settings that restrict automatic permission grants. Regularly updating software to patch known logic errors is essential for maintaining robust defense-in-depth against such privilege escalation attacks via web interfaces.