Axios proxy, SSH constraint, and vLLM runtime-channel boundary checks¶

Sources: hourly offensive-security scan, 2026-07-17 GitHub Security Advisory feeds. Primary entries: GHSA-pjwm-pj3p-43mv, GHSA-45gg-vh54-h5m9, GHSA-f5wc-c3c7-36mc, GHSA-5cgq-3rg8-m6cv, GHSA-x527-x647-q7gg, GHSA-hjq4-87xh-g4fv, GHSA-9pcc-gvx5-r5wm, GHSA-9f8f-2vmf-885j, GHSA-mrw7-hf4f-83pf, GHSA-94f4-hr76-p5j6, and GHSA-6c4r-fmh3-7rh8. Nearby vLLM DoS-only entries (GHSA-v82g-2437-67m2, GHSA-rwxx-mrjm-wc2m, and GHSA-8wr5-jm2h-8r4f) are tracked here only as scope context, not standalone exploit-path guidance.

This batch is durable for operators because the advisories expose reusable boundary classes: URL canonicalization before proxy/no-proxy routing, SSH certificate and agent constraints dropped across multi-step authentication or key forwarding, AI inference runtime channels that deserialize or broadcast data on unintended network interfaces, ASGI Host header parsing drift before API-key checks, audio/image preprocessing differentials where human-reviewed media is not the signal an AI model receives, model artifact revision pins that decay across side artifacts, assert-stripped model configuration checks, and GPU tensor conversion paths that can expose stale multi-tenant state.

July 17 follow-up vLLM updates added GHSA-8jr5-v98p-w75m, GHSA-3ww4-5jv9-j5gm, GHSA-q8gq-377p-jq3r, GHSA-5jv2-g5wq-cmr4, GHSA-qh4c-xf7m-gxfc, GHSA-v359-jj2v-j536, GHSA-pf3h-qjgv-vcpr, GHSA-2pc9-4j83-qjmr, GHSA-8fr4-5q9j-m8gm, and GHSA-7972-pg2x-xr59. Adjacent resource-exhaustion-only vLLM entries (GHSA-7h4p-rffg-7823, GHSA-6pr9-rp53-2pmc, GHSA-3mwp-wvh9-7528, GHSA-hpv8-x276-m59f, GHSA-vrq3-r879-7m65, GHSA-wr9h-g72x-mwhm, and the earlier upload/regex/token DoS advisories) are tracked here only as limit-check context unless they are paired with an approved lab resilience exercise.

The July 20 Axios follow-ups add GHSA-xj6q-8x83-jv6g, GHSA-gcfj-64vw-6mp9, GHSA-7q8q-rj6j-mhjq, GHSA-mmx7-hfxf-jppx, and GHSA-f4gw-2p7v-4548. They extend the same theme from inherited Basic-auth subfields to interceptor-cloned proxy config, nested serializer values, bodies on bodyless aliases, and 0.0.0.0 proxy routing. The adjacent serializer recursion and streamed-upload limit records are tracked only as availability/policy-limit context.

What changed¶

Replayable validation boundaries¶

Axios NO_PROXY IPv4-mapped IPv6 checks¶

1. Build a local harness with an Axios version in scope, a configured HTTP proxy you control, and NO_PROXY entries for internal IPv4 canaries such as 127.0.0.1 or a documentation-range lab address.
2. Start an owned HTTP canary on the destination and a fake proxy that logs only method, host, and path.
3. Compare three request forms:
4. canonical IPv4 URL expected to bypass the proxy;
5. bracketed IPv4-mapped IPv6 URL for the same host;
6. patched Axios or a hardened proxy policy as the negative control.
7. Evidence should show whether the IPv4-mapped form routes through the proxy even though the same underlying destination is intended to be covered by NO_PROXY.
8. Do not use cloud metadata or internal production admin hosts as proof targets. If a customer wants metadata validation, use a metadata-simulator endpoint under their written scope.

Report this as URL host canonicalization mismatch -> NO_PROXY decision -> proxy-mediated access to an internal IPv4 destination. Include Axios version, proxy environment variables, parsed host forms, and proxy/canary logs.

Axios inherited Basic-auth subfield checks¶

1. Confirm both preconditions before testing: the host application has a separate, in-scope prototype-pollution primitive, and its Axios wrapper passes an own empty or partial object such as auth: {} or auth: opts.auth || {}. Merely installing Axios is not enough.
2. Use an affected Axios release (>=1.15.2,<1.18.0) in a disposable Node.js harness. Point requests only at a loopback HTTP capture server and use unmistakably fake username/password canaries.
3. Pollute only Object.prototype.username and/or Object.prototype.password inside the harness, then compare:
4. no own auth object;
5. an own empty auth: {} object;
6. a partial own object with only one real canary subfield;
7. a complete own object;
8. Axios 1.18.0 or later as the patched control.
9. Capture the outbound Authorization header locally, decode it offline, and verify which values were own properties versus inherited values. Clean the prototype in a finally block and terminate the disposable process after each case so state cannot leak between tests.
10. If the wrapper sets a pre-existing Authorization header, add a fake bearer-marker control and record whether Axios replaces it when auth is materialized. Do not use real tokens or send the request to an external collector.

Report this as separate host-process prototype pollution -> inherited Axios auth subfield read -> attacker-chosen Basic-auth request tampering. Do not describe Axios as the pollution source, and do not claim credential disclosure unless an independent application-specific path proves that a real missing auth field reaches an attacker-observable destination.

For the new proxy/body/serializer variants, reuse the disposable process but add an interceptor that returns {...config}, fake inherited proxy, paramsSerializer, and data values, and a loopback origin plus fake HTTP proxy. Test each property in a fresh process and clean Object.prototype in finally. Positive evidence must identify the exact gadget: interceptor clone routes a plaintext request through the fake proxy; nested serializer changes only the synthetic query; or a bodyless alias emits the marker body. For 0.0.0.0, compare localhost, 127.0.0.1, [::1], and 0.0.0.0 under the same NO_PROXY and redirect configuration. Never place real authorization headers or request bodies in the harness.

Go SSH certificate and agent-constraint checks¶

1. Use a disposable SSH server built on golang.org/x/crypto/ssh, disposable client keys, and an isolated agent. Never forward a real operator agent into the harness.
2. Create canary certificates with explicit restrictions: source-address, force-command, principals, and a revoked CA/signature-key control where relevant.
3. Exercise the authentication composition used by the target, especially public-key plus keyboard-interactive or other flows that can return partial success.
4. For agent forwarding, add a key with a destination-restriction extension and confirm whether the remote agent view preserves or silently drops that constraint.
5. Record accept/deny decisions only. Avoid opening a real shell, touching bastions, or proving impact with production commands.

Report this as SSH auth callback or agent-forwarding serialization -> certificate/agent restriction dropped -> canary login or key-use decision differs from policy. Strong evidence is a decision table with vulnerable, fixed, and policy-negative controls.

vLLM runtime-channel and prompt-embedding checks¶

1. Restrict testing to isolated vLLM labs or explicitly approved AI infrastructure. Prefer a two-node lab with fake prompts and a tiny disposable model.
2. Inventory runtime channels before sending payloads: V0 versus V1 engine, tensor parallelism across hosts, PyNcclPipe KV-cache transfer, ZeroMQ ports, TCPStore bind addresses, and Completions API prompt-embedding upload paths.
3. For PyNcclPipe and ZeroMQ, first prove network reachability with socket banners, connection outcomes, or harmless subscription markers. Do not send weaponized pickle payloads outside a lab.
4. For ZeroMQ broadcast exposure, subscribe with a lab client and capture only synthetic marker traffic generated by the test harness. Do not collect live prompts, hidden states, tensors, or tenant data.
5. For prompt embeddings, use a standalone harness or disposable worker with synthetic sparse tensors designed to exercise validation decisions, not a production inference endpoint. Preserve crash/memory evidence locally and avoid publishing binary payloads.
6. Repeat against patched versions or V1/non-multi-node configurations as negative controls.

Report this as AI worker runtime channel -> unauthenticated network reachability -> deserialization or internal-state exposure, or Completions prompt-embedding upload -> tensor parser boundary -> controlled crash/memory-safety evidence in lab.

vLLM OpenAI API-key middleware parser checks¶

1. Only test vLLM endpoints you own or where the customer explicitly approved direct API-gateway validation. Do not attempt to bypass production API keys to access real models or prompts.
2. Build a local or customer-provided lab with an affected vLLM version, an OpenAI-compatible route such as /v1/models, and a configured VLLM_API_KEY/--api-key.
3. Send four decision-table requests:
4. normal /v1/... without Authorization expected to return 401;
5. normal /v1/... with a fake/wrong key expected to return 401;
6. normal /v1/... with the lab key expected to return success;
7. malformed Host variants containing URL special characters such as / or ?, without a valid key, expected to demonstrate whether middleware path reconstruction differs from router path selection.
8. Repeat through an RFC-conforming reverse proxy such as nginx as a negative control when that matches the target architecture; the advisory notes proxy-fronted deployments may not be affected.
9. Evidence should be status codes, request-line/Host/path parsing, and harmless route results only. Do not run inference, enumerate private models beyond a synthetic lab fixture, or collect prompts.

Report this as ASGI Host header URL reconstruction -> API-key middleware path check -> OpenAI route reached without expected authorization. Include the vLLM version, ASGI server, direct-vs-proxied topology, exact redacted request bytes, and negative controls.

vLLM audio preprocessing differential checks¶

1. Scope this to audio-enabled vLLM labs, moderation sandboxes, or voice-auth test tenants using synthetic voices and synthetic content. Never use real user recordings or biometric enrollment material.
2. Create short multi-channel fixtures with:
3. benign front left/right channels;
4. a controlled marker or interference signal in LFE, rear, overhead, or otherwise unsupported/extra channels;
5. a stereo-only negative control containing the same benign front-channel content.
6. Compare three views of each fixture:
7. what normal playback surfaces to a human tester on common speakers/headphones;
8. a reference downmix that follows the target policy or ITU-style weighting expected by the assessment;
9. the vLLM/audio-model preprocessing and resulting transcript, moderation label, or voice-auth decision.
10. Keep markers harmless: use synthetic words, tones, or nonsense tokens. Do not hide real abusive content, authentication phrases, payment instructions, or social-engineering audio.
11. A strong proof shows a policy-relevant mismatch: the human/reviewer path appears benign while the model path receives or misses the controlled marker due to channel handling.

Report this as multi-channel audio fixture -> downmix/preprocessing differential -> model-visible content differs from human-visible content. Include the audio channel layout, fixture hash, preprocessing library/path, transcript/label decision table, and stereo/patched/reference controls.

vLLM image preprocessing differential checks¶

1. Scope this to owned multimodal vLLM labs or explicitly approved model-safety test tenants. Use synthetic images only.
2. Build a small fixture set that covers:
3. JPEG or TIFF EXIF orientation where the stored pixels and human-preview orientation differ;
4. PNG P, L, or RGB + tRNS files where transparent marker pixels become visible or change color after naive convert("RGB");
5. APNG/GIF files where later frames contain a harmless marker while the first frame is benign.
6. Capture three outputs for each fixture: browser/image-viewer preview, a reference-normalized image using explicit EXIF transpose plus transparency compositing, and the tensor/image bytes passed into the vLLM model path.
7. Use harmless labels, shapes, or short marker text. Do not hide abusive prompts, credentials, biometric material, or policy-evading content.
8. A strong proof shows the model acts on pixels that the review or moderation path did not display, or misses pixels a human reviewer did see.

Report this as image container metadata -> preprocessing normalization gap -> model-visible pixels differ from human-visible pixels. Include fixture hashes, mode/metadata, reference-normalization code, model-input capture, and patched controls.

vLLM artifact pin propagation checks¶

1. Start from a disposable vLLM worker and a private or local Hugging Face-style repository containing only inert config, weights, processor files, and dynamic-module canaries.
2. Pin the primary model with --revision and, where relevant, --code-revision; then make side artifacts differ between the pinned commit and default branch.
3. Exercise artifact families called out by the advisories: external auto_map dynamic modules, direct-file GGUF loads, image processors, retrieval side weights, and same-repository subfolder configs/weights.
4. Evidence should be resolved commit SHAs, cache paths, and inert marker values showing whether each artifact came from the reviewed pin or a floating revision.
5. Negative controls should include patched vLLM, explicit side-artifact pins if supported, and network/cache isolation that prevents fallback to unreviewed artifacts.

Report this as operator-supplied model revision pin -> side artifact resolver omits pin -> unreviewed code/config/weights loaded into serving worker. Do not use malicious model code or public attacker-controlled models in customer environments.

vLLM model-config import guard checks¶

1. Only test in a disposable worker launched with known Python flags. Record whether PYTHONOPTIMIZE or python -O is active.
2. Create a local model/config fixture whose activation function fields point first to an allowed torch.nn.modules.* class, then to an inert local module/class that would only write a marker if imported or instantiated.
3. Compare normal Python mode, optimized mode, and patched vLLM. The expected vulnerable pattern is rejection in normal mode but import/instantiation reachability in optimized mode because assert statements were stripped.
4. Keep canaries local and inert. Do not publish configs that import shells, network clients, credential readers, or destructive modules.

Report this as model configuration string -> assert-stripped security check -> unrestricted Python import/constructor path in optimized worker. Include launch flags, config fields, import trace, and negative controls.

vLLM GGUF GPU stale-memory checks¶

1. Restrict this to isolated multi-tenant GPU labs with no real user traffic and a worker you can reset after testing.
2. Seed GPU memory with a synthetic prior-request marker tensor, then load a crafted GGUF fixture whose dimensions exercise the 32-bit element-count truncation boundary in the dequantize path.
3. Capture only whether the output contains the synthetic marker or uninitialized nonzero regions. Never attempt to recover prompts, embeddings, logits, KV cache, or another tenant's model data.
4. Repeat after a worker restart and against patched kernels or bounded dimension checks to prove the signal is stale-memory exposure, not deterministic fixture content.

Report this as GGUF tensor dimensions -> 32-bit kernel count truncation -> uninitialized GPU output reveals prior synthetic marker. Include GPU model, vLLM version, fixture dimensions, marker-only evidence, and reset/patched controls.

vLLM media and batch SSRF checks¶

1. Scope testing to owned vLLM labs or explicitly approved customer AI gateways. Never target metadata endpoints or internal production services.
2. Inventory every URL-bearing ingestion path separately: multimodal chat media, MediaConnector.load_from_url(_async), OpenAI batch JSON, and any wrapper that fetches images, audio, or documents before inference.
3. Use owned callbacks, synthetic local HTTP services, and redirectors. Exercise ordinary URLs, backslash/userinfo host-confusion forms, encoded separators, redirects, and patched controls.
4. Compare the validator's parsed host with the HTTP client's final destination. Evidence should be request logs and parser decision tables only.
5. For batch runners, prove that batch JSON can trigger a fetch from the worker context with a harmless marker response; do not read files, metadata, service banners, or internal application pages.

Report this as AI media/batch URL -> validator/client parser mismatch or missing IP guard -> server-side fetch from worker network. Include the exact ingestion path, parser outputs, callback log, final destination, and negative controls.

vLLM model remote-code trust checks¶

1. Use disposable local or private Hugging Face-style repositories with inert marker modules only. Do not load public untrusted model code on production workers.
2. Create fixtures for top-level auto_map, nested config-class auto_map, cross-repository auto_map, and model-specific subcomponent loaders that may pass their own trust_remote_code value.
3. Launch workers with trust_remote_code=False and record import traces, resolved repository revisions, and whether any marker module is imported or instantiated.
4. Repeat with patched versions and with explicit trust enabled as a positive control so the report separates intended remote-code trust from bypass.
5. Evidence should be local import traces and marker files, never shell commands, network callbacks, credential reads, or destructive code.

Report this as model config/repository metadata -> remote dynamic module loader -> trust flag not enforced on startup or subcomponent path. Include the config field, loader path, CLI flags, resolved commit/cache path, and fixed behavior.

September 4 follow-up: derender output bounds, error-path disclosure, and structured-output guard siblings (4 GHSAs)¶

A 2026-09-04 vLLM cluster adds four entries that extend this page's runtime-channel and parser-differential themes: GHSA-hwrm-c4cx-rf4j / CVE-2026-73555, GHSA-48jh-3gj7-fg8v / CVE-2026-73556, GHSA-8737-qx52-hjff / CVE-2026-71486, and GHSA-pr7f-p5mw-fc87 / CVE-2026-73557. All are patched in vLLM 0.26.0.

Replayable validation boundaries¶

Error-path information disclosure (GHSA-hwrm-c4cx-rf4j).

1. Send one malformed-JSON or missing-field body to each /v1 POST endpoint (/v1/chat/completions, /v1/completions, /tokenize, /detokenize).
2. Record the full error body. A positive is a File "...", line N pattern or OS username/home-dir/venv path in the response.
3. Compare with the response body of a request that triggers a handled (non-exception) error to confirm the leak is specific to the exception handler's str(exc) path.
4. This is a read-only recon primitive: it fingerprints vLLM version and host layout without authentication. Do not combine it with real exploit attempts.

Structured-output backend coverage (GHSA-48jh-3gj7-fg8v).

1. Confirm the operator's structured-output backend selection (--structured-outputs-config). The bug is specific to backend=lm-format-enforcer; xgrammar and outlines are bounded.
2. With a lab vLLM using backend=lm-format-enforcer, submit a single /v1/completions request with structured_outputs.regex set to a catastrophic pattern (e.g. (a{1,300}){300}) and record that the request does not return while a control core is pegged.
3. Negative control: the identical request against backend=outlines or backend=xgrammar returns a clean, bounded error via compile_regex_with_timeout.
4. Report as per-backend ReDoS patch left one shared-primitive backend unguarded. Keep the proof to timing/timeout evidence; do not run the payload against a production engine.

Derender unbounded-output (GHSA-8737-qx52-hjff).

1. Confirm the target build exposes /v1/completions/derender or /v1/chat/completions/derender (introduced by the disaggregated-render PR; not in v0.23.0).
2. Submit a derender request with generate_responses containing nested choices[*].token_ids lists far larger than any generation-side budget (e.g. 16 responses × 4 choices × 8192 tokens) and record CPU/memory growth and response size.
3. Negative control: the same token budget passed through the normal /v1/completions generate path is bounded by max_tokens/max_model_len.
4. Report as client-supplied generated-output shape bypasses generation-side resource bounds at the post-processing stage. Use bounded payloads; do not attempt to crash a shared production frontend.

Concurrent prompt-embedding guard bypass (GHSA-pr7f-p5mw-fc87).

1. Preconditions: --enable-prompt-embeds enabled, no API-key middleware (stock default), PyTorch pin in the affected range. Record whether renderer_num_workers is default (1) — the bypass does not need a multi-worker renderer.
2. In a lab worker, build one /v1/chat/completions request with two prompt_embeds content parts: part A a benign valid embedding, part B the invalid sparse payload that the guarded loader rejects under serial execution.
3. Let both parts schedule on the event-loop default executor concurrently. The positive evidence is part B's torch.load(..., weights_only=True) observing the global invariant flag disabled and reconstructing the malformed sparse tensor, reaching to_dense() before later validation.
4. Negative controls: the identical two-part request in a patched build (or with a shared process-wide lock), and a serial single-part request where the guard holds.
5. Do not publish the sparse payload; report the concurrency interleaving (save/enable/restore of the process-global flag across two parts) and the guarded-sink reachability. RCE/memory-corruption consequences remain conditional on the historical CVE-2025-62164 behavior; do not claim them without a reproduced crash.

Durable operator value¶

1. Error handlers are a fingerprinting surface. Any framework that renders str(exception) into an HTTP response leaks file paths, usernames, and version-specific line numbers. Audit malformed-input error bodies on every unauthenticated endpoint, not just the happy-path auth checks.
2. Per-backend fixes leave sibling backends exposed. When a DoS/ReDoS is patched in one of N interchangeable backends, the audit must enumerate every backend that shares the vulnerable primitive. The patched backend is the negative control, not the proof of safety.
3. "Already-generated" input shapes defeat generation-side limits. Endpoints that accept the output of a pipeline (derender, post-processing, replay) from the client bypass every limit that the generating stage enforced. Validate the replayed structure against the same budgets.
4. Global-flag guards are a concurrency primitive. Any fix that wraps a deserialization sink in a save/enable/restore context over process-global state is raceable by concurrent request parts. Test the guarded region with two concurrent actors sharing one process.

Operator checklist¶

• Did the proof use owned canary infrastructure rather than metadata/internal production hosts?
• For Axios Basic-auth checks, are the separate pollution primitive and own empty/partial auth object both proven, with fake credentials and a patched control?
• Are URL host forms, proxy decisions, and destination equivalence shown side by side?
• Are SSH certificate restrictions and agent constraints represented as explicit allow/deny decision tables?
• Is the vLLM deployment actually using the affected engine/channel/API path, rather than only a vulnerable package version?
• For vLLM API-key checks, is the deployment directly exposed to the ASGI server path, or is a standards-compliant reverse proxy normalizing Host first?
• For audio checks, did the report compare human playback, reference downmix, and model-visible transcript/decision using synthetic fixtures only?
• For image checks, did the report compare human preview, reference-normalized pixels, and model-visible pixels with synthetic fixtures only?
• For revision-pin checks, did every loaded side artifact have a resolved commit/cache path, not just the primary model?
• For model-config import checks, did the proof show Python optimized mode and use inert local modules only?
• For GPU stale-memory checks, did the evidence stop at synthetic marker recovery in an isolated lab?
• For media/batch SSRF checks, did the proof stop at owned callbacks or synthetic local services and include final-destination parser evidence?
• For remote-code trust checks, did every imported module come from an inert local/private fixture and prove trust_remote_code=False was actually set?
• Are all payloads inert, non-sensitive, and reproducible in a lab?

Reporting notes¶

• Lead with the trust boundary that failed: URL canonicalization, inherited Axios auth subfields after separate prototype pollution, SSH restriction propagation, AI runtime-channel isolation, ASGI path reconstruction before API-key enforcement, media preprocessing before model trust, model artifact pin propagation, model-config import authorization, AI media/batch SSRF destination control, model remote-code trust flags, or GPU tensor initialization.
• Separate reachability from code execution. For vLLM, a high-quality report first proves the unintended channel is exposed, then uses lab-only markers to show the parser or broadcast effect.
• Redact proxy credentials, SSH key material, tokens, model names, cluster hostnames, and any customer topology that is not necessary to reproduce the decision boundary.