ghsa

**Summary** A command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler. **Root cause** The `commitHash` variable, derived from user input via the `--commit-hash` CLI argument, is interpolated directly into a shell command using template literals (e.g., ``execSync(`git show -s --format=%B ${commitHash}`)``). Shell metacharacters are interpreted by the shell, enabling command execution. **Impact** This vulnerability is generally hard to exploit, as it requires `--commit-hash` to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the `--commit-hash` parameter is populated from external, potentially u...

### Impact Unauthenticated denial of service. ### Summary When installing module packages from attacker-controlled sources, `tofu init` may cause high CPU usage when encountering maliciously-crafted `.zip` archives for either provider or module distribution packages. Those who depend on modules or providers served from untrusted third-party servers may experience denial of service due to `tofu init` failing to complete in a timely manner. Other processes running on the same computer as OpenTofu may also have their performance degraded due to the high CPU usage. These vulnerabilities **do not** permit arbitrary code execution or allow disclosure of confidential information. ### Details OpenTofu relies on a third-party implementation of `.zip` archive extraction from the standard library of the Go programming language. The Go project has recently published a minor release (Go 1.25.6) to address a problem of potential excessive CPU usage when accessing files in a maliciously-crafted ...

In affected versions of Triton VM, the verifier failed to correctly sample randomness in the FRI sub-protocol. Malicious provers can exploit this to craft proofs for arbitrary statements that this verifier accepts as valid, undermining soundness. Protocols that rely on proofs and the supplied verifier of the affected versions of Triton VM are completely broken. Protocols implementing their own verifier might be unaffected. The flaw was corrected in commit 3a045d63, where the relevant randomness is sampled correctly.

### Impact The `FetchUrlReader` component, used by the catalog and other plugins to fetch content from URLs, followed HTTP redirects automatically. This allowed an attacker who controls a host listed in `backend.reading.allow` to redirect requests to internal or sensitive URLs that are not on the allowlist, bypassing the URL allowlist security control. This is a Server-Side Request Forgery (SSRF) vulnerability that could allow access to internal resources, but it does not allow attackers to include additional request headers. ### Patches This vulnerability is fixed in `@backstage/backend-defaults` version 0.12.2, 0.13.2, 0.14.1, and 0.15.0. Users should upgrade to this version or later. ### Workarounds - Restrict `backend.reading.allow` to only trusted hosts that you control and that do not issue redirects - Ensure allowed hosts do not have open redirect vulnerabilities - Use network-level controls to block access from Backstage to sensitive internal endpoints ### References - ...

### Impact The `resolveSafeChildPath` utility function in `@backstage/backend-plugin-api`, which is used to prevent path traversal attacks, failed to properly validate symlink chains and dangling symlinks. An attacker could bypass the path validation by: 1. **Symlink chains**: Creating `link1 → link2 → /outside` where intermediate symlinks eventually resolve outside the allowed directory 2. **Dangling symlinks**: Creating symlinks pointing to non-existent paths outside the base directory, which would later be created during file operations This function is used by Scaffolder actions and other backend components to ensure file operations stay within designated directories. ### Patches This vulnerability is fixed in `@backstage/backend-plugin-api` version 0.1.17. Users should upgrade to this version or later. ### Workarounds - Run Backstage in a containerised environment with limited filesystem access - Restrict template creation to trusted users

### Impact Multiple Scaffolder actions and archive extraction utilities were vulnerable to symlink-based path traversal attacks. An attacker with access to create and execute Scaffolder templates could exploit symlinks to: 1. **Read arbitrary files** via the `debug:log` action by creating a symlink pointing to sensitive files (e.g., `/etc/passwd`, configuration files, secrets) 2. **Delete arbitrary files** via the `fs:delete` action by creating symlinks pointing outside the workspace 3. **Write files outside the workspace** via archive extraction (tar/zip) containing malicious symlinks This affects any Backstage deployment where users can create or execute Scaffolder templates. ### Patches This vulnerability is fixed in the following package versions: - `@backstage/backend-defaults` version 0.12.2, 0.13.2, 0.14.1, 0.15.0 - `@backstage/plugin-scaffolder-backend` version 2.2.2, 3.0.2, 3.1.1 - `@backstage/plugin-scaffolder-node` version 0.11.2, 0.12.3 Users should upgrade to these ...

### Impact Timing side-channel vulnerability in verify_key(). The method applied a random delay only on verification failures, allowing an attacker to statistically distinguish valid from invalid API keys by measuring response latencies. With enough repeated requests, an adversary could infer whether a key_id corresponds to a valid key, potentially accelerating brute-force or enumeration attacks. Affected: all users relying on verify_key() for API key authentication prior to the fix. ### Patches Yes. Users should upgrade to version 1.1.0 (or the version containing this fix). The patch applies a uniform random delay (min_delay to max_delay) to all responses regardless of outcome, eliminating the timing correlation. ### Workarounds - Add an application-level fixed delay or random jitter to all authentication responses (success and failure) before the fix is applied. - Use rate limiting to reduce the feasibility of statistical timing attacks. ### References - CWE-208: Observable Timin...

A privilege escalation vulnerability exists in the Flux Operator Web UI authentication code that allows an attacker to bypass Kubernetes RBAC impersonation and execute API requests with the operator's service account privileges. After OIDC token claims are processed through CEL expressions, there is no validation that the resulting `username` and `groups` values are non-empty. When both values are empty, the Kubernetes client-go library does not add impersonation headers to API requests, causing them to be executed with the flux-operator service account's credentials instead of the authenticated user's limited permissions. ### Impact - **Privilege Escalation**: Any authenticated user can escalate to operator-level read permissions and perform suspend/resume/reconcile actions - **Data Exposure**: Unauthorized read access to Flux resources across all namespaces, bypassing RBAC restrictions - **Information Disclosure**: View sensitive GitOps pipeline configurations, source URLs, and de...

### Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently write to arbitrary directories outside the destination path by using directory a symlink along with [`_preserve_symlinks: true`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) and a [generated directory structure](https://copier.readthedocs.io/en/stable/configuring/#generating-a-directory-structure) whose rendered path is inside the symlinked directory. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc. > [!NOTE] > > At the time of writing, the exploit is non-deterministic, as Copier walks the template's file tree using [`os.scandir`](...

### Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently include arbitrary files/directories outside the local template clone location by using symlinks along with [`_preserve_symlinks: false`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) (which is Copier's default setting). Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations and hopes for a user to push the generated project to a public location like [github.com](https://github.com/) where the template author can extract the secrets. Reproducible example: - Illegally include a file in the generated project via symlink resolution: ```shell echo "s3cr3t" > se...