Critical vulnerabilities in Zoom and GitLab require immediate patch

The platforms we use daily to coordinate work and projects put security back at the center of the debate: Zoom and GitLab have published patches to correct serious vulnerabilities that, in different scenarios, could allow from service interruption to remote code execution. These updates come after internal audits and reviews that have identified failures that managers cannot afford to ignore.

In the case of Zoom, the most alarming problem affects Zoom Node's (Multimedia Routers) MMR, key components when meeting solutions are deployed in hybrid or on-premises. According to the company, a command injection vulnerability was detected which, in versions prior to 5.2.1716.0, could allow a meeting participant to execute code on the team acting as MMR if they have access to the network. The tracking of this failure appears as CVE-2026-22844 and, due to its potential impact, received a score CVSS 9.9 over 10, which indicates a critical threat. Zoom has published the details and recommendations in his official security bulletin Here., and urges customers with Zoom Node Meetings, Hybrid or Meeting Connector deployments to update the MMR modules to the corrected version.

It is important to stress that, for now, Zoom has found no evidence that this vulnerability has been exploited in actual attacks outside its internal controls. However, the combination of a CVSS close to 10 and the nature of the attack vector - a participant with access to the meeting that could cause remote execution in the local infrastructure - makes the recommendation to update categorically. If your organization manages MMRs, implementation of the update should be considered an operational priority.

In parallel, GitLab has published a series of corrections for its Community Edition and Enterprise Edition after identifying multiple high and medium-severity vulnerabilities that could cause conditions of denial of service and, in one case, mocking two-factor authentication protections. The company described in its release note the corrected pieces and the affected versions; among the most critical are failures that allow non-authenticated users to trigger DoS through manipulated requests and a problem that could allow an attacker with knowledge of a victim's credential identifier to avoid 2FA by forging device responses. GitLab posted the patches and technical information on its release page Here..

GitLab-corrected failures include high-score CVE, such as CVE-2025-13927 and CVE-2025-13928 which allow for the creation of conditions of inavailability through malformed applications in different APIs; and CVE-2026-0723 which affects the second factor authentication flow by accepting forged responses. In addition, other average severity problems that could be facilitated by DoS by specially built Wiki content or by malformed SSH authentication attempts were solved. For self-housed instance administrators, these corrections are essential to maintain the integrity and availability of the service.

From a practical perspective, the appropriate response goes by applying patches as soon as possible, checking the records to detect unusual patterns and, if possible, isolating critical components until they are updated. In environments where network exposure is difficult to control, it is appropriate to review meeting access settings and entry points to the GitLab service, and to strengthen authentication and monitoring policies. Bodies such as MITRE keep public records of CVE; for example, the Zoom identifier can be consulted CVE-2026-22844 in MITRE for more technical context.

It is understandable that, in the face of security alerts, there is a debate about the likelihood of exploitation against the cost of applying updates in productive environments. However, recent history shows that unpaved vulnerabilities tend to be a rapid target for attack automation. With increasingly accessible discovery tools and exploits, a failure with high CVSS scores can become an exploitable attack vector in a short time. So, even if there is no confirmation of attacks in nature, the prudence guides to act without delay.

For security teams that manage these platforms, the recommended flow is clear: review the official Zoom and GitLab notices, compare the versions displayed with those mentioned in the bulletins, plan update windows with previous tests and run post-patch controls to validate that there are no returns. Complementing these actions with practices such as network segmentation, restriction of access to administrative interfaces and activation of alerts that detect exploitative attempts will increase barriers to potential attackers.

The availability of public information and the speed of communication by suppliers are a point in favour. Zoom and GitLab have made available to managers and users the technical details and update guides on their respective portals, which facilitates a coordinated response. In addition to official pages, it is appropriate to follow reports from cybersecurity organizations and vulnerability databases to obtain additional context and recommendations.

In the end, the lesson is repeated but necessary: in critical infrastructure or in mass collaboration, security is not an addition but an operational obligation. Keeping up with patches, understanding the impact of each CVE and adapting internal change management policies are key steps to reduce risks. If your organization uses Zoom Node MMRs or affected GitLab instances, the best defense today is to update and verify.