Vulnerability-Lookup

rustsec-2026-0279

Vulnerability from osv_rustsec

Published

2026-06-02 12:00

Modified

2026-09-08 09:58

Summary

Rojo development server vulnerable to DNS rebinding, allowing unauthenticated read/write access and local program execution

Details

Rojo's rojo serve command starts an unauthenticated HTTP API on localhost (default port 34872) with no Host or Origin header validation. While direct cross-origin fetch() requests from a malicious website are blocked by the browser's default CORS policy, an attacker can use DNS rebinding to bypass this restriction entirely.

The serve API is a two-way sync protocol. Once a DNS rebind is established, a malicious webpage visited by a developer running rojo serve can, without any further user interaction:

Read the full project source: GET /api/rojo returns the session ID, root instance ID, and project name. GET /api/read/{id} enumerates the complete instance tree including all script contents, exposing proprietary game logic, configuration, and any secrets embedded in source files.
Write to project files on disk: POST /api/write pushes changes back through Rojo's sync pipeline, allowing an attacker to inject arbitrary Lua into the developer's project. If the developer then publishes their game, the injected code executes on every player's client — a supply chain attack vector.
Launch local programs: POST /api/open/{id} calls the OS-level opener::open() function, which invokes the platform's default handler (open on macOS, xdg-open on Linux, start on Windows) for the target file. Exploitation requires only that rojo serve is running (the standard Roblox development workflow) and that the developer visits an attacker-controlled webpage in any browser on the same machine. The port is a fixed well-known default (34872), there is no authentication, and no user interaction is needed beyond the initial page visit.

The flaw was corrected in #1270, which adds Host/Origin header validation to reject cross-origin requests, gates /api/open to loopback clients regardless of validated origin, and emits a warning when the server binds to a non-loopback address

Reported by Aiden Mohan.

Severity

8.1 (High)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

References

URL

Type

	https://crates.io/crates/rojo	PACKAGE
	https://rustsec.org/advisories/RUSTSEC-2026-0279.html	ADVISORY
	https://github.com/rojo-rbx/rojo/pull/1270	WEB
	https://github.com/rojo-rbx/rojo/commit/ac6941f05…	WEB

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "code-execution",
          "file-disclosure"
        ],
        "cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rojo",
        "purl": "pkg:cargo/rojo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "7.7.0"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [],
  "database_specific": {
    "license": "CC0-1.0"
  },
  "details": "Rojo\u0027s `rojo serve` command starts an unauthenticated HTTP API on localhost\n(default port 34872) with no `Host` or `Origin` header validation. While\ndirect cross-origin `fetch()` requests from a malicious website are blocked by\nthe browser\u0027s default CORS policy, an attacker can use DNS rebinding to bypass\nthis restriction entirely.\n \nThe serve API is a two-way sync protocol. Once a DNS rebind is established, a\nmalicious webpage visited by a developer running `rojo serve` can, without any\nfurther user interaction:\n \n- **Read the full project source:** `GET /api/rojo` returns the session ID,\n  root instance ID, and project name. `GET /api/read/{id}` enumerates the\n  complete instance tree including all script contents, exposing proprietary\n  game logic, configuration, and any secrets embedded in source files.\n- **Write to project files on disk:** `POST /api/write` pushes changes back\n  through Rojo\u0027s sync pipeline, allowing an attacker to inject arbitrary Lua\n  into the developer\u0027s project. If the developer then publishes their game,\n  the injected code executes on every player\u0027s client \u2014 a supply chain attack\n  vector.\n- **Launch local programs:** `POST /api/open/{id}` calls the OS-level\n  `opener::open()` function, which invokes the platform\u0027s default handler\n  (`open` on macOS, `xdg-open` on Linux, `start` on Windows) for the target\n  file.\nExploitation requires only that `rojo serve` is running (the standard Roblox\ndevelopment workflow) and that the developer visits an attacker-controlled\nwebpage in any browser on the same machine. The port is a fixed well-known\ndefault (34872), there is no authentication, and no user interaction is needed\nbeyond the initial page visit.\n \nThe flaw was corrected in [#1270](https://github.com/rojo-rbx/rojo/pull/1270),\nwhich adds `Host`/`Origin` header validation to reject cross-origin requests,\ngates `/api/open` to loopback clients regardless of validated origin, and emits\na warning when the server binds to a non-loopback address\n\nReported by [Aiden Mohan](https://github.com/AidenMohan).",
  "id": "RUSTSEC-2026-0279",
  "modified": "2026-09-08T09:58:15Z",
  "published": "2026-06-02T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/rojo"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0279.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rojo-rbx/rojo/pull/1270"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rojo-rbx/rojo/commit/ac6941f05483b0875fda52c7664cd42033db7fa2"
    }
  ],
  "related": [],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rojo development server vulnerable to DNS rebinding, allowing unauthenticated read/write access and local program execution"
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.