CISA has added two high-risk flaws — a critical XWiki remote code execution and a VMware local privilege escalation — to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation and urging immediate remediation under Binding Operational Directive (BOD) 22-01.
The KEV Catalog exists to highlight vulnerabilities demonstrably exploited in the wild and to drive prioritized remediation across the Federal Civilian Executive Branch via BOD 22-01. When CISA flags an item for the KEV catalog, federal agencies are required to follow remediation timelines or implement compensating controls. For enterprise defenders the practical effect is the same: these are vulnerabilities being weaponized now, not theoretical weaknesses to shelve.
The two additions announced affect two very different attack surfaces:
Key technical points:
Real-world campaigns observed chains that:
Key technical points:
Some security researchers reported observed exploitation of this weakness by advanced actors. The attack pattern is straightforward: place a specially crafted executable in a path that broad pattern-matching will match, then trigger the discovery routine so the tool executes the binary with elevated privileges.
Source: CISA CISA Adds Two Known Exploited Vulnerabilities to Catalog | CISA
Background
The KEV Catalog exists to highlight vulnerabilities demonstrably exploited in the wild and to drive prioritized remediation across the Federal Civilian Executive Branch via BOD 22-01. When CISA flags an item for the KEV catalog, federal agencies are required to follow remediation timelines or implement compensating controls. For enterprise defenders the practical effect is the same: these are vulnerabilities being weaponized now, not theoretical weaknesses to shelve.The two additions announced affect two very different attack surfaces:
- CVE-2025-24893 — XWiki Platform: Eval (eval injection) / SolrSearch RCE, a critical, remotely exploitable injection that can be triggered by unauthenticated users.
- CVE-2025-41244 — VMware Aria Operations & VMware Tools: privilege defined with unsafe actions, a local privilege escalation (LPE) affecting VMware Tools / open-vm-tools in environments where Aria Operations’ Service Discovery Management Pack (SDMP) is enabled.
Why this matters now
These vulnerabilities are not theoretical. Security teams have observed in-the-wild exploitation leading to:- Full server compromise from a single unauthenticated web request in the case of the XWiki RCE.
- Local escalation to root on guest VMs when VMware Tools / Aria Operations SDMP is present, enabling lateral movement, persistence, or post-exploitation escalation inside virtualized environments.
CVE deep dive: CVE-2025-24893 (XWiki Platform — Eval Injection / RCE)
What it is and how it works
CVE-2025-24893 is an eval injection, sometimes described as improper neutralization of directives in dynamically evaluated code. The vulnerability resides in XWiki’s SolrSearch RSS feed/macro handling; unsanitized input can be rendered into an evaluation context (Groovy macro execution) so that specially crafted search text payloads execute server-side code.Key technical points:
- Attack vector: Network (HTTP/S), unauthenticated.
- Impact: Remote code execution (RCE) as the application service account; on many deployments this allows full system compromise.
- Exploit complexity: Low — attackers can reach the vulnerable endpoint remotely with a crafted request.
- Patched versions: Vendor fixes were released; XWiki published patched releases that remove the unsafe evaluation context and/or harden the SolrSearch macro.
Why it’s dangerous
Eval-style vulnerabilities permit arbitrary code execution in the context of the server’s runtime engine. In the XWiki case attackers can inject Groovy snippets into search parameters that the SolrSearch macro will evaluate. That makes exploitation trivial for internet-exposed instances and dangerous for internally accessible wikis where untrusted users exist.Real-world campaigns observed chains that:
- Stage a downloader via file writes,
- Fetch additional payloads (miners, backdoors),
- Execute them later — leaving forensic artifacts that are easy to miss in high-traffic web servers.
Immediate remediation and mitigations
- Patch immediately. Upgrade XWiki to the patched releases provided by the vendor (the vendor-supplied fixed versions remove the unsafe evaluation behavior).
- Block or restrict the endpoint. If patching is not immediately possible, restrict access to the SolrSearch endpoint (for example, block /xwiki/bin/get/Main/SolrSearch with WAF rules or network ACLs) and disable untrusted macros.
- Harden templates/macros. If you must patch manually, ensure templates output safe content types (e.g., application/xml) and avoid raw, unsanitized macro output.
- Hunt for indicators. Search logs for unusual SolrSearch access patterns, RSS requests containing macro tags (e.g., {{groovy}}), and any wget/curl activity off the host occurring after suspicious search accesses.
- Contain and remediate compromises. If signs of exploitation are found, isolate the host, preserve logs and disk images, and perform full forensic analysis.
Detection tips
- Search webserver logs for requests to the SolrSearch endpoint with payloads that include "groovy", "async", or macro delimiters.
- Look for processes invoking shell binaries from web server user accounts, unexpected files in /tmp or application directories, and outbound connections initiated shortly after SolrSearch hits.
- Monitor for new accounts, crontab entries, or suspicious binary write-execute sequences — typical post-exploit artifacts.
CVE deep dive: CVE-2025-41244 (VMware Aria Operations & VMware Tools — Privilege-Defined With Unsafe Actions)
What it is and how it works
CVE-2025-41244 is a local privilege escalation stemming from unsafe handling of discovery/version-check routines in VMware Tools (and open-vm-tools) when used alongside Aria Operations’ SDMP. The underlying issue is overly-broad or unsafe privilege use coupled with a search path or regex that matches binaries in user-writable directories (for example, /tmp). Attackers with limited local privileges on a VM can craft a binary in a predictable path and force VMware tools to execute or query it in a way that results in root-level execution.Key technical points:
- Attack vector: Local (attacker needs the ability to run code as a non-privileged user in a guest VM).
- Impact: Privilege escalation to root on the same guest VM; can be combined with initial access to pivot further.
- Severity: High (effective LPE is often exploited to maintain persistence and move laterally).
- Mitigation: Vendor-supplied patches for VMware Tools / open-vm-tools and advisories to update or apply fixes.
Why it’s dangerous
Virtualized environments commonly host many services and sensitive workloads. A local non-admin account is frequently available to untrusted users, scripts, or compromised containers. LPEs in VMware toolsets give attackers a reliable elevation path that is particularly damaging because VMware Tools runs with higher privileges and is commonly installed by default.Some security researchers reported observed exploitation of this weakness by advanced actors. The attack pattern is straightforward: place a specially crafted executable in a path that broad pattern-matching will match, then trigger the discovery routine so the tool executes the binary with elevated privileges.
Immediate remediation and mitigations
- Apply vendor patches now. Install the vendor updates for VMware Tools and open-vm-tools that explicitly fix the unsafe matching and execution behavior.
- Harden service discovery. If possible, disable Aria Operations’ SDMP or the specific service discovery features until patches can be applied.
- Update guest images and templates. Ensure any golden images, VM templates, and cloud-init scripts use patched open-vm-tools.
- Monitor for signs of LPE exploitation. Look for unusual binaries in /tmp or other writable paths, unexpected root-owned artifacts created shortly after non-privileged activity, or sudden changes to service accounts.
- Coordinate with OS vendors. Many distributions are rolling out patched open-vm-tools packages; apply those distro-specific updates where applicable.
Detection tips
- Search for unexpected executables in /tmp and other user-writable directories, especially those launched by system services.
- Review syslogs and audit logs for successful privilege escalations or processes started by VMware tools.
- Monitor Aria Operations collectors for unexpected child processes or network listeners spawned by local binaries.
Practical remediation checklist (for security teams)
- Inventory
- Identify all publicly accessible XWiki instances and internal XWiki deployments.
- Inventory VMs with VMware Tools / open-vm-tools installed and determine which are managed by Aria Operations SDMP.
- Prioritize
- Treat all internet-exposed XWiki instances as high-priority for immediate patching or blocking.
- Prioritize VMs with shared user access or multi-tenant workloads for VMware updates.
- Patch
- Deploy the XWiki security updates to the affected versions immediately.
- Apply the VMware Tools / open-vm-tools patches provided by vendors and applicable OS distributors.
- Temporary mitigations
- Block vulnerable endpoints with WAFs or network ACLs.
- Disable SDMP or service discovery features where feasible until patched.
- Detection & response
- Hunt for IOCs mentioned above (suspicious SolrSearch payloads, /tmp/httpd binaries, wget/curl downloads).
- If compromise is suspected, isolate the host and preserve forensic evidence.
- Post-incident
- Rotate credentials and secrets that may have been exposed.
- Rebuild affected systems from known-good images after forensic validation.
- Process improvements
- Update vulnerability management playbooks to handle KEV catalog additions as immediate high-priority items.
- Use automated tools to pull the KEV catalog and cross-reference with asset inventory.
Operational risk analysis
Strengths in the response ecosystem
- Vendors released patches rapidly once the vulnerabilities were publicized, and many OS distributions are distributing patched open-vm-tools packages.
- CISA’s KEV mechanism forces federal agencies and many large organizations to prioritize these issues.
- Security researchers and incident responders rapidly published exploit patterns and detection guidance, enabling defenders to hunt and contain.
Risks and gaps
- Many XWiki installations are community-managed or used internally with lax update practices; internet-exposed instances remain at immediate risk.
- LPEs like CVE-2025-41244 often go unnoticed on crowded virtualization hosts because logs and audit trails are not always centrally collected or analyzed.
- Attribution claims and “who’s exploiting it” reports should be treated cautiously; while some firms link exploitation to specific advanced groups, definitive attribution is challenging and may be incomplete or contested.
- Workarounds for these classes of vulnerabilities (especially eval-style RCEs) are often incomplete; a temporary fix may reduce attack surface but not fully prevent crafted exploit variants.
Practical mitigation balance
- Rely on vendor patches as the definitive corrective action. Workarounds can reduce exposure but should be replaced by official fixes as soon as possible.
- Apply layered defenses: network segmentation, WAFs, endpoint protection, and centralized logging to reduce the blast radius of a successful exploit.
Detection and hunting playbook (quick steps)
- Search webserver access logs for SolrSearch RSS requests containing macro delimiters or Groovy tokens.
- Check process trees for binaries launched from user-writable directories (e.g., /tmp, /var/tmp).
- Scan for unusual scheduled jobs, new startup hooks, or newly installed services after suspicious web activity.
- Query SIEM for outbound connections initiated by web or VMware tools processes to suspicious IPs or domains.
- Use file integrity monitoring to detect unexpected executable drops and changes in critical macro/template files.
Governance and BOD 22-01 implications
CISA’s use of the KEV catalog under BOD 22-01 means that affected federal agencies must remediate by the specified due date or implement compensating controls and justify deviations. For commercial organizations, being KEV-aware is best practice: treat additions to the catalog as immediate high-priority items in your patch management workflow. Update playbooks to ensure such catalog additions cause automatic alerting, inventory checks, and time-boxed remediation windows.Strengths and weaknesses of current public reporting
Public reporting on both vulnerabilities and exploitation has been rapid and detailed; that helps defenders. However, speed creates noise: early reports sometimes contain incomplete or evolving details about attack chains, IOCs, or threat actor attribution. Analysts must balance urgency with caution:- Strengths: Rapid vendor patches, distribution of detection guidance, KEV-driven remediation deadlines.
- Weaknesses: Some attribution claims may be preliminary; exploit details may be weaponized in public PoCs, increasing the risk of copycat attacks.
Recommendations for WindowsForum readers (practical, immediate steps)
- For organizations running XWiki:
- Patch to the vendor-provided fixed releases immediately.
- If you cannot patch within hours, block access to the SolrSearch endpoint with firewall/WAF rules and restrict network exposure.
- Hunt logs for macro-injection patterns and unusual downloads or processes.
- For virtual infrastructure teams running VMware Tools / Aria Operations:
- Apply the vendor/open-source patches for VMware Tools and open-vm-tools immediately.
- Where feasible, disable SDMP or other service-discovery features until systems are patched.
- Update all VM templates and golden images with patched open-vm-tools to prevent reintroduction.
- For security operations teams:
- Add KEV-catalog monitoring to your vulnerability management pipeline so you are notified the moment a new KEV entry affects any of your assets.
- Run targeted hunts for the described indicators and prioritize containment if suspicious artifacts are found.
- For CIOs and CISOs:
- Treat KEV listings as executive-level action items and ensure resources are available for rapid remediation windows.
- Verify that third-party software and hosted service providers are taking timely action; require proof of patching where sensitive workloads exist.
Cautionary notes and unverifiable claims
Some public reporting links observed exploitation to specific actor groups and described particular payloads (for example, cryptominer deployment and attribution to named threat groups). While these reports often come from reputable researchers, attribution and specific campaign linkage can evolve as new telemetry arrives. Treat such claims as actionable intelligence only when corroborated by multiple independent sources or by your own telemetry. The immediate priority remains patching, detection, and containment — not debating attribution.Conclusion
The KEV catalog additions for CVE-2025-24893 (XWiki RCE) and CVE-2025-41244 (VMware Tools/Aria LPE) are a clear signal: both web-facing application flaws and local privilege escalations in virtualization tooling continue to be reliable, high-impact vectors for attackers. The playbook for defenders is unchanged but urgent — inventory, patch, contain, and hunt.- Patch now where fixes exist.
- Restrict exposure (block vulnerable endpoints, disable risky features) where immediate patching is not possible.
- Hunt and respond using the specific indicators described above.
- Treat KEV additions as operational priorities and update remediation workflows to ensure rapid, auditable responses.
Source: CISA CISA Adds Two Known Exploited Vulnerabilities to Catalog | CISA
