[0day-rubbish] FME Flow 2026.2 Zip-Slip arbitrary file write to code execution as LocalSystem (8.8)

[disclosure via Fulldisclosure <fulldisclosure () seclists org>]

0day Rubbish Research Team is publicly disclosing a vulnerability in Safe
Software FME Flow 2026.2 build 26333.

Type: path-traversal write inside archive extraction (Zip-Slip) in
COM.safe.web.upload.StoreManager.extract(), shipped in
clients-webservicesutil-1.0.jar (CWE-22). The sink builds each destination path
from ZipArchiveEntry.getName() verbatim; commons-compress 1.26.2 does not
normalise "..", and the class's own canonical containment check isPathValid() is
called only from the constructor, never from the extraction path.

Scoring. This finding is dual-scored, and the conditional figure is a
non-default configuration that is published alongside the primary, not instead
of it:
- PRIMARY, 8.8 High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. This is the
  post-authentication rating: any authenticated user, including the
  low-privilege fmeuser and fmeguest roles, can drive it. The upload branch that
  sets opt_extractarchive=true performs no role or isPermitted check.
- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This
  applies only where a public app is published with requireAuthentication=false
  and allowTemporaryUploads=true, which is NOT a shipped default. The 9.8 figure
  is conditional and is not the headline.

Impact: arbitrary file write anywhere the Tomcat process can write, outside the
upload sandbox (create-only; an existing destination file is neither truncated
nor overwritten). On a default single-machine Windows install the repository root
and WEBAPPSDIR share one ancestor volume, so the write reaches an expanded web
application's document root; with unpackWARs=true, no /* servlet mapping in
fmeserver.war, and Tomcat installed as the FMEFlowAppServer service running as
.\LocalSystem, requesting the dropped .jsp yields command execution as
LocalSystem. This is a low-privilege-to-LocalSystem escalation.

Authentication: authenticated (any valid token; no role check on the archive
extraction branch).

Verification boundary, stated plainly. We verified the vulnerable code itself,
not a deployed installation. A harness compiled against the exact jars that ship
with FME Flow 2026.2 called the real StoreManager.extract on a Linux lab host
against Tomcat 10.1.42 on loopback; a zip entry name carrying enough "../"
wrote a .jsp outside the sandbox and the container then compiled and executed
it (marker recorded uid=0 on the Linux host). A complete Windows FME Flow
installation was NOT deployed (it requires PostgreSQL plus a product licence), so
the end-to-end HTTP delivery chain rests on the decompiled source rather than on
a live run against the product. On Windows the Tomcat service identity is
.\LocalSystem, established from installer artefacts (configureTomcat.bat and the
MSI property FMEFLOWUSER=LocalSystem) rather than observed; the expected
production marker is whoami = nt authority\system.

This is distinct from the previously published HTTP path-traversal fixes in this
product, whose ".." sequences travel in the request URL and are collapsed by the
container's normalisation. Here the traversal travels inside zip entry names in
the request body, which URL normalisation never inspects, so those fixes do not
cover this vector.

Full technical analysis and a reproducible proof-of-concept:
  https://0day-rubbish.com/blog/fme-flow-zipslip-arbitrary-file-write-rce

Project archive (ongoing disclosure series):
  https://github.com/Exploit-Garbage/0day-Rubbish

The vendor has been notified through its published security contact. No vulnerability identifier has been assigned to
this finding yet.

--
0day Rubbish Research Team
disclosure () 0day-rubbish com
https://0day-rubbish.com
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/