ghsa

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

### Impact This vulnerability only impacts versions `v2` and lower. An insecure temporary creation of a file allows other actors on the Actions runner to replace the Kubectl binary created by this action because it is world writable. This Kubectl tool installer runs `fs.chmodSync(kubectlPath, 777)` to set permissions on the Kubectl binary, however, this allows any local user to replace the Kubectl binary. This allows privilege escalation to the user that can also run kubectl, most likely root. This attack is only possible if an attacker somehow breached the GitHub actions runner or if a user is utilizing an Action that maliciously executes this attack. No impacted customers have been reported. ### Patches This has been fixed and released in all versions `v3` and later. 755 permissions are used instead. ### Workarounds If users absolutely cannot upgrade to `v3` or higher than they should be extra diligent of the other GitHub actions they are using in a workflow and ensure that the...

### Impact There is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the indices that back data streams potentially leading to incorrect access authorization. This issue can only be triggered by authenticated users authorized to read those data streams which are backed by the impacted indexes. Additionally, existing privileged users cannot access random indexes within these clusters; they can only access indexes to which they have already been granted permission. ### Patches OpenSearch 1.3.7 and 2.4.0 contain a fix for this issue. ### Workarounds There is no recommended work around. ### For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do not create a ...