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.

عند التشغيل في وضع HTTP مع تمكين `--lockdown-mode`، يتم تنفيذ `RepoAccessCache` كعنصر فريد شامل للعملية. يتم تهيئة هذا العنصر الفريد باستخدام عميل GraphQL الخاص بأول مستخدم تمت مصادقته، وتستمر الطلبات اللاحقة من مستخدمين مختلفين في استخدام نفس المثيل. ونتيجة لذلك، يتم تنفيذ استعلامات GraphQL المتعلقة بالحظر باستخدام بيانات اعتماد المستخدم الأول بدلاً من رمز الطلب الحالي. تؤثر هذه المشكلة على الدالة `GetInstance()` الموجودة في `pkg/lockdown/lockdown.go`، والتي تفشل في تحديث العميل الداخلي عند استدعائها من قبل مستخدمين مختلفين. ويؤدي ذلك إلى نتائج غير صحيحة في الدالة `IsSafeContent()`، التي تعتمد على `queryRepoAccessInfo` لتحديد ما إذا كان يجب الوثوق بالمحتوى الوارد من المساهمين الخارجيين أو تنقيته. تشمل الآثار المحتملة عمليات فحص غير صحيحة لرؤية المستودع، والوصول غير المصرح به إلى البيانات المخزنة مؤقتًا استنادًا إلى أذونات المستخدم الأول، وفشل تام لحماية الإغلاق في حالة انتهاء صلاحية رمز المستخدم الأول.