Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-wcg9-pgqv-xm5v: XWiki Platform allows XSS through XClass name in string properties

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

ghsa
#xss#web#git#java#jira#maven
GHSA-4hh3-vj32-gr6j: Mobile Security Framework (MobSF) has a Zip Slip Vulnerability in .a Static Library Files

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

GHSA-2m96-52r3-2f3g: fugit parse and parse_nat stall on lengthy input

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

GHSA-3r74-v83p-f4f4: Trufflehog vulnerable to Blind SSRF in some Detectors

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

GHSA-xmrp-424f-vfpx: SQLx Binary Protocol Misinterpretation caused by Truncating or Overflowing Casts

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...

GHSA-rv9v-r4vm-gj8x: Miniscript allows stack consumption

The Miniscript (aka rust-miniscript) library before 12.2.0 for Rust allows stack consumption because it does not properly track tree depth.

GHSA-r6ph-5fp2-3w2v: Microcks's POST /api/import and POST /api/export endpoints allow non-administrator access

In Microcks before 1.10.0, the POST /api/import and POST /api/export endpoints allow non-administrator access.

GHSA-hxwh-jpp2-84pm: Flask-CORS allows the `Access-Control-Allow-Private-Network` CORS header to be set to true by default

A vulnerability in corydolphin/flask-cors version 4.0.1 allows the `Access-Control-Allow-Private-Network` CORS header to be set to true by default, without any configuration option. This behavior can expose private network resources to unauthorized external access, leading to significant security risks such as data breaches, unauthorized access to sensitive information, and potential network intrusions.

GHSA-h6jq-w432-j26w: Silverpeas vulnerable to password complexity rule bypass

An issue in the password change function of Silverpeas v6.4.2 and lower allows for the bypassing of password complexity requirements.

GHSA-vwf8-q6fw-4wcm: Cilium leaks information via incorrect ReferenceGrant update logic in Gateway API

### Impact Due to ReferenceGrant changes not being immediately propagated in Cilium's GatewayAPI controller, Gateway resources are able to access secrets in other namespaces after the associated ReferenceGrant has been revoked. This can lead to Gateways continuing to establish sessions using secrets that they should no longer have access to. ### Patches This issue was resolved in https://github.com/cilium/cilium/pull/34032. This issue affects: - Cilium v1.15 between v1.15.0 and v1.15.7 inclusive - Cilium v1.16.0 This issue has been patched in: - Cilium v1.15.8 - Cilium v1.16.1 ### Workarounds Any modification of a related Gateway/HTTPRoute/GRPCRoute/TCPRoute CRD (for example, adding any label to any of these resources) will trigger a reconciliation of ReferenceGrants on an affected cluster. ### Acknowledgements The Cilium community has worked together with members of Cure53 and Isovalent to prepare these mitigations. Special thanks to @sayboras for resolving this issue. ###...