CISA’s latest update to the Known Exploited Vulnerabilities (KEV) Catalog adds three actively exploited flaws — a Linux kernel TOCTOU race condition, an Android Runtime issue, and a high‑impact Sitecore deserialization vulnerability — forcing organizations that track KEV and federal agencies under BOD 22‑01 to urgently reassess exposure and remediate according to accelerated timelines. (cisa.gov)
CISA’s KEV Catalog is a policy‑backed, operational list of Common Vulnerabilities and Exposures (CVEs) that the agency has determined are being actively exploited in the wild. The catalog exists to focus scarce operational resources on vulnerabilities with reliable evidence of exploitation and available mitigations. Under Binding Operational Directive (BOD) 22‑01, Federal Civilian Executive Branch (FCEB) agencies must remediate cataloged CVEs within prescribed deadlines — typically two weeks for recent CVEs (2021 and later) and six months for older CVEs unless CISA specifies otherwise. This directive effectively turns threat intelligence into mandatory operational workstreams for federal agencies. (cisa.gov)
On September 4, 2025, CISA added the following entries to the KEV Catalog: CVE‑2025‑38352 (Linux kernel TOCTOU race condition), CVE‑2025‑48543 (Android Runtime unspecified vulnerability), and CVE‑2025‑53690 (Sitecore multiple products — deserialization of untrusted data). The agency’s alert is concise but consequential: each entry is listed because of credible evidence of active exploitation. (cisa.gov)
Strengths of the KEV approach:
CISA’s alert and the surrounding vendor disclosures make one operational truth unavoidable: in a world where attackers pivot quickly from reconnaissance to exploitation, vulnerability management must be fast, coordinated, and evidence‑driven — and KEV additions are the most immediate evidence that defenders must act now. (cisa.gov, securityweek.com)
Source: CISA CISA Adds Three Known Exploited Vulnerabilities to Catalog | CISA
Background / Overview
CISA’s KEV Catalog is a policy‑backed, operational list of Common Vulnerabilities and Exposures (CVEs) that the agency has determined are being actively exploited in the wild. The catalog exists to focus scarce operational resources on vulnerabilities with reliable evidence of exploitation and available mitigations. Under Binding Operational Directive (BOD) 22‑01, Federal Civilian Executive Branch (FCEB) agencies must remediate cataloged CVEs within prescribed deadlines — typically two weeks for recent CVEs (2021 and later) and six months for older CVEs unless CISA specifies otherwise. This directive effectively turns threat intelligence into mandatory operational workstreams for federal agencies. (cisa.gov)On September 4, 2025, CISA added the following entries to the KEV Catalog: CVE‑2025‑38352 (Linux kernel TOCTOU race condition), CVE‑2025‑48543 (Android Runtime unspecified vulnerability), and CVE‑2025‑53690 (Sitecore multiple products — deserialization of untrusted data). The agency’s alert is concise but consequential: each entry is listed because of credible evidence of active exploitation. (cisa.gov)
Why KEV entries matter for enterprises and Windows admins
CISA’s KEV listings are aimed at federal agencies, but the operational reality is broader: private sector organizations and IT teams should treat KEV inclusions as high‑priority signals. Attackers routinely mix old and new exploits, and many KEV entries affect stacks that touch Windows infrastructure — for example, web servers, reverse proxies, load balancers, and identity stores that integrate with Windows domain services.- KEV entries reduce the signal‑to‑noise problem in vulnerability triage by highlighting exploited CVEs rather than every high‑scoring finding.
- For organizations that cannot patch immediately, KEV items often require hard decisions: mitigation or isolation until a patch can be applied.
- Windows administrators who manage hybrid environments (Windows servers, Linux appliances, Android devices used for mobile management, and .NET/asp.net web platforms like Sitecore) should treat KEV additions as cross‑domain incidents requiring coordination across endpoint, server, and application teams. (cisa.gov)
Deep dive: CVE‑2025‑38352 — Linux kernel TOCTOU race condition
What it is
CVE‑2025‑38352 is a race condition in the Linux kernel related to POSIX CPU timers (posix‑cputimers). The vulnerability arises from a Time‑of‑Check Time‑of‑Use (TOCTOU) window between timer handling and timer deletion routines, where an exiting task may be reaped while concurrent timer deletion is in progress — enabling inconsistent internal state that can lead to kernel instability or privilege escalation. The fix applied in kernel trees adds an extra task exit‑state check to prevent this race. (nvd.nist.gov, wiz.io)Why it matters now
Kernel race conditions are attractive to attackers because they can be leveraged for local privilege escalation or to destabilize a host (denial‑of‑service). When such a flaw is present in kernels used by edge systems, cloud instances, container hosts, or Android device kernels, exploitation can become a practical pathway to escalate from an unprivileged process to system or root privileges. CISA’s KEV addition indicates evidence of real‑world exploitation or telemetry consistent with active abuse, which elevates the operational priority of this bug beyond a routine kernel patch. (cisa.gov, wiz.io)Who’s affected
- Linux distributions running affected kernel branches (mainline and vendor backports).
- Android devices that include the vulnerable kernel code in their device kernel builds (Google and OEMs may ship fixes as part of monthly security updates).
- Virtualized and container platforms that inherit the host kernel’s behavior.
Mitigation and remediation
- Apply vendor kernel updates immediately where available.
- For systems where kernel upgrades require operational windows (e.g., production VMs or embedded systems), isolate or restrict untrusted code execution paths and remove or limit local access that could trigger exploitation.
- Use host‑based intrusion detection and kernel integrity monitoring to detect anomalous behavior that might indicate exploitation attempts.
- For Android fleets: enroll devices in a patch management cadence and deploy OEM/Google updates as they arrive. Public Android bulletins and vendor patch packages will include kernel fixes as appropriate. (wiz.io, bleepingcomputer.com)
Deep dive: CVE‑2025‑48543 — Android Runtime unspecified vulnerability
What is known
CVE‑2025‑48543 is listed by CISA as an Android Runtime vulnerability and is being treated as actively exploited. Public reporting around September 2025 (vendor bulletins and security outlets) indicates Google labeled the flaw as an elevation‑of‑privilege type issue that affects the Android Runtime (ART), which is the managed runtime for Java/Kotlin apps and many system services on Android devices. Google’s September security updates address this and another actively exploited issue. (cisa.gov, bleepingcomputer.com, helpnetsecurity.com)Operational impact
ART vulnerabilities are significant because they can be leveraged by malicious applications to escape sandbox restrictions or escalate privileges, enabling access to data or capabilities that should be out of reach for third‑party apps. If an attacker can install or coerce installation of a malicious app — or exploit a preinstalled app with writeable attack surfaces — they may be able to pivot from a limited app context into a broader device compromise.Vendor action and mitigation
- Google shipped fixes in the September 2025 Android security update; OEMs and device makers are releasing platform updates or patches for affected models. Organizations should prioritize installing these patches for managed Android fleets. (bleepingcomputer.com, helpnetsecurity.com)
- Where immediate patching isn’t feasible, restrict app installation sources, enforce mobile‑device management (MDM) policies that block untrusted apps, and apply runtime app protections (e.g., app‑allowlists, privilege restriction profiles).
- Monitor mobile threat intelligence feeds for Indicators of Compromise (IoCs) tied to the active exploitation described by vendors. CISA’s KEV listing implies exploitation telemetry exists but typically does not include exploit code or full technical details. (cisa.gov)
Deep dive: CVE‑2025‑53690 — Sitecore deserialization of untrusted data (ViewState)
Technical summary
CVE‑2025‑53690 is a deserialization (ViewState) vulnerability affecting multiple Sitecore products — including Experience Manager (XM), Experience Platform (XP), and Experience Commerce (XC) — when deployments used a publicly known or sample ASP.NET machine key. Attackers who possess or can guess the machine key can craft malicious ViewState payloads that the application will deserialize, leading to remote code execution (RCE). The vulnerability was observed in active exploitation where attackers delivered ViewState payloads that achieved RCE and installed reconnaissance and post‑exploitation tools. (helpnetsecurity.com, securityweek.com)Track record and observed attacks
Mandiant was involved in incident response that disrupted the attack, and multiple security outlets reported that attackers exploited an exposed sample machine key in deployment guides dating back several years. The exploit chain focused on the /sitecore/blocked.aspx endpoint (a page that uses a hidden ViewState form) and used WeepSteel (or similarly named tooling) in post‑exploit stages to harvest configuration data and move laterally. Observers reported the attackers archived web application directories, staged open source tools for tunneling and remote access, and attempted credential theft and lateral escalation. Because incident responders interrupted the intrusions, the full scope of the campaign remains unknown, but the immediate danger is clear: internet‑facing Sitecore instances deployed with non‑unique machine keys were reliably exploitable. (helpnetsecurity.com, securityweek.com, cyberscoop.com)Impact and affected configurations
- Internet‑facing Sitecore instances that used the sample machine key from deployment guides (notably older XP 9.0 deployment instructions) are at high risk.
- Multi‑instance topologies with static, manually managed machine keys are also potentially vulnerable.
- Managed Cloud or containerized environments that used customer‑provided static machine keys require verification; updated Sitecore deployments reportedly generate unique machine keys by default. (helpnetsecurity.com, cyberscoop.com)
Recommended remediation steps
- Immediately rotate the ASP.NET machine key for any Sitecore deployment where a sample or known key may have been used. Rotation is a first step but does not remediate systems already compromised.
- Deploy Sitecore‑provided patches and guidance. Sitecore has issued advisories and mitigation guidance; affected customers have reportedly been notified.
- Hunt for indicators of compromise: look for ViewState deserialization attempts in web logs, unexpected __VIEWSTATE responses containing encrypted data, staged artifacts in public directories, newly created admin accounts, and evidence of tools like DWAgent, Sharphound, or custom reconnaissance assemblies. (helpnetsecurity.com, securityweek.com)
- If an internet‑facing Sitecore instance was deployed with a non‑unique machine key, assume potential compromise until proven otherwise: isolate the instance, perform a full forensic investigation, and restore from clean backups after removing persistence. (cyberscoop.com)
Practical remediation checklist for IT teams
For organizations managing Windows servers, Linux hosts, Android fleets, and .NET/Sitecore applications, a coordinated remediation plan reduces operational risk and meets KEV‑driven urgency:- Inventory and prioritize
- Identify assets running vulnerable kernels, Android versions, or Sitecore topologies.
- Map internet‑facing services and business‑critical systems that may be exposed.
- Patch and verify
- Apply vendor patches immediately where available (Google/AOSP for Android, Linux distro vendors for kernel updates, Sitecore for product advisories).
- Verify patch deployment through configuration management or endpoint management tools.
- Isolate and mitigate when patching is delayed
- Block or limit exposure of internet‑facing endpoints (WAF rules, network ACLs, reverse proxy mitigations).
- For Android, restrict app installs and enforce MDM policies.
- On Windows networks, segment servers and limit lateral movement via firewall rules and privileged access management.
- Hunt and respond
- Search for web logs, syslogs, and EDR alerts that match known exploitation patterns (malformed ViewState requests, abnormal kernel oops/crashes, suspicious app behavior on Android).
- Rotate credentials and machine keys where relevant, and assume breach for services with confirmed exploitation.
- Communicate and document
- Record timelines, affected hosts, remediations, and verification steps.
- Notify stakeholders and escalate to incident response if signs of compromise are present.
Detection and hunting guidance (concise, actionable)
- Kernel/host hunts:
- Look for new kernel panics or repeated oops logs centered on posix_cputimers functions.
- Audit privileged process spawn events and unexpected setuid behaviors.
- Android hunts:
- Monitor for apps requesting unusual runtime permissions, abnormal app restarts, or native crashes in ART.
- Use MDM telemetry to track app installs and unusual network C2 patterns.
- Sitecore hunts:
- Search web server access logs for POSTs or GETs containing __VIEWSTATE values sent to pages like /sitecore/blocked.aspx.
- Flag responses that are larger than expected, or that contain unusual binary blobs.
- Look for new accounts, sudden uploads to public directories, or remote access tool binaries being staged. (helpnetsecurity.com, securityweek.com)
Risk analysis and critical considerations
CISA’s KEV designation reflects active exploitation; that elevates the risk posture of these CVEs from theoretical to operationally immediate. There are pragmatic caveats:- Public telemetry described by vendors and incident responders often lacks full exploit code or broad attribution, so defenders must behave as if there is a credible threat without relying on public exploit samples.
- Sitecore’s case highlights a recurring failure pattern: secure defaults and deployment guidance matter. Publicly distributed sample keys in documentation have long been a source of avoidable exposure — organizations must treat documentation artifacts as potential weak points. (cyberscoop.com)
- Linux kernel race conditions and Android runtime issues vary in exploit complexity; some may require local access or specific environment conditions, while others can be chained with other flaws for full RCE. Prioritization should consider exploitability, presence of internet‑facing vectors, and business impact. (wiz.io, bleepingcomputer.com)
What Windows administrators should do right now
- Ensure perimeter controls protect web applications: validate WAF rules, and harden reverse proxies and load balancers to block suspicious payloads and protect ViewState endpoints.
- Coordinate with Linux and cloud teams to fast‑track kernel updates for affected hosts; where kernel updates are disruptive, consider compensating controls such as host isolation, increased monitoring, and workload migration.
- For on‑premises Sitecore deployments, treat any instance that used default or sample machine keys as high‑risk: rotate keys, patch Sitecore components, and perform a forensic investigation into web logs and filesystem changes.
- Enforce endpoint management and mobile policy for Android devices; prioritize security patch levels and block sideloading for enterprise devices.
- Update incident response playbooks to include KEV entries as triggers for urgent review and remediation. (cisa.gov, helpnetsecurity.com)
Final assessment
CISA’s addition of CVE‑2025‑38352, CVE‑2025‑48543, and CVE‑2025‑53690 to the KEV Catalog is both a warning and a call to action. The three flaws span kernel internals, managed runtime components, and application‑level deserialization — illustrating the breadth of attacker tactics and the need for cross‑team coordination.Strengths of the KEV approach:
- Focuses attention on vulnerabilities with evidence of exploitation.
- Provides clear operational pressure (BOD 22‑01) that drives real remediation.
- KEV listings don’t always include full technical detail, leaving defenders to infer exploit specifics from vendor advisories and incident reports.
- Operational constraints (maintenance windows, legacy systems) complicate strict timelines and may force interim compensations that must be managed carefully.
CISA’s alert and the surrounding vendor disclosures make one operational truth unavoidable: in a world where attackers pivot quickly from reconnaissance to exploitation, vulnerability management must be fast, coordinated, and evidence‑driven — and KEV additions are the most immediate evidence that defenders must act now. (cisa.gov, securityweek.com)
Source: CISA CISA Adds Three Known Exploited Vulnerabilities to Catalog | CISA
