| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in SmallRye JWT's AwsAlbKeyResolver, which is used by applications to verify JSON Web Tokens signed by AWS Application Load Balancers. When the AWS_ALB key provider is configured, the resolver constructs the key-fetch URL by directly concatenating the attacker-controlled kid header value from an inbound JWT without sanitizing path traversal characters or query-string separators. This allows an unauthenticated remote attacker to force the application server to issue GET requests to arbitrary paths on the same origin as the configured key endpoint. As a result, non-public endpoints or internal data reachable on that origin may be read by the attacker before JWT signature verification takes place. |
| Banks generates meaningful LLM prompts using a simple template language. Prior to 2.5.1, Banks DirectoryPromptRegistry does not reject symbolic links for index.json or discovered and existing .jinja prompt files. In an application where untrusted users can influence a prompt directory, DirectoryPromptRegistry._scan() and DirectoryPromptRegistry.get() can follow a link outside the registry root and disclose a file, while DirectoryPromptRegistry.set(), DirectoryPromptRegistry._save(), and DirectoryPromptRegistry._load() can read or overwrite an external link target. The issue requires attacker influence over the registry directory or its extracted contents. This issue is fixed in version 2.5.1. |
| msgpack5 is a msgpack v5 implementation for node.js and the browser. Prior to 6.1.0, the streaming decoder treats the reserved MessagePack byte 0xc1 as incomplete input instead of invalid input. When 0xc1 begins a stream, subsequent data remains buffered while the decoder waits for bytes that cannot make the value valid, allowing a remote peer to exhaust memory. This issue is fixed in version 6.1.0. |
| IBM Guardium Data Protection 12.0, 12.1, and 12.2 could allow a remote attacker to execute arbitrary code due to path traversal. |
| IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 could allow a remote attacker to perform an arbitrary file write due to path traversal. |
| A path traversal vulnerability exists in the web management interface of multiple Multifunction Devices and Printers, including Apeos C4571 1.1.3 and earlier, Apeos C3567 1.1.3, or other products listed, specifically in the handling of externally supplied parameters.
If the device receives a specially crafted, malicious request, it may trigger unintended processing. |
| lrzsz before 0.13.0 contains a path traversal vulnerability in the lrz receive utility's restricted mode that allows malicious ZMODEM senders to write files outside the current directory using absolute pathnames. Because checkpath() in src/lrz.c only rejects '../' sequences unless built with --enable-pubdir, attackers can send files named with absolute paths to overwrite any file writable by the receiving user. |
| Kiota is an OpenAPI based HTTP Client code generator. From 1.25.1 until 1.35.0, Kiota copies x-ai-capabilities.response_semantics.oauth_card_path from an attacker-controlled or compromised OpenAPI description into a generated API plugin manifest without validating that the value is a safe package-relative file reference. Parent-directory traversal, rooted paths, or absolute URIs can therefore reach a consuming host that resolves the reference, allowing the host to cross the intended plugin-package boundary or use an unintended authentication card. Kiota does not itself read a local file or execute code merely while generating the manifest, and impact requires downstream resolution of the unsafe reference. This issue is fixed in version 1.35.0. |
| Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/icongenie 6.1.1, the icongenie generate --profile command accepted folder and name values from a user-supplied profile without constraining the resolved destination to the Quasar project directory. icongenie/lib/utils/get-assets-files.js joined those values with appDir, while icongenie/lib/utils/validate-profile-object.js required only non-empty strings, allowing parent-directory traversal. A developer who runs a crafted profile can cause generated image content to be written or overwritten at any path writable by that user, potentially modifying shell startup files, build scripts, or other executable configuration. This issue is fixed in version 6.1.1. |
| Quasar Framework is a framework for building high-performance Vue.js user interfaces. From 1.0.0 until 3.3.0, @quasar/app-vite recursively removed the resolved build.distDir before building without rejecting the project root, user home directory, filesystem roots, or symlink-resolved external directories. An unsafe trusted configuration can delete data writable by the build user before compilation begins. No attacker-controlled input reaches build.distDir by default, so exploitation requires compromised or less-trusted automation to influence build configuration, or a developer to run a mistaken configuration. This issue is fixed in version 3.3.0. |
| On affected versions of CloudVision Portal (on-premises) or CloudVision Sensor, a path traversal vulnerability exists. An authenticated user with sufficient high privileges could exploit this to extract unintended data from the Sensor. |
| Backstage is an open framework for building developer portals. Prior to 0.3.10 in @backstage/plugin-scaffolder-backend-module-bitbucket-cloud and 0.2.25 in @backstage/plugin-scaffolder-backend-module-bitbucket-server, the Bitbucket pull-request Scaffolder actions did not sufficiently validate filesystem paths. An authenticated user who can execute an eligible template and influence an allowed Bitbucket repository could affect paths outside the expected working area, potentially compromising backend confidentiality, integrity, or availability. This issue is fixed in @backstage/plugin-scaffolder-backend-module-bitbucket-cloud 0.3.10 and @backstage/plugin-scaffolder-backend-module-bitbucket-server 0.2.25. |
| Backstage is an open framework for building developer portals. Prior to 2.2.4, the @backstage/plugin-techdocs-backend package is affected by improper authorization enforcement for techdocs static content. An authenticated user with access to one TechDocs documentation site could craft a URL able to read documentation belonging to a different entity. This only affects deployments using the external TechDocs builder with an external storage provider (S3, GCS, etc.) and the permission framework enabled. Instances that do not use the permission framework are unaffected, since TechDocs content is visible to all authenticated users by design. This issue is fixed in version 2.2.4. |
| Backstage is an open framework for building developer portals. Prior to 2.2.4, the @backstage/plugin-techdocs-backend package is affected by improper input validation in techdocs static content requests. When using the Azure Blob Storage provider, an authenticated Backstage user may be able to read restricted TechDocs content when entity-level permissions are enabled. Deployments that intentionally disable the default backend authentication policy may have broader exposure. This issue is fixed in version 2.2.4. |
| Backstage is an open framework for building developer portals. Prior to 0.6.17, the @backstage/plugin-proxy-backend package is affected by improper input validation in proxy-backend. An authenticated Backstage user could craft a request URL that causes the proxy-backend to forward the request to a path outside the configured base path on the target server. This is limited to target servers already configured as proxy endpoints and requires Backstage authentication by default. This issue is fixed in version 0.6.17. |
| Backstage is an open framework for building developer portals. Prior to 1.54.6, cloud storage catalog providers did not sufficiently validate object paths. A principal able to create or rename objects in a configured Azure Blob Storage or AWS S3 catalog source could cause catalog descriptors to be read from outside the intended storage boundary, limited to locations reachable with the backend's configured credentials. This issue is fixed in 1.54.6. |
| Backstage is an open framework for building developer portals. Prior to 0.17.8, the @backstage/backend-defaults package is affected by improper input validation in cloud storage url readers. An attacker with write access to a cloud storage bucket used by Backstage could craft object names that could collide with protected files in the output directory. In certain deployment configurations, this could lead to content injection. This issue is fixed in version 0.17.8. |
| Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by inconsistent enforcement of allowed location types during catalog processing. Under certain configurations, the catalog backend could process location types that were not intended to be allowed, potentially leading to unintended file access on the backend host. This issue is fixed in version 3.9.1. |
| Claude Code validated that a target file path resided within the project working directory at permission-check time, but re-resolved the path at write time without repeating that validation. This time-of-check to time-of-use (TOCTOU) gap allowed an attacker who could write to the workspace to atomically replace a project file with a symlink, causing Claude Code to follow the symlink and write its output to an arbitrary file outside the project sandbox. Exploitation required the ability to win a race condition against the write operation and write access to the shared workspace, enabling a lower-privileged attacker to redirect benign edits to sensitive files (e.g., shell configuration) in a higher-privileged session.
Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.
Thank you to hackerone.com/c_h4ck_0 for reporting this issue. |
| A path traversal vulnerability exists in the EmailSheet extract_parts functionality of VisiData (version(s): dev (commit 38b21f78)). A specially crafted .eml file can lead to arbitrary file write. An attacker can provide a malicious file to trigger this vulnerability. |
