dbcve.org
Command InjectionWeakness · CWE-77

CVE-2026-44257

CRITICAL · 9.3 CVSS v4.0 Published 2026-05-12
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
efw4.X is an Enterprise Framework for Web. Prior to 4.08.010, efw.file.FileManager.unZip writes zip entries to disk using new File(baseDir, zipEntry.getName()) with no canonical-path check. An entry name such as ../../../pwned.jsp escapes the intended extraction directory and lands anywhere the Tomcat process can write — including the servlet context root. Combined with the framework's multipart /uploadServlet and an event that calls file.saveUploadFiles + FileManager.unZip, a remote attacker with no credentials drops a JSP webshell and executes arbitrary commands as the Tomcat user. This vulnerability is fixed in 4.08.010.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A path traversal vulnerability in efw4.X's FileManager.unZip function allows zip slip attacks. The code writes zip entries using new File(baseDir, zipEntry.getName()) without validating canonical paths, enabling entries like ../../../pwned.jsp to escape the intended extraction directory. Combined with the framework's /uploadServlet multipart endpoint and file.saveUploadFiles event, unauthenticated remote attackers can drop and execute JSP webshells, achieving RCE as the Tomcat user.

MitigationUpgrade to efw4.X version 4.08.010 or later which includes canonical-path validation in FileManager.unZip. If immediate upgrade is infeasible, disable the /uploadServlet endpoint or block the file.saveUploadFiles event triggering.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
Authentication
X
User interaction
None
Scope
X

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify efw4.X installation
    Locate the efw4.X framework installation directory and check for FileManager.class or similar core library files. Look for version information in build files, manifest files, or version.properties within the application WEB-INF or lib directories.
    Affected if The system is running efw4.X framework and the vulnerable FileManager.unZip function exists in the codebase.
  2. Determine installed version
    Check the version file or build metadata within the efw4.X installation. Common locations include version.properties, MANIFEST.MF, or a version.txt in the WEB-INF or root directory. Compare the version number to 4.08.010.
    Affected if The installed version is lower than 4.08.010, meaning canonical-path validation is not present in FileManager.unZip.
  3. Verify /uploadServlet endpoint is exposed
    Test for the presence of /uploadServlet by making a HEAD or OPTIONS request to the application's base URL with /uploadServlet appended. Check web.xml or equivalent deployment descriptor for servlet mappings to uploadServlet.
    Affected if The /uploadServlet endpoint is accessible and accepts multipart file uploads without additional authentication beyond basic auth.
  4. Confirm file.saveUploadFiles event is enabled
    Examine the efw4.X configuration files (typically in conf/ or config/ directories) for event handler definitions. Look for entries containing 'file.saveUploadFiles' or 'saveUploadFiles' to determine if this event handler is active.
    Affected if The file.saveUploadFiles event handler is configured and enabled, allowing uploaded files to be processed by the vulnerable unzip functionality.

The environment is affected if running efw4.X with a version lower than 4.08.010 where the /uploadServlet endpoint is exposed and the file.saveUploadFiles event is enabled, allowing the path traversal in FileManager.unZip to be exploited for RCE.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to efw4.X version 4.08.010 or later which includes canonical-path validation in FileManager.unZip. If immediate upgrade is infeasible, disable the /uploadServlet endpoint or block the file.saveUploadFiles event triggering.

Recommended fix High confidence

4.08.010

  1. Identify all deployed instances running efw4.X versions prior to 4.08.010
  2. Obtain the efw4.X version 4.08.010 release package from the vendor's official distribution channel
  3. Review release notes for version 4.08.010 to confirm the canonical-path check fix addresses the FileManager.unZip path traversal vulnerability
  4. Schedule a maintenance window for the upgrade, considering this is a critical remote code execution vulnerability
  5. Back up all application configuration files, deployed applications, and any custom code before proceeding
  6. Deploy version 4.08.010 to all affected Tomcat instances running efw4.X
  7. Verify the upgrade was successful by checking the efw4.X version information
  8. Test that the FileManager.unZip functionality works correctly with the updated version

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation4.0 h
  • Implementation4.0 h
  • Testing4.0 h
  • Review / QA3.0 h
15.0 hours of engineering $2,660
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,256.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-44257 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-44257 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data