Focus on webmproject vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with webmproject. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total webmproject CVEs: 21
Earliest CVE date: 06 Nov 2010, 00:00 UTC
Latest CVE date: 30 Sep 2023, 20:15 UTC
Latest CVE reference: CVE-2023-44488
30-day Count (Rolling): 0
365-day Count (Rolling): 0
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): -100.0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): -100.0%
Average CVSS: 5.18
Max CVSS: 10.0
Critical CVEs (≥9): 1
Range | Count |
---|---|
0.0-3.9 | 5 |
4.0-6.9 | 12 |
7.0-8.9 | 5 |
9.0-10.0 | 1 |
These are the five CVEs with the highest CVSS scores for webmproject, sorted by severity first and recency.
VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.
Heap buffer overflow in vp8 encoding in libvpx in Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
Heap buffer overflow in libwebp in Google Chrome prior to 116.0.5845.187 and libwebp 1.3.2 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)
There exists a use after free/double free in libwebp. An attacker can use the ApplyFiltersAndEncode() function and loop through to free best.bw and assign best = trial pointer. The second loop will then return 0 because of an Out of memory error in VP8 encoder, the pointer is still assigned to trial and the AddressSanitizer will attempt a double free.
A flaw was found in libwebp in versions before 1.0.1. When reading a file libwebp allocates an excessive amount of memory. The highest threat from this vulnerability is to the service availability.
A flaw was found in libwebp in versions before 1.0.1. An out-of-bounds read was found in function ChunkAssignData. The highest threat from this vulnerability is to data confidentiality and to the service availability.
A flaw was found in libwebp in versions before 1.0.1. An out-of-bounds read was found in function ChunkVerifyAndAssign. The highest threat from this vulnerability is to data confidentiality and to the service availability.
A flaw was found in libwebp in versions before 1.0.1. A use-after-free was found due to a thread being killed too early. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A flaw was found in libwebp in versions before 1.0.1. A heap-based buffer overflow in function WebPDecodeRGBInto is possible due to an invalid check for buffer size. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A use of uninitialized value was found in libwebp in versions before 1.0.1 in ReadSymbol().
A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in ShiftBytes().
A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in GetLE24().
A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in PutLE16().
A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in ApplyFilter().
A heap-based buffer overflow was found in libwebp in versions before 1.0.1 in GetLE16().
In libwebp 0.5.1, there is a double free bug in libwebpmux.
In libwebm before 2019-03-08, a NULL pointer dereference caused by the functions OutputCluster and OutputTracks in webm_info.cc will trigger an abort, which allows a DoS attack, a similar issue to CVE-2018-19212.
In libwebm through 2018-10-03, there is an abort caused by libwebm::Webm2Pes::InitWebmParser() that will lead to a DoS attack.
A use-after-free issue was discovered in libwebm through 2018-02-02. If a Vp9HeaderParser was initialized once before, its property frame_ would not be changed because of code in vp9parser::Vp9HeaderParser::SetFrame. Its frame_ could be freed while the corresponding pointer would not be updated, leading to a dangling pointer. This is related to the function OutputCluster in webm_info.cc.
The function ParseVP9SuperFrameIndex in common/libwebm_util.cc in libwebm through 2018-01-30 does not validate the child_frame_length data obtained from a .webm file, which allows remote attackers to cause an information leak or a denial of service (heap-based buffer over-read and later out-of-bounds write), or possibly have unspecified other impact.
Multiple integer overflows in libwebp allows attackers to have unspecified impact via unknown vectors.
VP8 Codec SDK (libvpx) before 1.0.0 "Duclair" allows remote attackers to cause a denial of service (application crash) via (1) unspecified "corrupt input" or (2) by "starting decoding from a P-frame," which triggers an out-of-bounds read, related to "the clamping of motion vectors in SPLITMV blocks".
WebM libvpx (aka the VP8 Codec SDK) before 0.9.5, as used in Google Chrome before 7.0.517.44, allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via invalid frames.