TL;DR

A path traversal vulnerability in an official eml-parser example script allows arbitrary file write. This can be escalated to Remote Code Execution (RCE) depending on the execution environment.

Overview

While analyzing the example script provided by eml-parser, I identified a path traversal issue in how attachment filenames are handled.

The script directly uses user-controlled filenames when writing files to disk, without any sanitization or restriction.

Vulnerable Code

None

The vulnerable logic is straightforward:

  • Attachment filename is directly used
  • Path is constructed using out_path / filename
  • No validation is applied

This allows path traversal via ../.

Root Cause

The root cause is the absence of filename sanitization.

User-controlled input flows directly into file system operations:

User input → filename → path join → file write

No checks are performed to ensure the file remains within the intended directory.

Proof of Concept

Malicious .eml File

None

The attacker injects a crafted filename:

../outside/pwned.txt

Execution

None
python poc.py -p . -o ./safe

Observed behavior:

Writing attachment to safe/../outside/pwned.txt

Result

None

The file is written outside the intended directory:

outside/pwned.txt

This confirms successful path traversal.

Impact

This vulnerability allows

  • Arbitrary file write
  • Overwriting existing files
  • Writing files to sensitive locations

In real-world scenarios, this can lead to:

  • Web shell placement
  • Persistence mechanisms
  • Remote Code Execution (RCE)

Turning This Into RCE

If the application runs in a web server environment:

  1. Attacker writes file to web root
  2. File becomes accessible via HTTP
  3. Attacker executes code remotely

example:

/var/www/html/shell.py

Access:

http://target/shell.py

Patch Analysis

None

The patch introduces

  • Path.resolve() to normalize paths
  • Path.name to strip directory components

Example fix

attachment_filename = pathlib.Path(a['filename']).name
out_filepath = out_path / attachment_filename

This prevents traversal by removing ../

Why This Is Interesting

This issue exists in an example script, not the core library.

하지만

  • Example code is often reused in production
  • Developers assume it is safe
  • Security checks are frequently omitted

This makes such vulnerabilities particularly dangerous.

Key Insight

Even simple file write operations become dangerous when combined with user-controlled input.

The difference between a harmless bug and RCE is often just execution context.

Conclusion

This vulnerability demonstrates how a lack of basic input validation can lead to significant security risks.

Although it may appear as a medium-severity issue, its real-world impact can be much higher.

Contribution

  • Identified path traversal in example script
  • Developed working PoC
  • Demonstrated arbitrary file write
  • Analyzed potential RCE impact

Author

redyank

GitHub: https://github.com/redyank

Team: https://redpoc.github.io/