fix(security): backport 12 upstream security fixes from v1.26.2 #165

2026-05-24T08:53:17Z

jmiller commented

2026-05-24 08:53:17 +00:00

Backports 12 security and hardening fixes from upstream release/v1.26:

golang.org/x/net v0.55.0 security update (critical)
Token scope enforcement on raw/media/attachment downloads
OAuth PKCE hardening and refresh token replay protection
Wiki git write and LFS token access enforcement
Public-only token filtering in API queries
Reading permission fix
Artifact signature payload hardening
AWS credentials encryption
Mermaid v11.15.0 security update
Composer package permission check

Closes #140 #141 #142 #143 #144 #145 #146 #161 #162 #164

Backports 12 security and hardening fixes from upstream release/v1.26: - golang.org/x/net v0.55.0 security update (critical) - Token scope enforcement on raw/media/attachment downloads - OAuth PKCE hardening and refresh token replay protection - Wiki git write and LFS token access enforcement - Public-only token filtering in API queries - Reading permission fix - Artifact signature payload hardening - AWS credentials encryption - Mermaid v11.15.0 security update - Composer package permission check Closes #140 #141 #142 #143 #144 #145 #146 #161 #162 #164

jmiller added 12 commits 2026-05-24 08:53:18 +00:00

fix(packages): Add label for private and internal package and fix composor package source permission check (#37610 ) (#37643 ) 738117248d

Backport #37610 by @lunny

- Add permission checks for Composer package source links

- Add private/internal visibility labels for packages, similar to
repository visibility labels

<img width="969" height="571" alt="image"
src="https://github.com/user-attachments/assets/8a8ec3a0-bfbd-4dd6-b45b-58eda5db1a2d"
/>

- Add a link to change package visibility

<img width="1309" height="208" alt="image"
src="https://github.com/user-attachments/assets/3fa82b23-4c63-4a5e-b3f0-d37a103231ee"
/>

- Update link package descriptions

<img width="1308" height="265" alt="image"
src="https://github.com/user-attachments/assets/2c80b50e-5ffe-4d96-aedd-aa15964c4e05"
/>

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Nicolas <bircni@icloud.com>
Co-authored-by: silverwind <me@silverwind.io>

fix(deps): update dependency mermaid to v11.15.0 [security], add e2e test (#37665 ) ee6405f4fd

Backport of #37662.

---
This PR was written with the help of Claude Opus 4.7

---------

Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>

feat(api): encrypt AWS creds (#37679 ) (#37713 ) ce83900967

Backport #37679 by @Exgene

## Description

As mentioned in #37654 `AWSAccessKeyID` and `AWSSecretAccessKey` are not
encrypted and stored as is.

## Update

Follow the existing `AuthToken` flow of setting the `Encrypted` fields,
`Decrypting` them later and `Clearing` them at the end.

Closes #37654

Signed-off-by: Kausthubh J Rao <105716675+Exgene@users.noreply.github.com>
Co-authored-by: Kausthubh J Rao <105716675+Exgene@users.noreply.github.com>
Co-authored-by: Lauris B <lauris@nix.lv>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>

fix(security): enforce wiki git writes and LFS token access at request time (#37695 ) (#37714 ) 6e0236d433

Backport #37695 by @lunny

This PR fixes two permission-checking gaps in Git and LFS request
handling.

## What it changes

- keep wiki Git HTTP pushes on the normal write-permission path, even
when proc-receive support is enabled
- revalidate LFS bearer token requests against the current user state
and current repository permissions before allowing access
- add regression coverage for unauthorized wiki HTTP pushes
- add LFS tests for blocked users, revoked repository access, read-only
upload attempts, and valid write access

## Why

- wiki repositories should not inherit the relaxed refs/for handling
used for normal code repositories
- LFS authorization tokens should not remain usable after a user is
disabled or loses repository access

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>

fix(web): enforce token scopes on raw, media, and attachment downloads (#37698 ) (#37733 ) d2cdd9b1d6

fix(oauth): strengthen PKCE validation and refresh token replay protection (#37706 ) (#37738 ) 2f381dc16c

Backport #37706

This PR tightens several OAuth validation paths related to PKCE
handling, redirect URI normalization, and refresh-token replay safety.

What it changes:

- switch redirect URI comparison to ASCII-only normalization for
exact-match checks, avoiding Unicode case-folding surprises
- harden PKCE verification by:
  - allowing PKCE omission only when no challenge data was stored
  - rejecting exchanges with a missing verifier when PKCE was used
- rejecting malformed challenge state where a challenge exists without a
valid method
  - comparing derived challenges with constant-time string matching
- make refresh-token invalidation counter updates conditional on the
previously observed counter value, so stale refresh state cannot be
accepted after the grant changes

Why:

These checks close gaps where:
- redirect URI comparisons could rely on broader Unicode normalization
than intended
- malformed or incomplete PKCE state could be treated too permissively
- concurrent or stale refresh-token use could advance the same grant
more than once

Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>
Co-authored-by: Nicolas <bircni@icloud.com>

fix(oauth): bind token exchanges to the original client request (#37704 ) (#37740 ) 2482a3726e

Backport #37704 

This PR hardens OAuth token exchange validation by binding exchanged
credentials to the client and redirect URI that originally obtained
them.

What it changes:

- reject refresh token exchanges when the refresh token belongs to a
different OAuth application
- reject authorization code exchanges when the `redirect_uri` in the
token request differs from the `redirect_uri` stored with the
authorization code
- add integration coverage for:
  - authorization code exchange with a mismatched redirect URI
- refresh token reuse across two different dynamically created OAuth
applications

Why:

OAuth authorization codes and refresh tokens must remain bound to the
client context that originally received them. Without those checks:
- a valid authorization code can be redeemed against a different
registered redirect URI of the same client
- a refresh token can be replayed by a different OAuth client

---------

Co-authored-by: Nicolas <bircni@icloud.com>

fix: Add missed token scope checking (#37735 ) (#37757 ) e9efbbc93b

Backport #37735 by @lunny

Follow #37698

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>

fix: Unify public-only token filtering in API queries and repo access checks (#37118 ) (#37773 ) ca6c8c958c

backport #37118 

This PR closes remaining `public-only` token gaps in the API by making
the restriction apply consistently across repository, organization,
activity, notification, and authenticated `/api/v1/user/...` routes.

Previously, `public-only` tokens were still able to:
- receive private results from some list/search/self endpoints,
- access repository data through ID-based lookups,
- and reach several authenticated self routes that should remain
unavailable for public-only access.

This change treats `public-only` as a cross-cutting visibility boundary:
- list/search endpoints now filter private resources consistently,
- repository lookups enforce the same restriction even when addressed
indirectly,
- and self routes that inherently expose or mutate private account state
now reject `public-only` tokens.

---
Generated by a coding agent with Codex 5.2

Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>
Co-authored-by: Nicolas <bircni@icloud.com>

fix(permissions): Fix reading permission (#37769 ) (#37781 ) b182855fc5

fix(actions): make artifact signature payloads unambiguous (#37707 ) (#37795 ) 43b5a54ffa

This PR hardens artifact URL signing by encoding signature inputs in an
unambiguous binary payload before computing the HMAC.

What it changes:

- replace direct concatenation-style signing inputs with explicit
payload builders
- encode string fields with a length prefix before appending their bytes
- encode integer fields as fixed-width binary values instead of decimal
text
- apply the same hardening to both:
  - Actions Artifact V4 signing in `routers/api/actions/artifactsv4.go`
  - artifact download signing in `routers/api/v1/repo/action.go`
- add regression tests that verify distinct field combinations produce
distinct payloads and signatures

Why:

The previous signing logic built HMAC inputs by appending multiple
fields without a strongly structured representation. That kind of
construction can create ambiguity at field boundaries, where different
parameter combinations may serialize into the same byte stream for
signing.

This change removes that ambiguity by constructing a deterministic
payload format with explicit boundaries between fields.

Backport #37707

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com>

fix(deps): update module golang.org/x/net to v0.55.0 [security] (#37813 ) (#37829 )

Branch Policy Check / Verify merge target (pull_request) Failing after 1s

Details

dbf70a7def

Backport #37813

Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: silverwind <me@silverwind.io>

jmiller merged commit 0270be743f into main

2026-05-24 08:53:24 +00:00

Sign in to join this conversation.

Priority -

Type -

Status —

Priority —

Type —

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoGitea-APP#165