ghsa

# Microsoft Security Advisory CVE-2023-36558: .NET Security Feature Bypass Vulnerability ## <a name="executive-summary"></a>Executive summary Microsoft is releasing this security advisory to provide information about a vulnerability in ASP.NET Core 6.0, ASP.NET Core 7.0 and, ASP.NET Core 8.0 RC2. This advisory also provides guidance on what developers can do to update their applications to address this vulnerability. A security feature bypass vulnerability exists in ASP.NET where an unauthenticated user is able to bypass validation on Blazor server forms which could trigger unintended actions. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/288 ### <a name="mitigation-factors"></a>Mitigation factors This vulnerability only affects ASP.NET Core Blazor apps. Other application types, including ASP.NET Core apps which do not utilize Blazor, are not affected. ## <a name="affected-software"></a>Affected software * Any ASP...

### Impact Aiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and lo...

> ### 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)