Yes. CISA added CVE-2019-8720 to its Known Exploited Vulnerabilities catalogue on 23 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. WebKitGTK contains a memory corruption vulnerability which can allow an attacker to perform remote code execution. Any organisation running the affected product should treat remediation as urgent.
What “exploited in the wild” means for CVE-2019-8720
For a CVE question, the practical meaning is whether there is credible evidence that attackers were using the flaw before or at the time defenders became aware of it. In this case, the answer is tied to CISA’s KEV catalogue entry, not to theory alone. That makes it a live exploitation problem, not a paper vulnerability.
WebKitGTK is a browser engine component, so exploitation can matter anywhere it is embedded in desktop Linux applications, browser-like renderers, or software that handles untrusted web content. The security question is therefore not only “is the library vulnerable?” but also “where is that engine exposed to attacker-controlled content?”
Why this vulnerability is operationally urgent
Memory corruption in a rendering engine is high value to attackers because it can be chained into code execution through ordinary user interaction. For exposed systems, the immediate concern is that successful exploitation may lead to arbitrary code execution inside the process context that loads the engine, which can then become a foothold for broader compromise.
Because this CVE is on CISA’s exploited-vulnerabilities list, the right response is to treat it as a priority exposure item, not as a routine backlog task. If the affected product is present on endpoints, kiosks, developer workstations, or application stacks that process untrusted web content, the blast radius can include data accessible to the running user or service and any trust relationships that process already holds.
How to confirm exposure and reduce risk quickly
Confirm where WebKitGTK is installed, which applications depend on it, and whether those applications are used with external or semi-trusted content. If the product is part of a fleet image, software bundle, or managed desktop build, inventory it at the package and application level so you do not miss indirect exposure through dependent software.
If patching must wait, reduce exposure by limiting where the affected renderer can reach untrusted content, tightening browser and application isolation, and removing unnecessary local trust. The safer interim posture is to narrow the number of users and systems that can trigger the vulnerable path while you wait for the vendor fix or approved mitigation path in the advisory.
After remediation, validate that the vulnerable component is no longer present in runtime packages and that the affected applications were actually updated, not merely staged for update. In exploitation cases, post-fix validation matters because a stale library copy, container image, or bundled application can leave the weak version reachable even when the host OS appears current.
Risk and Threat Considerations
Memory corruption in a widely used rendering component creates a realistic path from untrusted content to execution in the context of the affected application. That matters because attackers often target browser engines and embedded web runtimes as initial access points, then use the resulting code execution to expand to local data, sessions, or adjacent systems.
Failure mechanism: An attacker supplies content that triggers the memory corruption condition, which can produce code execution in the process that embeds WebKitGTK. If the application runs with access to sensitive data or trusted network paths, the compromise can extend well beyond the original user interaction.
Impact: The likely impact is endpoint compromise, credential or session exposure in the host context, and potential lateral movement if the compromised application has broader access than intended. Systems that embed the engine in privileged workflows or frequently process external content face the highest operational exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | Exposure decisions depend on knowing where WebKitGTK is deployed. |
| PR.PS-06 — Secure software development practices | A memory corruption exploit requires hardened software handling and timely remediation. | |
| DE.CM-08 — Vulnerability scans are performed | KEV-listed flaws require continuous discovery of exposed vulnerable software. | |
| Recommendation — Inventory affected hosts and bundled applications before you can scope remediation. Apply secure update and patch practices to remove the vulnerable component. Continuously scan for systems still running the affected package or bundle. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The question is about an actively exploited vulnerability and urgent remediation. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Reducing reachability of the affected engine is a configuration control problem. | |
| Recommendation — Prioritise and remediate the exploited CVE using a continuous vulnerability process. Harden application and desktop configurations to limit exposure to untrusted content. | ||
| OWASP ASVS | V15 — Secure Architecture | Embedded web runtimes need isolation and trust-boundary design to limit exploit impact. |
| Recommendation — Isolate embedded rendering paths from sensitive application functions and data. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Code execution from memory corruption is a common precursor to attacker execution actions. |
| Recommendation — Hunt for post-exploitation execution activity after a successful exploit. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | An exploited CVE requires timely flaw remediation and exception control. |
| SI-3 — Malicious Code Protection | Exploited rendering flaws often lead to payload delivery and execution. | |
| RA-5 — Vulnerability Monitoring and Scanning | You need continuous visibility into whether the KEV-listed issue still exists. | |
| Recommendation — Track and close the vulnerable software through formal flaw remediation. Pair patching with controls that block or detect delivered payloads. Continuously identify systems and bundles that remain exposed to the CVE. | ||
Practitioner Guidance
What to verify: Confirm whether the affected package is present in desktop images, application bundles, or dependency trees, and check whether any of those deployments process untrusted web content. If you cannot answer that quickly, your inventory is too weak for an exploited vulnerability.
Decision rule: If the vulnerable component is reachable in production, prioritise emergency remediation over normal maintenance scheduling. If patching is delayed, treat the exception as time-bound and pair it with exposure reduction, not passive acceptance.
Practitioner takeaway: For a KEV-listed memory corruption flaw, the key question is not whether exploitation is possible in principle, but whether your deployment still gives attackers a reachable path into a trusted runtime.
Related resources from NHI Mgmt Group
- Guide: Enterprise Browser and Browser Security Guide
- Is CVE-2019-7287 (Apple iOS Memory Corruption) being exploited in the wild?
- How do you patch or mitigate CVE-2019-8720 (WebKitGTK Memory Corruption)?
- Is CVE-2019-7286 (Apple Multiple Products Memory Corruption) being exploited in the wild?
- CVE-2019-8720 (WebKitGTK Memory Corruption)