Sunday's oss-security carried three things a community infrastructure operator actually runs: the data-sync backbone, the HTTPS transport everything clones through, and the patch utility that applies every fix bundle. All three disclosures are documented here the way they arrived — from the primary posts — because none of the three has a vendor blog and two of them are easy to misread from scanning headlines.

git-annex: the repo you clone decides what talks to what

Joey Hess disclosed CVE-2026-112818 himself — git-annex's own author, with the fix released the same day as 10.20261026 — and the advisory page describes a private-data exfiltration that starts with something most users consider harmless: cloning a git-annex repository someone else provides.

The attack needs one precondition and some patience. The precondition: the attacker controls one of the victim's remotes — most easily by being the person who provided a repository the victim clones. The patience: waiting for the victim to run a command like git-annex sync --content. What happens in between is the part that makes this a trust-boundary story rather than a normal bug.

git-annex repositories do not only carry files. The git-annex branch is configuration, and a newly initialized clone applies it — including autoenabled special remotes, which are remotes marked to be enabled without a user decision at clone time. In the simplest of the three forms Hess documents, the attacker's repository references annexed files the attacker knows exist in the victim's private git-annex repository — which the attacker knows about because the victim published the git repository (the tree of pointers) while keeping the annexed content itself private, a perfectly common split. Clone, initialization, autoenable: the victim's copy now contains a special remote pointing at the victim's own private repository, configured by the attacker. The victim runs git-annex sync --content; git-annex retrieves the victim's private files through that remote and sends them to the attacker. The user's own sync command is the exfiltration routine; nothing prompts, because to git-annex this is an ordinary remote doing ordinary work.

The second variant drops the autoenable requirement. The attacker provides a special remote — an S3 bucket is the advisory's example — which the victim clones and enables manually, in good faith, as their content backend. The attacker then updates the remote's configuration — a change that arrives via the git-annex branch and takes effect on the victim's next sync — retargeting the victim's remote definition at the victim's own private S3 bucket. Same command, same result: contents of the victim's private bucket flow to the attacker's endpoint, from a config the victim approved once for a different destination.

The third variant is the one to internalize about how little is needed: it requires only that the attacker knows the location of the victim's private git repository. The attacker's repo autoenables a git remote pointing there; on the victim's first sync, git-annex contacts the victim's private repository, leaking the set of annex keys it uses; the attacker adds those keys to their tree; on the second sync, the victim's private files are retrieved and sent to the attacker. Two runs of a command users type reflexively, against a remote the user never decided to trust.

For this site's audience the tool matters as much as the bug. git-annex is the canonical free-software answer to "keep a shared archive across several independent locations we control" — offsite copies on members' own boxes, remotes in different buildings, the data-repatriation pattern where the point is that no platform operator is in the middle. That is exactly the pattern community procurement recommendations keep endorsing, and its whole security model rests on every remote being one the group configured on purpose. This CVE says the configuration transport of the trust-critical tool was itself a trust boundary nobody drew.

The fix makes the boundary explicit and, usefully, default-on:

  • git-annex enableremote displays the configuration and requires explicit verification before a special remote can be used.
  • An autoenabled special remote can still be used (reads still work), but git-annex refuses to send annexed files to any remote until the user verifies that the autoenabled remote's configuration is safe — the exfiltration path, which is a send, is gated on a decision that now must be made.
  • git-annex installs a git pre-push hook that blocks pushes while an unverified special remote exists, so the gate holds against a user running plain git push and not thinking about remotes at all.
  • Changes to an already-enabled special remote's configuration that arrive via the git-annex branch do not take effect until verified — closing variant two, where the retarget rides in silently as branch data.

Nothing already-trusted breaks: existing, user-approved remotes keep working after the upgrade. The one action this advisory effectively asks of every existing user is in Hess's own words — if a special remote could have been configured by a third party, run git-annex verifyremote on it. For organizations that run git-annex as the shared-archive backbone, that is a five-minute audit: list remotes, run verifyremote against each, read what comes back, and treat any remote whose configuration you can't narrate as compromised until proven otherwise. Also brief the team that sync --content behavior and pushes will change on upgraded clients while unverified remotes exist — that is the fix working, not breakage to work around.

Packaging status, verified against the Debian security tracker tonight: CVE-2026-112818 is fixed only in sid (10.20261026-1); bookworm (10.20230126), trixie, and the forky base are still marked vulnerable. Hess published backport branches in the upstream git repository for exactly the version series in use — CVE-2026-112818-patch-10.20250416 (trixie's version), -patch-10.20251029, and -patch-10.20261006 (forky's) — so the maintainer's path to a stable upload is short. Until a distro build reaches your suite, building from the signed upstream source or pinning the patch branch is the honest interim; a data-sovereignty stack running an unpatched exfiltration vector is worse than an inconvenience, because the payload is the sovereign data.

Brotli and git: the decoder nobody chose

The second Sunday item is an exposure note, not a new CVE, and its one-sentence form is: git-remote-https is vulnerable to CVE-2026-111497 too, if your libcurl was built with brotli support — which, on most distro builds, it is.

CVE-2026-111497 has been trickling through consumers since the Node.js security release that carried it: the underlying flaw is in Google's brotli library itself (the library advisory, fixed as brotli v1.2.1) — an out-of-bounds write in the decoder, rated as permitting remote code execution, reached by handing the decoder a malicious compressed stream. Node.js 26/24/22 fixed it via a bundled copy; patchtheplanet.org/brotli tracks the consumer matrix (Bun, Envoy via its own advisory, Istio, the PyPI brotli packages under the "node2shell" headline) and is the honest place to check "am I a consumer" rather than guessing from memory.

Harry Sintonen — the researcher whose name is on several of libcurl's worst compression bugs — added the item people scanning consumer lists would otherwise miss: git's HTTPS remote helper asks the server for compressed transfer via libcurl's CURLOPT_ACCEPT_ENCODING option — but sets it through CURLOPT_ENCODING, the deprecated alias (git's http.c at the commit he pinned). A hostile HTTPS origin you clone, fetch, or pull from can then hand git a brotli-encoded response, and the decode — and therefore the out-of-bounds write — happens in libbrotli inside your git process before git validates anything about the bytes as git data. Nothing in a clone is executed, true; but this is the same shape the site keeps returning to, where the document is the payload and the upload surface carries the decoder, and the decoder is the only component running on attacker-controlled bytes.

The maintenance lesson is quietly the most reusable part: the vulnerable call site uses an option name that scanners grep for less often. Sintonen's own operational note: when you scan applications linked against libcurl for this class, check both option names, because "a fair bit of older code still uses" the alias. A deprecation is a compatibility promise, not an audit of downstream users.

Debian status matters here more than usual because the fixed and vulnerable states split by suite in the opposite direction from the other two tools: libbrotli1 is already fixed in bookworm-security (1.0.9-2+deb12u1) and trixie-security (1.1.0-2+deb13u1), but remains vulnerable in the forky base series pending the 1.2.0-4.1 build that is currently only in sid. Forky is the base Devuan Freia tracks, which is where a large share of self-hosted community stacks live today — so on the freshest Debian lineage, the decoder in your git transport is the one still waiting for its security update. Bundled copies lag harder: nodejs remains marked vulnerable across the stable suites at the tracker tonight, which is exactly the pattern the patchtheplanet matrix exists to disambiguate — the library is one fix; every consumer's pinned copy is its own countdown.

Practical posture for an operator: update libbrotli1 wherever the suite has the fix; check whether your git transport is even exposed (git config --get http.acceptEncoding and the distro's libcurl build config is the honest inventory); and normalize the real exposure question — which HTTPS origins do you clone from without an adversarial trust story? Cloning from your forge and distro mirrors is not the risk model; cloning a stranger's repo over HTTPS while its server serves bytes it chose is, and that risk just dropped sharply with the library fix where shipped.

GNU patch 2.8.1: the path check reverse-apply forgot

The third Sunday item is the smallest and the oldest lesson. GNU patch 2.8.1 was released to fix one flaw, CVE-2026-115207: when reverse-applying a patch that deletes a file, patch recreated that file without checking whether the pathname is safe. An absolute path in a patch header becomes a file creation at that absolute path, with the permissions of the user running patch — "out-of-tree files," as the release announcement puts it, in the most literal reading of the phrase.

The trigger asymmetry is what makes it worth writing down rather than shrugging at. Ordinary patch application is the famously hardened path — apply-side pathname checks have survived decades of scrutiny. Reverse-apply (patch -R) is the mode used in packaging workflows, kernel backport queues, and "undo this change" scripts — precisely the automated contexts where the input is a file that arrived from a mirror, a mailing list thread, or another maintainer's bundle, and where a user may be running patch inside a script with more permissions than they'd spend interactively. This site's running theme applies again at the smallest possible scale: the patch file is a document, and the parser decides what the document does.

Status: the new source ships with sha256 checksums and a signed release (ftp.gnu.org/gnu/patch); the Debian tracker marks the fix as landed in forky and sid (2.8.1-1) while bookworm (2.7.6) and trixie (2.8) remain vulnerable. One precision point for anyone drafting their homelab's patch policy: GNU patch and git apply are separate programs with separate code and separate histories — patching your git hygiene does not patch this tool — but both read the same genre of untrusted input, and the rule generalizes: a patch file fetched from anywhere you didn't author gets read through a validator that treats headers as untrusted, or it gets applied in a filesystem cage.

Three small surfaces, one audit session

What links the three Sunday disclosures is not severity ranking but where the trust decision actually lives. In git-annex, it lives in a config file that travels inside the repository and acts on clone. In git-over-brotli, it lives in an encoding negotiation your tool set by a name nobody audits anymore. In GNU patch, it lives in a header's pathname field on the code path every reviewer skips because the apply path is the famous one. None of these required a zero-day, a fuzzer, or a bounty; each required someone to re-ask "what do I trust to configure/decode/create here?" on a surface that had stopped being asked.

The audit, for the stack this site assumes its readers run, is short enough to do before the next sync runs:

git-annex version # and upgrade to >= 10.20261026 git-annex verifyremote # per remote a third party could have touched apt policy libbrotli1 git-annex patch # suite-level fix status, per package dpkg -l | grep -E "libbrotli|patch|git-annex" # what is actually installed

Then the two policies that outlast any CVE: a cloned-from-elsewhere annex repository is quarantined (no sync of content onto trusted remotes) until its remote list is narrated and verified; and patch files, compressed streams, and encoding headers from untrusted origins are decoded by the freshest library build the suite offers, not the one the tool was linked against when you built the box. None of Sunday's three fixes adds a feature. They add back the checks that a trust model assumed were always there — which is the definition of work worth doing the week it ships, at three in the morning, while the syncs and the clones and the patch queues run their own schedules.