CVE-2026-73410

Executive Summary

CVE-2026-73410 describes a critical DNS rebinding vulnerability in Budibase, an open-source low-code platform, affecting versions prior to 3.40.0. A malicious builder with low-level privileges can exploit this flaw to bypass network access controls, allowing the Budibase server to connect to arbitrary internal network addresses. This enables severe impacts including full response access and the ability to execute arbitrary REST methods against internal systems, leading to high confidentiality, integrity, and availability compromise of an organization's internal infrastructure.

Technical Analysis

Budibase is designed as an open-source platform enabling rapid application development. The vulnerability, identified as CVE-2026-73410 (CWE-367: Insufficient Synchronization), stems from an inconsistency in how network requests are handled, specifically within REST integration functionalities.

At its core, the vulnerability arises from a discrepancy between how Budibase initially validates an outbound address and how subsequent connections are established. The component packages/backend-core/src/utils/outboundFetch.ts is designed to pin a validated address using a Node agent, ensuring that once a hostname is resolved and approved, future requests to that hostname utilize the pre-validated IP address. This mechanism is intended to prevent attacks where a hostname's DNS record is altered post-validation.

However, the REST integration functionality, crucial for connecting Budibase applications to external (and potentially internal) services, does not consistently adhere to this pinned address. Instead, it utilizes getDispatcher from packages/backend-core/src/utils/fetch.ts. This dispatcher, when interacting with the undici HTTP/1.1 client, fails to properly inherit or respect the Node agent's pinned address. Consequently, undici performs a fresh DNS resolution for the hostname associated with the REST integration whenever a request is made, effectively ignoring the initial validation and pinned address.

This behavior creates a window for a DNS rebinding attack. An attacker, acting as a "builder" within the Budibase platform (a low-privileged role as per the CVSS vector PR:L), can define a REST integration that points to a hostname they control. Initially, the attacker's domain is configured to resolve to a public IP address, allowing it to pass Budibase's initial validation checks carried out by outboundFetch.ts. After this validation, but critically, before or during the actual execution of a REST request, the attacker can rapidly change the DNS record for their controlled domain. The new DNS record is configured to resolve to an internal IP address (e.g., an address within RFC 1918 ranges like 192.168.x.x, 10.x.x.x, or 172.16.x.x).

When the packages/server/src/integrations/rest.ts module attempts to perform an actual REST request using the undici dispatcher, undici performs a fresh DNS lookup, resolves the attacker's domain to the newly specified internal IP address, and initiates a connection to an internal service. This circumvents the intended security measure of pinning the validated external IP. The vulnerable system then makes requests to the internal network on behalf of the attacker, providing "full response access and arbitrary REST methods."

The fix for this vulnerability, implemented in Budibase version 3.40.0, involves adding createPinnedLookup support directly to the undici dispatcher. Furthermore, the validated address is explicitly passed to custom fetch implementations, ensuring that undici consistently respects the initially resolved and validated IP address, thereby preventing the DNS rebinding window.

Exploitation Scenarios

Exploiting CVE-2026-73410 leverages the trust relationship within the Budibase application and its ability to interact with defined REST integrations. The attack chain primarily targets internal network resources that the Budibase server can reach but which are otherwise inaccessible from the internet.

1. Reconnaissance/Target Identification: An attacker first identifies a publicly accessible Budibase instance that is running a vulnerable version (prior to 3.40.0). This can be achieved through various internet scanning techniques, including specific Shodan dorks (http.title:"Budibase" or "Budibase") or by directly enumerating known Budibase deployments. The attacker then needs to gain access to a "builder" account on the target Budibase instance. This low-privileged access (PR:L in CVSS) might be achieved through standard credential compromise, weak password exploitation, or social engineering.

2. Triggering the Flaw (Initial Validation Bypass): With "builder" privileges, the attacker creates a new REST integration within the Budibase platform. For this integration, the attacker specifies a URL pointing to a domain name that they control (e.g., attacker-controlled-domain.com). At this initial stage, the attacker has configured attacker-controlled-domain.com to resolve to a public IP address that they also control (e.g., their own web server or a benign public IP). When the Budibase platform attempts to validate this integration (likely through packages/backend-core/src/utils/outboundFetch.ts), it resolves attacker-controlled-domain.com to the public IP and, finding it acceptable, allows the integration to be saved. The key is that this initial validation only "pins" the public IP to a Node agent, but this pinning is not respected by the undici dispatcher used by the REST integration.

3. Payload/Execution Method (DNS Rebinding and Internal Access): Immediately after the REST integration is successfully validated and saved, the attacker rapidly changes the DNS record for attacker-controlled-domain.com. The new DNS record is configured to resolve to an internal IP address within the victim's network (e.g., 192.168.1.10, 10.0.0.50, or the IP of an internal database, API, or management interface). When the attacker (or a user interacting with an application built by the attacker) triggers an action within Budibase that makes a call to this malicious REST integration, the packages/server/src/integrations/rest.ts component initiates a request. During this process, packages/backend-core/src/utils/fetch.ts's getDispatcher is invoked, which in turn uses undici. Because undici ignores the previously pinned address and performs a fresh DNS lookup, it resolves attacker-controlled-domain.com to the new internal IP address. The Budibase server then directly connects to this internal system. The arbitrary REST methods allow the attacker to craft specific HTTP requests (GET, POST, PUT, DELETE, etc.) to interact with the internal service.

4. Post-Exploitation Impact: Upon successful connection to an internal host, the attacker gains "full response access and arbitrary REST methods" against that internal system. This has several severe consequences:

   • Internal Network Enumeration: By crafting various REST requests to common internal IP ranges and ports, the attacker can map out the internal network, discover active services, and identify other vulnerable systems.
   • Data Exfiltration: If the internal system is a database, file share, or internal API containing sensitive data, the attacker can use arbitrary REST methods to query, extract, and exfiltrate this information.
   • Lateral Movement and Further Compromise: The ability to execute arbitrary REST methods against internal systems can be leveraged to interact with internal APIs, potentially triggering actions, configuring services, or even achieving remote code execution on other internal hosts if those internal services have their own vulnerabilities.
   • Service Disruption: Arbitrary REST methods could also be used to send malformed requests or overload internal services, leading to denial of service.

The attack's success hinges on the attacker's ability to quickly update DNS records and the Budibase server's prompt re-resolution of the hostname. While no public PoC is available, the attack chain is a well-understood mechanism for server-side request forgery (SSRF) facilitated by DNS rebinding, directly inferred from the vulnerability class and detailed NVD description.

Impact Assessment

The CVSS v3.1 score for CVE-2026-73410 is 8.5, categorized as High severity. This score reflects a significant potential for severe damage to an organization's confidentiality, integrity, and availability, primarily by enabling unauthorized access to internal networks.

Breaking down the CVSS vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H:

• Attack Vector (AV:N - Network): The vulnerability can be exploited remotely over a network. An attacker does not need physical access or even local network access to the Budibase server; they only need network connectivity to the publicly exposed Budibase instance. This significantly broadens the attack surface.
• Attack Complexity (AC:H - High): Exploitation requires a high level of sophistication. Specifically, DNS rebinding attacks are time-sensitive and require the attacker to control a domain's DNS records, rapidly changing them between validation and request execution. This involves setting up custom DNS servers or quickly updating records, making it more challenging than simpler attacks.
• Privileges Required (PR:L - Low): The attacker only needs "builder" privileges within the Budibase platform. This indicates that a successful compromise does not require administrative access, making it potentially easier to achieve initial access through less robust credentials or standard user accounts.
• User Interaction (UI:N - None): No user interaction is required on the part of the victim. Once the malicious REST integration is configured by the attacker (as a builder), the server itself performs the vulnerable action when the integration is triggered, without requiring a legitimate user to click a link or download a file.
• Scope (S:C - Changed): This is a critical aspect of the vulnerability. A "Changed" scope indicates that the vulnerability in one component (the Budibase application's REST integration) has a security impact on components or resources beyond its immediate security scope (the internal network). The attacker transitions from interacting with the Budibase application itself to directly interacting with internal services that would otherwise be inaccessible.
• Confidentiality (C:H - High): The attacker gains "full response access" to arbitrary internal REST methods. This means they can read sensitive data from internal systems, including databases, internal APIs, configuration files, and other services. This could lead to the exposure of credentials, personal identifiable information (PII), intellectual property, or other proprietary data.
• Integrity (I:H - High): The ability to use "arbitrary REST methods" implies the attacker can not only read but also modify or delete data on internal systems. For example, they could alter database records, modify configurations on internal services, or inject malicious data, leading to severe data corruption or unauthorized changes.
• Availability (A:H - High): By performing arbitrary REST methods against internal services, an attacker could potentially disrupt their operation. This might involve sending malicious commands, initiating resource-intensive queries, or triggering denial-of-service conditions in internal applications, severely impacting business operations and critical functions.

Business Impact: The cumulative business impact is severe. Organizations using vulnerable Budibase instances face a significant risk of internal network compromise, leading to:

• Data Breaches: Exposure of sensitive customer data, financial records, or intellectual property.
• Operational Disruption: Interruption of critical internal services and business processes.
• Reputational Damage: Loss of customer trust and brand damage due to security incidents.
• Regulatory Fines: Non-compliance with data protection regulations (e.g., GDPR, HIPAA) following a breach.
• Further Attacks: The compromised Budibase server can serve as a pivot point for lateral movement and more advanced attacks within the network.

Affected Systems and Blast Radius: The primary affected system is the Budibase server running a version prior to 3.40.0. The blast radius, however, extends to any internal system or service that the Budibase server can reach via network connections. This includes, but is not limited to:

• Internal databases (SQL, NoSQL).
• Internal APIs and microservices.
• Intranet web applications.
• Authentication systems (LDAP, Active Directory).
• File servers and network-attached storage.
• Other application servers and backend systems. The extent of the blast radius depends directly on the network segmentation and egress filtering policies applied to the Budibase server. If the server has broad access to the internal network, the entire internal infrastructure is at risk.

Detection Guidance

Detecting exploitation attempts for CVE-2026-73410 is challenging due to the nature of DNS rebinding, which manipulates legitimate network functionalities. Detection strategies should focus on monitoring anomalous outbound network connections from the Budibase server, unusual DNS resolution patterns, and suspicious activities within the Budibase platform itself.

Sigma Rule

A Sigma rule focuses on detecting outbound network connections from the Budibase application process to RFC1918 private IP ranges, especially if those connections are unexpected for the typical operation of a Budibase server. This assumes process logging is enabled.

title: Budibase DNS Rebinding Exploitation Attempt (CVE-2026-73410)
id: 00000000-0000-4000-8000-000000000001 # Placeholder - generate a unique UUID
related:
  - CVE-2026-73410
status: experimental
description: Detects suspicious outbound network connections from Budibase server process to internal/private IP ranges, indicative of a DNS rebinding attack exploiting CVE-2026-73410.
author: ValterSit Threat Intelligence
logsource:
  category: network_connection
  product: linux
  service: auditd # Or other process/network logging source like Sysmon for Windows
detection:
  selection:
    Image|endswith:
      - '\node' # Budibase backend runs on Node.js
      - '\npm'
      - '\budibase-server' # Assuming a specific process name for Budibase server
    # Target private IP ranges (RFC1918)
    DestinationIp|startswith:
      - '10.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.20.'
      - '172.21.'
      - '172.22.'
      - '172.23.'
      - '172.24.'
      - '172.25.'
      - '172.26.'
      - '172.27.'
      - '172.28.'
      - '172.29.'
      - '172.30.'
      - '172.31.'
      - '192.168.'
    # Exclude known legitimate internal connections if applicable (e.g., to database)
    # This might require tuning specific to environment
    # DestinationIp|!startswith:
    #   - '10.0.0.10' # Example: exclude known internal database IP
  condition: selection
falsepositives:
  - Legitimate internal service integrations if Budibase is configured to interact with private IPs. Requires baselining.
level: high

YARA Rule

A YARA rule for this vulnerability would be challenging without specific exploit code patterns or artifacts left on disk. However, if an attacker were to save specific malicious REST integration definitions that contain unusual or rapidly changing domain names, or if specific malicious response handling logic was injected, a YARA rule could potentially identify these. This rule will focus on highly generic patterns related to HTTP requests and domain names often used in DNS rebinding, with a strong caveat that it's unlikely to be effective without more specific IOCs.

rule CVE_2026_73410_Budibase_DNS_Rebinding
{
  meta:
    author = "ValterSit Threat Intelligence"
    date = "2023-10-27"
    description = "Attempts to detect artifacts related to CVE-2026-73410 DNS rebinding in Budibase, primarily targeting suspicious domain patterns or internal IP references within configuration."
    severity = "medium"
    cve = "CVE-2026-73410"
    licence = "Detection Rule License 1.1"

  strings:
    // Common patterns for URLs in REST integrations
    $s1 = "rest.ts connect to an internal address" ascii wide // Directly from NVD, high confidence
    $s2 = "undici to ignore that agent and resolve the hostname again" ascii wide // Directly from NVD, high confidence
    $s3 = "packages/server/src/integrations/rest.ts" ascii wide // Relevant file path from NVD
    $s4 = "packages/backend-core/src/utils/fetch.ts" ascii wide // Relevant file path from NVD
    $s5 = "packages/backend-core/src/utils/outboundFetch.ts" ascii wide // Relevant file path from NVD

    // Look for URL patterns that might indicate a placeholder for rebinding
    // Attacker-controlled domains might use dynamic DNS or short-lived domains
    $s6 = /^(http|https):\/\/[a-z0-9-]+\.(xip\.io|nip\.io|sslip\.io)/ ascii // Common DNS rebinding services
    $s7 = /^(http|https):\/\/[a-z0-9-]{5,15}\.[a-z]{2,5}\/[^\s"']*/ ascii // Generic suspicious short domain + path
    $s8 = /internal-service\.local|192\.168\.\d{1,3}\.\d{1,3}|10\.\d{1,3}\.\d{1,3}\.\d{1,3}/ ascii // References to internal IPs/hostnames

  condition:
    (uint16(0) == 0x5a4d and uint32(uint32(0x3c)) == 0x00004550) or // Executable
    (any of ($s1, $s2, $s3, $s4, $s5)) or // Keywords from NVD
    (1 of ($s6, $s7, $s8) and filesize < 5MB) // Look for suspicious URL patterns in configs/scripts
}

Suricata IDS Rule

A Suricata rule would focus on detecting the outbound connection to private IP ranges from the Budibase server. It's difficult to specifically detect the DNS rebinding event at the network layer without stateful correlation of DNS requests and subsequent HTTP connections, which would require more advanced techniques than a simple rule. This rule focuses on the consequence: the Budibase server initiating connections to unexpected internal IPs.

# Detect outbound HTTP/HTTPS connections from Budibase server to RFC1918 addresses
# This assumes the Budibase server's IP is known, or it's applied as an egress rule.
alert http any any -> [10.0.0.0/8,172.16.0.0/12,192.168.0.0/16] any (msg:"CVE-2026-73410 Budibase DNS Rebinding - Outbound HTTP to Private IP"; flow:to_server; http.method; content:"GET"; classtype:attempted-recon; sid:20267341001; rev:1;)
alert http any any -> [10.0.0.0/8,172.16.0.0/12,192.168.0.0/16] any (msg:"CVE-2026-73410 Budibase DNS Rebinding - Outbound POST to Private IP"; flow:to_server; http.method; content:"POST"; classtype:attempted-recon; sid:20267341002; rev:1;)
alert tls any any -> [10.0.0.0/8,172.16.0.0/12,192.168.0.0/16] any (msg:"CVE-2026-73410 Budibase DNS Rebinding - Outbound TLS to Private IP"; flow:to_server; tls.handshake.type:1; classtype:attempted-recon; sid:20267341003; rev:1;)

# More advanced: Correlate DNS responses with subsequent connections if possible.
# This would require a more complex rule or external correlation engine.
# For example, look for DNS responses for a domain, then connection to a private IP for that domain.
# Example (conceptual, requires stateful logic beyond simple rule):
# alert dns any any -> $HOME_NET any (msg:"DNS Query for suspicious domain"; dns.query; pcre:"/^(attacker|dynamic)\-[a-z0-9]+\.(xip\.io|nip\.io)/i"; sid:20267341004; rev:1;)

Elastic Detection

Elastic EQL can correlate events from various data sources (e.g., process, network, dns). A robust detection would involve looking for a node process (Budibase backend) making unexpected outbound connections to private IP addresses. If DNS logs are available, correlating DNS queries for a domain resolving to an external IP, followed shortly by a connection attempt to an internal IP for the same domain, would be ideal.

{
  "query": {
    "bool": {
      "must": [
        {
          "match_phrase": {
            "event.category": "network"
          }
        },
        {
          "match_phrase": {
            "event.type": "connection"
          }
        },
        {
          "wildcard": {
            "process.executable.text": "*node*"
          }
        },
        {
          "bool": {
            "should": [
              { "cidr": { "destination.ip": "10.0.0.0/8" } },
              { "cidr": { "destination.ip": "172.16.0.0/12" } },
              { "cidr": { "destination.ip": "192.168.0.0/16" } }
            ],
            "minimum_should_match": 1
          }
        }
        // Optional: Exclude known legitimate internal IPs or services accessed by Budibase
        // {
        //   "bool": {
        //     "must_not": [
        //       { "match_phrase": { "destination.ip": "10.0.0.10" } }, // Example: internal database
        //       { "match_phrase": { "destination.port": 5432 } } // Example: PostgreSQL
        //     ]
        //   }
        // }
      ]
    }
  },
  "index": ["logs-*", "packetbeat-*", "auditbeat-*"]
}

// More advanced EQL for DNS rebinding correlation (requires DNS logs and network connections)
/*
sequence by host.ip
  [dns where dns.question.name : "*.attacker-controlled-domain.com" and dns.resolved_ip != "1.2.3.4" and dns.resolved_ip !in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]
  [network where process.executable.text : "*node*" and destination.ip in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") and destination.domain : "*.attacker-controlled-domain.com"]
*/

Splunk SPL Query

A Splunk query would similarly focus on monitoring outbound network connections from the Budibase server process to private IP ranges, potentially correlating with DNS queries.

# Detect outbound connections from Budibase process to private IP ranges
index=* (sourcetype=linux_audit OR sourcetype=syslog OR sourcetype=stream:tcp OR sourcetype=pan:traffic)
| search (comm="node" OR process="budibase-server")
| search dest_ip IN ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
| stats count by _time, host, process, dest_ip, dest_port, user
| `cim_network_traffic_filter` # Use Splunk CIM if available for consistent field names
| table _time, host, process, dest_ip, dest_port, user, count

# Advanced: Correlate DNS requests with subsequent network connections for DNS rebinding
# This requires DNS logs (e.g., from network devices or server DNS caches)
# and network connection logs from the Budibase host.
# index=dns_logs query="*.attacker-controlled-domain.com"
# | eval original_ip=resolved_ip
# | join _time host
#    [search index=network_logs src_ip="<budibase_server_ip>" dest_ip IN ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") dest_domain="*.attacker-controlled-domain.com"]
# | where original_ip!=dest_ip # If the resolved IP changed from public to private
# | table _time, host, query, original_ip, dest_ip, dest_port

Wazuh OSSEC Rule

Wazuh can monitor process execution and network connections. A rule can be created to detect outbound connections from the node process (which runs the Budibase backend) to internal IP addresses.

<group name="budibase,vulnerability,cve,dns_rebinding,">

  <rule id="100001" level="12">
    <if_sid>60000</if_sid> <!-- Generic rule for new active internet connection -->
    <field name="srcip">BUDIBASE_SERVER_IP</field> <!-- Replace with actual Budibase server IP -->
    <match offset="0" type="pcre2">\b(10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})\b</match>
    <description>Budibase DNS Rebinding - Outbound Connection to Private IP from Budibase Server</description>
    <group>attack,</group>
    <options>no_email_alert</options>
  </rule>

  <rule id="100002" level="10">
    <if_sid>530</if_sid> <!-- Generic rule for new process started (Sysmon/Auditd equivalent) -->
    <field name="process.name">node|npm|budibase-server</field> <!-- Adjust process name as needed -->
    <regex>.* (connect|socket) (10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}) .*</regex>
    <description>Budibase DNS Rebinding - Process connecting to private IP</description>
    <group>attack,</group>
  </rule>

  <!-- This rule relies on log data containing the process name and target IP.
       Consider configuring specific process auditing for the Budibase application,
       e.g., via auditd logs on Linux, and sending them to Wazuh for analysis. -->

</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED

While the NVD description explicitly states, "This issue is fixed in version 3.40.0," the provided patch confidence indicates that this fix has not been independently verified or tracked by external sources. Organizations should proceed with caution, prioritize internal testing of the patch, and implement robust compensatory controls.

1. Immediate Mitigations (Temporary & Compensatory):

   • Egress Filtering: Implement strict network egress filtering on firewalls and security groups for the Budibase server. Restrict outbound connections from the Budibase server to only known, whitelisted external IP addresses and domains that are absolutely necessary for its operation. Crucially, block all outbound connections from the Budibase server to RFC 1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). This is the most critical immediate mitigation to prevent internal network access.
   • Principle of Least Privilege for Builders: Review and enforce the principle of least privilege for "builder" accounts within Budibase. If possible, restrict their ability to create or modify REST integrations, or impose stricter review processes for such integrations, particularly those connecting to external resources.
   • DNS Monitoring: Implement enhanced DNS monitoring to detect rapid changes in DNS records for domains actively used by Budibase REST integrations, especially if those domains are controlled by third parties.
   • Network Segmentation: Isolate the Budibase server within a demilitarized zone (DMZ) or a highly restricted network segment. This limits its ability to reach sensitive internal systems even if a bypass is achieved.
   • Outbound Proxy/Web Application Firewall (WAF): Route all outbound traffic from the Budibase server through an explicit proxy or WAF that can perform deeper inspection of destination IPs and hostnames, and enforce more granular access policies.

2. Patch/Upgrade Steps (Permanent Fix):

   • Upgrade to Version 3.40.0 or Later: According to the NVD description, Budibase version 3.40.0 contains the fix for CVE-2026-73410. Organizations should plan to upgrade their Budibase instances to this version or a newer stable release as soon as possible.
   • Backup: Before any upgrade, ensure a full backup of the Budibase application data and configuration.
   • Staging Environment Testing: Always perform upgrades in a staging or development environment first to ensure compatibility and stability before deploying to production.
   • Review Release Notes: Consult the official Budibase release notes for version 3.40.0 (or subsequent versions) for any additional post-upgrade steps, known issues, or security enhancements.

3. Long-Term Hardening:

   • Regular Security Audits: Conduct regular security audits and penetration tests of Budibase deployments, focusing on configurations of integrations and network egress policies.
   • Secure Development Practices: Encourage and enforce secure development practices for custom Budibase applications, particularly concerning data input validation and external integrations.
   • Robust Logging and Monitoring: Implement comprehensive logging for all Budibase application activity, network connections, and DNS resolutions. Ensure these logs are centralized and actively monitored by a Security Information and Event Management (SIEM) system.
   • Zero Trust Architecture: Adopt Zero Trust principles where every connection, whether internal or external, is authenticated and authorized based on least privilege. This can help limit the impact of vulnerabilities that bypass perimeter defenses.
   • Supply Chain Security: Regularly review the security posture of open-source components and third-party libraries used within Budibase deployments to proactively identify and address potential vulnerabilities.

References

• National Vulnerability Database (NVD) Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-73410 (Note: URL will become active upon publication)
• Budibase GitHub Repository (Potential for Fix Commits/Release Notes): https://github.com/Budibase/budibase (Specific commit or release notes for 3.40.0 should be sought here)
• CWE-367 (Insufficient Synchronization) - MITRE: https://cwe.mitre.org/data/definitions/367.html
• DNS Rebinding Attacks Explained: https://owasp.org/www-community/attacks/DNS_Rebinding
• Undici Project (Node.js HTTP/1.1 client): https://undici.nodejs.org/