ghsa

### Impact Any user with edit rights on a document can trigger a XAR import on a forged XAR file, leading to the ability to display the content of any file on the XWiki server host. Example to reproduce: * Create a forget XAR file and inside it, have the following `package.xml` content: ```xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <package> <infos> <name>&xxe;</name> <description> &xxe; Helper pages for creating and listing Class/Template/Sheets</description> <licence></licence> <author>XWiki.Admin</author> ... ``` * Upload it onto a wiki page (e.g. `XXE`) as an attachment (e.g. `test.xar`). * Call the page using `http://localhost:8080/xwiki/bin/view/Main/XXE?sheet=XWiki.AdminImportSheet&file=test.xar` You'll then notice that the displayed UI contains the content of the `/etc/passwd` file. ### Patches The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1. ### Workarounds You'd...

### Impact Any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of UIX parameters A proof of concept exploit is to log in, add an `XWiki.UIExtensionClass` xobject to the user profile page, with an Extension Parameters content of: ``` order=100 label={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} icon=icon:pencil target=XWiki.username ``` Then, navigating to `PanelsCode.ApplicationsPanelConfigurationSheet` (i.e., `<xwiki-host>/xwiki/bin/view/PanelsCode/ApplicationsPanelConfigurationSheet` where `<xwiki-host>` is the URL of your XWiki installation) should not execute the Groovy script. If it does, you will see `Hello from groovy!` displayed on the screen. ### Patches The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1 ### Workarounds The issue can be ...

### Impact Users with read access to the `password` field in `directus_users` can extract the argon2 password hashes by brute forcing the export functionality combined with a `_starts_with` filter. This allows the user to enumerate the password hashes. ### Patches The problem has been patched by preventing any hashed/concealed field to be filtered against with the `_starts_with` or other string operator. ### Workarounds Ensuring that no user has `read` access to the `password` field in `directus_users` is sufficient to prevent this vulnerability. ### For more information If you have any questions or comments about this advisory: * Open a Discussion in [directus/directus](https://github.com/directus/directus/discussions/new) * Email us at [[email protected]](mailto:[email protected])

A deserialization vulnerability existed when dubbo generic invoke, which could lead to malicious code execution. This issue affects Apache Dubbo 2.7.x version 2.7.21 and prior versions; Apache Dubbo 3.0.x version 3.0.13 and prior versions; Apache Dubbo 3.1.x version 3.1.5 and prior versions.

Use of Hard-coded Credentials in GitHub repository alextselegidis/easyappointments 1.4.3 and prior. A patch is available and anticipated to be part of version 1.5.0.

### Impact OWSLib's XML parser (which supports both `lxml` and `xml.etree`) does not disable entity resolution, and could lead to arbitrary file reads from an attacker-controlled XML payload. This affects all XML parsing in the codebase. ### Patches This issue is patched in 0.28.1. ### Workarounds The patch approach should be: - update all XML support as follows: - use ONLY `lxml.etree` - apply the patch below ```python patch_well_known_namespaces(etree) etree.set_default_parser( parser=etree.XMLParser(resolve_entities=False) ) ``` ### References - `GHSL-2022-131`

### Impact ZipSlip issue when use fsutil package to unzip files. When users use fsutil.Unzip to unzip zip files from a malicious attacker, they may be vulnerable to path traversal. ### Patches It has been fixed in v0.6.0, Please upgrade version to v0.6.0 or above. ### Workarounds No, users have to upgrade version.

### Impact Instances relying on an allow-listed reset URL are vulnerable to an HTML injection attack through the use of query parameters in the reset URL. ### Patches The problem has been resolved and released under version 9.23.0. People relying on a custom password reset URL should upgrade to 9.23.0 or later, or remove the custom reset url from the configured allow list. ### Workarounds Disable the custom reset URL allow list.

`maligned::align_first` manually allocates with an alignment larger than T, and then uses `Vec::from_raw_parts` on that allocation to get a `Vec<T>`. [`GlobalAlloc::dealloc`](https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#tymethod.dealloc) requires that the `layout` argument must be the same layout that was used to allocate that block of memory. When deallocating, `Box` and `Vec` may not respect the specified alignment and can cause undefined behavior.

When the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. ``` buildctl build --frontend dockerfile.v0 --context https://<credentials>@url/repo.git ``` Equivalent in `docker buildx` would be ``` docker buildx build https://<credentials>@url/repo.git ``` 2) If the client sends additional VCS info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from `.git/config` file. Thanks to Oscar Alberto Tovar for discovering the issue. ### Impact When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previou...