# Worker container escape lead to arbitrary file reading in host machine [again]

Symlinking .lgtm.yml to a host file in an LGTM build project caused the post-build file viewer to expose host machine file contents.

- Payout: $2,000
- Severity: critical
- Program: Semmle
- Credited: testanull
- Disclosed: 2019-10-21
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/697055
- Library page: https://bugbountylibrary.com/r/h1%3A697055
- Tags: domain:cloud domain:infra impact:data-leak impact:internal-access kind:bounty platform:hackerone sev:critical technique:chained vuln:info-disclosure vuln:path-traversal vuln:privilege-escalation

**Target:** LGTM build/extraction pipeline and post-build file viewer (lgtm-com.pentesting.semmle.net)
**Root cause:** LGTM processes lgtm.yml and skips .lgtm.yml but retains both in the directory; a symlink named .lgtm.yml pointing to a host path is followed when the file list/content is served after build.
**Steps:**
1. Create a project that builds successfully on LGTM.
2. Add `lgtm.yml` with valid config, e.g. `extraction: java: index: build_command: - ./custom-build`.
3. Create a symlink named `.lgtm.yml` pointing to a host file/directory (e.g. `/etc/passwd`).
4. Trigger a successful build.
5. View the file list/content; `.lgtm.yml` now contains host machine file contents.
**How found:** Noticed LGTM keeps both lgtm.yml and .lgtm.yml in the directory but only processes lgtm.yml, leaving .lgtm.yml as an attacker-controllable entry that the viewer later reads.
**Exploitation:** Attacker controls repo contents; by naming a symlink `.lgtm.yml` and pointing it at a host path, the post-build file viewer dereferences it and returns host file contents to the attacker.
**Insight:** When a build system keeps but ignores a config file, try symlinking that ignored filename to host paths; the post-build artifact viewer may dereference it outside the container.