ghsa

Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 9.11.x <= 9.11.17, 10.10.x <= 10.10.0, 10.9.x <= 10.9.3 fail to validate import data which allows a system admin to crash the server via the bulk import feature.

Username enumeration vulnerability in Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.14 and 7.4 GA through update 92 allows attackers to determine if an account exist in the application by inspecting the server processing time of the login request.

Mattermost versions 10.8.x <= 10.8.3, 10.5.x <= 10.5.8, 10.10.x <= 10.10.0, 10.9.x <= 10.9.3 fail to sanitize file names which allows users with file upload permission to overwrite file attachment thumbnails via path traversal in file streaming APIs.

A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.0 t through 7.4.3.132, and Liferay DXP 2025.Q2.0, 2025.Q1.0 through 2025.Q1.13, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.17 and 7.4 GA through update 92 allows an remote authenticated attacker to inject JavaScript into the _com_liferay_layout_admin_web_portlet_GroupPagesPortlet_type parameter.

A reflected cross-site scripting (XSS) vulnerability in the Liferay Portal 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.15, 2025.Q2.0 through 2025.Q2.2 and 2024.Q1.13 through 2024.Q1.19 allows a remote authenticated user to inject JavaScript code via snippet parameter.

A flaw was found in org.keycloak/keycloak-model-storage-service. The KeycloakRealmImport custom resource substitutes placeholders within imported realm documents, potentially referencing environment variables. This substitution process allows for injection attacks when crafted realm documents are processed. An attacker can leverage this to inject malicious content during the realm import procedure. This can lead to unintended consequences within the Keycloak environment.

### Impact Due to improper Cross-Origin Resource Sharing (CORS) configuration, there is a risk that user API Keys or equivalent credentials may be exposed to untrusted domains. Attackers could exploit this misconfiguration to steal credentials, abuse accounts, exhaust quotas, or access sensitive data. ### Patches The issue has been patched in v1.0.34.

### Summary Files not included in `src` was possible to access with a crafted request. ### Impact Only apps explicitly exposing the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) are affected. Arbitrary files can be disclosed by exploiting this vulnerability. ### Details Consider the following configuration in used by `vite.config.ts`: ```ts import { defineConfig } from 'vite' import { viteStaticCopy } from 'vite-plugin-static-copy' export default defineConfig({ plugins: [ viteStaticCopy({ targets: [ { src: "./public/images", dest: "./", }, ], }), ], }); ``` The files under the `./public/images` is only expected to be served. Abusing this vulnerability, an attacker can access arbitrary files on the filesystem. ### PoC I've attached a demo app to showcase the bug. Run it with `npm run dev` and issue the foll...

### Summary This is the same as [GHSA-cpq7-6gpm-g9rc](https://github.com/browserify/cipher-base/security/advisories/GHSA-cpq7-6gpm-g9rc) but just for `sha.js`, as it has its own implementation. Missing input type checks lead to it calculating invalid values, hanging, rewinding the hash state (including turning a tagged hash into an untagged hash) on malicious JSON-stringifyable input ### Details See PoC ### PoC ```js const forgeHash = (data, payload) => JSON.stringify([payload, { length: -payload.length}, [...data]]) const sha = require('sha.js') const { randomBytes } = require('crypto') const sha256 = (...messages) => { const hash = sha('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') } const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e.g. over network, whatever console.log(sha256...

### Summary This affects e.g. `create-hash` (and `crypto-browserify`), so I'll describe the issue against that package Also affects `create-hmac` and other packages Node.js `createHash` works only on strings or instances of Buffer, TypedArray, or DataView. Missing input type checks in npm `create-hash` polyfill of Node.js `createHash` lead to it calculating invalid values, hanging, rewinding the hash state (including turning a tagged hash into an untagged hash) on malicious JSON-stringifyable input ### Details See PoC ### PoC ```js const createHash = require('create-hash/browser.js') const { randomBytes } = require('crypto') const sha256 = (...messages) => { const hash = createHash('sha256') messages.forEach((m) => hash.update(m)) return hash.digest('hex') } const validMessage = [randomBytes(32), randomBytes(32), randomBytes(32)] // whatever const payload = forgeHash(Buffer.concat(validMessage), 'Hashed input means safe') const receivedMessage = JSON.parse(payload) // e....