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.
939 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-P96H-94Q2-FH5V
Vulnerability from github – Published: 2026-03-22 15:31 – Updated: 2026-03-22 15:31A vulnerability was detected in PuTTY 0.83. Affected is the function eddsa_verify of the file crypto/ecc-ssh.c of the component Ed25519 Signature Handler. The manipulation results in improper verification of cryptographic signature. The attack may be performed from remote. The attack requires a high level of complexity. The exploitability is told to be difficult. The exploit is now public and may be used. The real existence of this vulnerability is still doubted at the moment. The patch is identified as af996b5ec27ab79bae3882071b9d6acf16044549. It is advisable to implement a patch to correct this issue. The vendor was contacted early, responded in a very professional manner and quickly released a patch for the affected product. However, at the moment there is no proof that this flaw might have any real-world impact.
{
"affected": [],
"aliases": [
"CVE-2026-4115"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-22T13:16:20Z",
"severity": "MODERATE"
},
"details": "A vulnerability was detected in PuTTY 0.83. Affected is the function eddsa_verify of the file crypto/ecc-ssh.c of the component Ed25519 Signature Handler. The manipulation results in improper verification of cryptographic signature. The attack may be performed from remote. The attack requires a high level of complexity. The exploitability is told to be difficult. The exploit is now public and may be used. The real existence of this vulnerability is still doubted at the moment. The patch is identified as af996b5ec27ab79bae3882071b9d6acf16044549. It is advisable to implement a patch to correct this issue. The vendor was contacted early, responded in a very professional manner and quickly released a patch for the affected product. However, at the moment there is no proof that this flaw might have any real-world impact.",
"id": "GHSA-p96h-94q2-fh5v",
"modified": "2026-03-22T15:31:28Z",
"published": "2026-03-22T15:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4115"
},
{
"type": "WEB",
"url": "https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=af996b5ec27ab79bae3882071b9d6acf16044549"
},
{
"type": "WEB",
"url": "https://github.com/py-thok/putty-ed25519-malleability-s-plus-l"
},
{
"type": "WEB",
"url": "https://github.com/py-thok/putty-ed25519-malleability-s-plus-l/blob/main/poc.py"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.352429"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.352429"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.775576"
},
{
"type": "WEB",
"url": "https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/eddsa-overlarge-s.html"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc8032#section-8.4"
}
],
"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-P9VF-4JX2-5HPP
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2023-09-26 18:50A security bypass vulnerability exists in Magento 2.2 prior to 2.2.10, Magento 2.3 prior to 2.3.3 or 2.3.2-p1. An unauthenticated user can bypass the email confirmation mechanism via GET request that captures relevant account data obtained from the POST response related to new user creation.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.2-p1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-8112"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-18T20:02:18Z",
"nvd_published_at": "2019-11-05T23:15:00Z",
"severity": "HIGH"
},
"details": "A security bypass vulnerability exists in Magento 2.2 prior to 2.2.10, Magento 2.3 prior to 2.3.3 or 2.3.2-p1. An unauthenticated user can bypass the email confirmation mechanism via GET request that captures relevant account data obtained from the POST response related to new user creation.",
"id": "GHSA-p9vf-4jx2-5hpp",
"modified": "2023-09-26T18:50:25Z",
"published": "2022-05-24T17:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8112"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/magento/product-community-edition/CVE-2019-8112.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://magento.com/security/patches/magento-2.3.3-and-2.2.10-security-update"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20220121051105/https://magento.com/security/patches/magento-2.3.3-and-2.2.10-security-update"
}
],
"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": "Magento 2 Community Edition Security Bypass"
}
GHSA-PC93-2W93-6F7V
Vulnerability from github – Published: 2023-06-07 21:30 – Updated: 2024-04-04 04:39If an attacker can trick an authenticated user into loading a maliciously crafted .zip file onto Advantech WebAccess version 8.4.5, a web shell could be used to give the attacker full control of the SCADA server.
{
"affected": [],
"aliases": [
"CVE-2023-2866"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-351"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T21:15:13Z",
"severity": "HIGH"
},
"details": "\nIf an attacker can trick an authenticated user into loading a maliciously crafted .zip file onto Advantech WebAccess version 8.4.5, a web shell could be used to give the attacker full control of the SCADA server. \n\n",
"id": "GHSA-pc93-2w93-6f7v",
"modified": "2024-04-04T04:39:55Z",
"published": "2023-06-07T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2866"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-150-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PF8R-HFJ4-5HRM
Vulnerability from github – Published: 2024-09-26 18:31 – Updated: 2024-09-26 18:31The goTenna Pro ATAK Plugin use AES CTR mode for short, encrypted messages without any additional integrity checking mechanisms. This leaves messages malleable to any attacker that can access the message.
{
"affected": [],
"aliases": [
"CVE-2024-43108"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-353"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-26T18:15:06Z",
"severity": "MODERATE"
},
"details": "The goTenna Pro ATAK Plugin use AES CTR mode for short, encrypted \nmessages without any additional integrity checking mechanisms. This \nleaves messages malleable to any attacker that can access the message.",
"id": "GHSA-pf8r-hfj4-5hrm",
"modified": "2024-09-26T18:31:45Z",
"published": "2024-09-26T18:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43108"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-270-05"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/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-PFHH-873G-HHX7
Vulnerability from github – Published: 2023-03-21 15:30 – Updated: 2023-03-28 15:30A CWE-345: Insufficient Verification of Data Authenticity vulnerability exists in the Data Server that could allow the renaming of files in the IGSS project report directory, this could lead to denial of service when an attacker sends specific crafted messages to the Data Server TCP port. Affected Products: IGSS Data Server(IGSSdataServer.exe)(V16.0.0.23040 and prior), IGSS Dashboard(DashBoard.exe)(V16.0.0.23040 and prior), Custom Reports(RMS16.dll)(V16.0.0.23040 and prior).
{
"affected": [],
"aliases": [
"CVE-2023-27979"
],
"database_specific": {
"cwe_ids": [
"CWE-345"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-21T13:15:00Z",
"severity": "HIGH"
},
"details": "A CWE-345: Insufficient Verification of Data Authenticity vulnerability exists in the Data Server that could allow the renaming of files in the IGSS project report directory, this could lead to denial of service when an attacker sends specific crafted messages to the Data Server TCP port. Affected Products: IGSS Data Server(IGSSdataServer.exe)(V16.0.0.23040 and prior), IGSS Dashboard(DashBoard.exe)(V16.0.0.23040 and prior), Custom Reports(RMS16.dll)(V16.0.0.23040 and prior).",
"id": "GHSA-pfhh-873g-hhx7",
"modified": "2023-03-28T15:30:17Z",
"published": "2023-03-21T15:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27979"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2023-073-04\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2023-073-04.pdf"
}
],
"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"
}
]
}
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.