#vulnerability

There is a possible ReDoS vulnerability in Action Controller's HTTP Token authentication. This vulnerability has been assigned the CVE identifier CVE-2024-47887. Impact ------ For applications using HTTP Token authentication via `authenticate_or_request_with_http_token` or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected. Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- Users on Ruby 3.2 are unaffected by this issue. Credits ------- Thanks to [scyoon](https://hackerone.com/scyoon) for reporting

There is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-41128. Impact ------ Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or apply the relevant patch immediately. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected. Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- Users on Ruby 3.2 are unaffected by this issue. Credits ------- Thanks to [scyoon](https://hackerone.com/scyoon) for the report and patches!

A security issue was discovered in the Kubernetes Image Builder versions <= v0.1.37 where default credentials are enabled during the image build process when using the Nutanix, OVA, QEMU or raw providers. The credentials can be used to gain root access. The credentials are disabled at the conclusion of the image build process. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project. Because these images were vulnerable during the image build process, they are affected only if an attacker was able to reach the VM where the image build was happening and used the vulnerability to modify the image at the time the image build was occurring.

A security issue was discovered in the Kubernetes Image Builder versions <= v0.1.37 where default credentials are enabled during the image build process. Virtual machine images built using the Proxmox provider do not disable these default credentials, and nodes using the resulting images may be accessible via these default credentials. The credentials can be used to gain root access. Kubernetes clusters are only affected if their nodes use VM images created via the Image Builder project with its Proxmox provider.

### Summary Starlette treats `multipart/form-data` parts without a `filename` as text form fields and buffers those in byte strings with no size limit. This allows an attacker to upload arbitrary large form fields and cause Starlette to both slow down significantly due to excessive memory allocations and copy operations, and also consume more and more memory until the server starts swapping and grinds to a halt, or the OS terminates the server process with an OOM error. Uploading multiple such requests in parallel may be enough to render a service practically unusable, even if reasonable request size limits are enforced by a reverse proxy in front of Starlette. ### PoC ```python from starlette.applications import Starlette from starlette.routing import Route async def poc(request): async with request.form(): pass app = Starlette(routes=[ Route('/', poc, methods=["POST"]), ]) ``` ```sh curl http://localhost:8000 -F 'big=</dev/urandom' ``` ### Impact This Denial of ...

### Impact matrix-react-sdk before 3.102.0 allows a malicious homeserver to potentially steal message keys for a room when a user invites another user to that room, via injection of a malicious device controlled by the homeserver. This is possible because matrix-react-sdk before 3.102.0 shared historical message keys on invite. ### Patches matrix-react-sdk 3.102.0 [disables sharing message keys on invite](https://github.com/matrix-org/matrix-react-sdk/pull/12618) by removing calls to the vulnerable functionality. ### Workarounds None. ### References The vulnerability in matrix-react-sdk is caused by calling `MatrixClient.sendSharedHistoryKeys` in matrix-js-sdk, which is inherently vulnerable to this sort of attack. This matrix-js-sdk vulnerability is tracked as CVE-2024-47080 / [GHSA-4jf8-g8wp-cx7c](https://github.com/matrix-org/matrix-js-sdk/security/advisories/GHSA-4jf8-g8wp-cx7c). Given that this functionality is not specific to sharing message keys on *invite*, is optional, ...

### Impact In matrix-js-sdk versions 9.11.0 through 34.7.0, the method `MatrixClient.sendSharedHistoryKeys` is vulnerable to interception by malicious homeservers. The method implements functionality proposed in [MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061) and can be used by clients to share historical message keys with newly invited users, granting them access to past messages in the room. However, it unconditionally sends these "shared" keys to all of the invited user's devices, regardless of whether the user's cryptographic identity is verified or whether the user's devices are signed by that identity. This allows the attacker to potentially inject its own devices to receive sensitive historical keys without proper security checks. Note that this only affects clients running the SDK with the legacy crypto stack. Clients using the new Rust cryptography stack (i.e. those that call `MatrixClient.initRustCrypto()` instead of `MatrixClient.initCrypto()`) ar...

### Summary A Server Side Template Injection in changedetection.io caused by usage of unsafe functions of Jinja2 allows Remote Command Execution on the server host. ### Details changedetection.io version: 0.45.20 ``` docker images REPOSITORY TAG IMAGE ID CREATED SIZE dgtlmoon/changedetection.io latest 53529c2e69f1 44 hours ago 423MB ``` The vulnerability is caused by the usage of vulnerable functions of Jinja2 template engine. ```python from jinja2 import Environment, BaseLoader ... # Get the notification body from datastore jinja2_env = Environment(loader=BaseLoader) n_body = jinja2_env.from_string(n_object.get('notification_body', '')).render(**notification_parameters) n_title = jinja2_env.from_string(n_object.get('notification_title', '')).render(**notification_parameters) ``` ### PoC 1. Create/Edit a URL watch item 2. Under *Notifications* tab insert this payload: ```python {{ self.__init__.__globa...

# Description ## Path traversal This vulnerability allows an attacker to craft a request which is able to traverse the server file system and retrieve the contents of arbitrary files, including sensitive data such as configuration files, environment variables, and other critical data stored on the server. From Rajesh Sharma who discovered the vulnerability: POC: `curl --path-as-is http://localhost:3000/assets/../package.json` gives you the content of package.json present in the local directory. The vulnerability stems from usage of decodedReqPath directly in path.join without performing any path normalization i.e path.normalize in node.js https://github.com/vendure-ecommerce/vendure/blob/801980e8f599c28c5059657a9d85dd03e3827992/packages/asset-server-plugin/src/plugin.ts#L352-L358 If the vendure service is behind some server like nginx, apache, etc. Path normalization is performed on the root server level but still the actual client's request path will be sent to vendure service ...

Certificate verification (in [lib/agent/certificate.dart](https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart)) has been found to contain two issues: - During the delegation verification (in [_checkDelegation](https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162) function) the canister_ranges aren't verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification [here](https://internetcomputer.org/docs/current/references/ic-interface-spec#certification-delegation). Also for reference you can check how is this implemented in [the agent-rs](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L903-L914). - The certificate’s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expir...