#git

Two operators and 50 servers that were behind an online marketplace where criminals could buy stolen data have been seized

We are excited to introduce LLMail-Inject, a new challenge focused on evaluating state-of-the-art prompt injection defenses in a realistic simulated LLM-integrated email client. In this challenge, participants assume the role of an attacker who sends an email to a user. The user then queries the LLMail service with a question (e.

### Impact The regular expression that is vulnerable to backtracking can be generated in the 0.1.x release of `path-to-regexp`, originally reported here: https://github.com/advisories/GHSA-9wv6-86v2-598j ### Patches Upgrade to 0.1.12. ### Workarounds Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking. ### References - https://github.com/advisories/GHSA-9wv6-86v2-598j - https://blakeembrey.com/posts/2024-09-web-redos/

### Summary The Comment feature has implemented a filter to prevent users from adding restricted characters, such as HTML tags. However, this filter operates on the client-side, which can be bypassed, making the application vulnerable to HTML Injection. ### Details The Comment feature implements a character filter on the client-side, this can be bypassed by directly sending a request to the endpoint. Example Request: ``` PATCH /activity/comment/3 HTTP/2 Host: directus.local { "comment": "<h1>TEST <p style=\"color:red\">HTML INJECTION</p> <a href=\"//evil.com\">Test Link</a></h1>" } ``` Example Response: ```json { "data": { "id": 3, "action": "comment", "user": "288fdccc-399a-40a1-ac63-811bf62e6a18", "timestamp": "2023-09-06T02:23:40.740Z", "ip": "10.42.0.1", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36", "collection": "directus_files", "item": "7247dda1-c386-4e7a-...

### Summary sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients...

Researchers testing generative AI systems can use prompt injection, re-register after being banned, and bypass rate limits without running afoul of copyright law.

SUMMARY A large U.S. company with operations in China fell victim to a large-scale cyberattack earlier this year,…

Cloudflare Tunnels is just the latest legitimate cloud service that cybercriminals and state-sponsored threat actors are abusing to hide their tracks.

A single barrier prevented attackers from exploiting a critical vulnerability in an enterprise collaboration platform. Now there's a workaround.

In PyO3 0.23.0 the `PYO3_CONFIG_FILE` environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as `maturin` to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version. All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.