{"answers":{"affected":"","exploited":"It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-80347 exists.","fix":"No fix has been published for CVE-2026-80347 yet. Limit exposure of the affected software until one is available.","what":"CVE-2026-80347 is a high-severity server-side request forgery vulnerability in kazuph mcp-fetch, published on 26 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-80347 and fix it if it is affected.\n\nWhat it is: CVE-2026-80347 is a high-severity server-side request forgery vulnerability in kazuph mcp-fetch, published on 26 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-80347 exists.\n\nAffected product: kazuph mcp-fetch. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-80347/ (Markdown: https://insights.sbomify.com/CVE-2026-80347/index.md)","id":"CVE-2026-80347","markdown":"https://insights.sbomify.com/CVE-2026-80347/index.md","name":"CVE-2026-80347","record":{"aliases":["GHSA-mqq2-4r9w-4h99"],"analysis":{"component_type":"library","fix_type":"patch","impacts":["data_read"],"network_reachable":"yes","non_default_config":false,"product_category":"MCP fetch library","requires_auth":"none","summary":"An attacker can bypass SSRF protections in mcp-fetch to read internal network resources by using IPv6 literal brackets, exposing sensitive data to the model context.","user_interaction":"not_required","vuln_class":"ssrf"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"VulnCheck","cpe":[],"cvss":{"score":8.7,"severity":"high","source":"cna","vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N","version":"4.0"},"cwes":[{"id":"CWE-918","name":"Server-Side Request Forgery"}],"description":"mcp-fetch checks a fetch target against its SSRF guard without removing the brackets that surround an IPv6 literal. isSafeUrl reads the hostname from the parsed URL, which for a literal such as http://[::1]/ yields the bracketed string, and then tests it with net.isIP. That call returns zero for a bracketed value, so the branch holding the private-address checks is skipped entirely. The guard falls back to resolving the hostname, the bracketed string is not a resolvable name, no addresses are returned, and the target is reported safe. The HTTP client then strips the brackets and connects. Because the address may be given in IPv4-mapped form, the same path reaches any IPv4 target the loopback and private checks were meant to exclude, including link-local metadata endpoints. isPrivateIPv6 also has no case for the ::ffff: prefix, so the mapped form would still pass even if the brackets were removed. The fetch target is supplied as a tool argument, so an attacker who can influence what the model requests can read internal responses back into the model context.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"weaponised"},"has_fix":false,"headline":"mcp-fetch through 1.6.3 Server-Side Request Forgery via Unstripped IPv6 Literal Brackets","id":"CVE-2026-80347","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"ssrf","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"TarsWeb through 3.0.16 Missing Authorization on Patch Deploy, Download and Delete Endpoints","id":"CVE-2026-80348"},"packages":[],"prev":{"headline":"StarRocks through 4.0.13 Missing Authorization on DROP MATERIALIZED VIEW for Legacy Synchronous Materialized Views","id":"CVE-2026-80346"},"products":["mcp-fetch"],"published":"2026-08-26","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"yes","exploitation":"poc","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-26","vendors":["kazuph"]},"summary":"An attacker can bypass SSRF protections in mcp-fetch to read internal network resources by using IPv6 literal brackets, exposing sensitive data to the model context.","url":"https://insights.sbomify.com/CVE-2026-80347/"}