CVE-2026-81095 in pg-aiguide
Summary
by MITRE • 08/27/2026
pg-aiguide started its MCP HTTP transport without enabling the host allow-list the underlying SDK provides. src/httpServer.ts called the shared httpServerFactory helper and never set the DNS-rebinding-protection option, so the transport accepted a request whatever host it named. A page in a browser could therefore point a name it controlled at the address the server was bound to and drive the locally reachable MCP server through the visitor's browser. The protection was already available in the packaged transport and simply not turned on, so updating the dependency alone would not have closed it. Version 0.5.1 passes the option explicitly.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in pg-aiguide represents a critical misconfiguration of HTTP server security controls, specifically concerning DNS rebinding protection mechanisms inherent to the underlying software development kit. By initiating its Model Context Protocol (MCP) HTTP transport without enabling the host allow-list feature provided by the SDK, the application failed to implement essential boundary checks on incoming requests. This oversight meant that the httpServerFactory helper invoked in src/httpServer.ts did not configure any restrictions based on the Host header or target address resolution. Consequently, the server operated with an overly permissive access policy, accepting HTTP requests regardless of the hostname specified by the client. This architectural flaw effectively neutralized standard browser-based security models that rely on same-origin policies and host validation to prevent unauthorized cross-site interactions.
From a technical perspective, this misconfiguration creates a direct pathway for DNS rebinding attacks. In such an attack scenario, an adversary controls a domain name and configures its DNS records to resolve to the local IP address of the victim machine running pg-aiguide. When a user visits the attacker-controlled page in their browser, the JavaScript code within that page can make HTTP requests directly to the localhost address where the vulnerable server is listening. Because the server does not validate whether the Host header matches an expected internal domain or allow-listed host, it processes these external-originated requests as if they were legitimate local calls. This allows a remote attacker in a browser context to interact with sensitive backend services that are typically isolated from public internet access by network firewalls and localhost binding configurations.
The operational impact of this vulnerability is severe, particularly given the nature of MCP servers which often handle database queries or system administration tasks. An authenticated or unauthenticated attacker could potentially execute arbitrary commands, exfiltrate data, or manipulate local resources through the browser interface. The risk is amplified because DNS rebinding attacks can bypass traditional network-level protections that assume localhost traffic originates only from trusted applications on the same machine. Since the protection mechanism was already available within the packaged transport library but simply left disabled by default in this specific implementation, the flaw stems entirely from application logic rather than a deficiency in the underlying SDK. This distinction is crucial for remediation, as it indicates that upgrading dependencies alone would not have resolved the issue; explicit configuration of security parameters was required to enforce host validation.
To mitigate this vulnerability and prevent similar issues in future deployments, developers must explicitly enable DNS rebinding protection by configuring the host allow-list option within the HTTP server factory settings. This involves defining a strict list of permitted hostnames or IP addresses that are allowed to connect to the service. Additionally, implementing Content Security Policy headers can provide an additional layer of defense against cross-origin data theft and script injection attempts originating from malicious web pages. It is also advisable to audit all third-party library integrations for security-relevant configuration defaults, ensuring that protective features like host validation are not left in their default disabled state even if they exist within the vendor's codebase. Adhering to these practices aligns with industry standards such as CWE-284 Improper Access Control and mitigates risks associated with ATT&CK technique T1505 Server Software Component, which covers the exploitation of server-side components for unauthorized access or control.