ghsa

Hello Kubernetes Community, A security issue was discovered in secrets-store-sync-controller where an actor with access to the controller logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when there is a specific error marshaling the `parameters` sent to the providers. ### Am I vulnerable? To check if tokens are being logged, examine the manager container log: ```bash kubectl logs -l 'app.kubernetes.io/part-of=secrets-store-sync-controller' -c manager -f | grep --line-buffered "csi.storage.k8s.io/serviceAccount.tokens" ``` ### Affected Versions - secrets-store-sync-controller < v0.0.2 ### How do I mitigate this vulnerability? Upgrade to secrets-store-sync-controller v0.0.2+ ### Fixed Versions - secrets-store-sync-controller >= v0.0.2 ### Detection Examine cloud provider logs for unexpected token exchanges, as well as unexpected...

### Impact **What kind of vulnerability is it?** This is a **Critical** severity directory traversal (path traversal) vulnerability in the `File.download()` method of the `internetarchive` library. **Who is impacted?** All users of the `internetarchive` library versions `< 5.5.1` are impacted. The vulnerability is particularly critical for users on **Windows systems**, but all operating systems are affected. **Description of the vulnerability:** The vulnerability existed because the `file.download()` method did not properly sanitize user-supplied filenames or validate the final download path. A maliciously crafted filename could contain path traversal sequences (e.g., `../../../../windows/system32/file.txt`) or illegal characters that, when processed, would cause the file to be written outside of the intended target directory. **Potential Impact:** An attacker could potentially overwrite critical system files or application configuration files, leading to a denial of service, privil...

### Impact When establishing a TLS session using `fs2-io` on the JVM using the `fs2.io.net.tls` package, if one side of the connection shuts down write while the peer side is awaiting more data to progress the TLS handshake, the peer side will spin loop on the socket read, fully utilizing a CPU. This CPU is consumed until the overall connection is closed. This could be used as a denial of service attack on an fs2-io powered server -- for example, by opening many connections and putting them in a half-shutdown state. Note: this issue impacts ember backed http4s servers with HTTPS as a result of ember using fs2's TLS support. ### Patches Fixed in fs2 3.12.2 and 3.13.0-M7. ### Workarounds No workarounds. ### For more information If you have any questions or comments about this advisory: [Open an issue.](https://github.com/typelevel/fs2/issues/new/choose) Contact the [Typelevel Security Team](https://github.com/typelevel/.github/blob/main/SECURITY.md).

## Summary Insecure session handling opened room for a privilege escalation scenario in which [prebuilt workspaces](https://coder.com/docs/admin/templates/extending-templates/prebuilt-workspaces) could be compromised by abusing a shared system identity. ## Details Coder automatically generates a session token for a user when a workspace is started. It is automatically exposed via [`coder_workspace_owner.session_token`](https://registry.terraform.io/providers/coder/coder/latest/docs/data-sources/workspace_owner#session_token-1). Prebuilt workspaces are initially owned by a built-in `prebuilds` system user. When a prebuilt workspace is claimed, a new session token is generated for the user that claimed the workspace, but the previous session token for the `prebuilds` user was not expired. Any Coder workspace templates that persist this automatically generated session token are potentially impacted. For example, the [coder-login module](https://github.com/coder/registry/blob/8677e7...

**Reporter:** Lumina Mescuwa **Product:** ImageMagick 7 (MagickCore) **Component:** `MagickCore/blob.c` (Blob I/O - BlobStream) **Tested:** 7.1.2-0 (source tag) and 7.1.2-1 (Homebrew), macOS arm64, clang-17, Q16-HDRI **Impact:** Heap out-of-bounds **WRITE** (attacker-controlled bytes at attacker-chosen offset) → memory corruption; potential code execution --- ## Executive Summary For memory-backed blobs (**BlobStream**), [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) permits advancing the stream **offset** beyond the current end without increasing capacity. The subsequent [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) then expands by **`quantum + length`** (amortized) instead of **`offset + length`**, and copies to `data + offset`. When `offset ≫ extent`, the copy targets memory beyond the allocatio...

pgAdmin <= 9.7 is affected by a Cross-Origin Opener Policy (COOP) vulnerability. This vulnerability allows an attacker to manipulate the OAuth flow, potentially leading to unauthorised account access, account takeover, data breaches, and privilege escalation.

Improper neutralization of special elements used in an OS command ('OS Command Injection') issue exists in TkEasyGUI versions prior to v1.0.22. If this vulnerability is exploited, an arbitrary OS command may be executed by a remote unauthenticated attacker if the settings are configured to construct messages from external sources.

Uncontrolled search path element issue exists in TkEasyGUI versions prior to v1.0.22. If this vulnerability is exploited, arbitrary code may be executed with the privilege of running the program.

### Impact The podman kube play command can overwrite host files when the kube file contains a ConfigMap or Secret volume mount and the volume already contains a symlink to a host file. This allows a malicious container to write to arbitrary files on the host BUT the attacker only controls the target path not the contents that will be written to the file. The contents are defined in the yaml file by the end user. ### Requirements to exploit: podman kube play must be used with a ConfigMap or Secret volume mount AND must be run more than once on the same volume. All the attacker has to do is create the malicious symlink on the volume the first time it is started. After that all following starts would follow the symlink and write to the host location. ### Patches Fixed in podman v5.6.1 https://github.com/containers/podman/commit/43fbde4e665fe6cee6921868f04b7ccd3de5ad89 ### Workarounds Don't use podman kube play with ConfigMap or Secret volume mounts.

### Impact An unauthenticated attacker with access to the back-office URL can manipulate the id_employee and reset_token parameters to enumerate valid back-office employee email addresses. Impacted parties: Store administrators and employees: their email addresses are exposed. Merchants: risk of phishing, social engineering, and brute-force attacks targeting admin accounts. ### Patches PrestaShop 8.2.3 ### Workarounds You must upgrade, or at least apply the changes from the PrestaShop 8.2.3 patch. More information: https://build.prestashop-project.org/news/2025/prestashop-8-2-3-security-release/