CVE-2026-33075: Fastgpt Security Vulnerability (CVSS 9.4)

FastGPT is an AI Agent building platform. Prior to version 4.14.9.5, FastGPT's MCP (Model Context Protocol) tools endpoints (/api/core/app/mcpTools/getTools and /api/core/app/mcpTools/runTool) accept a user-supplied URL parameter and make server-side HTTP requests to it without validating whether the URL points to an internal/private network address. Although the application has a dedicated isInternalAddress() function for SSRF protection (used in other endpoints like the HTTP workflow node), the MCP tools endpoints do not call this function. An authenticated attacker can use these endpoints to scan internal networks, access cloud metadata services, and interact with internal services such as MongoDB and Redis. This issue has been patched in version 4.14.9.5.

FastGPT is an AI Agent building platform. Prior to version 4.14.9.5, the FastGPT HTTP tools testing endpoint (/api/core/app/httpTools/runTool) is exposed without any authentication. This endpoint acts as a full HTTP proxy — it accepts a user-supplied baseUrl, toolPath, HTTP method, custom headers, and body, then makes a server-side HTTP request and returns the complete response to the caller. This issue has been patched in version 4.14.9.5.

MOOS essential-moos pAntler through 10.0.1 contains a remote code execution vulnerability that allows unauthenticated attackers to execute arbitrary programs by publishing a crafted MISSION_FILE message to the MOOSDB. Attackers can publish a mission file containing malicious Run entries that pAntler parses and executes via execvp() without authentication validation.

The Angular Language Service VS Code Extension provides a rich editing experience for Angular templates. Prior to 21.2.4, the client-side Angular Language Service VS Code extension reads the custom TypeScript SDK paths typescript.tsdk and js/ts.tsdk.path directly from workspace configurations (.vscode/settings.json) without verifying VS Code Workspace Trust state or asking for user consent (located in client/src/client.ts). The client-side extension then passes the parsed settings path as a command-line argument (--tsdk) to the background Node.js language server process. During server initialization, the background language server resolves and dynamically imports (via standard Node.js require()) the module library tsserverlibrary.js relative to the workspace-specified custom directory path. An attacker can exploit this behavior by committing a repository containing a local malicious tsserverlibrary.js script inside a custom folder, and a crafted .vscode/settings.json file pointing to that folder. When a developer opens the repository folder in VS Code, the extension automatically attempts to initialize and load the server, which dynamically resolves, loads, and executes the malicious script silently in the background. This vulnerability is fixed in 21.2.4.

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. An exception like NoHttpResponseException can indicate transient errors. If the errors persist after a maximum number of retries, Gradle would continue to the next repository. This behavior could allow an attacker to disrupt the service of a repository and leverage another repository to serve malicious artifacts. This attack requires the attacker to have control over a repository after the disrupted repository. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.

Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. If a Gradle build used an unresolvable host name, Gradle would continue to work as long as all dependencies could be resolved from another repository. An unresolvable host name could be caused by allowing a repository's domain name registration to lapse or typo-ing the real domain name. This behavior could allow an attacker to register a service under the host name used by the build and serve malicious artifacts. The attack requires the repository to be listed before others in the build configuration. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.