GitLab, JFrog, and Cisco Flaws Under Active Attack

GitLab Patches Maximum-Severity Path Traversal Flaw

GitLab just shipped emergency patches for a flaw that's about as bad as it gets on paper: a perfect 10.0 severity score with no authentication required to exploit it. If you run GitLab CE or EE yourself, this is the one to check before anything else on your list.

What You Need to Know

GitLab has released emergency updates for CVE-2026-85706, a maximum-severity path traversal vulnerability in the repository commits API affecting self-managed GitLab Community Edition and Enterprise Edition deployments. Improper path confinement combined with missing authentication enforcement means an unauthenticated attacker can read arbitrary files from a vulnerable server, with no valid account, user interaction, or complex attack chain required. That combination of a perfect severity score and trivial exploitation conditions makes this a top patching priority for anyone running self-managed GitLab.

What's Vulnerable

The flaw affects GitLab CE and EE versions 18.7 through prior to 19.1.8, 19.2 through prior to 19.2.6, and 19.3 through prior to 19.3.2. Fixes are available in versions 19.1.8, 19.2.6, and 19.3.2. GitLab.com is already running a patched version, and GitLab Dedicated customers don't need to take any action, so the exposure sits entirely with organizations operating their own GitLab infrastructure. That includes internet-facing development platforms that may hold source code, CI/CD configuration, API tokens, SSH keys, database credentials, and other sensitive operational data, all of which becomes reachable to an attacker who can read arbitrary files without ever logging in.

Why This Matters

GitLab sits at the center of most software development and CI/CD workflows, so a successful arbitrary-file-read attack isn't just a data exposure problem in isolation. It can hand an adversary exactly what they need to pursue credential theft, source-code exposure, supply-chain compromise, or lateral movement into whatever development environments connect back to that server.

What to Do

Identify every self-managed GitLab instance in your environment, confirm the deployed version, and upgrade affected systems to the applicable fixed release. Internet-exposed instances deserve the most urgent attention, since an unauthenticated attacker can reach the vulnerable API path directly. Review reverse-proxy, web application firewall, and GitLab access logs for anomalous repository commits API requests, particularly unusual path values or repeated unauthenticated requests from unfamiliar infrastructure. Where immediate patching isn't possible, temporarily restrict public access to affected instances, limit API exposure through network controls, and make sure administrative interfaces aren't externally reachable.

A CVSS 10.0 with no authentication barrier doesn't leave much room for a wait-and-see approach, patch this one first.

Attackers Chain Two JFrog Artifactory Flaws to Seize Admin Control

Artifactory servers are being actively hunted right now, and attackers don't need much more than an unauthenticated foothold to walk away with admin control. Two chained bugs plus a third standalone flaw give self-hosted instances more than one path to full compromise.

What You Need to Know

Attackers are actively targeting unpatched, self-hosted JFrog Artifactory servers by chaining two vulnerabilities, CVE-2026-42018 and CVE-2026-42016, to escalate from unauthenticated access to full administrator control. The activity has been observed between August 15 and September 8. Neither flaw alone grants full admin rights, but combined they let an external attacker create privileged accounts, manipulate repositories, deploy malicious plugins, and execute commands on the underlying server. A separate, more severe flaw, CVE-2026-82329, has also been exploited and can grant admin access on its own.

What Happened

The chained attack works by exploiting CVE-2026-42018 to obtain an internal anonymous-user token, then abusing CVE-2026-42016 to exchange that limited token for one with administrator scope. The resulting activity can show up in logs simply as token:anonymous, which complicates investigation and makes anomalous token behavior one of the more reliable detection signals. Artifactory is a valuable target because it commonly stores software packages, build artifacts, containers, secrets, and deployment dependencies used across enterprise pipelines. In observed compromises, attackers created persistent administrator accounts, installed malicious Groovy plugins capable of executing code on the server, and used plugin execution endpoints to enumerate files and run shell commands. Researchers also saw payloads written to world-writable directories like /tmp followed by outbound command-and-control activity, and in several cases attackers deployed a custom Rust backdoor. Access to an Artifactory server can also expose the platform's cluster join key, letting an adversary register unauthorized nodes or expand access across a clustered deployment.

Separately, CVE-2026-82329 is a critical authentication-bypass flaw with a CVSS score of 9.8 that can grant an unauthenticated network attacker administrator privileges on its own, without needing the token-exchange chain. It affects multiple Artifactory release branches, and public exploit code plus widespread internet scanning followed quickly after disclosure.

Why This Matters

Cloud-hosted JFrog instances aren't affected by either issue, but organizations running self-managed Artifactory should treat vulnerable internet-facing systems as potentially already compromised rather than simply at risk. Exposed artifact repositories have shown they can become a rapid target for both opportunistic and more capable threat actors once a path to admin access is public.

What to Do

Upgrade self-hosted Artifactory to the fixed release for your branch: version 7.133.11 or later for CVE-2026-42016; 7.111.20, 7.117.27, 7.125.19, 7.133.28, or 7.146.8 for CVE-2026-42018; and 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20 for CVE-2026-82329. Patching alone isn't enough if exploitation may have already occurred: review accounts and access tokens, remove unauthorized administrative users, inspect plugin configurations and recent repository changes, revoke tokens issued since late August, and rotate the Artifactory cluster join key. Prioritize detection around token creation by anonymous or low-privilege identities, unexpected plugin deployment, suspicious command execution, and outbound connections from Artifactory hosts.

Chained low-severity flaws can add up to full admin control just as easily as a single critical bug, which is exactly why patch prioritization needs to account for combinations, not just individual CVSS scores.

Windows 11 Update KB5124008 Reportedly Breaks Always On VPN

Not every problem this cycle is a vulnerability. A regression in this month's Windows 11 cumulative update is knocking certificate-based Always On VPN connections offline, and that's its own kind of emergency for a remote workforce.

What You Need to Know

Organizations deploying the September Windows 11 cumulative update, KB5124008, should evaluate a reported regression affecting Always On VPN connections that rely on certificate-based authentication. The issue has been observed on Windows 11 24H2 and 25H2 clients connecting to Windows Server 2019 Routing and Remote Access Service and Network Policy Server infrastructure managed through Microsoft Intune. Affected users report VPN failures after installing the update, and removing it restores connectivity, which puts IT teams in the familiar bind of balancing patch compliance against a core remote-access service.

What Happened

Available reporting indicates the failure occurs during certificate negotiation in the VPN handshake, pointing to a possible change in Windows networking behavior, IPsec processing, or certificate-chain validation introduced by the cumulative update rather than a problem with existing VPN configurations. For enterprises relying on Always On VPN, the impact can be immediate: remote users may lose connectivity to internal applications, file services, administrative systems, and other resources that depend on the tunnel.

Why This Matters

This isn't a security vulnerability, but it creates real operational risk. Losing remote access to internal resources can disrupt business continuity just as effectively as a security incident, and it forces a decision between deploying a cumulative update with real security fixes and keeping a core connectivity service running.

What to Do

Validate KB5124008 in a representative pilot group before broad deployment, especially where certificate-based device tunnels or user tunnels are in use. If you haven't yet deployed the update, consider pausing rollout through Intune or Windows Server Update Services until Microsoft confirms scope or releases a remediation. For devices where the update is already installed and connectivity is essential, removing it may restore service, but weigh that against the security fixes in the cumulative release and handle it through formal change control rather than as an ad hoc fix. Capture affected-client event logs, RasClient records, IKE and IPsec diagnostics, NPS logs, and certificate-validation errors before making any configuration changes. One potential workaround is updating affected profiles to use EAP-TLS authentication through Intune where appropriate for your VPN design, which may avoid the certificate-validation path implicated in the failures, but test it carefully and confirm authentication and conditional-access requirements stay intact rather than treating it as a universal fix.

Security and infrastructure teams need to coordinate here, not choose one priority over the other, since remote-access availability and timely patching both matter.

Trezor Users Targeted in Phishing Campaign After Brevo Breach

When a phishing email comes from a company's own legitimate account, the usual red flags disappear. That's exactly what happened to roughly 347,000 Trezor newsletter subscribers after a breach at a third-party email vendor.

What You Need to Know

Trezor has disclosed a phishing campaign targeting roughly 347,000 newsletter subscribers after attackers compromised Brevo, the third-party marketing platform Trezor uses for email campaigns. The breach occurred on September 9, 2026, and affected 120 Brevo customer accounts. Because attackers sent the fraudulent messages from Trezor's own compromised account, the emails carried a legitimacy that made the campaign more dangerous than a typical brand-impersonation attempt.

What Happened

The phishing emails impersonated Trezor and claimed a critical hardware microcontroller vulnerability affected Trezor cold-storage wallets. Recipients were directed to a malicious website and prompted to download an application that requested their wallet backup, commonly called a seed phrase or recovery seed. Possession of that backup lets an attacker take control of a victim's cryptocurrency assets even if the victim still physically holds the hardware wallet. Trezor removed the malicious domain within 20 minutes, but approximately 2,500 recipients clicked the embedded link before it was disabled. Trezor said its own systems were not compromised and that the exposed data was limited to its opt-in newsletter database.

Why This Matters

This incident is a reminder that compromising a trusted communications channel can be more effective than impersonating a brand from an unrelated domain. Users accustomed to receiving legitimate product updates, support notices, and security alerts through a known mailing list are naturally more likely to trust a message delivered through it, which is exactly what made this campaign work as well as it did.

What to Do

Treat any email that creates urgency around a wallet vulnerability, account restriction, firmware update, or asset-recovery requirement as suspicious. Hardware-wallet vendors do not need a customer's recovery seed to resolve a security issue, validate a device, or restore access to funds, so never enter a wallet backup into an application, website, browser extension, or form, even if the request appears to come from the vendor. Anyone who entered a recovery seed after receiving one of these emails should assume that wallet is compromised and immediately transfer assets to a newly generated wallet with a new seed. Expect follow-on phishing attempts as well, since the exposed newsletter database contains email addresses that could be reused for future cryptocurrency-themed lures.

The seed phrase is a wallet's master secret, and any unsolicited request for it, regardless of how legitimate the sender looks, is a reliable sign of fraud.

Cisco FMC Vulnerabilities Exploited for Credential Theft and Qilin Ransomware

Firewall management platforms don't get compromised quietly, and Cisco's Secure Firewall Management Center is proving that point across three separate attack campaigns right now, one of which ends in Qilin ransomware.

What You Need to Know

Cisco has confirmed active exploitation of two vulnerabilities in Secure Firewall Management Center by threat clusters linked to ransomware operations and suspected state-sponsored activity. The more serious flaw, CVE-2026-20079, carries a CVSS score of 10.0 and lets an unauthenticated remote attacker bypass FMC web interface authentication, execute script files, and gain root-level access to the underlying operating system. CISA has added both this flaw and a second, CVE-2026-20316, to its Known Exploited Vulnerabilities catalog, and federal civilian agencies must remediate CVE-2026-20079 by September 12, 2026.

What Happened

CVE-2026-20316, with a CVSS score of 5.3, permits unauthenticated access through a low-privilege account, exposing sensitive system data and potentially supporting privilege escalation when combined with other weaknesses. Three distinct threat clusters have exploited these flaws in observed activity. UAT-12197 exploited CVE-2026-20079 to deploy JSP web shells and a Java Archive-based command executor, letting operators query internal databases and obtain authentication data and credentials. UAT-11823 chained both vulnerabilities to install a Netcat reverse shell, harvest managed-device configurations, and deploy a Cyclops Blink variant, a modular ELF implant previously associated with Sandworm activity. A third cluster, UAT-11988, used CVE-2026-20316 as an entry point before relying on native FMC tooling for reconnaissance, credential collection, endpoint targeting, security-tool termination, and deployment of Qilin ransomware.

Why This Matters

FMC centrally manages firewall policies, devices, credentials, and network-security controls, which makes it Tier 0 infrastructure. Compromise here doesn't just affect one system, it can give attackers visibility into network segmentation, firewall policy, managed-device configuration, and privileged credentials across an entire environment, which explains why three separate threat clusters with different objectives are all going after the same flaws.

What to Do

Apply Cisco's available hotfixes immediately, prioritizing FMC systems exposed to external networks or accessible from less-trusted internal segments. Cisco is also preparing a broader hardening release to address additional internally identified vulnerabilities. Assume opportunistic and targeted actors may already be probing vulnerable FMC instances, and review for new or modified JSP files, unexpected Java Archive files, Netcat activity, unauthorized shell execution, unusual FMC administrative accounts, anomalous database queries, and outbound connections from management appliances. Rotate FMC credentials and review managed-device configurations if you find any compromise indicators. Beyond immediate remediation, isolate FMC administrative interfaces, restrict access through dedicated management networks, enforce MFA for administrative users, and continuously monitor management-plane events.

A CVSS 10.0 flaw in the system that manages your firewalls isn't just another patch to schedule, it's the kind of exposure that deserves treatment as Tier 0 infrastructure from here forward.