Ranex
Gitea 1.27.3, SiYuan 3.8.2 and Keycloak 26.7.3: upgrade checks

Gitea 1.27.3, SiYuan 3.8.2 and Keycloak 26.7.3: upgrade checks

What these three releases changed, what to verify before an upgrade, and a reproducible Gitea startup check with recorded results.

6 min read
Updated:
Share:X

Running Gitea, SiYuan, or Keycloak? These three releases contain security-related changes worth checking against your installed version and configuration. Start with the relevant row, then use the upgrade worksheet to record your rollout decision.

This is a dated release brief originally published September 3, 2026, with release sources reopened and a Gitea startup test added September 8. These are the versions covered by the article, not a claim that they remain the newest available releases.

Release covered What to investigate Next action
Gitea 1.27.3 Package access, repository permissions, and Actions trust boundaries. Map the linked SECURITY entries to your features; test representative repository workflows in staging.
SiYuan 3.8.2 The stored-XSS advisory described below. Compare your version and install method with the advisory’s affected range and fixed release.
Keycloak 26.7.3 Authentication, token exchange, and delegated administration fixes. Read the advisories relevant to your configuration and exercise your login and authorization flows.

Download the Gitea check and upgrade worksheet (ZIP). It includes the exact test script, image digest, recorded result, and an editable rollout checklist.

What the upstream sources say

Gitea v1.27.3

Published 2026-08-29T17:42:17Z, not a prerelease. The release notes lead with a SECURITY section, not ENHANCEMENTS: package token-scope handling, attachment path enforcement, same-repo issue access in markup, Actions artifact signatures, hiding limited users, fork-PR trust boundaries, hook permissions, and repo-creation token authorization all get fixes. No CVE is assigned on the page, and there's no CVSS score attached.

If you self-host Gitea, this one is yours to read. The release page doesn't enumerate which older versions each fix covers, so open the SECURITY list and check it against what your instance actually exposes. Gitea Cloud instances auto-upgrade in a maintenance window, so that's not your call to make. The license is unchanged: MIT at the v1.27.3 tag.

Primary source: Gitea v1.27.3 release notes

SiYuan v3.8.2

Published 2026-08-30T04:36:15Z. The changelog lists one bugfix line ("Some security vulnerabilities") linked to issue #18837, which indexes several GHSAs closed into this release. The one worth naming is GHSA-7h8j-qw37-w46g: Critical, CVSS 9.0, an incomplete asset blocklist that let a previously-fixed stored-XSS issue come back. Affected versions are <= 3.8.1; 3.8.2 patches it. The advisory was published 2026-08-19 and carries no CVE ID.

The advisory notes that desktop builds bundling pandoc carry higher impact than the official Docker container, which ships without pandoc at all. That distinction matters if you're choosing between install methods, and not only whether to upgrade. License is unchanged: AGPL v3.

Primary source: GHSA-7h8j-qw37-w46g advisory

Keycloak 26.7.3

Published 2026-08-31T09:29:37Z, not a prerelease. This is a CVE batch, not a single fix. CVE-2026-35563 covers an LDAP client that doesn't verify the server certificate hostname. CVE-2026-16093 is a signed-JWT assertion policy bypass through unsigned headers. CVE-2026-16089 lets authorization codes get retargeted to a different client session. The same notes list token-exchange tenant and hosted-domain bypasses (CVE-2026-18215 and CVE-2026-18214), plus bugs in FGAP v2 authorization.

The release page doesn't say which earlier patch levels each CVE reaches. What it does name is components: the security-fix rows carry labels for OIDC, LDAP, organizations, token-exchange, and FGAP v2. If your Keycloak leans on any of those, this is your release. Keycloak links a migration guide alongside the notes. I didn't re-fetch the individual GHSAs for this one; the release page was the primary source I checked.

Primary source: Keycloak 26.7.3 release notes

What we actually tested: Gitea fresh startup

On September 8, 2026 at 12:31 UTC, an automated local check started a fresh Gitea 1.27.3 container on amd64 with Docker 29.7.2, SQLite, one CPU, and a 512 MB memory limit. The test container had no external network, published ports, or host-directory mounts. Its data was disposable.

The image was pinned to:

docker.gitea.com/gitea@sha256:87a67ee09d3ae0d1df5fda5dcda3e2a1f9236a45b0a59025d6e00e46adc43bef
Check Observed result
GET /api/v1/version {"version":"1.27.3"}
GET /api/healthz Overall status pass; database:ping and cache:ping passed.
Cleanup The test script removed its disposable container and anonymous volumes.

To repeat this startup check, download and inspect the kit, then run the following from its extracted directory. It requires Python 3, a running Docker daemon, and network access to download the image.

python3 gitea-smoke.py

Test boundary: this demonstrates fresh startup and the reported endpoint responses. It does not verify an upgrade from an older database, backup/restore, repository workflows, or any security fix. SiYuan and Keycloak were not run locally for this article.

Before upgrading an existing installation

  1. Record the starting point. Save your installed version, image digest, deployment method, enabled integrations, and the exact target release.
  2. Read the matching guidance. Follow the release notes to relevant advisories and migration documentation. An affected-version range from one advisory does not describe every fix in a release.
  3. Prove recovery. Follow the project’s backup procedure and restore into a separate instance. For Gitea, start with the official backup and restore guide.
  4. Exercise your workflows in staging. For a Git forge, include login, clone, push, permissions, and any Actions or package workflows you use. For identity software, include the login and authorization paths your applications depend on.
  5. Write the rollback and monitoring plan. Record the owner, maintenance window, recovery steps, and post-upgrade checks. Do not assume that switching back to an old container image reverses a database migration.

A startup check is a useful first gate. Your staging results and demonstrated recovery path should determine whether the rollout is ready.

Evidence and disclosures

The release sections report upstream documentation and advisories; the separate Gitea section reports a local automated test. AI assistance was used for research, editing, and the test. Human review of the September 8 revision has not been recorded. Ranex publishes this site; no production-readiness or vulnerability-remediation certification is implied.

For a project you have not adopted yet, start with six repository checks beyond stars. Browse more guides at Open Source.

FAQ

Does the Gitea startup test prove an upgrade is safe?

No. It checks a fresh SQLite startup, the version endpoint, and the built-in health endpoint. Upgrade, restore, repository workflows, and security fixes were not tested.

Are these the latest releases?

This article covers the named releases from its September 3, 2026 brief. Check the upstream release pages and advisories for newer versions before planning an upgrade.

About the author

Anthony Garces

Anthony Ryan M. Garces is a Senior Principal Lead Architect with 17+ years in IT, including four years at Pantheon on mission-critical platform work. He is building Ranex in public.