ghsa

Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ. During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections. This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected. Users are recommended to upgrade to version 6.1.6+, 5.19.0+, 5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue. Existing users may implement mutual TLS to mitigate the risk on affected brokers.

### Overview This vulnerability allows an attacker to impersonate any user during SAML authentication by tampering with a valid SAML response. This can be done by adding attributes to the response. ### Am I Affected? You are affected by this SAML Attribute Smuggling vulnerability if you are using `passport-wsfed-saml2` version 4.6.3 or below, specifically under the following conditions: 1. The service provider is using `passport-wsfed-saml2`, 2. A valid SAML Response signed by the Identity Provider can be obtained ### Fix Upgrade to v4.6.4 or greater.

### Overview This vulnerability allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP. ### Am I Affected? You are affected by this SAML Signature Wrapping vulnerability if you are using `passport-wsfed-saml2` version 4.6.3 or below, specifically under the following conditions: 1. The service provider is using `passport-wsfed-saml2`, 2. A valid SAML document signed by the Identity Provider can be obtained. ### Fix Upgrade to v4.6.4 or greater.

ffi::nstr() should be marked unsafe, since a pointer to a buffer without a trailing 0 value will cause a heap buffer overflow.

A flaw was found in the JBoss EAP Management Console, where a stored Cross-site scripting vulnerability occurs when an application improperly sanitizes user input before storing it in a data store. When this stored data is later included in web pages without adequate sanitization, malicious scripts can execute in the context of users who view these pages, leading to potential data theft, session hijacking, or other malicious activities. ### Impact Cross-site scripting (XSS) vulnerability in the management console. ### Patches Fixed in [HAL 3.7.11.Final](https://github.com/hal/console/releases/tag/v3.7.11) ### Workarounds No workaround available

A reflected cross-site scripting (XSS) vulnerability in the Liferay Portal 7.4.0 through 7.4.3.131, and Liferay DXP 2024.Q4.0 through 2024.Q4.5, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.12, 7.4 GA through update 92 allows an remote non-authenticated attacker to inject JavaScript into the modules/apps/marketplace/marketplace-app-manager-web.

### Impact ZITADEL offers developers the ability to manage user sessions using the [Session API](https://zitadel.com/docs/category/apis/resources/session_service_v2/session-service). This API enables the use of IdPs for authentication, known as idp intents. Following a successful idp intent, the client receives an id and token on a predefined URI. These id and token can then be used to authenticate the user or their session. However, it was possible to exploit this feature by repeatedly using intents. This allowed an attacker with access to the application’s URI to retrieve the id and token, enabling them to authenticate on behalf of the user. It’s important to note that the use of additional factors (MFA) prevents a complete authentication process and, consequently, access to the ZITADEL API. ### Patches 3.x versions are fixed on >=[3.0.0](https://github.com/zitadel/zitadel/releases/tag/v3.0.0) 2.71.x versions are fixed on >=[2.71.9](https://github.com/zitadel/zitadel/releases/t...

### Summary It seems that when running **goshs** without arguments it is possible for anyone to execute commands on the server. This was tested on version **1.0.4** of **goshs**. The command function was introduced in version **0.3.4**. ### Details It seems that the function ```dispatchReadPump``` does not checks the option cli ```-c```, thus allowing anyone to execute arbitrary command through the use of websockets. ### PoC Used **websocat** for the POC: ```bash echo -e '{"type": "command", "content": "id"}' |./websocat 'ws://192.168.1.11:8000/?ws' -t ``` ### Impact The vulnerability will only impacts goshs server on vulnerable versions.

The following functions in the `tanton_engine` crate are unsound due to lack of sufficient boundary checks in public API: - `Stack::offset()` - `ThreadStack::get()` - `RootMoveList::insert_score_depth()` - `RootMoveList::insert_score()` The tanton_engine crate is no longer maintained, so there are no plans to fix this issue.

### Summary Due to a validation error in `got.scpaping`, it is possible to use an HTTP redirect to avoid IP filtering. ### Details In `got.scpaping`, Summaly first makes a HTTP `HEAD` request to the page being summarized. It then preforms private IP address checks on the `HEAD` response, then makes an additional HTTP `GET` request to the page being summarized. Unfortunately, since private IP address checks aren't performed on the `GET` response, the `GET` response can issue a HTTP redirect to a private IP address, which will succeed, regardless of if private IP addresses are allowed by Summaly. ### PoC With a simple Caddy webserver, you can get Summaly to summarize a page hosted via a local IP address: ```caddy @summaly-bypass-head { method HEAD path /summaly-bypass } @summaly-bypass-get { method GET path /summaly-bypass } header @summaly-bypass-head Content-Type "text/html" respond @summaly-bypass-head 200 redir @summaly-bypass-get http://127.0.0.1:3080/ ``` ### Imp...