| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Tanium addressed a use-after-free vulnerability in Threat Response Client Extension. |
| Tanium addressed an improper link resolution before file access vulnerability in Threat Response Client Extension. |
| Tanium addressed an infinite loop vulnerability in Threat Response Client Extension. |
| Tanium addressed an information disclosure vulnerability in Threat Response Client Extension. |
| Tanium addressed an unauthorized code execution vulnerability in Threat Response. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Threat Response. |
| Tanium addressed an improper certificate validation vulnerability in Stream Client Extension. |
| Tanium addressed an insertion of sensitive information into log file vulnerability in Reputation. |
| Tanium addressed an information disclosure vulnerability in Tanium Server. |
| Tanium addressed a denial of service vulnerability in Tanium Server. |
| Tanium addressed a heap-based buffer overflow vulnerability in Index. |
| Tanium addressed a local privilege escalation vulnerability in End-User Notifications. |
| Tanium addressed a local privilege escalation vulnerability in End-User Notifications. |
| Tanium addressed an unauthorized code execution vulnerability in Certificate Manager. |
| Tanium addressed an improper access controls vulnerability in Comply. |
| Tanium addressed an improper access controls vulnerability in Comply. |
| Private keys for eight eMudhra intermediate CA certificates have been compromised https://emudhra.we-have-a-problem.com/ , which impacts certificate trust for outbound network request features of HCL Notes Client. An unauthenticated network attacker could spoof server certificates to execute a man in the middle (MITM) attack, enabling them to intercept and/or modify the content of outbound TLS connections. |
| An out-of-bounds write vulnerability in the Qt QTextCodec iconv-based encoding of the Qt 5 Compatibility APIs module (Qt Core in Qt 5 and earlier) impacts Qt. Under certain conditions, encoding text with QTextCodec may write outside an internal buffer. This can cause the application to crash and may affect data integrity. |
| The asynchronous Smile parser (NonBlockingByteArrayParser) uses a raw-binary length prefix taken from untrusted input to allocate a byte[] before the body is read, with no upper bound and no overflow check. On the raw-binary marker 0xFD, _decodeVInt() computes (value << 6) + (i & 0x3F) without the (value >>> 25) != 0 overflow guard present in the blocking SmileParser._readUnsignedVInt, and _startRawBinary then allocates the declared length immediately.
A Smile feed of roughly ten bytes can therefore force an eager allocation of approximately 2 GB, producing an OutOfMemoryError on reactive or asynchronous Smile endpoints. A VInt crafted to overflow int yields a negative length and a NegativeArraySizeException, a RuntimeException that is not a JacksonException and so escapes the parser contract. Either outcome crashes the request or processing thread.
This is the same class of issue as CVE-2020-28491 in the CBOR parser of this library, which was fixed with a LONGEST_NON_CHUNKED_BINARY guard; the asynchronous Smile parser never received the equivalent guard. No privileges or user interaction beyond the ability to submit data for parsing are required. |
| ProtobufParser parses length-prefixed protobuf string and bytes fields by checking (_inputPtr + len) <= _inputEnd and then, on the fast path, calling _finishShortText(len). Both use 32-bit signed integer arithmetic. When an attacker supplies a varint decoding to a length near Integer.MAX_VALUE, _inputPtr + len overflows to a negative value, the bounds check passes, and _finishShortText(len) reaches TextBuffer.expandCurrentSegment(len), which performs Arrays.copyOf with no cap and throws OutOfMemoryError: Requested array size exceeds VM limit.
The JVM refuses arrays larger than Integer.MAX_VALUE - 8 before consulting available heap, so -Xmx tuning does not mitigate the issue. StreamReadConstraints.maxStringLength and maxDocumentLength do not gate this path: a 33-byte payload is far below any document-length cap and the string-length check does not fire before the allocation. This was confirmed empirically against shipping artifacts with maxStringLength, maxDocumentLength and maxNestingDepth all configured.
A February 2026 hardening commit added the equivalent overflow guard to the packed-array-length and message-length paths but left the string-length call sites unguarded. No privileges or user interaction beyond the ability to submit data for parsing are required. |
