CISA Highlights Active Exploitation of GeoServer XXE Vulnerability CVE-2025-58360

A critical XML External Entity (XXE) vulnerability in GeoServer, tracked as CVE-2025-58360, is being actively exploited in the wild, prompting CISA to add the flaw to its Known Exploited Vulnerabilities catalog and urge immediate patching. The issue allows remote attackers to exfiltrate sensitive files and potentially pivot within geospatial infrastructures widely used by governments, utilities, and critical infrastructure operators.

Overview of CVE-2025-58360

CVE-2025-58360 is an XML External Entity processing flaw in vulnerable versions of GeoServer that mishandles untrusted XML input. When GeoServer parses XML payloads without disabling external entities and DTD resolution, an attacker can craft input that forces the server to dereference local files or remote network resources.

The vulnerability requires only network access to exposed GeoServer endpoints that accept XML, such as WFS, WMS, or configuration APIs, and no valid credentials in many default deployments. This makes internet-exposed instances high-value targets for automated scanning and exploitation.

Technical Mechanics of the XXE Attack

At its core, the flaw arises from insecure XML parser configuration. XXE attacks leverage the ability to define an external entity in a document type definition and reference that entity within the XML body processed by the server.

In a typical exploit, the attacker submits an XML payload that:

• Introduces a custom DOCTYPE section that defines an external entity pointing to a local file, such as system configuration or credential stores.
• References this entity within a field that GeoServer parses and processes, causing the XML parser to load the referenced resource.
• Relies on GeoServer’s response formatting to reflect the expanded entity back to the attacker, effectively exfiltrating the targeted data.

If outbound network access is permitted, an attacker can also define entities that point to internal HTTP services to perform server-side request forgery against internal management APIs, cloud metadata services, or other geospatial components that are not directly exposed to the internet.

Impact on Geospatial and Critical Infrastructure Environments

GeoServer is commonly deployed in national mapping agencies, municipal planning, utilities, telecommunications, and transportation sectors as a central component of spatial data infrastructure. In these environments, the XXE flaw can expose:

• Configuration files that include database connection strings, API keys, and embedded credentials for GIS backends.
• Project files and layer definitions that reveal network locations, internal topology, and data classification details.
• Underlying host system files that may leak user account details, service configuration, and log data useful for further intrusion.

Once sensitive credentials or network information are obtained, attackers can pivot to backend spatial databases, file shares storing high-value geospatial datasets, or adjacent application servers. In an operational technology or critical infrastructure context, detailed geospatial information combined with internal topology can materially increase the impact of follow-on attacks or reconnaissance.

CISA’s Known Exploited Vulnerabilities Inclusion and Deadlines

CISA’s decision to add CVE-2025-58360 to the Known Exploited Vulnerabilities catalog indicates confirmed, widespread exploitation against real targets. For United States federal civilian executive branch agencies, this listing typically carries a binding operational directive that establishes a fixed remediation deadline.

Agencies are required to:

• Identify all deployed GeoServer instances, including shadow IT and embedded components within larger GIS stacks.
• Patch or apply vendor-recommended mitigations by the prescribed due date.
• Report completion or any exceptions under their vulnerability management procedures.

Even for non-federal organizations, presence in this catalog signals that the vulnerability is likely being exploited at scale and should be treated as a high-priority risk rather than a theoretical software defect.

Detection and Incident Response Considerations

Detection is complicated by the fact that many XXE payloads resemble normal XML traffic, but several indicators can be used to identify active exploitation attempts and compromises.

From a network perspective, defenders should look for:

• Spike patterns in requests to GeoServer XML endpoints, especially from unfamiliar or distributed sources.
• Outbound HTTP or DNS connections from GeoServer hosts to unexpected external domains that could represent exfiltration channels for XXE payload responses.

On the host and application side, relevant signals include:

• Unusual error messages or stack traces in GeoServer logs referencing DTD parsing, entity resolution, or unexpected resource loading.
• Suspicious file access patterns by the GeoServer process, particularly reads of sensitive configuration locations not normally touched during standard operation.

If compromise is suspected, incident responders should:

• Capture and preserve GeoServer logs and relevant web server logs for forensic analysis.
• Rotate any credentials stored in GeoServer configuration or environment variables, including database users and API tokens.
• Assess backend systems accessed with those credentials for secondary compromise.

Patch Strategy and Hardening Measures

Organizations should prioritize upgrading GeoServer to fixed versions as recommended by the maintainers, ensuring that the vulnerable XML parsing code paths have been corrected. Patching must be validated across all instances, including development, testing, and production, to avoid leaving accessible legacy endpoints in place.

Beyond applying the specific patch, long-term mitigation should focus on:

• Reviewing GeoServer configuration to disable unused services and endpoints that accept arbitrary XML.
• Restricting network exposure by placing GeoServer behind reverse proxies or application firewalls and limiting direct internet access where practical.
• Implementing strict egress controls for GeoServer hosts to limit the ability of XXE payloads to reach external exfiltration servers.
• Conducting regular application security testing of spatial services, including checks for XXE, SSRF, and authentication weaknesses in OGC-compliant APIs.

Integrating GeoServer into centralized vulnerability scanning and configuration management baselines helps ensure that future critical advisories are detected and acted upon rapidly, rather than relying on ad hoc awareness within GIS teams.

SAP Releases December 2025 Security Updates Addressing Critical Enterprise Vulnerabilities

SAP’s December 2025 security updates introduce 14 new security notes, including three critical vulnerabilities affecting Solution Manager, Commerce Cloud, and the jConnect SDK. These flaws enable remote code execution and sensitive information exposure across widely deployed SAP landscapes, requiring rapid patching and rigorous validation in enterprise environments.

Scope of the December 2025 SAP Security Notes

The December release includes a combination of new and updated security notes spanning multiple SAP products. The headline items are three critical issues, each with high potential impact on core business processes and data confidentiality.

Typical SAP deployments involve tightly integrated application servers, middleware, and specialized components that share credentials and trust relationships. Consequently, exploitation of a single exposed component can provide an effective entry point into the broader landscape if not properly segmented and monitored.

Critical Vulnerability in SAP Solution Manager

One of the critical notes addresses a vulnerability in SAP Solution Manager, the central monitoring and lifecycle management platform used to administer many SAP estates. Solution Manager often has elevated privileges and broad visibility, making it a prime target for attackers.

The flaw reportedly allows an authenticated or partially authenticated user to execute arbitrary code or escalate privileges through a vulnerable service interface. In practice, this means that compromise of a lower-privileged account integrated into Solution Manager could be leveraged to:

• Deploy or modify custom code or scripts that run with higher privileges.
• Manipulate connected system configurations, including transport routes and monitoring agents.
• Access sensitive operational data and performance traces that may include credentials or business data.

Because Solution Manager is frequently connected to both production and non-production systems, this vulnerability can serve as a lateral movement facilitator across multiple SAP environments if left unaddressed.

Commerce Cloud Remote Exploitation Risks

Another critical note covers a serious vulnerability in SAP Commerce Cloud, the platform that underpins many large-scale e-commerce operations. In typical architectures, Commerce Cloud is internet-facing and directly processes customer traffic, making its attack surface widely accessible.

The issue relates to insufficient validation in a service or API exposed by Commerce Cloud, enabling an attacker to inject crafted data that results in remote code execution or unauthorized access to back-end services. Given the nature of e-commerce workloads, exploitation risks include:

• Exfiltration of customer data such as order history, personal details, and potentially payment-related information depending on integration patterns.
• Manipulation of pricing, discounts, or inventory data with direct financial impact.
• Deployment of web skimming or credential harvesting scripts to capture subsequent user sessions.

Because Commerce Cloud is often integrated with third-party payment providers, analytics platforms, and content delivery networks, attackers may also attempt to pivot into these auxiliary systems through compromised credentials or tokens stored within the Commerce configuration.

jConnect SDK Vulnerability and Application Ecosystems

The third critical issue affects the jConnect SDK, a Java-based connectivity component used by SAP systems and custom applications to interact with databases. Vulnerabilities in SDKs are particularly challenging because they can be embedded in a wide range of applications beyond core SAP products.

The flaw appears to expose systems to risks such as arbitrary code execution within the context of the application using the SDK or unauthorized access to database resources. For organizations, this means:

• Any custom-developed Java applications using vulnerable jConnect libraries must be identified, rebuilt, and redeployed with updated versions.
• Legacy applications that are no longer actively maintained may still contain the vulnerable SDK and continue to present a hidden risk.
• Central patching of SAP application servers alone is insufficient if dependent applications are not also addressed.

Security teams should treat the jConnect issue as a software supply chain problem and coordinate with development, application owners, and vendors to locate all usages of the affected libraries.

Patch Management and Change Control in SAP Environments

SAP systems are often change-controlled due to their central role in critical business processes, which can delay patch deployment. Nevertheless, critical notes such as those in the December 2025 batch require expedited handling through established emergency change procedures.

Effective remediation should include:

• Prioritizing Solution Manager and internet-facing Commerce Cloud components for immediate patching and verification.
• Implementing temporary compensating controls, such as tightening network access controls, enhancing logging, or restricting high-risk interfaces where patches cannot be applied instantly.
• Performing targeted regression testing that focuses on key business flows and integration points most likely to be affected by the updates.

Post-patch, organizations should validate that security notes are successfully implemented by confirming component versions and using available SAP security tools or scripts to verify configuration status.

Detection, Monitoring, and Hardening Recommendations

In parallel with patching, security operations teams should tune monitoring around the updated components. For Solution Manager, logging for administrative actions, transport changes, and script deployments should be reviewed and baselined to catch anomalies. For Commerce Cloud, web application firewall rules can be updated to detect and block exploit signatures or abnormal request patterns targeting known vulnerable endpoints.

For applications using the jConnect SDK, database access logs can help identify unusual query patterns, privilege escalations, or access from unexpected application identities that might indicate exploitation. Strong authentication and authorization at the database layer, combined with least-privilege principles for application accounts, can reduce the blast radius even if an application is compromised.

Over the longer term, organizations should integrate SAP security note monitoring into their continuous vulnerability management process and ensure that custom and third-party applications that rely on SAP components are tracked as part of software inventory and bill-of-materials efforts.

December 2025 Microsoft Security Updates Address Critical Windows and Server Vulnerabilities

Microsoft’s December 2025 security updates deliver patches for a broad set of Windows client and server products, Office components, and related services, including fixes for multiple critical remote code execution vulnerabilities. The update cycle underscores the need for disciplined patching, reboots, and layered defenses across enterprise fleets.

Scope of the December 2025 Patch Release

The December 2025 updates cover supported Windows operating systems, including desktop and server editions, as well as Microsoft Edge, Office, and selected cloud-connected services. Organizations are advised to deploy the latest cumulative updates that bundle individual fixes into a single, testable package per platform.

As is typical for year-end releases, the patch set includes both newly discovered vulnerabilities and refinements to previous fixes, addressing issues such as remote code execution in core services, privilege escalation in local components, and information disclosure through improperly secured subsystems.

Critical Remote Code Execution Vulnerabilities

Among the most severe issues in the December updates are remote code execution vulnerabilities affecting network-exposed services and content parsing components. These flaws can often be triggered via crafted network packets, specially formed files, or malicious web content that a user or system processes.

In many enterprise configurations, affected services may be reachable over internal networks, meaning that an attacker who breaches one segment could exploit these vulnerabilities to spread laterally without user interaction. In some cases, domain-joined hosts and servers supporting file and print, directory, or application services are at particular risk.

Because these vulnerabilities impact core operating system components, exploitation could lead to full system compromise, installation of persistent malware, credential theft, or use of the host as a launchpad for further attacks against domain controllers and other high-value systems.

Privilege Escalation and Lateral Movement Risks

The update set also remediates several elevation-of-privilege vulnerabilities in Windows subsystems. Although these issues may require initial code execution or a local user foothold, they are frequently combined with remote code execution or phishing to convert a low-privilege presence into full administrative control.

Common exploitation scenarios include:

• Leveraging a browser or document-based exploit to gain a limited user context and then invoking a local privilege escalation bug to obtain system-level access.
• Using compromised endpoints as a stepping stone to dump cached credentials, access password vaults, or pivot into administrative interfaces.
• Abusing vulnerable services running with elevated permissions to modify security settings, disable endpoint defenses, or install kernel-level drivers.

Given the prevalence of endpoint management tools and automation agents deployed with high privileges, timely patching is critical to prevent attackers from weaponizing these footholds for rapid lateral spread.

Patch Deployment and Reboot Requirements

The December guidance emphasizes that many of the patches require a system reboot to fully take effect. Applying updates without scheduling and completing reboots can leave systems in a partially patched state where vulnerable code remains in memory or active components are not replaced.

An effective deployment plan should:

• Use centralized management platforms such as WSUS, Configuration Manager, or equivalent tools to stage and roll out updates in waves.
• Define and enforce maintenance windows for servers and critical workstations to ensure that reboots occur within a defined time frame after patch installation.
• Track patch and reboot status, focusing on exceptions such as servers configured for high availability or systems that repeatedly fail to apply updates.

Organizations running mission-critical workloads should employ staggered deployments and validation checks but avoid indefinite deferral, especially for vulnerabilities rated as critical or under active exploitation.

Mitigation Strategies When Immediate Patching Is Not Possible

In environments where immediate patching is constrained by compatibility concerns or operational requirements, administrators should apply temporary risk reduction measures tailored to the specific vulnerabilities addressed by the December release.

Such measures may include:

• Restricting network exposure of affected services by closing unneeded ports or limiting access to trusted segments through firewall rules.
• Increasing monitoring of suspicious events related to vulnerable components, such as anomalous process launches, access to sensitive resources, or unexpected service behavior.
• Enforcing strong least-privilege policies, ensuring users and services have only the access required to perform their roles, thereby constraining potential impact.

These mitigations should be viewed as temporary and regularly revisited, with a clear plan to complete patch installation once necessary testing or planning is finished.

Operational Best Practices for Ongoing Microsoft Patch Cycles

The December updates highlight the ongoing need for structured patch management around monthly release cycles. Effective practices include:

• Maintaining accurate inventories of Windows and Microsoft workloads to ensure full visibility into patch scope.
• Implementing dedicated test environments that mirror production configurations for rapid validation of cumulative updates.
• Integrating vulnerability scanning and endpoint detection data to prioritize remediation of systems that are exposed and at higher risk.

By combining timely installation of monthly updates with robust configuration baselines, application control, and identity protection, organizations can substantially reduce the attack surface presented by Microsoft platforms and respond more effectively when new high-impact vulnerabilities are disclosed.