AiSOC v22.1.0 — five advisories patched to a named version, and three silent data-loss defects closed

[beenuar]

AiSOC v22.1.0 is out. It is the follow-through release: the five advisories published against v22.0.0 are patched and now name a real version you can upgrade to, and a long-standing data-loss defect in Duo polling is closed.

34 defects have been addressed across this release and the two before it — 16 here, 15 in v22.0.0 and 3 in v21.0.0, counting distinct product and CI defects named in each release's Fixed and Security sections.

Upgrade, and what you get

docker compose pull && docker compose up -d

All 16 first-party images are published at v22.1.0 for linux/amd64 and linux/arm64, and :latest now points at this release. The Helm chart publishes as 7.16.0.

The security work

Five advisories, every one of them reproduced before it was fixed and each now naming 22.1.0 as the patched version rather than a bare commit — so a reader has somewhere to upgrade to:

Advisory	Severity	What it closes
GHSA-m57m-6p4p-cq6p	Critical 9.1	A deployed demo signed session tokens with the default SECRET_KEY published in this repository
GHSA-32q9-5fvr-8wcx	High 7.7	Connector egress: three construction sites bypassed the guard, and bare-hostname fields were never read as destinations
GHSA-6465-rp4f-ppj6	High 7.4	A password reset left existing sessions alive, and one TOTP code could open more than one session
GHSA-57rw-w33m-cp5v	Medium 5.9	Committed .env backups remain in history, and the namespace was not denied
GHSA-4hxg-m5rw-gw3x	Medium 5.9	Agent tool arguments were not checked against the tool's own schema

The critical one is worth reading even if you do not run the Railway recipe, because the shape generalises: enforce_secure_defaults refuses an insecure default at boot, but only when ENVIRONMENT=production, and demo turned out to be the one member of the dev-environment set that denotes a deployed environment. A deployed demo now substitutes a per-process key and states the cost at boot rather than letting you find it. The fix covers the whole set of published defaults, not only the spelling the report named.

Two actions worth taking. If you deployed from a clone that reused one of the committed .env backups, rotate SECRET_KEY, the Fernet AISOC_CREDENTIAL_KEY and your Postgres, Redis and ClickHouse passwords — no vendor credential was in those files, so the exposure is bounded to a reused deployment file. And if you poll CrowdStrike, grant your API client Alerts: Read.

Three defects that were costing you data, silently

Each of these had no error, no gap in the logs, and nothing on a dashboard to suggest anything was wrong — which is what makes them worth naming.

Duo was losing roughly 40% of authentication events on every deployment. The poll window ran [now - interval, now] with no checkpoint anywhere in the connector, while Duo serves an authentication no sooner than two minutes after it happens and answers a more recent range as empty. So the last 120 seconds of every window was read once, while it was still empty, and the next poll's window began past it. At the default 300-second interval that is 120 seconds in every 300, lost quietly. The window now ends where Duo's logs actually become available, so consecutive polls stay contiguous. Thank you to @rudycelekli, who found and fixed this.

CrowdStrike's investigation read was answering "no detections" to a 404. CrowdStrike decommissioned the /detects/* endpoints in September 2025. The connector raised the 404 visibly, which is how it got reported — but the actions-side read logged a warning and returned an empty list, so the action reported SUCCEEDED with count: 0 and an investigation read that as the EDR having nothing on the host. That is the strongest exonerating evidence there is, produced by a call that never reached the vendor. Both callers now use the Alerts API, and a failed read raises instead of returning empty.

cloudflare_zt WAF mode polled a route that does not exist. Measured against the live API, the path it used answers 404 for any zone, with or without a token, while an unrelated zone route answers an auth refusal — so the probe discriminates and the absence is a measurement rather than a guess. WAF mode could never have returned an event on any deployment. It now queries Cloudflare's GraphQL analytics dataset, which changes the token scope it needs to Zone: Analytics: Read. Access mode was never affected.

Numbers that now say what they measure

Five surfaces published an ATT&CK figure on one deployment at one moment — 392/392, 1/201, 22.22%, 494 and 14 — each measuring something different and none saying which, so any two of them contradicted each other. Each now names its measurement. The operations card also claimed "100% of known techniques have an enabled rule", which was false: the endpoint returns one row per technique your rules already reference, so a technique with no rule never appears at all.

In the same spirit, a console strip reported "Backlog 7" from a number that was a correlation outcome rather than a queue depth, and two landing surfaces rendered a hardcoded connector count of 26 against a registry of 91. The gate that owns that figure had only ever reconciled markdown prose; it now reads components too.

Alongside that, the event lake no longer runs two flushes at once, a cached triage verdict is actually persisted (and carries an explicit note that a cache hit is not authorization to close an alert), a tenant can be created on a brand-new database without naming every column the schema fills in, and the sandbox demo completes on a Windows console with a legacy encoding instead of stopping at a traceback.

Also in this release

The gate that proves published images match the tree compared VERSION, which does not change after a release — so every post-release commit was invisible to it. It now compares the commit for tags that move, which is what catches a :latest that quietly went stale.

Channels

Neither stable channel moves. Image stable is on v19.0.0 and chart stable on 7.8.0, so promoting either here would carry it across three application majors. Both guards held automatically and said so. If you pull by stable you are unaffected by this release; if you want the fixes, pin v22.1.0 or track :latest.

Thanks

To @rudycelekli for the Duo fix, and to everyone who filed an issue, reported a vulnerability privately, or pushed back on a number that did not look right. Several of the entries above started as someone saying "that figure cannot be correct."

Full detail, every entry with the reasoning behind it, is in the release notes and CHANGELOG.md. Docs are at https://beenuar.github.io/AiSOC/.

[beenuar]

The stable channel now points at v22.1.0

Until today ghcr.io/beenuar/aisoc-*:stable served v19.0.0 and the Helm chart channel served 7.8.0. Because every advisory in this release declares an affected range of <= 22.0.0, anything pinned to stable was inside that range — including for the critical-severity issue. The channel has now been moved deliberately, and the registry confirms all 16 images and the chart serve v22.1.0 / chart 7.16.0.

The automatic guard had correctly refused to move it on its own, because promoting across a major is an upgrade decision rather than a side effect of a patch release.

If you were pinned to stable, you are crossing three majors

There are exactly three breaking changes between v19.0.0 and v22.1.0, one per major. All three are small, and each is described in full in CHANGELOG.md.

Release	Breaking change
v20.0.0	POST /api/v1/cases/{case_id}/comments no longer accepts is_system in the request body.
v21.0.0	Correlation grouping narrows when identifiers are missing, so alerts that previously collapsed together may now stay separate. Published alert-reduction figures were corrected downward as a result.
v22.0.0	GET /posture/summary returns null instead of 0 for its eight counts when nothing has collected. Generated SDK types change from int to int | None. The old type was the defect: an empty table and a clean estate are different facts and 0 could not express both.

The v21.0.0 and v22.0.0 entries are both corrections where a number that looked confident was not measured. Neither requires action unless you consume those fields programmatically.

If you prefer not to track a channel

Pin an explicit version tag, for example ghcr.io/beenuar/aisoc-core-api:v22.1.0. Version tags are immutable; stable and latest move.

[beenuar]

Follow-up: v22.2.0 is out.

Unrelated to the advisories above — it closes a collection-integrity class: eight connectors were losing data on every deployment, silently, and Google Workspace OAuth token events had never once been ingested anywhere. If you run Entra, Defender, Sentinel, Google Workspace, Google Cloud Audit, Security Command Center or Wiz, it is worth reading.

The five advisories in this thread are unchanged and still name 22.1.0 as patched, which is accurate — those fixes shipped here.