CVE-2026-63004: Server-Side Request Forgery in Unleash Addon and Integration Subsystem

The Unleash feature management platform incorporates an integration and addon subsystem designed to notify external services when toggle changes, project configurations, or environment updates occur. This subsystem, located within src/lib/addons/, acts as an outbound gateway. It dispatches structured JSON payloads to target destinations such as Slack, Microsoft Teams, Datadog, New Relic, or arbitrary user-defined webhooks. To execute these outbound connections, the application server relies on background workers that parse configuration inputs and resolve network addresses dynamically.

The administrative control plane exposes integration configuration endpoints to authenticated users possessing high-privilege permissions, specifically CREATE_ADDON or UPDATE_ADDON. Because these integration models allow administrators to specify target destination URLs, they expose an outbound network attack surface. Prior to security patches, the outbound connection module processed user-provided URLs without enforcing restrictions on protocols, routing prefixes, or network scope.

This flaw is classified under CWE-918 (Server-Side Request Forgery). By registering or modifying an integration, an administrative attacker can coerce the backend application server into initiating outbound TCP connections to arbitrary destinations. This includes routing requests to internal loopback interfaces, private RFC 1918 subnets, and sensitive cloud metadata endpoints. Because the backend server acts as the source of these connections, they bypass typical boundary firewalls and perimeter access controls.

The underlying vulnerability stems from the absence of input validation and address resolution verification prior to executing outbound network sockets. In affected versions of Unleash, when an integration event triggers, the system pulls the target URL string configured in the addon configuration and feeds it directly into the fetchRetry handler inside src/lib/addons/addon.ts. This client lacks any evaluation layer to verify whether the target address belongs to a public or private IP range.

Because the host operating system handles DNS resolution transparently, the target hostname is resolved to its destination IP address without restriction. This allows an attacker to route requests to loopback addresses (127.0.0.1, ::1) or internal networks (such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). These private networks typically contain internal administrative portals, cluster services, and key-value stores that assume a trust boundary and do not require authentication.

Additionally, the outbound client presents a mechanism for credential leakage. Certain integrations configure sensitive authorization headers, such as API tokens or custom credentials. By updating the integration target URL to an external, attacker-controlled host, an administrator can force Unleash to transmit these sensitive keys to an untrusted domain. Furthermore, because Unleash logs connection results and error states, the system provides an informational oracle. Attackers can map active ports and trace internal subnets by analyzing the error codes and latency patterns returned in administrative logs.

To understand the vulnerability mechanics and subsequent correction, we can analyze the outbound request wrapper. In vulnerable versions, the fetchRetry wrapper in src/lib/addons/addon.ts executed outbound HTTP connections directly with minimal processing:

// PRE-PATCH VULNERABLE CODE PATH
async fetchRetry(
    url: string,
    options: any = {},
    retries: number = 1,
): Promise<Response> {
    try {
        // The raw URL is resolved and queried directly
        const res = await ky(url, {
            retry: retries,
            ...options,
        });
        return res;
    } catch (e) {
        throw e;
    }
}

The fix, introduced in June 2026, implements a URL validation module (validate-url.ts) and enforces strict validation checks. This module parses target schemas, resolves hostnames, and validates resulting IP addresses against restricted network blocks:

// PATCHED URL VALIDATION (validate-url.ts)
export const validateUrl = async (
    rawUrl: string,
    options: ValidateUrlOptions = {},
): Promise<ValidatedUrl> => {
    const url = new URL(rawUrl);
    if (url.protocol !== 'http:' && url.protocol !== 'https:') {
        throw new ValidationError(`Invalid protocol: ${url.protocol}`, [], url);
    }
    const hostname = url.hostname.toLowerCase();
    const ipFamily = net.isIP(hostname);
    const resolved =
        ipFamily !== 0
            ? [{ address: hostname, family: ipFamily as 4 | 6 }]
            : await (options.lookup ?? defaultLookup)(hostname);
 
    // Parsed addresses are matched against local, private, and loopback CIDR blocks
    const isLocalIpv4 = (ip: Address4) => {
        return (
            ip.isInSubnet(new Address4('127.0.0.0/8')) ||
            ip.isInSubnet(new Address4('10.0.0.0/8')) ||
            ip.isInSubnet(new Address4('172.16.0.0/12')) ||
            ip.isInSubnet(new Address4('192.168.0.0/16')) ||
            ip.isInSubnet(new Address4('169.254.0.0/16')) ||
            ip.isInSubnet(new Address4('0.0.0.0/8'))
        );
    };
    // Verification throws a ValidationError if an IP falls within these ranges
};

To prevent DNS Rebinding, where a malicious host changes its DNS record to a loopback address during the socket connection phase (a classic Time-of-Check to Time-of-Use / TOCTOU vulnerability), Unleash overrides Node's native HTTP client lookup function. This pins the connection socket strictly to the pre-validated IP address:

// DNS PINNING CLIENT (addon.ts)
const fetchWithPinnedLookup = async (
    input: Parameters<typeof fetch>[0],
    init: Parameters<typeof fetch>[1],
    validated: ValidatedUrl,
): Promise<Response> => {
    const request = new Request(input, init);
    const body = request.body ? Buffer.from(await request.arrayBuffer()) : undefined;
    const requestUrl = new URL(request.url);
    const client = requestUrl.protocol === 'https:' ? https : http;
 
    return new Promise<Response>((resolve, reject) => {
        const req = client.request(
            requestUrl,
            {
                method: request.method,
                headers: Object.fromEntries(request.headers),
                signal: request.signal,
                lookup: (_hostname, options, callback) => {
                    const cb = typeof options === 'function' ? options : callback;
                    if (typeof cb !== 'function') return;
                    // Forces the network socket to bind exclusively to the pre-validated address
                    cb(null, validated.pinnedAddress, validated.family);
                },
            },
            (res) => { /* Process Response */ }
        );
        req.on('error', reject);
        req.end(body);
    });
};

Exploiting CVE-2026-63004 requires an authenticated administrative session with the capability to create or update integrations. Once these credentials are secured, an attacker targets endpoints inside the private network infrastructure. Common targets include cloud Instance Metadata Services (such as AWS IMDSv1 at 169.254.169.254), container control engines (such as Kubelet APIs on 10.96.0.1), or databases bound strictly to local loopback interfaces.

An administrative attacker initiates the attack by sending a POST or PUT request to /api/admin/addons to register a webhook integration. The request configuration points to the targeted internal network interface:

POST /api/admin/addons HTTP/1.1
Host: unleash.target-network.internal
Authorization: Bearer <ADMIN_TOKEN>
Content-Type: application/json
 
{
  "provider": "webhook",
  "description": "Internal Scan",
  "enabled": true,
  "projects": ["*"],
  "environments": ["*"],
  "events": ["feature-created"],
  "parameters": {
    "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/internal-admin-role",
    "contentType": "application/json"
  }
}

To trigger the outbound request, the attacker performs a benign administrative action, such as creating or toggling a development feature flag. The action triggers the addon event pipeline, forcing the server backend to execute a connection to the specified metadata URL. If the server is hosted in an AWS EC2 or EKS environment running IMDSv1, the metadata service returns the temporary IAM credentials associated with the node's host role. Depending on the server's logging levels and error handling configurations, the backend either leaks these response values directly or generates structural connection oracles (such as HTTP 500 error messages containing returned headers or stack traces), allowing the attacker to retrieve the compromised credentials or map the port states of the internal network.

The impact of this vulnerability depends heavily on the host network topology and cloud deployment configuration. Because Unleash represents a core piece of feature-flag infrastructure, it is frequently placed in high-trust network segments with administrative access to target environments. An administrative attacker exploit can pivot from the web interface into the private VPC or local host loopback.

In containerized or cloud environments, the extraction of temporary credentials from metadata endpoints (such as 169.254.169.254) can lead to complete host cluster takeover. If the service account has excessive permissions on the host platform, the attacker can leverage the extracted keys to compromise supplementary cloud systems. For on-premises installations, the SSRF serves as a network-tunneling vector to probe and map internal databases, cache instances, and management daemons that otherwise exclude external traffic.

The CVSS v3.1 base score is 5.5 (Medium), with high privilege requirements. However, in enterprise environments where the system is integrated into broader cloud boundaries, the "Scope Change" (S:C) metric reflects a significant risk, as exploitation permits an adversary to bypass the administrative logical isolation boundary and compromise adjacent infrastructure services.

The primary remediation strategy is upgrading Unleash to the patched releases: 7.5.2, 7.6.5, or 8.0.2. These updates introduce the validateUrl module, manual redirect handlers, and DNS pinning. In deployments where immediate patching is not feasible, administrators must implement network-level controls and system configurations to restrict outgoing traffic.

Administrators can restrict integrations by setting the environment variable UNLEASH_ALLOW_PRIVATE_URL_IN_INTEGRATION to false. This prevents the addon subsystem from resolving to loopback or private ranges. To enforce stricter controls, specify an explicit allow-list of approved domains using the UNLEASH_ALLOW_LIST_INTEGRATION variable:

export UNLEASH_ALLOW_PRIVATE_URL_IN_INTEGRATION=false
export UNLEASH_ALLOW_LIST_INTEGRATION="hooks.slack.com,api.teams.microsoft.com,api.datadoghq.com"

At the network and host routing layer, restrict the Unleash server's outbound egress. Implement firewall or security group rules to drop any traffic bound for the local metadata service IP (169.254.169.254) or adjacent internal administrative ports. If possible, run Unleash in a segregated network zone with zero default egress routing to private RFC 1918 addresses except for specifically mapped, authenticated destination gateways.