Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-5p5r-57fx-pmfr: Langflow vulnerable to remote code execution

langflow <=1.0.18 is vulnerable to Remote Code Execution (RCE) as any component provided the code functionality and the components run on the local machine rather than in a sandbox.

ghsa
#vulnerability#web#mac#rce#auth
GHSA-g5vw-3h65-2q3v: Access control vulnerable to user data deletion by anonynmous users

### Impact Anonymous users can delete the user data maintained by an `AccessControl.userfolder.UserFolder` which may prevent any privileged access. ### Patches The problem is fixed in version 7.2. ### Workarounds The problem can be fixed by adding `data__roles__ = ()` to `AccessControl.userfolder.UserFolder`. ### References https://github.com/zopefoundation/AccessControl/issues/159

GHSA-3hxg-fxwm-8gf7: CRLF injection in Refit's [Header], [HeaderCollection] and [Authorize] attributes

### Summary The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection. ### Details The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method: <https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328> This method does not check for CRLF characters in the header value. This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. ### PoC The below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the "Authorization" header: ```c# using Refit; internal class Program { private static void Main(string[] args) { ...

GHSA-82j3-hf72-7x93: Reposilite vulnerable to path traversal while serving javadoc expanded files (arbitrary file read) (`GHSL-2024-074`)

### Summary Reposilite v3.5.10 is affected by an Arbitrary File Read vulnerability via path traversal while serving expanded javadoc files. ### Details The problem lies in the way how the expanded javadoc files are served. The `GET /javadoc/{repository}/<gav>/raw/<resource>` route uses the `<resource>` path parameter to find the file in the `javadocUnpackPath` directory and returns it's content to the user. [JavadocFacade.kt#L77](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocFacade.kt#L77): ```kotlin fun findRawJavadocResource(request: JavadocRawRequest): Result<JavadocRawResponse, ErrorResponse> = with (request) { mavenFacade.canAccessResource(accessToken, repository, gav) .flatMap { javadocContainerService.loadContainer(accessToken, repository, gav) } .filter({ Files.exists(it.javadocUnpackPath.resolve(resource.toString())) }, { notFound("Resourc...

GHSA-29wx-vh33-7x7r: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations

### Summary Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. ### Fix We have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. ### Workaround We are aware that this changes the behaviour of an established funct...

GHSA-7vm6-qwh5-9x44: loona-hpack Panic Vulnerability

### Summary `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in https://github.com/mlalic/hpack-rs/issues/11 ### Details The original includes a very nice description of the problem, as well as an easy-enough fix for it. ### PoC The original example pretty much still applies: ```rust use loona_hpack::Decoder; pub fn main() { let input = &[0x3f]; let mut decoder = Decoder::new(); let _ = decoder.decode(input); } ``` ### Impact From the original: `All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. A patched version of the crate is available on [crates.io](https://crates.io/crates/hpack-patched) under the name hpack-patched. See [Cargo's documentation on overriding dependencies](https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html) for more information.`

GHSA-r7mv-mv7m-pjw3: hornetq vulnerable to file overwrite, sensitive information disclosure

An issue in the `createTempFile` method of hornetq v2.4.9 allows attackers to arbitrarily overwrite files or access sensitive information.

GHSA-752q-72qc-rc66: Apache Kylin Session Fixation vulnerability

Session Fixation vulnerability in Apache Kylin. This issue affects Apache Kylin: from 2.0.0 through 4.x. Users are recommended to upgrade to version 5.0.0 or above, which fixes the issue.

GHSA-q3rp-vvm7-j8jg: Safearchive Path Traversal vulnerability

There exists a Path Traversal vulnerability in Safearchive on Platforms with Case-Insensitive Filesystems (e.g., NTFS). This allows Attackers to Write Arbitrary Files via Archive Extraction containing symbolic links. We recommend upgrading past commit f7ce9d7b6f9c6ecd72d0b0f16216b046e55e44dc

GHSA-4gmq-m9vp-jrwg: Umbraco CMS Cross-site Scripting vulnerability

A vulnerability was found in Umbraco CMS 12.3.6. It has been classified as problematic. Affected is an unknown function of the file /Umbraco/preview/frame?id{} of the component Dashboard. The manipulation of the argument culture leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.