Back to Intelligence

CVE-2026-75885: Critical OpenShift Console SSRF and DoS — Detection and Remediation Guide

SA
Security Arsenal Team
September 18, 2026
9 min read

NVD has published CVE-2026-75885, a CVSS 9.3 (Critical) vulnerability in the Red Hat OpenShift web console — the management UI that sits at the heart of nearly every OpenShift cluster. The flaw is network-exploitable, requires no authentication, and delivers two distinct attack primitives: Server-Side Request Forgery (SSRF) against internal cluster and cloud services, and unbounded memory consumption leading to Denial of Service against the console pod.

If you run OpenShift — especially clusters where the console route is exposed beyond tightly controlled networks — treat this as an urgent remediation item. SSRF from a pod inside your cluster boundary is not a minor issue: it gives an unauthenticated external attacker a proxy into your internal network, your cloud metadata endpoints, and any service that trusts cluster-internal traffic. That is a textbook foothold for escalation into secrets theft, lateral movement, and full cluster compromise.

What Happened

A flaw was identified in the OpenShift console's devfile handling logic. The console exposes two API endpoints:

  • /api/devfile/
  • /api/devfile/samples/

These endpoints accept devfile content — YAML-based developer workspace definitions — and the console backend processes them without requiring authentication. Two failure modes result:

  1. SSRF: A crafted devfile can coerce the console pod into making requests to arbitrary internal destinations. Partial responses are reflected back to the attacker, turning the console into an internal reconnaissance and data-leak proxy.
  2. DoS: By sending repeated large request bodies without a specified Content-Length header, an attacker triggers unbounded memory growth in the console pod, eventually crashing it or triggering OOM kills — taking down the management plane UI and, under memory pressure, potentially impacting co-located workloads on the node.

Technical Analysis

Affected Component

  • Product: Red Hat OpenShift Container Platform — web console component (the console deployment in the openshift-console namespace)
  • Attack surface: The console route (typically console-openshift-console.apps.<cluster-domain>), reachable over HTTPS
  • Prerequisites for exploitation: Network reachability to the console route. No credentials, tokens, or user interaction required.

Refer to the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-75885) and the Red Hat security advisory for the definitive list of affected and fixed versions per OCP release stream. Verify against your specific cluster version — OpenShift 4.x streams receive fixes on different cadences, and your cluster's clusterversion operator will tell you exactly what you're running.

Attack Chain (Defender's View)

SSRF path:

  1. Attacker sends an unauthenticated HTTP request to /api/devfile/ or /api/devfile/samples/ containing a crafted devfile with attacker-controlled URLs (e.g., in devfile component definitions or imported resources).
  2. The console pod server-side fetches the referenced URL — from inside the cluster network, using the pod's network position.
  3. The response (or a partial reflection of it) is returned to the attacker in the HTTP response.
  4. The attacker iterates: probing internal services, cluster API endpoints, Kubernetes service CIDRs, cloud instance metadata services (169.254.169.254 on AWS/Azure/GCP IMDS), and any internal application that trusts cluster-local sources.

Why this is dangerous in practice: the console pod's service account and network position can reach endpoints that are completely invisible from the internet. IMDS retrieval can yield cloud credentials. Internal service probing maps your architecture without tripping perimeter controls.

DoS path:

  1. Attacker issues repeated requests to the devfile endpoints with large bodies and no Content-Length header (chunked or streaming transfer).
  2. The console backend buffers request content in memory without enforcing an upper bound.
  3. Memory grows unbounded until the pod hits its cgroup limit and is OOM-killed, or node memory pressure triggers eviction cascades.
  4. Repeated in parallel, this keeps the console permanently unavailable and can destabilize the node hosting it.

Exploitation Status

At time of writing, CVE-2026-75885 has been published by NVD with a critical score. The vulnerability class (unauthenticated SSRF + trivially triggered DoS, network-reachable, no user interaction) is the profile that historically moves from disclosure to scanning within days. Treat exploitation as imminent: assume internet-facing console routes will be probed for /api/devfile/ paths. Monitor the CISA KEV catalog and Red Hat advisories for confirmation of in-the-wild activity, and don't wait for a KEV listing to patch a 9.3 on an internet-reachable management interface.

Detection & Response

The highest-fidelity detection surface for this CVE is HTTP access logging — OpenShift router (HAProxy) logs, console pod logs in openshift-console, and any upstream WAF/load balancer that fronts the console route. Every exploitation attempt must touch /api/devfile/ or /api/devfile/samples/; unauthenticated requests to these paths from external sources are the signal. Secondary signals: the console pod initiating unexpected outbound connections (SSRF evidence), and console pod memory spikes or OOMKilled restarts.

YAML
---
title: Unauthenticated Access to OpenShift Console Devfile Endpoints (CVE-2026-75885)
id: 3f8a1c94-7b2e-4d5a-9f16-8c4d2e7a5b31
status: experimental
description: Detects HTTP requests to the OpenShift console devfile API endpoints associated with CVE-2026-75885 SSRF and DoS exploitation. Any external or unauthenticated request to these paths should be investigated.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-75885
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: openshift
detection:
  selection:
    cs-uri-stem|contains:
      - '/api/devfile/'
      - '/api/devfile/samples'
  condition: selection
falsepositives:
  - Legitimate developer use of the OpenShift devfile/samples UI features by authenticated console users
  - Internal health checks misconfigured to hit these paths
level: high
---
title: OpenShift Console Pod Suspicious Outbound Connection (Possible SSRF)
id: 9c2e5b18-4f7a-4c8d-b3e5-1a6f9d2c8e47
status: experimental
description: Detects the OpenShift console pod initiating connections to internal service ranges, link-local metadata addresses, or unusual destinations — consistent with SSRF exploitation of CVE-2026-75885 where the console pod is coerced into fetching attacker-specified URLs.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-75885
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1190
logsource:
  category: network_connection
  product: kubernetes
detection:
  selection:
    SourceNamespace: 'openshift-console'
    DestinationIp:
      - '169.254.169.254'
      - '169.254.170.2'
      - '100.100.100.200'
  condition: selection
falsepositives:
  - Legitimate console plugin integrations reaching documented internal services (whitelist known-good destinations)
level: critical
KQL — Microsoft Sentinel / Defender
// Hunt for requests to OpenShift console devfile endpoints via router/WAF logs ingested as CEF/Syslog
// Tune TimeGenerated window and exclude known internal scanner IPs
let timeframe = 7d;
let known_scanners = dynamic(["10.0.0.5", "10.0.0.6"]); // replace with your scanner IPs
union isfuzzy=true
    (CommonSecurityLog
    | where TimeGenerated > ago(timeframe)
    | where RequestURL contains "/api/devfile/"
    | project TimeGenerated, SourceIP, RequestURL, RequestMethod, ApplicationProtocol, DeviceAction, SourceHostName="Router/WAF"),
    (Syslog
    | where TimeGenerated > ago(timeframe)
    | where SyslogMessage contains "/api/devfile/"
    | extend SourceIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
    | project TimeGenerated, SourceIP, RequestURL=SyslogMessage, RequestMethod="", ApplicationProtocol="", DeviceAction="", SourceHostName=HostName)
| where SourceIP !in (known_scanners)
| summarize RequestCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), UniquePaths=dcount(RequestURL) by SourceIP
| order by RequestCount desc
VQL — Velociraptor
-- Hunt OpenShift console pods for SSRF evidence and devfile endpoint access
-- Run against cluster nodes: checks live netstat from console pods and
-- greps console pod logs for devfile endpoint requests
LET console_logs = SELECT FullPath, B AS Line
FROM foreach(
    row={
        SELECT FullPath FROM glob(globs='/var/log/pods/openshift-console_console-*/console/*.log')
    },
    query={
        SELECT FullPath, B
        FROM parse_lines(filename=FullPath)
        WHERE B =~ '/api/devfile/'
    })
SELECT FullPath AS LogFile, Line AS MatchingLogLine
FROM console_logs
Bash / Shell
#!/bin/bash
# CVE-2026-75885 - OpenShift console devfile endpoint verification & mitigation
# Run with a cluster-admin kubeconfig. Review before executing in production.

set -euo pipefail

echo "=== [1] Cluster and console version ==="
oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}'
oc get deployment console -n openshift-console -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

echo "=== [2] Console route exposure ==="
oc get route console -n openshift-console -o jsonpath='{.spec.host}{"\n"}'

echo "=== [3] Recent devfile endpoint hits in console pod logs ==="
oc logs -n openshift-console -l app=console --since=24h 2>/dev/null | grep -E '/api/devfile/' | tail -50 || echo "No devfile endpoint hits in last 24h"

echo "=== [4] Console pod restart / OOM history (DoS indicator) ==="
oc get pods -n openshift-console -l app=console -o jsonpath='{range .items[*]}{.metadata.name}{" restarts="}{.status.containerStatuses[0].restartCount}{" lastState="}{.status.containerStatuses[0].lastState.terminated.reason}{"\n"}{end}'

echo "=== [5] Deploy compensating NetworkPolicy (restrict console ingress to trusted CIDRs) ==="
read -r -p "Apply NetworkPolicy restricting console ingress? Edit TRUSTED_CIDR first. [y/N] " ans
if [[ "$ans" == "y" ]]; then
  TRUSTED_CIDR="10.0.0.0/8"   # <-- EDIT: your corporate/VPN CIDR
  oc apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: console-restrict-ingress-cve-2026-75885
  namespace: openshift-console
spec:
  podSelector:
    matchLabels:
      app: console
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: ${TRUSTED_CIDR}
      ports:
        - port: 443
          protocol: TCP
EOF
  echo "NetworkPolicy applied."
fi

echo "=== [6] Check for available upgrade ==="
oc adm upgrade

echo "Done. If console image/version is in Red Hat's affected list, schedule the cluster upgrade immediately."

Remediation

  1. Patch immediately. Apply the OpenShift 4.x z-stream update containing the fix for CVE-2026-75885 per the Red Hat advisory linked from the NVD entry. Confirm your exact fixed version against Red Hat's advisory for your release stream (oc adm upgrade will surface available, supported target versions). Do not assume your current z-stream is covered — verify against the advisory's fixed-in list.

  2. Restrict console route exposure now. If the console is reachable from the internet or broad internal networks, place it behind a VPN, bastion, or IP allowlist. The NetworkPolicy in the script above is a compensating control, not a substitute for patching — but it eliminates the unauthenticated external attack path while you schedule the upgrade.

  3. Block at the edge. If a WAF or load balancer fronts the console route, add a temporary rule denying unauthenticated requests to /api/devfile/ and /api/devfile/samples/. Verify legitimate devfile workflows aren't in active use in your environment first.

  4. Enforce memory limits. Confirm the console deployment has memory requests/limits configured so the DoS path results in a bounded pod OOM-kill rather than node-level memory pressure. Check node eviction thresholds as a second layer.

  5. Hunt before you patch. Run the log review in section [3] of the script going back at least 30 days, plus the KQL query above. SSRF exploitation is quiet — look for devfile endpoint requests from unexpected source IPs, and for evidence of the console pod reaching 169.254.169.254 or internal service IPs it has no business touching. If you find hits, rotate cloud credentials obtainable via IMDS and audit the console service account's RBAC.

  6. Reduce IMDS blast radius. On cloud-hosted clusters, enforce IMDSv2 (AWS) or equivalent metadata protections, and block pod-to-metadata traffic via NetworkPolicy where workloads don't require it. This caps what a successful SSRF can steal.

  7. Monitor KEV and vendor channels. Track the CISA Known Exploited Vulnerabilities catalog and Red Hat errata for escalation of this CVE. If it lands in KEV, federal remediation deadlines apply and your own SLA should compress accordingly.

The pattern here — an unauthenticated API on a management plane, reachable by design, that proxies trust into the cluster interior — is one we see repeatedly in IR engagements. Management interfaces of orchestration platforms deserve the same exposure discipline you'd apply to a domain controller: minimal reachability, logged access, and aggressive patching.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.