Search Results (4 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-44258 1 Efwgrp 1 Efw4.x 2026-05-13 N/A
efw4.X is an Enterprise Framework for Web. Prior to 4.08.010, the elfinder_checkRisk function validates target and targets for path traversal and home containment, but does not validate the dst (destination) parameter used by elfinder_paste. An attacker can copy or move files from within the home directory to any arbitrary destination by setting dst to a base64-encoded traversal path. This bypasses the protected=true security control. This vulnerability is fixed in 4.08.010.
CVE-2026-44257 1 Efwgrp 1 Efw4.x 2026-05-13 N/A
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.
CVE-2026-44259 1 Efwgrp 1 Efw4.x 2026-05-13 4.6 Medium
efw4.X is an Enterprise Framework for Web. Prior to 4.08.010, the previewServlet serves files with their detected MIME type based on file extension, without any content sanitization or security headers. Files with .html, .htm, or .svg extensions are served as text/html or image/svg+xml respectively, causing any embedded JavaScript to execute in the victim's browser within the application's origin. This vulnerability is fixed in 4.08.010.
CVE-2026-44260 1 Efwgrp 1 Efw4.x 2026-05-13 8.1 High
efw4.X is an Enterprise Framework for Web. Prior to 4.08.010, the readonly flag set on the <efw:elFinder> JSP tag is intended to prevent file modifications. When protected=true, elfinder_checkRisk enforces that the client sends readonly=true (matching the session value), but no event handler checks the readonly value before performing write operations. The flag only controls client-side UI elements (disabling buttons) and response metadata (write: 0, locked: 1). An attacker who sends requests directly (bypassing the UI) can perform all file operations despite readonly=true. This vulnerability is fixed in 4.08.010.