Latest vulnerabilities · Page 8

Volmarg Personal Management System through 2.1.0 OS Command Injection via Storage Folder Path

Volmarg Personal Management System through 2.1.0 contains an OS command injection vulnerability that allows authenticated users to execute shell commands via unescaped folder paths in the storage module's tree command. Attackers can create a directory under upload/files containing shell metacharacters such as $(...) and then move or copy it, running commands as the web server user.

Dolibarr ERP CRM before 24.0.2 Missing Authorization via public recruitment view.php

Dolibarr ERP CRM before 24.0.2 contains a missing authorization vulnerability in htdocs/public/recruitment/view.php that allows unauthenticated attackers to view unpublished draft job positions. Attackers can enumerate sequential provisional references via the ref parameter to read titles, descriptions, salary budgets, and recruiter names and emails.

• Update to 24.0.2

FreeImage (danoli3 fork) before 3.19.25 Heap Buffer Overflow via GIF_PLAYBACK Compositing

FreeImage (danoli3 fork) before 3.19.25 contains a heap buffer overflow vulnerability in PluginGIF.cpp that allows attackers to write past the canvas allocation via unclipped GIF frame rectangles. Attackers can craft a GIF whose frame left plus width exceeds the logical screen width, causing GifPlaybackCompositeFrame() and GifPlaybackFillRect() to corrupt heap memory when loaded with GIF_PLAYBACK.

• Update to 3.19.25

FreeImage before 3.19.22 Heap Buffer Overflow via IFF/LBM PBM RLE Decoder

FreeImage (danoli3 fork) before 3.19.22 contains a heap buffer overflow vulnerability in the PBM RLE decoder of PluginIFF.cpp that lacks bounds checks on ByteRun1 runs. Attackers can supply a crafted IFF/LBM PBM file with runs straddling scanline ends to write up to 127 controlled bytes past the heap-allocated bitmap.

• Update to 3.19.22

python-markdown2 through 2.5.5 Denial of Service via Unclosed Inline Link Destinations

python-markdown2 through 2.5.5 contains a denial of service vulnerability that allows remote users to exhaust CPU by submitting Markdown with unclosed inline link destinations. Attackers can submit repeated '[a](' or '![a](' sequences, causing _find_balanced to rescan the remaining document for each link and consume quadratic CPU time.

CherryTree through 1.7.2 Local File Disclosure via Embedded-File Filename Path

CherryTree through 1.7.2 contains a path traversal vulnerability in CtStorageXmlHelper::_create_image_from_xml that trusts unvalidated embedded-file 'filename' attributes in XML documents. Attackers can craft a .ctd, .ctz, or .ctx document with an absolute or ~/ filename and no data, so saving embeds files like ~/.ssh/id_rsa into the document.

CherryTree through 1.7.2 OS Command Injection via Custom Web Link Action

CherryTree through 1.7.2 contains an OS command injection vulnerability in CtActions::link_clicked that allows attackers to execute commands by embedding shell metacharacters in web link URLs. When the non-default Custom Web Link Clicked Action option is enabled, attackers can supply crafted documents whose links pass $(...), backticks, or semicolons unquoted to std::system, running commands as the victim on click.

xianyu-auto-reply-fix through 2.0.7 Unauthenticated Message Sending via /send-message

xianyu-auto-reply-fix through 2.0.7 contains a missing authorization vulnerability in the POST /send-message endpoint that allows unauthenticated attackers to send messages from other users' accounts using publicly known default API secrets. Attackers can supply the hard-coded api_key and another user's cookie_id, plus chosen chat_id, to_user_id and message values, to send arbitrary Xianyu messages to buyers from that merchant account.

Signal K Server before 2.33.0 Missing Authentication via /skServer/ziplogs

Signal K Server before 2.33.0 contains a missing authentication vulnerability that allows unauthenticated remote attackers to download log archives via the /skServer/ziplogs endpoint. Attackers can extract the JWT secretKey from security.json in the ZIP, forge administrator tokens, and create persistent admin accounts for full server control.

• Update to 2.33.0

OvenMediaEngine through 0.21.0 OVT Relay DoS via Oversized payload_length

OvenMediaEngine through 0.21.0 contains a denial of service vulnerability in OvtPacket::LoadHeader() that allows unauthenticated attackers to stall connections by sending payload_length values above 32750. Attackers can send crafted OVT packets to the OVT listener to hold connections open indefinitely and accumulate buffered memory, disrupting origin-to-edge stream relay.

ClashMi through 1.0.32.1801 Disabled TLS Certificate Validation Enables Update MITM

KaringX ClashMi through 1.0.32.1801 disables TLS certificate validation by default in the HttpUtils helper, allowing attackers to intercept HTTPS traffic by presenting any certificate. Attackers operating the user's proxy node can serve a forged update manifest omitting sha256 to deliver a malicious installer, achieving code execution when the update runs.

OAuthLib: Token grants can use attacker-supplied client_id for authorization after authenticating a different client

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client's identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from reques

filelock: StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold

`StrictSoftFileLock` and `AsyncStrictSoftFileLock` apply the caller's `mode` to the sentinel (the lock file at `<path>`) and to both claim files (the files whose presence says a process wants or holds the lock). They create the two directories that hold the claims, `<path>.filelock` and `<path>.filelock/claims`, with a bare `mkdir()`. That gives `0o777` filtered through the umask (a per-process mask that removes permission bits from new files and directories) or, under a parent with a default ACL (an access control list on a directory that sets the permissions of entries created inside it), through that ACL. A hold consists of two claim name

• Update to 4.2.1

filelock: WindowsFileLock ignores mode: a 0o600 lock file and the ReadWriteLock database inherit the directory ACL

filelock on Windows ignores the `mode` argument. `FileLock(path, mode=0o600)` creates the same file as `FileLock(path)`: one with no security descriptor of its own (the Windows record that says who may access a file). Its access list, or ACL, is whatever the lock directory hands down to new files. filelock creates the `ReadWriteLock` database, which it asks to be `0o600`, the same way. In a directory whose inheritable ACL grants other local accounts access to new files, those accounts can open the lock file or database. They can take the byte-range lock (a lock on a span of bytes in a file) once the owner releases it and keep the owner's late

• Update to 4.2.1

filelock: StrictSoftFileLock follows a symbolic link swapped in at <path>.filelock and creates claim files in a directory another local user chooses

`StrictSoftFileLock` and `AsyncStrictSoftFileLock` check `<path>.filelock` (the coordination directory that holds the lock's state) with one `lstat` call on its name. `lstat` reports what a name is without following a symbolic link (a file that redirects to another path). After that check, the code reaches `<path>.filelock/claims` by pathname for every later operation (`mkdir`, scan, publish, link, unlink). `_open_directory` passes `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link), but the flag covers only the final `claims` component. The kernel follows a symbolic link in any earlier component. Another loc

• Update to 4.2.1

LangGraph JavaScript custom authentication may permit cross-user Store access

langgraph-api implements the LangGraph API for rapid development and testing. From 0.1.2 until 0.15.0, JavaScript or TypeScript custom authentication Store authorization handlers can return a rewritten namespace that is not carried across the runtime boundary and applied before the Store operation. An authenticated user can therefore access another user's Store namespace when a deployment relies on namespace rewriting for isolation, allowing unauthorized reads, overwrites, searches, or deletions. Python custom authentication and handlers that reject unauthorized namespaces instead of rewriting them are not affected. This issue is fixed in ver

• Update to 0.15.0

LangGraph: Unencoded identifiers in LangGraph SDK v3 streaming can redirect authenticated GET requests

LangGraph Python SDK is used to connect to running LangGraph API servers, manage assistants, threads and stream runs from Python applications. From langgraph-sdk 0.4.0 until 0.4.6, and from langgraph 1.2.3 until 1.2.14 when RemoteGraph v3 streaming uses an affected langgraph-sdk version, the synchronous and asynchronous v3 stream get_tree and _fetch_state helpers interpolate caller-controlled assistant_id and thread_id values into authenticated GET request paths without using _quote_path_param. Relative path segments can therefore be normalized into another readable path on the configured server while retaining authentication headers. This is

• Update to 0.4.6
• Update to 1.2.14

GraphQL Tools: Shared legacy executor routes one subscription's results to a different caller

GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to version 1.1.36 of the GraphQL Tools legacy WebSocket executor package, buildWSLegacyExecutor in packages/executors/legacy-ws/src/index.ts reuses one WebSocket and replaces its single websocket.onmessage handler whenever a new overlapping subscription starts. The handler delivers LEGACY_WS.DATA frames to the newest observer without comparing data.id with the subscription operation id, so a caller using the same executor can receive another user's authorized subscription payload while the earlier caller's stream is starved. This issue is fixed in ver

• Update to 1.1.36

GraphQL Tools: Per-request connection parameters persist into later users' WebSocket authentications

GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to version 1.1.36 of the GraphQL Tools legacy WebSocket executor package, buildWSLegacyExecutor in packages/executors/legacy-ws/src/index.ts retains request.extensions.connectionParams in the closure-scoped executorConnectionParams object after cleanupWebsocket closes a connection. When one executor is reused across different authorization contexts, a later request that omits a sensitive key can send an earlier caller's Authorization or tenant value in its connection_init payload, causing the downstream server to authenticate the later caller as the e

• Update to 1.1.36

decode-uri-component: Denial of service via quadratic replacement of percent-encoded runs

decode-uri-component provides a more robust alternative to decodeURIComponent. Prior to 0.5.1, decodeUriComponent in index.js falls back to customDecodeURIComponent after native decoding throws, and the fallback collects every distinct percent-encoded run before performing a full-string regular-expression replacement for each entry. Malformed input containing many distinct runs can therefore make both the number of replacements and the scanned input length grow together, causing quadratic CPU consumption and blocking the Node.js event loop; request-body inputs can reach the demonstrated size, while ordinary URL header limits reduce the practi