VYPR

CWE-834

Excessive Iteration

ClassIncomplete

Description

The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.

If the iteration can be influenced by an attacker, this weakness could allow attackers to consume excessive resources such as CPU or memory. In many cases, a loop does not need to be infinite in order to cause enough resource consumption to adversely affect the product or its host system; it depends on the amount of resources consumed per iteration.

Hierarchy (View 1000)

CVEs mapped to this weakness (65)

page 1 of 4
  • CVE-2017-12587HigAug 6, 2017
    risk 0.57cvss 8.8epss 0.02

    ImageMagick 7.0.6-1 has a large loop vulnerability in the ReadPWPImage function in coders\pwp.c.

  • CVE-2024-4227HigJan 15, 2025
    risk 0.49cvss 7.5epss 0.01

    In Genivia gSOAP with a specific configuration an unauthenticated remote attacker can generate a high CPU load when forcing to parse an XML having duplicate ID attributes which can lead to a DoS.

  • CVE-2018-14342HigJul 19, 2018
    risk 0.49cvss 7.5epss 0.04

    In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the BGP protocol dissector could go into a large loop. This was addressed in epan/dissectors/packet-bgp.c by validating Path Attribute lengths.

  • CVE-2018-11813HigJun 6, 2018
    risk 0.49cvss 7.5epss 0.03

    libjpeg 9c has a large loop because read_pixel in rdtarga.c mishandles EOF.

  • CVE-2018-9261HigApr 4, 2018
    risk 0.49cvss 7.5epss 0.03

    In Wireshark 2.4.0 to 2.4.5 and 2.2.0 to 2.2.13, the NBAP dissector could crash with a large loop that ends with a heap-based buffer overflow. This was addressed in epan/dissectors/packet-nbap.c by prohibiting the self-linking of DCH-IDs.

  • CVE-2018-7323HigFeb 23, 2018
    risk 0.49cvss 7.5epss 0.03

    In Wireshark 2.4.0 to 2.4.4 and 2.2.0 to 2.2.12, epan/dissectors/packet-wccp.c had a large loop that was addressed by ensuring that a calculated length was monotonically increasing.

  • CVE-2018-7321HigFeb 23, 2018
    risk 0.49cvss 7.5epss 0.02

    In Wireshark 2.4.0 to 2.4.4 and 2.2.0 to 2.2.12, epan/dissectors/packet-thrift.c had a large loop that was addressed by not proceeding with dissection after encountering an unexpected type.

  • CVE-2017-11409HigJul 18, 2017
    risk 0.49cvss 7.5epss 0.02

    In Wireshark 2.0.0 to 2.0.13, the GPRS LLC dissector could go into a large loop. This was addressed in epan/dissectors/packet-gprs-llc.c by using a different integer data type.

  • CVE-2017-11188HigJul 12, 2017
    risk 0.49cvss 7.5epss 0.02

    The ReadDPXImage function in coders\dpx.c in ImageMagick 7.0.6-0 has a large loop vulnerability that can cause CPU exhaustion via a crafted DPX file, related to lack of an EOF check.

  • CVE-2018-9133MedMar 30, 2018
    risk 0.43cvss 6.5epss 0.03

    ImageMagick 7.0.7-26 Q16 has excessive iteration in the DecodeLabImage and EncodeLabImage functions (coders/tiff.c), which results in a hang (tens of minutes) with a tiny PoC file. Remote attackers could leverage this vulnerability to cause a denial of service via a crafted tiff…

  • CVE-2024-0842HigFeb 9, 2024
    risk 0.42cvss 7.5epss 0.01

    The Backuply – Backup, Restore, Migrate and Clone plugin for WordPress is vulnerable to Denial of Service in all versions up to, and including, 1.2.6. This is due to direct access of the backuply/restore_ins.php file and. This makes it possible for unauthenticated attackers to…

  • CVE-2018-11507MedMay 28, 2018
    risk 0.42cvss 6.5epss 0.01

    An issue was discovered in Free Lossless Image Format (FLIF) 0.3. An attacker can trigger a long loop in image_load_pnm in image/image-pnm.cpp.

  • CVE-2017-17914MedDec 27, 2017
    risk 0.42cvss 6.5epss 0.02

    In ImageMagick 7.0.7-16 Q16, a vulnerability was found in the function ReadOnePNGImage in coders/png.c, which allows attackers to cause a denial of service (ReadOneMNGImage large loop) via a crafted mng image file.

  • CVE-2017-14222MedSep 9, 2017
    risk 0.42cvss 6.5epss 0.02

    In libavformat/mov.c in FFmpeg 3.3.3, a DoS in read_tfra() due to lack of an EOF (End of File) check might cause huge CPU and memory consumption. When a crafted MOV file, which claims a large "item_count" field in the header but does not contain sufficient backing data, is…

  • CVE-2017-14175MedSep 7, 2017
    risk 0.42cvss 6.5epss 0.02

    In coders/xbm.c in ImageMagick 7.0.6-1 Q16, a DoS in ReadXBMImage() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted XBM file, which claims large rows and columns fields in the header but does not contain sufficient backing data, is…

  • CVE-2017-14174MedSep 7, 2017
    risk 0.42cvss 6.5epss 0.02

    In coders/psd.c in ImageMagick 7.0.7-0 Q16, a DoS in ReadPSDLayersInternal() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted PSD file, which claims a large "length" field in the header but does not contain sufficient backing data, is…

  • CVE-2017-14172MedSep 7, 2017
    risk 0.42cvss 6.5epss 0.02

    In coders/ps.c in ImageMagick 7.0.7-0 Q16, a DoS in ReadPSImage() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted PSD file, which claims a large "extent" field in the header but does not contain sufficient backing data, is provided, the…

  • CVE-2017-14171MedSep 7, 2017
    risk 0.42cvss 6.5epss 0.02

    In libavformat/nsvdec.c in FFmpeg 2.4 and 3.3.3, a DoS in nsv_parse_NSVf_header() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted NSV file, which claims a large "table_entries_used" field in the header but does not contain sufficient…

  • CVE-2017-14170MedSep 7, 2017
    risk 0.42cvss 6.5epss 0.02

    In libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, a DoS in mxf_read_index_entry_array() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted MXF file, which claims a large "nb_index_entries" field in the header but does not contain sufficient…

  • CVE-2017-14059MedAug 31, 2017
    risk 0.42cvss 6.5epss 0.02

    In FFmpeg 3.3.3, a DoS in cine_read_header() due to lack of an EOF check might cause huge CPU and memory consumption. When a crafted CINE file, which claims a large "duration" field in the header but does not contain sufficient backing data, is provided, the image-offset parsing…