Skip to content

Runtime package and build execution-boundary batch (GHSA)

Signal: GitHub Security Advisories surfaced a 2026-05-04 batch where package parsing, build inputs, archive/crawl configuration, Git options, and radio/media app parameters crossed from data into code or filesystem authority.

Advisories in this batch

Why this is durable

These are different surfaces with the same failure mode: trusted runtimes accepted attacker-shaped strings, files, symlinks, package metadata, or configuration and later interpreted them with stronger authority.

Immediate triage

  1. Patch protobufjs, GitPython, apko, and AzuraCast to fixed versions; isolate ArchiveBox AddView exposure until an upstream fix or compensating gate exists.
  2. Rebuild images produced by affected apko versions where repository compromise, untrusted mirrors, or writable build contexts were possible.
  3. Treat ArchiveBox crawl submissions, AzuraCast media uploads, remote relay passwords, and GitPython multi-option inputs as suspicious if exposed to non-admin users.
  4. Rotate secrets on hosts where package/build/archive inputs could have reached command execution.

Hunt ideas

  • Search CI logs for GitPython calls with user-controlled multi_options, embedded spaces, shell metacharacters, or split-sensitive quoting.
  • Review apko build contexts for symlinks, hard links, unexpected device files, or package downloads whose digest only matched repository metadata.
  • Inspect ArchiveBox access logs for AddView requests carrying config override keys, downloader settings, or shell-like payloads.
  • Review AzuraCast station logs for unusual media upload paths, ../, encoded separators, and Liquidsoap syntax in relay password fields.

Durable controls

  • Split and normalize command options before validation, then pass them as argv arrays rather than shell strings.
  • Verify downloaded packages against immutable digest metadata and pin repository trust roots.
  • Open build-root files with no-follow semantics and enforce canonical path containment at every file operation.
  • Keep per-request configuration overrides on a strict allowlist with types, ranges, and no command/runtime keys.

July 7 ArchiveBox AddView config-to-plugin follow-up

The July 7 updated-feed refresh for GHSA-3h23-7824-pj8r / CVE-2026-42601 adds enough implementation detail to make the ArchiveBox item a replayable operator workflow. The crossed boundary is:

untrusted URL submission -> per-job config merge -> process environment -> archiver CLI arguments / binary selector

Prioritize ArchiveBox targets where /add/ is reachable by unauthenticated users, bookmarklets, shared teams, or semi-trusted contributors; PUBLIC_ADD_VIEW=True is enabled; or archive plugins accept extra arguments, post-processing hooks, browser flags, downloader binaries, or external converters.

Safe validation boundaries:

  • Config-key acceptance: submit an owned benign URL to a disposable ArchiveBox lab, then repeat with harmless config keys. Positive evidence is a low-trust request-controlled key appearing in crawl config or plugin environment when it should be server-owned. Negative controls are patched allowlist rejection, type validation, and logs showing only server-derived config.
  • Tool-argument / binary-selector canary: only when explicitly authorized in a lab, use an inert wrapper or fixed temp marker to prove request-derived config can influence plugin arguments or selected binaries. Prefer argument-echo wrappers over real command execution.

Do not publish command payloads, reverse shells, environment dumps, archive database paths, browser profile paths, cookies, credentials, or production filesystem paths. Report this as URL submission config to archive-plugin runtime control, with route, auth state, config key, merge point, plugin name, job ID, and patched behavior.

Operator lesson

If an input can change how a tool builds, crawls, parses, uploads, or shells out, it is not metadata. Treat it as code until proven otherwise.