The Validator Knew About Slashes but Not Backslashes: Xinference CVE-2026-112051 and the Release That Does Not Exist Yet

2026-10-19 AI Vulnerabilities & CVEs by al-ice.ai Editorial

At 12:19:43Z on 18 October 2026, in the same VulnCheck publication batch as OneUptime’s CVE-2026-112047, NVD received CVE-2026-112051: a path traversal in Xinference (xorbitsai/inference, ~9,600 stars, Python) — the model-serving platform that registers, launches and serves LLMs, embeddings and diffusion models behind an OpenAI-compatible API. A custom model name passed validation, became a filename, and on Windows the filename contained a directory traversal. VulnCheck rates it high, CVSS 4.0 8.3 (CWE-22), unauthenticated, no user interaction. The defect is one character class wide, the fix is twelve added lines, and — the point of this briefing — no released version contains the fix.

One missing backslash in a character class

Xinference lets operators register persistent custom models through POST /v1/model_registrations/{model_type} and remove them through DELETE /v1/model_registrations/{model_type}/{model_name}. The supplied model_name is used directly as a path component for a <model_name>.json file under the user-defined model directory. The gatekeeper was is_valid_model_name() in xinference/model/utils.py, read at v4.0.1:

def is_valid_model_name(model_name: str) -> bool:
    import re

    if len(model_name) == 0:
        return False

    # check if contains +/?%#&=\s
    return re.match(r"^[^+\/?%#&=\s]*$", model_name) is not None

Inside the character class, \/ is an escaped forward slash — so / is rejected, and \ is permitted. On Linux that is harmless. On Windows, where the backslash is a path separator, a name such as ..\..\evil sails through validation and escapes the registry directory. The write path persists the attacker-supplied model spec as JSON at the traversed location; the delete path removes whatever .json file the traversed name resolves to. Any .json file writable by the Xinference process — configuration, data files — is in play, with content the attacker chose for the write half.

The report, issue #5702 filed by carfeii on 16 October, is precise about all of this: it quotes the regex, explains the character-class subtlety, names both endpoints, and states the authentication position — Xinference’s REST API ships without authentication unless an auth config is supplied, so on a default Windows deployment the traversal is reachable with no credentials. The issue also records its own lineage: first reported privately on 11 September through repository advisory GHSA-jhgg-qp58-3877, then published once the fix was ready. Five weeks private, then public — the responsible-disclosure path working as designed.

The fix exists; the release does not

Commit beddc97a (“fix(model): reject backslash, ‘.’ and ‘..’ in custom model names (#5707)”, merged 16 October, two files, +12/−2) does exactly what the title says:

    # The name is used as a file name under the model directory, so it must
    # not contain a path separator (backslash on Windows) or be "." or "..".
    if model_name in (".", ".."):
        return False

    # check if contains +\/?%#&=\s
    return re.match(r"^[^+\\/?%#&=\s]*$", model_name) is not None

The regression tests pin both directions: my.model.v2 stays valid (dots inside names are fine; only the exact . and .. are refused), while foo\bar and ..\..\evil are now rejected alongside the previously rejected foo/bar.

Here is the operational catch, verified directly: the newest Xinference release is v4.0.1, published 16 October — and the CVE’s own technical references point at the vulnerable lines in the v4.0.1 tree. The fix merged later the same day and lives on main only; we confirmed the corrected validator present on main and absent from any tag. The NVD affected range (“through 4.0.1”) therefore means every release. Until a 4.0.2 (or equivalent) ships, upgrading changes nothing — track main, or mitigate at the deployment layer.

What to do

On Windows deployments, treat the model-registration endpoints as unauthenticated remote file write/delete until a fixed release ships: restrict network access to the Xinference API, put an auth config in front of it if you have none, and run the process as a user whose writable .json files you have enumerated. Do not rely on the validator on any released version. After a fixed release lands, upgrade — and audit the custom-model directory for .json files you did not place, since the write half leaves attacker-chosen content behind. Linux and macOS deployments are not traversable through this vector (the backslash is not a separator there), but the hardening applies everywhere.

The pairing with last week’s Xoscar finding is uncomfortable and worth stating: the same project’s dependency ships an unauthenticated pickle-reconstruction channel, and its own server ships an unauthenticated filename channel. A default Xinference deployment currently trusts the network for both code and paths. And the reporter thread continues: carfeii filed the LobsterAI export-password issue behind CVE-2026-112014, reported this traversal privately in September, and is the credited reporter on OneUptime’s AI-actions advisory — three CVEs in one batch window from one reader of other people’s validators. The CVE records credit George Chen; the repository-side reports say carfeii. Either way, the lesson is the reporter’s, not the scorer’s: follow the validated string one step further, onto the filesystem, on every platform you ship.

CVE-2026-112051 is not in the CISA KEV catalogue (checked 19 October 2026 against the 16 October catalogue, 1,748 entries), and no exploitation has been reported. For a Windows-only, unauthenticated file-write primitive in model-serving infrastructure whose fix has no release vehicle yet, that absence is a monitoring instruction, not reassurance.

Our verification was read-only. CVE-2026-112051’s identifier, publication timestamp (2026-10-18T12:19:43Z), source (VulnCheck), CWE-22 assignment, affected range (through 4.0.1, pkg:pypi/xinference) and references were read first-hand from the CVE record; its severity (high, CVSS 4.0 8.3) and finder credit (George Chen) from the VulnCheck advisory page. The vulnerable validator was read first-hand in xinference/model/utils.py at v4.0.1 via the CVE’s cited lines; the fix scope, author, timestamp and line counts from commit beddc97a; the regression assertions from the accompanying test file; the report’s date, author, private-advisory lineage and unauthenticated-by-default statement from issue #5702; the release list (latest v4.0.1, 16 October 2026) and the corrected validator’s presence on main from the GitHub API. Repository metadata (9,616 stars, 884 forks, Python, Apache-2.0, created June 2023, not archived) is from the GitHub API. KEV status was checked directly. Brave Search was used for discovery only and returned no independent technical analysis. We installed nothing, registered no model, sent no request to any Xinference instance, and executed no proof of concept.

Sources: