CWE-345
DiscouragedInsufficient Verification of Data Authenticity
Abstraction: Class · Status: Draft
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
944 vulnerabilities reference this CWE, most recent first.
GHSA-P2WF-95F3-Q546
Vulnerability from github – Published: 2023-12-21 12:30 – Updated: 2023-12-21 12:30In JetBrains IntelliJ IDEA before 2023.3.2 code execution was possible in Untrusted Project mode via a malicious plugin repository specified in the project configuration
{
"affected": [],
"aliases": [
"CVE-2023-51655"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-349"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-21T10:15:36Z",
"severity": "MODERATE"
},
"details": "In JetBrains IntelliJ IDEA before 2023.3.2 code execution was possible in Untrusted Project mode via a malicious plugin repository specified in the project configuration",
"id": "GHSA-p2wf-95f3-q546",
"modified": "2023-12-21T12:30:28Z",
"published": "2023-12-21T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51655"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P2WM-HVRR-C5C3
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42An issue was discovered in heinekingmedia StashCat through 1.7.5 for Android, through 0.0.80w for Web, and through 0.0.86 for Desktop. The product's protocol only tries to ensure confidentiality. In the whole protocol, no integrity or authenticity checks are done. Therefore man-in-the-middle attackers can conduct replay attacks.
{
"affected": [],
"aliases": [
"CVE-2017-11130"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-01T14:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in heinekingmedia StashCat through 1.7.5 for Android, through 0.0.80w for Web, and through 0.0.86 for Desktop. The product\u0027s protocol only tries to ensure confidentiality. In the whole protocol, no integrity or authenticity checks are done. Therefore man-in-the-middle attackers can conduct replay attacks.",
"id": "GHSA-p2wm-hvrr-c5c3",
"modified": "2022-05-13T01:42:08Z",
"published": "2022-05-13T01:42:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11130"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/Jul/90"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P4GJ-RMQV-7H27
Vulnerability from github – Published: 2022-07-27 00:00 – Updated: 2022-08-03 00:00Motorola ACE1000 RTUs through 2022-05-02 mishandle application integrity. They allow for custom application installation via either STS software, the C toolkit, or the ACE1000 Easy Configurator. In the case of the Easy Configurator, application images (as PLX/DAT/APP/CRC files) are uploaded via the Web UI. In case of the C toolkit, they are transferred and installed using SFTP/SSH. In each case, application images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks.
{
"affected": [],
"aliases": [
"CVE-2022-30269"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-26T23:15:00Z",
"severity": "HIGH"
},
"details": "Motorola ACE1000 RTUs through 2022-05-02 mishandle application integrity. They allow for custom application installation via either STS software, the C toolkit, or the ACE1000 Easy Configurator. In the case of the Easy Configurator, application images (as PLX/DAT/APP/CRC files) are uploaded via the Web UI. In case of the C toolkit, they are transferred and installed using SFTP/SSH. In each case, application images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks.",
"id": "GHSA-p4gj-rmqv-7h27",
"modified": "2022-08-03T00:00:54Z",
"published": "2022-07-27T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30269"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-179-06"
},
{
"type": "WEB",
"url": "https://www.forescout.com/blog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P5J9-FJFF-QRMR
Vulnerability from github – Published: 2026-04-25 18:32 – Updated: 2026-04-25 18:32A security vulnerability has been detected in Cesanta Mongoose up to 7.20. This issue affects the function mg_aes_gcm_decrypt of the file /src/tls_aes128.c of the component GCM Authentication Tag Handler. Such manipulation leads to improper verification of cryptographic signature. The attack may be performed from remote. A high complexity level is associated with this attack. The exploitability is assessed as difficult. The exploit has been disclosed publicly and may be used. Upgrading to version 7.21 is capable of addressing this issue. It is advisable to upgrade the affected component. VulDB has contacted the vendor early and they confirmed quickly, that this issue got fixed already.
{
"affected": [],
"aliases": [
"CVE-2026-6986"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-25T17:16:33Z",
"severity": "MODERATE"
},
"details": "A security vulnerability has been detected in Cesanta Mongoose up to 7.20. This issue affects the function mg_aes_gcm_decrypt of the file /src/tls_aes128.c of the component GCM Authentication Tag Handler. Such manipulation leads to improper verification of cryptographic signature. The attack may be performed from remote. A high complexity level is associated with this attack. The exploitability is assessed as difficult. The exploit has been disclosed publicly and may be used. Upgrading to version 7.21 is capable of addressing this issue. It is advisable to upgrade the affected component. VulDB has contacted the vendor early and they confirmed quickly, that this issue got fixed already.",
"id": "GHSA-p5j9-fjff-qrmr",
"modified": "2026-04-25T18:32:58Z",
"published": "2026-04-25T18:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6986"
},
{
"type": "WEB",
"url": "https://github.com/cesanta/mongoose/releases/tag/7.21"
},
{
"type": "WEB",
"url": "https://github.com/dwBruijn/CVEs/blob/main/Mongoose/AESGCM.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/796231"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359529"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359529/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P6R4-24W5-R764
Vulnerability from github – Published: 2022-05-17 03:56 – Updated: 2025-04-12 12:59Allround Automations PL/SQL Developer 11 before 11.0.6 relies on unverified HTTP data for updates, which allows man-in-the-middle attackers to execute arbitrary code by modifying fields in the client-server data stream.
{
"affected": [],
"aliases": [
"CVE-2016-2346"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-04-25T18:59:00Z",
"severity": "HIGH"
},
"details": "Allround Automations PL/SQL Developer 11 before 11.0.6 relies on unverified HTTP data for updates, which allows man-in-the-middle attackers to execute arbitrary code by modifying fields in the client-server data stream.",
"id": "GHSA-p6r4-24w5-r764",
"modified": "2025-04-12T12:59:13Z",
"published": "2022-05-17T03:56:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-2346"
},
{
"type": "WEB",
"url": "https://adamcaudill.com/2016/02/02/plsql-developer-nonexistent-encryption"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/229047"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-P6VJ-J24G-56WP
Vulnerability from github – Published: 2022-05-13 01:29 – Updated: 2022-05-13 01:29client_side.cc in Squid before 3.5.18 and 4.x before 4.0.10 does not properly ignore the Host header when absolute-URI is provided, which allows remote attackers to conduct cache-poisoning attacks via an HTTP request.
{
"affected": [],
"aliases": [
"CVE-2016-4553"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-05-10T19:59:00Z",
"severity": "HIGH"
},
"details": "client_side.cc in Squid before 3.5.18 and 4.x before 4.0.10 does not properly ignore the Host header when absolute-URI is provided, which allows remote attackers to conduct cache-poisoning attacks via an HTTP request.",
"id": "GHSA-p6vj-j24g-56wp",
"modified": "2022-05-13T01:29:26Z",
"published": "2022-05-13T01:29:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4553"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1139"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1140"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201607-01"
},
{
"type": "WEB",
"url": "http://bugs.squid-cache.org/show_bug.cgi?id=4501"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00010.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00040.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-08/msg00069.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3625"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1035768"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Advisories/SQUID-2016_7.txt"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-14039.patch"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2995-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P75G-GCV5-42QG
Vulnerability from github – Published: 2022-05-24 17:24 – Updated: 2024-02-01 21:47Grin 3.0.0 before 4.0.0 has insufficient validation of data related to Mimblewimble.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "grin"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15899"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-01T21:47:51Z",
"nvd_published_at": "2020-07-28T18:15:00Z",
"severity": "HIGH"
},
"details": "Grin 3.0.0 before 4.0.0 has insufficient validation of data related to Mimblewimble.",
"id": "GHSA-p75g-gcv5-42qg",
"modified": "2024-02-01T21:47:51Z",
"published": "2022-05-24T17:24:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15899"
},
{
"type": "WEB",
"url": "https://github.com/mimblewimble/grin-security/blob/master/CVEs/CVE-2020-15899.md"
},
{
"type": "WEB",
"url": "https://github.com/mimblewimble/grin/compare/v3.1.1...v4.0.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Grin insufficient data validation"
}
GHSA-P7MM-R948-4Q3Q
Vulnerability from github – Published: 2026-04-16 22:48 – Updated: 2026-04-16 22:48Summary
The approval-resolution endpoints (POST /approvals/:id/approve, /reject, /request-revision) accept a client-supplied decidedByUserId field in the request body and write it verbatim into the authoritative approvals.decidedByUserId column — without cross-checking it against the authenticated actor. Any board user who can access an approval's company can record the decision as having been made by another user (e.g. the CEO), forging the governance audit trail. For hire_agent approvals with a monthly budget, the same attacker-controlled string is also stamped onto the resulting budget_policies row as createdByUserId/updatedByUserId.
Details
Entry point — server/src/routes/approvals.ts:130:
router.post("/approvals/:id/approve", validate(resolveApprovalSchema), async (req, res) => {
assertBoard(req);
const id = req.params.id as string;
if (!(await requireApprovalAccess(req, id))) {
res.status(404).json({ error: "Approval not found" });
return;
}
const { approval, applied } = await svc.approve(
id,
req.body.decidedByUserId ?? "board", // ← client-controlled
req.body.decisionNote,
);
Authorization check — server/src/routes/authz.ts:4:
export function assertBoard(req: Request) {
if (req.actor.type !== "board") {
throw forbidden("Board access required");
}
}
assertBoard only checks that the caller is some board user; it never ties req.body.decidedByUserId to req.actor.userId. requireApprovalAccess/assertCompanyAccess only verify the attacker is allowed to touch the approval's company, which every board user in that company already is.
Validator — packages/shared/src/validators/approval.ts:13:
export const resolveApprovalSchema = z.object({
decisionNote: z.string().optional().nullable(),
decidedByUserId: z.string().optional().default("board"),
});
The Zod schema accepts any string for decidedByUserId — no UUID check, no membership check, no binding to the session.
Sink — server/src/services/approvals.ts:54:
const updated = await db
.update(approvals)
.set({
status: targetStatus,
decidedByUserId, // ← attacker-chosen value written verbatim
decisionNote: decisionNote ?? null,
decidedAt: now,
updatedAt: now,
})
.where(and(eq(approvals.id, id), inArray(approvals.status, resolvableStatuses)))
.returning()
Secondary sink (budget policies) — server/src/services/approvals.ts:147-156, reached when a hire_agent approval with budgetMonthlyCents > 0 is approved:
if (budgetMonthlyCents > 0) {
await budgets.upsertPolicy(
updated.companyId,
{ scopeType: "agent", scopeId: hireApprovedAgentId, amount: budgetMonthlyCents, windowKind: "calendar_month_utc" },
decidedByUserId, // ← forwarded as actorUserId
);
}
budgets.upsertPolicy uses that actorUserId to populate createdByUserId/updatedByUserId on the budget_policies row, extending the forgery to budget-policy audit columns.
Same pattern in reject and request-revision — server/src/routes/approvals.ts:229 and :257:
router.post("/approvals/:id/reject", validate(resolveApprovalSchema), async (req, res) => {
assertBoard(req);
...
const { approval, applied } = await svc.reject(id, req.body.decidedByUserId ?? "board", req.body.decisionNote);
approvalService.reject() and requestRevision() (approvals.ts:175 and :201) both write decidedByUserId directly into the approvals row.
Why logActivity is not a mitigation: the route handlers correctly use req.actor.userId ?? "board" when writing to activity_log (e.g. approvals.ts:151, 175, 190, 212, 246, 276), which shows the developer intent was that the deciding user equals the authenticated user. But the authoritative approvals.decidedByUserId column — the value shown to anyone reviewing the approval — is still sourced from the client, so the two records are allowed to diverge and the user-visible attribution is the forged one.
Why this is reachable from a non-admin attacker: actorMiddleware (server/src/middleware/auth.ts:62-98) populates req.actor as type: "board" for any authenticated user (session cookie or board API key); isInstanceAdmin is not consulted by assertBoard. In a multi-user authenticated deployment, any board member of a company can spoof the attribution of any other board member for approvals within that company. In local_trusted deployments there is only a single implicit local-board user, so the exploit has no target — but the code is shipped for both deployment modes.
PoC
Prerequisite: a pending hire_agent approval $APPROVAL_ID in a company where both attacker@corp and ceo@corp are board members of the authenticated deployment. Attacker authenticates with their own session cookie / board API key.
- Attacker approves as the CEO:
curl -X POST http://localhost:3000/approvals/$APPROVAL_ID/approve \
-H 'Content-Type: application/json' \
-H "Cookie: $ATTACKER_SESSION" \
-d '{"decidedByUserId":"ceo@corp","decisionNote":"LGTM"}'
- Verify the forged attribution is stored on the authoritative row:
curl http://localhost:3000/approvals/$APPROVAL_ID \
-H "Cookie: $ATTACKER_SESSION" | jq '.decidedByUserId'
# => "ceo@corp"
- For
hire_agentapprovals withbudgetMonthlyCents > 0, confirm the budget-policy row is also stamped with the forged user (direct DB read, or via an endpoint that surfacesbudget_policies.createdByUserId):
SELECT scope_id, amount, created_by_user_id, updated_by_user_id
FROM budget_policies
WHERE scope_type = 'agent'
ORDER BY created_at DESC LIMIT 1;
-- created_by_user_id = 'ceo@corp'
-- updated_by_user_id = 'ceo@corp'
- The same body works against
/approvals/$APPROVAL_ID/rejectand/approvals/$APPROVAL_ID/request-revision.
Note: the activity_log row written alongside the approval still shows the real attacker's userId (correctly taken from req.actor.userId), so a defender who looks at activity_log will see the discrepancy — but the approval UI, the approvals API, and the budget_policies audit columns all display the forged user.
Impact
- Forged governance audit trail. Any board user with access to a company can record approval, rejection, or revision-request decisions under any arbitrary user identifier — including other legitimate board users of that company. Approvals gate security-sensitive actions (agent hiring, which grants execution privileges and assigns a monthly spend budget), and the
approvals.decidedByUserIdcolumn is the authoritative record of who authorized each decision. - Budget-policy attribution forgery. For
hire_agentapprovals that carry a monthly budget,budget_policies.createdByUserId/updatedByUserIdare also populated from the same attacker-controlled string, spreading the forgery to spend-authorization audit columns. - Non-repudiation break. A board user can frame another board user for approving/rejecting a hire, undermining accountability for governance actions. The parallel
activity_logentry does preserve the true actor, but any reviewer inspecting the approval itself (not the activity log) will see the forged attribution as fact. - Scope. Limited to board users who already have company access; does not escalate privileges, does not leak data, and does not change whether the decision itself gets applied. Integrity impact is Low (attribution only, not decision content); confidentiality and availability are unaffected.
Recommended Fix
Drop decidedByUserId from the request schema entirely and derive it server-side from the authenticated actor. Treat req.body.decidedByUserId as untrusted and ignore it.
packages/shared/src/validators/approval.ts:
export const resolveApprovalSchema = z.object({
decisionNote: z.string().optional().nullable(),
// decidedByUserId removed — server derives from req.actor
});
export const requestApprovalRevisionSchema = z.object({
decisionNote: z.string().optional().nullable(),
});
server/src/routes/approvals.ts (apply to /approve, /reject, /request-revision):
router.post("/approvals/:id/approve", validate(resolveApprovalSchema), async (req, res) => {
assertBoard(req);
const id = req.params.id as string;
if (!(await requireApprovalAccess(req, id))) {
res.status(404).json({ error: "Approval not found" });
return;
}
const decidedBy = req.actor.userId ?? "board"; // trust the session, not the body
const { approval, applied } = await svc.approve(id, decidedBy, req.body.decisionNote);
...
});
Repeat the same const decidedBy = req.actor.userId ?? "board"; substitution at approvals.ts:238 (/reject) and :269 (/request-revision). No change is needed inside approvalService — it already accepts the value as a parameter — and this also ensures the forged value cannot reach budgets.upsertPolicy at approvals.ts:155. Existing callers that currently pass a body decidedByUserId can be updated to stop sending it (it is already effectively redundant with the session).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@paperclipai/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.416.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:48:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe approval-resolution endpoints (`POST /approvals/:id/approve`, `/reject`, `/request-revision`) accept a client-supplied `decidedByUserId` field in the request body and write it verbatim into the authoritative `approvals.decidedByUserId` column \u2014 without cross-checking it against the authenticated actor. Any board user who can access an approval\u0027s company can record the decision as having been made by another user (e.g. the CEO), forging the governance audit trail. For `hire_agent` approvals with a monthly budget, the same attacker-controlled string is also stamped onto the resulting `budget_policies` row as `createdByUserId`/`updatedByUserId`.\n\n## Details\n\n**Entry point** \u2014 `server/src/routes/approvals.ts:130`:\n\n```ts\nrouter.post(\"/approvals/:id/approve\", validate(resolveApprovalSchema), async (req, res) =\u003e {\n assertBoard(req);\n const id = req.params.id as string;\n if (!(await requireApprovalAccess(req, id))) {\n res.status(404).json({ error: \"Approval not found\" });\n return;\n }\n const { approval, applied } = await svc.approve(\n id,\n req.body.decidedByUserId ?? \"board\", // \u2190 client-controlled\n req.body.decisionNote,\n );\n```\n\n**Authorization check** \u2014 `server/src/routes/authz.ts:4`:\n\n```ts\nexport function assertBoard(req: Request) {\n if (req.actor.type !== \"board\") {\n throw forbidden(\"Board access required\");\n }\n}\n```\n\n`assertBoard` only checks that the caller is some board user; it never ties `req.body.decidedByUserId` to `req.actor.userId`. `requireApprovalAccess`/`assertCompanyAccess` only verify the attacker is allowed to touch the approval\u0027s company, which every board user in that company already is.\n\n**Validator** \u2014 `packages/shared/src/validators/approval.ts:13`:\n\n```ts\nexport const resolveApprovalSchema = z.object({\n decisionNote: z.string().optional().nullable(),\n decidedByUserId: z.string().optional().default(\"board\"),\n});\n```\n\nThe Zod schema accepts any string for `decidedByUserId` \u2014 no UUID check, no membership check, no binding to the session.\n\n**Sink** \u2014 `server/src/services/approvals.ts:54`:\n\n```ts\nconst updated = await db\n .update(approvals)\n .set({\n status: targetStatus,\n decidedByUserId, // \u2190 attacker-chosen value written verbatim\n decisionNote: decisionNote ?? null,\n decidedAt: now,\n updatedAt: now,\n })\n .where(and(eq(approvals.id, id), inArray(approvals.status, resolvableStatuses)))\n .returning()\n```\n\n**Secondary sink (budget policies)** \u2014 `server/src/services/approvals.ts:147-156`, reached when a `hire_agent` approval with `budgetMonthlyCents \u003e 0` is approved:\n\n```ts\nif (budgetMonthlyCents \u003e 0) {\n await budgets.upsertPolicy(\n updated.companyId,\n { scopeType: \"agent\", scopeId: hireApprovedAgentId, amount: budgetMonthlyCents, windowKind: \"calendar_month_utc\" },\n decidedByUserId, // \u2190 forwarded as actorUserId\n );\n}\n```\n\n`budgets.upsertPolicy` uses that `actorUserId` to populate `createdByUserId`/`updatedByUserId` on the `budget_policies` row, extending the forgery to budget-policy audit columns.\n\n**Same pattern in `reject` and `request-revision`** \u2014 `server/src/routes/approvals.ts:229` and `:257`:\n\n```ts\nrouter.post(\"/approvals/:id/reject\", validate(resolveApprovalSchema), async (req, res) =\u003e {\n assertBoard(req);\n ...\n const { approval, applied } = await svc.reject(id, req.body.decidedByUserId ?? \"board\", req.body.decisionNote);\n```\n\n`approvalService.reject()` and `requestRevision()` (`approvals.ts:175` and `:201`) both write `decidedByUserId` directly into the approvals row.\n\n**Why `logActivity` is not a mitigation**: the route handlers correctly use `req.actor.userId ?? \"board\"` when writing to `activity_log` (e.g. `approvals.ts:151`, `175`, `190`, `212`, `246`, `276`), which shows the developer intent was that the deciding user equals the authenticated user. But the authoritative `approvals.decidedByUserId` column \u2014 the value shown to anyone reviewing the approval \u2014 is still sourced from the client, so the two records are allowed to diverge and the user-visible attribution is the forged one.\n\n**Why this is reachable from a non-admin attacker**: `actorMiddleware` (`server/src/middleware/auth.ts:62-98`) populates `req.actor` as `type: \"board\"` for any authenticated user (session cookie or board API key); `isInstanceAdmin` is not consulted by `assertBoard`. In a multi-user `authenticated` deployment, any board member of a company can spoof the attribution of any other board member for approvals within that company. In `local_trusted` deployments there is only a single implicit `local-board` user, so the exploit has no target \u2014 but the code is shipped for both deployment modes.\n\n## PoC\n\nPrerequisite: a pending `hire_agent` approval `$APPROVAL_ID` in a company where both `attacker@corp` and `ceo@corp` are board members of the `authenticated` deployment. Attacker authenticates with their own session cookie / board API key.\n\n1. Attacker approves as the CEO:\n\n```bash\ncurl -X POST http://localhost:3000/approvals/$APPROVAL_ID/approve \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \"Cookie: $ATTACKER_SESSION\" \\\n -d \u0027{\"decidedByUserId\":\"ceo@corp\",\"decisionNote\":\"LGTM\"}\u0027\n```\n\n2. Verify the forged attribution is stored on the authoritative row:\n\n```bash\ncurl http://localhost:3000/approvals/$APPROVAL_ID \\\n -H \"Cookie: $ATTACKER_SESSION\" | jq \u0027.decidedByUserId\u0027\n# =\u003e \"ceo@corp\"\n```\n\n3. For `hire_agent` approvals with `budgetMonthlyCents \u003e 0`, confirm the budget-policy row is also stamped with the forged user (direct DB read, or via an endpoint that surfaces `budget_policies.createdByUserId`):\n\n```sql\nSELECT scope_id, amount, created_by_user_id, updated_by_user_id\nFROM budget_policies\nWHERE scope_type = \u0027agent\u0027\nORDER BY created_at DESC LIMIT 1;\n-- created_by_user_id = \u0027ceo@corp\u0027\n-- updated_by_user_id = \u0027ceo@corp\u0027\n```\n\n4. The same body works against `/approvals/$APPROVAL_ID/reject` and `/approvals/$APPROVAL_ID/request-revision`.\n\nNote: the `activity_log` row written alongside the approval still shows the real attacker\u0027s `userId` (correctly taken from `req.actor.userId`), so a defender who looks at `activity_log` will see the discrepancy \u2014 but the approval UI, the approvals API, and the budget_policies audit columns all display the forged user.\n\n## Impact\n\n- **Forged governance audit trail.** Any board user with access to a company can record approval, rejection, or revision-request decisions under any arbitrary user identifier \u2014 including other legitimate board users of that company. Approvals gate security-sensitive actions (agent hiring, which grants execution privileges and assigns a monthly spend budget), and the `approvals.decidedByUserId` column is the authoritative record of who authorized each decision.\n- **Budget-policy attribution forgery.** For `hire_agent` approvals that carry a monthly budget, `budget_policies.createdByUserId` / `updatedByUserId` are also populated from the same attacker-controlled string, spreading the forgery to spend-authorization audit columns.\n- **Non-repudiation break.** A board user can frame another board user for approving/rejecting a hire, undermining accountability for governance actions. The parallel `activity_log` entry does preserve the true actor, but any reviewer inspecting the approval itself (not the activity log) will see the forged attribution as fact.\n- **Scope.** Limited to board users who already have company access; does not escalate privileges, does not leak data, and does not change whether the decision itself gets applied. Integrity impact is Low (attribution only, not decision content); confidentiality and availability are unaffected.\n\n## Recommended Fix\n\nDrop `decidedByUserId` from the request schema entirely and derive it server-side from the authenticated actor. Treat `req.body.decidedByUserId` as untrusted and ignore it.\n\n**`packages/shared/src/validators/approval.ts`:**\n\n```ts\nexport const resolveApprovalSchema = z.object({\n decisionNote: z.string().optional().nullable(),\n // decidedByUserId removed \u2014 server derives from req.actor\n});\n\nexport const requestApprovalRevisionSchema = z.object({\n decisionNote: z.string().optional().nullable(),\n});\n```\n\n**`server/src/routes/approvals.ts`** (apply to `/approve`, `/reject`, `/request-revision`):\n\n```ts\nrouter.post(\"/approvals/:id/approve\", validate(resolveApprovalSchema), async (req, res) =\u003e {\n assertBoard(req);\n const id = req.params.id as string;\n if (!(await requireApprovalAccess(req, id))) {\n res.status(404).json({ error: \"Approval not found\" });\n return;\n }\n const decidedBy = req.actor.userId ?? \"board\"; // trust the session, not the body\n const { approval, applied } = await svc.approve(id, decidedBy, req.body.decisionNote);\n ...\n});\n```\n\nRepeat the same `const decidedBy = req.actor.userId ?? \"board\";` substitution at `approvals.ts:238` (`/reject`) and `:269` (`/request-revision`). No change is needed inside `approvalService` \u2014 it already accepts the value as a parameter \u2014 and this also ensures the forged value cannot reach `budgets.upsertPolicy` at `approvals.ts:155`. Existing callers that currently pass a body `decidedByUserId` can be updated to stop sending it (it is already effectively redundant with the session).",
"id": "GHSA-p7mm-r948-4q3q",
"modified": "2026-04-16T22:48:46Z",
"published": "2026-04-16T22:48:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-p7mm-r948-4q3q"
},
{
"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:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Paperclip: Approval decision attribution spoofing via client-controlled `decidedByUserId` in paperclip server"
}
GHSA-P847-VWJ5-4Q73
Vulnerability from github – Published: 2022-05-13 01:29 – Updated: 2022-05-13 01:29mime_header.cc in Squid before 3.5.18 allows remote attackers to bypass intended same-origin restrictions and possibly conduct cache-poisoning attacks via a crafted HTTP Host header, aka a "header smuggling" issue.
{
"affected": [],
"aliases": [
"CVE-2016-4554"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-05-10T19:59:00Z",
"severity": "HIGH"
},
"details": "mime_header.cc in Squid before 3.5.18 allows remote attackers to bypass intended same-origin restrictions and possibly conduct cache-poisoning attacks via a crafted HTTP Host header, aka a \"header smuggling\" issue.",
"id": "GHSA-p847-vwj5-4q73",
"modified": "2022-05-13T01:29:27Z",
"published": "2022-05-13T01:29:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4554"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1138"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1139"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2016:1140"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201607-01"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00010.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-08/msg00040.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-08/msg00069.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3625"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1035769"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Advisories/SQUID-2016_8.txt"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.1/changesets/SQUID-2016_8.patch"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.2/changesets/SQUID-2016_8.patch"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.3/changesets/SQUID-2016_8.patch"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.4/changesets/SQUID-2016_8.patch"
},
{
"type": "WEB",
"url": "http://www.squid-cache.org/Versions/v3/3.5/changesets/SQUID-2016_8.patch"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-2995-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P8CQ-42F6-5Q3J
Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2024-09-07 00:31Matrix Tafnit v8
CWE-646: Reliance on File Name or Extension of Externally-Supplied File
{
"affected": [],
"aliases": [
"CVE-2024-38432"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-646"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T09:15:03Z",
"severity": "MODERATE"
},
"details": "Matrix\u00a0Tafnit v8\n\n - \n\n\n\nCWE-646: Reliance on File Name or Extension of Externally-Supplied File",
"id": "GHSA-p8cq-42f6-5q3j",
"modified": "2024-09-07T00:31:28Z",
"published": "2024-07-30T09:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38432"
},
{
"type": "WEB",
"url": "https://www.gov.il/en/Departments/faq/cve_advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-148: Content Spoofing
An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged. The term content spoofing is most often used to describe modification of web pages hosted by a target to display the adversary's content instead of the owner's content. However, any content can be spoofed, including the content of email messages, file transfers, or the content of other network communication protocols. Content can be modified at the source (e.g. modifying the source file for a web page) or in transit (e.g. intercepting and modifying a message between the sender and recipient). Usually, the adversary will attempt to hide the fact that the content has been modified, but in some cases, such as with web site defacement, this is not necessary. Content Spoofing can lead to malware exposure, financial fraud (if the content governs financial transactions), privacy violations, and other unwanted outcomes.
CAPEC-218: Spoofing of UDDI/ebXML Messages
An attacker spoofs a UDDI, ebXML, or similar message in order to impersonate a service provider in an e-business transaction. UDDI, ebXML, and similar standards are used to identify businesses in e-business transactions. Among other things, they identify a particular participant, WSDL information for SOAP transactions, and supported communication protocols, including security protocols. By spoofing one of these messages an attacker could impersonate a legitimate business in a transaction or could manipulate the protocols used between a client and business. This could result in disclosure of sensitive information, loss of message integrity, or even financial fraud.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.
CAPEC-701: Browser in the Middle (BiTM)
An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.