ghsa

### Description There's an SSRF in the file upload processing system that allows remote attackers to make arbitrary HTTP requests from the server without authentication. The vulnerability exists in the serialization/deserialization handlers for multipart form data and JSON requests, which automatically download files from user-provided URLs without proper validation of internal network addresses. The framework automatically registers any service endpoint with file-type parameters (`pathlib.Path`, `PIL.Image.Image`) as vulnerable to this attack, making it a framework-wide security issue that affects most real-world ML services handling file uploads. While BentoML implements basic URL scheme validation in the `JSONSerde` path, the `MultipartSerde` path has no validation whatsoever, and neither path restricts access to internal networks, cloud metadata endpoints, or localhost services. The documentation explicitly promotes this URL-based file upload feature, making it an intended but i...

## Summary In the latest version of Koa, the back method used for redirect operations adopts an insecure implementation, which uses the user-controllable referrer header as the redirect target. ## Details on the API document https://www.koajs.net/api/response#responseredirecturl-alt, we can see: **response.redirect(url, [alt])** ``` Performs a [302] redirect to url. The string "back" is specially provided for Referrer support, using alt or "/" when Referrer does not exist. ctx.redirect('back'); ctx.redirect('back', '/index.html'); ctx.redirect('/login'); ctx.redirect('http://google.com'); ``` however, the "back" method is insecure: - https://github.com/koajs/koa/blob/master/lib/response.js#L322 ``` back (alt) { const url = this.ctx.get('Referrer') || alt || '/' this.redirect(url) }, ``` Referrer Header is User-Controlled. ## PoC **there is a demo for POC:** ``` const Koa = require('koa') const serve = require('koa-static') const Router = require('@koa/router') const...

### Impact Umbraco's [content delivery API](https://docs.umbraco.com/umbraco-cms/reference/content-delivery-api) can be restricted from public access such that an API key must be provided in a header to authorize the request. It's also possible to configure output caching, such that the delivery API outputs will be cached for a period of time, improving performance. There's an issue when these two things are used together though in that the caching doesn't vary by the header that contains the API key. As such it's possible for a user without a valid API key to retrieve a response for a given path and query if it has recently been requested and cached by request with a valid key. ### Patches Patches will be available in 13.9.3, 15.4.4 and 16.1.1. ### Workarounds Workaround is to remove or reduce the time period of the output caching or to provide other restrictions to access the delivery API such as by IP. ### References Content delivery API documentation: https://docs.umbraco.com...

The Memos application, up to version v0.24.3, allows for the embedding of markdown images with arbitrary URLs. When a user views a memo containing such an image, their browser automatically fetches the image URL without explicit user consent or interaction beyond viewing the memo. This can be exploited by an attacker to disclose the viewing user's IP address, browser User-Agent string, and potentially other request-specific information to the attacker-controlled server, leading to information disclosure and user tracking.

Versions of the package z-push/z-push-dev before 2.7.6 are vulnerable to SQL Injection due to unparameterized queries in the IMAP backend. An attacker can inject malicious commands by manipulating the username field in basic authentication. This allows the attacker to access and potentially modify or delete sensitive data from a linked third-party database. **Note:** This vulnerability affects Z-Push installations that utilize the IMAP backend and have the IMAP_FROM_SQL_QUERY option configured. Mitigation Change configuration to use the default or LDAP in backend/imap/config.php php define('IMAP_DEFAULTFROM', ''); or php define('IMAP_DEFAULTFROM', 'ldap');

A vulnerability was found in the netavark package, a network stack for containers used with Podman. Due to dns.podman search domain being removed, netavark may return external servers if a valid A/AAAA record is sent as a response. When creating a container with a given name, this name will be used as the hostname for the container itself, as the podman's search domain is not added anymore the container is using the host's resolv.conf, and the DNS resolver will try to look into the search domains contained on it. If one of the domains contain a name with the same hostname as the running container, the connection will forward to unexpected external servers.

Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. To conduct the attack an attacker would need a validly signed document from the identity provider (IdP). In fixing this we made sure to process the SAML assertions from only verified/authenticated contents. This will prevent future variants from coming up. Note: this is distinct from the previous xml-crypto CVEs.

### Summary An unauthenticated attacker is able to execute arbitrary JavaScript code in a victim's browser due to improper sanitization of multimedia tags in music files, including `m3u` files. ### Details Multimedia metadata is rendered in the web-app without sanitization. This can be exploited in two ways: * a user which has the necessary permission for uploading files can upload a song with an artist-name such as `<img src=x onerror=alert(document.domain)>` * an unauthenticated user can trick another user into clicking a malicious URL, performing this same exploit using an externally-hosted m3u file The CVE score and PoC is based on the m3u approach, which results in a higher severity. ### PoC 1. Create a file named `song.m3u` with the following content. Host this file on an attacker-controlled web server. ```m3u #EXTM3U #EXTINF:1,"><img src=x onerror=alert(document.domain)> - "><img src=x onerror=alert(document.domain)> http://example.com/audio.mp3 ``` ...

### Description The lookup function takes a user address for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production. The library does not prevent Localhost access (neither does it prevent LAN addresses such as 192.168.x.x) , thus is not safe for use in production by ActivityPub applications. The only check for localhost is done for selecting between HTTP and HTTPS protocols, and it is done by testing for a host that starts with the string “localhost” and ends with a port. Anything else (such as “127.0.0.1” or “localhost:1234/abc”) would not be considered localhost for this test. In addition, the way that the function determines the host, makes it possible to access any path in the host, not only “/.well-known/...” paths: ```javascript if (address.indexOf('://') > -1) { // other uri for...

### Impact This vulnerability affects applications that: * Use the ImageMagick handler for image processing (`imagick` as the image library) * **AND** either: * Allow file uploads with user-controlled filenames and process uploaded images using the `resize()` method * **OR** use the `text()` method with user-controlled text content or options An attacker can: * Upload a file with a malicious filename containing shell metacharacters that get executed when the image is processed * **OR** provide malicious text content or options that get executed when adding text to images ### Patches Upgrade to v4.6.2 or later. ### Workarounds * **Switch to the GD image handler** (`gd`, the default handler), which is not affected by either vulnerability * **For file upload scenarios**: Instead of using user-provided filenames, generate random names to eliminate the attack vector with `getRandomName()` when using the `move()` method, or use the `store()` method, which automatically generates safe ...