Trending Topics

Oracle E‑Business At Risk: CVE-2026-46817 Lets Attackers Take Over Oracle Payments And Exposed ERP Systems

Oracle Payments has a critical, actively exploited vulnerability, and hundreds of internet-facing EBS instances are sitting exposed right now. Here's what's at risk and how to close the gap.

What You Need to Know
Over 900 Oracle E-Business Suite instances are exposed online right now, and attackers are actively exploiting one of them: CVE-2026-46817, a critical flaw in Oracle Payments that allows full system takeover over the network. This turns a single missing patch into a direct threat to financial operations, sensitive data, and the stability of core ERP environments.

What's Vulnerable
CVE-2026-46817 was publicly disclosed on May 28, 2026, and detailed in Oracle's May 2026 Critical Patch Update as affecting the File Transmission component of Oracle Payments, a core module within Oracle E-Business Suite. The flaw hits Oracle Payments versions 12.2.3 through 12.2.15 and is triggered via standard HTTP network access, requiring no prior authentication, which makes internet-facing EBS deployments trivial to target remotely. With a CVSS score of 9.8 and an SVRS score of 94, it's rated CRITICAL, reflecting near-total loss of confidentiality, integrity, and availability if exploited.

An unauthenticated attacker can remotely take complete control of an affected Oracle Payments system through network access alone, achieving full remote code execution on the Oracle Payments stack. From there, an attacker can access, modify, or destroy sensitive financial data, inject or process fraudulent transactions, and disrupt or halt payment processing entirely. Exploitation is already labeled "In The Wild," confirming this isn't theoretical: attackers are actively probing and abusing the flaw. A public proof-of-concept, CIA911/cve-2026-46817_PoC, is available on GitHub, sharply lowering the barrier to entry for opportunistic attackers and smaller criminal groups who can weaponize the code without doing their own research.

Why This Matters
No specific APT groups have been publicly linked to campaigns exploiting this flaw yet, but the combination of a ready-to-use PoC and the sheer value of the financial data Oracle Payments processes makes widespread exploitation highly likely. For organizations relying on Oracle Payments within their EBS deployments, a successful compromise means severe financial risk, reputational damage, and heightened exposure to regulatory and compliance failures, especially in sectors where payment integrity and data protection are tightly regulated.

What to Do
Any organization running Oracle Payments versions 12.2.3 through 12.2.15 should assume it's at risk, particularly if its EBS instances are reachable from the internet. Start by inventorying all Oracle Payments deployments and verifying and applying the patches included in Oracle's May 2026 Critical Patch Update. Where possible, remove direct internet exposure by placing EBS systems behind VPNs, access gateways, or other controlled access mechanisms. Alongside patching, increase logging and monitoring around the File Transmission component, payment workflows, and system-level access. Watch for anomalous transactions, unexpected process activity, or configuration changes that could signal compromise.

Phantom Squatting Turns AI Hallucinated Domains Into Real Phishing And Supply Chain Threats

Phantom squatting is the newest twist on domain-based phishing, and it starts with a hallucination instead of a typo. Here's how the attack works and what security teams should do about it.

What You Need to Know
A new attack technique called phantom squatting turns AI hallucinations into live phishing infrastructure. Attackers register the fake domains that large language models invent, then let those same trusted AI tools direct users and agents straight into the trap.

What's Happening
Researchers describe phantom squatting as the domain-side counterpart to "slopsquatting," where criminals register nonexistent package names suggested by AI coding assistants. When an AI model does not know the real URL for a brand or service, it often produces a plausible, professional-looking domain that has never been registered. Whoever buys that domain first instantly inherits the misplaced trust of the users and automated agents relying on the AI.

In one study, models generated millions of links for hundreds of global brands, many of which mapped to malicious infrastructure, and left hundreds of thousands of hallucinated domains unowned and ready for attackers to scoop up. Models also hallucinate domains consistently, so different models often invent the same fake URL for the same brand, which makes it easy for criminals to identify promising targets and build phishing kits around them.

Why This Matters
Traditional defenses are built for domains with a history: reputation systems, blocklists, and threat feeds need time and bad behavior to mark something as risky. A brand new phantom domain starts life with a clean record that filters cannot flag. Because the victim often receives the link from a trusted AI assistant or workflow, they are more likely to click it or integrate it without hesitation, feeding credentials, API keys, or code directly into an attacker-controlled site. For defenders, this is both a software supply chain risk and a user safety issue, one that calls for treating AI outputs as unverified drafts rather than trusted references.

What to Do
Security teams can start mapping hallucinated domains by systematically probing AI models, then monitoring domain registrations for those exact names to catch phantom squatters before users or agents reach them. At a practical level, stop agents from automatically opening AI-generated links, enforce domain verification for any workflow involving passwords or code, and invest in URL filtering tuned to AI-era threats, where hallucinations can become real attack surfaces overnight.

Fake Claude Code And ClickFix Commands: How MacSync Stealer Hijacks macOS And Windows

A new stealer campaign is using fake Claude Code lures to hijack macOS and Windows systems, and it doesn't rely on a software bug at all. Here's how the attack works and what developers and security teams should watch for.

What You Need to Know
A new campaign called MacSync is quietly hijacking macOS and Windows systems by abusing fake Claude-branded code, Google Ads, and a single copy-paste Terminal command that victims believe is safe. Rather than exploiting a software flaw, the attackers rely entirely on social engineering, turning trusted AI tools and developer workflows into the delivery channel for a powerful infostealer.

What's Happening
At the core of the operation is ClickFix, a technique that tricks users into "fixing" a problem by pasting a helpful-looking command directly into Terminal or a shell, which in reality silently downloads and installs malware. Victims typically start with an ordinary Google search for things like Homebrew setup, disk space analyzers, online DNS resolvers, or Claude Code extensions, and are shown sponsored links that look legitimate at the top of the results. These ads lead to convincing lure pages hosted on official-looking platforms such as claude[.]ai, Medium, Squarespace, or VS Code marketplace clones, where a fake "macOS Secure Command Execution" guide or "Claude Code" install page instructs users to paste a single shell command to get started.

Once that command runs, MacSync takes effect. On macOS, it downloads a Mach-O payload that bypasses Gatekeeper checks and installs an infostealer designed to harvest Keychain contents, browser saved logins, session cookies, and crypto wallet keys, then bundles them into an archive, typically named osalogging[.]zip, for exfiltration to a command-and-control server. The malware uses a fake macOS user agent and a multi-stage infection chain to blend in with normal system behavior, making it harder for conventional endpoint tools to catch. Researchers note that MacSync is an evolved rebrand of the older Mac.c malware, so the operators are iterating on their tooling while keeping the social engineering pattern intact.

The campaign doesn't stop at macOS. A parallel strain targets Windows developers through a trojanized Claude Code plugin that impersonates legitimate extensions in Visual Studio Code. Once installed, the plugin runs quietly in the background, downloading second-stage payloads such as a fake utility named CrossMark2 that focuses on credential theft and persistence. Threat intelligence from multiple vendors ties both the macOS ClickFix lures and the VS Code plugin to the same infrastructure and C2 servers, suggesting a single actor or closely linked group is behind the broader "Claude Fraud" operation.

Why This Matters
For developers and power users, this campaign is a stark reminder that the biggest risk is often the code you choose to run, not the bugs you patch after the fact. Because the lures are built around trusted brands and normal developer habits, like searching for setup guides or installing extensions, standard technical defenses have less to catch. This is a targeting choice, not an accident: the campaign is clearly tuned to reach the growing audience of AI and developer tool users.

What to Do
Never paste a command into Terminal or PowerShell that you don't fully understand, and verify that any Claude or other AI-branded guide is actually hosted and vetted by the vendor before following it. Prefer official download pages over sponsored search results, especially for developer tools and AI extensions. Security teams should treat AI artifacts, shared chats, and extension marketplaces as potential attack surfaces, monitor shell history for unexpected curl or script execution patterns, and add indicators for MacSync and CrossMark2 infrastructure to their detection stack, since this family of campaigns is actively evolving.

MacSync is a good case study in how far social engineering can get attackers without ever touching a vulnerability, and a sign that developer tooling and AI brands will keep being an attractive lure.

CISA Confirms Ransomware Gangs Are Actively Exploiting Microsoft Defender's BlueHammer Flaw

Ransomware gangs have moved from proof-of-concept to active exploitation on a Microsoft Defender flaw Hunter Strategy flagged back when it first surfaced. Here's what changed and what to check on your endpoints now.

What You Need to Know
CISA has confirmed that ransomware gangs are actively exploiting CVE-2026-33825, a Microsoft Defender privilege escalation vulnerability known as BlueHammer. The flaw was originally released with proof-of-concept code under the name Nightmare Eclipse and was covered in a previous Hunter Strategy Trending Topics post, but it's now moved from theoretical risk to active use by cybercrime groups.

What's Vulnerable
BlueHammer is a race condition in Microsoft Defender that allows a local attacker to access the Security Account Manager database, which stores password hashes for local Windows accounts. The exploit works by triggering a Defender detection, then using an NTFS junction point to redirect Defender's file remediation path, causing the platform to write with SYSTEM privileges to a location the attacker already controls. From there, an attacker either cracks the recovered password hashes offline to obtain plaintext credentials or passes the hashes directly as authentication tokens. Either way, SYSTEM access is gained without ever having the actual account password.

Why This Matters
Microsoft released a patch for this flaw earlier in the year as part of April Patch Tuesday, but many organizations still haven't applied it. That gap has given cybercrime groups ample time to build a working exploit, test it, identify targets, and carry out attacks. Because BlueHammer requires an existing foothold to escalate, it's most dangerous as the second stage of an intrusion, turning limited initial access into full SYSTEM control.

What to Do
Apply Microsoft's patch to eliminate exposure from this vulnerability if you haven't already. Audit local administrator passwords across endpoints and make sure they aren't shared or reused. Review endpoint telemetry for suspicious Defender service activity, unexpected privilege changes, and lateral movement indicators, since those are the signs an attacker already has the foothold BlueHammer needs to escalate.

Checkmarx Uncovers Eight Trojanized PyPI Packages Targeting Telegram Bot Developers

Operation Navy Ghost: What You Need to Know

Researchers have uncovered a supply chain campaign hiding a Telegram-based backdoor inside fake Pyrogram packages on PyPI. Here's how the attack works and what to do if you installed one of the affected packages.

What You Need to Know
Checkmarx researchers uncovered a supply chain campaign dubbed Operation Navy Ghost, in which a single threat actor published eight malicious packages on PyPI disguised as branches of the popular Pyrogram library. Any developer who installed one of the affected packages should treat their server as compromised.

What's Vulnerable
The malicious packages were posted as early as November 2025 and were designed to look like legitimate forks of Pyrogram, a Python framework widely used to build bots on Telegram for purposes like scheduling and automated support. Pyrogram is no longer actively maintained by its original developers, which made it a prime target for a trojan campaign like this. The fake packages looked identical to real Pyrogram forks because they included the complete original source code. The only addition was a hidden file called secret[.]py buried inside the helpers module, which activated when an infected bot launched and registered concealed command handlers. Those hidden handlers gave the attacker direct command-line access to the victim's server through Telegram itself.

The backdoor ran under the infected application's full authority, meaning it could access databases, credentials, cloud API keys, environment variables, and the victim's own Telegram session data. The campaign appears to deliberately target production bot deployments rather than development environments, since a Telegram bot running in production has standing connections to databases and cloud services that a development instance wouldn't.

Why This Matters
Because the malicious packages contained the real Pyrogram source code with only one hidden file added, they were built to pass a casual review. And because the backdoor specifically favored production deployments, a successful compromise means an attacker had standing access to the systems and credentials that actually matter, not just a sandboxed test environment.

What to Do
Check your environment against the eight trojanized packages below. If any are installed, treat that server as compromised:

• VLifeGram
• VLife-Gram
• pyrogram-navy
• pyrogram-styled
• pyrogram-zeeb
• kelragram
• sepgram
• pyrogram-kelra

Remove any of these immediately, rotate every credential and API key stored on or accessible from the affected server, and revoke the Telegram bot token for any bot that ran on that machine. Checkmarx has published the attacker's Telegram IDs and profile URLs as indicators of compromise, so cross-check those against your own logs and bot activity.