Thai Son Dinh

The `web.NewHandler` static file server in `web/handler.go` fails to verify that the result of joining the URL-decoded `r.URL.Path` with `Config.AppDir` remains within the configured application directory. An unauthenticated remote attacker can use URL-encoded dot segments, such as `%2e%2e`, to bypass the traversal redirect performed by Go's ServeMux. This allows the attacker to access and disclose files outside of `Config.AppDir` that are readable by the server process, even when Dev mode is disabled.

A session fixation issue exists because the login process fails to regenerate the PHP session ID. This allows an attacker who has set or obtained a victim's pre-authentication `YesWiki-*` session cookie to reuse that identifier after the victim authenticates, enabling the attacker to hijack the session, access private content, and perform actions using the victim's privileges.

Authenticated administrators can perform an unrestricted file upload by using the Bazar CSV import preview. By importing a CSV file where the file or image field references a remote .php URL, an attacker can write remote files into the web-accessible `files/` directory. Because the system does not perform extension checks, the uploaded file can be executed as server-side code.

Insufficient session expiration occurs because password reset tokens lack expiry timestamps. This allows attackers who obtain an unused reset URL from mailboxes, logs, backups, or browser history to submit a new password through the `checkEmailKey()` function and take over accounts.

OAuthConfig writes a plaintext fallback file containing `access token` and `refresh token` within the user's `.mcp-atlassian` directory. This file is created using process-default permissions rather than restrictive ones. On systems with a permissive umask, local users or processes in the same group can read these persisted tokens and reuse them to gain unauthorized access to Atlassian products. The issue occurs during the execution of the `OAuthConfig. save tokens()` function, which unconditionally maintains a plaintext copy of the tokens in `~/.mcp-atlassian/oauth-<client id>.json` for backwards compatibility, even when keyring storage is successful.

Jira and Confluence attachment upload tools accept arbitrary local filesystem paths and send the selected bytes to Atlassian. In HTTP or multi-user deployments, a caller can cross the client-to-server filesystem boundary to disclose configuration, credentials, mounted secrets, or other files readable by the MCP process. This server-side arbitrary file read and exfiltration occurs because the implementation converts relative paths to absolute paths and opens them without validating if the path is safe or restricted to an allowed directory. The issue affects the following components: - **API Endpoints:** The attachment upload tools for Jira and Confluence. - **Vulnerable Parameters:** The `file path` parameter and the `attachments` field (which accepts JSON or CSV local paths). - **Function Names:** `jira upload attachment()`, `confluence upload attachment()`, and `upload attachment()`.

Requests to the HTTP MCP endpoint without a per-user identity can reach tool handlers that utilize globally configured Jira or Confluence credentials. This allows a network caller to perform operations using the permissions of the operator account if the deployment lacks an independent authentication boundary. The processing flow involves `streamable-http`, `UserTokenMiddleware`, ` get fetcher`, and global credentials.