Grafana Alloy’s prometheus.operator.servicemonitors component allows a user who can create or modify ServiceMonitor resources in a watched namespace to specify an arbitrary local file through bearerTokenFile. Alloy reads the file and sends its contents as a bearer token to an attacker-controlled scrape endpoint. This may disclose files accessible to the Alloy process, including its projected Kubernetes service account token, potentially granting the attacker Alloy’s Kubernetes permissions. Exploitation requires ServiceMonitor write access and lower privileges than Alloy’s service account.

Halloy is an IRC application written in Rust. Prior to commit 0f77b2cfc5f822517a256ea5a4b94bad8bfe38b6, the DCC receive flow did not sanitize filenames from incoming `DCC SEND` requests. A remote IRC user could send a filename with path traversal sequences like `../../.ssh/authorized_keys` and the file would be written outside the user's configured `save_directory`. With auto-accept enabled this required zero interaction from the victim. Starting with commit 0f77b2cfc5f822517a256ea5a4b94bad8bfe38b6, all identified code paths sanitize filenames through a shared `sanitize_filename` function.

Halloy is an IRC application written in Rust. In versions on \*nix and macOS prior to commit f180e41061db393acf65bc99f5c5e7397586d9cb, halloy creates its config directory and files using default umask permissions, which typically results in `0644` on files and `0755` on directories. This allows any local user on the system to read plaintext credentials stored in `config.toml` or referenced `password_file` paths. Commit f180e41061db393acf65bc99f5c5e7397586d9cb patches the issue.