ghsa

Critical severity. Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.

Critical severity. Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.

Critical severity. Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.

Critical severity. Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.

Critical severity. It is possible to inject JavaScript XSS in the content type entries "name" and "short name". To exploit this, one must already have permission to edit content types, which limits it in many cases to people who are already administrators. However, please verify which users have this permission. The fix ensures any injections are escaped.

### Impact Unauthenticated GraphQL queries for user accounts can expose password hashes of users that have created or modified content, typically but not necessarily limited to administrators and editors. ### Patches Resolving versions: Ibexa DXP v1.0.13, v2.3.12 ### Workarounds Remove the "passwordHash" entry from "src/bundle/Resources/config/graphql/User.types.yaml" in the GraphQL package, and other properties like hash type, email, login if you prefer. ### References This issue was reported to us by Philippe Tranca ("trancap") of the company Lexfo. We are very grateful for their research, and responsible disclosure to us of this critical vulnerability. ### For more information If you have any questions or comments about this advisory, please contact Support via your service portal.

It is possible to inject JavaScript XSS in the content type entries "name" and "short name". To exploit this, one must already have permission to edit content types, which limits it in many cases to people who are already administrators. However, please verify which users have this permission. The fix ensures any injections are escaped.

### Impact Unauthenticated GraphQL queries for user accounts can expose password hashes of users that have created or modified content, typically but not necessarily limited to administrators and editors. ### Patches Affected versions: Ibexa DXP v3.3.\*, v4.2.\*, eZ Platform v2.5.\* Resolving versions: Ibexa DXP v3.3.28, v4.2.3, eZ Platform v2.5.31 ### Workarounds Remove the "passwordHash" entry from "src/bundle/Resources/config/graphql/User.types.yaml" in the GraphQL package, and other properties like hash type, email, login if you prefer. ### References This issue was reported to us by Philippe Tranca ("trancap") of the company Lexfo. We are very grateful for their research, and responsible disclosure to us of this critical vulnerability. ### For more information If you have any questions or comments about this advisory, please contact Support via your service portal.

### Impact People who use some older NLP examples that reference the old S3 bucket. ### Patches The problem has been patched. Upgrade to snapshots for now. A release will be published later to address this due to the vulnerability mostly being examples and 1 class in the actual code base. ### Workarounds Download a word2vec google news vector from a new source using git lfs

### Impact There is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. The pooling instance allocator in Wasmtime works by preallocating virtual memory for a fixed number of instances to reside in and then new instantiations pick a slot to use. Most conventional modules additionally have an initial copy-on-write "heap image" which is mapped in Wasmtime into the linear memory slot. When a heap slot is deallocated Wasmtime resets all of its contents back to the initial state but it does not unmap the image in case the next instance is an instantiation of the same module. The bug in Wasmtime occurs when a slot in the pooling allocator previously was used for a module with a heap image, meaning that its current state of memory contains the initial heap contents of that module. If the next instantiation within that sl...