#git

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (3.5) ### Problem The login screen of the standalone install tool discloses the full path of the transient data directory (e.g. _/var/www/html/var/transient/_). This applies to composer-based scenarios only - “classic” non-composer installations are not affected. ### Solution Update to TYPO3 version 12.4.8 that fixes the problem described above. ### Credits Thanks to Markus Klein who reported and fixed the issue. ### References * [TYPO3-CORE-SA-2023-005](https://typo3.org/security/advisory/typo3-core-sa-2023-005)

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.4) ### Problem DOM processing instructions are not handled correctly. This allows bypassing the cross-site scripting mechanism of [`typo3/html-sanitizer`](https://packagist.org/packages/typo3/html-sanitizer). ### Solution Update to `typo3/html-sanitizer` versions 1.5.3 or 2.1.4 that fix the problem described. ### Credits Thanks to Yaniv Nizry and Niels Dossche who reported this issue, and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2023-007](https://typo3.org/security/advisory/typo3-core-sa-2023-007) * [Disclosure & PoC](https://github.com/TYPO3/html-sanitizer/security/advisories/GHSA-652v-xw37-rvw7) (embargoed +90 days)

### Impact In certain versions of gitsign, Rekor public keys were fetched via the Rekor API, instead of through the local TUF client. If the upstream Rekor server happened to be compromised, gitsign clients could potentially be tricked into trusting incorrect signatures. There is no known compromise the default public good instance (`rekor.sigstore.dev`) - anyone using this instance is unlikely to be affected. ### Patches This was fixed in v0.8.0 via https://github.com/sigstore/gitsign/pull/399 ### Workarounds n/a ### References _Are there any links users can visit to find out more?_ https://docs.sigstore.dev/about/threat-model/#sigstore-threat-model

# Short summary Combining two molecules to one another, called "cross-linking" results in a molecule with a chemical formula that is composed of all atoms of the original two molecules. In Fabric, one can take a block of transactions and cross-link the transactions in a way that alters the way the peers parse the transactions. If a first peer receives a block `B` and a second peer receives a block identical to `B` but with the transactions being cross-linked, the second peer will parse transactions in a different way and thus its world state will deviate from the first peer. Orderers or peers cannot detect that a block has its transactions cross-linked, because there is a vulnerability in the way Fabric hashes the transactions of blocks. It simply and naively concatenates them, which is insecure and lets an adversary craft a "cross-linked block" (block with cross-linked transactions) which alters the way peers process transactions. For example, it is possible to select a transact...

### Impact When using the file uploads feature, it was possible to upload PHP files. ### Patches The vulnerability is fixed in v3.1.2.

All public versions prior to `1.02` used an insufficient check to ensure that users correctly marked the dependent type as either `covariant` or `not_covariant`. This allowed users to mark a dependent as covariant even though its type was not covariant but invariant, for certain invariant types involving trait object lifetimes. One example for such a dependent type is `type Dependent<'a> = RefCell<Box<dyn fmt::Display + 'a>>`. Such a type allowed unsound usage in purely safe user code that leads to undefined behavior. The patched versions now produce a compile time error if such a type is marked as `covariant`.

Cross Site Scripting vulnerability in BootBox Bootbox.js v.3.2 through 6.0 allows a remote attacker to execute arbitrary code via a crafted payload to alert(), confirm(), prompt() functions.

> ### CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N/E:X/RL:O/RC:C` (4.0) ### Problem Given that there are at least two different sites in the same TYPO3 installation - for instance _first.example.org_ and _second.example.com_ - then a session cookie generated for the first site can be reused on the second site without requiring additional authentication. This vulnerability primarily affects the frontend of the website. It's important to note that exploiting this vulnerability requires a valid user account. ### Solution Update to TYPO3 versions 8.7.55 ELTS, 9.5.44 ELTS, 10.4.41 ELTS, 11.5.33, 12.4.8 that fix the problem described above. ### Credits Thanks to Rémy Daniel who reported this issue, and to TYPO3 core & security team member Benjamin Franzke who fixed the issue. ### References * [TYPO3-CORE-SA-2023-006](https://typo3.org/security/advisory/typo3-core-sa-2023-006)

# Introduction This write-up describes a vulnerability found in [Label Studio](https://github.com/HumanSignal/label-studio), a popular open source data labeling tool. The vulnerability affects all versions of Label Studio prior to `1.9.2post0` and was tested on version `1.8.2`. # Overview In all current versions of [Label Studio](https://github.com/HumanSignal/label-studio), the application allows users to insecurely set filters for filtering tasks. An attacker can construct a *filter chain* to filter tasks based on sensitive fields for all user accounts on the platform by exploiting Django's Object Relational Mapper (ORM). Since the results of query can be manipulated by the ORM filter, an attacker can leak these sensitive fields character by character. For an example, the following filter chain will task results by the password hash of an account on Label Studio. ``` filter:tasks:updated_by__active_organization__active_users__password ``` For consistency, this type of vulnerabil...

Path Traversal: '\..\filename' in GitHub repository salesagility/suitecrm prior to 7.14.2, 7.12.14, 8.4.2.