Is CVE-2025-43529 (Apple Multiple Products Use-After-Free WebKit) being exploited in the wild?

Yes. CISA added CVE-2025-43529 to its Known Exploited Vulnerabilities catalogue on 15 December 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS, iPadOS, macOS, and other Apple products contain a use-after-free vulnerability in WebKit. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

This question is not about whether the bug exists in theory, it is about whether exploitation has moved from proof-of-concept or lab testing into real attacker activity. For a CVE on CISA’s KEV list, the operational conclusion is simple: treat exposure as active, not hypothetical, and prioritise remediation based on the systems you actually run rather than on abstract severity.

For Apple WebKit issues, the practical exposure is broader than a single browser app. WebKit is embedded across Apple platforms, so the question is really about any reachable product surface that renders untrusted web content. That means internet-facing browsing, embedded web views, in-app content rendering, and any workflow where a user can be driven to malicious content. The CISA Known Exploited Vulnerabilities Catalog is the right place to confirm that this is being treated as an actively exploited flaw.

What should you verify on affected Apple estates?

First confirm where Apple iOS, iPadOS, macOS, and any other Apple products with WebKit are present, then determine which endpoints are exposed to untrusted browsing or app-embedded web content. The point is not just inventory, it is reachability, because a device that cannot be patched immediately but rarely processes hostile web content has a different near-term risk profile from a browser-heavy workstation or executive mobile device. This is the same practical prioritisation logic used in Vulnerability Management Guide.

Then validate whether you have compensating controls that materially reduce exposure, such as restricted browsing paths, managed browser policy, URL filtering, and the ability to limit high-risk users from opening untrusted links on the most exposed devices. If a system is part of a privileged workflow, has access to sensitive data, or is used for email and web access all day, it deserves faster treatment than a low-use endpoint.

If you need a broader pattern for how active exploitation changes response discipline, the common playbook is to treat KEV-listed issues as a patch-and-assess event, not as a routine backlog item. The right question becomes, “Where can this code path be reached, and what does compromise of that device expose?” not “Is the vendor advisory available yet?”

How to respond if patching must wait

When remediation cannot happen immediately, reduce the attack surface around the vulnerable WebKit-bearing products. That means tightening access to untrusted content, reducing the number of users and devices exposed to risky browsing, and removing any unnecessary web-facing dependencies that increase the chance of exploitation. For mobile fleets, also review whether the most exposed devices need temporary handling changes, such as stricter content filtering or deferred use for especially sensitive work.

Because WebKit flaws are often used for initial code execution or sandbox escape chains, the fallback is not “we will patch later and watch logs.” It is to narrow who can reach the vulnerable code path, shorten the exposure window, and assume that public exploit pressure is already part of the environment. The NIST Cybersecurity Framework 2.0 is useful here as a governance wrapper for identifying, protecting, detecting, responding, and recovering around an actively exploited weakness.

Risk and Threat Considerations

This kind of vulnerability is attractive because browser engines sit at the front door of daily user activity, and exploitation can occur through ordinary-looking web traffic or content delivery. The main risk is not just endpoint compromise, but what the compromised device can reach next, including sessions, web applications, email, files, and privileged workflows.

Failure mechanism: A use-after-free in WebKit can allow attacker-controlled memory corruption when parsing or rendering malicious content, which may be chained into code execution or deeper compromise depending on the platform and browser context.

Impact: An exploited endpoint can become a pivot point for credential theft, session hijack, data access, or follow-on intrusion, especially when the affected device belongs to a high-value user or has broad access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active KEV exploitation requires prioritised vuln management and rapid remediation.
Recommendation — Prioritise and remediate KEV-listed weaknesses on the most exposed assets first.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	This question is about confirming exposure to an actively exploited weakness.
	PR.PS-01 — Configurations and Operating Environments Are Managed to Meet Cybersecurity Requirements	Mitigation depends on reducing exposure and hardening browser/content handling.
	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Active exploitation warrants monitoring for signs of compromise on exposed devices.
Recommendation — Identify where the affected Apple products are deployed and record exposure paths. Harden exposed Apple endpoints and restrict untrusted web-content paths. Monitor exposed endpoints for indicators of browser-chain compromise and follow-on activity.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV status makes vulnerability prioritisation and verification materially relevant.
Recommendation — Scan and validate affected Apple assets, then drive urgent remediation tracking.

Practitioner Guidance

What to prioritise: Patch and verify the most exposed Apple endpoints first, especially those used for browsing, email, and access to sensitive business systems. If you cannot patch all devices at once, prioritise the ones with the broadest data access and the least restrictive browser controls.

What to verify: Confirm the vulnerable product family is actually in use, confirm the device is reachable by untrusted web content, and confirm the remediation really landed rather than only being scheduled. For active exploitation, verification matters as much as deployment.

Decision rule: If a device can process untrusted web content and holds meaningful enterprise access, treat it as urgent even if no local alert has fired. Absence of alerts does not mean absence of exploitation.

Practitioner takeaway: For a KEV-listed WebKit flaw, the operational standard is to assume real-world exploit pressure, reduce exposure immediately, and verify remediation on the highest-value devices first.