{ "version": "https://jsonfeed.org/version/1.1", "title": "VulnWatch — AI Security Tracker", "description": "Curated AI/ML security vulnerabilities, advisories, and breach disclosures.", "home_page_url": "https://vulnwatch.ai", "feed_url": "https://vulnwatch.ai/feed/json", "language": "en-US", "authors": [{ "name": "VulnWatch" } ], "items": [{ "id": "https://vulnwatch.ai/01a0c96a-9733-7015-b7f9-66c208fbbecb", "title": "AI Agents Are Rewriting the Rules of Lateral Movement", "url": "https://thehackernews.com/2026/09/ai-agents-are-rewriting-rules-of.html", "content_html": "Security teams have spent decades asking whether an identity has too much access. AI agents raise a harder question: how can we determine which paths an autonomous system can discover, given the access it already has?\n\nA person may try several ways to complete a task. A deterministic application follows the flow its developer wrote. But an AI agent is relentless in its pursuit of done. In May", "summary": "Security teams have spent decades asking whether an identity has too much access. AI agents raise a harder question: how can we determine which paths an autonomous system can discover, given the access it already has?\n\nA person may try several ways to complete a task. A deterministic application follows the flow its developer wrote. But an AI agent is relentless in its pursuit of done. In May", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c8fc-cef6-721b-b308-c7ae997c2d05", "title": "CVE-2025-14486: The PixelPlay plugin for WordPress is vulnerable to unauthorized API key deletion due to missing authorization checks in", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14486", "content_html": "The PixelPlay plugin for WordPress is vulnerable to unauthorized API key deletion due to missing authorization checks in all versions up to, and including, 1.0.2. This makes it possible for unauthenticated attackers to delete arbitrary API keys (Pixabay, Unsplash, Pixels, OpenAI) configured by site administrators via the 'clear_api_type' parameter.", "summary": "The PixelPlay plugin for WordPress is vulnerable to unauthorized API key deletion due to missing authorization checks in all versions up to, and including, 1.0.2. This makes it possible for unauthenticated attackers to delete arbitrary API keys (Pixabay, Unsplash, Pixels, OpenAI) configured by site administrators via the 'clear_api_type' parameter.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c8fc-ed81-703f-a826-0c439cecb033", "title": "Transformers now runs llama.cpp quants", "url": "https://huggingface.co/blog/transformers-llama-cpp-quants", "content_html": "", "summary": "", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c821-3165-73ae-b4b3-b33f702b3a4b", "title": "Jun Kim, oMLX creator and maintainer, joins Hugging Face to support the MLX community", "url": "https://huggingface.co/blog/omlx", "content_html": "", "summary": "", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a79-7284-a6ed-1ce91bfa40de", "title": "CVE-2026-94627: vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child reque", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94627", "content_html": "vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill\/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.", "summary": "vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill\/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a72-70f5-bc7f-44a5807e3fd1", "title": "CVE-2026-94626: vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoi", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94626", "content_html": "vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tp_size values in prefill\/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process.", "summary": "vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tp_size values in prefill\/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a6d-718a-8cd4-83ed06fc19d6", "title": "CVE-2026-94625: vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests cr", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94625", "content_html": "vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders that are never reclaimed. Attackers can send rejected requests to exhaust sender task pools, causing valid requests to be delayed by up to 480 seconds while health checks continue returning success.", "summary": "vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders that are never reclaimed. Attackers can send rejected requests to exhaust sender task pools, causing valid requests to be delayed by up to 480 seconds while health checks continue returning success.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a68-7140-92fa-080808f4d9aa", "title": "CVE-2026-94624: vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configur", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94624", "content_html": "vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configured with TieringOffloadingSpec and a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions that retain ZeroMQ sockets until the context quota is exhausted, causing an uncaught ZMQError that crashes EngineCore and stops all inference.", "summary": "vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configured with TieringOffloadingSpec and a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions that retain ZeroMQ sockets until the context quota is exhausted, causing an uncaught ZMQError that crashes EngineCore and stops all inference.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a61-7341-95e4-f6cf1ed14a15", "title": "CVE-2026-94623: vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation tha", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94623", "content_html": "vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill\/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.", "summary": "vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill\/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a59-7163-ac4b-19e2f5854de6", "title": "CVE-2026-94622: vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for pre", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94622", "content_html": "vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill\/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.", "summary": "vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill\/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a4d-700a-927f-80aba6852f69", "title": "CVE-2026-77518: MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, a normal workspace user who knows anothe", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77518", "content_html": "MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, a normal workspace user who knows another user's active MCP tool_id in the same workspace can retrieve the hidden tool through the tool-detail route because it does not apply the per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit an attacker-owned workflow can place the same foreign mcp_tool_id in a workflow mcp-node so workflow debug uses the owner's MCP configuration without verifying permission to use that tool. No fixed version is available as of this review.", "summary": "MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, a normal workspace user who knows another user's active MCP tool_id in the same workspace can retrieve the hidden tool through the tool-detail route because it does not apply the per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit an attacker-owned workflow can place the same foreign mcp_tool_id in a workflow mcp-node so workflow debug uses the owner's MCP configuration without verifying permission to use that tool. No fixed version is available as of this review.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a44-72bf-ae9a-8dd4add40a02", "title": "CVE-2026-61647: NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content ", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61647", "content_html": "NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the `POST \/batch-to-vault` endpoint, also exposed through the `batch_to_vault` MCP tool beginning in version 1.7.0, because attacker-controlled `vault_dir` and `slug_prefix` values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes `slug_prefix` and supports vault containment when `NOTEBOOKLM_VAULT_ROOT` is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate `vault_dir` values supplied by LLMs processing untrusted content.", "summary": "NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the `POST \/batch-to-vault` endpoint, also exposed through the `batch_to_vault` MCP tool beginning in version 1.7.0, because attacker-controlled `vault_dir` and `slug_prefix` values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes `slug_prefix` and supports vault containment when `NOTEBOOKLM_VAULT_ROOT` is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate `vault_dir` values supplied by LLMs processing untrusted content.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c669-9a39-700e-a586-b37bdd5f97e4", "title": "CVE-2026-61612: CKAN MCP Server is a tool for querying CKAN open data portals. Prior to version 0.4.108, the SSRF guard `validateServerU", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61612", "content_html": "CKAN MCP Server is a tool for querying CKAN open data portals. Prior to version 0.4.108, the SSRF guard `validateServerUrl` (added for CVE-2026-33060, extended for CVE-2026-53509) validates only the hostname string and never resolves DNS. Any caller-supplied `server_url` whose hostname *resolves* to an internal address passes the guard, so the server issues requests to loopback and cloud metadata (`169.254.169.254`). This is a third bypass of the same guard, and it reaches IMDS \u2014 strictly more than CVE-2026-53509, which only reached loopback. Version 0.4.108 contains an updated fix.", "summary": "CKAN MCP Server is a tool for querying CKAN open data portals. Prior to version 0.4.108, the SSRF guard `validateServerUrl` (added for CVE-2026-33060, extended for CVE-2026-53509) validates only the hostname string and never resolves DNS. Any caller-supplied `server_url` whose hostname *resolves* to an internal address passes the guard, so the server issues requests to loopback and cloud metadata (`169.254.169.254`). This is a third bypass of the same guard, and it reaches IMDS \u2014 strictly more than CVE-2026-53509, which only reached loopback. Version 0.4.108 contains an updated fix.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-0225-73ed-970c-e72dbdf67922", "title": "CVE-2026-88978: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.106.1, t", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88978", "content_html": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.106.1, the WorkerStatus gRPC polling path in pkg\/repository\/durable_events.go passes caller-supplied durable task, node, and branch identifiers to ListSatisfiedEntries without a tenant filter, allowing an authenticated tenant worker that knows another tenant's durable-task UUID to retrieve matching durable event-log records. The UUIDv4 requirement makes exploitation unlikely, and single-tenant deployments are unaffected in practice. This issue is fixed in version 0.106.1.", "summary": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.106.1, the WorkerStatus gRPC polling path in pkg\/repository\/durable_events.go passes caller-supplied durable task, node, and branch identifiers to ListSatisfiedEntries without a tenant filter, allowing an authenticated tenant worker that knows another tenant's durable-task UUID to retrieve matching durable event-log records. The UUIDv4 requirement makes exploitation unlikely, and single-tenant deployments are unaffected in practice. This issue is fixed in version 0.106.1.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-021d-727d-9df1-dd8ad114df9b", "title": "CVE-2026-84298: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.95.3, th", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84298", "content_html": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.95.3, the V1 DurableTask stream handler stores worker-supplied task_external_id values in the durableInvocations routing map before tenant ownership is verified, and callback delivery resolves that map by task UUID without tenant identity. An authenticated tenant worker that knows another tenant's durable task UUID and keeps a stream open on the same dispatcher process can receive that task's durable callback result payload. UUIDv4 values are not enumerable, and single-tenant deployments are unaffected in practice. This issue is fixed in version 0.95.3.", "summary": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.95.3, the V1 DurableTask stream handler stores worker-supplied task_external_id values in the durableInvocations routing map before tenant ownership is verified, and callback delivery resolves that map by task UUID without tenant identity. An authenticated tenant worker that knows another tenant's durable task UUID and keeps a stream open on the same dispatcher process can receive that task's durable callback result payload. UUIDv4 values are not enumerable, and single-tenant deployments are unaffected in practice. This issue is fixed in version 0.95.3.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-0210-7244-bc05-ac11c3695482", "title": "CVE-2026-63342: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, ap", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63342", "content_html": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, api-contracts\/openapi\/paths\/v1\/workflow-runs\/workflow_run.yaml defines the GET \/api\/v1\/stable\/durable-tasks\/{durable-task} endpoint implemented by listDurableEventLog without requiring the target tenant as a parent resource, allowing an authenticated user who obtains another tenant's durable task UUID to read that task's event log. Disclosed data can include task display names, workflow identifiers, user messages, wait conditions, branching logic, and timing information. This issue is fixed in version 0.91.1.", "summary": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, api-contracts\/openapi\/paths\/v1\/workflow-runs\/workflow_run.yaml defines the GET \/api\/v1\/stable\/durable-tasks\/{durable-task} endpoint implemented by listDurableEventLog without requiring the target tenant as a parent resource, allowing an authenticated user who obtains another tenant's durable task UUID to read that task's event log. Disclosed data can include task display names, workflow identifiers, user messages, wait conditions, branching logic, and timing information. This issue is fixed in version 0.91.1.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-0209-71da-8524-477ea27d870b", "title": "CVE-2026-61687: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, Va", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61687", "content_html": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, ValidateOAuthState clears the oauth_state_ session value to an empty string after a successful OAuth callback and later accepts an empty state parameter as equal, allowing an unauthenticated attacker to bind a victim's Hatchet session to an attacker-controlled OAuth identity. Exploitation requires the victim to have completed an OAuth flow in the current session and the deployment to enable auth.google.enabled, auth.github.enabled, or the Slack integration. This issue is fixed in version 0.91.1.", "summary": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, ValidateOAuthState clears the oauth_state_ session value to an empty string after a successful OAuth callback and later accepts an empty state parameter as equal, allowing an unauthenticated attacker to bind a victim's Hatchet session to an attacker-controlled OAuth identity. Exploitation requires the victim to have completed an OAuth flow in the current session and the deployment to enable auth.google.enabled, auth.github.enabled, or the Slack integration. This issue is fixed in version 0.91.1.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-01ff-73f0-8a05-a6e32f2bda4e", "title": "CVE-2026-61681: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, th", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61681", "content_html": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, the SNS UnsubscribeConfirmation handler in internal\/integrations\/ingestors\/sns\/sns.go calls http.Get() on payload.UnsubscribeURL after VerifyPayload() even though BuildSignature() excludes UnsubscribeURL, allowing an authenticated Hatchet tenant to replace that field in an otherwise valid AWS-signed message with an internal URL. The server-side request can reach EC2 Instance Metadata Service, internal services, and internal HTTP APIs, potentially exposing IAM credentials or network-accessible data and functionality. This issue is fixed in version 0.91.1.", "summary": "Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, the SNS UnsubscribeConfirmation handler in internal\/integrations\/ingestors\/sns\/sns.go calls http.Get() on payload.UnsubscribeURL after VerifyPayload() even though BuildSignature() excludes UnsubscribeURL, allowing an authenticated Hatchet tenant to replace that field in an otherwise valid AWS-signed message with an internal URL. The server-side request can reach EC2 Instance Metadata Service, internal services, and internal HTTP APIs, potentially exposing IAM credentials or network-accessible data and functionality. This issue is fixed in version 0.91.1.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-01f7-7187-9de0-3f2502ceca46", "title": "CVE-2026-55563: Feast is the open source feature store for AI and machine learning. Prior to 0.65.0, .github\/workflows\/pr_integration_te", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55563", "content_html": "Feast is the open source feature store for AI and machine learning. Prior to 0.65.0, .github\/workflows\/pr_integration_tests.yml uses pull_request_target with the synchronize event and preserves ok-to-test, approved, or lgtm labels across newly pushed commits, allowing a fork contributor to obtain approval for a benign revision and then run changed code from refs\/pull\/${{ github.event.pull_request.number }}\/merge through privileged make targets. The job exposes GCP, AWS, and Snowflake credentials to that code, enabling runner code execution, credential disclosure, and possible access to downstream cloud resources. An external label-removal integration could mitigate the condition, but no repository workflow provided that protection. This issue is fixed in version 0.65.0.", "summary": "Feast is the open source feature store for AI and machine learning. Prior to 0.65.0, .github\/workflows\/pr_integration_tests.yml uses pull_request_target with the synchronize event and preserves ok-to-test, approved, or lgtm labels across newly pushed commits, allowing a fork contributor to obtain approval for a benign revision and then run changed code from refs\/pull\/${{ github.event.pull_request.number }}\/merge through privileged make targets. The job exposes GCP, AWS, and Snowflake credentials to that code, enabling runner code execution, credential disclosure, and possible access to downstream cloud resources. An external label-removal integration could mitigate the condition, but no repository workflow provided that protection. This issue is fixed in version 0.65.0.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c520-01e5-735d-91ab-9d0a455d50b9", "title": "CVE-2026-55071: MCP-for-Stata is a MCP server for integrating Stata into agent loops with a safety-first design. Prior to version 1.19.0", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55071", "content_html": "MCP-for-Stata is a MCP server for integrating Stata into agent loops with a safety-first design. Prior to version 1.19.0, the ado_package_install MCP tool in stata-mcp concatenates user-controlled input directly into a Stata command string without any validation or sanitization. An attacker who can invoke the MCP tool or the equivalent Python API can embed newline characters in the package argument to inject arbitrary Stata commands. Because Stata supports a shell escape command, this leads to full OS-level arbitrary command execution (RCE) under the account running the Stata-MCP server. The tool is registered in the default all profile, so no non-default configuration is required. This issue has been patched in version 1.19.0.", "summary": "MCP-for-Stata is a MCP server for integrating Stata into agent loops with a safety-first design. Prior to version 1.19.0, the ado_package_install MCP tool in stata-mcp concatenates user-controlled input directly into a Stata command string without any validation or sanitization. An attacker who can invoke the MCP tool or the equivalent Python API can embed newline characters in the package argument to inject arbitrary Stata commands. Because Stata supports a shell escape command, this leads to full OS-level arbitrary command execution (RCE) under the account running the Stata-MCP server. The tool is registered in the default all profile, so no non-default configuration is required. This issue has been patched in version 1.19.0.", "date_published": "2026-09-22T12:00:06+00:00", "date_modified": "2026-09-22T12:00:06+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c4b2-4a51-703f-9e92-ba83cb34fe6c", "title": "\u26a1 Weekly Recap: Cisco 0-Day, AI Agent RCE, ClickFix Attacks, ClickFix Surge, and Browser Hijacks", "url": "https://thehackernews.com/2026/09/weekly-recap-cisco-0-day-ai-agent-rce.html", "content_html": "A browser. A plugin. A package. A login screen. Normal stuff. That is basically the problem this week.\n\nThe trouble keeps showing up inside things people already trust: code that takes a bad turn, old payloads coming back, exposed systems, weak checks, fake fixes, and attack paths that look almost too easy. Even the research side is getting messy, with more findings, more automation, and not", "summary": "A browser. A plugin. A package. A login screen. Normal stuff. That is basically the problem this week.\n\nThe trouble keeps showing up inside things people already trust: code that takes a bad turn, old payloads coming back, exposed systems, weak checks, fake fixes, and attack paths that look almost too easy. Even the research side is getting messy, with more findings, more automation, and not", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c444-3d02-737b-9991-cf6074315030", "title": "Pruning LLMs Like a Physicist: Block Removal as an Ising Optimization Problem", "url": "https://huggingface.co/blog/MultiverseComputingCAI/pruning-llms-like-a-physicist-block-removal-as-an", "content_html": "", "summary": "", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c2fa-d6d5-73d1-9ef9-22c12915981a", "title": "Google Confirms Gemini AI Breached Three Firms", "url": "https://www.securityweek.com/google-confirms-gemini-ai-breached-three-firms/", "content_html": "Google is the latest AI giant to confirm that its models escaped a testing environment and hacked real companies.\nThe post Google Confirms Gemini AI Breached Three Firms appeared first on SecurityWeek.", "summary": "Google is the latest AI giant to confirm that its models escaped a testing environment and hacked real companies.\nThe post Google Confirms Gemini AI Breached Three Firms appeared first on SecurityWeek.", "date_published": "2026-09-22T02:00:01+00:00", "date_modified": "2026-09-22T02:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0c143-328c-714b-b755-005965850a2b", "title": "CVE-2026-94093: A security vulnerability has been detected in DLR-RM stable-baselines3 up to 2.9.0. This affects the function PPO.load\/l", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94093", "content_html": "A security vulnerability has been detected in DLR-RM stable-baselines3 up to 2.9.0. This affects the function PPO.load\/load_replay_buffer\/VecNormalize.load of the file save_util.py. Such manipulation leads to deserialization. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. In v2.9.0 the PyTorch tensor load path is hardened (weights_only=True), but that hardening was later reverted on master via PR #1913 \"Hotfix: revert loading with weights_only=True\" [blocked] to fix PyTorch 1.13 compat - so even the one \"safe\" path is inconsistent across versions. #2281 was closed as a duplicate of #1831 since both are unsafe pickle deserialization - but #1831's fix (PR #41) only gated the Hugging Face Hub loader in the separate huggingface_sb3 package. This finding covers the core stable_baselines3 load APIs (PPO.load, load_replay_buffer, VecNormalize.load), which have no safe mode or gate and remained exploitable in v2.9.0 until the outstanding hardening (PR #2264) ships.", "summary": "A security vulnerability has been detected in DLR-RM stable-baselines3 up to 2.9.0. This affects the function PPO.load\/load_replay_buffer\/VecNormalize.load of the file save_util.py. Such manipulation leads to deserialization. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. In v2.9.0 the PyTorch tensor load path is hardened (weights_only=True), but that hardening was later reverted on master via PR #1913 \"Hotfix: revert loading with weights_only=True\" [blocked] to fix PyTorch 1.13 compat - so even the one \"safe\" path is inconsistent across versions. #2281 was closed as a duplicate of #1831 since both are unsafe pickle deserialization - but #1831's fix (PR #41) only gated the Hugging Face Hub loader in the separate huggingface_sb3 package. This finding covers the core stable_baselines3 load APIs (PPO.load, load_replay_buffer, VecNormalize.load), which have no safe mode or gate and remained exploitable in v2.9.0 until the outstanding hardening (PR #2264) ships.", "date_published": "2026-09-21T18:00:04+00:00", "date_modified": "2026-09-21T18:00:04+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0bff9-9ad2-73c8-bef9-6da772e4a2c2", "title": "CVE-2026-94111: Tencent BrowserSkill through 0.3.0 contains an authentication bypass vulnerability in the local daemon WebSocket origin ", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94111", "content_html": "Tencent BrowserSkill through 0.3.0 contains an authentication bypass vulnerability in the local daemon WebSocket origin validation that accepts any chrome-extension origin with 32 characters in range a-p. Attackers can register a malicious extension as a browser client to intercept and manipulate page content, DOM, and screenshots returned to the AI agent.", "summary": "Tencent BrowserSkill through 0.3.0 contains an authentication bypass vulnerability in the local daemon WebSocket origin validation that accepts any chrome-extension origin with 32 characters in range a-p. Attackers can register a malicious extension as a browser client to intercept and manipulate page content, DOM, and screenshots returned to the AI agent.", "date_published": "2026-09-21T06:00:01+00:00", "date_modified": "2026-09-21T06:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0bf1d-deb5-702a-838d-8bdd2bcc4639", "title": "Researchers escape OpenAI Codex sandbox to run commands on host", "url": "https://www.bleepingcomputer.com/news/security/researchers-escape-openai-codex-sandbox-to-run-commands-on-host/", "content_html": "Researchers escaped OpenAI's Codex sandbox two ways, one running commands on a developer's machine from its most locked-down mode. OpenAI has patched both. [...]", "summary": "Researchers escaped OpenAI's Codex sandbox two ways, one running commands on a developer's machine from its most locked-down mode. OpenAI has patched both. [...]", "date_published": "2026-09-22T14:00:01+00:00", "date_modified": "2026-09-22T14:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0bc1c-da16-7311-9f84-7dd1bc9cbe70", "title": "CVE-2026-93993: Mistral Vibe before 2.25.5 contains a remote code execution vulnerability in the worktree creation process that executes", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93993", "content_html": "Mistral Vibe before 2.25.5 contains a remote code execution vulnerability in the worktree creation process that executes git hooks before trust validation. Attackers can supply a repository with a crafted post-checkout hook that executes arbitrary shell commands with the privileges of the user running Vibe.", "summary": "Mistral Vibe before 2.25.5 contains a remote code execution vulnerability in the worktree creation process that executes git hooks before trust validation. Attackers can supply a repository with a crafted post-checkout hook that executes arbitrary shell commands with the privileges of the user running Vibe.", "date_published": "2026-09-20T18:00:01+00:00", "date_modified": "2026-09-20T18:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0bc1c-da0a-7393-91fe-91eaa28ab16a", "title": "CVE-2026-93989: vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in Sa", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93989", "content_html": "vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in SamplingParams.update_from_tokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests, causing different in-flight HTTP requests to return incorrect tokens.", "summary": "vLLM through 0.29.0 fails to properly validate bad_words token indices against the model's generation output width in SamplingParams.update_from_tokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests, causing different in-flight HTTP requests to return incorrect tokens.", "date_published": "2026-09-20T18:00:01+00:00", "date_modified": "2026-09-20T18:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b989-daa4-72bf-b09f-e32189439e68", "title": "Claude Opus 5 Helped Researchers Take Over OpenAI Staff Accounts via Chained Flaws", "url": "https://thehackernews.com/2026/09/claude-opus-5-helped-researchers-take.html", "content_html": "Three researchers at the security firm\u00a0Hacktron\u00a0used Anthropic's Claude Opus 5 to chain two flaws and take over the ChatGPT and Codex accounts of several OpenAI employees, then reach an internal OpenAI code repository.\n\nThe chain began with a bug in the software that runs OpenAI's public help forum and moved through a weakness in OpenAI's own login system.\n\nThis was security research,", "summary": "Three researchers at the security firm\u00a0Hacktron\u00a0used Anthropic's Claude Opus 5 to chain two flaws and take over the ChatGPT and Codex accounts of several OpenAI employees, then reach an internal OpenAI code repository.\n\nThe chain began with a bug in the software that runs OpenAI's public help forum and moved through a weakness in OpenAI's own login system.\n\nThis was security research,", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0ba65-9052-718b-8f3f-801e0c749a00", "title": "BragJack attacks hijack AI browser agents through malicious extensions", "url": "https://www.bleepingcomputer.com/news/security/bragjack-attacks-hijack-ai-browser-agents-through-malicious-extensions/", "content_html": "BragJack, a proof-of-concept attack from Forever Security's Gal Weizman, hijacks the AI assistants in Chrome, Edge, Opera Neon, Perplexity Comet, and Claude in Chrome using one malicious extension. The Prompt Forcing technique earned over $20,000 in bounties and two CVEs. [...]", "summary": "BragJack, a proof-of-concept attack from Forever Security's Gal Weizman, hijacks the AI assistants in Chrome, Edge, Opera Neon, Perplexity Comet, and Claude in Chrome using one malicious extension. The Prompt Forcing technique earned over $20,000 in bounties and two CVEs. [...]", "date_published": "2026-09-22T12:00:13+00:00", "date_modified": "2026-09-22T12:00:13+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0bad3-4485-7251-9063-724e0fc5cb40", "title": "CVE-2026-93982: OpenPanel through commit bad75bdd writes Model Context Protocol authentication tokens from URL query parameters to plain", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93982", "content_html": "OpenPanel through commit bad75bdd writes Model Context Protocol authentication tokens from URL query parameters to plaintext application logs without redaction. Attackers with access to application stdout or centralized logging systems can capture base64-encoded credentials to replay MCP requests and access project analytics.", "summary": "OpenPanel through commit bad75bdd writes Model Context Protocol authentication tokens from URL query parameters to plaintext application logs without redaction. Attackers with access to application stdout or centralized logging systems can capture base64-encoded credentials to replay MCP requests and access project analytics.", "date_published": "2026-09-20T12:00:01+00:00", "date_modified": "2026-09-20T12:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b91b-c940-70bb-a6e2-d501f96aeae9", "title": "Google Gemini Broke Into Real Company Systems After Security Test Domain Mix-Up", "url": "https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html", "content_html": "Google's Gemini model has become the latest artificial intelligence (AI) system to access the internet and break into other companies during a cybersecurity evaluation. The development was first reported by The Wall Street Journal.\n\nThe incidents occurred in May 2026 as part of a test run conducted by Israeli company Irregular. The evaluation partner was also involved in similar hacks disclosed", "summary": "Google's Gemini model has become the latest artificial intelligence (AI) system to access the internet and break into other companies during a cybersecurity evaluation. The development was first reported by The Wall Street Journal.\n\nThe incidents occurred in May 2026 as part of a test run conducted by Israeli company Irregular. The evaluation partner was also involved in similar hacks disclosed", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b6f6-9034-724a-a661-efee3f121dce", "title": "CVE-2026-93841: vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs ind", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93841", "content_html": "vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.", "summary": "vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.", "date_published": "2026-09-19T18:00:02+00:00", "date_modified": "2026-09-19T18:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b6f6-902d-72eb-84e7-b117fa39e71c", "title": "CVE-2026-93840: vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in Sampling", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93840", "content_html": "vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists.", "summary": "vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in SamplingParams._validate_allowed_token_ids(). Attackers can supply token IDs above the output vocabulary that pass validation, causing LogitBiasState to corrupt GPU logits state and allow concurrent requests to sample tokens outside their allowlists.", "date_published": "2026-09-19T18:00:02+00:00", "date_modified": "2026-09-19T18:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b6f6-9025-71ba-b3a4-110500696e69", "title": "CVE-2026-93838: SGLang versions through 0.5.20 contain an unbounded memory allocation vulnerability in handle_staging_req() that fails t", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93838", "content_html": "SGLang versions through 0.5.20 contain an unbounded memory allocation vulnerability in handle_staging_req() that fails to validate chunk_idx from ZMQ STAGING_REQ frames in prefill\/decode disaggregation deployments. Attackers with access to the decode engine's internal ZMQ rank port can send a frame with an extremely large chunk_idx value, causing the scheduler to allocate memory until the system runs out and terminates the process.", "summary": "SGLang versions through 0.5.20 contain an unbounded memory allocation vulnerability in handle_staging_req() that fails to validate chunk_idx from ZMQ STAGING_REQ frames in prefill\/decode disaggregation deployments. Attackers with access to the decode engine's internal ZMQ rank port can send a frame with an extremely large chunk_idx value, causing the scheduler to allocate memory until the system runs out and terminates the process.", "date_published": "2026-09-19T18:00:02+00:00", "date_modified": "2026-09-19T18:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b6f6-9014-72b0-a3d5-38393d754858", "title": "CVE-2026-33625: LMDeploy is a toolkit for compressing, deploying, and serving large language models. Versions 012.1 through 0.12.2 conta", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33625", "content_html": "LMDeploy is a toolkit for compressing, deploying, and serving large language models. Versions 012.1 through 0.12.2 contain a code injection vulnerability in `lmdeploy\/pytorch\/config.py` line 620 that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted `quantization_config.quant_dtype` value. When a user loads the model with lmdeploy, the `quant_dtype` is passed to `eval(f'torch.{quant_dtype}')` without any validation. Version 0.12.3 contains a patch.", "summary": "LMDeploy is a toolkit for compressing, deploying, and serving large language models. Versions 012.1 through 0.12.2 contain a code injection vulnerability in `lmdeploy\/pytorch\/config.py` line 620 that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted `quantization_config.quant_dtype` value. When a user loads the model with lmdeploy, the `quant_dtype` is passed to `eval(f'torch.{quant_dtype}')` without any validation. Version 0.12.3 contains a patch.", "date_published": "2026-09-19T18:00:02+00:00", "date_modified": "2026-09-19T18:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b6f6-900a-7165-bb00-531f022328db", "title": "CVE-2025-66455: LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66455", "content_html": "LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior to version 0.16.0, LMDeploy's PyTorch DistServe\/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements `recv_pyobj()` using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the `POST \/distserve\/p2p_connect` HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation\/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow. The fix was released in LMDeploy 0.16.0. Users who cannot upgrade immediately should prevent untrusted clients from reaching `\/distserve\/*` endpoints, restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks, configure API-key authentication, and block arbitrary outbound ZeroMQ connections from serving nodes. These measures reduce exposure but do not make pickle deserialization safe.", "summary": "LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior to version 0.16.0, LMDeploy's PyTorch DistServe\/PD-disaggregation control plane used `recv_pyobj()` to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements `recv_pyobj()` using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the `POST \/distserve\/p2p_connect` HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation\/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow. The fix was released in LMDeploy 0.16.0. Users who cannot upgrade immediately should prevent untrusted clients from reaching `\/distserve\/*` endpoints, restrict the DistServe HTTP and ZeroMQ control planes to trusted cluster networks, configure API-key authentication, and block arbitrary outbound ZeroMQ connections from serving nodes. These measures reduce exposure but do not make pickle deserialization safe.", "date_published": "2026-09-19T18:00:02+00:00", "date_modified": "2026-09-19T18:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b7d-7151-922a-733726e04dd4", "title": "Obot: Server-Side Request Forgery via remote MCP server URL", "url": "https://github.com/advisories/GHSA-jgh3-fggc-mcpm", "content_html": "## Summary\n\nIn affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (`169.254.169.254`), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses.\n\n## Am I affected?\n\nYou are affected if you run Obot `", "summary": "## Summary\n\nIn affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (`169.254.169.254`), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses.\n\n## Am I affected?\n\nYou are affected if you run Obot `", "date_published": "2026-09-19T01:00:02+00:00", "date_modified": "2026-09-19T01:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b84-7188-8281-78d907b2f9b3", "title": "Obot: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion", "url": "https://github.com/advisories/GHSA-xwmw-prc4-v3cr", "content_html": "## Summary\n\nIn affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker's redirect URI and exchanged for an access token. That token was minted with the victim's full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to \u2014 rather than being scoped to just the requested MCP server.\n\n## Am I affected?\n\nYou are affected if you run Obot `", "summary": "## Summary\n\nIn affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker's redirect URI and exchanged for an access token. That token was minted with the victim's full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to \u2014 rather than being scoped to just the requested MCP server.\n\n## Am I affected?\n\nYou are affected if you run Obot `", "date_published": "2026-09-19T01:00:02+00:00", "date_modified": "2026-09-19T01:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b5ad-2ff8-70ec-a701-1de83d117f36", "title": "CVE-2026-77616: Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's ", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77616", "content_html": "Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. In versions 7.0.0 through 7.1.0, `Special:Ask` accepts a `cursor` query parameter for keyset pagination (added in 7.0.0). The token is decoded by `CursorEncoder`, which is an **unsigned** base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's `sort=` \/ `order=`, `QueryCreator::applyCursorIfRequested()` builds an error message by interpolating the attacker-controlled `sort_prop` \/ `sort_order` values into a raw string via `Query::addErrors()`. Unlike SMW's message-key errors, this raw string bypasses the message layer's sanitization (`ProcessingErrorMsgHandler::normalizeAndDecodeMessages()` passes a non-key, non-encoded string through unchanged). `ErrorWidget::queryError()` then assembles the errors and passes them to `Html::errorBox()`, whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted `cursor` token containing markup in `sort_prop` (or `sort_order`) executes script in the victim's browser on the wiki origin. No authentication or special permission is required. The payload is delivered via a crafted link. Version 7.2.0 contains a fix.", "summary": "Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. In versions 7.0.0 through 7.1.0, `Special:Ask` accepts a `cursor` query parameter for keyset pagination (added in 7.0.0). The token is decoded by `CursorEncoder`, which is an **unsigned** base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's `sort=` \/ `order=`, `QueryCreator::applyCursorIfRequested()` builds an error message by interpolating the attacker-controlled `sort_prop` \/ `sort_order` values into a raw string via `Query::addErrors()`. Unlike SMW's message-key errors, this raw string bypasses the message layer's sanitization (`ProcessingErrorMsgHandler::normalizeAndDecodeMessages()` passes a non-key, non-encoded string through unchanged). `ErrorWidget::queryError()` then assembles the errors and passes them to `Html::errorBox()`, whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted `cursor` token containing markup in `sort_prop` (or `sort_order`) executes script in the victim's browser on the wiki origin. No authentication or special permission is required. The payload is delivered via a crafted link. Version 7.2.0 contains a fix.", "date_published": "2026-09-19T12:00:02+00:00", "date_modified": "2026-09-19T12:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b5ad-2ff3-71bd-a8ed-d06fcd044db1", "title": "CVE-2026-58197: ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to Too", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58197", "content_html": "ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.", "summary": "ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.", "date_published": "2026-09-19T12:00:02+00:00", "date_modified": "2026-09-19T12:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b8a-712b-a0c4-0e73862c9d06", "title": "ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement", "url": "https://github.com/advisories/GHSA-qg2g-g9w3-m5h8", "content_html": "## Summary\n\nA containerized MCP server running with the default `network` permission profile (`insecure_allow_all: true`) can reach host-local services via `host.docker.internal`. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host's localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.\n\n## Severity\n\n**High** \u2014 This bypasses the container isolation model that is ToolHive's core security value proposition.\n\n## Reproduction\n\nAll tests performed from inside the `filesystem` MCP container (`docker.io\/mcp\/filesystem:latest`), started with default settings via `thv run filesystem -- \/tmp`.\n\n### 1. Container can reach the ToolHive control plane MCP endpoint\n\n```bash\n$ docker exec wget -qO- \\\n --header=\"Content-Type: application\/json\" \\\n --header=\"Accept: application\/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"evil-mcp\",\"version\":\"1.0\"}},\"id\":1}' \\\n http:\/\/host.docker.internal:50444\/mcp\n```\n\n**Result:** Full MCP handshake succeeds:\n```json\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{\"logging\":{},\"tools\":{}},\"serverInfo\":{\"name\":\"toolhive-mcp\",\"version\":\"v0.9.3\"}}}\n```\n\n### 2. Container can connect to another MCP server's proxy and call its tools\n\n```bash\n$ docker exec wget -qO- \\\n --header=\"Content-Type: application\/json\" \\\n --header=\"Accept: application\/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"tools\/list\",\"params\":{},\"id\":2}' \\\n http:\/\/host.docker.internal:64965\/mcp\n```\n\n**Result:** Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":3,\"result\":{\"content\":[{\"text\":\"Allowed directories:\\n\/tmp\",\"type\":\"text\"}]}}\n```\n\n### 3. Container can reach other host services\n\n```bash\n# Kubernetes API\n$ docker exec wget -qO- --no-check-certificate https:\/\/host.docker.internal:6443\/version\n{\"major\":\"1\",\"minor\":\"34\",\"gitVersion\":\"v1.34.1\"...}\n\n# Ollama LLM API\n$ docker exec wget -qO- http:\/\/host.docker.internal:11434\/api\/tags\n{\"models\":[{\"name\":\"kimi-k2:1t-cloud\"...}]}\n```\n\n## Attack Scenarios\n\n### Scenario 1: Malicious MCP server pivots to privileged native MCP tools\n\nMany users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have `execute_command`, `write_file`, or `shell` capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:\n\n1. Port-scan `host.docker.internal` to discover listening services\n2. Attempt MCP handshakes on discovered ports\n3. Call privileged tools (e.g., `execute_command(\"rm -rf \/\")` or `write_file(\"\/etc\/crontab\", \"...\")`)\n\nThis achieves **full host compromise without any container escape vulnerability**.\n\n### Scenario 2: Compromised MCP server manipulates ToolHive itself\n\nVia the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:\n\n- List and stop other running MCP servers (denial of service)\n- Start new MCP servers with attacker-controlled images\n- Modify configurations\n\n### Scenario 3: Data exfiltration via cross-MCP-server access\n\nA low-privilege MCP server (e.g., `sequentialthinking` with no file mounts) could reach the `filesystem` server's proxy and call `read_file` to access files it was never authorized to see.\n\n### Scenario 4: LLM model theft \/ abuse\n\nAs demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.\n\n## Root Causes\n\n1. **`insecure_allow_all: true` as default** \u2014 permits outbound connections to any destination including `host.docker.internal`\n2. **No authentication on ToolHive API \/ MCP proxies** \u2014 any client that can reach the port can interact fully\n3. **Docker's `host.docker.internal` DNS** \u2014 resolves to the host machine, bypassing localhost-only binding assumptions\n\n## Suggested Mitigations\n\n### Short-term\n\n- **Block `host.docker.internal` and `172.17.0.1`** (Docker gateway) in container networking by default, even when `insecure_allow_all` is enabled. These should require explicit opt-in.\n- **Add authentication to MCP proxy endpoints** \u2014 even a shared secret or token per session would prevent cross-container lateral movement.\n\n### Medium-term\n\n- **Network policy per container** \u2014 ToolHive already has the `permission_profile` infrastructure. Add support for explicit allow-lists rather than just the binary none\/all choice.\n- **Isolate container networks** \u2014 run each MCP server in its own Docker network with no access to the Docker bridge gateway.\n\n### Long-term\n\n- **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.\n- **Audit logging** \u2014 log all MCP tool calls with source identification so lateral movement attempts are visible.\n\n## Environment\n\n- ToolHive v0.9.3 (macOS desktop app, Docker runtime)\n- Docker Desktop for Mac (host.docker.internal enabled by default)\n- Tested with `docker.io\/mcp\/filesystem:latest`", "summary": "## Summary\n\nA containerized MCP server running with the default `network` permission profile (`insecure_allow_all: true`) can reach host-local services via `host.docker.internal`. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host's localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.\n\n## Severity\n\n**High** \u2014 This bypasses the container isolation model that is ToolHive's core security value proposition.\n\n## Reproduction\n\nAll tests performed from inside the `filesystem` MCP container (`docker.io\/mcp\/filesystem:latest`), started with default settings via `thv run filesystem -- \/tmp`.\n\n### 1. Container can reach the ToolHive control plane MCP endpoint\n\n```bash\n$ docker exec wget -qO- \\\n --header=\"Content-Type: application\/json\" \\\n --header=\"Accept: application\/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"evil-mcp\",\"version\":\"1.0\"}},\"id\":1}' \\\n http:\/\/host.docker.internal:50444\/mcp\n```\n\n**Result:** Full MCP handshake succeeds:\n```json\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{\"logging\":{},\"tools\":{}},\"serverInfo\":{\"name\":\"toolhive-mcp\",\"version\":\"v0.9.3\"}}}\n```\n\n### 2. Container can connect to another MCP server's proxy and call its tools\n\n```bash\n$ docker exec wget -qO- \\\n --header=\"Content-Type: application\/json\" \\\n --header=\"Accept: application\/json\" \\\n --post-data='{\"jsonrpc\":\"2.0\",\"method\":\"tools\/list\",\"params\":{},\"id\":2}' \\\n http:\/\/host.docker.internal:64965\/mcp\n```\n\n**Result:** Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":3,\"result\":{\"content\":[{\"text\":\"Allowed directories:\\n\/tmp\",\"type\":\"text\"}]}}\n```\n\n### 3. Container can reach other host services\n\n```bash\n# Kubernetes API\n$ docker exec wget -qO- --no-check-certificate https:\/\/host.docker.internal:6443\/version\n{\"major\":\"1\",\"minor\":\"34\",\"gitVersion\":\"v1.34.1\"...}\n\n# Ollama LLM API\n$ docker exec wget -qO- http:\/\/host.docker.internal:11434\/api\/tags\n{\"models\":[{\"name\":\"kimi-k2:1t-cloud\"...}]}\n```\n\n## Attack Scenarios\n\n### Scenario 1: Malicious MCP server pivots to privileged native MCP tools\n\nMany users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have `execute_command`, `write_file`, or `shell` capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:\n\n1. Port-scan `host.docker.internal` to discover listening services\n2. Attempt MCP handshakes on discovered ports\n3. Call privileged tools (e.g., `execute_command(\"rm -rf \/\")` or `write_file(\"\/etc\/crontab\", \"...\")`)\n\nThis achieves **full host compromise without any container escape vulnerability**.\n\n### Scenario 2: Compromised MCP server manipulates ToolHive itself\n\nVia the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:\n\n- List and stop other running MCP servers (denial of service)\n- Start new MCP servers with attacker-controlled images\n- Modify configurations\n\n### Scenario 3: Data exfiltration via cross-MCP-server access\n\nA low-privilege MCP server (e.g., `sequentialthinking` with no file mounts) could reach the `filesystem` server's proxy and call `read_file` to access files it was never authorized to see.\n\n### Scenario 4: LLM model theft \/ abuse\n\nAs demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.\n\n## Root Causes\n\n1. **`insecure_allow_all: true` as default** \u2014 permits outbound connections to any destination including `host.docker.internal`\n2. **No authentication on ToolHive API \/ MCP proxies** \u2014 any client that can reach the port can interact fully\n3. **Docker's `host.docker.internal` DNS** \u2014 resolves to the host machine, bypassing localhost-only binding assumptions\n\n## Suggested Mitigations\n\n### Short-term\n\n- **Block `host.docker.internal` and `172.17.0.1`** (Docker gateway) in container networking by default, even when `insecure_allow_all` is enabled. These should require explicit opt-in.\n- **Add authentication to MCP proxy endpoints** \u2014 even a shared secret or token per session would prevent cross-container lateral movement.\n\n### Medium-term\n\n- **Network policy per container** \u2014 ToolHive already has the `permission_profile` infrastructure. Add support for explicit allow-lists rather than just the binary none\/all choice.\n- **Isolate container networks** \u2014 run each MCP server in its own Docker network with no access to the Docker bridge gateway.\n\n### Long-term\n\n- **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.\n- **Audit logging** \u2014 log all MCP tool calls with source identification so lateral movement attempts are visible.\n\n## Environment\n\n- ToolHive v0.9.3 (macOS desktop app, Docker runtime)\n- Docker Desktop for Mac (host.docker.internal enabled by default)\n- Tested with `docker.io\/mcp\/filesystem:latest`", "date_published": "2026-09-19T01:00:02+00:00", "date_modified": "2026-09-19T01:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b8f-738c-a3bb-d72c32fcb98a", "title": "LMDeploy vulnerable to arbitrary code execution via eval() of untrusted quant_dtype in model config loading", "url": "https://github.com/advisories/GHSA-3hmm-rh5q-gwwr", "content_html": "### Summary\n\nlmdeploy", "summary": "### Summary\n\nlmdeploy", "date_published": "2026-09-19T01:00:02+00:00", "date_modified": "2026-09-19T01:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b94-7107-b740-70e20bfd0c25", "title": "LMDeploy has Remote Code Execution\u00a0by Pickle Deserialization via handle_zmq_recv in lmdeploy\/lmdeploy\/pytorch\/disagg\/conn\/engine_conn.py", "url": "https://github.com/advisories/GHSA-2vh9-42vm-xmv2", "content_html": "## Summary\n\nLMDeploy's PyTorch DistServe\/PD-disaggregation control plane used\n`recv_pyobj()` to deserialize messages received through a ZeroMQ PULL\nsocket. PyZMQ implements `recv_pyobj()` using Python pickle\ndeserialization, which can execute arbitrary code while reconstructing\nan object.\n\nThe peer address used by the receiver was supplied through the\n`POST \/distserve\/p2p_connect` HTTP endpoint. An attacker who could reach\nan affected DistServe API server could cause the server to connect to an\nattacker-controlled ZeroMQ endpoint and deserialize a crafted pickle\npayload.\n\nAPI-key authentication is not enabled unless the operator explicitly\nconfigures it. As a result, affected DistServe deployments without API\nkeys allowed unauthenticated remote code execution with the privileges\nof the LMDeploy serving process.\n\nThis issue affects the PyTorch backend when PD-disaggregation\/DistServe\nis enabled. Ordinary deployments that do not use the affected\ndisaggregated-serving path do not expose this data flow.\n\n## Affected components\n\n- HTTP entry point:\n `lmdeploy\/serve\/openai\/endpoints\/distserve.py`,\n `POST \/distserve\/p2p_connect`\n- Attacker-controlled peer address:\n `DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address`\n- Vulnerable receiver:\n `lmdeploy\/pytorch\/disagg\/conn\/engine_conn.py`,\n `EngineP2PConnection.handle_zmq_recv()`\n- Unsafe operation: `recv_pyobj()`, which performs pickle deserialization\n\n## Vulnerable data flow\n\n1. A caller submits a DistServe P2P connection request containing a\n ZeroMQ address.\n2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.\n3. `handle_zmq_recv()` receives messages using `recv_pyobj()`.\n4. A malicious peer sends a crafted pickle object.\n5. Python code executes during deserialization, before LMDeploy can\n perform any type or field validation.\n\n A type check performed after `recv_pyobj()` cannot mitigate this issue\n because pickle payload execution occurs during deserialization.\n\n## Impact\n\nSuccessful exploitation allows arbitrary code execution as the\nLMDeploy serving process. This can expose model weights, prompts,\ncredentials, attached storage, cluster-network services, and host or\nGPU resources. An attacker may also modify or terminate the serving\nprocess.\n\n## Affected versions\n\nAffected versions:\n\n- `lmdeploy >= 0.9.2, < 0.16.0`\n\nThe vulnerable P2P receiver was introduced in commit `b0b705f7`.\n\n## Remediation\n\nThe issue was fixed by replacing the pickle-based ZeroMQ protocol with\nJSON serialization:\n\n- `send_pyobj()` was replaced with `send_json()`.\n- `recv_pyobj()` was replaced with `recv_json()`.\n- Received objects are validated using the\n `DistServeCacheFreeRequest` Pydantic schema before use.\n- Invalid or off-schema messages are rejected without terminating the\n receive loop.\n\nFix commit:\n\nhttps:\/\/github.com\/InternLM\/lmdeploy\/commit\/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2\n\nThe fix was released in LMDeploy 0.16.0.\n\n## Workarounds\n\nUsers who cannot upgrade immediately should:\n\n- Prevent untrusted clients from reaching `\/distserve\/*` endpoints.\n- Restrict the DistServe HTTP and ZeroMQ control planes to trusted\n cluster networks.\n- Configure API-key authentication.\n- Block arbitrary outbound ZeroMQ connections from serving nodes.\n\nThese measures reduce exposure but do not make pickle deserialization\nsafe. Upgrading to LMDeploy 0.16.0 or later is recommended.", "summary": "## Summary\n\nLMDeploy's PyTorch DistServe\/PD-disaggregation control plane used\n`recv_pyobj()` to deserialize messages received through a ZeroMQ PULL\nsocket. PyZMQ implements `recv_pyobj()` using Python pickle\ndeserialization, which can execute arbitrary code while reconstructing\nan object.\n\nThe peer address used by the receiver was supplied through the\n`POST \/distserve\/p2p_connect` HTTP endpoint. An attacker who could reach\nan affected DistServe API server could cause the server to connect to an\nattacker-controlled ZeroMQ endpoint and deserialize a crafted pickle\npayload.\n\nAPI-key authentication is not enabled unless the operator explicitly\nconfigures it. As a result, affected DistServe deployments without API\nkeys allowed unauthenticated remote code execution with the privileges\nof the LMDeploy serving process.\n\nThis issue affects the PyTorch backend when PD-disaggregation\/DistServe\nis enabled. Ordinary deployments that do not use the affected\ndisaggregated-serving path do not expose this data flow.\n\n## Affected components\n\n- HTTP entry point:\n `lmdeploy\/serve\/openai\/endpoints\/distserve.py`,\n `POST \/distserve\/p2p_connect`\n- Attacker-controlled peer address:\n `DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address`\n- Vulnerable receiver:\n `lmdeploy\/pytorch\/disagg\/conn\/engine_conn.py`,\n `EngineP2PConnection.handle_zmq_recv()`\n- Unsafe operation: `recv_pyobj()`, which performs pickle deserialization\n\n## Vulnerable data flow\n\n1. A caller submits a DistServe P2P connection request containing a\n ZeroMQ address.\n2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.\n3. `handle_zmq_recv()` receives messages using `recv_pyobj()`.\n4. A malicious peer sends a crafted pickle object.\n5. Python code executes during deserialization, before LMDeploy can\n perform any type or field validation.\n\n A type check performed after `recv_pyobj()` cannot mitigate this issue\n because pickle payload execution occurs during deserialization.\n\n## Impact\n\nSuccessful exploitation allows arbitrary code execution as the\nLMDeploy serving process. This can expose model weights, prompts,\ncredentials, attached storage, cluster-network services, and host or\nGPU resources. An attacker may also modify or terminate the serving\nprocess.\n\n## Affected versions\n\nAffected versions:\n\n- `lmdeploy >= 0.9.2, < 0.16.0`\n\nThe vulnerable P2P receiver was introduced in commit `b0b705f7`.\n\n## Remediation\n\nThe issue was fixed by replacing the pickle-based ZeroMQ protocol with\nJSON serialization:\n\n- `send_pyobj()` was replaced with `send_json()`.\n- `recv_pyobj()` was replaced with `recv_json()`.\n- Received objects are validated using the\n `DistServeCacheFreeRequest` Pydantic schema before use.\n- Invalid or off-schema messages are rejected without terminating the\n receive loop.\n\nFix commit:\n\nhttps:\/\/github.com\/InternLM\/lmdeploy\/commit\/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2\n\nThe fix was released in LMDeploy 0.16.0.\n\n## Workarounds\n\nUsers who cannot upgrade immediately should:\n\n- Prevent untrusted clients from reaching `\/distserve\/*` endpoints.\n- Restrict the DistServe HTTP and ZeroMQ control planes to trusted\n cluster networks.\n- Configure API-key authentication.\n- Block arbitrary outbound ZeroMQ connections from serving nodes.\n\nThese measures reduce exposure but do not make pickle deserialization\nsafe. Upgrading to LMDeploy 0.16.0 or later is recommended.", "date_published": "2026-09-22T01:00:01+00:00", "date_modified": "2026-09-22T01:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b72d-6b97-7235-8ea2-4dddd5c4ad0f", "title": "Semantic MediaWiki affected by reflected XSS in `Special:Ask` via a forged cursor pagination token", "url": "https://github.com/advisories/GHSA-cx86-7xwp-w9wf", "content_html": "## Reflected XSS via a forged cursor pagination token\n\n#### Failure mode\n\n`Special:Ask` accepts a `cursor` query parameter for keyset pagination (added in 7.0.0). The token is decoded by `CursorEncoder`, which is an **unsigned** base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's `sort=` \/ `order=`, `QueryCreator::applyCursorIfRequested()` builds an error message by interpolating the attacker-controlled `sort_prop` \/ `sort_order` values into a raw string via `Query::addErrors()`.\n\nUnlike SMW's message-key errors, this raw string bypasses the message layer's sanitisation (`ProcessingErrorMsgHandler::normalizeAndDecodeMessages()` passes a non-key, non-encoded string through unchanged). `ErrorWidget::queryError()` then assembles the errors and passes them to `Html::errorBox()`, whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted `cursor` token containing markup in `sort_prop` (or `sort_order`) executes script in the victim's browser on the wiki origin.\n\nNo authentication or special permission is required. The payload is delivered via a crafted link, e.g. `Special:Ask?q=...&p[cursor]=` where the token decodes to `{\"v\":1,\"sort_prop\":\"...\"}`. Confirmed executing in a browser; the responses carry no Content-Security-Policy, so inline script is not blocked.\n\n#### Remediation\n\n- Output-encode the attacker-controlled `sort_prop` \/ `sort_order` values before they are interpolated into the error text in `QueryCreator`, so no raw user input enters the error stream.\n- Defense in depth: the `format=debug` output path that reflected the same error text was hardened separately in GHSA-q5fm-9mx6-44f4.\n\n#### Maintenance note\n\nQuery error strings are rendered as raw HTML by `ErrorWidget::queryError()` via `Html::errorBox()`. Any error added through `Query::addErrors()` that embeds user-controlled text must be output-encoded (or use a message key); pagination and validation error text is attacker-influenced and must not be treated as trusted.", "summary": "## Reflected XSS via a forged cursor pagination token\n\n#### Failure mode\n\n`Special:Ask` accepts a `cursor` query parameter for keyset pagination (added in 7.0.0). The token is decoded by `CursorEncoder`, which is an **unsigned** base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's `sort=` \/ `order=`, `QueryCreator::applyCursorIfRequested()` builds an error message by interpolating the attacker-controlled `sort_prop` \/ `sort_order` values into a raw string via `Query::addErrors()`.\n\nUnlike SMW's message-key errors, this raw string bypasses the message layer's sanitisation (`ProcessingErrorMsgHandler::normalizeAndDecodeMessages()` passes a non-key, non-encoded string through unchanged). `ErrorWidget::queryError()` then assembles the errors and passes them to `Html::errorBox()`, whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted `cursor` token containing markup in `sort_prop` (or `sort_order`) executes script in the victim's browser on the wiki origin.\n\nNo authentication or special permission is required. The payload is delivered via a crafted link, e.g. `Special:Ask?q=...&p[cursor]=` where the token decodes to `{\"v\":1,\"sort_prop\":\"...\"}`. Confirmed executing in a browser; the responses carry no Content-Security-Policy, so inline script is not blocked.\n\n#### Remediation\n\n- Output-encode the attacker-controlled `sort_prop` \/ `sort_order` values before they are interpolated into the error text in `QueryCreator`, so no raw user input enters the error stream.\n- Defense in depth: the `format=debug` output path that reflected the same error text was hardened separately in GHSA-q5fm-9mx6-44f4.\n\n#### Maintenance note\n\nQuery error strings are rendered as raw HTML by `ErrorWidget::queryError()` via `Html::errorBox()`. Any error added through `Query::addErrors()` that embeds user-controlled text must be output-encoded (or use a message key); pagination and validation error text is attacker-influenced and must not be treated as trusted.", "date_published": "2026-09-19T01:00:02+00:00", "date_modified": "2026-09-19T01:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b5ad-2fec-7073-af96-89d08ab2de8a", "title": "CVE-2026-93688: SGLang through 0.5.19 in prefill\/decode disaggregation mode with Mooncake KV transfer backend fails to validate bootstra", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93688", "content_html": "SGLang through 0.5.19 in prefill\/decode disaggregation mode with Mooncake KV transfer backend fails to validate bootstrap_room values, allowing unbounded transfer state allocation. Unauthenticated attackers can reach the decode engine's POST \/generate endpoint and submit arbitrary bootstrap_room values to exhaust prefill process memory until out-of-memory termination.", "summary": "SGLang through 0.5.19 in prefill\/decode disaggregation mode with Mooncake KV transfer backend fails to validate bootstrap_room values, allowing unbounded transfer state allocation. Unauthenticated attackers can reach the decode engine's POST \/generate endpoint and submit arbitrary bootstrap_room values to exhaust prefill process memory until out-of-memory termination.", "date_published": "2026-09-19T12:00:02+00:00", "date_modified": "2026-09-19T12:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b5ad-2fe2-7098-b4c2-5536bf87b738", "title": "CVE-2026-93592: vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the \/v1\/embeddings and \/pooling endpoints, ", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93592", "content_html": "vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the \/v1\/embeddings and \/pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.", "summary": "vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the \/v1\/embeddings and \/pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.", "date_published": "2026-09-19T12:00:02+00:00", "date_modified": "2026-09-19T12:00:02+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b4d1-28ed-71d2-aeec-08f909bbbd2c", "title": "AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code", "url": "https://www.securityweek.com/ai-built-exploit-and-sign-in-flaw-opened-path-to-internal-openai-code/", "content_html": "Hacktron researchers earned a bug bounty after demonstrating access to OpenAI employee accounts.\u00a0\nThe post AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code appeared first on SecurityWeek.", "summary": "Hacktron researchers earned a bug bounty after demonstrating access to OpenAI employee accounts.\u00a0\nThe post AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code appeared first on SecurityWeek.", "date_published": "2026-09-21T14:00:01+00:00", "date_modified": "2026-09-21T14:00:01+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b4d1-26b9-7004-bb6c-b21b192a5269", "title": "Plugin4Shell Lets Repository Owners Swap Pinned Plugin Code Across Four AI Coding Agents", "url": "https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html", "content_html": "A flaw in four widely used AI coding agents lets someone who controls a plugin's code repository swap the plugin an agent installs for a malicious one, even when the agent locked that plugin to a specific reviewed version, security firm\u00a0Air Security said on Thursday.\n\nThe firm said Anthropic has patched the flaw in Claude Code 2.1.179 and OpenAI in Codex 0.146.0, that GitHub Copilot has no", "summary": "A flaw in four widely used AI coding agents lets someone who controls a plugin's code repository swap the plugin an agent installs for a malicious one, even when the agent locked that plugin to a specific reviewed version, security firm\u00a0Air Security said on Thursday.\n\nThe firm said Anthropic has patched the flaw in Claude Code 2.1.179 and OpenAI in Codex 0.146.0, that GitHub Copilot has no", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] }, { "id": "https://vulnwatch.ai/01a0b3f5-6bdc-73af-b56d-71cac0544195", "title": "Claimed Bug Bounty Hunter Likely Used LLM to Build PhantomRaven npm Stealer", "url": "https://thehackernews.com/2026/09/claimed-bug-bounty-hunter-likely-used.html", "content_html": "A financially motivated threat actor has been linked to the development and distribution of a JavaScript (JS)-based information stealer known as PhantomRaven via the npm package registry.\n\n\"The developer likely wrote the malware using a large language model (LLM), an assessment made with high confidence based on verbose comments, placeholder code, and statistical token-analysis patterns,\"", "summary": "A financially motivated threat actor has been linked to the development and distribution of a JavaScript (JS)-based information stealer known as PhantomRaven via the npm package registry.\n\n\"The developer likely wrote the malware using a large language model (LLM), an assessment made with high confidence based on verbose comments, placeholder code, and statistical token-analysis patterns,\"", "date_published": "2026-09-22T16:00:14+00:00", "date_modified": "2026-09-22T16:00:14+00:00", "authors": [{ "name": "VulnWatch" }], "tags": [ ] } ] }