Researchers identified multiple issues, including traffic leaks, third-party tracking, weak encryption practices, and VPN tunnel hijacking, raising concerns about the security of many Android VPN services.

Security Risks Behind Insecure VPN Apps

The primary purpose of a VPN is to route all internet traffic through an encrypted tunnel, preventing unauthorized parties from monitoring user activity. However, researchers found that many Android VPN apps fail to protect all network traffic.

In some cases, DNS requests, IPv6 connections, and certain application traffic bypass the encrypted VPN tunnel, exposing information such as browsing activity, IP addresses, and other network metadata. These leaks are particularly concerning when users connect to public Wi-Fi networks, where attackers may monitor or manipulate exposed traffic.

The research also found that several VPN applications contain advertising, analytics, and tracking software development kits (SDKs). These components can collect device identifiers, approximate location data, application usage statistics, and other telemetry. While some data collection may support diagnostics or performance monitoring, excessive tracking contradicts the privacy expectations users typically associate with VPN services.

Another concern is VPN tunnel hijacking, where malicious Android applications may exploit weaknesses in a VPN app’s implementation to misuse its network connection or interfere with its operation. Although Android has introduced security improvements over recent releases, poorly implemented VPN applications can still expose users to unnecessary risks.

Recommendations for Android Users

Users should carefully evaluate VPN applications before installing them and avoid assuming that every VPN service provides the same level of security.

To improve protection, consider the following best practices:

• Choose reputable VPN providers with transparent ownership and privacy policies.
• Prefer providers that have completed independent security audits.
• Select VPNs that offer DNS leak protection, IPv6 protection, and a reliable kill switch.
• Review requested permissions before installing any VPN application.
• Keep Android devices and VPN apps updated with the latest security patches.
• Enable Android’s Always-on VPN and Block connections without VPN settings when available.
• Avoid installing unknown or untrusted applications alongside VPN software, especially on devices used for work or sensitive activities.

As VPN usage continues to grow, this research highlights the importance of choosing trusted providers rather than relying solely on marketing claims. A VPN can only protect user privacy if it is implemented securely, maintained properly, and supported by transparent data-handling practices. Regular updates, careful provider selection, and good security hygiene remain essential for safeguarding personal and organizational data.

The post Android VPN Apps Expose User Traffic appeared first on First Hackers News.

How the Attacks Work

Threat actors are abusing vulnerabilities such as:

• Unauthenticated file upload
• Remote Code Execution (RCE)
• Server-Side Request Forgery (SSRF)
• Deserialization flaws

These vulnerabilities allow attackers to upload webshells, giving them persistent remote access to compromised websites.

Impact on Organizations

Organizations worldwide, including small and medium-sized businesses, have already been affected. Once attackers gain access, they can:

• Execute commands remotely
• Install additional malware
• Steal sensitive data
• Harvest user credentials
• Move laterally within internal networks
• Use compromised websites for defacement or hosting scams

Incident Response Recommendations

If you suspect your website has been compromised, assume the system is affected until proven otherwise.

Security teams should:

• Inspect plugin directories for suspicious or unknown files.
• Review web server logs for unusual GET or POST requests.
• Isolate affected servers immediately.
• Preserve logs for forensic investigation.
• Audit user accounts, authentication logs, and network activity.
• Look for persistence mechanisms and signs of lateral movement or data exfiltration.

If a webshell is found, remove malicious files, eliminate persistence mechanisms, and restore the website from a recent trusted backup before bringing services back online.

Affected Software and Plugins

Security Recommendations

Organizations should:

• Apply the latest security patches immediately.
• Enable automatic updates where practical.
• Identify vulnerable plugins and CMS components.
• Remove unused or unsupported plugins.
• Monitor websites for suspicious activity and unauthorized file changes.
• Investigate any unusual web traffic or unexpected server behavior promptly.

Keeping WordPress plugins and other CMS components fully updated remains the most effective way to reduce the risk of exploitation.

The post WordPress Plugin Vulnerabilities Enable RCE appeared first on First Hackers News.

The flaw is caused by insecure BinaryFormatter deserialization, a long-known security risk in .NET applications. According to researchers, the issue continues a pattern of similar vulnerabilities affecting Veeam’s .NET Remoting components.

How the Vulnerability Works

Veeam Backup & Replication is widely used by organizations to manage backup, disaster recovery, and replication across virtual, physical, and cloud environments.

The vulnerability affects the Veeam Backup Service, which exposes a .NET Remoting HTTP endpoint on TCP port 8000.

Instead of allowing only trusted object types, the service relies on a blacklist-based filtering mechanism. While known dangerous classes are blocked, any unlisted serializable class is still accepted, creating an opportunity for attackers to bypass the protection.

Low-Privilege Users Can Exploit the Flaw

Researchers found that the vulnerability can be exploited by any authenticated domain user.

The application only verifies whether a user belongs to the standard Windows User group, meaning administrative privileges are not required to reach the vulnerable component.

An attacker can abuse this weakness to execute malicious serialized objects and ultimately run arbitrary commands on the backup server.

Exploitation Process

The attack follows a sequence of interactions with the Veeam service before delivering the malicious payload.

During exploitation, the attacker:

• Creates a restore session.
• Initializes the backup session.
• Sends a malicious BinaryFormatter payload.
• Triggers insecure deserialization.
• Executes arbitrary commands on the server.

Researchers demonstrated that the exploit abuses System.Data.DataSet deserialization to instantiate ObjectDataProvider, which can invoke Process.Start() and execute attacker-controlled commands.

Because the Veeam Backup Service typically runs with SYSTEM privileges, successful exploitation can result in full control of the backup server.

Why This Vulnerability Exists

The root cause is Veeam’s continued use of BinaryFormatter, a serialization technology that Microsoft has considered unsafe and deprecated since .NET 5.

Researchers explain that relying on blocklists is not a long-term solution because attackers can continue discovering new classes capable of bypassing the restrictions.

Previous vulnerabilities, including CVE-2024-40711 and CVE-2025-23120, were based on the same underlying weakness.

Patch and Mitigation

Veeam addressed the issue in version 12.3.2.4854 (KB4696) by adding the newly discovered gadget class to its BinaryFormatter blacklist.

However, researchers note that the update does not remove BinaryFormatter or redesign the underlying deserialization process.

In contrast, Veeam Backup & Replication 13.x removes the BinaryFormatter-based implementation entirely, eliminating this class of vulnerabilities.

Security Recommendations

Organizations using Veeam Backup & Replication 12.x should take immediate action to reduce the risk of exploitation.

Recommended security measures include:

• Apply the latest Veeam security updates.
• Restrict access to TCP port 8000.
• Limit network exposure of backup servers.
• Consider deploying backup servers in workgroup mode instead of domain-joined environments where appropriate.
• Monitor backup servers for suspicious deserialization or remote execution activity.

Because backup infrastructure is frequently targeted by ransomware groups, organizations should prioritize patching this vulnerability to prevent attackers from gaining control over critical backup systems.

The post Critical Veeam Backup Flaw Discovered appeared first on First Hackers News.

The decision comes after videos circulated online showing users remotely shutting down battery-powered three-wheelers, raising serious concerns about passenger and road safety.

Authorities have also warned that any other apps offering similar unsafe remote-control capabilities could face similar action.

Why Were These Apps Removed?

The apps were originally developed as Battery Management System (BMS) tools for electric vehicles.

Their intended purpose was to help:

• Monitor battery health and charging status
• Track vehicle location
• Manage fleet operations
• Disable vehicles in cases of theft or loan default

However, authorities found that the remote shutdown feature was allegedly being misused to stop vehicles without the driver’s permission.

How the Apps Were Misused

According to reports, some users were able to remotely disable nearby e-rickshaws using the connected battery management system.

Researchers believe the issue was caused by weak access controls, allowing unauthorized users with access credentials to send remote shutdown commands.

This meant that features designed for fleet management could potentially be misused by:

• Unauthorized individuals
• Rival financiers
• Disgruntled employees
• Malicious actors
• Pranksters

Such actions could interrupt journeys and create serious safety risks for both drivers and passengers.

Security Concerns

The incident highlights growing security challenges within Internet of Things (IoT)-enabled electric vehicles.

Researchers note that many low-cost electric vehicle platforms prioritize functionality over security, leaving connected systems vulnerable to misuse.

Some of the reported concerns include:

• Weak authentication mechanisms
• Shared or leaked login credentials
• Insufficient access controls
• Lack of driver authorization
• Remote shutdown without safety checks

Without proper safeguards, features intended to improve vehicle management can become potential security risks.

Government Response

Following reports of misuse, the government instructed Google and Apple to remove the affected applications from their respective app stores.

Officials also indicated that additional apps found enabling similar remote vehicle shutdown capabilities could face the same action.

The move reflects increasing efforts to improve the security of connected transportation technologies and protect public safety.

Recommendations for Fleet Operators

Organizations using connected Battery Management Systems should strengthen their security by:

• Enabling multi-factor authentication (MFA)
• Restricting access to authorized users only
• Preventing remote shutdown while vehicles are moving
• Maintaining audit logs for remote commands
• Conducting regular security assessments of BMS platforms
• Securing backend APIs and user credentials

As connected electric vehicles become more common, securing remote management features will be essential to prevent misuse and ensure passenger safety.

The post India Bans Apps Used to Stop E-Rickshaws Remotely appeared first on First Hackers News.

Although the attack requires local code execution on the host system, the research demonstrates that several built-in security mechanisms can be bypassed, ultimately leading to full administrative control within the sandbox.

How Claude Cowork Protects Its Sandbox

Claude Cowork Sandbox is designed to help users build applications and automate tasks using Claude Code within an isolated environment.

On Windows, the platform runs workloads inside a Hyper-V-based Ubuntu virtual machine protected by several security layers, including:

• Hyper-V isolated Ubuntu VM
• Authenticode-based named pipe authentication
• Bubblewrap sandbox namespaces
• Per-session unprivileged Linux users
• Seccomp filtering
• Domain-restricted outbound network access

These protections are intended to isolate workloads and prevent unauthorized access to the underlying environment.

Researchers Found a Way Around the Protections

According to research published by Armadin, the attack targeted the CoworkVMService, a Local System service responsible for managing communication between Windows and the Ubuntu virtual machine.

The service uses a named pipe and validates that only applications digitally signed by Anthropic can communicate with it.

Researchers attempted to bypass the signature validation but found that the authentication checks correctly rejected forged signatures and invalid trust chains.

Instead, they identified another attack path.

DLL Sideloading Enabled Code Execution

Researchers discovered that claude.exe loads USERENV.dll from its application directory before loading the legitimate Windows system library.

By placing a malicious USERENV.dll alongside the application, they successfully performed DLL sideloading, allowing arbitrary code to execute inside the trusted Anthropic process.

Because the malicious code was running within the signed application, it successfully passed the service’s identity verification.

Root Access Achieved Through RPC Manipulation

After gaining code execution, researchers analyzed the application’s JSON-based RPC protocol used to communicate with the virtual machine.

The protocol exposed several methods, including:

• configure
• startVM
• isGuestConnected
• spawn

While most security controls continued to function correctly, researchers discovered that two parameters—isResume and allowedDomains—were forwarded directly to the sandbox daemon without sufficient validation.

By fuzzing the RPC interface, they reconstructed the parameter structure and identified a logic flaw.

Normally, setting isResume to false creates a new unprivileged Linux user.

However, when isResume was set to true, the existing user validation was skipped entirely.

This allowed researchers to specify any username, including root, and execute commands with root privileges inside the sandbox.

Security Impact

The vulnerability demonstrates that multiple security boundaries can be bypassed once an attacker gains local code execution.

Although Anthropic’s threat model assumes local access is already required, the research highlights how privilege escalation can occur even inside heavily sandboxed AI environments.

Successful exploitation could allow an attacker to:

• Execute commands as root inside the Linux sandbox.
• Bypass intended privilege restrictions.
• Gain unrestricted administrative access within the virtual machine.
• Circumvent multiple sandbox security controls.

The issue was successfully demonstrated against Claude Desktop for Windows version 1.9255.2.0.

As AI-powered development environments continue to evolve, this research serves as a reminder that sandbox implementations should be regularly reviewed to ensure privilege boundaries cannot be bypassed through chained vulnerabilities.

The post Claude Cowork Sandbox Flaw Allows Root Access appeared first on First Hackers News.

Instead of relying on traditional malware downloaders, the attackers combine trusted applications, DLL sideloading, reflective loading, and process hollowing to quietly install remote access malware while avoiding detection.

Fake Software Websites Used as Lures

The attackers created numerous fake download websites designed to imitate popular software applications.

Some of the impersonated software includes:

• OBS Studio
• DNS Jumper
• DS4Windows
• Bandicam
• Other widely used freeware applications

Many of these websites were translated into more than ten languages, allowing the campaign to target users across multiple regions.

Researchers also found that search engine optimization (SEO) techniques helped these malicious websites appear higher in search results, increasing the likelihood that users would download the infected installers.

How the Infection Works

Each downloaded archive contains a mix of legitimate and malicious files.

The package typically includes:

• A legitimate Microsoft-signed install.exe
• A malicious install.res.1033.dll
• An Assets folder containing the legitimate software
• A renamed ScreenConnect MSI installer disguised as a trusted file, such as vcredist_x64.dll

When the user launches the installer, the signed executable automatically loads the malicious DLL through DLL sideloading.

The DLL silently installs the ScreenConnect service and registers it under names that appear legitimate, such as Microsoft Update Service, before connecting the infected system to attacker-controlled servers.

Multiple Techniques Used to Evade Detection

Once ScreenConnect is installed, attackers execute PowerShell and VBScript commands to strengthen their foothold on the system.

The scripts perform several actions, including:

• Adding Microsoft Defender exclusions for entire drives and important processes.
• Disabling User Account Control (UAC) prompts.
• Dropping additional malware components into the C:\Users\Public directory.

The malware then decrypts an encrypted payload stored in secret_bytes.txt. A PowerShell script named cap.ps1 reconstructs the payload by decoding hexadecimal data, applying XOR decryption, and rebuilding the executable entirely in memory.

The recovered .NET assembly is loaded directly into memory using reflective loading, avoiding the need to write the malware to disk.

AsyncRAT Deployed Through Process Hollowing

To further reduce detection, the malware launches RegAsm.exe in a suspended state before replacing its memory with the AsyncRAT payload using process hollowing.

Running the malware inside a legitimate Windows process helps it blend in with normal system activity and bypass some security tools that rely on process reputation.

Persistence and Infrastructure

To maintain long-term access, the attackers create a scheduled task named MasterPackager.Updater.

The task runs every two minutes, allowing the malware to restart automatically after reboots or if its processes are terminated.

Kaspersky researchers also identified two major infrastructure clusters supporting the campaign.

The operation used:

• Multiple command-and-control (C2) servers
• Numerous spoofed domains
• Separate download servers for malware archives
• ScreenConnect configuration files pointing to attacker infrastructure

Based on domain registration data, researchers believe the campaign has been active since October 2025 and continued operating through March 2026, with several fake download websites still accessible online.

Security Recommendations

Because this campaign abuses trusted software and legitimate administrative tools, organizations should strengthen their defenses against both malware and software supply chain attacks.

Security teams should consider the following measures:

• Download software only from official vendor websites.
• Block MSI installers from untrusted locations.
• Monitor for newly created Windows services and scheduled tasks.
• Detect unusual DLL sideloading activity.
• Watch for suspicious use of PowerShell, VBScript, and signed Windows binaries.
• Monitor outbound connections to unknown remote management servers.
• Keep endpoint protection enabled and regularly updated.
• Educate users to verify download sources before installing software.

This campaign demonstrates how attackers continue to blend legitimate administration tools with advanced malware techniques. By combining trusted software, stealthy execution methods, and fake software distribution sites, threat actors can significantly increase the chances of compromising both individual users and enterprise environments.

IOCs

The post Fake Installers Spread AsyncRAT Using ScreenConnect appeared first on First Hackers News.

The vulnerability affects environments where OpenID Connect (OIDC) authentication is enabled. Due to improper verification of cryptographic signatures, attackers can bypass authentication and gain unauthorized access to affected systems.

How the Vulnerability Works

According to CISA, the issue occurs because SimpleHelp does not properly validate identity tokens during the OIDC authentication process. As a result, a remote attacker can create forged identity tokens and have them accepted as legitimate.

This allows attackers to impersonate authorized users without valid credentials and gain technician-level access to the application. In some environments, the vulnerability may also allow attackers to bypass multi-factor authentication (MFA), significantly increasing the risk of unauthorized access.

Because SimpleHelp is widely used for remote IT support, successful exploitation could provide attackers with direct access to managed devices, creating opportunities for privilege escalation and lateral movement across enterprise networks.

Immediate Action Required

CISA has instructed federal agencies to remediate the vulnerability under Binding Operational Directive (BOD) 26-04, with a deadline of July 2, 2026. The agency also recommends that organizations follow vendor guidance, prioritize patching internet-facing systems, and review affected environments for signs of compromise.

If patches cannot be applied immediately, organizations should consider temporarily removing vulnerable SimpleHelp servers from public access until security updates are in place.

Although CISA has not linked the vulnerability to ransomware attacks, its inclusion in the KEV catalog confirms that threat actors are actively exploiting the flaw. Organizations using SimpleHelp should treat this issue as a high priority and apply the latest security updates as soon as possible to reduce the risk of unauthorized access.

The post CISA Flags SimpleHelp Flaw as Actively Exploited appeared first on First Hackers News.

Instead of exchanging phone numbers, users will be able to share a unique username when starting new conversations. This feature is especially useful when joining community groups, networking at events, or interacting with people for the first time.

The rollout is being introduced in phases, with users able to reserve their preferred usernames before the feature becomes widely available.

How the Username Feature Works

Once the feature is enabled, new contacts will only see a user’s username instead of their phone number. Existing chats and contacts will continue to function normally, and users who prefer sharing phone numbers can continue using WhatsApp as they always have.

To prevent impersonation and abuse, WhatsApp has introduced several rules for creating usernames:

• Usernames must be 3–35 characters long.
• Only lowercase letters, numbers, periods, and underscores are allowed.
• Every username must include at least one letter.
• Usernames that resemble website domains, such as .com or .in, are not permitted.
• Each username must be unique, and users can choose to match their existing Instagram or Facebook handle for consistent branding.

WhatsApp has also added an optional username key, a four-digit PIN-like code that provides an additional layer of privacy. New contacts must enter this code before they can send a message, helping reduce spam and unwanted conversations. Existing contacts are not affected by this requirement.

Improved Privacy and User Protection

Unlike many social media platforms, WhatsApp usernames are not searchable through a public directory. Users cannot browse or discover other usernames unless they already know the exact handle, significantly reducing unsolicited messages and unwanted contact.

The feature is available across Android, iOS, Windows, and WhatsApp Web as the rollout expands globally. Users can reserve a username by navigating to Settings → Account → Username on the latest version of the app. WhatsApp also provides username suggestions if a preferred handle has already been taken.

The new system is particularly beneficial for creators, businesses, and organizations, allowing them to use the same username across WhatsApp, Instagram, and Facebook for a consistent online identity.

By moving from phone number-based communication to username-based messaging, WhatsApp is strengthening user privacy while reducing unnecessary exposure of personal contact information. The update also brings the platform closer to privacy-focused messaging services that have long supported handle-based communication.

The post WhatsApp Introduces Usernames for Private Messaging appeared first on First Hackers News.

According to security researchers, the vulnerability is caused by unsafe deserialization of user-controlled data, allowing specially crafted input to be executed on the server.

How the Vulnerability Works

The issue exists in the way Splunk Secure Gateway processes alert data stored in its KV Store. A low-privileged authenticated user can submit a specially crafted JSON payload through the Splunk REST API.

Due to weaknesses in the application’s validation process, the malicious data is accepted as legitimate and passed to the deserialization component. This enables attackers to execute arbitrary Python code with the privileges of the Splunk service account.

Researchers found that the validation logic fails to inspect all fields within the submitted JSON document. As a result, attackers can bypass security checks by embedding malicious content inside otherwise valid data structures.

A successful attack requires only a valid low-privileged Splunk account and does not rely on user interaction, making the vulnerability particularly dangerous in shared enterprise environments.

Below is a simplified proof-of-concept (PoC) demonstrating how the vulnerability can be exploited using a benign command:

import jsonpickle

import subprocess

payload = {     

“py/object”: “spacebridgeapp.data.alert_data.Alert”,

    “notification”:         

“py/reduce”:

[             

{“py/function”: “subprocess.check_output”},             

{“py/tuple”: [[“uname”, “-a”]]}         

]     

}

}

encoded = jsonpickle.encode(payload)

decoded = jsonpickle.decode(encoded, safe=True)

print(decoded)

subprocess.check_output(["uname", "-a"]) command during data deserialization. This confirms that enabling the safe=True option in jsonpickle does not fully prevent exploitation.

The flaw affects Splunk Secure Gateway versions 3.8.x, 3.9.x, and 3.10.x, along with Splunk Enterprise versions released before 10.0.7, 10.2.4, and 10.4.0. Splunk has fixed the issue in Secure Gateway versions 3.8.67, 3.9.20, and 3.10.6.

Security Recommendations

To reduce the risk of exploitation, organizations should:

• Apply the latest Splunk Secure Gateway security patches immediately.
• Upgrade to the fixed versions: SSG 3.8.67, 3.9.20, or 3.10.6, and supported Splunk Enterprise releases.
• Disable the Secure Gateway app if it is not actively being used.
• Restrict KV Store write permissions to trusted administrators only.
• Enforce the principle of least privilege by limiting access to authorized users.
• Avoid deserializing untrusted data with jsonpickle or similar libraries without proper validation.
• Implement input validation and class allow-listing to prevent unsafe deserialization.
• Monitor Splunk logs for unusual activity or unauthorized changes to the KV Store.

Following these best practices can help organizations reduce the risk of remote code execution and strengthen the overall security of their Splunk environment.

The post Splunk Secure Gateway RCE Vulnerability Discovered appeared first on First Hackers News.

The fake invoices often impersonate well-known brands such as Norton, McAfee, Apple, and PayPal, creating a false sense of urgency by claiming that expensive products or subscriptions have been purchased.

How the Scam Works

The Shop app automatically collects order information from connected email accounts and Shop Pay transactions, allowing users to view all their purchases in one place. Attackers appear to be exploiting this functionality or related merchant processes to insert fake orders into users’ purchase history.

These fraudulent orders typically display costly items, including antivirus subscriptions, smartphones, or gift cards. The invoices also include fake customer support phone numbers hidden within product descriptions, shipping details, or order notes.

When victims call the number, they are connected to scammers posing as customer support representatives. The attackers then attempt to steal sensitive information such as login credentials, payment card details, one-time passwords, or convince victims to install remote access software.

Researchers emphasized that there is currently no evidence that Shopify or the Shop app has been breached. Instead, the campaign appears to abuse legitimate platform features to distribute fraudulent content.

How to Stay Safe

Users should always verify unexpected purchase notifications before taking any action. If an invoice appears suspicious, check your bank account or the official service provider directly instead of calling phone numbers listed in the receipt.

To reduce the risk of becoming a victim:

• Verify purchases through official websites or banking apps.
• Never call support numbers included in unexpected invoices.
• Report suspicious orders through the Shop app or Shopify’s abuse channels.
• Avoid installing software at the request of unknown callers.

This campaign demonstrates how cybercriminals are increasingly exploiting trusted platforms instead of relying solely on phishing emails. As users become more cautious of email scams, attackers are shifting their focus to legitimate applications where fraudulent content is less likely to raise suspicion.

The post Fake Shopify Invoices Steal User Credentials appeared first on First Hackers News.