CISA has added two vulnerabilities affecting GitLab and Cisco products to its Known Exploited Vulnerabilities (KEV) catalog after citing evidence of active exploitation. While the KEV list is a U.S. government resource, it is closely watched by security teams worldwide because inclusion generally indicates that attackers are already using the flaws in real-world campaigns.

For European businesses, the development matters less because of the U.S. agency itself and more because it highlights an immediate operational risk: organisations using affected GitLab or Cisco systems may need to accelerate patching, validate internet exposure and review whether compensating controls are in place.

What happened

According to the source report, CISA added two flaws affecting GitLab and Cisco software to its KEV catalog. The article states that the decision was based on evidence of active exploitation. One of the listed issues is identified as CVE-2026-97229, described as a GitLab vulnerability with a CVSS severity score of 10.0.

Placement in the KEV catalog does not create a legal obligation for most private-sector European companies by itself. However, it is widely treated as a strong indicator that exploitation is no longer theoretical. In practice, many security teams use KEV as a prioritisation signal for patch management and exposure reduction.

Why it matters for European businesses

GitLab is widely used in software development, DevOps and internal deployment workflows. Cisco security and network infrastructure products are also common in business environments, including among mid-sized organisations and service providers. If a vulnerability is being actively exploited, the business risk goes beyond technical disruption.

• Operational risk: A compromised GitLab instance can affect source code, CI/CD pipelines, internal credentials and software delivery processes.
• Security risk: Vulnerabilities in firewall or network security products can weaken perimeter defences and create opportunities for follow-on attacks.
• Supply chain implications: If a development platform is affected, the impact may extend to customer-facing applications, deployment pipelines and partner integrations.
• Compliance pressure: For regulated organisations or companies subject to contractual security requirements, delayed remediation can create audit, incident response or reporting consequences.

For SMEs in particular, actively exploited vulnerabilities are important because attackers often target exposed systems opportunistically rather than selecting only large enterprises. Publicly reachable admin interfaces, development systems and edge devices can become entry points if patching is delayed.

Who may be affected

• Businesses running self-hosted GitLab Community Edition or Enterprise Edition for software development, internal tools or CI/CD.
• Companies using Cisco security or firewall infrastructure in offices, data centres or hybrid network environments.
• Digital agencies and software teams managing multiple client environments where GitLab or Cisco products are part of delivery infrastructure.
• E-commerce and SaaS businesses that depend on continuous deployment and uptime-sensitive infrastructure.
• Regulated organisations that need to demonstrate timely vulnerability management and incident readiness.

What companies should consider

• Identify exposure quickly: Confirm whether affected GitLab or Cisco products are present in your environment, including test, staging and subsidiary systems.
• Check vendor advisories: Review the official GitLab and Cisco security guidance for affected versions, patches and any temporary mitigation steps. Do not rely only on secondary reporting.
• Prioritise internet-facing assets: Systems exposed to the public internet should be reviewed first, especially development portals, administrative interfaces and security appliances.
• Review access logs and alerts: Because CISA cited active exploitation, organisations should look for unusual authentication events, configuration changes, service disruption or signs of attempted exploitation.
• Test business continuity: Where firewalls or development platforms are involved, prepare rollback and recovery plans before patching to reduce operational disruption.
• Strengthen vulnerability processes: If your business does not already track KEV-style alerts, this is a practical reason to formalise how critical external advisories are reviewed and escalated.

At this stage, businesses should treat the KEV addition as a prioritisation signal rather than assume every deployment is automatically compromised. The immediate question is whether affected products are in use, exposed and patched. For companies that depend on GitLab for software delivery or Cisco for edge security, that review should happen without delay.