The Cybersecurity and Infrastructure Security Agency dropped another batch of actively exploited vulnerabilities into its Known Exploited Vulnerabilities catalog this week, and the implications stretch far beyond the federal agencies legally obligated to patch them. Three flaws — affecting Apple’s core operating systems, the Craft CMS content management platform, and the Laravel PHP framework — are now confirmed as weaponized in the wild. Not theoretical. Not proof-of-concept. Actively exploited.
For federal civilian executive branch agencies, the clock is ticking. CISA’s Binding Operational Directive 22-01 compels them to remediate these vulnerabilities by a hard deadline: April 3, 2025. But the directive’s real power has always been its signaling function. When CISA adds a vulnerability to the KEV catalog, it’s telling every organization — public, private, and everything in between — that attackers are already using this flaw to compromise systems. The catalog now contains over 1,200 entries, each one a documented case of exploitation in the real world.
The three new additions, as reported by The Hacker News, represent a cross-section of the modern attack surface: a mobile and desktop operating system used by billions, a popular content management system powering thousands of websites, and a PHP framework that underpins countless web applications. Let’s break down what’s happening with each one and why the urgency is warranted.
Apple’s Authorization Bypass: CVE-2025-24201 and the WebKit Problem That Won’t Go Away
The Apple vulnerability, tracked as CVE-2025-24201, is an out-of-bounds write issue in WebKit — the browser engine that powers Safari and is embedded in virtually every app on iOS that renders web content. Apple has described it as a supplementary fix for an attack that was blocked in iOS 17.2, meaning the company was aware of exploitation attempts dating back to at least late 2023. The flaw allows maliciously crafted web content to break out of the Web Content sandbox, a critical security boundary designed to contain the damage if a browser-based exploit succeeds.
Apple patched this vulnerability in iOS 18.3.2, iPadOS 18.3.2, macOS Sequoia 15.3.2, visionOS 2.3.2, and Safari 18.3.1. The company noted in its advisory that the bug “may have been exploited in an extremely sophisticated attack against specific targeted individuals.” That language — “extremely sophisticated” and “specific targeted individuals” — is Apple’s standard phrasing for what the security community typically associates with commercial spyware operations or nation-state targeting.
WebKit vulnerabilities have become a recurring theme. The engine’s mandatory use across all iOS browsers makes it a high-value target. An attacker who finds a WebKit flaw effectively has a vector into every iPhone and iPad on the planet, regardless of which browser the user prefers. Google Chrome on iOS? Still WebKit underneath. Firefox? Same story. This architectural decision by Apple, often criticized by security researchers and competitors alike, concentrates risk in a single codebase.
The sandbox escape dimension makes CVE-2025-24201 particularly dangerous. Most WebKit bugs are confined within the sandbox — they can read data the browser can see, but they can’t reach the rest of the operating system. An out-of-bounds write that escapes the sandbox is a different animal entirely. It’s the kind of vulnerability that, when chained with a privilege escalation bug, can give an attacker complete control of the device.
And these chains are exactly what commercial spyware vendors build.
The timing matters too. Apple releasing this as a “supplementary fix” suggests the original mitigation in iOS 17.2 was incomplete. Attackers found a way around it. That cat-and-mouse dynamic is familiar to anyone who’s tracked the ongoing battle between Apple’s security team and groups like NSO Group, whose Pegasus spyware has repeatedly exploited WebKit and iMessage vulnerabilities to compromise devices belonging to journalists, activists, and government officials worldwide.
Craft CMS and Laravel: When the Web’s Plumbing Springs a Leak
The other two vulnerabilities hit the web application layer, and they tell a story about how interconnected modern software really is.
CVE-2025-32432 is a remote code execution vulnerability in Craft CMS, the content management system used by organizations ranging from small creative agencies to major enterprises. With a CVSS score of 10.0 — the maximum — it doesn’t get more severe on paper. The flaw was disclosed by Orange Cyberdefense’s SensePost team, who discovered it during incident response work. That’s significant. They didn’t find it through routine research. They found it because someone was already exploiting it.
According to analysis published by Orange Cyberdefense, the Craft CMS vulnerability is rooted in how the platform handles image transformation requests. An unauthenticated attacker can send a specially crafted POST request to a Craft CMS controller action, which then passes user-supplied data into a PHP function in a way that enables arbitrary code execution on the server. No login required. No special permissions. Just a network request.
Craft CMS versions 3.x through 3.9.14, 4.x through 4.14.14, and 5.x through 5.6.16 are all affected. Patches are available in versions 3.9.15, 4.14.15, and 5.6.17. But here’s where it gets more complicated.
The Craft CMS vulnerability is actually a two-stage problem. The RCE in Craft CMS is made possible, in part, by a separate vulnerability in the Laravel framework — specifically in the Symfony component that Laravel uses. CVE-2024-9143, tracked separately, is a flaw that allows attackers to manipulate the way PHP processes certain inputs. The Craft CMS exploit chain uses both vulnerabilities together. Fixing one without the other leaves organizations exposed.
Laravel is not some niche tool. It’s the most popular PHP framework in the world, powering applications across every industry. When a vulnerability in Laravel’s dependency chain becomes part of an active exploit, the blast radius is enormous. The maintainers of both Craft CMS and Laravel have released patches, but the challenge for defenders is identifying every instance of these technologies in their environments. Shadow IT, forgotten staging servers, third-party plugins that bundle vulnerable components — these are the gaps attackers exploit.
The SensePost team’s research also revealed that attackers had been exploiting these flaws to deploy PHP-based web shells on compromised Craft CMS servers. Web shells give attackers persistent access. Even if the vulnerability is patched, if the web shell isn’t found and removed, the attacker retains a foothold. This means patching alone isn’t sufficient. Organizations running Craft CMS need to conduct forensic analysis of their servers to determine whether they’ve already been compromised.
CISA’s decision to add all three vulnerabilities simultaneously sends a clear message about the agency’s assessment of the threat. These aren’t theoretical risks. Federal agencies must patch by April 3, 2025, but CISA has repeatedly emphasized that every organization should treat the KEV catalog as a prioritization tool for their own vulnerability management programs.
The broader pattern here is worth examining. CISA’s KEV catalog has become one of the most influential vulnerability prioritization mechanisms in the industry, arguably more useful than CVSS scores alone. A CVSS 10.0 vulnerability that nobody is exploiting is less urgent than a CVSS 7.5 vulnerability with confirmed exploitation in the wild. The KEV catalog captures that distinction. And the data shows it works — organizations that prioritize KEV-listed vulnerabilities reduce their exposure to the attacks that are actually happening, not just the ones that could theoretically happen.
But the catalog also highlights a persistent problem. The gap between vulnerability disclosure and organizational patching remains stubbornly wide. CISA gives federal agencies weeks to patch KEV entries. Many private sector organizations take months. Some never patch at all. The three vulnerabilities added this week all have patches available. The Apple fix has been out since March 12. The Craft CMS and Laravel patches have been available since their respective disclosures. Yet the inclusion in the KEV catalog suggests that exploitation continues — meaning plenty of systems remain unpatched.
What This Means for Security Teams Right Now
The practical takeaways are straightforward but demand immediate action.
If you run Apple devices in your organization — and you almost certainly do — ensure they’re updated to iOS 18.3.2, iPadOS 18.3.2, macOS Sequoia 15.3.2, or later. Mobile device management platforms should be pushing these updates automatically, but verify. Don’t assume.
If you run Craft CMS anywhere in your infrastructure, treat this as an emergency. A CVSS 10.0 with confirmed exploitation and no authentication requirement is about as bad as it gets for a web-facing application. Patch immediately, then investigate. Check server logs for unusual POST requests to Craft CMS controller actions. Look for unfamiliar PHP files in your web directories. If you find web shells, assume the attacker has had access to everything the web server can reach — databases, configuration files, API keys, the works.
For Laravel and its Symfony dependencies, audit your applications. The vulnerability in the underlying component may affect applications beyond Craft CMS. Any PHP application using the affected Symfony versions could potentially be vulnerable, depending on how it processes user input.
And for everyone: if you’re not already using CISA’s KEV catalog as a core input to your vulnerability management program, start. It’s free. It’s updated regularly. And it reflects what attackers are actually doing, not what they might do someday.
The federal government’s patch-or-perish model under BOD 22-01 has its critics. Some argue the deadlines are too aggressive for complex enterprise environments. Others point out that the directive only applies to federal civilian agencies, leaving critical infrastructure operators and private companies to make their own decisions. But the underlying logic is sound: known exploited vulnerabilities represent clear and present danger, and they should be treated accordingly.
Three vulnerabilities. Three very different technologies. One common thread: attackers found them first, and they’re using them now. The patches exist. The question, as always, is whether organizations will apply them before the damage is done.