MCP GitLab CVE-2026-61568: Update to 2.1.30 for DNS Rebinding Protection

By AiCybr Editorial · Published September 17, 2026

@zereight/mcp-gitlab versions before 2.1.30 are affected by CVE-2026-61568, a critical DNS-rebinding vulnerability in the Streamable HTTP MCP transport. The advisory assigns a CVSS 3.1 score of 9.6. A malicious web page can direct browser traffic to a local MCP listener while retaining attacker-controlled Host and Origin headers.

Version 2.1.30 contains the fix. The project's official v2.1.30 release notes identify the relevant change as “guard Streamable HTTP host headers”, and current project documentation exposes MCP_SERVER_URL, MCP_ALLOWED_HOSTS, and MCP_ALLOWED_ORIGINS for DNS-rebinding protection.

The vulnerability was published on September 15, 2026. Its patch predates the public CVE: the upstream v2.1.30 release was published on July 5, 2026. Operators should therefore inventory installed package versions instead of using the CVE publication date as a proxy for exposure.

CVE-2026-61568 at a glance

How the DNS-rebinding path works

@zereight/mcp-gitlab can expose an MCP endpoint over Streamable HTTP. In affected releases, that endpoint lacks an effective allowlist enforcing the expected HTTP Host or browser Origin at the transport boundary.

A malicious site can use DNS rebinding so a hostname initially associated with attacker-controlled infrastructure later resolves to an address reachable from the victim's browser, including a service on the victim's machine or local network. Requests can then reach the MCP listener while carrying the attacker's Host and Origin values.

The published advisory confirms that forged-origin traffic can reach the MCP initialization path. The resulting tool exposure depends on the deployment's credential model: a server configured with its own GitLab token can expose credentialed tools without a browser-supplied token, while remote-authorization deployments require the caller's per-request GitLab credential. Session state and the token's GitLab permissions determine the operations available after the transport boundary is crossed.

Authentication and Host/Origin validation are separate controls

The project's remote-authorization mode requires each HTTP caller to provide a GitLab token in a supported request header. That token check limits unauthenticated GitLab API operations, while Host/Origin validation controls which browser origins can reach the MCP HTTP service in the first place.

Deployments should retain both controls. A valid GitLab token should authorize the intended caller; it should not substitute for a network-origin boundary on a browser-reachable MCP listener.

The project currently documents these relevant settings:

What changed in 2.1.30

The official v2.1.30 release notes list two security-relevant fixes: guard Streamable HTTP host headers and harden MCP safety controls. The CVE advisory identifies 2.1.30 as the patched version for the DNS-rebinding issue.

The current project documentation also describes explicit allowed-host and allowed-origin configuration for /mcp. Administrators running an older pinned npm package, container image, lockfile, Nix input or other packaged deployment should confirm the effective application version rather than assuming an upstream repository update changed their installation.

What operators should do

1. Inventory the installed @zereight/mcp-gitlab version. Any release earlier than 2.1.30 falls within the published affected range.
2. Upgrade to a current release. Version 2.1.30 is the CVE-specific fixed floor; using the current stable release also incorporates subsequent fixes.
3. Review Streamable HTTP exposure. Identify the interface and address on which the MCP service listens and whether browsers on untrusted networks can reach it.
4. Configure the expected public server URL or explicit allowlists. Use MCP_SERVER_URL, MCP_ALLOWED_HOSTS, and MCP_ALLOWED_ORIGINS as appropriate for the deployment.
5. Keep authentication enabled for shared or remote deployments. Per-request GitLab authorization remains a separate security boundary from DNS-rebinding protection.
6. Check reverse-proxy trust settings. Enable MCP_TRUST_PROXY only when the proxy is trusted and direct access to the backend MCP listener is blocked, matching the project's deployment guidance.
7. Review GitLab credentials and activity if exposure is suspected. The relevant GitLab token determines which projects, variables and write operations an MCP session can reach, including deployments where the server itself holds the token.

Exposure by transport mode

The advisory concerns the Streamable HTTP MCP endpoint. A local stdio deployment has a different transport boundary because it communicates through a spawned process's standard input and output instead of exposing the affected HTTP listener.

For HTTP deployments, network placement still matters after upgrading. Bind addresses, firewall policy, reverse-proxy routing, authentication, token scope and explicit Host/Origin configuration determine the service's reachable attack surface.

Exploitation status

The public advisory establishes the vulnerability, affected range and patch. Current authoritative material reviewed for this article does not report in-the-wild exploitation. The remediation case is based on the exposed browser-to-local-service boundary and the privileges available through the deployment's GitLab credentials.

Bottom line

Operators using @zereight/mcp-gitlab over Streamable HTTP should run 2.1.30 or later and configure the expected MCP host/origin boundary. The flaw allows attacker-origin browser traffic to reach a local MCP HTTP listener through DNS rebinding; the consequences depend on the GitLab credentials available to the server or request and their permissions.

The durable deployment pattern is layered: current package version, explicit Host/Origin controls, appropriately scoped GitLab credentials, restricted network exposure and carefully configured reverse-proxy trust.

Sources

• GitHub Security Advisory GHSA-vmp7-252j-cwp7 / CVE-2026-61568.
• Zereight GitLab MCP v2.1.30 release notes, published July 5, 2026.
• Zereight GitLab MCP current documentation for Streamable HTTP, remote authorization, allowed hosts/origins and proxy trust.
• GitLab Advisory Database entry for CVE-2026-61568, published September 15, 2026.