CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
6271 vulnerabilities reference this CWE, most recent first.
GHSA-4GM2-V7J4-74P8
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2026-02-18 18:30When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is disabled
{
"affected": [],
"aliases": [
"CVE-2021-22175"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T16:15:00Z",
"severity": "CRITICAL"
},
"details": "When requests to the internal network for webhooks are enabled, a server-side request forgery vulnerability in GitLab affecting all versions starting from 10.5 was possible to exploit for an unauthenticated attacker even on a GitLab instance where registration is disabled",
"id": "GHSA-4gm2-v7j4-74p8",
"modified": "2026-02-18T18:30:19Z",
"published": "2022-05-24T19:05:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22175"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1059596"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22175.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/294178"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-22175"
}
],
"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"
}
]
}
GHSA-4GP8-RJRQ-CH6Q
Vulnerability from github – Published: 2026-05-05 20:13 – Updated: 2026-05-13 14:20Impact
The library did not check for IPv6 loopback attacks. There was also a DNS attack, where an address could be resolved into an internal IP. This could cause internal data leaks.
Patches
Problem has been patched in version 4.0.1. However, it cannot be completely solved by the package alone. The regex used for validation has been tightened for IPv6 addresses.
The DNS resolving, however, is more difficult. The regex has been tightened to prohibit .internal, .local, .nip.io and .sslip.io addresses, however there can be other services not on the list, therefore it is imperative that users use the resolveDNSHost option to do DNS resolution before fetching content. To that regard a (scary) error message has been added when the option is not set.
Workarounds
Users can do their own validation before fetching content.
Reported by https://github.com/Andrew-most-likely
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.0"
},
"package": {
"ecosystem": "npm",
"name": "link-preview-js"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43897"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T20:13:02Z",
"nvd_published_at": "2026-05-11T22:22:14Z",
"severity": "HIGH"
},
"details": "### Impact\nThe library did not check for IPv6 loopback attacks. There was also a DNS attack, where an address could be resolved into an internal IP. This could cause internal data leaks.\n\n### Patches\nProblem has been patched in version 4.0.1. However, it cannot be completely solved by the package alone. The regex used for validation has been tightened for IPv6 addresses. \n\nThe DNS resolving, however, is more difficult. The regex has been tightened to prohibit .internal, .local, .nip.io and .sslip.io addresses, however there can be other services not on the list, therefore it is imperative that users use the resolveDNSHost option to do DNS resolution before fetching content. To that regard a (scary) error message has been added when the option is not set.\n\n### Workarounds\nUsers can do their own validation before fetching content.\n\nReported by https://github.com/Andrew-most-likely",
"id": "GHSA-4gp8-rjrq-ch6q",
"modified": "2026-05-13T14:20:09Z",
"published": "2026-05-05T20:13:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OP-Engineering/link-preview-js/security/advisories/GHSA-4gp8-rjrq-ch6q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43897"
},
{
"type": "WEB",
"url": "https://github.com/OP-Engineering/link-preview-js/pull/179"
},
{
"type": "WEB",
"url": "https://github.com/OP-Engineering/link-preview-js/commit/4396d48909fab37553c0e93e26447fe218363ede"
},
{
"type": "PACKAGE",
"url": "https://github.com/OP-Engineering/link-preview-js"
},
{
"type": "WEB",
"url": "https://github.com/OP-Engineering/link-preview-js/releases/tag/4.0.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "link-preview-js vulnerable to IPv6 and internal loopback attacks"
}
GHSA-4GWR-3V6M-22JJ
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40JetBrains TeamCity Plugin before 2020.2.85695 SSRF. Vulnerability that could potentially expose user credentials.
{
"affected": [],
"aliases": [
"CVE-2020-35667"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-03T16:15:00Z",
"severity": "HIGH"
},
"details": "JetBrains TeamCity Plugin before 2020.2.85695 SSRF. Vulnerability that could potentially expose user credentials.",
"id": "GHSA-4gwr-3v6m-22jj",
"modified": "2022-05-24T17:40:49Z",
"published": "2022-05-24T17:40:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35667"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2021/02/03/jetbrains-security-bulletin-q4-2020"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4H4F-V54Q-7PQ8
Vulnerability from github – Published: 2026-07-06 09:30 – Updated: 2026-08-28 21:52Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component.
The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam. headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField. headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam. and SolrField. headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-solr"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.14.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-solr"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-solr"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48203"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T21:52:11Z",
"nvd_published_at": "2026-07-06T09:16:37Z",
"severity": "CRITICAL"
},
"details": "Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component.\n\nThe camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField.* headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging consumer is unauthenticated.\nThis issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.\n\nUsers are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam.* and SolrField.* headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.",
"id": "GHSA-4h4f-v54q-7pq8",
"modified": "2026-08-28T21:52:11Z",
"published": "2026-07-06T09:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48203"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23410"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23483"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/23489"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/4578a9014a6b7a914cf16baf2c5bf62a7b163a88"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/cfc0d51f015b3112eae4ce0968d045f00e95c796"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/f79cbe3f8bc3fe1095d8492e9ef321289451d457"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.14.8"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.18.3"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.21.0"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-23597"
},
{
"type": "WEB",
"url": "http://camel.apache.org/security/CVE-2026-48203.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/05/17"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Camel-Solr: The SolrParam. and SolrField. Exchange header prefixes used non-Camel-prefixed names that bypass the HTTP header filter, allowing an HTTP client to inject Solr query parameters (server-side request forgery) and document fields"
}
GHSA-4HHP-H66F-J5J7
Vulnerability from github – Published: 2026-09-08 20:42 – Updated: 2026-09-08 20:42Summary
vllm/transformers_utils/processors/mimo_v2_omni.py — the multimodal processor for MiMoV2OmniForCausalLM — issues requests.get(...) directly on user-supplied image and audio URL strings and Image.open(...) on user-supplied local paths, without the SSRF / allowed_local_media_path checks that vllm.multimodal.utils.MediaConnector was hardened with in GHSA-qh4c-xf7m-gxfc, GHSA-v359-jj2v-j536, and GHSA-pf3h-qjgv-vcpr.
This is the same bug class as those three published advisories, in a code path the patches missed. When a user passes a URL or local-file string through multi_modal_data (e.g. LLM.generate(multi_modal_data={"image": "http://..."})), the processor takes the unsanitized string and dispatches it without any URL-scheme allowlist, network-target allowlist, size cap, or local-path allowlist.
Details
File: vllm/transformers_utils/processors/mimo_v2_omni.py (current main)
Sink 1 — image SSRF + local-file read (_fetch_image, lines 231–249):
def _fetch_image(src: Any) -> Image.Image:
if isinstance(src, Image.Image):
return _to_rgb(src)
if isinstance(src, bytes):
return _to_rgb(copy.deepcopy(Image.open(BytesIO(src))))
if isinstance(src, str):
if src.startswith(("http://", "https://")):
r = requests.get(src, timeout=30) # SSRF: no allowlist, follows redirects
r.raise_for_status()
return _to_rgb(copy.deepcopy(Image.open(BytesIO(r.content))))
if src.startswith("file://"):
return _to_rgb(Image.open(src[7:])) # arbitrary local file read
if src.startswith("data:image"):
...
return _to_rgb(Image.open(src)) # fallback also opens local files
raise ValueError(f"Unrecognized image source: {type(src)}")
Sink 2 — audio SSRF (around line 471):
elif audio.startswith(("http://", "https://")):
r = requests.get(audio, timeout=30) # SSRF: same pattern
r.raise_for_status()
file_obj = io.BytesIO(r.content)
Reachability. _fetch_image is invoked from MiMoVLProcessor.process_image:
def process_image(self, image: ImageInput) -> torch.Tensor:
kw = self._resolve_img_kw(image)
src = image.image
if isinstance(src, (str, bytes)):
src = _fetch_image(src)
...
MiMoVLProcessor is wrapped by MiMoV2OmniMultiModalProcessor and registered for the MiMoV2OmniForCausalLM model architecture (vllm/model_executor/models/mimo_v2_omni.py:1169). Whenever a user passes a string into multi_modal_data["image"] (or ["audio"]) for this model, the unsanitized URL/path reaches the sink.
Comparison to the recent fixes. The remediation pattern adopted in the three earlier advisories was to route every external resource fetch through MediaConnector, which checks allowed_local_media_path and applies SSRF protection before issuing the network request. chat_utils.py (lines 838, 902, 924, 963, 1053, 1081) already uses self._connector.fetch_image / fetch_audio / fetch_video. The model processor in mimo_v2_omni.py was added later and skipped the connector — it calls requests.get and Image.open directly. Result: the public OpenAI chat-completion path is protected, but library use (LLM.generate(multi_modal_data=...)), batch processing, and any other path that lets a string reach the processor receive no protection.
Impact
- SSRF — internal-network probing / cloud-metadata theft. Standard
requests.getfollows redirects and accepts any URL. An attacker who controls amulti_modal_datavalue can: - read AWS / GCP / Azure instance metadata (e.g.
http://169.254.169.254/latest/meta-data/iam/security-credentials/), - probe internal services on the vLLM host (
http://127.0.0.1:<port>,http://10.x.y.z), - exfiltrate via DNS / HTTP timing oracles even when the body is rejected by
Image.open. - Arbitrary local file read via
file://path(line 242) and the unguarded fallbackImage.open(src)(line 248). Any file readable by the vLLM process is reachable through the model pipeline; with suitable formats this exposes/etc/passwd,~/.aws/credentials, etc. - Server-side traffic generation / amplification by hammering arbitrary URLs from the vLLM host, with a 30-second timeout per request.
Suggested remediation
Replace direct requests.get and bare Image.open paths with MediaConnector.fetch_image / fetch_audio_async (or pass the inputs through MediaConnector before they reach the processor):
# vllm/transformers_utils/processors/mimo_v2_omni.py
from vllm.multimodal.utils import MediaConnector
_connector = MediaConnector()
def _fetch_image(src):
if isinstance(src, Image.Image):
return _to_rgb(src)
if isinstance(src, bytes):
return _to_rgb(copy.deepcopy(Image.open(BytesIO(src))))
if isinstance(src, str):
return _to_rgb(_connector.fetch_image(src)) # delegates to the hardened path
raise ValueError(f"Unrecognized image source: {type(src)}")
Same change for the audio loader at line 471. This re-uses the SSRF allowlist, allowed_local_media_path policy, and size caps that the previous patches added.
Alternative: forbid str src from reaching the processor and require all multi-modal pre-processing to go through chat_utils.py / MediaConnector before hitting the model. Larger surface change, but completes the architectural fix.
Discovery
Static review on vllm@main (HEAD as of 2026-04-30) — found by triaging the file list against the three recent SSRF advisories: the mimo_v2_omni.py processor, added after those fixes, reintroduced the same bypass class.
Reporter
Ievgen Bondarenko — sactransport2000@gmail.com — GitHub @ibondarenko1
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73560"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:42:00Z",
"nvd_published_at": "2026-08-17T21:16:48Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`vllm/transformers_utils/processors/mimo_v2_omni.py` \u2014 the multimodal processor for `MiMoV2OmniForCausalLM` \u2014 issues `requests.get(...)` directly on user-supplied image and audio URL strings and `Image.open(...)` on user-supplied local paths, **without** the SSRF / `allowed_local_media_path` checks that `vllm.multimodal.utils.MediaConnector` was hardened with in **GHSA-qh4c-xf7m-gxfc**, **GHSA-v359-jj2v-j536**, and **GHSA-pf3h-qjgv-vcpr**.\n\nThis is the same bug class as those three published advisories, in a code path the patches missed. When a user passes a URL or local-file string through `multi_modal_data` (e.g. `LLM.generate(multi_modal_data={\"image\": \"http://...\"})`), the processor takes the unsanitized string and dispatches it without any URL-scheme allowlist, network-target allowlist, size cap, or local-path allowlist.\n\n### Details\n\n**File:** `vllm/transformers_utils/processors/mimo_v2_omni.py` (current `main`)\n\n**Sink 1 \u2014 image SSRF + local-file read (`_fetch_image`, lines 231\u2013249):**\n\n```python\ndef _fetch_image(src: Any) -\u003e Image.Image:\n if isinstance(src, Image.Image):\n return _to_rgb(src)\n if isinstance(src, bytes):\n return _to_rgb(copy.deepcopy(Image.open(BytesIO(src))))\n if isinstance(src, str):\n if src.startswith((\"http://\", \"https://\")):\n r = requests.get(src, timeout=30) # SSRF: no allowlist, follows redirects\n r.raise_for_status()\n return _to_rgb(copy.deepcopy(Image.open(BytesIO(r.content))))\n if src.startswith(\"file://\"):\n return _to_rgb(Image.open(src[7:])) # arbitrary local file read\n if src.startswith(\"data:image\"):\n ...\n return _to_rgb(Image.open(src)) # fallback also opens local files\n raise ValueError(f\"Unrecognized image source: {type(src)}\")\n```\n\n**Sink 2 \u2014 audio SSRF (around line 471):**\n\n```python\nelif audio.startswith((\"http://\", \"https://\")):\n r = requests.get(audio, timeout=30) # SSRF: same pattern\n r.raise_for_status()\n file_obj = io.BytesIO(r.content)\n```\n\n**Reachability.** `_fetch_image` is invoked from `MiMoVLProcessor.process_image`:\n\n```python\ndef process_image(self, image: ImageInput) -\u003e torch.Tensor:\n kw = self._resolve_img_kw(image)\n src = image.image\n if isinstance(src, (str, bytes)):\n src = _fetch_image(src)\n ...\n```\n\n`MiMoVLProcessor` is wrapped by `MiMoV2OmniMultiModalProcessor` and registered for the `MiMoV2OmniForCausalLM` model architecture (`vllm/model_executor/models/mimo_v2_omni.py:1169`). Whenever a user passes a string into `multi_modal_data[\"image\"]` (or `[\"audio\"]`) for this model, the unsanitized URL/path reaches the sink.\n\n**Comparison to the recent fixes.** The remediation pattern adopted in the three earlier advisories was to route every external resource fetch through `MediaConnector`, which checks `allowed_local_media_path` and applies SSRF protection before issuing the network request. `chat_utils.py` (lines 838, 902, 924, 963, 1053, 1081) already uses `self._connector.fetch_image / fetch_audio / fetch_video`. The model processor in `mimo_v2_omni.py` was added later and skipped the connector \u2014 it calls `requests.get` and `Image.open` directly. Result: the public OpenAI chat-completion path is protected, but library use (`LLM.generate(multi_modal_data=...)`), batch processing, and any other path that lets a string reach the processor receive no protection.\n\n### Impact\n\n1. **SSRF \u2014 internal-network probing / cloud-metadata theft.** Standard `requests.get` follows redirects and accepts any URL. An attacker who controls a `multi_modal_data` value can:\n - read AWS / GCP / Azure instance metadata (e.g. `http://169.254.169.254/latest/meta-data/iam/security-credentials/`),\n - probe internal services on the vLLM host (`http://127.0.0.1:\u003cport\u003e`, `http://10.x.y.z`),\n - exfiltrate via DNS / HTTP timing oracles even when the body is rejected by `Image.open`.\n2. **Arbitrary local file read** via `file://path` (line 242) and the unguarded fallback `Image.open(src)` (line 248). Any file readable by the vLLM process is reachable through the model pipeline; with suitable formats this exposes `/etc/passwd`, `~/.aws/credentials`, etc.\n3. **Server-side traffic generation / amplification** by hammering arbitrary URLs from the vLLM host, with a 30-second timeout per request.\n\n### Suggested remediation\n\nReplace direct `requests.get` and bare `Image.open` paths with `MediaConnector.fetch_image` / `fetch_audio_async` (or pass the inputs through `MediaConnector` before they reach the processor):\n\n```python\n# vllm/transformers_utils/processors/mimo_v2_omni.py\nfrom vllm.multimodal.utils import MediaConnector\n\n_connector = MediaConnector()\n\ndef _fetch_image(src):\n if isinstance(src, Image.Image):\n return _to_rgb(src)\n if isinstance(src, bytes):\n return _to_rgb(copy.deepcopy(Image.open(BytesIO(src))))\n if isinstance(src, str):\n return _to_rgb(_connector.fetch_image(src)) # delegates to the hardened path\n raise ValueError(f\"Unrecognized image source: {type(src)}\")\n```\n\nSame change for the audio loader at line 471. This re-uses the SSRF allowlist, `allowed_local_media_path` policy, and size caps that the previous patches added.\n\nAlternative: forbid `str` `src` from reaching the processor and require all multi-modal pre-processing to go through `chat_utils.py` / `MediaConnector` before hitting the model. Larger surface change, but completes the architectural fix.\n\n### Discovery\n\nStatic review on `vllm@main` (HEAD as of 2026-04-30) \u2014 found by triaging the file list against the three recent SSRF advisories: the `mimo_v2_omni.py` processor, added after those fixes, reintroduced the same bypass class.\n\n### Reporter\n\nIevgen Bondarenko \u2014 `sactransport2000@gmail.com` \u2014 GitHub `@ibondarenko1`",
"id": "GHSA-4hhp-h66f-j5j7",
"modified": "2026-09-08T20:42:00Z",
"published": "2026-09-08T20:42:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-4hhp-h66f-j5j7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73560"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/43117"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/54503ecec0f3ac31e5ecfc5f28652e4cc42307b5"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/releases/tag/v0.26.0"
}
],
"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"
}
],
"summary": "vLLM: SSRF + arbitrary local file read in MiMoV2OmniMultiModalProcessor `_fetch_image` and audio loader bypass MediaConnector protections"
}
GHSA-4HHQ-38M9-MGG7
Vulnerability from github – Published: 2026-05-29 18:31 – Updated: 2026-05-29 18:31MoviePilot v2 contains a server-side request forgery vulnerability in the image proxy endpoint that allows authenticated attackers to request arbitrary URLs by supplying a resource_token cookie and a URL whose domain matches the assembled allowlist. Attackers can bypass internal network protections because the SecurityUtils.is_safe_url function performs only domain-membership checking without blocking private, loopback, or link-local addresses, enabling enumeration of internal services such as Jellyfin, Emby, or Plex and exfiltration of data from internal network resources.
{
"affected": [],
"aliases": [
"CVE-2026-10107"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-29T18:16:31Z",
"severity": "HIGH"
},
"details": "MoviePilot v2 contains a server-side request forgery vulnerability in the image proxy endpoint that allows authenticated attackers to request arbitrary URLs by supplying a resource_token cookie and a URL whose domain matches the assembled allowlist. Attackers can bypass internal network protections because the SecurityUtils.is_safe_url function performs only domain-membership checking without blocking private, loopback, or link-local addresses, enabling enumeration of internal services such as Jellyfin, Emby, or Plex and exfiltration of data from internal network resources.",
"id": "GHSA-4hhq-38m9-mgg7",
"modified": "2026-05-29T18:31:35Z",
"published": "2026-05-29T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10107"
},
{
"type": "WEB",
"url": "https://github.com/jxxghp/MoviePilot/issues/5823"
},
{
"type": "WEB",
"url": "https://github.com/jxxghp/MoviePilot/commit/0b7854a0af8751160b68c43c46ded48d2bd8a212"
},
{
"type": "WEB",
"url": "https://github.com/jxxghp/MoviePilot/releases/tag/v2.13.2"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/moviepilot-v2-ssrf-via-api-v1-system-img-proxy-endpoint"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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-4HJQ-9XXM-GCG6
Vulnerability from github – Published: 2022-05-14 01:51 – Updated: 2022-05-14 01:51An SSRF issue was discovered in tecrail Responsive FileManager 9.13.4 via the upload.php url parameter. NOTE: this issue exists because of an incomplete fix for CVE-2018-15495.
{
"affected": [],
"aliases": [
"CVE-2018-18867"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-31T05:29:00Z",
"severity": "HIGH"
},
"details": "An SSRF issue was discovered in tecrail Responsive FileManager 9.13.4 via the upload.php url parameter. NOTE: this issue exists because of an incomplete fix for CVE-2018-15495.",
"id": "GHSA-4hjq-9xxm-gcg6",
"modified": "2022-05-14T01:51:59Z",
"published": "2022-05-14T01:51:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18867"
},
{
"type": "WEB",
"url": "https://github.com/trippo/ResponsiveFilemanager/issues/506"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4HW6-J957-CHCW
Vulnerability from github – Published: 2025-11-19 21:31 – Updated: 2025-11-19 21:31Server-Side Request Forgery (SSRF) vulnerability in Progress MOVEit Transfer.This issue affects MOVEit Transfer: before 2024.1.8, from 2025.0.0 before 2025.0.4.
{
"affected": [],
"aliases": [
"CVE-2025-13147"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-19T21:15:48Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Progress MOVEit Transfer.This issue affects MOVEit Transfer: before 2024.1.8, from 2025.0.0 before 2025.0.4.",
"id": "GHSA-4hw6-j957-chcw",
"modified": "2025-11-19T21:31:24Z",
"published": "2025-11-19T21:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13147"
},
{
"type": "WEB",
"url": "https://docs.progress.com/bundle/moveit-transfer-release-notes-2024/page/Fixed-Issues-in-2024.1.8.html"
},
{
"type": "WEB",
"url": "https://docs.progress.com/bundle/moveit-transfer-release-notes-2025/page/Fixed-Issues-in-2025.0.4.html"
},
{
"type": "WEB",
"url": "https://docs.progress.com/bundle/moveit-transfer-release-notes-2025_1/page/Fixed-Issues-in-2025.1.html"
}
],
"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-4HX9-P925-QCV7
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-24 17:45Server side request forgery (SSRF) in phpBB before 3.2.6 allows checking for the existence of files and services on the local network of the host through the remote avatar upload function.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpbb/phpbb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-11767"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T17:45:12Z",
"nvd_published_at": "2019-05-05T06:29:00Z",
"severity": "MODERATE"
},
"details": "Server side request forgery (SSRF) in phpBB before 3.2.6 allows checking for the existence of files and services on the local network of the host through the remote avatar upload function.",
"id": "GHSA-4hx9-p925-qcv7",
"modified": "2024-04-24T17:45:12Z",
"published": "2022-05-24T16:45:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11767"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpbb/phpbb-app"
},
{
"type": "WEB",
"url": "https://www.phpbb.com/community/viewtopic.php?f=14\u0026t=2509941"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpBB Server side request forgery (SSRF)"
}
GHSA-4J42-WQ8Q-C389
Vulnerability from github – Published: 2022-05-14 01:09 – Updated: 2022-05-14 01:09An issue was discovered in GitLab Community and Enterprise Edition before 11.6.10, 11.7.x before 11.7.6, and 11.8.x before 11.8.1. It allows SSRF.
{
"affected": [],
"aliases": [
"CVE-2019-9174"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-17T17:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in GitLab Community and Enterprise Edition before 11.6.10, 11.7.x before 11.7.6, and 11.8.x before 11.8.1. It allows SSRF.",
"id": "GHSA-4j42-wq8q-c389",
"modified": "2022-05-14T01:09:25Z",
"published": "2022-05-14T01:09:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9174"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/2019/03/04/security-release-gitlab-11-dot-8-dot-1-released"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/blog/categories/releases"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab-ce/issues/55468"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.