Repository navigation
fix: land TechVault on env-packs 6.2.1 (compat, detection, CVE gates, docs) - #1248
Merged
Merged
Conversation
env-packs 6.2.1 changed the TechVault pack set-digest and made the authored Suricata rule 303020 chain off the built-in Wazuh rule 86601 (env-packs #418). Two lilrae-side changes are needed so 6.2.1 boots and the web-attack detection works. - Pin the aptl_techvault providers (capture, serving, startup, planning, verification) to the 6.2.1 pack set-digests: techvault sha256:1229f94f... and techvault-participant-study sha256:03baae36... - Move the raes-env-packs requirement and the hash-locked requirement exports to 6.2.1; regenerate uv.lock. - Stop excluding the built-in Suricata ruleset 0475-suricata_rules.xml in the Wazuh manager config. Rule 303020 chains off built-in rule 86601, so the built-in base must load for a network web attack to surface as 303020. - Update the pack-digest assertions in the affected tests. Validated on a clean GCE VM: base techvault boots to ready with 28 healthy containers, and the SQLi -> Suricata -> Wazuh 303020 native evidence passes.
Three contract tests still asserted version("raes-env-packs") == "6.2.0"; the pack now resolves 6.2.1. Update the assertions and two version-specific source comments.
proxy-addr 2.0.7 has CRITICAL CVE-2026-90711 (IP spoofing via IPv4-mapped IPv6 trust subnet), pulled transitively through express in all nine MCP packages. Bump the resolved version to 2.0.8 in each package lockfile. npm audit (high+) is clean afterward. This clears the dependency-audit and Trivy critical that currently fails every CI run, including on dev.
The node:22-trixie-slim base bundles yarn and corepack. This substrate uses npm only (and already replaces npm with 11.x). Their bundled dependencies (e.g. postcss-selector-parser) fail the Trivy image gate for tooling we never run. Remove them in the npm-replacement layer.
Document how LilRAE consumes a scenario as two installed parts: the content pack (resolved from raes-env-packs by identity) and its adapter (the aptl.* entry points keyed by the pack id). Cover selecting the pack in aptl.json, verifying with aptl lab scenarios, and troubleshooting unknown-id, missing-pack, and missing-adapter errors. Add it to the Lab Guide nav.
Add the three changelog fragments and the install-scenario-packs guide to tracked-file-inventory.tsv, and list the guide in the scenario-pack terminology inventory, so the rename-boundary and terminology contract tests stay green.
Brad-Edwards
changed the title
This was referenced Oct 6, 2026
The proxy-addr 2.0.8 bump changed the mcp-red/indexer/wazuh package-lock.json bytes. Update their pinned sha256 in asset-lock.json, and the asset-lock sha256 in profile.json, so the participant-profile reference-digest chain verifies.
The Trivy image gate flagged postcss-selector-parser 7.1.4 (CVE-2026-104844, fixed 7.1.6) at usr/local/lib/node_modules/npm/node_modules/. It is bundled in npm itself; no npm release (through 12.2.0) has adopted 7.1.6, so a version bump cannot fix it. npm's install/ci path does not use it, so remove it in the npm-replacement layer. Also keep dropping the unused yarn/corepack tooling. The removal precedes the MCP npm ci build, which would fail if npm needed it.
The node22 base image failed the Trivy image scan because npm bundles postcss-selector-parser 7.1.4, which carries CVE-2026-104844 (fixed in 7.1.6). The earlier attempt to delete the bundled module broke `npm ci`, because npm requires the module at install time. Upgrade the bundled copy in place to 7.1.6. The fixed release keeps the same runtime dependencies (cssesc, util-deprecate), which npm already bundles. Verify the download against its published sha512 integrity and assert the installed version.
Brad-Edwards
added a commit
that referenced
this pull request
Oct 11, 2026
…ed pebble (#1270) * fix(deps): bump @modelcontextprotocol/sdk to 1.31.0 in the MCP packages The MCP TypeScript SDK from 1.12.0 up to 1.31.0 (exclusive) has GHSA-6qxp-vccf-f47h / CVE-2026-104850 (high): its OAuth client could send stored credentials to an authorization server chosen by the MCP server. All nine MCP packages locked 1.26.0 or 1.29.0, which fails `npm audit --omit=dev --audit-level=high` in the Dependency vulnerability scan and the Trivy filesystem scan on dev. Raise each package's range to ^1.31.0 and lock 1.31.0, the first fixed release. The fix only touches the SDK's OAuth code (client auth and the server proxy auth provider), which these servers do not use: they use the low-level Server, StdioServerTransport and the tools/list and tools/call request schemas, so no code change is needed. One change between 1.26.0 and 1.31.0 reaches that path: since 1.30.0 a single stdio message over 10 MB closes the transport. The new mcp-red, mcp-indexer and mcp-wazuh lockfile bytes change their pinned sha256 in the guided-purple asset lock, which changes the asset-lock sha256 in profile.json. Update both so the participant-profile digest chain verifies. * fix(deps): bump dompurify to 3.4.16 in web DOMPurify up to 3.4.15 has GHSA-p98j-92pf-mc4p and GHSA-6688-9rhm-gjv2 (both low, fixed in 3.4.16). npm audit reports them in web on dev; they sit below --audit-level=high, so they do not fail the Dependency vulnerability scan. Both need the IN_PLACE option, which web/src/lib/markdown.ts does not use (it calls DOMPurify.sanitize on a string). Raise the range to ^3.4.16 and lock 3.4.16 so the audit reports no web finding at any level. * fix(containers): apply published Alpine fixes in the alpine-based images The Trivy image gate fails the appliance-egress-proxy, network-boundary-helper and web images on zlib CVE-2026-85091 (medium): they ship zlib 1.3.2-r0 and the fix is 1.3.2-r1. No newer base image carries it yet: alpine:3.24 (3.24.2, sha256:294b683c) and alpine:3.23 (3.23.6), which caddy:2-alpine builds on, were last pushed 2026-09-18, while zlib 1.3.2-r1 reached the v3.24 and v3.23 main repositories on 2026-10-06. Run `apk upgrade --no-cache` before adding the pinned packages, the same step operator-access-proxy already takes (#1203), so each image takes the published Alpine fixes its pinned base predates. * fix(containers): remove the unused pebble binary from the Ubuntu 26.04 images The ubuntu:26.04 rootfs ships /usr/bin/pebble (canonical/pebble v1.32.3-0.20260908071357-f1688182910f, built with go1.26.7). Trivy reports Go stdlib CVE-2026-78667 and CVE-2026-97031 (high) and CVE-2026-94439 and CVE-2026-97032 (medium) in it, fixed in Go 1.26.9 and 1.27.2 (released 2026-10-08). No dpkg package owns the file, so `apt-get upgrade` cannot replace it, and the newest ubuntu:26.04 image (resolute-20260927) is the digest already pinned. This fails the base-ubuntu, reverse, generic-samba-ad-base and generic-samba-ad-wazuh-agent-base image scans. Nothing runs pebble. base-ubuntu and reverse boot systemd (/usr/sbin/init), generic-samba-ad-base runs tini and then samba, and generic-samba-ad-wazuh-agent-base builds on it. No file in the repository or in the installed raes and raes-env-packs 6.2.1 packages refers to it. Delete it in each image's existing apt layer, as #1248 deleted the unused yarn and corepack from the node22 base. generic-samba-ad-wazuh-agent-base inherits the removal from its parent. * docs(containers): say the Alpine upgrade step applies every pending update The `apk upgrade --no-cache` step from fcd5d74 applies every pending Alpine update, not only zlib. In run 38035974153 it upgraded libcrypto3 and libssl3 (3.5.8-r0 to 3.5.9-r0) and zlib (1.3.2-r0 to 1.3.2-r1) in appliance-egress-proxy, network-boundary-helper and web, but the comments named only zlib. Say that the step takes every update the pinned base predates, list the current ones, and keep zlib's CVE-2026-85091 as the reason the scan needs it. * fix(web): build Caddy with patched Go and x/net The upstream caddy:2-alpine binary uses Go 1.26.8 and golang.org/x/net 0.59.0. Trivy reports CVE-2026-78667 and CVE-2026-78669 for them. No newer upstream image has the fixes. - Build Caddy v2.11.7 from source with Go 1.26.9 and x/net 0.60.0. - Replace the upstream binary in the runtime stage. - Add a gomod Dependabot entry for the new module. - Add the new files to the tracked-file ledger. --------- Co-authored-by: Brad Edwards <j.bradley.edwards@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make TechVault run on
raes-env-packs6.2.1 (which carries the Suricata rule fix, env-packs #418), fix the detection end to end, clear the dependency/image CVE gates the 6.2.1 image rebuild surfaced, and document the pack+adapter install path. This consolidates the techvault fix, the repo-wide security fixes, and the docs into one green PR (previously split across #1249 and #1250, now closed).TechVault 6.2.1 compatibility
aptl_techvaultproviders (capture, serving, startup, planning, verification) to the 6.2.1 pack set-digests (techvault1229f94f…,techvault-participant-study03baae36…). The 6.2.0 pins rejected admission withScenarioCaptureProviderError: provider-missing.raes-env-packsto 6.2.1; regenerateuv.lockand the hash-lockedrequirements/*.txt.0475-suricata_rules.xmlin the Wazuh manager config. Rule303020chains off built-in rule86601, so the built-in base must load for a web attack to surface as303020.Repo-wide security (image/dependency CVE gates)
proxy-addr→ 2.0.8 in all nine MCP lockfiles (CVE-2026-90711, CRITICAL, transitive via express).yarnandcorepackfrom thegeneric-systemd-node22-baseimage. The base bundles them; their deps (e.g.postcss-selector-parser) failed the Trivy image gate for tooling this substrate never runs (it uses npm only).Docs
env-packsource, verify/troubleshoot); register it in the nav, the Review APTL readiness for the LilRAE personal backend migration #962 tracked-file ledger, and the scenario-pack terminology inventory.Validation
On a clean GCE VM (plain Ubuntu, Docker-direct), base
techvaulton 6.2.1:aptl lab startreaches "Lab is ready", exit 0; 28/28 containers healthy; thesuricata-wazuh-sqlinative evidence passes;wazuh-logtestfires rule303020on a real eve alert. The golden imageshifter-techvault-20261006was baked from this.