CVE Vulnerability Catalog

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to an expected dependency confusion.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow an attacker with access to the server secret and Redis write access to submit a malicious serialized cache value. When the value was retrieved, deserialization could have executed attacker-controlled code with the privileges of the service process.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of generation of code.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in code.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote attacker to execute arbitrary code due to improper control of code generation.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper access control.

A flaw was found in `sssd-kcm` that allows a local denial of service. A local user or process able to connect to the `sssd-kcm` UNIX socket can send a request with a large length header and then stall the connection, causing significant memory preallocation. This leads to memory exhaustion in the `sssd-kcm` responder, resulting in a DoS.

In ssh in OpenSSH before 10.6, a $ or \ character can occur in a command-line username, leading to injection.

IBM Langflow OSS versions 1.0.0 through 1.12.2 could allow a remote authenticated attacker to execute arbitrary code due to improper access control.

Requesting a user or organization profile page with an Accept header for RSS/Atom returned the owner's activity feed without the visibility check applied by the profile page and .rss/.atom routes. Anonymous, restricted users and non-members could confirm the existence of limited or private users/organizations and read their profile details and public activity, even when ENABLE_FEED was disabled. Activity in private repositories was not included.

The Gitea API endpoint for creating push mirrors checked only whether mirroring was enabled, not the [mirror] DISABLE_NEW_PUSH setting enforced by the web interface. A repository administrator could create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule.

The Gitea API endpoint GET /api/v1/repos/{owner}/{repo}/media/{filepath} wrote files up to 1 KiB stored directly in Git (not LFS) to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was rendered by the browser on the Gitea origin. A user with push access could run JavaScript in the session of a victim opening the media URL and act with the victim's permissions.

With [repository] FORCE_PRIVATE = true, Gitea creates new repositories as private, but the post-receive hook still applied the repo.private=false push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected.

The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with [security] IMPORT_LOCAL_PATHS = true, a repository administrator without local path import permission could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process.