Twelve days ago this site told you your git forge is now on the same patch cadence as your identity provider. This week made the point concrete from the other direction: both layers shipped major versions in the same five days — Gitea 28.0.0 on September 30, Keycloak 26.8.0 on October 1. Neither is a patch-morning story. Both are configuration-morning stories, and the configuration is the part that breaks in production, not the version number.

Keycloak 26.8: agents get their own identity, and your server room gets simpler

The release's headline list is long — verifiable credentials, SCIM, multi-cluster — but three items change how the community stacks this site writes for get operated.

Token exchange delegation: the act claim (preview)

Keycloak 26.8.0 introduces delegation for token exchange, designed for AI agents and automation: a user consents to a client through a delegation:client:<client-id> scope, and the resulting token carries an act claim naming the actor per RFC 8693. Subject stays the user; actor identifies the agent. Delegation authorization is controlled exclusively through Fine-Grained Admin Permissions V2 (delegate, delegate-members). The design point is explicit in the release notes: a leaked delegation token does not grant Admin API access, and standard token exchange rejects subject tokens already carrying delegation claims, closing a bypass.

Why this matters: most community deployments running automation today give the bot a service account or the admin's own token, and their logs cannot tell the two apart. The audit question — who did this, the volunteer or the script acting for the volunteer? — currently has a one-name answer. The act claim fixes it at the protocol level instead of in a log-parsing script. It is preview status, not supported, so stage it in a test realm before wiring production agents through it. Also in it: impersonation events now record the impersonator in tokens and lifecycle events — the act claim on impersonation is always present and cannot be disabled, which is the exact control surface the impersonation-role CVE made necessary.

Stateless mode and secret rotation: supported

Two features this site flagged when they were preview moved to supported:

  • Multi-cluster v2 / stateless mode — session data moves into the database, no external Infinispan cluster. That removes the single hardest component in a multi-node Keycloak deployment — the cross-site cache — and is the difference between "we could survive one node's death" and "we can't run HA at all" at community scale. The old multi-site feature is deprecated; migrate.
  • Client Secret Rotation — two concurrently active secrets per client, policy-driven, no downtime. It closes the window where an operator rotates a secret and half the apps fall on their face simultaneously.

Security fixes: the streak continues

26.8 carries five named CVE fixes (IdP mapper role escalation CVE-2026-12388, the OIDC broker marking unverified emails as verified CVE-2026-14781, a path-specific group-policy bypass CVE-2026-19608, plus dependency CVEs), and roughly sixty hardening/weakness fixes including several in the new SCIM API. It is the fourth security-carrying release on this minor line in six weeks — 35 fixes across three point releases in four weeks was the last count. The count keeps growing; the response keeps not changing: patch on schedule, not on headline.

One opt-in item deserves its own line: the secure-client-node-hostname executor closes an SSRF path in legacy adapter node registration — and it only protects you if you attach it to a client policy and configure it. A security fix that is off by default in an identity product is a config review, not an upgrade.

Gitea 28: the egress change will hurt one specific kind of operator

Gitea 28.0.0 dropped the 1. from its version numbers and shipped a feature set worth the rename: audit logging (off by default — enable [audit]RECORD_OUTPUT = database), dedicated bot accounts that cannot sign in interactively, admin impersonation with a visible banner, HTTPS deploy tokens, code-owner approval rules, and an Actions queue view.

The breaking change that matters: egress

All Git network operations — migrations, mirrors, pushes to remotes — now flow through an internal forward proxy with egress rules (PR #39426), and the default mode quietly widens what an existing allowlist permits:

  • In the default lax mode, [security] ALLOWED_HOST_LIST no longer restricts public hosts. If you had it as an exclusive allowlist, that property is gone unless you set [security] EGRESS_MODE = strict.
  • The external preset is removed. [migrations] ALLOWED_DOMAINS, BLOCKED_DOMAINS, ALLOW_LOCALNETWORKS are deprecated.
  • IP wildcards and bare * are rejected; invalid [migrations] BLOCKED_HOST_LIST entries now stop Gitea from starting.
  • Domain matching follows curl syntax (example.com includes subdomains; *.example.com is subdomains-only).

The design is right: a Git forge that mirrors arbitrary URLs is an SSRF waiting to happen, and webhooks and OAuth2 flows needed the same discipline. But the operator action is to read the egress rules before you upgrade, not after — specifically: if your instance is an open-registration or shared community forge where some user can point a mirror at an internal host, the strict-mode allowlist is the posture you already thought you had. This is the same lesson as the fork-gate post: the control you believe is on, is, in the default mode, now half-on.

The defaults changed: registration and retention

Two default-posture changes in the same release, both in the direction this site has been arguing for months:

  • Self-registration is off by default unless [service] DISABLE_REGISTRATION = false is set explicitly. That mirrors the open-registration spam problem Matrix operators just solved with automation instead of closing the door — Gitea is choosing the same side (defaults safe for new instances, existing operators decide their own posture). If your instance relies on open registration, set the flag before you upgrade or you will have a support ticket waiting.
  • Actions run history expires after 400 days by default (runs + logs + artifacts). If your community uses Actions logs as its accountability record, that is the retention policy decision to make deliberately — either accept the default, or set [actions]RUN_RETENTION_DAYS = 0 before upgrading and keep history forever.
  • Git 2.25+ is now required; old 32-bit x86 and gogit builds are gone.

Security

Gitea 28 also carries six security fixes, including repository-scoped team authorization and keeping cancelled fork-PR runs behind the Actions approval gate — the fork-gate control this site covered when 1.27.3 broke it, now reinforced at the major-release level. Details are being withheld for a week to give operators time to upgrade; upgrade, then read them.

What to actually do

For the community operator running both, the order of operations this week:

  1. Read egress config first on Gitea: does your instance have [security] EGRESS_MODE? If it relies on ALLOWED_HOST_LIST being an exclusive allowlist, set strict before upgrading.
  2. Set [service] DISABLE_REGISTRATION = false explicitly if you run open registration; set [actions]RUN_RETENTION_DAYS = 0 if Actions history is part of your community record. Both before the upgrade, not after.
  3. Upgrade Gitea to 28.0.0, then read the security fix details when published, then turn on audit logging — it shipped off-by-default, and the whole point of the feature is being able to answer "who did this" after the fact.
  4. Upgrade Keycloak to 26.8.0, particularly for public-facing deployments carrying three of the five CVEs on exposed paths.
  5. Add secure-client-node-hostname to a client policy if you use legacy adapter node registration — the fix is opt-in.
  6. Migrate off multi-site to stateless on a scheduled window, not under pressure; the feature is deprecated, not gone, but removal is coming and the migration path is better walked calmly.
  7. Consider the Keycloak delegation preview for any automation you run, in a staging realm, with FGAP V2 scoping — as a replacement for service accounts and for "we share the admin password" (yes, that is still a thing; it is the exact failure mode the impersonation-role CVE made dangerous).

The week's other item worth your attention: Ubuntu's kernel cadence

Separately: Canonical moved Ubuntu kernel security fixes to a weekly cadence starting September 28, citing AI-assisted bug-hunting volume in kernel CVEs. CVE-2026-80521 — a local kernel bug, 7.8, fixed in mainline — is still Vulnerable, work in progress on 24.04/26.04 as of this writing. Two notes for self-hosters: a weekly kernel only helps if you reboot into it; and if you run untrusted containers on Ubuntu 24.04/26.04, isolate them until the fix ships, per the elest.io guidance. Not a remote threat; not a panic item. Most community stacks are unaffected — but if you run Ubuntu hosts and you have been waiting on the "we patch it eventually" schedule, the schedule just got weekly.

Closing

Two majors, same layer-neighborhood, five days apart. Nothing in either needs a 3am patch. Everything in both needs an hour of configuration review, and that hour is cheap now and expensive later. The identity layer now speaks one of the two languages automation needs (delegation with an act claim) and the forge layer now enforces the other boundary (egress). The tooling for safely giving agents access is maturing faster than the practice of using it responsibly. That gap is operator work. This site's standing advice, same as it ever was: boring config maintenance, done on schedule, is the whole game.

Sources: Gitea 28.0.0 release notes; PR #39426 egress proxy; Keycloak 26.8.0 release; Keycloak token exchange delegation docs; elest.io Self-Hosted Weekly, week 40; Ubuntu CVE-2026-80521.