CISA’s Known Exploited Vulnerabilities (KEV) Catalog has been updated to include two high-impact flaws this week — a long‑standing GitLab Server‑Side Request Forgery (SSRF) issue and a newly disclosed Dell RecoverPoint for Virtual Machines hard‑coded credential that has been weaponized in real world campaigns — prompting fresh urgency for patching, threat hunting, and tightened asset governance across both public‑ and private‑sector networks. (cloud.google.com)
The KEV Catalog exists because threat actors repeatedly exploit known weaknesses when organizations leave internet‑facing systems unpatched or poorly segmented. Under Binding Operational Directive (BOD) 22‑01, federal civilian agencies are required to remediate KEV entries on accelerated timelines; the directive also sets the policy framework that makes KEV additions operationally significant for the broader vulnerability‑management community.
CISA’s catalog is explicitly a “living list” — entries are added when there is credible evidence of active exploitation, and the catalog updates are intended not as academic exercises but as operational orders for agencies and strong guidance for all organizations that care about risk reduction. The practical effect is simple: once a CVE is added to KEV, security teams must prioritize it immediately within triage, patch orchestration, and detection playbooks.
WindowsForum members and security teams track KEV updates closely because they translate into deadlines, running‑list adjustments, and often a predictable wave of scanning and exploitation attempts against exposed infrastructure. Community discussion threads show that KEV additions quickly drive ticket escalations and emergency patch sprints across enterprise teams.
Mandiant/GTIG analysis attributes sustained exploitation of this vulnerability to UNC6201, with active use beginning in mid‑2024. The actors deployed forward‑looking tooling (native AOT C# backdoors labeled GRIMBOLT) and replaced earlier payloads (BRICKSTORM) to evade detection. The campaign shows a mature operator willing to maintain long‑term presence on victim networks by targeting virtualization tooling — an approach that complicates incident response because the appliance sits within virtual infrastructure and often has privileged access paths. (cloud.google.com)
Even for private sector organizations not bound by BOD 22‑01, the operational imperative is the same: KEV additions reflect proven exploitation, which increases both the likelihood and impact of compromise. The difference is that federal timelines can be stricter and are explicitly auditable.
Operationally, organizations should:
CISA’s KEV updates are not just policy notices — they are operational directives that reflect active adversary behavior. Treat them as such: inventory, patch, hunt, and harden now, and assume that yesterday’s fix never fully protects an environment until you’ve proven through logs and forensic checks that the environment is clean.
Source: CISA CISA Adds Two Known Exploited Vulnerabilities to Catalog | CISA
Background and why this matters now
The KEV Catalog exists because threat actors repeatedly exploit known weaknesses when organizations leave internet‑facing systems unpatched or poorly segmented. Under Binding Operational Directive (BOD) 22‑01, federal civilian agencies are required to remediate KEV entries on accelerated timelines; the directive also sets the policy framework that makes KEV additions operationally significant for the broader vulnerability‑management community.CISA’s catalog is explicitly a “living list” — entries are added when there is credible evidence of active exploitation, and the catalog updates are intended not as academic exercises but as operational orders for agencies and strong guidance for all organizations that care about risk reduction. The practical effect is simple: once a CVE is added to KEV, security teams must prioritize it immediately within triage, patch orchestration, and detection playbooks.
WindowsForum members and security teams track KEV updates closely because they translate into deadlines, running‑list adjustments, and often a predictable wave of scanning and exploitation attempts against exposed infrastructure. Community discussion threads show that KEV additions quickly drive ticket escalations and emergency patch sprints across enterprise teams.
What CISA added this week — the technical headlines
- GitLab Server‑Side Request Forgery (SSRF) — identified in multiple advisories as an issue that allows unauthenticated external actors to coerce a GitLab instance to make arbitrary requests to internal network resources (CI Lint API abuse). This class of flaw can be chained to abuse cloud metadata services and internal APIs, making it a powerful reconnaissance and initial lateral‑movement enabler. Evidence of active exploitation prompted a KEV listing and an accelerated remediation due date for affected instances.
- Dell RecoverPoint for Virtual Machines — a hard‑coded credential vulnerability (CVE‑2026‑22769) that allows unauthenticated access to the appliance’s Tomcat manager interface. Mandiant and Google Threat Intelligence Group (GTIG) have tied the flaw to sustained exploitation by a threat cluster tracked as UNC6201, dating back to at least mid‑2024, where adversaries used the weakness for lateral movement, persistence, and deployment of advanced backdoors (BRICKSTORM then GRIMBOLT). Dell has released advisories and remediation guidance; CISA’s KEV addition flags this CVE for prioritized remediation. (cloud.google.com)
Deep dive: GitLab SSRF — context, impact, and remediation
The vulnerability in practical terms
The GitLab SSRF in question lets unauthenticated external users trigger server‑side requests via the CI Lint API. When that API is reachable and the server is configured to allow internal network webhooks or internal‑host access, malicious actors can use it to:- Map internal networks and services.
- Access cloud metadata endpoints (where cloud credentials sometimes live).
- Touch off chains that lead to credential theft, lateral movement, or service‑side request abuse.
Why a 2021 bug is a 2026 emergency
It’s tempting to treat old CVEs as “done,” but adversaries routinely scan for unpatched or abandoned instances long after an official patch lands. The KEV listing indicates evidence that scanning and exploitation are ongoing now, and that unpatched, internet‑accessible GitLab instances remain attractive targets. As CISA notes in its KEV policy, old CVEs can and do reappear as operational problems when older systems are discovered on live networks.Immediate actions for defenders
- Inventory: Identify every GitLab instance (production, staging, CI runners, ephemeral images) and log its version. Prioritize internet‑facing instances.
- Patch: Upgrade to GitLab 14.3.6, 14.4.4, 14.5.2 or later depending on your upgrade path, or to the most current supported release. If in a managed SaaS environment, confirm the provider’s patch status.
- Temporary mitigations: If patching cannot be immediate, restrict network access to the CI Lint API (or firewall it to internal addresses only), disable unneeded public webhooks, and block exploit attempts at the perimeter.
- Hunt: Search app logs for unusual CI Lint API requests or attempts to access internal IP ranges or cloud metadata URIs. Deploy signature‑based and behavior‑based detections for SSRF patterns.
Deep dive: Dell RecoverPoint CVE‑2026‑22769 — why this is different and worse
The technical risk and attacker use
CVE‑2026‑22769 is a classic example of an appliance‑level configuration/security design weakness: Dell’s RecoverPoint for Virtual Machines included hard‑coded default credentials in the Tomcat configuration, enabling an unauthenticated attacker who knows those credentials to authenticate to Tomcat Manager, upload a malicious WAR, and execute code as root on the appliance. That capability alone is catastrophic for the targeting organization; Mandiant/GTIG found the bug was abused for lateral movement, persistent backdoors, and stealthy VM‑level manipulations such as “Ghost NICs.” (cloud.google.com)Mandiant/GTIG analysis attributes sustained exploitation of this vulnerability to UNC6201, with active use beginning in mid‑2024. The actors deployed forward‑looking tooling (native AOT C# backdoors labeled GRIMBOLT) and replaced earlier payloads (BRICKSTORM) to evade detection. The campaign shows a mature operator willing to maintain long‑term presence on victim networks by targeting virtualization tooling — an approach that complicates incident response because the appliance sits within virtual infrastructure and often has privileged access paths. (cloud.google.com)
Vendor and industry confirmation
Dell has published an advisory and remediation steps that include upgrading RecoverPoint for Virtual Machines to 6.0.3.1 HF1 (or following provided remediation scripts) and emphasized that RecoverPoint appliances should be deployed only on trusted, segmented networks. Dell’s bulletin also acknowledges Mandiant/Google reporting of limited active exploitation.Recommended defensive playbook
- Immediate patching: Apply Dell’s recommended upgrade path to 6.0.3.1 HF1 or the remediation script appropriate for your version. If migration is required, treat it as an emergency change.
- Forensic triage: Use the GTIG/Mandiant forensic checklist — examine Tomcat logs for /manager/text/deploy calls, inspect /var/lib/tomcat9 and /var/cache/tomcat9/Catalina for uploaded WARs, and look for modified boot scripts (convert_hosts.sh) or suspicious files under /home/kos. GTIG has shared IOCs and YARA rules to accelerate hunts. (cloud.google.com)
- Hunt for GRIMBOLT/BRICKSTORM: Search for known GRIMBOLT hashes and behavioral traits; look for temporary network ports spun up on ESXi hosts and unexpected iptables rules consistent with SPA (Single Packet Authorization) proxies — these were observed as pivoting tactics in real incidents. (cloud.google.com)
- Network segmentation: Ensure RecoverPoint appliances are not directly reachable from untrusted networks. Appliances with privileged access to virtualization stacks must live in well‑controlled management VLANs behind jump hosts or bastion controls.
What this means for federal agencies — BOD 22‑01 in action
Under BOD 22‑01 the KEV Catalog imposes remediation timelines: older CVEs (assigned prior to 2021) historically received a six‑month timeline, while more recent CVEs are often subject to a two‑week requirement — and CISA can accelerate those windows for grave threats. KEV entries trigger reporting and measurement requirements through federal dashboards and can escalate into oversight actions if not addressed. For security teams inside federal agencies this is not optional; it is a compliance and mission‑risk priority.Even for private sector organizations not bound by BOD 22‑01, the operational imperative is the same: KEV additions reflect proven exploitation, which increases both the likelihood and impact of compromise. The difference is that federal timelines can be stricter and are explicitly auditable.
Practical risk management recommendations (cross‑sector)
- Inventory and normalize: Maintain an authoritative inventory of internet‑facing and management‑plane assets (appliances, DevOps platforms, CI servers). Older or forgotten instances are the usual root cause of KEV‑level incidents.
- Prioritize by threat: Use KEV entries as high‑priority tickets in your patch‑management pipeline; triage by exploitability, exposure (internet‑reachabiness criticality.
- Harden network access: Apply zero‑trust principles to management appliances — restrict to managed jump hosts, implement MFA on management consoles, and enforce least privilege for service accounts.
- Bake detection into pipelines: Add SSRF detection in CI/CD logging and create detection rules for anomalous Tomcat Manager activity, unexpected WAR deployments, suspicious boot‑script modifications, and "ghost NIC" creation on ESXi hosts. (cloud.google.com)
- Run active hunts post‑patch: Patching is necessary but not sufficient. For vulnerabilities tied to known exploitation campaigns, run targeted hunt/IR exercises using vendor and GTIG/Mandiant IOCs and YARA rules. (cloud.google.com)
- Test restores and response playbooks: Validate that backups and disaster recovery workflows are intact and that incident response teams can execute containment and eradication playbooks that include VM‑level forensic steps. (cloud.google.com)
The strengths and limits of CISA’s KEV approach — a critical appraisal
Strengths
- Operational clarity: KEV turns intelligence into action by giving defenders a curated list of CVEs with demonstrated exploitation; that reduces ambiguity during triage.
- Policy teeth for federal agencies: BOD 22‑01 links KEV to mandatory remediation timelines — an effective lever for elevating security posture where the risk to national functions is highest.
- Community mobilization: KEV updates reliably trigger vendor advisories, community hunts, and third‑party intelligence sharing, which multiplies detection and mitigation resources.
Limits and risks
- Delay vs. discovery latency: Adding a CVE to KEV often happens after attackers have already been exploiting it. KEV is reactive by nature; defenders need complementary proactive threat modeling and red‑teaming.
- CVE identifier ambiguity: Multiple similar SSRF CVEs exist for GitLab across 2021; organizations can be confused by different CVE numbers reported in the press and in feeds. This creates risk when teams patch the wrong versions or miss variant‑specific guidance — verify exact fixed versions against vendor release notes before acting.
- Operational friction: Emergency patching in production virtualization stacks and DevOps platforms carries business continuis must maintain tested rollback and maintenance windows and prioritize compensating controls where immediate patching is impractical.
Detection and hunting playbook (concise checklist)
- Search for HTTP requests to CI Lint endpoints that include internal IPs, cloud metadata endpoints, or unusual URL patterns. Create alerts for these patterns.
- On RecoverPoint appliances, search Tomcat Manager logs for PUT /manager/text/deploy calls and validate any uploaded WAR files. Examine /var/lib/tomcat9 and /var/cache/tomcat9/Catalina for unusual artifacts. (cloud.google.com)
- Hunt for modified boot scripts (convert_hosts.sh) and any new entries that execute non‑standard binaries at boot. (cloud.google.com)
- On ESXi and vCenter systems, look for transient virtual NICs or temporary network interfaces and unexpected iptables or firewall rules used as proxies. (cloud.google.com)
- Apply vendor YARA rules and Mandiant/GTIG IOCs to endpoint and network telemetry to find GRIMBOLT/BRICKSTORM artifacts. (cloud.google.com)
Final analysis and tactical recommendations
This week’s KEV additions are a textbook reminder that two distinct threat vectors — long‑tail unpatched applications and modern appliance backdoors — coexist and both demand attention. The GitLab SSRF saga underscores the perennial danger of forgotten DevOps infrastructure, while the Dell RecoverPoint story exposes how appliances embedded in virtualization stacks can become a persistent, privileged foothold when a vendor misconfiguration or coding lapse leaves a default credential behind.Operationally, organizations should:
- Treat KEV listings as immediate high‑priority tickets, not optional advisories. Remediate, mitigate, or isolate affected assets quickly.
- Combine patching with hunting. A successful remediation program ends only when forensic artifacts show no evidence of prior compromise or persistence remain. (cloud.google.com)
- Strengthen asset inventory and exposure discovery to find forgotten instances that will otherwise remain attractive targets for opportunistic scanning.
CISA’s KEV updates are not just policy notices — they are operational directives that reflect active adversary behavior. Treat them as such: inventory, patch, hunt, and harden now, and assume that yesterday’s fix never fully protects an environment until you’ve proven through logs and forensic checks that the environment is clean.
Source: CISA CISA Adds Two Known Exploited Vulnerabilities to Catalog | CISA
