Safari’s WebKit rendering engine has a flaw that could crash the browser and enable malicious code execution, and Apple hasn’t yet patched it even though a fix’s been available for weeks.
STORY HIGHLIGHTS:
Apple, WebKit vulnerabilities and patch-gapping
A new report fromArsTechnicaexplains that Safari’s WebKit engine has an exploitable flaw on iOS, iPadOS and macOS that could allow malicious code to execute on your iPhone, iPad, iPod touch and Mac. Curiously, afix for the Webkit flawhas been available for three weeks.
However, Apple’s yet to implement it.
Recent Apple OS updates include fixes for several vulnerabilities found in WebKit, but not for this particular flaw even though it could open the door to further malicious attacks. The company is currently testing iOS 14.7 with its registered developers and public beta testers, but it’s unclear if the updates include any patches for the vulnerability.
A bug in AudioWorklet seems to permit malicious code to execute on the device. AudioWorklet is a WebKit feature that’s responsible for rendering audio from web pages.
A fix for the AudioWorklet bug has been developed by third-party developers several weeks ago, but it’s unclear why Apple hasn’t implemented it already. Of course, the company could easily inclue neccessary fixes in upcoming operating system updates.
WebKit is a layout engine created by Apple that’s used by Safari and some other web browsers.
“We didn’t expect Safari to still be vulnerable weeks after the patch was public,” vulnerability researcher Tim Becker of cybersecurity startup Theori commented onTwitter.
This exploit was a fun challenge. We didn’t expect Safari to still be vulnerable weeks after the patch was public, but here we are…https://t.co/jkEH7w498Q
— Tim Becker (@tjbecker_)June 24, 2025
Becker opines in a post published on theTheori blogthat the existence of the yet-to-be-patched WebKit vulnerability yet again demonstrates that “patch-gapping is a significant danger with open source development.”
Patch-gapping refers to the window of time between a public patch for a security flaw and a stable release that integrates the patch into the main software. This window should be as small as possible to prevent bad actors from exploiting the vulnerability on devices in the wild.
“Ideally, the window of time between a public patch and a stable release is as small as possible.” Becker wrote. “In this case, a newly released version of iOS remains vulnerable weeks after the patch was public.”
