An information disclosure flaw in FFmpeg's Go2Meeting (G2M) decoder lets an attacker who supplies a crafted G2M3/G2M4 stream read uninitialized stack memory, because out-of-range Kempf palette indices cause kempf_restore_buf() to copy stale stack bytes - potentially pointers or stack guards - into the decoded frame. FFmpeg 2.0 through 9.0.2 are affected; exploitation requires the victim or an automated media pipeline to decode the crafted file and a way to observe the resulting decoded output, and it grants no integrity or availability impact. The upstream fix (commit edad2d0dafcf44fa315eab716fd0183ce808053b, PR 24858) adds a col >= npal bounds check; no public exploit code has been identified at time of analysis and CVE-2026-120243 is not in CISA KEV.
Authenticated users with low privileges on WordPress sites running the Crocoblock JetFormBuilder plugin through 3.6.7.1 can exploit a path traversal flaw to delete files outside the intended directory, degrading availability (CVSS 6.5, availability-only impact). The issue is network-reachable with low complexity and no user interaction, but it requires a logged-in account (PR:L), so sites that allow open or low-barrier registration carry the highest practical exposure. No public exploit code or CISA KEV entry is associated with this CVE in the available data, and the exact vulnerable endpoint or path parameter is not identified in the sources; the priority label assigned is 'this_month'.
Apache Wicket 8.x through 10.x can be made to return the HTML markup template of an application's own component class instead of the static file that the package resource guard approved, giving a remote unauthenticated attacker read access to developer-authored template source. Exposure is conditional: the application must contain a component class whose simple name includes an underscore and for which no shorter underscore-delimited prefix is itself a class (for example Report_v2 or Wizard_Step1), and disclosure is confined to HTML files in that component's own package - component structure, developer comments, conditional markup, inline script and named endpoints, but no user data, credentials or session material. No public exploit code is identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Markup template disclosure in Apache Wicket 8.0.0-8.19.0, 9.0.0-9.24.0 and 10.0.0-10.11.0 allows unauthenticated remote attackers to fetch a component's HTML markup template over HTTP with status 200 by requesting its package-resource URL. The flaw only manifests in non-standard deployments where wicket-core is loaded by a class loader that cannot see the application's component classes (shared servlet-container library directory, EAR lib directory with the WAR-hosted application, application-server global module, or OSGi bundle); the ordinary WAR layout with wicket-core in WEB-INF/lib is not affected. Impact is strictly read-only disclosure of developer-authored template content - component structure, comments, conditionally rendered markup, inline script and named endpoints - with no user data, credentials or session material reachable and no integrity or availability effect; no public exploit code was identified at time of analysis and there is no CISA KEV listing, and the priority signal is this_month rather than immediate action.
Apache Wicket's resource authorization check is bypassed when a restricted resource is served through a component that was constructed with an IResource instance instead of a ResourceReference. The framework enforces IAuthorizationStrategy#isResourceAuthorized() and the wicket-auth-roles @AuthorizeResource annotation at only one point - ResourceRequestHandler - so ResourceLink(String, IResource), Image, ImageButton and AjaxDownloadBehavior call IResource#respond() directly from their own request listener and never consult the strategy; for Image and ImageButton the listener URL is written into the tag's src attribute, so a browser fetches the protected content with no user action. Affected versions are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0; only applications that actually restrict a resource and then hand that same instance to one of these components are exposed, and ExportToolbar in wicket-extensions triggers the pattern for data-table exports. No public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS data was not provided; severity is rated medium (vendor CVSS 4.0 base 6.3).
Missing authorization in Apache Wicket's native WebSocket transport allows a remote caller who holds a bound Wicket session to invoke the callbacks of a registered `WebSocketResource` shared resource without the application's `IAuthorizationStrategy` ever being consulted, so class-level restrictions such as `@AuthorizeResource` are silently ignored. The flaw is unauthenticated per the CVSS vector (PR:N) and affects Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, 10.0.0 through 10.11.0, and older unsupported 7.x releases, but only where an application registers a `WebSocketResource` as a shared resource and relies on the authorization strategy to protect it. Impact is bounded to whatever the targeted resource's `onConnect()` and `onMessage()` callbacks do with an attacker-supplied text or binary message, and because the connection registers under the caller's own session there is no path to another user's connection; no public exploit code has been identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Denial of service in the ag-ui TypeScript client SDK (versions up to and including 0.0.58) allows a party that controls the interrupt/event producer to permanently wedge a conversation thread by emitting one or more Interrupt objects that omit the expiresAt field. isInterruptExpired treats a missing expiresAt as 'never expires', and the client's resume-coverage check requires every pending interrupt to be addressed before the thread can run again, so the thread stays blocked; before the fix there was also no cap on how many pending interrupts were tracked per thread. No public exploit code has been confirmed (a public PoC reference exists; it is not verified as working exploit code), CVE is not in CISA KEV, and impact is availability-only with no data exposure or modification.
Denial of service in the ag-ui TypeScript client SDK (versions up to 0.0.58) where the SSE/protobuf stream parser fails to cap buffered data, so a malicious or compromised AG-UI server can force excessive memory consumption in the consuming client. Exploitation requires control over the data delivered into the event stream and a low-privileged stream connection (CVSS PR:L), confining impact to low availability loss with no confidentiality or integrity effect; a public PoC reference exists but is not verified as working exploit code, and no active exploitation has been reported. Priority signals consistently place this as a low-severity, monitor-level issue.
Resource exhaustion in the ag-ui Protocol TypeScript client SDK (versions up to and including 0.0.58) allows a hostile or compromised HTTP endpoint to force the client process to buffer an unbounded error-response body, degrading availability of that client. The flaw sits in the HTTP Transport error path of runHttpRequest, which read non-success response bodies in full with no size limit, so an attacker who controls, has compromised, or can man-in-the-middle the server the client talks to can return an oversized or never-ending body on a non-2xx status and exhaust process memory. Impact is availability-only for the initiating client - no data disclosure or modification - and a public PoC reference exists (GitHub issue 2521); it is not verified as working exploit code. An upstream fix is proposed in pull request 2698 but is not yet merged or released, and the current assessment rates this as a medium-severity, availability-only issue rather than a top-priority emergency.
Improper input validation in the AG-UI protocol SDK transport decoder path affects ag-ui versions up to and including 0.0.58, allowing crafted event content to be parsed without proper text handling and producing limited confidentiality, integrity and availability impact. The attack is remote and requires low-level privileges (PR:L with no user interaction), meaning the attacker must be an authorized participant able to submit events over an AG-UI transport rather than an anonymous internet user. A public PoC reference exists (GitHub issue 2524) but it is not verified as working exploit code, and the vendor fix is available in 0.0.59 via commit 660182b973a44b8eda5484b14b88eb9cc251edc4.
Cross-site scripting in the PostyBirb Plus submission description editor affects versions through 3.1.75. Crafted description markup loaded through the editor's defaultValue or overwriteDescriptionValue paths can execute in the Electron renderer, but exploitation requires an authenticated local user of the desktop app and user interaction, and impact is limited to integrity with no confidentiality or availability loss. Version 3.1.76 fixes the issue by sanitizing those loaded values; a public PoC reference exists, but it is not verified as working exploit code.
OpenAlgo 1.0.0.29 up to but excluding 2.0.3.1 ships SMTP client code that switches off TLS certificate and hostname verification, so a network-positioned attacker who can intercept the path between OpenAlgo and its configured mail server can present a forged certificate, terminate the TLS session, and read the SMTP username and password along with every subsequent message - including password-reset links. The weakness is in the shipped code itself (utils/email_utils.py and utils/email_debug.py) and applies to both STARTTLS and implicit SMTPS paths, so any affected instance that sends mail is exposed without special configuration. Exploitation still requires the attacker to hold an active man-in-the-middle position (AV:A, AC:H, AT:P), which is the main limiter; no public exploit has been identified at time of analysis and no active exploitation is confirmed, making this a medium-severity confidentiality issue suited to scheduled, this-month remediation rather than emergency response.
Cross-site scripting in the Cloud Management web interface of Ruijie RG-ES series switches (RG-ES205GC, RG-ES206GC-P, RG-ES208GC, RG-ES210GC-LP and RG-ES210GS-P running firmware ESW_1.0(1)B1P48) lets an administrator who already holds high-privilege access inject script through the 'url' argument of set_cloud_serverUrl.cgi, with the payload running in a victim's browser only after that victim interacts with the resulting page. Scoring reflects that constraint: CVSS 4.0 rates it 1.9 with PR:H and UI:P, and the independent assessment lands on CVSS 3.1 AV:N/AC:L/PR:H/UI:R/S:C/C:N/I:L/A:N, meaning the realistic ceiling is limited integrity impact on page content rather than credential theft or device takeover. A public PoC reference exists in a GitHub repository, but it is not verified as working exploit code; there is no KEV listing and the current decision label is monitor.
Presenton 0.9.11-beta and earlier ship an Electron desktop build whose local Next.js and FastAPI HTTP servers accept requests without authentication, allowing anonymous clients that can reach those loopback services to use internal REST, export and local-file-read functionality and to read files the app can access. Exploitation is narrowed by the loopback binding: a genuinely remote attacker needs local access to the host or must induce a victim's browser to issue cross-port or DNS-rebinding requests to localhost, so the assessed CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N yielding low confidentiality, integrity and availability impact. The CVSS 4.0 vector supplied by the CNA rates exploitation maturity as proof-of-concept (E:P) and the CVE text asserts that exploit code has been made public; that claim is not independently verified here, no CISA KEV entry is associated, and the vendor resolves the issue in 0.9.12-beta.
Predictable session-ID generation in Oray Pugongying X5 Pro up to 7.6.1 lets an authenticated ordinary user recover another user's password by manipulating the _user argument in the session_get function of session.lua. The published CVSS 4.0 score is 1.3, and the independent assessment uses CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N: remote reachable, high complexity, and limited to confidentiality with no integrity or availability impact. A public PoC reference exists but is not verified as working exploit code, no CISA KEV status is reported, and the issue is low priority despite remote reachability because an existing low-privilege account is required.
Code injection in the Groovy Script Executor component of beecue FastBee up to and including 2.1.0 lets a remote attacker who holds a high-privilege account submit crafted script content through /iot/script and have it executed by the platform, producing limited confidentiality, integrity and availability impact. The CVSS 4.0 base score is 5.1, and the CVSS 3.1 assessment places it at PR:H, so exploitation is confined to authorized operators or attackers who have already obtained privileged credentials. A vendor fix is available as the Gitee commit 890a33846005a937a58cccd738b7fb9821b82ea9; no public exploit code and no confirmed active exploitation are identified at time of analysis.
OS command injection in Minimax Code 0.5.8 lets an attacker who controls the -exec argument of the Find Command Handler inject and execute operating-system commands. Exploitation requires a valid low-privilege account (PR:L) plus passive user interaction (UI:P), and only version 0.5.8 is identified as affected; the vector's low confidentiality, integrity and availability ratings indicate command execution in a constrained context rather than full host takeover. No public exploit code has been identified at time of analysis, the vendor was contacted but did not respond, and this is tracked as a medium-severity, this-month priority item rather than an emergency.
Stored cross-site scripting in Thelia's back-office store configuration lets an authenticated administrator holding store update permission upload SVG logo or banner images whose event handlers and script content are stored intact, creating a persistent script implant on the shop origin. The same bytes execute against higher-privileged administrators at /admin/store-media/logo and against anonymous visitors, crawlers and link-preview fetchers via the image cache copy mirrored into the document root and advertised in every front-office page's og:image meta. The vendor fixed the flaw in Thelia 3.1.1 and back-office default-twig template 1.1.1, and the GitHub advisory carries a step-by-step PoC walkthrough, so a public PoC reference exists; it is not verified as working exploit code, and the issue is not confirmed actively exploited (CISA KEV).
Pages rendered by Apache Wicket 10.10.0, 10.11.0 and 9.24.0 can be served without any Content-Security-Policy header when the page's render request handler is wrapped in more than one IRequestHandlerDelegate, because the framework unwraps only a single delegate level when deciding whether a request renders a page; with a deeper chain - for example an application-provided delegating request mapper combined with CryptoMapper - CSP is silently skipped with no error or warning, and the nonce-based protection for inline scripts and styles plus any other configured directives are lost for those pages. Only applications that wrap request handlers themselves in a non-default deployment are exposed; stock Wicket applications are not affected, and because the defect removes a protective control rather than providing an injection primitive, actual content injection additionally requires a separate injection vector on such a page and a victim rendering it (passive user interaction). This is a low-severity, configuration-dependent regression - versions before 10.10.0 and 9.24.0 handled nested delegates correctly - and no public exploit has been identified at time of analysis, with CISA KEV status absent and the vulnerability not listed as actively exploited.
Apache Wicket's native WebSocket support keeps serving a session after the servlet container has ended it: because each connection resolves its Wicket session from a copy taken at handshake time, an authenticated user holding an open socket continues to be treated as signed in - with the original session attributes and, in wicket-auth-roles applications, the signed-in state - for as long as the connection stays open. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (older unsupported 6.x releases from 6.0.0 are also affected), but only where an application uses native WebSocket pages or WebSocketResource endpoints that require an authenticated session and terminates sessions through the container (idle timeout, filter or security-framework HttpSession#invalidate(), container-managed logout, or session replacement) rather than through Wicket. Severity is low (CVSS 4.0 base score 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) since the attacker must already hold such an authenticated connection, and no public exploit has been identified at time of analysis.
Missing authorization in Apache Wicket's native WebSocket support lets a client's text and binary messages reach a WebSocketBehavior's onMessage() callbacks even when the component that behavior is attached to is hidden, disabled, or denied by the application's IAuthorizationStrategy. Only applications that override onMessage() on a WebSocketBehavior attached to (or beneath) such a restricted component are affected, and an attacker must hold their own valid session and open their own page containing that component, since messages are delivered only within the client's own page store and never to another user's session or connection. Affected releases are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (with older unsupported 6.x-and-later releases also affected); no public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and priority signals point to monitoring rather than urgent action.
Catastrophic backtracking in loguru's ANSI color-markup parser (AnsiParser.feed in loguru/_colorizer.py, with the CPE covering 0.7.3 and, as a wildcard range, other versions) lets an attacker who can get crafted text into a colorized log message exhaust CPU and degrade availability. Reachability is integration-specific: only host applications that route attacker-controlled strings through the colorization/markup path with markup enabled are exposed, which is why our assessed vector rates attack complexity High with Availability-only impact. There is no CISA KEV entry; the disclosure states the exploit is now public, but that has not been verified as working exploit code, and the vendor did not respond to the report, so no fixed version is identified at time of analysis.
Schema validation bypass in the lud jsv JSON Schema validator (versions 0.1.0 through 0.26.1) lets an unauthenticated remote attacker slip input past `pattern`, `patternProperties`, `propertyNames` and `not` constraints. The root cause is that jsv's backtracking-limited regex helper runs :re.run/3 without :report_errors, so a PCRE match_limit exhaustion is returned as :nomatch and treated as a genuine non-match - a failed `pattern` under `not`, `anyOf`, `oneOf`, `if` or `contains` can therefore make the parent schema succeed, and a skipped `patternProperties` subschema leaves the value checked against `additionalProperties` or not at all. Exploitation is conditional: the deployed schema must already contain a regex with nested quantifiers or overlapping alternatives that forces backtracking before the matching branch, which is why the assessed vector is network-reachable but high-complexity with only low integrity impact (CVSS 3.1 AV:N/AC:H/PR:N/UI:N/C:N/I:L/A:N; vendor CVSS 4.0 base 2.1); the vendor advisory publishes a proof-of-concept walkthrough, but it is not verified as working exploit code and there is no evidence of active exploitation (not in CISA KEV), with the overall priority rated monitor.
Incorrect ordering of security checks in Apache Wicket 9.1.0 through 9.24.0 and 10.0.0 through 10.11.0 allows a cross-origin request to bypass the opt-in ResourceIsolationRequestCycleListener when an application refuses unauthenticated visitors with RestartResponseAtInterceptPageException and later calls continueToOriginalDestination(), so a victim who follows an attacker-supplied top-level navigation and then signs in resumes a form whose query-string field values were chosen by another origin. Impact is confined to integrity of form values read from the query string on the resumed GET; request-body parameters stored with the intercepted URL are not replayed, already-authenticated visitors are unaffected, and user interaction is required. The vulnerability is assessed as low severity (CVSS 3.1 base 2.1-equivalent integrity-only impact) and no public exploit identified at time of analysis.
Stored cross-site scripting in the Typemill flat-file CMS through 2.26.0 allows an authenticated user with media/image upload rights to upload a crafted SVG that executes script in a victim's browser when the file is later opened or rendered. The sanitizer in system/typemill/Models/SvgSanitizer.php accepted SVG files carrying a DOCTYPE (DTD) declaration and left XML processing instructions and comments in place, which per the patch can trigger XSLT transformations in browsers. A public exploit reference has been published and may be used, but this is a moderate, not emergency, priority requiring login, upload permission and a second user viewing the file; upgrading to 2.27.0 resolves it.
Local buffer overflow in Hangzhou Xiongmai Technology's P2P SDK affects P2PAPI.dll 1.3.3.32 on Windows, where a crafted 'input' string passed to P2PAPI_Connect overflows a buffer. Per the independent assessment, exploitation requires local access and low-level privileges (AV:L/PR:L) and is confined to availability impact (VA:L, no confidentiality or integrity loss), scoring 1.9 - a genuinely low-priority, monitor-level issue. The vendor was contacted and did not respond, and the public disclosure includes a linked GitHub gist reference that has not been verified as working exploit code; no CISA KEV entry or other confirmed active exploitation signal is present.
The web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the `public-only` restriction of the personal access token used to authenticate. Any user holding a public-only token could send it over HTTP Basic authentication to read the profile and activity feed of limited-visibility users and organizations, which are hidden from anonymous visitors and refused on the equivalent API routes. The disclosure covers existence, profile metadata and public activity; it does not grant write access.
The `/{username}` web route accepted personal access tokens over HTTP Basic authentication without checking their scope. A token confined to an unrelated scope, such as `read:issue`, could read its owner's private activity through the user RSS/Atom feed and the profile activity tab, and other members' activity in a private organization through the organization feed; a public-only token could list the owner's private repositories and organizations and render private profile READMEs. For a site administrator's token this applied to every account. Tokens are now accepted on this route only for feeds, which require `read:user` or `read:organization`.
XS::libbrotli versions before 1.2.1.0 for Perl bundle a brotli library with an out-of-bounds write in the decoder. Affected versions compile a bundled brotli into static archives that dependent XS modules link against at build time, rather than using the system library. The bundled copy, 1.0.7 or 1.1.0 across the range, carries the decoder out-of-bounds write described in CVE-2026-111497. Version 1.2.1.0 updates it to brotli 1.2.1. XS::libbrotli has no Perl interface, so the decoder is reached through any dependent module that decompresses untrusted data with it. An attacker supplying a crafted brotli stream can corrupt decoder state, disclose memory, crash the process, or potentially execute arbitrary code. Upgrading the system brotli does not remediate this.
Legacy (v1 to v3) Actions artifact uploads stored the request's `Content-Encoding` header unchecked in the column that is served as the artifact's `Content-Type` on download, and a value starting with `video/` or `audio/` also removed the sandboxing Content-Security-Policy. A user who can run an Actions job could upload an artifact that a browser renders as HTML on the Gitea origin when the direct artifact download URL is opened, and the URL is reachable anonymously on public repositories. A victim who opens the link runs the attacker's script with their own session, which for an administrator means control of the instance. Legacy uploads now store only the `gzip` marker, and the special serve headers are chosen only for valid media types.
The issue timeline API and the web issue page hid cross-reference events that point at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue had been linked as a dependency to an issue in a repository the reader cannot access, for example a private repository, any reader of the first issue, including anonymous users of a public repository, received the linked issue's current title, body, state, labels, poster and attachment names through the API, and its repository, number and title on the web page. Creating the link requires access to both issues; comments and attachment downloads of the linked issue stayed protected. Dependency events are now filtered with the same read permission check; a related exposure of unlinked attachment metadata through hidden dependency placeholders was already fixed in 28.2.0.
The web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check whether the repository is archived. A user allowed to change issues of an archived repository could use the API to edit, close or delete issues, change labels and deadlines, add or delete tracked time and stopwatches, add reactions, change issue blocks, and pin issues, altering data that archiving is meant to freeze. Gitea 28.2.0 added the check to the issue edit, delete and label routes; Gitea 28.3.0 applies it to all modifying repository API requests.
When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access.
Gitea 1.27.3 stopped personal access tokens restricted to public resources (`public-only`) from creating repositories through `POST /api/v1/user/repos` and `POST /api/v1/repos/migrate`, but `POST /api/v1/org/{org}/repos`, `POST /api/v1/orgs/{org}/repos`, `POST /api/v1/orgs` and `POST /api/v1/repos/{owner}/{repo}/generate` still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates. The token still could not read the private repositories it created.
The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (`public-only`). A holder of such a token could list the private repositories visible to the token's owner, and that user's stars and watches of private repositories. The API and the profile activity tab already applied the restriction. The impact is disclosure of repository names and metadata, not of repository content.
`GET /api/v1/users/{username}/heatmap` computed the contribution heatmap with the repository access of the token owner and ignored the public-only restriction of the access token, unlike the activity feed endpoints. A holder of a user's public-only token could read contribution counts and their 15-minute time buckets that stem from that user's activity in private repositories. Repository names and contents were not disclosed. For public-only tokens the heatmap now only counts activity visible to anonymous users.
Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed. Boards now skip linked pull requests in repositories where the viewer cannot read pull requests.
`DELETE /api/v1/orgs/{org}/repos` deletes all repositories of an organization, but it did not enforce the public-only restriction of access tokens: the route only checked that the organization itself was public. A public-only token of an owner of a public organization could therefore permanently delete the organization's private repositories, which such a token must not reach. Routes that require organization ownership now reject public-only tokens.
The OAuth2 userinfo endpoint (`/login/oauth/userinfo`) decided whether to limit the `groups` claim to public organizations by re-parsing the `Authorization` header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships. The disclosure is limited to the owner's organization and team names and memberships; no repository content is exposed. The endpoint now uses the scope of the authenticating token.
The OCI registry's cross-repository blob mount checked the target package against the token's `public-only` restriction, but checked the source blob only against the full account permissions of the token owner. A `public-only` token with `write:package` scope, whose owner can read a private package and write to a public package namespace, could mount a blob of the private package into the public package. The private blob, such as a container layer, could then be downloaded by anyone through the public package.
The `/api/v1/admin` route group did not enforce the `public-only` restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could therefore list private organizations and the email addresses of all users, create organizations, obtain runner registration tokens and create new site administrator accounts, the last of which persists after the token is revoked. Tokens of users who are not site administrators cannot reach these routes; public-only tokens are now rejected on the admin API.
The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping their download URLs, delete releases and tags, and create, edit or delete milestones and labels of a repository that is meant to be read-only. Changing requests on these routes now return 423 Locked for archived repositories.
Gitea did not reject personal access tokens restricted to public resources (`public-only`) on the organization Actions runner registration-token endpoint, and the runner registered with the resulting token was not limited to public repositories. Holding only such a token with `write:organization` that belongs to an owner of a public organization, an attacker could register an organization-level runner and receive jobs of the organization's private repositories that have Actions enabled, including the workflow content, Actions secrets and variables, and a task token with access to the private repository. The issue widens what the restricted token can reach; it gives nothing beyond what the owner's full account can already do.
When `[oauth2_client].ACCOUNT_LINKING` is set to `auto` (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and be signed in as it without its password, including as an administrator. The link persisted for later sign-ins. Automatic linking now only happens when the existing account matches the provider's email or provider-derived user name; otherwise the account password is required.
Workflows triggered by a pull request review were read from the commit named in the review's `commit_id`, while the fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a `GITEA_TOKEN` with write access to the repository. Review-triggered workflows now run on the pull request head.
Gitea Actions task tokens authenticate to the REST API as a shared system user with a negative ID, which repository, organization, project and key filters treated as having no owner restriction, and the token carried no API scope to restrict user-scoped routes. A user who can run a workflow could use the job's token with `GET /api/v1/user/repos` to list every repository on the instance, including private repositories of other users and organizations, with their metadata. Repository contents remained protected by per-repository permission checks. System users now own nothing, and `/api/v1/user` routes other than `GET /api/v1/user` accept only individual and bot accounts.
The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation (the default) the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance in every repository where they appear, including pull requests to repositories the user cannot write to. The impact is limited to the displayed signature status: enforcement such as required signed commits only checks that a signature is verified and is unaffected, and no access is gained. The `/api/v1/user` routes now reject system users.
Google::Auth versions from 0.11 through 0.12 for Perl accept an authorization code from any local process because the gcloud-auth login callback does not check the OAuth state. The gcloud-auth login and application-default login commands send a state parameter with the authorization request, then take the code from the first request to reach their loopback listener without comparing the returned state. A local attacker can submit an authorization code for their own Google account. The CLI exchanges it and stores the refresh token as the user's credentials, so the user's tools then act as the attacker's account.
Google::Auth versions 0.12 for Perl allow server side request forgery via unvalidated credential_source URLs in AWS external account credentials. An external_account configuration with the AWS subject token type selects Google::Auth::ExternalAccountCredentials::Aws. Its retrieve_subject_token sends requests to the imdsv2_session_token_url, url and region_url fields of credential_source without the host check that the other credential classes apply. Any caller that builds credentials from a configuration it does not fully control issues GET and PUT requests to hosts the configuration names, including internal services and link-local metadata endpoints.
HTTP::Session versions before 0.54 for Perl allow memcached command injection via unfiltered session ids in HTTP::Session::Store::CHI. The session id from the client's cookie reaches the CHI cache unchanged. The sibling HTTP::Session::Store::Memcached rejects ids that contain control characters, but the CHI store has no such check, and CHI does not escape keys for its memcached drivers. With a memcached driver, a CR and LF in the session id end the cache command early, and the server reads the bytes after them as further commands.