ghsa

Schema parsing in the parquet-avro module of Apache Parquet 1.15.0 and previous versions allows bad actors to execute arbitrary code. While 1.15.1 introduced a fix to restrict untrusted packages, the default setting of trusted packages still allows malicious classes from these packages to be executed. The exploit is only applicable if the client code of parquet-avro uses the "specific" or the "reflect" models deliberately for reading Parquet files. ("generic" model is not impacted) Users are recommended to upgrade to 1.15.2 or set the system property "org.apache.parquet.avro.SERIALIZABLE_PACKAGES" to an empty string on 1.15.1. Both are sufficient to fix the issue.

Security policies like [`allowed-gadgets`](https://inspektor-gadget.io/docs/latest/reference/restricting-gadgets), [`disallow-pulling`](https://inspektor-gadget.io/docs/latest/reference/disallow-pulling), [`verify-image`](https://inspektor-gadget.io/docs/latest/reference/verify-assets#verify-image-based-gadgets) can be bypassed by a malicious client. ### Impact Users running `ig` in daemon mode or IG on Kubernetes that rely on any of the features mentioned above are vulnerable to this issue. In order to exploit this, the client needs access to the server, like the correct TLS certificates on the `ig daemon` case or access to the cluster in the Kubernetes case. ### Patches The issue has been fixed in v0.40.0 ### Workarounds There is not known workaround to fix it.

Incorrect access control in the /admin/** API of brcc v1.2.0 allows attackers to gain access to Admin rights via a crafted request.

Cross-Site Scripting (XSS) vulnerability exists in Mezzanine CMS 6.0.0 in the "View Entries" feature within the Forms module.

### Summary A LLM application leveraging `XMLToolMessage` class may be exposed to untrusted XML input that could result in DoS and/or exposing local files with sensitive information. ### Details `XMLToolMessage` uses `lxml` without safeguards: https://github.com/langroid/langroid/blob/df6227e6c079ec22bb2768498423148d6685acff/langroid/agent/xml_tool_message.py#L51-L52 `lxml` is vulnerable to quadratic blowup attacks and processes external entity declarations for local files by default. Check here: https://pypi.org/project/defusedxml/#python-xml-libraries ### PoC A typical Quadratic blowup XML payload looks like this: ```xml <!DOCTYPE bomb [ <!ENTITY a "aaaaaaaaaa"> <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;"> <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;"> ]> <bomb>&c;</bomb> ``` Here, &a; expands to 10 characters, &b; expands to 100, and &c; expands to 1000, causing exponential memory usage and potentially crashing the application. ### Fix Langroid 0.53.4 initializes `XMLParser` with...

### Summary Cross-site scripting (XSS) vulnerability in the [Attributes extension](https://commonmark.thephpleague.com/extensions/attributes/) of the league/commonmark library (versions 1.5.0 through 2.6.x) allows remote attackers to insert malicious JavaScript calls into HTML. ### Details The league/commonmark library provides configuration options such as `html_input: 'strip'` and `allow_unsafe_links: false` to mitigate cross-site scripting (XSS) attacks by stripping raw HTML and disallowing unsafe links. However, when the Attributes Extension is enabled, it introduces a way for users to inject arbitrary HTML attributes into elements via Markdown syntax using curly braces. As a result, even with the secure configuration shown above, an attacker can inject dangerous attributes into applications using this extension via a payload such as: ```md ![](){onerror=alert(1)} ``` Which results in the following HTML: ```html <p><img onerror="alert(1)" src="" alt="" /></p> ``` Which cause...

The fix to https://cantina.xyz/code/c486d600-bed0-4fc6-aed1-de759fd29fa2/findings/21 has a typo that still results in the highest limb of `pc` being range checked to 8-bits instead of 6-bits. In the AIR, we do https://github.com/openvm-org/openvm/blob/0f94c8a3dfa7536c1231465d1bdee5fc607a5993/extensions/rv32im/circuit/src/auipc/core.rs#L135 ``` for (i, limb) in pc_limbs.iter().skip(1).enumerate() { if i == pc_limbs.len() - 1 { ``` It should be ``` for (i, limb) in pc_limbs.iter().enumerate().skip(1) { ``` Right now the if statement is never triggered because the enumeration gives `i=0,1,2` when we instead want `i=1,2,3`. What this means is that `pc_limbs[3]` is range checked to 8-bits instead of 6-bits. This leads to a vulnerability where the `pc_limbs` decomposition differs from the true `pc`, which means a malicious prover can make the destination register take a different value than the AUIPC instruction dictates, by making the decomposition overflow t...

Craft CMS contains a potential remote code execution vulnerability via Twig SSTI. You must have administrator access and `ALLOW_ADMIN_CHANGES` must be enabled for this to work. https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production Note: This is a follow-up to https://github.com/craftcms/cms/security/advisories/GHSA-f3cw-hg6r-chfv Users should update to the patched versions (4.14.13 and 5.6.15) to mitigate the issue. ### References https://github.com/craftcms/cms/pull/17026

**Vulnerable MobSF Versions:** <= v4.3.2 **Details:** MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors. MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack. Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the serv...

# Summary `{field}.isFilterable` access control can be bypassed in `update` and `delete` mutations by adding additional unique filters. These filters can be used as an oracle to probe the existence or value of otherwise unreadable fields. Specifically, when a mutation includes a `where` clause with multiple unique filters (e.g. `id` and `email`), Keystone will attempt to match records even if filtering by the latter fields would normally be rejected by `field.isFilterable` or `list.defaultIsFilterable`. This can allow malicious actors to infer the presence of a particular field value when a filter is successful in returning a result. # Impact This affects any project relying on the default or dynamic `isFilterable` behaviour (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. While this access control is respected during `findMany` operations, it was not completely enforced during `update` and `delete` mutations when...