Latest News

Forget gullible old people — Gen Z is the most at-risk age group on the Web. Older folks might want to ignore it, but employers are likely to feel the brunt.

Everest ransomware claims Mailchimp breach, leaks 943,000 lines of data. While limited in size, it adds to a spike in global ransomware activity this July.

### Summary Nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. ### Details The MaterialX [specification](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#mtlx-file-format-definition) supports importing other files by using `XInclude` tags. When parsing file imports, recursion is used to process nested files in the form of a tree with the root node being the first MaterialX files parsed. However, there is no limit imposed to the depth of files that can be parsed by the library, therefore, by building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. ### PoC This test is going to employ Windows UNC paths, in order to make the Proof Of Concept more realistic. In fact, by using windows network shares, an attacker would be able t...

### Summary When parsing an MTLX file with multiple nested `nodegraph` implementations, the MaterialX XML parsing logic can potentially crash due to stack exhaustion. ### Details By specification, multiple kinds of elements in MTLX support nesting other elements, such as in the case of `nodegraph` elements. Parsing these subtrees is implemented via recursion, and since there is no max depth imposed on the XML document, this can lead to a stack overflow when the library parses an MTLX file with an excessively high number of nested elements. ### PoC Please download the `recursion_overflow.mtlx` file from the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-53009 `build/bin/MaterialXView --material recursion_overflow.mtlx` ### Impact An attacker could intentionally crash a target program that uses OpenEXR by sending a malicious MTLX file.

The `num2words` project was compromised via a phishing attack and two new versions were uploaded to PyPI containing malicious code. The affected versions have been removed from PyPI, and users are advised to remove the affected versions from their environments.

The fall of RansomHub led to a major consolidation of the ransomware ecosystem last quarter, which was a boon for the DragonForce and Qilin gangs.

The Trump Administration is working with 60 companies on a plan to have Americans voluntarily upload their healthcare and medical data.

### Summary The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations. ### Details A concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large. ```cpp in.setFrameBuffer (i); int step = 1; // // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true; // ...

### Summary When reading a deep scanline image with a large sample count in `reduceMemory` mode, it is possible to crash a target application with a NULL pointer dereference in a write operation. ### Details In the `ScanLineProcess::run_fill` function, implemented in `src/lib/OpenEXR/ImfDeepScanLineInputFile.cpp`, the following code is used to write the `fillValue` in the sample buffer: ```cpp switch (fills.type) { case OPENEXR_IMF_INTERNAL_NAMESPACE::UINT: { unsigned int fillVal = (unsigned int) (fills.fillValue); unsigned int* fillptr = static_cast<unsigned int*> (dest); for ( int32_t s = 0; s < samps; ++s ) fillptr[s] = fillVal; // <--- POTENTIAL CRASH HERE break; } ``` However, when `reduceMemory` mode is enabled in the `readDeepScanLine` function in `src/lib/Open...

### Summary The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. ### Details In the `LossyDctDecoder_execute` function (from `src/lib/OpenEXRCore/internal_dwa_decoder.h`, when SSE2 is enabled), the following code is used to copy data from the chunks: ```cpp // no-op conversion to linear for (int y = 8 * blocky; y < 8 * blocky + maxY; ++y) { __m128i* restrict dst = (__m128i *) chanData[comp]->_rows[y]; __m128i const * restrict src = (__m128i const *)&rowBlock[comp][(y & 0x7) * 8]; for (int blockx = 0; blockx < numFullBlocksX; ++blockx) { _mm_storeu_si128 (dst, _mm_loadu_si128 (src)); // src += 8 * 8; // <--- si128 pointer incremented as a uint16_t dst += 8; } } ``` The issue arises because the `src` pointer, which is a `si128` pointer, is incremented by `8*8`, as if it were a `uint16_t` pointer...