Trending Topics

New MacOS Stealer ClickLock Uses ClickFix to Steal Login Credentials

ClickLock doesn't hack your Mac so much as ask nicely. Here's how it tricks people into handing over their password, and what to watch for so it doesn't happen to you.

What You Need to Know

Group-IB researchers have identified a new macOS information stealer called ClickLock, active since May 2026 and already confirmed on at least 100 systems across 33 countries. The malware doesn't rely on any technical vulnerability. It works by convincing users to run a command themselves, then tricks them into typing their own password into a fake system dialog. If you use a Mac, this is one to know about now, not after the fact.

How the Attack Works

ClickLock spreads through a ClickFix lure, a fake Cloudflare human-verification page that asks the visitor to copy and paste a command into Terminal. Once that command runs, the malware disables keyboard interrupts and suppresses notifications for six hours while its modules download quietly in the background.

At that point, ClickLock shows a fake macOS password dialog, complete with the victim's real username and a downloaded Apple icon to make it look legitimate. If the person enters their password, it's sent straight to the attacker over Telegram. If they dismiss the dialog instead, ClickLock plants two LaunchAgents and simply waits for the next login to try again.

What It Steals

Once ClickLock has credentials, it harvests saved logins, cookies, autofill data, and bookmarks across multiple browsers, and pulls financial and cryptocurrency information wherever it's available. Defenders can watch for a few concrete signs of compromise: osascript launching password dialogs, repeated termination of system processes, or LaunchAgent entries named com.authirity.plist or com.chromer.plist. Any of these should be investigated immediately.

Why This Matters

ClickLock works precisely because it skips the hard part. There's no exploit to patch and no privilege escalation to detect, just a user's trust in what looks like a normal macOS prompt. That makes it effective against exactly the kind of people who'd never fall for a sketchy download link, because the attack doesn't look like one.

What to Do

Never paste a Terminal command from a website, no matter how official or urgent the page looks. That single habit closes off ClickLock's entire infection path. If a Mac becomes unresponsive with only a password dialog on screen, don't enter the password. Hold the power button to force a shutdown and boot into Safe Mode to recover. On the detection side, monitor for osascript-triggered password prompts, unusual process termination patterns, and the two named LaunchAgent files above.

Trust your instincts here. A real verification check will never ask you to run a command to prove you're human.

Claude Chrome Extension Gives Malicious Extensions a Path to Connected Services

A researcher has flagged an unpatched flaw in Anthropic's Claude for Chrome extension. Here's what it affects, how it works, and what to do about it in the meantime.

What You Need to Know

Ax Sharma of Manifold Security disclosed a vulnerability in Anthropic's Claude for Chrome browser extension that lets a malicious extension hijack Claude's built-in AI workflows without the user ever clicking anything. The flaw was confirmed present in version 1.0.80 as of July 7, 2026. Anthropic acknowledged the report through its bug bounty program, but no patch had shipped as of disclosure. Anyone who has connected Claude for Chrome to Gmail, Google Docs, Google Calendar, or Salesforce should take this seriously right now.

What's Vulnerable

The root cause is a missing trust check. Browsers distinguish real user interactions from programmatically generated ones through a property called Event.isTrusted, which is set to true only when a person physically clicks something. The Claude extension listens for click events tied to its predefined workflows but never verifies whether those clicks actually came from a real user before acting on them.

That gap matters because any Chrome extension with permission to run on claude.ai, a common and often overlooked permission, can inject a page element and fire a synthetic click. Claude accepts it as genuine and executes the associated action. Since the supported workflows reach into Gmail, Google Docs, Google Calendar, and Salesforce, a successful attack could expose sensitive email content, documents, calendar details, or CRM data.

Why This Matters

This isn't a case of Claude being tricked by a clever prompt. It's a case of Claude trusting the wrong signal entirely, treating a scripted action as if a person had approved it. That distinction matters because it sidesteps the usual defenses people rely on, like being careful about what they type or click. The vulnerability lives in permissions most users grant without a second thought, which is exactly what makes it worth checking today rather than waiting.

What to Do

Audit every Chrome extension currently installed and remove anything that isn't from a verified, trusted source, especially any extension with permission to run on claude.ai. Disable the "Act without asking" setting in the Claude extension immediately, since that setting is what allows this attack to execute without a prompt for confirmation. Until Anthropic confirms a patched release, treat any active Claude connection to Gmail, Google Docs, Google Calendar, or Salesforce as a potential liability and decide whether it's worth keeping active in the meantime.

Agentic AI tools are only as trustworthy as the permission checks behind them, and this is a reminder to look closely at what you've actually granted access to.

Active Exploitation of Critical SharePoint Flaw CVE-2026-58644

Microsoft's SharePoint Server has a critical, actively exploited vulnerability, and it's just landed on CISA's must-patch list. Here's what's going on and how to respond.

What You Need to Know

CVE-2026-58644 is a critical RCE vulnerability in Microsoft SharePoint Server, carrying a CVSS score of 9.8 and confirmed active exploitation in the wild. It stems from deserialization of untrusted data and allows unauthenticated attackers with network access to run arbitrary code on affected servers. CISA has added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of July 19, 2026, and it's part of a broader wave of SharePoint issues disclosed this year. If your organization runs SharePoint Server, this belongs at the top of the patching queue.

What's Vulnerable

The flaw affects both internet-facing SharePoint deployments and internally accessible instances, and the risk isn't limited to external attackers. Anyone who has already pivoted in from another compromised system inside the network can reach it too. A successful exploit hands an attacker full control of the SharePoint server, opening the door to data theft, service disruption, ransomware deployment, and further lateral movement across the environment.

CVE-2026-58644 doesn't exist in isolation. It's one of several SharePoint vulnerabilities disclosed this year, alongside CVE-2026-45659 and CVE-2026-32201, both high-severity flaws, and CVE-2026-56164, an elevation-of-privilege issue that attackers can use after initial compromise to expand their foothold. Taken together, these flaws raise the odds of chained attacks against environments that haven't kept current on patches.

Why This Matters

A CVSS 9.8 score paired with confirmed in-the-wild exploitation and a federal KEV deadline is about as clear a signal as CISA sends. This isn't a theoretical risk sitting in a report somewhere, it's already being used against real targets. Add in the related SharePoint flaws disclosed this year and the picture gets worse, since an attacker who can't get in through one flaw may still get in through another, then chain toward full server control.

What to Do

Organizations running SharePoint Server 2016, 2019, or Subscription Edition should prioritize the July 2026 security updates and review their environments for indicators of compromise. Where immediate patching isn't possible, cut down exposure by restricting internet access to affected servers, enforcing network segmentation, and applying WAF protections to filter malicious requests. Make sure logging is comprehensive across IIS, SharePoint ULS, Windows Event Logs, and any endpoint detection tools in place, since early detection matters as much as the patch itself while remediation is in progress.

With a July 19 federal deadline already on the books, this isn't one to leave sitting in a backlog.

High-Severity Splunk Vulnerabilities CVE-2026-20296 and CVE-2026-20297

Splunk has patched two high-severity vulnerabilities affecting Splunk Enterprise and, in one case, Splunk Cloud Platform. Here's what they do and how to close the gap.

What You Need to Know

Splunk has disclosed two high-severity vulnerabilities, CVE-2026-20296 and CVE-2026-20297, affecting Splunk Enterprise, with CVE-2026-20296 also impacting certain Splunk Cloud Platform releases. Both create pathways for attackers to perform unauthorized actions inside Splunk environments, potentially exposing sensitive data, altering configurations, or enabling broader compromise. There's no confirmed active exploitation yet, but given how much access these flaws can hand over if abused, they're worth prioritizing now rather than waiting for that to change.

The Details

CVE-2026-20296 is a CSRF vulnerability tied to Deployment Server functionality in Splunk Web. Deployment Server endpoints don't validate CSRF tokens on GET requests, which lets an attacker trick an authenticated user holding the list_deployment_server capability into unknowingly triggering attacker-controlled SPL searches. Because those searches run as splunk-system-user, a successful attack can expose stored credentials, indexed data, and configuration details across the environment. It requires the victim to take some action, like clicking a malicious link, so it's best understood as a phishing-adjacent risk rather than something an attacker can trigger at will.

CVE-2026-20297 is a path traversal vulnerability in the App Install REST endpoint. A user holding both the edit_local_apps and install_apps capabilities can manipulate the app installation path to write files outside the intended directory, landing them in $SPLUNK_HOME/etc/ and its subdirectories instead. That means an attacker who already holds those elevated privileges could plant files in sensitive system locations, which could support further compromise down the line. Splunk has found no workaround for this one, so patching is the only real fix.

Used together, these two flaws could form a chain: one to gain powerful SPL query execution, the other to place malicious files deeper in the system.

Why This Matters

Splunk environments sit at the center of a lot of security operations, holding credentials, indexed logs, and configuration data that would be valuable to any attacker looking to expand their reach. A CSRF flaw that hijacks a privileged user's session and a path traversal flaw that lets an already-privileged user write files outside their lane might look like separate, contained issues on their own. Chained together, they start to look like a real path toward deeper compromise, which is exactly the kind of risk that's easy to underestimate before it's exploited.

What to Do

Splunk has released patches for affected versions, including Splunk Enterprise 10.4.1, 10.2.5, 10.0.8, and 9.4.13, along with 9.3.14 for the 9.3 branch, plus updated Splunk Cloud Platform release tracks. Prioritize upgrading to these versions and review who holds access to Splunk Web, especially administrative capabilities and the deployment server and app installation permissions named above. Where immediate patching isn't possible for CVE-2026-20296, consider disabling Splunk Web if operationally feasible. Reducing exposure through VPN access, enforcing least privilege for user roles, and educating administrators on CSRF and phishing risks will all help lower the odds of exploitation. Monitoring for unusual SPL activity and REST endpoint requests, along with tightening filesystem permissions on Splunk hosts, adds another layer of visibility while patches roll out.

Neither flaw has a confirmed exploit in the wild yet, which makes this the right moment to get ahead of it rather than catch up later.

Fake Coding Tests Hide OtterCookie Malware in SVG Flag Images

The latest Contagious Interview campaign trades on a familiar lure, a coding test, but hides its payload somewhere developers wouldn't think to look.

What You Need to Know

North Korea-linked threat actors are back with another twist on their long-running developer job scam, this time hiding malware inside SVG flag icons using steganography. The campaign, tracked as REF9403 and tied to the broader Contagious Interview operation, uses fake coding assessments to get developers running trojanized repositories that quietly deploy a four-stage OtterCookie-aligned payload. If you or your team evaluate coding challenges from unfamiliar recruiters, this one is worth understanding before the next unsolicited offer shows up.

How the Attack Works

The lure starts with an enticing Slack message advertising modern Next.js and NestJS work. From there, targets get funneled into direct messages and asked to clone and run a "test" project that looks legitimate on the surface but is engineered for silent compromise. The trick is in how the malicious code hides. The repositories split a base64-encoded payload into fragments and bury them inside HTML comments across multiple SVG images made to look like standard country flag icons. A JavaScript file named serverValidation.js reassembles those fragments and makes sure the malware executes on every server boot.

Once active, the payload deploys OtterCookie, a cross-platform tool that has evolved into a modular stealer and remote access trojan. It harvests browser and cryptocurrency wallet data, exfiltrates files with sensitive extensions, and delivers a Socket-based RAT for persistent control. Notably, it also targets AI coding tool artifacts like .claude, .cursor, and .gemini, suggesting the operators are deliberately after developer secrets and workflow metadata, not just generic credentials.

Why This Matters

This campaign is a reminder that compromising one developer can open the door to much larger supply chain attacks. What makes it particularly effective is that the trojanized project runs perfectly fine on the surface while executing hidden logic in the background, so there's no obvious red flag telling a developer something is wrong. Hiding payload fragments inside image files that look like ordinary flag icons also sidesteps a lot of the scrutiny code review normally catches, since nobody expects an SVG to carry executable logic.

What to Do

Security teams should tighten controls over developer environments, enforce strict validation of code test repositories before they're run, and monitor for unusual Socket.IO activity and base64-heavy SVG assets appearing in project trees. Developers should treat unsolicited job offers and off-platform coding assessments with real caution, verify employers through trusted channels rather than taking a Slack DM at face value, and run any evaluation projects in isolated sandboxes rather than on primary workstations tied to production systems or sensitive source code.

A coding test is a normal part of hiring. Running someone else's code on your main machine without checking it first doesn't have to be.