Vulnerability database
Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.
27 results
Oct 20, 2026The War Thunder game client transmits its authentication bearer token (auth_jwt) in the very first data packet after the TCP handshake, using only LZ4 compressiCVE-2026-107692 · Other software · Gaijin Entertainment · reported by cret@cert.orgMedium 4.8
The War Thunder game client transmits its authentication bearer token (auth_jwt) in the very first data packet after the TCP handshake, using only LZ4 compression rather than encryption. An attacker positioned on the network path can passively intercept and decompress this packet to reveal the plaintext JSON payload. This vulnerability allows for temporary authenticated impersonation, enabling an attacker to access game services and certain user data (such as email address and displayed phone number) as the affected user. While this allows for unauthorized access to gameplay, it does not facilitate full account takeover, as it cannot be used to modify account security settings, change passwords, bypass two-factor authentication for account management, or access financial information.
- Product
- War Thunder
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-106453 · Other software · yawkat · reported by GitHubMedium 5.3
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to approximately 2 GiB and exhaust the JVM heap. Convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor allocate the untrusted size, while overloads that write to a caller-provided destination buffer are not affected because the caller controls the destination size. This issue is fixed in version 1.11.2.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-106452 · Other software · yawkat · reported by GitHubMedium 5.3
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-106451 · Other software · yawkat · reported by GitHubHigh 7.3
yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to create an exclusive temporary .lck file but derives the native-library path by removing the suffix, then FileOutputStream opens that predictable path without exclusive creation, allowing another local user with access to the same shared temporary directory to create or replace the library file before System.load() uses it. Successful exploitation depends on shared-directory permissions, host protections, and winning the race, and can execute native code as the victim; hardened systems may instead cause library loading to fail and fall back to Java implementations. Configurations using a system library, a private java.io.tmpdir, or Java-only implementations are not affected. This issue is fixed in version 1.11.4.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-106450 · Other software · yawkat · reported by GitHubMedium 5.3
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Oct 6, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-106449 · Other software · yawkat · reported by GitHubLow 3.7
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption. This issue is fixed in version 1.11.4.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Sep 25, 2026In the Linux kernel, the following vulnerability has been resolved: erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduCVE-2026-98067 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: erofs: disable LZ4 rolling decompression for now LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages: For many cases, it is needed for users to read small data within a compressed extent (pcluster), either due to random small read, or since uptodate folios (typically order-0) cannot be reused for decompression again since decompression algorithm refills already-uptodate folios. Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing. It can save a lot of temporary memory, e.g. 601,960-byte data can be compressed into a 256k LZ4 compressed extent, which means it needs 146 extra pages per request in the worst case if rolling decompression is disabled. However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 18, 2026yawkat LZ4 Java provides LZ4 compression for Java.CVE-2026-59949 · Other software · yawkat · reported by GitHubMedium 6.5
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
May 27, 2026In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can haveCVE-2026-45999 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1
In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Mar 19, 2026lz4_flex is a pure Rust implementation of LZ4 compression/decompression.CVE-2026-32829 · Other software · PSeitz · reported by GitHubHigh 8.2
lz4_flex is a pure Rust implementation of LZ4 compression/decompression. In versions 0.11.5 and below, and 0.12.0, decompressing invalid LZ4 data can leak sensitive information from uninitialized memory or from previous decompression operations. The library fails to properly validate offset values during LZ4 "match copy operations," allowing out-of-bounds reads from the output buffer. The block-based API functions (`decompress_into`, `decompress_into_with_dict`, and others when `safe-decode` is disabled) are affected, while all frame APIs are unaffected. The impact is potential exposure of sensitive data and secrets through crafted or malformed LZ4 input. This issue has been fixed in versions 0.11.6 and 0.12.1.
- Product
- lz4_flex
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Dec 12, 2025Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java.CVE-2025-67721 · Other software · airlift · reported by GitHubMedium 6.3
Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java. In versions 3.3 and below, incorrect handling of malformed data in Java-based decompressor implementations for Snappy and LZ4 allow remote attackers to read previous buffer contents via crafted compressed input. With certain crafted compressed inputs, elements from the output buffer can end up in the uncompressed output, potentially leaking sensitive data. This is relevant for applications that reuse the same output buffer to uncompress multiple inputs. This can be the case of a web server that allocates a fix-sized buffer for performance purposes. There is similar vulnerability in GHSA-cmp6-m4wj-q63q. This issue is fixed in version 3.4.
- Product
- aircompressor
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Dec 5, 2025yawkat LZ4 Java provides LZ4 compression for Java.CVE-2025-66566 · Other software · yawkat · reported by GitHubHigh 8.2
yawkat LZ4 Java provides LZ4 compression for Java. Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected. This vulnerability is fixed in 1.10.1.
- Product
- lz4-java
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Nov 28, 2025Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted cCVE-2025-12183 · Other software · reported by 103e4ec9-0a87-450b-af77-479448ddef11High 8.8
Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted compressed input.
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgithub.comsonatype.com
Feb 26, 2025In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if CVE-2022-49078 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
May 29, 2024Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java.CVE-2024-36114 · Other software · airlift · reported by GitHubHigh 8.6
Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java. All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. Users should update to Aircompressor 0.27 or newer where these issues have been fixed. When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. There are no known workarounds for this issue.
- Product
- aircompressor
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Mar 1, 2024In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer forCVE-2023-52497 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompressi
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Dec 27, 2022LZ4 bindings use a deprecated C API that is vulnerable to memory corruption, which could lead to arbitrary code execution if called with untrusted user input.CVE-2014-125026 · Other software · github.com/cloudflare/golz4 · reported by security@golang.orgCritical 9.8
LZ4 bindings use a deprecated C API that is vulnerable to memory corruption, which could lead to arbitrary code execution if called with untrusted user input.
- Product
- github.com/cloudflare/golz4
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Mar 14, 2022Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query.CVE-2021-43305 · Other software · yandex · reported by reefs@jfrog.comHigh 8.8
Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query. There is no verification that the copy operations in the LZ4::decompressImpl loop and especially the arbitrary copy operation wildCopy<copy_amount>(op, ip, copy_end), don’t exceed the destination buffer’s limits. This issue is very similar to CVE-2021-43304, but the vulnerable copy operation is in a different wildCopy call.
- Product
- clickhouse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordjfrog.comlists.debian.org
Mar 14, 2022Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query.CVE-2021-43304 · Other software · yandex · reported by reefs@jfrog.comHigh 8.8
Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query. There is no verification that the copy operations in the LZ4::decompressImpl loop and especially the arbitrary copy operation wildCopy<copy_amount>(op, ip, copy_end), don’t exceed the destination buffer’s limits.
- Product
- clickhouse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordjfrog.comlists.debian.org
Mar 14, 2022Heap out-of-bounds read in Clickhouse's LZ4 compression codec when parsing a malicious query.CVE-2021-42388 · Other software · yandex · reported by reefs@jfrog.comHigh 8.1
Heap out-of-bounds read in Clickhouse's LZ4 compression codec when parsing a malicious query. As part of the LZ4::decompressImpl() loop, a 16-bit unsigned user-supplied value ('offset') is read from the compressed data. The offset is later used in the length of a copy operation, without checking the lower bounds of the source of the copy operation.
- Product
- clickhouse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordjfrog.comlists.debian.org
Mar 14, 2022Heap out-of-bounds read in Clickhouse's LZ4 compression codec when parsing a malicious query.CVE-2021-42387 · Other software · yandex · reported by reefs@jfrog.comHigh 8.1
Heap out-of-bounds read in Clickhouse's LZ4 compression codec when parsing a malicious query. As part of the LZ4::decompressImpl() loop, a 16-bit unsigned user-supplied value ('offset') is read from the compressed data. The offset is later used in the length of a copy operation, without checking the upper bounds of the source of the copy operation.
- Product
- clickhouse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordjfrog.comlists.debian.org
Jun 2, 2021There's a flaw in lz4.CVE-2021-3520 · Other software · Siemens · reported by Red HatCritical 9.8
There's a flaw in lz4. An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash. The greatest impact of this flaw is to availability, with some potential impact to confidentiality and integrity as well.
- Product
- SIMATIC S7-1500 CPU 1518-4 PN/DP MFP
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordbugzilla.redhat.comsecurity.netapp.com
Oct 13, 2019LZ4 before 1.9.2 has a heap-based buffer overflow in LZ4_write32 (related to LZ4_compress_destSize), affecting applications that call LZ4_compress_fast with a lCVE-2019-17543 · Other software · Siemens · reported by MITREHigh 8.1
LZ4 before 1.9.2 has a heap-based buffer overflow in LZ4_write32 (related to LZ4_compress_destSize), affecting applications that call LZ4_compress_fast with a large input. (This issue can also lead to data corruption.) NOTE: the vendor states "only a few specific / uncommon usages of the API are at risk."
- Product
- SIMATIC S7-1500 CPU 1518-4 PN/DP MFP
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordlists.opensuse.orglists.opensuse.org
Apr 15, 2019Heap-based Buffer Overflow write in Graphite2 library in Firefox before 54 in lz4::decompress src/Decompressor.CVE-2017-7773 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgHigh 8.8
Heap-based Buffer Overflow write in Graphite2 library in Firefox before 54 in lz4::decompress src/Decompressor.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordmozilla.orgmozilla.org
Apr 12, 2019Heap-based Buffer Overflow in Graphite2 library in Firefox before 54 in lz4::decompress function.CVE-2017-7772 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgHigh 8.8
Heap-based Buffer Overflow in Graphite2 library in Firefox before 54 in lz4::decompress function.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordmozilla.orgmozilla.org
Jul 3, 2014Yann Collet LZ4 before r119, when used on certain 32-bit platforms that allocate memory beyond 0x80000000, does not properly detect integer overflows, which allCVE-2014-4715 · Other software · Yann Collet · reported by MITREMedium 5
Yann Collet LZ4 before r119, when used on certain 32-bit platforms that allocate memory beyond 0x80000000, does not properly detect integer overflows, which allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted Literal Run, a different vulnerability than CVE-2014-4611.
- Product
- Lz4
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordblog.securitymouse.comfastcompression.blogspot.fr
Jul 3, 2014Integer overflow in the LZ4 algorithm implementation, as used in Yann Collet LZ4 before r118 and in the lz4_uncompress function in lib/lz4/lz4_decompress.c in tCVE-2014-4611 · Computers, phones & browsers · Linux · reported by MITREMedium 5
Integer overflow in the LZ4 algorithm implementation, as used in Yann Collet LZ4 before r118 and in the lz4_uncompress function in lib/lz4/lz4_decompress.c in the Linux kernel before 3.15.2, on 32-bit platforms might allow context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted Literal Run that would be improperly handled by programs not complying with an API limitation, a different vulnerability than CVE-2014-4715.
- Product
- Linux Kernel
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordblog.securitymouse.comfastcompression.blogspot.fr
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
Tell us what you're building.
A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.
Not ready to talk yet? Run the free website check and see what Google sees.