#git

Security teams at agile, fast-growing companies often have the same mandate: secure the business without slowing it down. Most teams inherit a tech stack optimized for breakneck growth, not resilience. In these environments, the security team is the helpdesk, the compliance expert, and the incident response team all rolled into one. Securing the cloud office in this scenario is all about

### Impact _What kind of vulnerability is it? Who is impacted?_ This issue impacts every Soft Serve instance. A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Yes, please upgrade to version 0.11.3 as soon as possible. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ You need to upgrade

**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 ...

### 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...