ghsa

### Impact Some endpoints in the Management API can return stack trace information, even when Umbraco is not in debug mode.

Exposure of Remote Code Execution in Apache Dolphinscheduler. This issue affects Apache DolphinScheduler: before 3.2.2. We recommend users to upgrade Apache DolphinScheduler to version 3.2.2, which fixes the issue.

In Spring Framework versions 5.3.0 - 5.3.38 and older unsupported versions, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) expression that may cause a denial of service (DoS) condition. Older, unsupported versions are also affected. Specifically, an application is vulnerable when the following is true: * The application evaluates user-supplied SpEL expressions.

Missing Authorization When Using @AuthorizeReturnObject in Spring Security 6.3.0 and 6.3.1 allows attacker to render security annotations inaffective.

### Impact A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time. ### Patches This vulnerability has been patched in XWiki 15.10RC1. ### Workarounds No workaround. It is advised to upgrade to XWiki 15.10+. ### References * https://jira.xwiki.org/browse/XWIKI-20331 * https://jira.xwiki.org/browse/XWIKI-21311 * https://jira.xwiki.org/browse/XWIKI-21481 * https://jira.xwiki.org/browse/XWIKI-21482 * https://jira.xwiki.org/browse/XWIKI-21483 * https://jira.xwiki.org/browse/XWIKI-21484 * https://jira.xwiki.org/browse/XWIKI-21485 * https://jira.xwiki.org/browse/XWIKI-21486 * https://jira.xwiki.org/browse/XWIKI-21487 * https://jira.xwiki.org/browse/XWIKI-21488 * https://jira.xwiki.org/browse/XWIKI-21489 * https://jira.xwiki.org/browse/XWIKI-21490 ### ...

### Impact Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL. #### Reproduction steps 1. As a user without script or programming right, create a (non-terminal) document named `" + alert(1) + "` (the quotes need to be part of the name). 1. Edit the class. 1. Add a string property named `"test"`. 1. Edit using the object editor and add an object of the created class 1. Get an admin to open `<xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit` where `<xwiki-server>` is the URL of your XWiki installation. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References - https://jira.xwiki.org/browse/XWIKI-21810 - https://github.com/xwiki/xwiki-plat...

### Summary Upon reviewing the MobSF source code, I identified a flaw in the Static Libraries analysis section. Specifically, during the extraction of .a extension files, the measure intended to prevent Zip Slip attacks is improperly implemented. Since the implemented measure can be bypassed, the vulnerability allows an attacker to extract files to any desired location within the server running MobSF. ### Details Upon examining lines 183-192 of the `mobsf/StaticAnalyzer/views/common/shared_func.py` file, it is observed that there is a mitigation against Zip Slip attacks implemented as `a.decode('utf-8', 'ignore').replace('../', '').replace('..\\', '')`. However, this measure can be bypassed using sequences like `....//....//....//`. Since the replace operation is not recursive, this sequence is transformed into `../../../` after the replace operation, allowing files to be written to upper directories. <img width="448" alt="image" src="https://github.com/user-attachments/assets/fadf...

### Impact The fugit "natural" parser, that turns "every wednesday at 5pm" into "0 17 * * 3", accepted any length of input and went on attempting to parse it, not returning promptly, as expected. The parse call could hold the thread with no end in sight. Fugit dependents that do not check (user) input length for plausability are impacted. ### Patches Problem was reported in #104 and the fix was released in [fugit 1.11.1](https://rubygems.org/gems/fugit/versions/1.11.1) ### Workarounds By making sure that `Fugit.parse(s)`, `Fugit.do_parse(s)`, `Fugit.parse_nat(s)`, `Fugit.do_parse_nat(s)`, `Fugit::Nat.parse(s)`, and `Fugit::Nat.do_parse(s)` are not fed strings too long. 1000 chars feels ok, while 10_000 chars makes it stall. In fewer words, making sure those fugit methods are not fed unvetted input strings. ### References gh-104

### Impact _What kind of vulnerability is it? Who is impacted?_ This vulnerability allows a malicious actor to craft data in a way that, when scanned by specific detectors, could trigger the detector to make an unauthorized request to an endpoint chosen by the attacker. For an exploit to be effective, the target endpoint must be an unauthenticated GET endpoint that produces side effects. The victim must scan the maliciously crafted data and have such an endpoint targeted for the exploit to succeed. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The vulnerability has been resolved in TruffleHog v3.81.9 and later versions. Users should upgrade to this or a more recent version to mitigate the issue. _Special thanks to Karan Bamal, Security Researcher at Sentinel One for this discovery_

The following presentation at this year's DEF CON was brought to our attention on the SQLx Discord: > SQL Injection isn't Dead: Smuggling Queries at the Protocol Level > <http://web.archive.org/web/20240812130923/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn't%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf> > (Archive link for posterity.) Essentially, encoding a value larger than 4GiB can cause the length prefix in the protocol to overflow, causing the server to interpret the rest of the string as binary protocol commands or other data. It appears SQLx _does_ perform truncating casts in a way that could be problematic, for example: <https://github.com/launchbadge/sqlx/blob/6f2905695b9606b5f51b40ce10af63ac9e696bb8/sqlx-postgres/src/arguments.rs#L163> This code has existed essentially since the beginning, so it is reasonable to assume that all published versions `<= 0.8.0` a...