Common Weakness Enumeration

CWE-835

Allowed

Loop with Unreachable Exit Condition ('Infinite Loop')

Abstraction: Base · Status: Incomplete

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-9W8R-397F-PRFH

Vulnerability from github – Published: 2021-04-20 16:35 – Updated: 2024-10-14 16:12
VLAI
Summary
Infinite Loop in Pygments
Details

An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Pygments"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5"
            },
            {
              "fixed": "2.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-20270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-12T20:58:03Z",
    "nvd_published_at": "2021-03-23T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the \"exception\" keyword.",
  "id": "GHSA-9w8r-397f-prfh",
  "modified": "2024-10-14T16:12:14Z",
  "published": "2021-04-20T16:35:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20270"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pygments/pygments/commit/f91804ff4772e3ab41f46e28d370f57898700333"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1922136"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pygments/pygments"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pygments/PYSEC-2021-140.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/05/msg00006.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4889"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Infinite Loop in Pygments"
}

GHSA-9WJ4-8H85-PGRW

Vulnerability from github – Published: 2025-06-10 20:14 – Updated: 2025-06-10 20:14
VLAI
Summary
OctoPrint Vulnerable to Denial of Service through malformed HTTP request in OctoPrint
Details

Impact

OctoPrint versions up until and including 1.11.1 contain a vulnerability that allows any unauthenticated attacker to send a manipulated broken multipart/form-data request to OctoPrint and through that make the web server component become unresponsive. This could be used to effectively run a denial of service attack on the OctoPrint server.

Patches

The vulnerability has been patched in version 1.11.2.

Workaround

OctoPrint administrators are once more reminded to not make OctoPrint available on hostile networks (e.g. the internet), regardless of whether this vulnerability is patched or not.

Details

The issue can be triggered by a broken multipart/form-data request lacking an end boundary to any of OctoPrint's endpoints implemented through the octoprint.server.util.tornado.UploadStorageFallbackHandler request handler. The request handler will get stuck in an endless busy loop, looking for a part of the request that will never come. As Tornado is single-threaded, that will effectively block the whole web server.

The fix adds detection of invalid requests like that and ensures they are handled gracefully with an HTTP 400 Bad Request response.

Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OctoPrint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-140",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T20:14:43Z",
    "nvd_published_at": "2025-06-10T16:15:41Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nOctoPrint versions up until and including 1.11.1 contain a vulnerability that allows any unauthenticated attacker to send a manipulated broken `multipart/form-data` request to OctoPrint and through that make the web server component become unresponsive. This could be used to effectively run a denial of service attack on the OctoPrint server.\n\n### Patches\n\nThe vulnerability has been patched in version 1.11.2.\n\n### Workaround\n\nOctoPrint administrators are once more reminded to not make OctoPrint available on hostile networks (e.g. the internet), regardless of whether this vulnerability is patched or not.\n\n### Details\n\nThe issue can be triggered by a broken `multipart/form-data` request lacking an end boundary to any of OctoPrint\u0027s endpoints implemented through the `octoprint.server.util.tornado.UploadStorageFallbackHandler` request handler. The request handler will get stuck in an endless busy loop, looking for a part of the request that will never come. As Tornado is single-threaded, that will effectively block the whole web server.\n\nThe fix adds detection of invalid requests like that and ensures they are handled gracefully with an HTTP 400 Bad Request response.\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi.",
  "id": "GHSA-9wj4-8h85-pgrw",
  "modified": "2025-06-10T20:14:44Z",
  "published": "2025-06-10T20:14:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-9wj4-8h85-pgrw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48879"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/commit/c9c35c17bd820f19c6b12e6c0359fc0cfdd0c1ec"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OctoPrint/OctoPrint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OctoPrint Vulnerable to Denial of Service through malformed HTTP request in OctoPrint"
}

GHSA-9WM5-V79H-43G8

Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2025-04-20 03:46
VLAI
Details

find_abstract_instance_name in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (infinite recursion and application crash) via a crafted ELF file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-15024"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-05T01:29:00Z",
    "severity": "MODERATE"
  },
  "details": "find_abstract_instance_name in dwarf2.c in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (infinite recursion and application crash) via a crafted ELF file.",
  "id": "GHSA-9wm5-v79h-43g8",
  "modified": "2025-04-20T03:46:20Z",
  "published": "2022-05-13T01:43:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15024"
    },
    {
      "type": "WEB",
      "url": "https://blogs.gentoo.org/ago/2017/10/03/binutils-infinite-loop-in-find_abstract_instance_name-dwarf2-c"
    },
    {
      "type": "WEB",
      "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=22187"
    },
    {
      "type": "WEB",
      "url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git%3Bh=52a93b95ec0771c97e26f0bb28630a271a667bd2"
    },
    {
      "type": "WEB",
      "url": "https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=52a93b95ec0771c97e26f0bb28630a271a667bd2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9WWR-2JH3-482P

Vulnerability from github – Published: 2026-02-18 18:30 – Updated: 2026-06-02 15:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths

The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.

This patch fixes the issue by changing the return value from SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-18T16:22:31Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths\n\nThe problem occurs when a signed request fails smb2 signature verification\ncheck. In __process_request(), if check_sign_req() returns an error,\nset_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.\nset_smb2_rsp_status() set work-\u003enext_smb2_rcv_hdr_off as zero. By resetting\nnext_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain\nis lost. Consequently, is_chained_smb2_message() continues to point to\nthe same request header instead of advancing. If the header\u0027s NextCommand\nfield is non-zero, the function returns true, causing __handle_ksmbd_work()\nto repeatedly process the same failed request in an infinite loop.\nThis results in the kernel log being flooded with \"bad smb2 signature\"\nmessages and high CPU usage.\n\nThis patch fixes the issue by changing the return value from\nSERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that\nthe processing loop terminates immediately rather than attempting to\ncontinue from an invalidated offset.",
  "id": "GHSA-9wwr-2jh3-482p",
  "modified": "2026-06-02T15:31:53Z",
  "published": "2026-02-18T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23220"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/010eb01ce23b34b50531448b0da391c7f05a72af"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/544adb0a6658ea1bff4064723761dbf05f95b1e2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5accdc5b7f28a81bbc5880ac0b8886e60c86e8c8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/71b5e7c528315ca360a1825a4ad2f8ae48c5dc16"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9135e791ec2709bcf0cda0335535c74762489498"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7b1c2f5642bbd60b1beef1f3298cbac81eb232c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fb3b66bd72deb5543addaefa67963b34fb163a7b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C33M-22CR-J9X4

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2024-11-26 15:50
VLAI
Summary
Designate does not enforce the DNS protocol limit concerning record set sizes
Details

Designate does not enforce the DNS protocol limit concerning record set sizes

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "designate"
      },
      "versions": [
        "2015.1.0b2"
      ]
    }
  ],
  "aliases": [
    "CVE-2015-5694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-21T22:15:16Z",
    "nvd_published_at": "2019-11-22T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Designate does not enforce the DNS protocol limit concerning record set sizes",
  "id": "GHSA-c33m-22cr-j9x4",
  "modified": "2024-11-26T15:50:36Z",
  "published": "2022-05-24T17:01:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5694"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-5694"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/designate"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/designate/PYSEC-2019-243.yaml"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2015-5694"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/07/28/11"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/07/29/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Designate does not enforce the DNS protocol limit concerning record set sizes"
}

GHSA-C47W-GGCW-5493

Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-03-18 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()

Above the while() loop in wait_sb_inodes(), we document that we must wait for all pages under writeback for data integrity. Consequently, if a mapping, like fuse, traditionally does not have data integrity semantics, there is no need to wait at all; we can simply skip these inodes.

This restores fuse back to prior behavior where syncs are no-ops. This fixes a user regression where if a system is running a faulty fuse server that does not reply to issued write requests, this causes wait_sb_inodes() to wait forever.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23109"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-04T17:16:21Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes()\n\nAbove the while() loop in wait_sb_inodes(), we document that we must wait\nfor all pages under writeback for data integrity.  Consequently, if a\nmapping, like fuse, traditionally does not have data integrity semantics,\nthere is no need to wait at all; we can simply skip these inodes.\n\nThis restores fuse back to prior behavior where syncs are no-ops.  This\nfixes a user regression where if a system is running a faulty fuse server\nthat does not reply to issued write requests, this causes wait_sb_inodes()\nto wait forever.",
  "id": "GHSA-c47w-ggcw-5493",
  "modified": "2026-03-18T15:30:39Z",
  "published": "2026-02-04T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23109"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f4ed5e2b8f111553562507ad6202432c7c57731"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f9a49aa302a05e91ca01f69031cb79a0ea33031f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4J8-6XXF-P927

Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48
VLAI
Details

A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipso_v4_optptr() function in net/ipv4/cipso_ipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-10938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-27T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipso_v4_optptr() function in net/ipv4/cipso_ipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.",
  "id": "GHSA-c4j8-6xxf-p927",
  "modified": "2022-05-13T01:48:59Z",
  "published": "2022-05-13T01:48:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10938"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10938"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=40413955ee265a5e42f710940ec78f5450d49149"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3797-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3797-2"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4308"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/oss-sec/2018/q3/179"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105154"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041569"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C59P-WQ67-24WX

Vulnerability from github – Published: 2025-01-21 19:58 – Updated: 2025-01-21 19:58
VLAI
Summary
Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify
Details

Summary

This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack.

Details

The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.

The lookupWebFinger function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the lookupWebFinger function- getActorHandle, and lookupObject, which are both used as a wrapper for the vulnerable lookup function. As the lookupObject function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way getActorHandle is.

The getActorHandle function is a wrapper function for the getActorHandleInternal function (both present at /src/vocab/actor.ts):

async function getActorHandleInternal(
  actor: Actor | URL,
  options: GetActorHandleOptions = {},
): Promise<`@${string}@${string}` | `${string}@${string}`> {
  const actorId = actor instanceof URL ? actor : actor.id;
  if (actorId != null) {
    const result = await lookupWebFinger(actorId, {
      userAgent: options.userAgent,
      tracerProvider: options.tracerProvider,
    });
    if (result != null) {
      const aliases = [...(result.aliases ?? [])];
      if (result.subject != null) aliases.unshift(result.subject);
      for (const alias of aliases) {
        const match = alias.match(/^acct:([^@]+)@([^@]+)$/);
        if (match != null) {
          const hostname = new URL(`https://${match[2]}/`).hostname;
          if (
            hostname !== actorId.hostname &&
            !await verifyCrossOriginActorHandle(
              actorId.href,
              alias,
              options.userAgent,
              options.tracerProvider,
            )
          ) {
            continue;
          }
          return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);
        }
      }
    }
  }
  if (
    !(actor instanceof URL) && actor.preferredUsername != null &&
    actor.id != null
  ) {
    return normalizeActorHandle(
      `@${actor.preferredUsername}@${actor.id.host}`,
      options,
    );
  }
  throw new TypeError(
    "Actor does not have enough information to get the handle.",
  );
}

The actorId parameter containing a URL of the actor ID sinks into the lookupWebFinger function which is a wrapper for the lookupWebFingerInternal:

async function lookupWebFingerInternal(
  resource: URL | string,
  options: LookupWebFingerOptions = {},
): Promise<ResourceDescriptor | null> {
  if (typeof resource === "string") resource = new URL(resource);
  let protocol = "https:";
  let server: string;
  if (resource.protocol === "acct:") {
    const atPos = resource.pathname.lastIndexOf("@");
    if (atPos < 0) return null;
    server = resource.pathname.substring(atPos + 1);
    if (server === "") return null;
  } else {
    protocol = resource.protocol;
    server = resource.host;
  }
  let url = new URL(`${protocol}//${server}/.well-known/webfinger`);
  url.searchParams.set("resource", resource.href);
  while (true) {
    logger.debug(
      "Fetching WebFinger resource descriptor from {url}...",
      { url: url.href },
    );
    let response: Response;
    try {
      response = await fetch(url, {
        headers: {
          Accept: "application/jrd+json",
          "User-Agent": typeof options.userAgent === "string"
            ? options.userAgent
            : getUserAgent(options.userAgent),
        },
        redirect: "manual",
      });
    } catch (error) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {error}",
        { url: url.href, error },
      );
      return null;
    }
    if (
      response.status >= 300 && response.status < 400 &&
      response.headers.has("Location")
    ) {
      url = new URL(
        response.headers.get("Location")!,
        response.url == null || response.url === "" ? url : response.url,
      );
      continue;
    }
    if (!response.ok) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {status} {statusText}.",
        {
          url: url.href,
          status: response.status,
          statusText: response.statusText,
        },
      );
      return null;
    }
    try {
      return await response.json() as ResourceDescriptor;
    } catch (e) {
      if (e instanceof SyntaxError) {
        logger.debug(
          "Failed to parse WebFinger resource descriptor as JSON: {error}",
          { error: e },
        );
        return null;
      }
      throw e;
    }
  }
}

The function takes the actorId parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.

On the fetch request, the redirect attribute is set to “manual” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400).

This custom redirect implementation contains multiple issues: 1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting. 2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation. 3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.

In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.

PoC

  1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.
  2. We will create two machines, victim and attacker, each one on a different server with different domains.

Victim Machine 1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager. 2. Install a Deno server: curl -fsSL https://deno.land/install.sh | sh source ~/.bashrc deno --version #check deno is working 3. Pull the git repository of the victim blog app: git clone https://github.com/dahlia/fedify.git 4. Modify the federation object to remove signature checks for the sake of easy testing: On file /examples/blog/federation/mod.ts edit the createFederation object the following attribute: skipSignatureVerification: true. 5. Change into the blog app directory ( /examples/blog ) and run the app: deno task preview 6. Surf to the application on the browser, and register a user on the app.

Attacker Machine 1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager. 2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked): curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash source ~/.bashrc nvm list-remote 3. Install the latest stable version: nvm install {latest_ver} #for example: v20.10.0 source ~/.bashrc npm -v #check it works node -v #check it works 4. Download the attacker app repository: git clone https://github.com/dahlia/microblog.git 5. Disable request signature validations: Edit the /src/federation.ts file and add a skipSignatureVerification: true attribute to the createFederation object. 6. Modify the /src/federation.ts file and tamper with the Person object on the actor dispatcher ( setActorDispatcher("/users/{identifier}" ) - change the actor ID attribute “id: ctx.getActorUri(identifier)” into “id: new URL(‘http://:1337/users/enterloop’)”. 7. Install python flask and create the Python Flask redirect server: apt update apt install python3-flask

from flask import Flask, redirect

app = Flask(__name__)

@app.route('/health')
def health():
    return "hello", 200

@app.route('/.well-known/webfinger')
def ssrfinger():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

@app.route('/endlessloop')
def endlessloop():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

if __name__ == '__main__':
    app.run(debug=True,host='0.0.0.0' ,port=1337)
  1. Run the python server and attempt to reach the “/health” path to see the server functions as expected.
  2. Read the README.txt file on the attacker app and follow the instructions on how to execute the app.
  3. Surf the app on the browser and attempt to follow the federated user on the victim’s machine.
  4. Send the “follow” request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).

Impact

  1. Implement a limiting stop condition for the endless loop to prevent infinite loops.
  2. Validate the scheme while performing a manual redirection handler.
  3. For each web resource (for the lookupWebFinger function and also URLs found on the “Location” header inside the loop) use the “validatePublicUrl” function to verify that it is not targeting a local resource.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.13"
            },
            {
              "fixed": "1.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.13"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.10"
            },
            {
              "fixed": "1.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.1.10"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.10"
            },
            {
              "fixed": "1.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.2.10"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.3"
            },
            {
              "fixed": "1.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.3.3"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-23221"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-21T19:58:29Z",
    "nvd_published_at": "2025-01-20T17:15:07Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThis vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim\u2019s server into an infinite loop causing Denial of Service.\nMoreover, this issue can also be maneuvered into performing a Blind SSRF attack.\n\n### Details\nThe Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.\n\nThe **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor\u2019s object.\nOn Fedify, two client-facing functions implement the **lookupWebFinger** function- **getActorHandle**, and **lookupObject**, which are both used as a wrapper for the vulnerable lookup function.\nAs the **lookupObject** function is implemented only for CLI usage, we won\u2019t focus our PoC and explanation on it, but it is still vulnerable in the same way **getActorHandle** is.\n\nThe **getActorHandle** function is a wrapper function for the **getActorHandleInternal** function (both present at _/src/vocab/actor.ts_):\n```javascript\nasync function getActorHandleInternal(\n  actor: Actor | URL,\n  options: GetActorHandleOptions = {},\n): Promise\u003c`@${string}@${string}` | `${string}@${string}`\u003e {\n  const actorId = actor instanceof URL ? actor : actor.id;\n  if (actorId != null) {\n    const result = await lookupWebFinger(actorId, {\n      userAgent: options.userAgent,\n      tracerProvider: options.tracerProvider,\n    });\n    if (result != null) {\n      const aliases = [...(result.aliases ?? [])];\n      if (result.subject != null) aliases.unshift(result.subject);\n      for (const alias of aliases) {\n        const match = alias.match(/^acct:([^@]+)@([^@]+)$/);\n        if (match != null) {\n          const hostname = new URL(`https://${match[2]}/`).hostname;\n          if (\n            hostname !== actorId.hostname \u0026\u0026\n            !await verifyCrossOriginActorHandle(\n              actorId.href,\n              alias,\n              options.userAgent,\n              options.tracerProvider,\n            )\n          ) {\n            continue;\n          }\n          return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);\n        }\n      }\n    }\n  }\n  if (\n    !(actor instanceof URL) \u0026\u0026 actor.preferredUsername != null \u0026\u0026\n    actor.id != null\n  ) {\n    return normalizeActorHandle(\n      `@${actor.preferredUsername}@${actor.id.host}`,\n      options,\n    );\n  }\n  throw new TypeError(\n    \"Actor does not have enough information to get the handle.\",\n  );\n}\n```\n\nThe **actorId** parameter containing a URL of the actor ID sinks into the **lookupWebFinger** function which is a wrapper for the **lookupWebFingerInternal**:\n```javascript\nasync function lookupWebFingerInternal(\n  resource: URL | string,\n  options: LookupWebFingerOptions = {},\n): Promise\u003cResourceDescriptor | null\u003e {\n  if (typeof resource === \"string\") resource = new URL(resource);\n  let protocol = \"https:\";\n  let server: string;\n  if (resource.protocol === \"acct:\") {\n    const atPos = resource.pathname.lastIndexOf(\"@\");\n    if (atPos \u003c 0) return null;\n    server = resource.pathname.substring(atPos + 1);\n    if (server === \"\") return null;\n  } else {\n    protocol = resource.protocol;\n    server = resource.host;\n  }\n  let url = new URL(`${protocol}//${server}/.well-known/webfinger`);\n  url.searchParams.set(\"resource\", resource.href);\n  while (true) {\n    logger.debug(\n      \"Fetching WebFinger resource descriptor from {url}...\",\n      { url: url.href },\n    );\n    let response: Response;\n    try {\n      response = await fetch(url, {\n        headers: {\n          Accept: \"application/jrd+json\",\n          \"User-Agent\": typeof options.userAgent === \"string\"\n            ? options.userAgent\n            : getUserAgent(options.userAgent),\n        },\n        redirect: \"manual\",\n      });\n    } catch (error) {\n      logger.debug(\n        \"Failed to fetch WebFinger resource descriptor: {error}\",\n        { url: url.href, error },\n      );\n      return null;\n    }\n    if (\n      response.status \u003e= 300 \u0026\u0026 response.status \u003c 400 \u0026\u0026\n      response.headers.has(\"Location\")\n    ) {\n      url = new URL(\n        response.headers.get(\"Location\")!,\n        response.url == null || response.url === \"\" ? url : response.url,\n      );\n      continue;\n    }\n    if (!response.ok) {\n      logger.debug(\n        \"Failed to fetch WebFinger resource descriptor: {status} {statusText}.\",\n        {\n          url: url.href,\n          status: response.status,\n          statusText: response.statusText,\n        },\n      );\n      return null;\n    }\n    try {\n      return await response.json() as ResourceDescriptor;\n    } catch (e) {\n      if (e instanceof SyntaxError) {\n        logger.debug(\n          \"Failed to parse WebFinger resource descriptor as JSON: {error}\",\n          { error: e },\n        );\n        return null;\n      }\n      throw e;\n    }\n  }\n}\n```\n\nThe function takes the **actorId** parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.\n\nOn the fetch request, the **redirect** attribute is set to \u201c**manual**\u201d preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the \u201cLocation\u201d header until receiving a valid response or an error occurs (loop keeps until 300\u003estatus code\u003e400).\n\nThis custom redirect implementation contains multiple issues:\n1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting.\n2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation.\n3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.\n\nIn order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.\n\n\n### PoC\n1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.\n2. We will create two machines, victim and attacker, each one on a different server with different domains.\n\n**_Victim Machine_**\n1. Create a new instance (we tested on ubuntu\u2019s latest version), and update the package manager.\n2. Install a Deno server:\n`\ncurl -fsSL https://deno.land/install.sh | sh\n`\n`\nsource ~/.bashrc\n`\n`\ndeno --version #check deno is working\n`\n3. Pull the git repository of the victim blog app:\n`\ngit clone https://github.com/dahlia/fedify.git\n`\n4. Modify the federation object to remove signature checks for the sake of easy testing:\nOn file **_/examples/blog/federation/mod.ts_** edit the **_createFederation\u003cvoid\u003e_** object the following attribute: **_skipSignatureVerification: true_**.\n5. Change into the blog app directory ( /examples/blog ) and run the app:\n`\ndeno task preview\n`\n6. Surf to the application on the browser, and register a user on the app.\n\n**_Attacker Machine_**\n1. Create a new instance (we tested on ubuntu\u2019s latest version), and update the package manager.\n2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):\n`\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash\n`\n`\nsource ~/.bashrc\n`\n`\nnvm list-remote\n`\n3. Install the latest stable version:\n`\nnvm install {latest_ver} #for example: v20.10.0\n`\n`\nsource ~/.bashrc\n`\n`\nnpm -v #check it works\n`\n`\nnode -v #check it works\n`\n4. Download the attacker app repository:\n`\ngit clone https://github.com/dahlia/microblog.git\n`\n5. Disable request signature validations:\nEdit the **_/src/federation.ts_** file and add a **_skipSignatureVerification: true_** attribute to the **_createFederation_** object.\n6. Modify the **_/src/federation.ts_** file and tamper with the Person object on the actor dispatcher ( **_setActorDispatcher(\"/users/{identifier}\"_** ) - change the actor ID attribute **_\u201cid: ctx.getActorUri(identifier)_**\u201d into \u201c**_id: new URL(\u2018http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/users/enterloop\u2019)_**\u201d.\n7. Install python flask and create the Python Flask redirect server:\n`\napt update\n`\n`\napt install python3-flask\n`\n```python\nfrom flask import Flask, redirect\n\napp = Flask(__name__)\n\n@app.route(\u0027/health\u0027)\ndef health():\n    return \"hello\", 200\n\n@app.route(\u0027/.well-known/webfinger\u0027)\ndef ssrfinger():\n    return redirect(\"http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/endlessloop\")\n\n@app.route(\u0027/endlessloop\u0027)\ndef endlessloop():\n    return redirect(\"http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/endlessloop\")\n\nif __name__ == \u0027__main__\u0027:\n    app.run(debug=True,host=\u00270.0.0.0\u0027 ,port=1337)\n```\n8.  Run the python server and attempt to reach the \u201c**_/health_**\u201d path to see the server functions as expected.\n9. Read the **_README.txt_** file on the attacker app and follow the instructions on how to execute the app.\n10. Surf the app on the browser and attempt to follow the federated user on the victim\u2019s machine.\n11. Send the \u201cfollow\u201d request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).\n\n\n### Impact\n1. Implement a limiting stop condition for the endless loop to prevent infinite loops.\n2. Validate the scheme while performing a manual redirection handler.\n3. For each web resource (for the **_lookupWebFinger_** function and also URLs found on the \u201c**_Location_**\u201d header inside the loop) use the \u201c**_validatePublicUrl_**\u201d function to verify that it is not targeting a local resource.\n",
  "id": "GHSA-c59p-wq67-24wx",
  "modified": "2025-01-21T19:58:29Z",
  "published": "2025-01-21T19:58:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23221"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/fedify/commit/8be3c2038eebf4ae12481683a1e809b314be3151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/fedify/commit/c505eb82fcd6b5b17174c6659c29721bc801ab9a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dahlia/fedify/commit/e921134dd5097586e4563ea80b9e8d1b5460a645"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dahlia/fedify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify"
}

GHSA-C873-F884-8R22

Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details

An issue was discovered in QPDF before 7.0.0. There is an infinite loop in the QPDFWriter::enqueueObject() function in libqpdf/QPDFWriter.cc.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-18183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-13T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in QPDF before 7.0.0. There is an infinite loop in the QPDFWriter::enqueueObject() function in libqpdf/QPDFWriter.cc.",
  "id": "GHSA-c873-f884-8r22",
  "modified": "2022-05-13T01:44:36Z",
  "published": "2022-05-13T01:44:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qpdf/qpdf/issues/143"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qpdf/qpdf/commit/8249a26d69f72b9cda584c14cc3f12769985e481"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3638-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C87F-HW9Q-6V9P

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

In Wireshark 2.4.0 to 2.4.4 and 2.2.0 to 2.2.12, epan/dissectors/packet-dcm.c had an infinite loop that was addressed by checking for integer wraparound.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-23T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Wireshark 2.4.0 to 2.4.4 and 2.2.0 to 2.2.12, epan/dissectors/packet-dcm.c had an infinite loop that was addressed by checking for integer wraparound.",
  "id": "GHSA-c87f-hw9q-6v9p",
  "modified": "2022-05-13T01:53:19Z",
  "published": "2022-05-13T01:53:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7322"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14411"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=afc780e2c796e971bb7d164103f4f0d10d3c25b5"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/04/msg00018.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2018-06.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103158"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.