#vulnerability

A likely China-nexus threat actor has been exploiting unpatched Ivanti vulnerabilities to gain initial access to victim networks and then patching the systems to block others from breaking in to the same network.

Qantas has confirmed a data breach after attackers gained access through a third-party call centre platform, affecting millions…

The ever-growing volume of vulnerabilities and threats requires organizations to remain resilient and anti-fragile — that is, to be able to proactively respond to issues and continuously improve.

**According to the CVSS metric, the attack vector is network (AV:N) and the user interaction is required (UI:R). What is the target context of the remote code execution?** This attack requires an authenticated client to click a link so that an unauthenticated attacker can initiate remote code execution.

### Summary This vulnerability affects JUnit's support for writing Open Test Reporting XML files which is an opt-in feature of `junit-platform-reporting`. If a repository is cloned using a GitHub token or other credentials in its URL, for example: ```bash git clone https://${GH_APP}:${GH_TOKEN}@github.com/example/example.git ``` The credentials are captured by `OpenTestReportGeneratingListener` which produces (trimmed for brevity): ```xml <infrastructure> <git:repository originUrl="https://username:[email protected]/example/example.git" /> </infrastructure> ``` ### Details https://github.com/junit-team/junit5/blob/6b7764dac92fd35cb348152d1b37f8726875a4e0/junit-platform-reporting/src/main/java/org/junit/platform/reporting/open/xml/OpenTestReportGeneratingListener.java#L183 I think this should be configurable in some way to exclude select git information or exclude it entirely. ### PoC 1. Clone a repo using a GitHub token as shown above. 2. Enable the listener `junit.platfor...

Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files in cases where the prefix matches an allowed directory. Users are advised to upgrade to 2025.7.1 to resolve the issue. Thank you to Elad Beber (Cymulate) for reporting these issues.

Versions of Filesystem prior to 0.6.3 & 2025.7.1 could allow access to unintended files via symlinks within allowed directories. Users are advised to upgrade to 2025.7.1 to resolve. Thank you to Elad Beber (Cymulate) for reporting these issues.

Cybersecurity researchers have discovered a critical security vulnerability in artificial intelligence (AI) company Anthropic's Model Context Protocol (MCP) Inspector project that could result in remote code execution (RCE) and allow an attacker to gain complete access to the hosts. The vulnerability, tracked as CVE-2025-49596, carries a CVSS score of 9.4 out of a maximum of 10.0. "This is one

### Summary Certs generated by v4 contain their private key. ## Details ### Background Recently, I encountered an API in Go that’s easy to misuse: sha512.Sum384 and sha512.New384().Sum look very similar and behave very differently. https://go.dev/play/p/kDCqqoYk84k demonstrates this. I want to discuss extending static analysis to detect this case with the go community, but before I do that, I want to make a best-effort pass at open-source projects to fix the existing bugs. I figured that if there were any vulnerabilities out there, they would be easy to find once that discussion begins, so it’s better to address them early. This work is a hobby project and has no affiliation with my employer, so I may be slow to respond due to existing commitments. ### PoC https://go.dev/play/p/vSW0U3Hq4qk ### Impact [This code](https://github.com/juju/utils/blob/0141ef0ee74a0cac603c5c9e4aff194008722f41/cert/cert.go#L120) (cert.NewLeaf) generates certs with the SubjectKeyId set to `sha512.Ne...

There is a heap buffer overflow when writing a sufficiently large (>64k encoded with default settings) image in the DDS format due to writing into a buffer without checking for available space. This only affects users who save untrusted data as a compressed DDS image. * Unclear how large the potential write could be. It is likely limited by process segfault, so it's not necessarily deterministic. It may be practically unbounded. * Unclear if there's a restriction on the bytes that could be emitted. It's likely that the only restriction is that the bytes would be emitted in chunks of 8 or 16. This was introduced in Pillow 11.2.0 when the feature was added.