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/ratelimiter.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.

pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, the HTTP transport did not validate the Origin header on incoming requests. A user who visited an attacker-controlled page could be targeted through DNS rebinding, allowing the page to reach a locally running server and read schemas and query results from configured databases. The issue affected deployments with the HTTP transport enabled on a machine that also ran a browser, while the default stdio transport was not reachable through this path. This issue is fixed in version 1.1.0.

pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, the where parameter of the countrows tool accepted subqueries against tables other than the table named in the tool call. A caller could use predicates and the returned row count as an inference oracle to extract data from any other table that the connected database role could read. The database privilege boundary remained intact, and the flaw did not grant access to tables outside that role's existing SELECT privileges. This issue is fixed in version 1.1.0.