# World-writable permissions on sensitive paths

Archive extraction or daemon umask leaving world-writable files on paths later loaded as code or config

_Area: Web infrastructure and server-side requests. Seen in 3 disclosed reports; 3 confirmed bounties, median $2,400, range $500-$4,660; latest 2023-08-15. Updated 2026-10-23._

## How it works
A tool creates or extracts files on a path that is later trusted as code or configuration, but it does not apply the process umask or a safe default mode. The permission bits come from the archive, from a daemon's umask 0, or from a default install path that happens to be user-writable. The broken assumption is that the sensitive path is only writable by its owner. When any local user can write there, they can substitute content the victim process will load and execute.

## Where it shows up
- Archive/package extraction that copies stored mode bits instead of masking with umask [E1](https://bugbountylibrary.com/r/h1%3A2094785.md)
- Daemons started with `--daemon` that set umask 0, creating world-writable logs and directories [E2](https://bugbountylibrary.com/r/h1%3A1690093.md)
- Log or cache paths that are followed as symlinks into code-executed locations [E2](https://bugbountylibrary.com/r/h1%3A1690093.md)
- Cross-compiled defaults mapping Unix paths like `/usr/local` to user-creatable Windows paths such as `C:/usr/local` [E3](https://bugbountylibrary.com/r/h1%3A683318.md)
- Config, plugin, or engine search paths pointing at writable directories [E3](https://bugbountylibrary.com/r/h1%3A683318.md)

## How to review
Identify every path the process later reads as code or config (caches, logs, config dirs, plugin/engine paths). For each, check the actual mode of created files and directories: does extraction apply umask, does the daemon set a restrictive umask, is the default path owner-only? The invariant: no file or directory on a code/config load path may be writable by users other than the owning service account. Run a permission sweep (`find -perm -002`) over build caches and install prefixes. Confirm symlinks are not followed into executed paths.

## Variants seen
- Package manager extraction preserving world-writable bits, poisoning cached dependency source [E1](https://bugbountylibrary.com/r/h1%3A2094785.md)
- Daemon umask 0 plus symlink race on log files to inject DAG code [E2](https://bugbountylibrary.com/r/h1%3A1690093.md)
- Build-time default install prefix resolving to a writable Windows directory, enabling config/engine planting [E3](https://bugbountylibrary.com/r/h1%3A683318.md)

## Impact and severity
All three led to local code execution as the victim user or service. Severity is high because the attacker needs only local access, and the poisoned artifact executes on the next build, daemon start, or config load. It worsens when the writable path feeds a privileged service or a shared build cache used by many.

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A2094785.md
- E2: https://bugbountylibrary.com/r/h1%3A1690093.md
- E3: https://bugbountylibrary.com/r/h1%3A683318.md