GHSA-5JH9-2H63-PW4Q

Vulnerability from github – Published: 2026-05-29 20:21 – Updated: 2026-05-29 20:21
VLAI
Summary
CC-Tweaked has an SSRF Protection Bypass with NAT64
Details

Summary

CC-Tweaked's HTTP API (http.request, http.websocket) blocks requests to private network ranges to prevent server-side request forgery (SSRF). This protection can be bypassed on IPv6-capable servers using NAT64 well-known prefix addresses (64:ff9b::/96). An attacker who can execute Lua code can reach any internal IPv4 service that the filter is intended to block, by addressing it as http://[64:ff9b::<ipv4-as-hex>]/ instead of its direct IPv4 address. This affects any CC-Tweaked deployment on a network with NAT64 routing — a configuration that is standard on AWS, GCP, and other cloud platforms when using IPv6-only subnets.

Details

The IP filter in PrivatePattern.matches() (AddressPredicate.java#L121–L130) blocks private network ranges by calling Java's standard InetAddress classification methods:

public boolean matches(InetAddress socketAddress) {
    return socketAddress.isAnyLocalAddress()
        || socketAddress.isLoopbackAddress()
        || socketAddress.isLinkLocalAddress()
        || socketAddress.isSiteLocalAddress()
        || socketAddress.isMulticastAddress()
        || isUniqueLocalAddress(socketAddress)
        || isCarrierGradeNatAddress(socketAddress)
        || additionalAddresses.contains(socketAddress);
}

When a NAT64 address such as 64:ff9b::c0a8:0101 (encoding 192.168.1.1) is resolved via new InetSocketAddress("64:ff9b::c0a8:0101", 80), Java returns an Inet6Address. Every method above returns false for this address — the 64:ff9b::/96 prefix is not recognised by any of Java's built-in classification methods. The address passes the filter and CC-Tweaked opens a connection.

On a network with a 64:ff9b::/96 → NAT Gateway route, that connection is translated at the network level: the embedded IPv4 address is extracted and the packet is forwarded to 192.168.1.1:80. The internal service receives a normal IPv4 TCP connection.

The existing 6to4 (2002::/16) mitigation in AddressRule.java#L74–L75 does not cover the NAT64 prefix. No other check catches 64:ff9b::/96.

PoC

Preconditions (all three required): 1. The server running CC-Tweaked has an IPv6 address assigned 2. The network has a NAT Gateway (or equivalent) 3. The route table contains 64:ff9b::/96 → NAT Gateway — the standard AWS/GCP configuration for IPv6-only subnets with outbound IPv4 access (AWS documentation)

Lua payload (targets an internal service at 10.0.1.17:8888):

-- 10.0.1.17 = 0x0a000111, expressed as NAT64: 64:ff9b::0a00:0111
local res = http.request("http://[64:ff9b::0a00:0111]:8888/")
if res then print(res.readAll()) end

Conversion formula — for any blocked IPv4 a.b.c.d, the bypass address is:

64:ff9b::<hex(a)><hex(b)>:<hex(c)><hex(d)>

Impact

This is a server-side request forgery (SSRF) vulnerability. Any user able to execute Lua code on a CC-Tweaked computer — including players on a public server — can use it to send HTTP requests to internal IPv4 services that the HTTP filter is designed to block. On cloud-hosted servers (AWS, GCP, Azure) using IPv6-only subnets with NAT64, which is an increasingly common configuration following AWS's February 2024 public IPv4 pricing change, this includes other instances in the VPC, internal databases, and cloud management APIs.

Suggested fix: add a check for the NAT64 well-known prefix in PrivatePattern.matches():

|| isNAT64Address(socketAddress)

private boolean isNAT64Address(InetAddress address) {
    if (!(address instanceof Inet6Address)) return false;
    byte[] b = address.getAddress();
    // 64:ff9b::/96 — NAT64 well-known prefix (RFC 6052)
    return b[0] == 0x00 && b[1] == 0x64 &&
           b[2] == (byte) 0xff && b[3] == (byte) 0x9b &&
           b[4] == 0 && b[5] == 0 && b[6] == 0 && b[7] == 0 &&
           b[8] == 0 && b[9] == 0 && b[10] == 0 && b[11] == 0;
}

This vulnerability does not seem to work on servers running on modern versions of MacOS.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.21-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.20.1-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.20.4-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.20.5-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.20.6-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.19.3-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.19.4-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "cc.tweaked:cc-tweaked-1.20-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.119.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T20:21:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nCC-Tweaked\u0027s HTTP API (`http.request`, `http.websocket`) blocks requests to private network ranges to prevent server-side request forgery (SSRF). This protection can be bypassed on IPv6-capable servers using NAT64 well-known prefix addresses (`64:ff9b::/96`). An attacker who can execute Lua code can reach any internal IPv4 service that the filter is intended to block, by addressing it as `http://[64:ff9b::\u003cipv4-as-hex\u003e]/` instead of its direct IPv4 address. This affects any CC-Tweaked deployment on a network with NAT64 routing \u2014 a configuration that is standard on AWS, GCP, and other cloud platforms when using IPv6-only subnets.\n\n### Details\n\nThe IP filter in [`PrivatePattern.matches()` (AddressPredicate.java#L121\u2013L130)](https://github.com/cc-tweaked/CC-Tweaked/blob/663ffed4337da0dc3d82ace1e813e3c78b4a8c99/projects/core/src/main/java/dan200/computercraft/core/apis/http/options/AddressPredicate.java#L121-L130) blocks private network ranges by calling Java\u0027s standard `InetAddress` classification methods:\n\n```java\npublic boolean matches(InetAddress socketAddress) {\n    return socketAddress.isAnyLocalAddress()\n        || socketAddress.isLoopbackAddress()\n        || socketAddress.isLinkLocalAddress()\n        || socketAddress.isSiteLocalAddress()\n        || socketAddress.isMulticastAddress()\n        || isUniqueLocalAddress(socketAddress)\n        || isCarrierGradeNatAddress(socketAddress)\n        || additionalAddresses.contains(socketAddress);\n}\n```\n\nWhen a NAT64 address such as `64:ff9b::c0a8:0101` (encoding `192.168.1.1`) is resolved via `new InetSocketAddress(\"64:ff9b::c0a8:0101\", 80)`, Java returns an `Inet6Address`. Every method above returns `false` for this address \u2014 the `64:ff9b::/96` prefix is not recognised by any of Java\u0027s built-in classification methods. The address passes the filter and CC-Tweaked opens a connection.\n\nOn a network with a `64:ff9b::/96 \u2192 NAT Gateway` route, that connection is translated at the network level: the embedded IPv4 address is extracted and the packet is forwarded to `192.168.1.1:80`. The internal service receives a normal IPv4 TCP connection.\n\nThe existing 6to4 (`2002::/16`) mitigation in [`AddressRule.java#L74\u2013L75`](https://github.com/cc-tweaked/CC-Tweaked/blob/663ffed4337da0dc3d82ace1e813e3c78b4a8c99/projects/core/src/main/java/dan200/computercraft/core/apis/http/options/AddressRule.java#L74-L75) does not cover the NAT64 prefix. No other check catches `64:ff9b::/96`.\n\n### PoC\n\n**Preconditions** (all three required):\n1. The server running CC-Tweaked has an IPv6 address assigned\n2. The network has a NAT Gateway (or equivalent)\n3. The route table contains `64:ff9b::/96 \u2192 NAT Gateway` \u2014 the standard AWS/GCP configuration for IPv6-only subnets with outbound IPv4 access ([AWS documentation](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html))\n\n**Lua payload** (targets an internal service at `10.0.1.17:8888`):\n```lua\n-- 10.0.1.17 = 0x0a000111, expressed as NAT64: 64:ff9b::0a00:0111\nlocal res = http.request(\"http://[64:ff9b::0a00:0111]:8888/\")\nif res then print(res.readAll()) end\n```\n\n**Conversion formula** \u2014 for any blocked IPv4 `a.b.c.d`, the bypass address is:\n```\n64:ff9b::\u003chex(a)\u003e\u003chex(b)\u003e:\u003chex(c)\u003e\u003chex(d)\u003e\n```\n\n### Impact\n\nThis is a server-side request forgery (SSRF) vulnerability. Any user able to execute Lua code on a CC-Tweaked computer \u2014 including players on a public server \u2014 can use it to send HTTP requests to internal IPv4 services that the HTTP filter is designed to block. On cloud-hosted servers (AWS, GCP, Azure) using IPv6-only subnets with NAT64, which is an [increasingly common configuration following AWS\u0027s February 2024 public IPv4 pricing change](https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/), this includes other instances in the VPC, internal databases, and cloud management APIs.\n\n**Suggested fix:** add a check for the NAT64 well-known prefix in [`PrivatePattern.matches()`](https://github.com/cc-tweaked/CC-Tweaked/blob/663ffed4337da0dc3d82ace1e813e3c78b4a8c99/projects/core/src/main/java/dan200/computercraft/core/apis/http/options/AddressPredicate.java#L121-L130):\n\n```java\n|| isNAT64Address(socketAddress)\n\nprivate boolean isNAT64Address(InetAddress address) {\n    if (!(address instanceof Inet6Address)) return false;\n    byte[] b = address.getAddress();\n    // 64:ff9b::/96 \u2014 NAT64 well-known prefix (RFC 6052)\n    return b[0] == 0x00 \u0026\u0026 b[1] == 0x64 \u0026\u0026\n           b[2] == (byte) 0xff \u0026\u0026 b[3] == (byte) 0x9b \u0026\u0026\n           b[4] == 0 \u0026\u0026 b[5] == 0 \u0026\u0026 b[6] == 0 \u0026\u0026 b[7] == 0 \u0026\u0026\n           b[8] == 0 \u0026\u0026 b[9] == 0 \u0026\u0026 b[10] == 0 \u0026\u0026 b[11] == 0;\n}\n```\n\nThis vulnerability does not seem to work on servers running on modern versions of MacOS.",
  "id": "GHSA-5jh9-2h63-pw4q",
  "modified": "2026-05-29T20:21:12Z",
  "published": "2026-05-29T20:21:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cc-tweaked/CC-Tweaked/security/advisories/GHSA-5jh9-2h63-pw4q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cc-tweaked/CC-Tweaked"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CC-Tweaked has an SSRF Protection Bypass with NAT64"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…