https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 18:57:49 +0000 https://vulnerability.circl.lu/vuln/bdu:2025-12797 bdu:2025-12797 https://vulnerability.circl.lu/vuln/bdu:2025-12797 https://vulnerability.circl.lu/vuln/cleanstart-2026-ad71344 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opentofu-fips</p> <p>Multiple security vulnerabilities affect the opentofu-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: opentofu-fips</p> <p>Multiple security vulnerabilities affect the opentofu-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://vulnerability.circl.lu/vuln/cleanstart-2026-ad71344 https://vulnerability.circl.lu/vuln/cve-2025-58058 <p><strong>Affected:</strong> ulikunitz xz</p> <p>xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn&#39;t include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.</p> <p><strong>Affected:</strong> ulikunitz xz</p> <p>xz is a pure golang package for reading and writing xz-compressed files. Prior to version 0.5.14, it is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn&#39;t include a magic number or has a checksum to detect such an issue according to the specification. Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done. This issue has been patched in version 0.5.14.</p> https://vulnerability.circl.lu/vuln/cve-2025-58058