{"api_version":"1","generated_at":"2026-11-10T19:13:55+00:00","cve":"CVE-2026-125321","urls":{"html":"https://cve.report/CVE-2026-125321","api":"https://cve.report/api/cve/CVE-2026-125321.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-125321","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-125321"},"summary":{"title":"pgEdge Postgres MCP Server login rate limiting can be evaded by a caller-supplied header","description":"pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, deployments exposing the nondefault HTTP transport with authentication enabled used the leftmost caller-supplied X-Forwarded-For value as the client address for login rate limiting. ExtractIPAddress in internal/auth/middleware.go supplied that value to IsAllowed and RecordFailedAttempt in internal/auth/rate_limiter.go, allowing an unauthenticated caller to rotate addresses to evade throttling or assert another user's address to consume that user's limiter bucket. The published nginx configuration appended rather than replaced X-Forwarded-For, making the issue reachable without an operator misconfiguration. Username-keyed account lockout did not use the client address, but shipped defaults disabled that separate control through MaxFailedAttemptsBeforeLockout: 0. This issue is fixed in version 1.1.0.","state":"PUBLISHED","assigner":"GitHub_M","published_at":"2026-11-10 18:17:33","updated_at":"2026-11-10 18:17:33"},"problem_types":["CWE-770","CWE-807","CWE-770 CWE-770: Allocation of Resources Without Limits or Throttling","CWE-807 CWE-807: Reliance on Untrusted Inputs in a Security Decision"],"metrics":[{"version":"3.1","source":"security-advisories@github.com","type":"Secondary","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"LOW"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","data":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"LOW","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"LOW","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","version":"3.1"}}],"references":[{"url":"https://github.com/pgEdge/pgedge-postgres-mcp/security/advisories/GHSA-v347-v3w7-7fq9","name":"https://github.com/pgEdge/pgedge-postgres-mcp/security/advisories/GHSA-v347-v3w7-7fq9","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgEdge/pgedge-postgres-mcp/issues/204","name":"https://github.com/pgEdge/pgedge-postgres-mcp/issues/204","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgEdge/pgedge-postgres-mcp/pull/205","name":"https://github.com/pgEdge/pgedge-postgres-mcp/pull/205","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgEdge/pgedge-postgres-mcp/commit/6a19e46a240b9f4661a4a253811948dd75c4077e","name":"https://github.com/pgEdge/pgedge-postgres-mcp/commit/6a19e46a240b9f4661a4a253811948dd75c4077e","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-125321","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-125321","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"pgEdge","product":"pgedge-postgres-mcp","version":"affected < 1.1.0","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"product":"pgedge-postgres-mcp","vendor":"pgEdge","versions":[{"status":"affected","version":"< 1.1.0"}]}],"descriptions":[{"lang":"en","value":"pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, deployments exposing the nondefault HTTP transport with authentication enabled used the leftmost caller-supplied X-Forwarded-For value as the client address for login rate limiting. ExtractIPAddress in internal/auth/middleware.go supplied that value to IsAllowed and RecordFailedAttempt in internal/auth/rate_limiter.go, allowing an unauthenticated caller to rotate addresses to evade throttling or assert another user's address to consume that user's limiter bucket. The published nginx configuration appended rather than replaced X-Forwarded-For, making the issue reachable without an operator misconfiguration. Username-keyed account lockout did not use the client address, but shipped defaults disabled that separate control through MaxFailedAttemptsBeforeLockout: 0. This issue is fixed in version 1.1.0."}],"metrics":[{"cvssV3_1":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"LOW","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"LOW","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","version":"3.1"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-770","description":"CWE-770: Allocation of Resources Without Limits or Throttling","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-807","description":"CWE-807: Reliance on Untrusted Inputs in a Security Decision","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-11-10T17:36:23.877Z","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","shortName":"GitHub_M"},"references":[{"name":"https://github.com/pgEdge/pgedge-postgres-mcp/security/advisories/GHSA-v347-v3w7-7fq9","tags":["x_refsource_CONFIRM"],"url":"https://github.com/pgEdge/pgedge-postgres-mcp/security/advisories/GHSA-v347-v3w7-7fq9"},{"name":"https://github.com/pgEdge/pgedge-postgres-mcp/issues/204","tags":["x_refsource_MISC"],"url":"https://github.com/pgEdge/pgedge-postgres-mcp/issues/204"},{"name":"https://github.com/pgEdge/pgedge-postgres-mcp/pull/205","tags":["x_refsource_MISC"],"url":"https://github.com/pgEdge/pgedge-postgres-mcp/pull/205"},{"name":"https://github.com/pgEdge/pgedge-postgres-mcp/commit/6a19e46a240b9f4661a4a253811948dd75c4077e","tags":["x_refsource_MISC"],"url":"https://github.com/pgEdge/pgedge-postgres-mcp/commit/6a19e46a240b9f4661a4a253811948dd75c4077e"}],"source":{"advisory":"GHSA-v347-v3w7-7fq9","discovery":"UNKNOWN"},"title":"pgEdge Postgres MCP Server login rate limiting can be evaded by a caller-supplied header"}},"cveMetadata":{"assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","assignerShortName":"GitHub_M","cveId":"CVE-2026-125321","datePublished":"2026-11-10T17:36:23.877Z","dateReserved":"2026-11-09T21:22:55.597Z","dateUpdated":"2026-11-10T17:36:23.877Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-10 18:17:33","lastModifiedDate":"2026-11-10 18:17:33","problem_types":["CWE-770","CWE-807","CWE-770 CWE-770: Allocation of Resources Without Limits or Throttling","CWE-807 CWE-807: Reliance on Untrusted Inputs in a Security Decision"],"metrics":{"cvssMetricV31":[{"source":"security-advisories@github.com","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"LOW"},"exploitabilityScore":3.9,"impactScore":2.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"125321","Ordinal":"1","Title":"pgEdge Postgres MCP Server login rate limiting can be evaded by ","CVE":"CVE-2026-125321","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"125321","Ordinal":"1","NoteData":"pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, deployments exposing the nondefault HTTP transport with authentication enabled used the leftmost caller-supplied X-Forwarded-For value as the client address for login rate limiting. ExtractIPAddress in internal/auth/middleware.go supplied that value to IsAllowed and RecordFailedAttempt in internal/auth/rate_limiter.go, allowing an unauthenticated caller to rotate addresses to evade throttling or assert another user's address to consume that user's limiter bucket. The published nginx configuration appended rather than replaced X-Forwarded-For, making the issue reachable without an operator misconfiguration. Username-keyed account lockout did not use the client address, but shipped defaults disabled that separate control through MaxFailedAttemptsBeforeLockout: 0. This issue is fixed in version 1.1.0.","Type":"Description","Title":"pgEdge Postgres MCP Server login rate limiting can be evaded by "}]}}}