CVE-2026-2818 & CVE-2026-2817: Path Traversal and Insecure Temp Files in Spring Data Geode

Spring Data Geode may not be the most talked-about library in the Spring ecosystem, but for the enterprises that depend on it, particularly those still using Spring Boot 2.7 to manage dependencies, two newly disclosed vulnerabilities demand immediate attention. CVE-2026-2818 (High severity) and CVE-2026-2817 (Medium severity) both target the library's snapshot import feature, and both have been patched by HeroDevs in NES for Spring.

Here is a breakdown of what these vulnerabilities are, why Spring Data Geode is still in production at many organizations, and what your options are now that the project has reached end of life.

‍

What Is Spring Data Geode, and Why Is It Still in Use?

Spring Data Geode (and its predecessor, Spring Data GemFire) provides the Spring-based configuration and programming model for Apache Geode and Pivotal GemFire. These are in-memory data grids used heavily in financial services, telecommunications, and other latency-sensitive environments for distributed caching, real-time event processing, and session management.

Despite reaching end of life, Spring Data Geode remains embedded in many enterprise systems for several reasons:

• Migration complexity: Applications built on Geode-backed caching or session clustering are tightly coupled to Geode's APIs. Replacing them often means rearchitecting significant portions of the data tier.
• Stability bias: Teams running stable, revenue-critical workloads on Geode see little incentive to migrate until a forcing event (like a CVE) arrives.
• Transitive dependencies: Spring Data Geode often appears as a transitive dependency pulled in through Spring Boot starters or internal platform libraries, meaning teams may not even realize it is in their dependency tree.
• Regulatory lock-in: Particularly in financial services and government, change control processes are slow. Moving off a known, tested stack requires extensive validation.

The result is a large installed base of EOL software that no longer receives community security patches, precisely the scenario where vulnerabilities go unaddressed the longest.

‍

CVE-2026-2818: Path Traversal via Zip-Slip (High Severity)

Category: Path Traversal
Affected packages: spring-data-geode, spring-data-gemfire
Affected versions: >=1.7.0 <=2.2.13, >=2.0.0 <=2.7.18
Published: February 20, 2026
Credit: Joe Kuhel, HeroDevs

The Vulnerability

This is a classic zip-slip attack targeting the snapshot import feature. When a ZIP or JAR archive is imported as a Geode snapshot, the library sanitizes filenames by stripping directory components using the platform's native path separator.

On Linux and macOS, the native separator (/) matches the ZIP specification, so sanitization works correctly. On Windows, the native separator (\) does not match the forward slashes used in ZIP entries. This means path traversal sequences like ../../../../ pass through undetected. An attacker who can supply a crafted archive for snapshot import can write files to arbitrary locations accessible by the application.

‍

Impact

If the following conditions are met, the application is vulnerable:

1. The application runs on Windows.
2. The application imports an attacker-controlled ZIP or JAR archive.
3. The application has write permissions to the target paths.

Successful exploitation could lead to arbitrary file writes, enabling code execution, data corruption, or persistence through startup scripts.

Interim Mitigations

• Validate the integrity and origin of all snapshot archives before importing.
• Never import snapshot archives from untrusted sources.
• Run the application with minimal filesystem permissions to limit the blast radius.

‍

CVE-2026-2817: Insecure Temporary File Handling (Medium Severity)

Category: Creation of Temporary File in Directory with Insecure Permissions
Affected packages: spring-data-geode, spring-data-gemfire
Affected versions: >=1.7.0 <=2.2.13, >=2.0.0 <2.7.18
Published: February 19, 2026
Credit: Jonathan Leitschuh (@JLLeitschuh)

The Vulnerability

When Spring Data Geode imports a ZIP or JAR archive for snapshot import, it extracts the archive contents to a temporary directory. The directory name is predictable (derived from the archive filename), uses default system permissions (typically world-readable), and no cleanup of extracted files is performed after import.

This enables a local user to enumerate predictable temp directory names and read sensitive Geode or GemFire cache data exported by another user on the same system.

Impact

On multi-tenant or shared systems, this is a local information disclosure vulnerability. Any user on the same host can read extracted snapshot data, which may include cached application data, session state, or other sensitive information stored in the Geode region.

Interim Mitigations

• Set the Java temp directory to a user-private location using -Djava.io.tmpdir.
• Clean up temporary snapshot directories immediately after imports.
• Restrict filesystem permissions on the system temp directory where possible.

‍

Why These CVEs Matter More Than They Appear

At first glance, these may seem like narrow, conditional vulnerabilities. CVE-2026-2818 requires Windows and an attacker-supplied archive. CVE-2026-2817 requires local access and shared hosting. But in practice, the conditions are more common than they seem:

Enterprise Windows deployments are widespread. Many organizations, particularly in financial services and government, run Spring applications on Windows Server. The zip-slip vulnerability is a direct threat in those environments.

Shared infrastructure is the norm. CI/CD runners, staging environments, and containerized workloads on shared Kubernetes nodes all create scenarios where CVE-2026-2817's local information disclosure becomes exploitable.

Compliance frameworks treat unpatched CVEs as findings. SOC 2, PCI DSS, FedRAMP, and the EU Cyber Resilience Act all require organizations to demonstrate timely remediation of known vulnerabilities. An unpatched High-severity CVE in an EOL library is exactly the kind of finding that auditors flag.

Scanners will surface these. Whether your organization uses Snyk, Dependabot, Grype, or another SCA tool, these CVEs will appear in scan results. Without a patched version to point to, the finding remains open.

‍

The EOL Problem: No Community Patches Available

Here is the core challenge: Spring Data Geode and Spring Data GemFire have reached end of life. The open-source community no longer provides security patches for these libraries. That means the versions listed in these CVEs (spanning from 1.7.0 through 2.7.18) will remain vulnerable indefinitely in the public Maven repositories.

Organizations that depend on Spring Data Geode have three options:

1. Migrate away from Spring Data Geode. This is the long-term correct answer, but it requires significant engineering effort. Replacing an in-memory data grid is not a weekend project.
   
   
2. Accept the risk. Some teams will evaluate the conditions and determine the risk is tolerable. This may be true for internal-only Linux deployments with no snapshot import from untrusted sources, but it does not resolve the compliance dimension.
   
   
3. Adopt a commercial support solution. NES for Spring from HeroDevs provides secure, drop-in replacement packages for end-of-life Spring libraries, including Spring Data Geode. Both CVE-2026-2817 and CVE-2026-2818 have been patched in the NES release, giving teams a remediated artifact they can point to in scan results and audit reports.

‍

How NES for Spring Addresses These Vulnerabilities

HeroDevs' Never-Ending Support for Spring delivers patched versions of spring-data-geode and spring-data-gemfire through private Maven repositories. The fix is a drop-in replacement: no code changes, no API breaks, no migration required.

For CVE-2026-2818, the NES release corrects the filename sanitization logic to properly handle forward-slash path separators on Windows, eliminating the zip-slip vector. For CVE-2026-2817 the NES release allows you to define a temp directory with restricted permissions and performs cleanup after import.

Switching to NES packages takes minutes. You point your build configuration (Maven, Gradle) to the HeroDevs private registry, and the patched artifacts resolve in place of the vulnerable community versions. SBOMs and VEX documents are available for organizations that need to demonstrate compliance.

‍

What to Do Right Now

If Spring Data Geode or Spring Data GemFire appears in your dependency tree:

1. Check your versions. Run mvn dependency:tree or gradle dependencies and look for spring-data-geode or spring-data-gemfire in the affected version ranges.
   
   
2. Assess your exposure. Are you running on Windows? Do you import snapshots from external sources? Is the application on shared infrastructure?
   
   
3. Evaluate your remediation path. If migration is months away, NES for Spring provides immediate coverage. Contact HeroDevs to get access to patched packages.
   
   
4. Update your SBOM. Once you have moved to the NES release, regenerate your SBOM and VEX documents to reflect the remediated state.
   
   

These vulnerabilities are a reminder that end of life does not mean end of risk. As long as EOL software remains in production, new vulnerabilities will continue to surface, and the organizations running that software need a plan for addressing them.

For full technical details, see the CVE-2026-2818 and CVE-2026-2817 entries in the HeroDevs Vulnerability Directory.

‍

FAQ

What are CVE-2026-2818 and CVE-2026-2817?These are two security vulnerabilities discovered in Spring Data Geode and Spring Data GemFire, both affecting the libraries' snapshot import feature. CVE-2026-2818 is a High-severity path traversal vulnerability (zip-slip) that allows arbitrary file writes on Windows systems. CVE-2026-2817 is a Medium-severity vulnerability involving insecure temporary file handling that can expose sensitive cached data on shared or multi-tenant systems.

Which versions of Spring Data Geode are affected?CVE-2026-2818 affects versions ≥1.7.0 ≤2.2.13 and ≥2.0.0 ≤2.7.18. CVE-2026-2817 affects versions ≥1.7.0 ≤2.2.13 and ≥2.0.0 <2.7.18. Both spring-data-geode and spring-data-gemfire packages are impacted.

Do I need to be running Windows to be vulnerable?For CVE-2026-2818 (zip-slip), yes — the path traversal exploit is Windows-specific due to how Windows handles path separators differently than the ZIP specification. CVE-2026-2817, however, affects any operating system where Spring Data Geode runs on shared or multi-tenant infrastructure.

Why aren't community patches available for these CVEs?Spring Data Geode has reached end of life, meaning the open-source maintainers no longer release security patches. Affected versions in public Maven repositories will remain vulnerable indefinitely unless organizations migrate or adopt a commercial support solution.

How does HeroDevs NES for Spring fix these vulnerabilities?NES for Spring delivers patched drop-in replacement artifacts for spring-data-geode and spring-data-gemfire through a private Maven registry. No code changes or API migrations are required — you update your build configuration to point to the HeroDevs registry, and patched versions resolve in place of the vulnerable community packages.

Will these CVEs show up in my security scans?Yes. SCA tools including Snyk, Dependabot, Grype, and others will surface these CVEs against affected version ranges. Without a patched artifact to reference, the findings will remain open. NES packages give you a remediated version to resolve scan findings and satisfy auditor requests.

What compliance frameworks require me to address these?SOC 2, PCI DSS, FedRAMP, and the EU Cyber Resilience Act all require timely remediation of known vulnerabilities. An unpatched High-severity CVE in an EOL dependency is a common audit finding. NES for Spring also provides SBOMs and VEX documents to support compliance documentation.

How do I know if Spring Data Geode is in my dependency tree?
Run mvn dependency:tree or gradle dependencies and search for spring-data-geode or spring-data-gemfire. It often appears as a transitive dependency pulled in through Spring Boot starters or internal platform libraries, so teams may not realize it's present until a scan surfaces it.

‍