ghsa

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

### Impact There is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator. This bug can only be triggered by setting `InstanceLimits::memory_pages` to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm mo...

mm-wki v0.2.1 is vulnerable to Cross Site Scripting (XSS).

### Impact This vulnerability allowed a malicious user to serve arbitrary HTML files from the main application domain (readthedocs[.]org/readthedocs[.]com) by exploiting a vulnerability in the code that serves downloadable content from a project. Exploiting this would have required the attacker to get a logged-in user to visit the malicious URL, which would have allowed the attacker to take control of the user's session with JavaScript (making requests to the API/site on behalf of the user). This URL would have looked something like `hxxps[:]//readthedocs[.]org/projects/attacker-project/downloads/html/version-with-javascript-attack/`. ### Patches This issue has been patched in our 8.8.1 release.

# Impact _What kind of vulnerability is it? Who is impacted?_ This is an API vulnerability in Redwood's [dbAuth], specifically the dbAuth forgot password feature: - only projects with the dbAuth "forgot password" feature are affected - this vulnerability was introduced in v0.38.0 ## User Accounts are Vulnerable to Takeover (Hijacking) A reset token for any user can be obtained given knowledge of their username or email via the forgot-password API. With the leaked reset token, a malicious user could request to reset a user's password, changing their credentials and gaining access to their account. ## How to Determine if Projects have been Attacked To determine if a project has been attacked, we recommend checking logs for suspicious activity; namely, the volume of requests to the forgot-password API using emails that don't exist. Another indication is if users inform you that they can't access their accounts. If you have question or concerns, reach out via the "For More Informati...