Hewei-Gikaku

The `upload attachment()` function in both the Jira and Confluence modules fails to constrain the resolved path to the server workspace, allowing the use of absolute paths and traversal sequences. This occurs because the function does not call `validate safe path()`, enabling an authenticated MCP caller with attachment access to read arbitrary server-local files (such as `/etc/passwd` or `/proc/self/environ`) and exfiltrate them by uploading them as attachments to a Jira or Confluence instance. The issue affects the `upload attachment()` function in `src/mcp atlassian/jira/attachments.py` and `src/mcp atlassian/confluence/attachments.py`, as well as the ` upload attachment direct()` function in `src/mcp atlassian/confluence/attachments.py`. The vulnerable parameter is `file path`.

When registry authentication is enabled via the `OBOT SERVER ENABLE REGISTRY AUTH` variable, the software fails to enforce authentication on MCP Registry endpoints under the `/v0.1/*` path. This occurs because the authorizer uses a fixed set of protected prefixes and default-allows others; since the `/v0.1` prefix was missing from this set, anonymous requests were authorized before reaching the authentication challenge. Unauthenticated attackers can send GET requests to the `/v0.1/servers` endpoint to read registry metadata, including server names, descriptions, repository URLs, and connect URLs. This issue does not expose credential values, and unauthenticated users cannot connect to the servers as the connection process remains protected.

Obot contains a server-side request forgery (SSRF) issue during remote MCP server registration. Privileged users with Power User, Power User Plus, or Admin roles can specify arbitrary URLs in the `RemoteRuntimeConfig.URL` variable without destination validation. The system fails to block requests to loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (`169.254.169.254`). Consequently, an attacker can coerce the server into making requests to internal services and the cloud instance metadata service, reading the responses via error messages to disclose sensitive information, such as cloud IAM credentials.

When operating in HTTP mode with `--lockdown-mode` enabled, the `RepoAccessCache` is implemented as a process-global singleton. This singleton is initialized using the GraphQL client of the first authenticated user, and subsequent requests from different users continue to use this same instance. Consequently, lockdown-related GraphQL queries are executed using the credentials of the first user rather than the current requester's token. This issue affects the `GetInstance()` function in `pkg/lockdown/lockdown.go`, which fails to update the internal client when called by different users. This leads to incorrect results in the `IsSafeContent()` function, which relies on `queryRepoAccessInfo` to determine if content from external contributors should be trusted or sanitized. Potential impacts include incorrect repository visibility checks, unauthorized access to cached data based on the first user's permissions, and a total failure of lockdown protection if the first user's token expires.