ghsa

### Affected packages The vulnerability has been discovered in the samples that use the [preview](https://ckeditor.com/cke4/addon/preview) feature: * `samples/old/**/*.html` * `plugins/[plugin name]/samples/**/*.html` All integrators that use these samples in the production code can be affected. ### Impact A potential vulnerability has been discovered in one of CKEditor's 4 samples that are shipped with production code. The vulnerability allowed to execute JavaScript code by abusing the misconfigured [preview feature](https://ckeditor.com/cke4/addon/preview). It affects all users using the CKEditor 4 at version < 4.24.0-lts with affected samples used in a production environment. ### Patches The problem has been recognized and patched. The fix will be available in version 4.24.0-lts. ### For more information Email us at [[email protected]](mailto:[email protected]) if you have any questions or comments about this advisory. ### Acknowledgements The CKEditor 4 team would li...

### Affected packages The vulnerability has been discovered in the core HTML parsing module and may affect all editor instances that: * Enabled [full-page editing](https://ckeditor.com/docs/ckeditor4/latest/features/fullpage.html) mode, * or enabled [CDATA](https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_dtd.html#property-S-cdata) elements in [Advanced Content Filtering](https://ckeditor.com/docs/ckeditor4/latest/guide/dev_advanced_content_filter.html) configuration (defaults to `script` and `style` elements). ### Impact A potential vulnerability has been discovered in CKEditor 4 HTML processing core module. The vulnerability allowed to inject malformed HTML content bypassing Advanced Content Filtering mechanism, which could result in executing JavaScript code. An attacker could abuse faulty CDATA content detection and use it to prepare an intentional attack on the editor. It affects all users using the CKEditor 4 at version < 4.24.0-lts. ### Patches The problem has been rec...

### Impact The vulnerability allows unauthenticated execution of arbitrary SQL statements on the database the SQLAlchemyDA instance is connected to. All users are affected. ### Patches The problem has been patched in version 2.2. ### Workarounds There is no workaround. All users are urged to upgrade to version 2.2

### Summary Arrays can be keyed by a signed integer, while they are defined for unsigned integers only. The typechecker doesn't throw when spotting the usage of an `int` as an index for an array. Typically, negative integers are filtered out at runtime by the bounds checker, but small enough (i.e. large in magnitude, ex. `-2**255 + 5`) quantities combined with large enough arrays (at least `2**255` in length) can pass the bounds checker, resulting in unexpected behavior. A contract search was performed, and no production contracts were found to be impacted. ### Details The typechecker allows the usage of signed integers to be used as indexes to arrays. The vulnerability is present in different forms in all versions. Here is an example from `0.3.10`: https://github.com/vyperlang/vyper/blob/c150fc49ee9375a930d177044559b83cb95f7963/vyper/semantics/types/subscriptable.py#L127-L137 As can be seen, the validation is performed against `IntegerT.any()`. ### PoC If the array is sufficiently...

The Document and Media widget In Liferay Portal 7.2.0 through 7.3.6, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 13, and older unsupported versions, does not limit resource consumption when generating a preview image, which allows remote authenticated users to cause a denial of service (memory consumption) via crafted PNG images.

Stored cross-site scripting (XSS) vulnerability in the Portal Search module's Search Result app in Liferay Portal 7.2.0 through 7.4.3.11, and older unsupported versions, and Liferay DXP 7.4 before update 8, 7.3 before update 4, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML into the Search Result app's search result if highlighting is disabled by adding any searchable content (e.g., blog, message board message, web content article) to the application.

Improper Authentication vulnerability in Apache Ozone. The vulnerability allows an attacker to download metadata internal to the Storage Container Manager service without proper authentication. The attacker is not allowed to do any modification within the Ozone Storage Container Manager service using this vulnerability. The accessible metadata does not contain sensitive information that can be used to exploit the system later on, and the accessible data does not make it possible to gain access to actual user data within Ozone. This issue affects Apache Ozone: 1.2.0 and subsequent releases up until 1.3.0. Users are recommended to upgrade to version 1.4.0, which fixes the issue.

Observable timing discrepancy vulnerability in Apache Pulsar SASL Authentication Provider can allow an attacker to forge a SASL Role Token that will pass signature verification. Users are recommended to upgrade to version 2.11.3, 3.0.2, or 3.1.1 which fixes the issue. Users should also consider updating the configured secret in the `saslJaasServerRoleTokenSignerSecretPath` file. Any component matching an above version running the SASL Authentication Provider is affected. That includes the Pulsar Broker, Proxy, Websocket Proxy, or Function Worker. 2.11 Pulsar users should upgrade to at least 2.11.3. 3.0 Pulsar users should upgrade to at least 3.0.2. 3.1 Pulsar users should upgrade to at least 3.1.1. Any users running Pulsar 2.8, 2.9, 2.10, and earlier should upgrade to one of the above patched versions. For additional details on this attack vector, please refer to https://codahale.com/a-lesson-in-timing-attacks/ .

An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.

The `Webhook::verify` function incorrectly compared signatures of different lengths - the two signatures would only be compared up to the length of the shorter signature. This allowed an attacker to pass in `v1,` as the signature, which would always pass verification.