| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Apache Wicket reads texts from the application's resource bundles — a localized label, a css class name — and writes some of them into the JavaScript and the markup it generates for a component. Those texts are placed inside single-quoted JavaScript string literals and inside quoted attribute values without being escaped for that context, so a text containing a quote ends the literal or the attribute, and what follows is parsed as script or as markup in the application's origin when the page loads.
A resource bundle entry is authored for the application and does not say where the framework will write it. The same key is read by the framework into element text, where Wicket escapes it, and into the contexts below, where it did not. A text containing an apostrophe, which is ordinary in several languages, is enough to break the page; a text under the influence of another party is enough to run script.
In org.apache.wicket:wicket-core, org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes the org.apache.wicket.mfu.delete message into a JavaScript string literal, and org.apache.wicket.markup.html.form.Form writes the hidden-fields css class into the class attribute of the container it renders for its hidden fields; on 8.0.0 through 8.19.0 and 9.0.0 through 9.24.0 Form#appendDefaultButtonField writes the same css class into a second container. In org.apache.wicket:wicket-extensions, UploadProgressBar writes its UploadProgressBar.starting text into a JavaScript string literal, FilterForm writes the hidden-fields css class into the class attribute of its hidden input markup, and on 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 TrapFocusBehavior writes its current css class into a JavaScript string literal.
The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does not prevent the JavaScript cases: the generated script is written into a script element carrying the per-response nonce, so the injected code is part of a script the policy admits. It does prevent an inline event handler injected through the attribute cases.
This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. |
| The System REST APIs do not correctly enforce access control mechanisms, allowing users with lower privilege roles to execute administrative actions that should be restricted. This weakness permits unauthorized operations on the affected product.
Successful exploitation could enable a malicious actor to perform unauthorized administrative operations, including executing administrative functions. APIs exposed through the WSO2 API Manager's API Gateway are not affected by this vulnerability. |
| Permission control vulnerability in the graphics module. Impact: Successful exploitation of this vulnerability may affect confidentiality. |
| DoS vulnerability in the file parsing module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Permission control vulnerability in the background task management module.
Impact: Successful exploitation of this vulnerability may affect service integrity. |
| Null pointer dereference vulnerability in the ArkWeb module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Buffer overflow vulnerability in the file preview module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| DoS vulnerability in the file parsing module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Permission control vulnerability in the WLAN module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| Race condition vulnerability in the location service module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| UAF vulnerability in the location service module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| OOB read vulnerability in the peripheral module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| DoS vulnerability in the window module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| Permission control vulnerability in the event notification management module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality. |
| DoS vulnerability in the DSoftBus module.
Impact: Successful exploitation of this vulnerability may affect availability. |
| 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. |
| 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. |
| `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. |
| 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`. |
| A weakness has been identified in apidevtools json-schema-ref-parser. This impacts the function Refs.set/Pointer.set in the library lib/pointer.ts. Executing a manipulation can lead to improperly controlled modification of object prototype attributes. The attack can be launched remotely. Upgrading to version 15.3.6 will fix this issue. This patch is called a786bc6afc3674f650496472ee93d5cf74c4bd84. It is suggested to upgrade the affected component. The project maintainer confirms: "I reproduced prototype pollution through the public $Refs.set() API in published versions 7.1.4, 9.0.0, 11.0.0, 14.0.0, 14.2.1, 15.3.0, and 15.3.5. The same pointer is rejected by 15.3.6 without modifying Object.prototype. This reported path requires an application to pass an attacker-controlled pointer to $Refs.set(); dependency presence alone does not establish exploitability." |
