Source
ghsa
> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C` (4.9) ### Problem It has been discovered that observing response time during user authentication (backend and frontend) can be used to distinguish between existing and non-existing user accounts. Extension authors of 3rd party TYPO3 extensions providing a custom authentication service should check if the extension is affected by the described problem. Affected extensions must implement new `MimicServiceInterface::mimicAuthUser`, which simulates corresponding times regular processing would usually take. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team members Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-007](https://typo3.org/security/advisory/typo3-core-sa-2022-007) * [Vulnerability Report on huntr.dev](htt...
> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the expiration time of a password reset link for TYPO3 backend users has never been evaluated. As a result, a password reset link could be used to perform a password reset even if the default expiry time of two hours has been exceeded. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Ingo Fabbri who reported this issue and to TYPO3 security team member Torben Hansen who fixed the issue. ### References * [TYPO3-CORE-SA-2022-008](https://typo3.org/security/advisory/typo3-core-sa-2022-008)
> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.0) ### Problem It has been discovered that the `FileDumpController` (backend and frontend context) is vulnerable to cross-site scripting when malicious files are displayed using this component. A valid backend user account is needed to exploit this vulnerability. ### Solution Update to TYPO3 version 7.6.58 ELTS, 8.7.48 ELTS, 9.5.37 ELTS, 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to Vautia who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-009](https://typo3.org/security/advisory/typo3-core-sa-2022-009) * [Vulnerability Report on huntr.dev](https://huntr.dev/bounties/51e9b709-193c-41fd-bd4a-833aaca0bd4e/) (embargoed +30 days)
> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (4.1) ### Problem It has been discovered that the `f:asset.css` view helper is vulnerable to cross-site scripting when user input is passed as variables to the CSS. ### Solution Update to TYPO3 version 10.4.32 or 11.5.16 that fix the problem described above. ### Credits Thanks to TYPO3 contributor member Frank Nägler who reported this issue and to TYPO3 core & security team member Oliver Hader who fixed the issue. ### References * [TYPO3-CORE-SA-2022-010](https://typo3.org/security/advisory/typo3-core-sa-2022-010)
The maintainer seems unreachable. The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust. The last release seems to have been seven years ago.
Crate `traitobject` has not had a release for over five years. In addition there is an existing security advisory that has not been addressed: - [RUSTSEC-2020-0027](https://rustsec.org/advisories/RUSTSEC-2020-0027) ## Possible Alternative(s) The below list has not been vetted in any way and may or may not contain alternatives; - [destructure_traitobject] [destructure_traitobject]: https://crates.io/crates/destructure_traitobject
The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could corrupt arbitary files when Cargo downloaded the package. The severity of this vulnerability is "low" for users of alternate registries. Users relying on crates.io are not affected. Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. ## Arbitrary file corruption After a package is downloaded, Cargo extracts its source code in the `~/.cargo` folder on disk, making it available to the Rust projects it builds. To record when an extraction i...
The Rust Security Response WG was notified that Cargo did not prevent extracting some malformed packages downloaded from alternate registries. An attacker able to upload packages to an alternate registry could fill the file system when Cargo downloaded the package. The severity of this vulnerability is "low" for users of alternate registries. Users relying on crates.io are not affected. Note that **by design** Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. ## Disk space exaustion It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extr...
OSU Open Source Lab VNCAuthProxy through 1.1.1 is affected by an vncap/vnc/protocol.py VNCServerAuthenticator authentication-bypass vulnerability that could allow a malicious actor to gain unauthorized access to a VNC session or to disconnect a legitimate user from a VNC session. A remote attacker with network access to the proxy server could leverage this vulnerability to connect to VNC servers protected by the proxy server without providing any authentication credentials. Exploitation of this issue requires that the proxy server is currently accepting connections for the target VNC server.
### Impact All rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects (class and property name must be known, though). This is also exploitable on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki). ### Patches This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. ### Workarounds It would be possible to protect all templates individually by adding code to check access rights first, but due to the number of templates and the fact that some of them need to be used without view rights, this seems impractical. ### References * https://jira.xwiki.org/browse/XWIKI-19549 * https://jira.xwiki.org/browse/XWIKI-18602 ##...