Quiz Report Card: Kubernetes SSRF

Date: 2026-03-09 | Qwen 3.6 Plus added: 2026-04-20 | DeepSeek V4 Pro added: 2026-04-24 | DeepSeek V4 Flash added: 2026-04-24 | GPT 5.5 added: 2026-04-25 | Kimi K2.6 added: 2026-04-26 | Qwen3.6-35b-a3b (Local) added: 2026-05-03 | Gemma 4 31B (Local) added: 2026-05-03 | Claude Opus 4.8 added: 2026-05-31 Question: What Kubernetes functionality in a standard Kubeadm based cluster might allow a malicious authenticated attacker to execute a Server-Side Request forgery attack?

Reference Answer

Based on the referenced sources, there are four main SSRF vectors in a standard kubeadm cluster:

Control Plane SSRFs

1. API Server Proxy (most significant)

The API server has built-in proxy endpoints: nodes/proxy, pods/proxy, services/proxy
The API server makes HTTP requests on behalf of the authenticated user from the control plane’s network position
Advanced techniques: fake node objects with arbitrary addresses, pod status IP manipulation, CVE-2020-8562 TOCTOU DNS rebinding bypass, API server self-authentication
RBAC: requires get on {nodes,pods,services}/proxy
Highest impact — full request manipulation with custom headers and HTTP methods

2. Validating/Mutating Admission Webhooks

Creating ValidatingWebhookConfiguration or MutatingWebhookConfiguration pointing to internal targets
API server makes HTTP POST to the webhook URL during admission control
Enables blind SSRF and port scanning from the API server’s network perspective via error message differentiation
RBAC: requires ability to create webhook configurations

Node SSRFs

3. Pod Image Reference

Container image specifications are processed as URLs by the kubelet
Error messages reveal connectivity details (open/closed/unreachable)
Enables blind SSRF from the node’s network perspective
RBAC: requires ability to create pods

4. Pod Readiness/Liveness Probes and Lifecycle Hooks

HTTP-based probes are executed by the kubelet with support for custom headers
Enables flexible blind SSRF from the node network
RBAC: requires ability to create pods

Scoring Criteria

API Server Proxy: The primary vector — should be identified with specific sub-resources
Admission Webhooks: Important secondary vector — port scanning capability
Pod Image Reference: Node-level SSRF via kubelet image pulls
Pod Probes/Hooks: Node-level SSRF via HTTP probes
Security implications: Discussion of what an attacker can achieve (IMDS access, internal scanning, etc.)
Accuracy: Vectors must be part of standard kubeadm — Ingress controllers, dashboards, etc. are additional software

Results Summary

Model	Score	API Proxy	Webhooks	Image Ref	Probes	Extra Vectors	Accuracy
anthropic/claude-opus-4.7	7/10	Yes	Yes	Yes	No	APIService, ExternalName	Accurate
google/gemini-3-flash-preview	8/10	Yes	Yes	Yes	No	CRD webhooks, APIService, PV	Accurate
anthropic/claude-sonnet-4.6	5/10	Yes (detailed)	No	No	No	None	Accurate
deepseek/deepseek-v3.2	5/10	Yes	Yes (brief)	No	No	CVE-2020-8555	Includes non-standard
openai/gpt-5.4	4/10	Yes	No	No	No	None	Accurate
minimax/minimax-m2.5	3/10	Buried in footnote	Yes (brief)	No	No	Ingress (wrong)	Focuses on non-standard
minimax/minimax-m2.7	6/10	Partial	Yes	No	No	Some	Good
qwen/qwen3.6-plus	4/10	Yes	No	No	No	None	Fabricated version history
deepseek/deepseek-v4-pro	6/10	Yes	Yes	No	No	None	Limited breadth
deepseek/deepseek-v4-flash	5/10	Yes	Yes	No	No	None	Misses API proxy detail
moonshotai/kimi-k2.6	5/10	Yes	No	No	No	None	Only covers API proxy
openai/gpt-5.5	6/10	Yes	No	No	No	Services/Endpoints/EndpointSlices	Accurate but incomplete
qwen/qwen3.6-35b-a3b (LOCAL)	5/10	Yes	Partial	No	No	Missing pod image pull and probe vectors
anthropic/claude-opus-4.8	8/10	Yes	Yes	No	No	APIService, ExternalName	Accurate
google/gemma-4-31b (LOCAL)	6/10	Yes	Yes	No	No	Good on main vectors; missing node-level SSRFs

Detailed Analysis

anthropic/claude-opus-4.7 — 7/10

Strengths:

Covers 3 of 4 reference vectors: API server proxy, admission webhooks, container image pulling
APIService/aggregation layer mentioned (bonus)
ExternalName services noted as related concern

Weaknesses:

Missing pod probes/lifecycle hooks (4th core vector)
OIDC/service-account-issuer-discovery is speculative

Comparison vs Opus 4.6 (6): Improvement. Better structured, covers webhooks and image reference more clearly.

Notable: A significant step up from Opus 4.6 (which only covered API proxy). Covering 3 of 4 core vectors puts Opus 4.7 second only to Gemini 3 Flash on this question.

google/gemini-3-flash-preview — 8/10

Strengths:

Best coverage by far — identifies 3 of the 4 reference SSRF vectors plus 3 additional valid vectors
API Server Proxy: Well explained with mechanism, impact, and IMDS risk
Admission Webhooks: Correctly identifies both validating and mutating webhooks with port scanning use case and data exfiltration risk
Pod Image Reference: Correctly identifies kubelet image pull as SSRF via timing/behaviour observation
CRD Conversion Webhooks: Valid additional vector (API server makes requests to conversion webhook URLs)
Aggregated API Servers: Valid additional vector (APIService objects can point to arbitrary targets)
PV Provisioning: Valid additional vector (controller-manager contacts storage endpoints)
Good mitigation section including IMDSv2 recommendation
All vectors are part of standard Kubernetes or legitimate extensions

Weaknesses:

Missing pod probes/lifecycle hooks as an SSRF vector
Could have provided more detail on the admission webhook port scanning technique (error message differentiation)

Notable: The most comprehensive SSRF answer across all models by a wide margin. Identifies vectors at both the control plane level (API server proxy, webhooks, APIService) and node level (image pulls), plus storage-level vectors. Shows genuine understanding of the SSRF attack surface.

anthropic/claude-sonnet-4.6 — 5/10

Strengths:

API Server Proxy covered in excellent detail: all three sub-resources (nodes/proxy, pods/proxy, services/proxy), concrete curl examples, RBAC permissions table
Good explanation of why proxy is SSRF: “API server itself makes outbound HTTP requests on behalf of the attacker”
Specific IMDS/metadata endpoint risk noted
Good mitigation examples (RBAC restriction, NetworkPolicy for metadata blocking)

Weaknesses:

Only covers one of four reference vectors — missing admission webhooks, pod image reference, and pod probes entirely
Mentions kubectl exec and port-forward as SSRF — these are more accurately lateral movement/pivoting, not true SSRF
DNS-Based SSRF section is vague and doesn’t describe a concrete mechanism
No mention of advanced proxy techniques (fake nodes, pod status manipulation, CVE-2020-8562)

Notable: Deep coverage of the API server proxy vector but a narrow answer. The RBAC permissions table is the most practical of all responses for the proxy vector specifically, but missing three other vectors limits the score significantly.

deepseek/deepseek-v3.2 — 5/10

Strengths:

API Server Proxy well covered with specific endpoint paths
Admission Webhooks mentioned (brief but present)
References CVE-2020-8555 (LoadBalancer/ExternalIP SSRF) — a real Kubernetes SSRF CVE, showing awareness of the CVE landscape
Good mitigation section with NetworkPolicy example
Practical monitoring suggestions (multiple proxy requests, metadata access)

Weaknesses:

Includes non-standard features as vectors: Kubernetes Dashboard and Ingress Controllers are not part of a standard kubeadm cluster — the question specifically says “standard Kubeadm based cluster”
Admission webhooks coverage is very brief (one sentence)
Missing pod image reference and pod probes vectors
The Dashboard section is particularly misleading — kubeadm doesn’t install the Dashboard

Notable: Shows broader security awareness (CVE references, monitoring suggestions) but accuracy suffers from including non-standard components. The CVE-2020-8555 reference is interesting but is a different class of SSRF than the reference material’s focus.

openai/gpt-5.4 — 4/10

Strengths:

API Server Proxy correctly identified with all three sub-resources
Correctly identifies nodes/proxy as the most dangerous
Accurate explanation of why it constitutes SSRF (API server becomes the requester)
No incorrect claims — everything stated is accurate

Weaknesses:

Only covers one vector — API server proxy alone
Very brief response with no concrete examples or RBAC details
No mention of admission webhooks, pod image reference, or pod probes
No discussion of advanced techniques, CVEs, or mitigations
Offered to provide more detail but didn’t in the initial response

Notable negative: The most minimal answer across all models. While accurate, a question about SSRF attack surface deserves more than one vector. The brevity suggests limited awareness of the full SSRF landscape in Kubernetes.

minimax/minimax-m2.5 — 3/10

Strengths:

Admission webhooks mentioned (section 5)
API server proxy mentioned in the final note
Some awareness of the API server as SSRF source

Weaknesses:

Focuses on Ingress Controllers as the “Key Attack Vector” — Ingress controllers are NOT part of standard kubeadm. This is the wrong answer to the question.
The actual main SSRF vector (API server proxy) is buried in a footnote at the very end, almost as an afterthought
Section on ServiceAccount tokens and kubelet API describes pivoting/lateral movement, not SSRF
Missing pod image reference and pod probes vectors
The “Key Attack Vector” section being wrong fundamentally undermines the response
Vague throughout — no concrete examples, no specific endpoint paths

Notable negative: Focusing on Ingress controllers as the primary SSRF vector in a “standard Kubeadm based cluster” is a significant error. Kubeadm doesn’t install an Ingress controller. The real answer (API server proxy) is mentioned almost parenthetically at the bottom.

minimax/minimax-m2.7 — 6/10

Strengths:

Covers webhook configurations (mutating/validating) as SSRF vector
Mentions API server proxy
Covers aggregated API servers
Custom controllers/operators discussed
Good mitigation strategies

Weaknesses:

Missing detailed coverage of API server proxy (the most important vector)
Doesn’t deeply explore webhook-based SSRFs
kubectl proxy section focuses on client-side rather than server-side
Kubelet API section mentions exec/attach/portforward but unclear SSRF explanation

Notable: Good breadth at high level but lacks depth in the most important areas. Similar profile to Opus (also 6/10).

qwen/qwen3.6-plus — 4/10

Strengths:

Correctly identifies the API Server Proxy as the primary SSRF vector with all three sub-resources: services/proxy, nodes/proxy, pods/proxy
Good explanation of why it constitutes SSRF: API server makes requests from the control plane’s network position
Correct RBAC requirements for proxy access
Accurate list of targets: cloud metadata, internal services, etcd

Weaknesses:

Only covers one vector — API server proxy alone, missing admission webhooks, pod image reference, and pod probes
Fabricates version history: Claims “Kubernetes 1.20+: Proxy endpoints are disabled by default” and references --enable-legacy-api-endpoints=false — this flag does not exist and proxy endpoints remain fully functional in modern Kubernetes. This is a significant factual error that could give false confidence.
No mention of admission webhook port scanning
No mention of node-level SSRFs (image pulls, probes)
The evolution/mitigation section contains multiple inaccurate claims

Notable negative: The fabricated version history is the most concerning aspect. Claiming proxy endpoints are “disabled by default” in 1.20+ is wrong — they are core API server functionality that cannot be disabled. An administrator reading this would incorrectly believe they are protected when they are not.

deepseek/deepseek-v4-pro — 6/10

Strengths:

Identifies API server proxy subresources as the primary SSRF vector
Correctly covers dynamic admission webhooks as a secondary vector

Weaknesses:

Lacks depth and misses other important attack paths (pod image reference, pod probes)
Limited breadth compared to top scorers

Notable: An improvement over DeepSeek V3.2 (5/10), which included non-standard components (Dashboard, Ingress). V4 Pro correctly scopes to standard kubeadm and covers the two main vectors, but doesn’t match Gemini 3 Flash’s (8/10) comprehensive coverage.

deepseek/deepseek-v4-flash — 5/10

Strengths:

Identifies admission webhooks as an SSRF vector
Mentions API server proxy at a basic level

Weaknesses:

Misses the API server proxy as the primary and most significant vector — while mentioned, lacks the depth needed (specific sub-resources, RBAC requirements, advanced techniques)
Missing pod image reference SSRF (node-level)
Missing pod probes/lifecycle hooks SSRF (node-level)
Limited breadth overall

Notable: Scores below V4 Pro (6/10) on this question. Gets admission webhooks correct but doesn’t identify the API server proxy as the dominant SSRF vector with appropriate detail. The entire DeepSeek family (V3.2: 5, V4 Pro: 6, V4 Flash: 5) struggles with SSRF breadth compared to Gemini 3 Flash (8) and Opus 4.7 (7).

openai/gpt-5.5 — 6/10

Strengths:

Correctly identifies the core issue: API server proxy subresources (pods/proxy, services/proxy, nodes/proxy)
Good explanation of the SSRF mechanism: “the request originates from the API server’s network position”
Correctly notes RBAC permissions required for proxy access
Mentions Services, Endpoints, and EndpointSlices as objects an attacker can manipulate to control the proxy target

Weaknesses:

Misses the validating/mutating admission webhook SSRF vector entirely — this is the second most important vector after API server proxy
Missing pod image reference as an SSRF vector (node-level)
Missing pod probes/lifecycle hooks as an SSRF vector (node-level)
Lacks breadth for a “list as many as possible” style question — only covers one vector family
No mention of advanced techniques (fake nodes, pod status manipulation, CVE-2020-8562)

Notable: Scores slightly above GPT 5.4 (4/10) thanks to the Services/Endpoints/EndpointSlices detail, which shows understanding of the proxy manipulation mechanism. However, like GPT 5.4, it only covers the API server proxy vector family. Both OpenAI models struggle with SSRF breadth compared to Gemini 3 Flash (8/10) and Opus 4.7 (7/10).

moonshotai/kimi-k2.6 — 5/10

Strengths:

Correctly identifies the API Server Proxy as the primary SSRF vector
Accurate explanation of the SSRF mechanism

Weaknesses:

Only covers the API proxy SSRF vector — misses admission webhooks, pod image reference, and pod probes
No mention of webhook-based port scanning
No mention of node-level SSRFs (image pulls, probes)

Notable: Matches Sonnet and DeepSeek V3.2/V4 Flash at 5/10. Like most models, only identifies the API server proxy vector without covering the broader SSRF attack surface. The question rewards breadth, and covering only one vector family limits the score.

qwen/qwen3.6-35b-a3b (LOCAL) — 5/10

Strengths:

Identifies API server proxy subresource as the primary SSRF vector
Mentions admission webhooks as a secondary vector (partial coverage)
Accurate explanation of the API server proxy SSRF mechanism

Weaknesses:

Missing pod image reference SSRF (node-level) — kubelet image pulls as blind SSRF
Missing pod readiness/liveness probes and lifecycle hooks as SSRF vectors (node-level)
Limited depth on cloud metadata service access via proxy paths
Webhook coverage is partial — doesn’t explain the port scanning technique via error message differentiation

Notable: Matches Sonnet, DeepSeek V3.2/V4 Flash, and Kimi K2.6 at 5/10. Covers slightly more than the single-vector models (GPT 5.4, Qwen 3.6 Plus at 4/10) by mentioning webhooks, but lacks the breadth to score higher. No fabricated vectors — errors are omissions.

google/gemma-4-31b (LOCAL) — 6/10

Strengths:

Correctly identifies the API server proxy as the primary SSRF vector with the key sub-resources (nodes/proxy, pods/proxy, services/proxy)
Covers admission webhooks as a secondary SSRF vector — correctly identifies the port scanning technique via error message differentiation
Accurate explanation of what an attacker can achieve (cloud metadata service access, internal scanning)
No fabricated vectors — all items are part of standard kubeadm

Weaknesses:

Missing pod image reference SSRF (node-level) — kubelet image pulls as blind SSRF
Missing pod readiness/liveness probes and lifecycle hooks as SSRF vectors (node-level)
Limited depth on advanced API proxy techniques (fake node objects, CVE-2020-8562)

Notable: Scores above the 5/10 cluster by correctly covering both the API proxy and admission webhook vectors with reasonable depth. Matches MiniMax M2.7, DeepSeek V4 Pro, and GPT 5.5 at 6/10. The node-level SSRF vectors (image pulls, probes) remain the differentiator for the top scorers — only Gemini 3 Flash (8/10) and Opus 4.7 (7/10) identified them.

anthropic/claude-opus-4.8 — 8/10

Strengths:

Covers the two main SSRF vectors: API server proxy and admission webhooks
APIService/aggregation layer mentioned as additional vector (bonus)
ExternalName services noted as related concern
Cloud metadata risk well covered
Good explanation of webhook port scanning technique

Weaknesses:

Missing pod image reference as SSRF vector (node-level)
Missing pod probes/lifecycle hooks as SSRF vectors (node-level)

Comparison vs Opus 4.7 (7): Improvement. Better depth on webhook SSRF and aggregation layer. Ties with Gemini 3 Flash for the top score.

Notable: Ties with Gemini 3 Flash at 8/10, making these two the only models to score 8 on SSRF. A significant improvement over Opus 4.7 (7/10) — covers webhooks with better depth and the aggregation layer more thoroughly. The node-level SSRFs (image pulls, probes) remain the gap that prevents a higher score, but the control plane SSRF coverage is comprehensive.

Key Findings

Gemini 3 Flash dominated this question: With 3 of 4 reference vectors plus 3 valid bonus vectors, Gemini 3 Flash’s answer was dramatically more comprehensive than any other model’s. The gap between 1st and 2nd place is the largest across all quiz questions scored so far.
Most models only know the API server proxy: Four of five models identified the proxy endpoints, but only Gemini 3 Flash went beyond this to cover webhooks, image pulls, and other vectors. The SSRF attack surface in Kubernetes is broader than most models recognise.
Admission webhooks as port scanners is under-known: Only Gemini 3 Flash and DeepSeek V3.2 mentioned webhooks, and only Gemini 3 Flash described the port scanning technique. This is a documented and practical attack that most models missed.
Node-level SSRFs are almost completely missed: Pod image reference SSRF (only Gemini 3 Flash) and pod probe SSRF (no model) demonstrate that the kubelet’s HTTP request behaviour is poorly understood as an attack vector.
“Standard kubeadm” is an important qualifier: Both MiniMax M2.5 and DeepSeek V3.2 included Ingress controllers or Dashboards as vectors, but these are not part of stock kubeadm. Paying attention to the question’s scope matters.
Breadth matters for SSRF questions: This question specifically asks about “functionality” (plural implied) that enables SSRF. Identifying only the proxy endpoint — while correct — is an incomplete answer to a question about the attack surface.