ghsa

### Summary This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack. ### Details The Webfinger endpoint takes a remote domain 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 **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the *...

### Summary Vite allowed any websites to send any requests to the development server and read the response due to default CORS settings and lack of validation on the Origin header for WebSocket connections. ### Upgrade Path Users that does not match either of the following conditions should be able to upgrade to a newer version of Vite that fixes the vulnerability without any additional configuration. - Using the backend integration feature - Using a reverse proxy in front of Vite - Accessing the development server via a domain other than `localhost` or `*.localhost` - Using a plugin / framework that connects to the WebSocket server on their own from the browser #### Using the backend integration feature If you are using the backend integration feature and not setting [`server.origin`](https://vite.dev/config/server-options.html#server-origin), you need to add the origin of the backend server to the [`server.cors.origin`](https://github.com/expressjs/cors#configuration-options) opti...

### Impact This is an RCE vulnerability that affects Craft 4 and 5 installs where your security key has already been compromised. https://craftcms.com/knowledge-base/securing-craft#keep-your-secrets-secret Anyone running an unpatched version of Craft with a compromised security key is affected. ### Patches This has been patched in Craft 5.5.8 and 4.13.8. ### Workarounds If you can't update to a patched version, then rotating your security key and ensuring its privacy will help to migitgate the issue. ### References https://github.com/craftcms/cms/commit/e59e22b30c9dd39e5e2c7fe02c147bcbd004e603

## Summary HashiCorp’s go-slug library is vulnerable to a zip-slip style attack when a non-existing user-provided path is extracted from the tar entry. This vulnerability, identified as CVE-2025-0377, is fixed in go-slug 0.16.3. ## Background HashiCorp’s go-slug shared library offers functions for packing and unpacking Terraform Enterprise compatible slugs. Slugs are gzip compressed tar files containing Terraform configuration files. ## Details When go-slug performs an extraction, the filename/extraction path is taken from the tar entry via the header.Name. It was discovered that the unpacking step improperly validated paths, potentially leading to path traversal, allowing an attacker to write an arbitrary file during extraction. ## Remediation Consumers of the go-slug shared library should evaluate the risk associated with this issue in the context of their go-slug usage and upgrade go-slug to 0.16.3 or later.

A potential denial of service vulnerability is present in versions of Apache CXF before 3.5.10, 3.6.5 and 4.0.6. In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients).

An allocation of resources without limits or throttling in Elasticsearch can lead to an OutOfMemoryError exception resulting in a crash via a specially crafted query using an SQL function.

WriteFreely through 0.15.1, when MySQL is used, allows local users to discover credentials by reading config.ini.

### Summary The group data stored for users in the boltdb database (meta.db) is an append-list so group revocations/removals are ignored in the API. ### Details [SetUserGroups](https://github.com/project-zot/zot/blob/5e30fec65c49e3139907e2819ccb39b2e3bd784e/pkg/meta/boltdb/boltdb.go#L1665) is alled on login, but instead of replacing the group memberships, they are appended. This may be due to some conflict with the group definitions in the config file, but that wasn't obvious to me if it were the case. ### PoC Login with group claims, logout, remove the user from a group from at IdP and log in again, the API still grants access and the new list of groups is appended creating meaningless duplicate entries and no longer mathing the expected groups from the IdP. The behavior can be verified by seeing the API or UI still presenting images it should not or by viewing the data directly: `bbolt get meta.db UserData <user>`, eg: ![image](https://github.com/user-attachments/assets/3491cbd2-...

### Impact KaTeX users who render untrusted mathematical expressions with `renderToString` could encounter malicious input using `\htmlData` that runs arbitrary JavaScript, or generate invalid HTML. ### Patches Upgrade to KaTeX v0.16.21 to remove this vulnerability. ### Workarounds - Avoid use of or turn off the `trust` option, or set it to forbid `\htmlData` commands. - Forbid inputs containing the substring `"\\htmlData"`. - Sanitize HTML output from KaTeX. ### Details `\htmlData` did not validate its attribute name argument, allowing it to generate invalid or malicious HTML that runs scripts. ### For more information If you have any questions or comments about this advisory: - Open an issue or security advisory in the [KaTeX repository](https://github.com/KaTeX/KaTeX/) - Email us at [[email protected]](mailto:[email protected])

### Impact Users who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow, https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34. However, the current `tls.connect` method will always set `rejectUnauthorized: false` which is a potential security concern. CDK should follow the best practice and set `rejectUnauthorized: true`. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag. Note that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack. As a best practice, CDK should still fix this issue under a...