{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:17:21Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration\n\n## Summary\n\nGitea validates the user-supplied repository migration URL, but the actual clone and later mirror fetch operations are performed by the Git command-line client without disabling HTTP redirects. Git\u0027s default `http.followRedirects=initial` follows the first redirect and then uses the redirected URL as the base for later repository object requests.\n\nThis creates a URL-policy bypass, SSRF, and repository exfiltration primitive. A low-privileged authenticated user can submit an allowed public Git URL that redirects the Gitea server to an otherwise blocked or internal Git HTTP(S) endpoint. Local validation confirmed that Git followed a first-hop redirect to `127.0.0.1`, fetched Git objects, and completed the clone; `git -c http.followRedirects=false clone` blocked the same path.\n\nThe main impact is internal Git repository exfiltration into an attacker-controlled Gitea repository. Pull mirrors increase risk because scheduled `git fetch --tags` operations can keep following the redirect and collect future internal commits.\n\nThis is High severity by default for internet-accessible instances with migrations enabled, and can become Critical where internal repositories contain deploy keys, CI/CD secrets, cloud credentials, Terraform state, kubeconfigs, signing material, or production configuration. Direct unauthenticated exploitation, direct Gitea server RCE, arbitrary `file://` import, and default Actions runner execution are not confirmed.\n\n## Technical Root Cause Analysis\n\nThe root cause is a validation/enforcement mismatch across a trust boundary. This should be treated as a product security issue rather than a pure deployment misconfiguration: deployment choices influence reachability and impact, but Gitea applies policy to the originally submitted URL while the Git subprocess is allowed to reach a different effective URL after redirection.\n\nGitea validates the original migration URL:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\web\\repo\\migrate.go:180` parses the submitted web migration clone address.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\web\\repo\\migrate.go:182` calls `migrations.IsMigrateURLAllowed`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\api\\v1\\repo\\migrate.go:101` parses the submitted API migration clone address.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\api\\v1\\repo\\migrate.go:103` calls `migrations.IsMigrateURLAllowed`.\n\nThe URL validator resolves and checks the initially supplied host:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:44` defines `IsMigrateURLAllowed`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:75` rejects unsupported schemes.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:79` extracts the host.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:85` performs DNS resolution.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:86` enforces the allow/block list on the originally resolved host.\n\nAfter this validation, the actual repository data transfer is delegated to Git:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:93` calls `gitrepo.CloneExternalRepo` with `opts.CloneAddr`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\gitrepo\\clone.go:13` delegates to `git.Clone`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:123` constructs a `git clone` command.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:125` conditionally sets only `http.sslVerify=false`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:154` appends the source and destination arguments.\n\nNo equivalent network policy is applied to the final URL reached by Git after HTTP redirection. The protected migration HTTP client exists for service-specific migration API calls, but it is not used for the raw Git clone/fetch operation:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\http_client.go:16` defines `NewMigrationHTTPClient`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\http_client.go:27` applies a host-matching dialer.\n\nThat protection does not wrap `git clone` or `git fetch`.\n\nThe behavior depends on Git\u0027s documented redirect handling. The current Git documentation states that `http.followRedirects=initial` follows the initial request redirect and uses the redirected URL as the base for follow-up requests. The default value is `initial`: https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpfollowRedirects\n\nThis means the effective enforcement point is not the same as the actual network sink. Gitea checks `https://attacker.example/repo.git`; Git later retrieves `http://127.0.0.1:PORT/internal.git/...` or another internal target selected by the redirector.\n\nFor mirrors, the issue extends beyond initial migration:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:177` creates a mirror record when migration is requested as a mirror.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:188` stores the sanitized original remote address.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\mirror\\mirror_pull.go:120` later performs mirror synchronization with `git fetch --tags`.\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\mirror\\mirror_pull.go:126` fetches from the configured remote.\n\nBecause the mirror sync path also delegates to Git, a redirecting remote can continue to redirect scheduled fetches into an internal target.\n\n## Affected Assets \u0026 Attack Surface\n\nAffected features are URL-based repository migration, API repository migration, pull mirror creation through migration, and scheduled pull mirror synchronization. The relevant entrypoints are `POST /repo/migrate` for signed-in web users (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\web\\web.go:1062`) and `POST /api/v1/repos/migrate` for API-token users (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\api\\v1\\api.go:1170`).\n\nImportant preconditions are:\n\n- Repository migrations are enabled, which is the default in code and example configuration (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\setting\\repository.go:181`, `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\custom\\conf\\app.example.ini:1078`).\n- The attacker has a low-privileged account or the instance permits self-registration. Default/example service settings do not force registration confirmation by default.\n- For persistent exfiltration, pull mirrors must be enabled (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\setting\\mirror.go:20`).\n- The Gitea server can reach internal Git HTTP(S) services that the attacker cannot reach directly.\n\nHigh-value targets include internal Gitea, GitLab, GitHub Enterprise, Bitbucket, cgit, git-http-backend, and static bare Git repositories, especially repositories containing CI/CD definitions, deployment manifests, IaC, credentials, or production configuration.\n\nThe key trust boundary is that low-privileged user input influences server-side Git network access. Gitea validates the initially supplied URL, then hands control to a Git subprocess whose redirected destination is not constrained by the same allow/block policy. An attacker can discover exposure by using a controlled redirector, observing outbound Git requests, and testing whether scheduled mirror requests continue to arrive.\n\n## Exploitation Walkthrough\n\n### Scenario 1: One-time internal repository exfiltration\n\n1. The attacker obtains a low-privileged Gitea account. On instances with open registration, this may require only creating a user.\n2. The attacker hosts a public HTTP endpoint that appears to be a Git remote, for example `https://attacker.example/public.git`.\n3. The attacker configures the endpoint to respond to the initial Git discovery request with an HTTP redirect to an internal target, for example `http://internal-git.company.local/team/private.git/info/refs?service=git-upload-pack`.\n4. The attacker submits the public URL to Gitea\u0027s repository migration flow.\n5. Gitea validates only `attacker.example`, which passes the migration allow/block list.\n6. Gitea invokes `git clone --mirror` against the public URL.\n7. Git follows the initial redirect and uses the internal Git URL as the base for follow-up object requests.\n8. Gitea imports the internal repository contents into the attacker-controlled repository.\n9. The attacker browses the imported repository, downloads an archive, clones it, and searches working tree and history for secrets.\n\n### Scenario 2: Persistent exfiltration through pull mirror\n\n1. The attacker performs the same setup but enables mirror migration.\n2. Gitea creates a mirror record using the attacker-supplied public URL.\n3. On each scheduled mirror synchronization, Gitea runs `git fetch --tags` against the stored remote.\n4. The attacker\u0027s remote again redirects Git to the internal repository.\n5. New internal commits become available in the attacker\u0027s Gitea repository after mirror sync.\n\nThis materially increases impact because the exposure is not limited to one migration event. The attacker can continue collecting internal commits for as long as the mirror remains enabled and the redirect target remains reachable.\n\n### Scenario 3: Credential-to-RCE chain\n\nThis chain is conditional but realistic in DevOps environments.\n\n1. The attacker imports or mirrors an internal repository.\n2. The attacker searches the repository and full Git history for secrets:\n   - CI variables committed into workflow files.\n   - Cloud access keys.\n   - Kubernetes kubeconfigs.\n   - Terraform state files or backend credentials.\n   - Deployment SSH keys.\n   - Package registry tokens.\n   - Gitea/GitLab/GitHub PATs.\n3. The attacker uses the recovered credential to access CI/CD, cloud, container registry, deployment hosts, or orchestration infrastructure.\n4. The attacker obtains code execution in a runner, deployment job, Kubernetes workload, cloud function, VM, or production environment.\n\nThis is not direct RCE in Gitea from the currently validated evidence. It is a credible post-exploitation chain from server-side internal repository exfiltration to infrastructure compromise.\n\n### Scenario 4: Conditional Gitea Actions runner exposure\n\nActions-related escalation is configuration-dependent.\n\nRelevant code behavior:\n\n- Actions are detected only when the Actions unit is enabled:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:138`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:146`\n- Workflows are detected from commits:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:184`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:186`\n- Action runs are created from detected workflows:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:321`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:347`\n- Non-fork events do not require approval:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:401`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\actions\\notifier_helper.go:405`\n\nDefault mirror repository units do not include Actions:\n\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\models\\unit\\unit.go:88`\n- `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\models\\unit\\unit.go:96`\n\nTherefore, the Actions chain should not be presented as default direct impact. It is a critical conditional chain if an operator enables Actions on migrated/mirrored repositories, customizes default mirror units to include Actions, or manually enables Actions on a mirror. In such cases, redirected repository content containing workflow files may enqueue jobs in a context that is not treated as an untrusted fork pull request.\n\n## Proof-of-Concept \u0026 Evidence\n\n### Code evidence\n\nThe vulnerable flow is:\n\n1. User-controlled clone URL is accepted by the web or API migration handler.\n2. The original URL is validated by `IsMigrateURLAllowed`.\n3. The same original URL is passed to `git clone --mirror`.\n4. Git follows the initial HTTP redirect by default.\n5. Gitea does not revalidate the redirected target.\n\nKey code locations:\n\n- Web migration validation:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\web\\repo\\migrate.go:180`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\web\\repo\\migrate.go:182`\n- API migration validation:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\api\\v1\\repo\\migrate.go:101`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\routers\\api\\v1\\repo\\migrate.go:103`\n- URL policy enforcement:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:44`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:85`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\migrations\\migrate.go:86`\n- Git clone execution:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:93`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\gitrepo\\clone.go:13`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:123`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:125`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:154`\n- Mirror persistence and repeated fetch:\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:177`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\repository\\migrate.go:188`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\mirror\\mirror_pull.go:120`\n  - `C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\mirror\\mirror_pull.go:126`\n\n### Local validation summary\n\nA local safe PoC was run with two HTTP services:\n\n- Redirector service: represents the attacker-controlled public URL.\n- Target service: represents an internal Git HTTP repository on loopback.\n\nObserved behavior:\n\n- `git clone` was invoked against the redirector URL.\n- The redirector returned a first-hop HTTP redirect to the internal target URL.\n- Git followed the redirect.\n- The internal target received Git requests for:\n  - `/info/refs`\n  - `/HEAD`\n  - object paths required for clone completion\n- The clone completed successfully.\n- The cloned repository contained the expected file content from the internal target repository.\n\nThe local PoC result showed:\n\n```text\ncode: 0\nredirector hit count: 1\ntarget hit count: 5\ncloned content: \"internal repo data via redirected git clone\"\n```\n\nMirror fetch behavior was also validated locally:\n\n- A bare mirror remote was configured to point at the redirector URL.\n- `git fetch --tags origin` followed the redirect into the internal target.\n- The target received object requests.\n- The mirror fetched the expected branch reference successfully.\n\nThe mirror PoC result showed:\n\n```text\ncode: 0\ntarget object requests observed: 5\nhasFetchedBranchRef: true\n```\n\nMitigation behavior was validated locally:\n\n- The same clone was run with `git -c http.followRedirects=false clone`.\n- Git failed on the redirect with an HTTP 302 error.\n- This confirms that disabling Git HTTP redirects blocks the validated redirect SSRF path.\n\nThe failed mitigation test behavior was:\n\n```text\nfatal: unable to access \u0027\u003credirector-url\u003e\u0027: The requested URL returned error: 302\n```\n\nNegative validation:\n\n- An HTTP redirect to `file://` was attempted.\n- Git refused the redirected local-file protocol with `Protocol \"file\" disabled (in redirect)`.\n- Based on this validation, this report does not claim arbitrary local filesystem read or local repository import through `file://` redirection.\n\nValidation scope:\n\n- The local PoC validates the security-critical network sink used by the Gitea migration path: Git clone/fetch follows the redirect and retrieves repository objects from the redirected internal target.\n- The source review validates that Gitea\u0027s migration handlers pass the validated clone URL into that Git clone/fetch path without disabling HTTP redirects.\n- A full disposable Gitea UI/API end-to-end import proof was not executed as part of this report. If additional assurance is required before external submission, the highest-value next validation step is to run a temporary Gitea instance, create a low-privileged user, submit the redirector URL through `POST /repo/migrate` or `POST /api/v1/repos/migrate`, and confirm that the resulting attacker-owned Gitea repository contains the internal repository content. For mirror mode, add a new commit to the internal target and confirm a later mirror sync imports it.\n\n## Impact Assessment\n\nConfirmed impact is server-side Git network access to a redirected destination, resulting in internal Git repository import when the redirected target is reachable from the Gitea server. This can expose private source code, full Git history, deleted secrets, internal architecture, deployment pipelines, service names, and future commits if pull mirrors continue syncing.\n\nThe highest-risk secondary impact is secret extraction. Internal repositories often contain CI/CD definitions, deployment scripts, kubeconfigs, Terraform state, cloud keys, registry tokens, package publishing tokens, PATs, SSH deploy keys, webhook secrets, and historical credentials. Exposure of these materials can escalate to CI/CD compromise, cloud compromise, production access, or supply-chain compromise.\n\nDirect Gitea server RCE is not confirmed. The clone path uses `git clone --mirror`, remote Git hooks are not executed by a normal clone, local validation showed Git rejects `file://` redirects, and the reviewed command construction does not show obvious shell injection. Indirect RCE remains plausible through stolen CI/CD, cloud, deployment, package, or Actions runner credentials.\n\nIncident responders should treat exploitation as potential source-code and secret disclosure, not just SSRF probing. Recommended triage is to review recently migrated repositories and mirrors, identify unusual migration sources or redirector domains, inspect Gitea and egress logs around migration/mirror sync times, secret-scan affected full histories, rotate exposed credentials, and remove malicious mirror configurations.\n\n## Remediation Guidance\n\nDisable Git HTTP redirects for migration clone and mirror fetch operations unless every redirect hop is explicitly revalidated under the same migration allow/block policy.\n\nRecommended immediate code changes:\n\n- Invoke migration clone as `git -c http.followRedirects=false clone ...` (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\modules\\git\\repo.go:123`).\n- Invoke pull mirror fetch as `git -c http.followRedirects=false fetch ...` (`C:\\Users\\One\\Desktop\\gitea_new\\gitea\\services\\mirror\\mirror_pull.go:122`).\n\nLocal mitigation testing confirmed that `http.followRedirects=false` prevents the redirect-based clone from succeeding. If redirect support is required for compatibility, Gitea should follow redirects in controlled code, validate each hop against the migration network policy, and then invoke Git with redirects disabled.\n\nDefense in depth:\n\n- Enforce egress restrictions for the Gitea process/container.\n- Block outbound access to loopback, RFC1918, link-local, multicast, metadata-service ranges, and internal Git services unless explicitly required.\n- Disable repository migrations and new pull mirrors where not operationally required.\n- Restrict migration access to trusted users; disable public self-registration or require manual approval.\n- Require authentication on internal Git HTTP endpoints even when they are network-internal.\n\n## Risk Classification\n\nSeverity: High by default for internet-accessible instances with repository migrations enabled; Critical in environments where Gitea can reach sensitive internal Git services containing secrets, deploy keys, CI/CD credentials, cloud credentials, or production configuration.\n\nCritical escalation conditions:\n\nCritical escalation conditions include sensitive internal Git reachability, weak egress controls, repositories containing production or CI/CD secrets, enabled pull mirrors that continue syncing future commits, or configurations where imported workflow content can reach shared/self-hosted Actions runners.\n\nNot confirmed:\n\nDirect unauthenticated exploitation, direct Gitea server RCE from the migration clone path, arbitrary local filesystem read via `file://` redirect, and default Actions runner execution from mirror sync without configuration changes.",
  "id": "GHSA-82f7-87hm-852x",
  "modified": "2026-07-21T19:17:22Z",
  "published": "2026-07-21T19:17:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-82f7-87hm-852x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-37229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T14:15:12Z",
    "severity": "HIGH"
  },
  "details": "Loftware Spectrum before 5.1 allows SSRF.",
  "id": "GHSA-82mg-vc5c-pcm3",
  "modified": "2024-09-10T18:30:44Z",
  "published": "2024-09-10T15:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37229"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com/public-vulnerability-list"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-0628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-07T07:15:07Z",
    "severity": "LOW"
  },
  "details": "The WP RSS Aggregator plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 4.23.5 via the RSS feed source in admin settings. This makes it possible for authenticated attackers, with administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-82mh-pj8x-3fw7",
  "modified": "2024-02-07T09:30:31Z",
  "published": "2024-02-07T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0628"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3029525/wp-rss-aggregator"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2154383e-eabb-4964-8991-423dd68d5efb?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-27780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-177",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "The curl URL parser wrongly accepts percent-encoded URL separators like \u0027/\u0027when decoding the host name part of a URL, making it a *different* URL usingthe wrong host name when it is later retrieved.For example, a URL like `http://example.com%2F127.0.0.1/`, would be allowed bythe parser and get transposed into `http://example.com/127.0.0.1/`. This flawcan be used to circumvent filters, checks and more.",
  "id": "GHSA-82rv-h33p-2xgc",
  "modified": "2024-03-27T15:30:35Z",
  "published": "2022-06-03T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27780"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1553841"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202212-01"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220609-0009"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "libtaxii"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.118"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-27197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-20T17:53:43Z",
    "nvd_published_at": "2020-10-17T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "\"TAXII libtaxii through 1.1.117, as used in EclecticIQ OpenTAXII through 0.2.0 and other products, allows SSRF via an initial http:// substring to the parse method, even when the no_network setting is used for the XML parser. NOTE: the vendor points out that the parse method \"wraps the lxml library\" and that this may be an issue to \"raise ... to the lxml group.\"\"",
  "id": "GHSA-836c-xg97-8p4h",
  "modified": "2024-09-27T21:39:29Z",
  "published": "2021-04-30T17:34:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TAXIIProject/libtaxii/issues/246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eclecticiq/OpenTAXII/issues/176"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TAXIIProject/libtaxii/pull/247"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TAXIIProject/libtaxii/commit/23c6f7b69d99e965c8d53dc4710ae64da3fb4842"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TAXIIProject/libtaxii"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-836c-xg97-8p4h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/libtaxii/PYSEC-2020-59.yaml"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/159662/Libtaxii-1.1.117-OpenTaxi-0.2.0-Server-Side-Request-Forgery.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "libtaxii Server-Side Request Forgery vulnerability"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "cowrie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-34469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-20T17:42:07Z",
    "nvd_published_at": "2025-12-31T22:15:49Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA Server-Side Request Forgery (SSRF) vulnerability in Cowrie\u0027s emulated shell mode allows unauthenticated attackers to abuse the honeypot as an amplification vector for HTTP-based denial-of-service attacks against arbitrary third-party hosts.\n\n### Details\n\nWhen Cowrie operates in emulated shell mode (the default configuration), it basically emulates common Linux commands. The `wget` and `curl` command emulations actually perform real outbound HTTP requests to the destinations specified by the attacker, as this functionality is intended to allow Cowrie to save downloaded files for later inspection.\n\nAn attacker who connects to the honeypot via SSH or Telnet can repeatedly invoke these commands targeting a victim host. Since there was no rate limiting mechanism in place, the attacker could generate unlimited outbound HTTP traffic toward the victim. The requests originate from the honeypot\u0027s IP address, effectively masking the attacker\u0027s identity and turning the honeypot into an unwitting participant in distributed denial-of-service (DDoS) attacks.\n\nThis vulnerability was observed being actively exploited in the wild.\n\n**Acknowledgements**\nThis vulnerability was investigated by _[Abraham Gebrehiwot](https://www.iit.cnr.it/en/abraham.gebrehiwot/)_ and _Filippo Lauria_, with additional contributions from _Michele Castellaneta_, _Claudio Porta_ and _Sara Afzal_. All researchers are affiliated with the [Institute of Informatics and Telematics](https://www.iit.cnr.it/en/) (IIT),  [Italian National Research Council](https://www.cnr.it/en/) (CNR).\n\n**Fix**\nThis issue has been fixed in version 2.9.0 via PR #2800, which introduces a rate limiting mechanism for outbound requests in command emulations such as `wget` and `curl`.\n\n### PoC\n\nThis is a rudimentary proof of concept demonstrating the amplification potential of this vulnerability.\n\n**Setup:**\n- Victim machine (192.168.1.30): runs a simple HTTP server\n- Attacker machine (192.168.1.20): initiates the attack\n- Cowrie honeypot (192.168.1.10): configured in emulated shell mode with SSH access (credentials: `test:test`)\n\n**On the victim machine**, start an HTTP server:\n```bash\nsudo python3 -m http.server 80\n```\n\n**On the attacker machine**, execute:\n```bash\nPAYLOAD=$(for i in {1..100}; do echo -n \u0027wget -q http://192.168.1.30;\u0027; done) \u0026\u0026 \\\nfor i in {1..10}; do sshpass -p test ssh test@192.168.1.10 \"$PAYLOAD\"; done\n```\n\nThis command builds a `PAYLOAD` consisting of 100 concatenated `wget` commands, then executes it 10 times via SSH, resulting in 1,000 HTTP requests toward the victim from a single attack script. The amplification factor can be arbitrarily increased by adjusting these values, bounded by technical limitations such as argument length, buffer sizes, etc.\n\n**Result:** The victim\u0027s HTTP server logs show 1,000 requests originating exclusively from the honeypot\u0027s IP address (192.168.1.10), received within approximately 5 seconds (truncated for brevity):\n```\n192.168.1.10 - - [11/Dec/2025 14:33:03] \"GET / HTTP/1.1\" 200 -\n192.168.1.10 - - [11/Dec/2025 14:33:03] \"GET / HTTP/1.1\" 200 -\n192.168.1.10 - - [11/Dec/2025 14:33:03] \"GET / HTTP/1.1\" 200 -\n...\n192.168.1.10 - - [11/Dec/2025 14:33:08] \"GET / HTTP/1.1\" 200 -\n192.168.1.10 - - [11/Dec/2025 14:33:08] \"GET / HTTP/1.1\" 200 -\n192.168.1.10 - - [11/Dec/2025 14:33:08] \"GET / HTTP/1.1\" 200 -\n```\n\nNotice that the attacker\u0027s IP (192.168.1.20) never appears in the victim\u0027s logs, demonstrating how the honeypot masks the attacker\u0027s identity.\n\n### Impact\n\nThis is a Server-Side Request Forgery (SSRF) vulnerability that enables abuse of Cowrie honeypots as DDoS amplification nodes.\n\n**Who is impacted:** Any organization running Cowrie in emulated shell mode (the default configuration) with versions prior to 2.9.0.\n\n**Consequences:**\n- Third-party victims receive unwanted HTTP traffic from the honeypot\u0027s IP address\n- Attackers can mask their identity behind the honeypot\u0027s IP\n- Honeypot operators may face abuse complaints or have their infrastructure blocklisted\n- Network resources of the honeypot host are consumed",
  "id": "GHSA-83jg-m2pm-4jxj",
  "modified": "2026-01-14T14:29:45Z",
  "published": "2025-12-20T17:42:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cowrie/cowrie/security/advisories/GHSA-83jg-m2pm-4jxj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cowrie/cowrie/issues/2622"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cowrie/cowrie/pull/2800"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-83jg-m2pm-4jxj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cowrie/cowrie"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cowrie/cowrie/releases/tag/v2.9.0"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/cverecord?id=CVE-2025-34469"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/cowrie-unrestricted-wget-curl-emulation-enables-ssrf-based-ddos-amplification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Cowrie has a SSRF vulnerability in wget/curl emulation enabling DDoS amplification"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.8.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49860"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T19:04:07Z",
    "nvd_published_at": "2026-06-23T18:18:04Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen a WebSocket connection was opened, Deno checked the destination hostname\nagainst `--deny-net` rules but did not re-check the IP addresses that hostname\nresolved to. An attacker-controlled script could use a specially crafted domain\nname that passes the hostname check yet resolves to a denied IP, bypassing the\nnetwork restriction entirely.\n\n## Impact\n\nCode running under `--deny-net` could connect to hosts that the user intended\nto block. In practice this means network isolation rules \u2014 for example,\nblocking access to `localhost` or internal services \u2014 could be silently\ncircumvented by a malicious or compromised dependency.\n\n`Deno.connect` and `fetch()` were not affected by this specific issue (a\ncompanion advisory covers `fetch()`).\n\n## Who is affected\n\nUsers who:\n\n- run untrusted or third-party code with `deno run`, and\n- rely on `--deny-net` to restrict which hosts that code can reach.\n\nIf you do not use `--deny-net`, or if you only run fully trusted code, you are\nnot affected.\n\n## Workaround\n\nNo workaround is available short of upgrading. If upgrading immediately is not\npossible, avoid granting `--allow-net` to untrusted code that also has\n`--deny-net` restrictions you depend on for security.",
  "id": "GHSA-83pc-3rw9-qpwj",
  "modified": "2026-07-20T21:01:04Z",
  "published": "2026-06-16T19:04:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-83pc-3rw9-qpwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49860"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deno: WebSocket API sandbox bypass via missing post-DNS check"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-45085"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-12T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Group Arge Energy and Control Systems Smartpower Web allows : Server Side Request Forgery.This issue affects Smartpower Web: before 23.01.01.",
  "id": "GHSA-83vx-xm77-c4mm",
  "modified": "2026-05-18T18:31:22Z",
  "published": "2023-02-12T06:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45085"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-23-0066"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-23-0066"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.xuxueli:xxl-job-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-43183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-21T22:33:41Z",
    "nvd_published_at": "2022-11-17T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "XXL-Job before v2.4.0 contains a Server-Side Request Forgery (SSRF) via the component /admin/controller/JobLogController.java.",
  "id": "GHSA-83w4-x5w9-hf4h",
  "modified": "2025-07-18T18:04:13Z",
  "published": "2022-11-17T21:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xuxueli/xxl-job/issues/3002"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xuxueli/xxl-job/commit/9293c61ca0a8d54afdfb27cc568885ae639a14dc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xuxueli/xxl-job"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xuxueli/xxl-job/releases/tag/2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "XXL-JOB vulnerable to Server-Side Request Forgery (SSRF)"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-1857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-18T07:16:09Z",
    "severity": "MODERATE"
  },
  "details": "The Gutenberg Blocks with AI by Kadence WP plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.6.1. This is due to insufficient validation of the `endpoint` parameter in the `get_items()` function of the GetResponse REST API handler. The endpoint\u0027s permission check only requires `edit_posts` capability (Contributor role) rather than `manage_options` (Administrator). This makes it possible for authenticated attackers, with Contributor-level access and above, to make server-side requests to arbitrary endpoints on the configured GetResponse API server, retrieving sensitive data such as contacts, campaigns, and mailing lists using the site\u0027s stored API credentials. The stored API key is also leaked in the request headers.",
  "id": "GHSA-8425-76gw-qxj4",
  "modified": "2026-02-18T09:31:03Z",
  "published": "2026-02-18T09:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1857"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/kadence-blocks/tags/3.5.32/includes/advanced-form/getresponse-rest-api.php#L57"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/kadence-blocks/tags/3.5.32/includes/advanced-form/getresponse-rest-api.php#L77"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3454881%40kadence-blocks%2Ftrunk\u0026old=3453204%40kadence-blocks%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2ea8d38a-f5ce-40dd-a015-f56d60579e05?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}