CVE-2026-47731 - AIT-Core BSC path traversal file append

NASA AMMOS AIT-Core Binary Stream Capture (BSC) exposed an unauthenticated HTTP API that could create packet-capture handlers from request-controlled form fields. A remote client could escape the configured BSC log root and append attacker-controlled data to arbitrary files writable by the ait-bsc process. Depending on deployment and file targets, this can corrupt telemetry artifacts, exhaust disk, damage Python modules or shell scripts, and create a route to code execution after a restart or later operator action.

The safe remediation is more than a package bump. Repositories that deploy BSC must upgrade, prove all BSC log paths stay under the configured root, remove unauthenticated network exposure, and document operator review for corrupted files or unexpected handler creation.

When to use it

Use this recipe when a Python service uses NASA AIT-Core Binary Stream Capture or an equivalent unauthenticated/low-trust API that appends uploaded stream data to filesystem paths. It is designed for source-code remediation, canonical path containment, service-account privilege review, deployment isolation, and evidence that attacker-controlled names cannot append outside the configured capture directory.

Inputs

  • ait-core version, Python dependency/lockfile state, BSC configuration, service account, capture root, deployment topology, and generated dependency or SBOM reports.
  • Source/config paths that expose BSC APIs, resolve stream names to files, append data, normalize paths, configure auth/network access, or process captured files after write.
  • Regression fixtures for traversal names, absolute paths, symlinks, benign stream names, append-only behavior, denied out-of-root writes, and service isolation.
  • Boundary evidence: writable directories, unauthenticated exposure, mission or telemetry data sensitivity, service privileges, logs, cleanup owner, and rollout owner.

Affected versions

  • Vulnerable package: ait-core <2.6.1
  • Vulnerable package: ait-core ==3.1.0
  • Fixed package: ait-core 2.6.1+ on the 2.x line or 3.1.1+ on the 3.x line
  • Affected component: Binary Stream Capture (ait-bsc)
  • Affected operation: unauthenticated handler creation through the BSC HTTP API, especially /<name>/start
  • Affected controls: log_dir_path, path, and file_name_pattern confinement to the configured BSC root log directory

Indicator-of-exposure

  • The repository depends on, vendors, forks, builds, or deploys ait-core in an affected version range.
  • BSC or ait-bsc is enabled in scripts, services, mission tooling, lab automation, containers, Kubernetes manifests, systemd units, or runbooks.
  • The BSC HTTP API is reachable from a network segment, forwarded port, operator workstation, lab network, remote desktop, VPN, tunnel, or localhost browser context that can be targeted by cross-site requests.
  • The ait-bsc process can write outside disposable log storage or runs with permission to modify source trees, mission artifacts, scripts, config, home directories, or shared volumes.
  • Config allows user-controlled handler path fields, file name patterns, or log directories to reach BSC without canonical path validation.

Quick checks:

rg -n "ait-core|ait_bsc|ait-bsc|Binary Stream Capture|StreamCaptureManager|root_log_directory|log_dir_path|file_name_pattern|/<name>/start|bsc.yaml|ait.core.bsc" .
python -m pip show ait-core
python -m pip freeze | rg -i "^ait-core=="
rg -n "ait-bsc|bsc.yaml|root_log_directory|AIT_CONFIG|ait.core.bsc" Dockerfile* docker-compose*.yml compose*.yml charts k8s systemd scripts .github . 2>/dev/null

Windows:

rg -n "ait-core|ait_bsc|ait-bsc|Binary Stream Capture|StreamCaptureManager|root_log_directory|log_dir_path|file_name_pattern|/<name>/start|bsc.yaml|ait.core.bsc" .
python -m pip show ait-core
python -m pip freeze | rg -i "^ait-core=="
rg -n "ait-bsc|bsc.yaml|root_log_directory|AIT_CONFIG|ait.core.bsc" Dockerfile* docker-compose*.yml compose*.yml charts k8s systemd scripts .github .

Do not send crafted BSC start requests, point BSC at sensitive paths, append to live files, host browser-based probes, or inspect mission data during triage.

Remediation strategy

  • Upgrade every controlled ait-core dependency, lockfile, image, virtualenv build, generated dependency report, and SBOM to 2.6.1+ or 3.1.1+ on the selected release line.
  • Keep BSC log output confined to a dedicated root directory. Validate the final canonical path after joining root_log_directory, handler path, and file_name_pattern; reject absolute paths, traversal, and symlink escapes.
  • Do not expose the BSC HTTP API to untrusted networks. Bind to loopback or a controlled management interface, block browser-origin requests where practical, and put BSC behind network policy or authentication when this repository controls deployment.
  • Run ait-bsc as a least-privilege service account that can append only to dedicated log storage, not source code, mission config, credentials, shell scripts, or shared operator home directories.
  • Add safe regression checks for path confinement and service exposure. Tests should assert rejection of unsafe path components without writing outside a temporary directory.
  • Review BSC logs, handler creation history, disk usage, and writable directories if a vulnerable BSC API was reachable.

The prompt

You are remediating CVE-2026-47731 / GHSA-p462-prxw-mjx4, a NASA AMMOS
AIT-Core Binary Stream Capture path traversal that can append attacker-
controlled data to arbitrary writable files. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades ait-core, confines BSC file
  paths, hardens BSC service exposure, adds safe regression checks, refreshes
  generated artifacts, and documents operator review, or
- TRIAGE.md if this repository does not own an affected AIT-Core BSC runtime or
  cannot safely patch the deployment.

## Rules

- Scope only CVE-2026-47731 / GHSA-p462-prxw-mjx4 and directly related BSC
  path-confinement and service-exposure controls.
- Treat mission telemetry, packet captures, configuration, credentials, source
  files, generated artifacts, service logs, operator home directories, and
  environment variables as sensitive.
- Do not send exploit-like `/<name>/start` requests, write outside temporary
  test directories, target real BSC services, host browser-based probes, or
  modify live mission/lab files during validation.
- Do not delete telemetry, disable logging, remove BSC coverage, or weaken
  deployment controls just to silence the alert.
- Do not auto-merge.

## Steps

1. Inventory every `ait-core` reference in Python manifests, lockfiles,
   constraints, Dockerfiles, virtualenv build scripts, lab images, mission
   service definitions, systemd units, Compose files, Helm/Kubernetes
   manifests, generated dependency reports, SBOMs, and runbooks.
2. Determine every resolved `ait-core` version. A target is vulnerable if it
   resolves to `<2.6.1` or exactly `3.1.0`.
3. Search for BSC usage: `ait-bsc`, `bsc.yaml`, `root_log_directory`,
   `StreamCaptureManager`, handler creation endpoints, service ports, reverse
   proxies, port forwarding, VPN or lab-network exposure, and browser-accessed
   operator workstations.
4. If the repository does not deploy or configure AIT-Core BSC, stop with
   `TRIAGE.md` listing checked files, owning platform or mission team if known,
   and the required fixed versions.
5. Upgrade affected `ait-core` references to `2.6.1+` or `3.1.1+` on the
   selected release line. Refresh locks, constraints, images, generated
   dependency reports, SBOMs, and docs.
6. Where this repository owns BSC code, forks, plugins, or wrappers, enforce
   final-path confinement:
   - derive the configured root log directory once;
   - reject client-supplied absolute paths;
   - join path components in a temporary-safe way;
   - canonicalize with realpath or equivalent after all substitutions;
   - reject final paths outside the root;
   - protect against symlink escapes before opening files;
   - create directories only under the configured root.
7. Harden deployment:
   - bind BSC to loopback or a controlled management interface;
   - remove accidental public, tunnel, or forwarded-port exposure;
   - add authentication or network policy if BSC must be remote;
   - run `ait-bsc` as a least-privilege account with write access only to
     dedicated log storage;
   - avoid mounting source trees, credentials, or operator home directories
     writable by the BSC process.
8. Add safe regression checks:
   - affected `ait-core` versions fail dependency policy;
   - path traversal, absolute paths, formatted filename escapes, and symlink
     escapes are rejected in a temporary directory;
   - BSC config uses a dedicated root log directory;
   - deployment does not expose unauthenticated BSC ports by default;
   - logs and test output do not print mission data, packet contents, secrets,
     or sensitive paths beyond sanitized examples.
9. Add a PR body section named `CVE-2026-47731 operator actions` that states:
   - `ait-core` versions before and after;
   - where BSC runs;
   - whether BSC was reachable from any non-loopback network, forwarded port,
     VPN, tunnel, or browser-accessible localhost context;
   - which directories the BSC process could write before and after;
   - which logs, handler history, disk usage, and writable directories need
     review for unexpected appends or corruption;
   - which validation commands passed.
10. Run available validation: package install, lockfile integrity, unit tests,
    path-confinement tests, config lint, service manifest lint, image build,
    SBOM refresh, dependency/security scans, and non-secret smoke checks.
11. Use PR title:
    `fix(sec): remediate CVE-2026-47731 in AIT-Core BSC`.

## Stop conditions

- No affected AIT-Core BSC runtime, dependency, image, service, or config is
  controlled by this repository.
- BSC is owned by another mission, lab, platform, or vendor team; name the
  owner and required fixed version in `TRIAGE.md`.
- A fixed AIT-Core version cannot be consumed without a broader mission/lab
  migration or maintenance window.
- Verification would require exploit-like BSC requests, writes outside a temp
  directory, live service access, packet capture disclosure, or secret access.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades ait-core, constrains BSC file paths with canonical containment checks, hardens API exposure, adds traversal regression tests, and documents cleanup/operator actions.
  • Or a TRIAGE.md file that lists inspected dependencies/config, owner, observed version, BSC exposure boundary, writable paths, required fix, and residual risk.
  • The output must include exact validation commands and must not append to real mission files, overwrite production configs/scripts, expose telemetry data, or probe unauthenticated production BSC endpoints.

Verification - what the reviewer looks for

  • No controlled dependency, lockfile, image, SBOM, or generated report resolves to ait-core <2.6.1 or ait-core 3.1.0.
  • BSC log paths are canonicalized after join/substitution and confined under the configured root directory.
  • BSC service exposure is loopback or explicitly controlled; unauthenticated public or browser-reachable defaults are removed.
  • The BSC process has least-privilege write access limited to dedicated log storage.
  • Regression tests prove rejection of unsafe paths without writing outside a temporary directory.

Watch for

  • Updating Python requirements while lab images, constraints, or virtualenv bootstrap scripts still install the affected package.
  • Validating with live BSC endpoints or real packet-capture paths.
  • Checking only path while log_dir_path or file_name_pattern can still escape the root.
  • Canonicalizing before substitutions instead of after the final path is built.
  • Running ait-bsc with write access to source code, mission config, operator home directories, or shared credentials.

References