Source
ghsa
A vulnerability was found in Kimai up to 2.15.0 and classified as problematic. Affected by this issue is some unknown functionality of the component Session Handler. The manipulation of the argument PHPSESSIONID leads to information disclosure. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. Upgrading to version 2.16.0 is able to address this issue. It is recommended to upgrade the affected component. VDB-263318 is the identifier assigned to this vulnerability.
Cross-site scripting (XSS) vulnerability in the search function in MvnRepository MS Basic 2.1.18.3 and earlier.
The Trix editor, versions prior to 2.1.1, is vulnerable to arbitrary code execution when copying and pasting content from the web or other documents with markup into the editor. The vulnerability stems from improper sanitization of pasted content, allowing an attacker to embed malicious scripts which are executed within the context of the application. **Vulnerable Versions**: Up to 2.1.0 **Fixed Version**: 2.1.1 **Vector**: - **Bug 1**: When copying content manipulated by a script, such as: ```js document.addEventListener('copy', function(e){ e.clipboardData.setData('text/html', '<div><noscript><div class="123</noscript>456<img src=1 onerror=alert(1)//"></div></noscript></div>'); e.preventDefault(); }); ``` and pasting into the Trix editor, the script within the content is executed. - **Bug 2**: Similar execution occurs with content structured as: ```js document.write(`copy<div data-trix-attachment="{"contentType":"text/html","content":"&l...
### Summary If PDF.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches [This patch](https://github.com/wojtekmaj/react-pdf/commit/671e6eaa2e373e404040c13cc6b668fe39839cad) forces `isEvalSupported` to `false`, removing the attack vector. ### Workarounds Set `options.isEvalSupported` to `false`, where `options` is `Document` component prop. ### References - [GHSA-wgrm-67xf-hhpq](https://github.com/mozilla/pdf.js/security/advisories/GHSA-wgrm-67xf-hhpq) - https://github.com/mozilla/pdf.js/pull/18015 - https://github.com/mozilla/pdf.js/commit/85e64b5c16c9aaef738f421733c12911a441cec6 - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645
An issue in tiagorlampert CHAOS before 1b451cf62582295b7225caf5a7b506f0bad56f6b and 24c9e109b5be34df7b2bce8368eae669c481ed5e allows a remote attacker to execute arbitrary code via the unsafe concatenation of the `filename` argument into the `buildStr` string without any sanitization or filtering.
An authenticated user could potentially access metadata for a datasource they are not authorized to view by submitting a targeted REST API request. This issue affects Apache Superset before 4.0.0. Users are recommended to upgrade to version 4.0.0, which fixes the issue.
In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, in the [EDC Connector component](https://github.com/eclipse-edc/Connector), an attacker might obtain OAuth2 client secrets from the vault. In Eclipse Dataspace Components from version 0.2.1 to 0.6.2, we have identified a security vulnerability in the EDC Connector component ( https://github.com/eclipse-edc/Connector ) regarding the OAuth2-protected data sink feature. When using a custom, OAuth2-protected data sink, the OAuth2-specific data address properties are resolved by the provider data plane. Problematically, the consumer-provided clientSecretKey, which indicates the OAuth2 client secret to retrieve from a secrets vault, is resolved in the context of the provider's vault, not the consumer. This secret's value is then sent to the tokenUrl, also consumer-controlled, as part of an OAuth2 client credentials grant. The returned access token is then sent as a bearer token to the data sink URL. This feature is now disabled e...
Minder's `HandleGithubWebhook` is susceptible to a denial of service attack from an untrusted HTTP request. The vulnerability exists before the request has been validated, and as such the request is still untrusted at the point of failure. This allows an attacker with the ability to send requests to `HandleGithubWebhook` to crash the Minder controlplane and deny other users from using it. One of the first things that `HandleGithubWebhook` does is to validate the payload signature. This is done by way of the internal helper `validatePayloadSignature`: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlers_githubwebhooks.go#L213-L218 `validatePayloadSignature` generates a reader from the incoming request by way of the internal helper `readerFromRequest`: https://github.com/stacklok/minder/blob/ee66f6c0763212503c898cfefb65ce1450c7f5ac/internal/controlplane/handlers_githubwebhooks.go#L337-L342 To create a reader from the incomin...
### Impact If pdf.js is used to load a malicious PDF, and PDF.js is configured with `isEvalSupported` set to `true` (which is the default value), unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches The patch removes the use of `eval`: https://github.com/mozilla/pdf.js/pull/18015 ### Workarounds Set the option `isEvalSupported` to `false`. ### References https://bugzilla.mozilla.org/show_bug.cgi?id=1893645
### Impact If using `keep_typographic_whitespace=False` (which is the default), the sanitizer normalizes unicode to the NFKC form at the end. Some unicode characters normalize to chevrons; this allows specially crafted HTML to escape sanitization. ### Patches The problem has been fixed in 2.4.2. ### Workarounds Set `keep_typographic_whitespace=True` explicitly, or normalize to NFKC yourself earlier.