<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <atom:link href="https://vulnwatch.ai/feed" rel="self" type="application/rss+xml" />
        <title><![CDATA[VulnWatch — AI Security Tracker]]></title>
        <link><![CDATA[https://vulnwatch.ai/feed]]></link>
        <description><![CDATA[Curated AI/ML security vulnerabilities, advisories, and breach disclosures.]]></description>
        <language>en-US</language>
        <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>

                    <item>
                <title><![CDATA[AI Agents Are Rewriting the Rules of Lateral Movement]]></title>
                <link>https://thehackernews.com/2026/09/ai-agents-are-rewriting-rules-of.html</link>
                <description><![CDATA[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?

A 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]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2025-14486: The PixelPlay plugin for WordPress is vulnerable to unauthorized API key deletion due to missing authorization checks in]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2025-14486</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Transformers now runs llama.cpp quants]]></title>
                <link>https://huggingface.co/blog/transformers-llama-cpp-quants</link>
                <description><![CDATA[]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Jun Kim, oMLX creator and maintainer, joins Hugging Face to support the MLX community]]></title>
                <link>https://huggingface.co/blog/omlx</link>
                <description><![CDATA[]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94627: vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child reque]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94627</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94626: vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoi]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94626</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94625: vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests cr]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94625</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94624: vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configur]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94624</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94623: vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation tha]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94623</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94622: vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for pre]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94622</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-77518</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-61647: NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content ]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-61647</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-61612</link>
                <description><![CDATA[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 — strictly more than CVE-2026-53509, which only reached loopback. Version 0.4.108 contains an updated fix.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-88978: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.106.1, t]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-88978</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-84298: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.95.3, th]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-84298</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-63342: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, ap]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-63342</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-61687: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, Va]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-61687</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-61681: Hatchet is a platform for orchestrating background tasks, AI agents, and durable workflows at scale. Prior to 0.91.1, th]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-61681</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-55563</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-55071</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:06 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[⚡ Weekly Recap: Cisco 0-Day, AI Agent RCE, ClickFix Attacks, ClickFix Surge, and Browser Hijacks]]></title>
                <link>https://thehackernews.com/2026/09/weekly-recap-cisco-0-day-ai-agent-rce.html</link>
                <description><![CDATA[A browser. A plugin. A package. A login screen. Normal stuff. That is basically the problem this week.

The 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]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Pruning LLMs Like a Physicist: Block Removal as an Ising Optimization Problem]]></title>
                <link>https://huggingface.co/blog/MultiverseComputingCAI/pruning-llms-like-a-physicist-block-removal-as-an</link>
                <description><![CDATA[]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Google Confirms Gemini AI Breached Three Firms]]></title>
                <link>https://www.securityweek.com/google-confirms-gemini-ai-breached-three-firms/</link>
                <description><![CDATA[Google is the latest AI giant to confirm that its models escaped a testing environment and hacked real companies.
The post Google Confirms Gemini AI Breached Three Firms appeared first on SecurityWeek.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 02:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94093</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Mon, 21 Sep 2026 18:00:04 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-94111: Tencent BrowserSkill through 0.3.0 contains an authentication bypass vulnerability in the local daemon WebSocket origin ]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-94111</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Mon, 21 Sep 2026 06:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Researchers escape OpenAI Codex sandbox to run commands on host]]></title>
                <link>https://www.bleepingcomputer.com/news/security/researchers-escape-openai-codex-sandbox-to-run-commands-on-host/</link>
                <description><![CDATA[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. [...]]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 14:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93993: Mistral Vibe before 2.25.5 contains a remote code execution vulnerability in the worktree creation process that executes]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93993</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sun, 20 Sep 2026 18:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93989</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sun, 20 Sep 2026 18:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Claude Opus 5 Helped Researchers Take Over OpenAI Staff Accounts via Chained Flaws]]></title>
                <link>https://thehackernews.com/2026/09/claude-opus-5-helped-researchers-take.html</link>
                <description><![CDATA[Three researchers at the security firm Hacktron used 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.

The 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.

This was security research,]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[BragJack attacks hijack AI browser agents through malicious extensions]]></title>
                <link>https://www.bleepingcomputer.com/news/security/bragjack-attacks-hijack-ai-browser-agents-through-malicious-extensions/</link>
                <description><![CDATA[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. [...]]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 12:00:13 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93982: OpenPanel through commit bad75bdd writes Model Context Protocol authentication tokens from URL query parameters to plain]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93982</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sun, 20 Sep 2026 12:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Google Gemini Broke Into Real Company Systems After Security Test Domain Mix-Up]]></title>
                <link>https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html</link>
                <description><![CDATA[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.

The 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]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93841: vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton _bincount_kernel where prompt token IDs ind]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93841</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 18:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93840: vLLM before 0.29.0 validates allowed_token_ids against tokenizer length instead of model output logits width in Sampling]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93840</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 18:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93838: SGLang versions through 0.5.20 contain an unbounded memory allocation vulnerability in handle_staging_req() that fails t]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93838</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 18:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-33625: LMDeploy is a toolkit for compressing, deploying, and serving large language models. Versions 012.1 through 0.12.2 conta]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-33625</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 18:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2025-66455: LMDeploy is a toolkit for compressing, deploying, and serving large language models. Starting in version 0.9.2 and prior]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2025-66455</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 18:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Obot: Server-Side Request Forgery via remote MCP server URL]]></title>
                <link>https://github.com/advisories/GHSA-jgh3-fggc-mcpm</link>
                <description><![CDATA[## Summary

In 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.

## Am I affected?

You are affected if you run Obot `]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 01:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Obot: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion]]></title>
                <link>https://github.com/advisories/GHSA-xwmw-prc4-v3cr</link>
                <description><![CDATA[## Summary

In 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 — rather than being scoped to just the requested MCP server.

## Am I affected?

You are affected if you run Obot `]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 01:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-77616: Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's ]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-77616</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 12:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-58197: ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to Too]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-58197</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 12:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement]]></title>
                <link>https://github.com/advisories/GHSA-qg2g-g9w3-m5h8</link>
                <description><![CDATA[## Summary

A 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.

## Severity

**High** — This bypasses the container isolation model that is ToolHive's core security value proposition.

## Reproduction

All tests performed from inside the `filesystem` MCP container (`docker.io/mcp/filesystem:latest`), started with default settings via `thv run filesystem -- /tmp`.

### 1. Container can reach the ToolHive control plane MCP endpoint

```bash
$ docker exec  wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"evil-mcp","version":"1.0"}},"id":1}' \
  http://host.docker.internal:50444/mcp
```

**Result:** Full MCP handshake succeeds:
```json
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"logging":{},"tools":{}},"serverInfo":{"name":"toolhive-mcp","version":"v0.9.3"}}}
```

### 2. Container can connect to another MCP server's proxy and call its tools

```bash
$ docker exec  wget -qO- \
  --header="Content-Type: application/json" \
  --header="Accept: application/json" \
  --post-data='{"jsonrpc":"2.0","method":"tools/list","params":{},"id":2}' \
  http://host.docker.internal:64965/mcp
```

**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:

```json
{"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"Allowed directories:\n/tmp","type":"text"}]}}
```

### 3. Container can reach other host services

```bash
# Kubernetes API
$ docker exec  wget -qO- --no-check-certificate https://host.docker.internal:6443/version
{"major":"1","minor":"34","gitVersion":"v1.34.1"...}

# Ollama LLM API
$ docker exec  wget -qO- http://host.docker.internal:11434/api/tags
{"models":[{"name":"kimi-k2:1t-cloud"...}]}
```

## Attack Scenarios

### Scenario 1: Malicious MCP server pivots to privileged native MCP tools

Many 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:

1. Port-scan `host.docker.internal` to discover listening services
2. Attempt MCP handshakes on discovered ports
3. Call privileged tools (e.g., `execute_command("rm -rf /")` or `write_file("/etc/crontab", "...")`)

This achieves **full host compromise without any container escape vulnerability**.

### Scenario 2: Compromised MCP server manipulates ToolHive itself

Via the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:

- List and stop other running MCP servers (denial of service)
- Start new MCP servers with attacker-controlled images
- Modify configurations

### Scenario 3: Data exfiltration via cross-MCP-server access

A 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.

### Scenario 4: LLM model theft / abuse

As demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.

## Root Causes

1. **`insecure_allow_all: true` as default** — permits outbound connections to any destination including `host.docker.internal`
2. **No authentication on ToolHive API / MCP proxies** — any client that can reach the port can interact fully
3. **Docker's `host.docker.internal` DNS** — resolves to the host machine, bypassing localhost-only binding assumptions

## Suggested Mitigations

### Short-term

- **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.
- **Add authentication to MCP proxy endpoints** — even a shared secret or token per session would prevent cross-container lateral movement.

### Medium-term

- **Network policy per container** — ToolHive already has the `permission_profile` infrastructure. Add support for explicit allow-lists rather than just the binary none/all choice.
- **Isolate container networks** — run each MCP server in its own Docker network with no access to the Docker bridge gateway.

### Long-term

- **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.
- **Audit logging** — log all MCP tool calls with source identification so lateral movement attempts are visible.

## Environment

- ToolHive v0.9.3 (macOS desktop app, Docker runtime)
- Docker Desktop for Mac (host.docker.internal enabled by default)
- Tested with `docker.io/mcp/filesystem:latest`]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 01:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[LMDeploy vulnerable to arbitrary code execution via eval() of untrusted quant_dtype in model config loading]]></title>
                <link>https://github.com/advisories/GHSA-3hmm-rh5q-gwwr</link>
                <description><![CDATA[### Summary

lmdeploy]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 01:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[LMDeploy has Remote Code Execution by Pickle Deserialization via handle_zmq_recv in lmdeploy/lmdeploy/pytorch/disagg/conn/engine_conn.py]]></title>
                <link>https://github.com/advisories/GHSA-2vh9-42vm-xmv2</link>
                <description><![CDATA[## Summary

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.

## Affected components

- HTTP entry point:
  `lmdeploy/serve/openai/endpoints/distserve.py`,
  `POST /distserve/p2p_connect`
- Attacker-controlled peer address:
  `DistServeConnectionRequest.remote_engine_endpoint_info.zmq_address`
- Vulnerable receiver:
  `lmdeploy/pytorch/disagg/conn/engine_conn.py`,
  `EngineP2PConnection.handle_zmq_recv()`
- Unsafe operation: `recv_pyobj()`, which performs pickle deserialization

## Vulnerable data flow

1. A caller submits a DistServe P2P connection request containing a
   ZeroMQ address.
2. The LMDeploy engine connects its ZeroMQ PULL socket to that address.
3. `handle_zmq_recv()` receives messages using `recv_pyobj()`.
4. A malicious peer sends a crafted pickle object.
5. Python code executes during deserialization, before LMDeploy can
   perform any type or field validation.

  A type check performed after `recv_pyobj()` cannot mitigate this issue
  because pickle payload execution occurs during deserialization.

## Impact

Successful exploitation allows arbitrary code execution as the
LMDeploy serving process. This can expose model weights, prompts,
credentials, attached storage, cluster-network services, and host or
GPU resources. An attacker may also modify or terminate the serving
process.

## Affected versions

Affected versions:

- `lmdeploy >= 0.9.2, < 0.16.0`

The vulnerable P2P receiver was introduced in commit `b0b705f7`.

## Remediation

The issue was fixed by replacing the pickle-based ZeroMQ protocol with
JSON serialization:

- `send_pyobj()` was replaced with `send_json()`.
- `recv_pyobj()` was replaced with `recv_json()`.
- Received objects are validated using the
  `DistServeCacheFreeRequest` Pydantic schema before use.
- Invalid or off-schema messages are rejected without terminating the
  receive loop.

Fix commit:

https://github.com/InternLM/lmdeploy/commit/f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2

The fix was released in LMDeploy 0.16.0.

## Workarounds

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.
- Block arbitrary outbound ZeroMQ connections from serving nodes.

These measures reduce exposure but do not make pickle deserialization
safe. Upgrading to LMDeploy 0.16.0 or later is recommended.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 01:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Semantic MediaWiki affected by reflected XSS in `Special:Ask` via a forged cursor pagination token]]></title>
                <link>https://github.com/advisories/GHSA-cx86-7xwp-w9wf</link>
                <description><![CDATA[## Reflected XSS via a forged cursor pagination token

#### Failure mode

`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 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.

No 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.

#### Remediation

- 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.
- Defense in depth: the `format=debug` output path that reflected the same error text was hardened separately in GHSA-q5fm-9mx6-44f4.

#### Maintenance note

Query 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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 01:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[CVE-2026-93688: SGLang through 0.5.19 in prefill/decode disaggregation mode with Mooncake KV transfer backend fails to validate bootstra]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93688</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 12:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[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, ]]></title>
                <link>https://nvd.nist.gov/vuln/detail/CVE-2026-93592</link>
                <description><![CDATA[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.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Sat, 19 Sep 2026 12:00:02 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code]]></title>
                <link>https://www.securityweek.com/ai-built-exploit-and-sign-in-flaw-opened-path-to-internal-openai-code/</link>
                <description><![CDATA[Hacktron researchers earned a bug bounty after demonstrating access to OpenAI employee accounts. 
The post AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code appeared first on SecurityWeek.]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Mon, 21 Sep 2026 14:00:01 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Plugin4Shell Lets Repository Owners Swap Pinned Plugin Code Across Four AI Coding Agents]]></title>
                <link>https://thehackernews.com/2026/09/plugin4shell-lets-repository-owners.html</link>
                <description><![CDATA[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 Air Security said on Thursday.

The 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]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
                    <item>
                <title><![CDATA[Claimed Bug Bounty Hunter Likely Used LLM to Build PhantomRaven npm Stealer]]></title>
                <link>https://thehackernews.com/2026/09/claimed-bug-bounty-hunter-likely-used.html</link>
                <description><![CDATA[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.

"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,"]]></description>
                <author><![CDATA[VulnWatch]]></author>
                <pubDate>Tue, 22 Sep 2026 16:00:14 +0000</pubDate>
                            </item>
            </channel>
</rss>
