The feature is designed to address the growing use of more convincing scams, including messages created with the help of AI. Instead of sending messages to WhatsApp’s servers for analysis, Scam Alert uses a small machine learning model that runs directly on the user’s device.

Once enabled, the model examines messages from people who are not saved as contacts. It looks for patterns in the conversation and language that may indicate common scam techniques.

The message itself stays on the device during this process. WhatsApp says it does not automatically send messages to Meta, WhatsApp, or another third party for review. Users decide what happens next.

If a message appears suspicious, WhatsApp can display a warning to the recipient. The user can then choose to block the sender, report the conversation, continue chatting, or mark the conversation as trusted if they believe the warning is incorrect.

Privacy Is a Key Part of Scam Alert

WhatsApp says the system was designed around three main ideas: local processing, no automatic reporting, and user control.

The company still needs some information to understand how well the feature performs. Instead of collecting individual messages, WhatsApp uses a privacy-focused analytics system that gathers limited information such as how many warnings were displayed and what actions users took.

This information is processed using Trusted Execution Environments (TEEs) and additional privacy techniques before aggregated statistics are sent to Meta.

Protecting the AI Model

Another concern is making sure attackers cannot secretly deliver a modified version of the scam-detection model to specific users.

WhatsApp says each model version is published with a SHA-256 hash in an append-only transparency system before it is deployed. This creates a record that can be used to verify that the model has not been secretly changed.

Model downloads also use an Oblivious HTTP (OHTTP) relay, which helps prevent the server from directly linking a model request to a user’s IP address.

WhatsApp says even the process used to assign users to different model versions for testing happens locally on their devices rather than being controlled by the server.

Additional Security Controls

The company says Scam Alert was designed to protect against several types of threats, including outside attackers, malicious employees, and compromised third-party suppliers.

Its security measures include isolated confidential computing environments, encrypted memory, and additional protections around the systems running the analytics infrastructure.

Users can also check information about the feature through WhatsApp’s transparency controls. The in-app activity section shows details such as which messages were analyzed and which model version was used.

External Researchers Can Test the System

WhatsApp is also expanding its Bug Bounty program to cover parts of the Scam Alert technology, including the machine learning models and analytics infrastructure.

This gives security researchers an opportunity to look for weaknesses and verify whether the system is being used only for its stated purpose of detecting scams.

Limited Beta Release

Scam Alert is initially being introduced through a limited beta rollout. WhatsApp says it plans to continue testing the technology with security researchers before making it more widely available.

The company also plans to publish a technical white paper explaining how the system works in greater detail.

The approach reflects a growing focus on building AI-powered security features without giving up user privacy. Instead of sending private conversations to the cloud for analysis, WhatsApp is attempting to combine on-device AI, confidential computing, and transparency mechanisms to detect scams while keeping message content protected.

The post WhatsApp Scam Alert: New Protection Against Hackers appeared first on First Hackers News.

The research involves OpenAI, Anthropic, and Google, and shows that encrypted reasoning data produced by powerful models could potentially be reused with less restricted models from the same provider. In some cases, this could allow the hidden reasoning to be reconstructed in readable text.

Researchers from the ELLIS Institute Tübingen, Max Planck Institute, MATS Research, and Snyk investigated the issue across the Claude, GPT, and Gemini ecosystems. The attack does not require special privileges and can be carried out through normal API access.

How the Attack Works

Modern reasoning models perform additional processing before producing their final answers. Much of this internal reasoning is intentionally hidden from users because it may contain sensitive information, system instructions, safety-related decisions, or proprietary model behavior.

Instead of keeping all conversation state on the server, some AI APIs return encrypted data that can be sent back with later requests. This allows the model to continue a conversation without storing every detail on the provider’s side.

Researchers found a potential weakness in how these encrypted reasoning packages were protected.

The data was not sufficiently tied to the specific model, user, or session that originally created it. This meant a reasoning package generated by a more heavily protected model could potentially be submitted to another model within the same provider’s ecosystem.

Using Smaller Models to Reveal Hidden Data

The researchers demonstrated an attack technique in which a reasoning package from a powerful model was passed to a less restricted model.

The smaller model could then be prompted to reproduce information contained inside the encrypted package.

This creates an unusual security problem. The attacker does not necessarily need to break the encryption directly. Instead, another model can potentially act as an intermediary that helps expose the information.

The research team reported similar behavior across the GPT, Claude, and Gemini model families.

Researchers also compared the recovered reasoning data with usage information provided through the APIs to determine whether the extracted material corresponded to the original reasoning process.

Hidden Reasoning Can Contain Sensitive Information

The concern goes beyond exposing how an AI model thinks.

Researchers analyzed thousands of publicly available AI agent transcripts collected from sources such as GitHub and Hugging Face. Their analysis identified hundreds of pieces of potentially sensitive information inside recovered reasoning data.

This included:

• 367 pieces of personally identifiable information
• 182 hardcoded credentials
• 62 API keys
• 33 passwords
• 30 personal email addresses

The problem is that some of this information may never appear in the model’s visible response.

A developer could therefore publish an AI session or agent log believing it contains no secrets, while sensitive information remains hidden inside associated reasoning data.

A New Risk for AI Agents

The research also highlights a potential problem for autonomous AI systems.

If security monitoring only examines the visible conversation between a user and an AI agent, malicious instructions hidden inside reasoning-related data could potentially escape detection.

An attacker could attempt to place instructions inside an encrypted reasoning package and have those instructions processed later by an AI agent.

This creates a potential indirect prompt injection scenario where the malicious content is not obvious in the conversation that security tools are monitoring.

For organizations using AI agents to interact with cloud services, databases, code repositories, or business applications, this type of hidden input deserves particular attention.

Which AI Platforms Were Studied?

The research covered major model ecosystems from three providers:

The exact attack paths and model combinations varied between providers, but the broader issue was similar: reasoning data was not sufficiently isolated from other models within the same ecosystem.

Providers Have Already Responded

The researchers reported the findings to the affected companies through responsible disclosure.

OpenAI, Anthropic, and Google acknowledged the research and introduced server-side protections. According to the researchers, the original proof-of-concept attacks could no longer be reproduced against the updated API implementations.

That reduces the immediate risk from the specific attack demonstrated in the research, but the findings highlight a larger issue for the AI industry.

As AI systems become more complex, security controls need to protect not only visible prompts and responses but also the internal data exchanged between models and supporting services.

How Organizations Can Reduce the Risk

AI providers and companies building applications around LLMs can take several steps to protect sensitive reasoning-related data.

Bind encrypted data to its source. Reasoning packages should be cryptographically linked to the specific model, user, and session that created them.

Separate model tiers. A payload generated by one model should not automatically be accepted by another model unless that behavior is explicitly intended and securely controlled.

Rotate older cryptographic keys. Where historical encrypted data may have been exposed, organizations should consider key rotation and invalidation strategies.

Protect AI logs. Developers should treat reasoning-related payloads, signatures, and encrypted model data as sensitive information. These fields should be removed or sanitized before logs are shared publicly.

Why This Matters

The research shows that protecting AI systems is not only about securing the model itself.

Modern LLM platforms involve APIs, model tiers, encrypted payloads, agent frameworks, logging systems, and multiple supporting services. A weakness in the connection between these components can create a security problem even when the underlying model remains protected.

For organizations adopting AI agents and reasoning models, the lesson is clear: hidden data should be treated as sensitive data, even when users cannot see it.

The post LLM API Bugs Leak Hidden Reasoning Traces appeared first on First Hackers News.

The attackers are primarily targeting users through Discord servers and gaming forums, where fake cheat downloads are shared as legitimate software. By taking advantage of the popularity of Roblox cheats, the campaign aims to steal sensitive information and gain complete control of victims’ computers.

Researchers say the operation continues to evolve, with new infrastructure and malware capabilities being added regularly.

How the Attack Works

The infection starts when users download what appears to be a genuine Xeno Roblox cheat.

The downloaded archive looks convincing, containing realistic folder structures and harmless-looking files that make it appear authentic.

Instead of launching a game cheat, the installer quietly begins executing malicious code in the background.

If Java is not already installed on the system, the malware automatically installs a local Java Runtime Environment without the user’s knowledge. This prepares the system for the next stage of the attack.

Multi-Stage Malware Deployment

After the initial infection, the malware loads a heavily obfuscated Java application disguised as a normal Windows executable.

Before continuing, it performs several checks to determine whether it is running inside a virtual machine, sandbox, or debugging environment. These techniques help attackers avoid detection by security researchers.

‍Follow Us on:Linkedin, Instagram, Facebook to get the latest security news!

The malware then collects basic system information and securely communicates with its command-and-control (C2) server to register the infected device and download additional malicious components.

Java RAT Gains Full System Access

The final payload is a Java Remote Access Trojan (RAT) hidden inside folders designed to resemble legitimate Microsoft GameDVR files associated with the Xbox Game Bar.

To remain active after a reboot, the malware creates registry Run entries using names that appear to be legitimate Windows components. It also attempts to obtain elevated privileges, allowing it to perform more advanced malicious activities.

Once established, the RAT connects to attacker-controlled servers and waits for further instructions.

What Information Does the Malware Target?

Unlike basic information-stealing malware, this campaign combines credential theft with powerful remote surveillance features.

The malware is capable of:

• Stealing saved passwords and browser cookies.
• Collecting credentials from Chrome, Edge, Opera, and Brave.
• Hijacking Discord, Roblox, and Minecraft accounts.
• Targeting cryptocurrency wallets, including Exodus.
• Capturing keystrokes and mouse activity.
• Taking screenshots.
• Streaming the victim’s desktop.
• Accessing webcam feeds.
• Uploading, downloading, and modifying files.
• Running PowerShell commands.
• Providing attackers with remote shell access.

These capabilities allow attackers to fully control an infected computer while collecting valuable personal and financial information.

Why Gamers Are Being Targeted

Researchers believe the campaign specifically targets Roblox players because many users search online for “free” or “undetected” cheat tools.

Young gamers are especially at risk, as they may download unofficial software from Discord communities or third-party websites without realizing it contains malware.

Since many gaming PCs are shared with family members, a successful infection could also expose banking information, personal documents, saved passwords, and private communications stored on the same device.

Malware Campaign Continues to Evolve

Security researchers, including Bitdefender and previous investigations by ThreatLocker, have linked the campaign to malware previously tracked as Powercat.

The operation has reportedly been active since early 2026 and continues to expand through new command-and-control servers and updated malware modules. The attackers also use encrypted communications and in-memory payload execution, making the malware more difficult to detect and remove.

How to Stay Protected

To reduce the risk of infection, users should follow these security best practices:

• Avoid downloading unofficial Roblox cheats or game modification tools.
• Only install software from trusted sources.
• Keep antivirus and security software up to date.
• Enable multi-factor authentication (MFA) on gaming and email accounts.
• Regularly update Windows and installed applications.
• Be cautious of download links shared through Discord servers or online gaming forums.

As cybercriminals increasingly target gaming communities, staying away from unofficial cheat software remains one of the most effective ways to avoid malware infections and protect personal information.

IOCs

The post Fake Roblox Hacks Target Discord and Gaming Credentials appeared first on First Hackers News.

Under the new policy, API keys created on or after August 17, 2026, will have a maximum lifetime of 30 days. Developers will no longer be able to create API keys that remain valid for 365 days. In addition, all API keys generated before August 17, 2026, will automatically expire on November 1, 2026.

The move is part of Microsoft’s broader effort to strengthen package security and encourage developers to adopt more secure authentication methods.

Why Is Microsoft Reducing API Key Lifetimes?

NuGet API keys are used by developers to publish packages to NuGet.org. These keys often function like passwords and are commonly stored in CI/CD pipelines, build servers, repository secrets, deployment environments, and other automation platforms.

Although this makes automated package publishing easier, it also creates an attractive target for cybercriminals. If attackers gain access to a long-lived API key, they could publish malicious packages under the name of a trusted project without immediately being detected.

By limiting API keys to just 30 days, Microsoft aims to significantly reduce the period during which a stolen credential can be exploited.

The Growing Risk of Supply Chain Attacks

Software supply chain attacks continue to rise as attackers increasingly target trusted software repositories instead of individual users.

Rather than directly attacking organizations, threat actors compromise developer credentials or package publishing accounts to insert malicious code into legitimate software packages. Once published, these compromised packages may be downloaded by thousands of developers and organizations, allowing malware to spread rapidly across multiple environments.

Microsoft explained that reducing the lifespan of publishing credentials is an important step toward minimizing this risk.

Recent Incidents Highlight the Threat

Microsoft referenced recent software package compromise incidents that demonstrate the dangers of stolen publishing credentials.

One notable example involved the NX Console package in the npm ecosystem. Attackers reportedly obtained valid publishing credentials and used them to release a malicious version of the package.

The compromised package was activated approximately 6,000 times within just 36 minutes before it was removed. This incident showed how quickly attackers can exploit trusted software repositories when publishing credentials fall into the wrong hands.

Events like these continue to reinforce the need for stronger authentication and shorter-lived credentials across software ecosystems.

Shorter API Keys Improve Security—but Don’t Eliminate the Risk

While reducing API key validity lowers the window of opportunity for attackers, Microsoft emphasized that shorter expiration periods alone cannot completely prevent credential theft.

API keys can still be exposed through several common scenarios, including:

• Source code repositories
• CI/CD pipeline logs
• Insecure secret storage
• Build servers
• Compromised developer workstations
• Accidentally shared configuration files

If an attacker obtains an active API key, they may still be able to publish malicious packages before the credential expires.

For this reason, Microsoft is encouraging developers to move beyond traditional API keys altogether.

Microsoft Recommends NuGet Trusted Publishing

To provide a more secure publishing process, Microsoft recommends using NuGet Trusted Publishing, which became available in September 2025.

Trusted Publishing replaces long-lived API keys with OpenID Connect (OIDC) authentication, allowing CI/CD platforms to securely verify their identity without permanently storing publishing credentials.

Instead of relying on reusable secrets, supported CI/CD services generate a temporary identity token during the publishing workflow.

NuGet.org validates this token against security policies configured by the package owner before issuing a temporary publishing credential that is valid only for that specific publishing operation.

This approach greatly reduces the chances of stolen credentials being reused by attackers.

How Trusted Publishing Works

The Trusted Publishing workflow is designed to eliminate long-lived secrets from automated publishing environments.

The process works as follows:

1. A supported CI/CD platform generates a short-lived OIDC identity token.
2. NuGet.org verifies the identity of the workflow.
3. Repository, workflow, and optional environment details are validated against the package owner’s security policy.
4. NuGet.org issues a temporary API key for that publishing session.
5. Once the publishing job is complete, the temporary credential expires automatically.

Because no reusable API key is stored in repositories or CI/CD secrets, attackers have far fewer opportunities to steal publishing credentials.

Benefits of Trusted Publishing

Microsoft highlighted several advantages of adopting Trusted Publishing:

• Eliminates long-lived API keys.
• Reduces the risk of credential theft.
• Removes the need to store publishing secrets in repositories.
• Simplifies credential rotation.
• Improves software supply chain security.
• Limits the impact of compromised developer environments.
• Strengthens automated package publishing workflows.

GitHub Actions and GitLab users are encouraged to migrate to Trusted Publishing before the August 2026 deadline.

What Developers Should Do Before the Deadline

Organizations that continue using traditional NuGet API keys should begin preparing now.

Microsoft recommends the following actions:

• Review all NuGet publishing workflows.
• Identify API keys created before August 17, 2026.
• Update automation to support 30-day API key rotation.
• Restrict API keys to the minimum required package scope.
• Apply the least-privilege principle for publishing permissions.
• Avoid storing API keys in source code, configuration files, or logs.
• Immediately revoke any API key that may have been exposed.
• Begin migrating CI/CD pipelines to Trusted Publishing wherever possible.

Taking these steps can help reduce the risk of malicious package publishing while ensuring a smooth transition to the new policy.

Looking Ahead

Microsoft indicated that shortening API key lifetimes is only one phase of its long-term software supply chain security strategy. As support for Trusted Publishing expands across additional CI/CD platforms, the company may further reduce API key validity periods in the future.

Developers and organizations are encouraged to adopt modern authentication methods such as OpenID Connect to strengthen package security, reduce reliance on reusable secrets, and better protect the software supply chain against evolving cyber threats.

The post Microsoft Takes Action to Strengthen NuGet Supply Chain Security appeared first on First Hackers News.

The malware also abuses WeChat by injecting malicious DLLs into the application, allowing attackers to maintain long-term access, monitor activity, and potentially steal sensitive information.

How the Attack Works

AtlasRAT begins with a Delphi executable disguised as a legitimate AGE Flash Player installer (FlashPlay.exe). While it appears harmless, the installer secretly launches the malware’s multi-stage infection process.

The attack unfolds in four stages:

• Stage 1: Decrypts and loads the next payload directly into memory without creating files on disk.
• Stage 2: Rebuilds encrypted shellcode using multiple encryption techniques, including Base64, XOR, and AES-256-CBC.
• Stage 3: Connects to a hardcoded command-and-control (C2) server and manually loads the next component into memory.
• Stage 4: Executes MainDll.dll, the primary AtlasRAT payload that provides attackers with remote access to the infected system.

By keeping every stage in memory, AtlasRAT significantly reduces forensic evidence and avoids many file-based security controls.

Advanced Remote Access Capabilities

Once active, AtlasRAT establishes an encrypted communication channel using TLS combined with ChaCha20 encryption. The malware even uses a self-signed certificate that mimics Microsoft to help disguise its network traffic.

The RAT allows attackers to:

• Execute additional plugins remotely
• Download and run malicious files
• View and terminate running processes
• Perform offline keylogging
• Continue collecting data even when the system is disconnected from the internet

‍Follow Us on:Linkedin, Instagram, Facebook to get the latest security news!

WeChat DLL Injection

One of AtlasRAT’s most notable capabilities is its ability to inject malicious DLLs into WeChat.exe using LoadLibraryW and CreateRemoteThread.

This enables attackers to:

• Hide inside a trusted application
• Maintain long-term persistence
• Monitor user activity
• Potentially steal sensitive communications

Using a legitimate messaging application also helps the malware blend into normal system activity.

Persistence Techniques

AtlasRAT includes a dedicated persistence module called persistence86.dll, which helps the malware survive system reboots.

Its persistence techniques include:

• Modifying the Windows BITS database
• Abusing NTUSER.MAN for logon persistence
• Bypassing User Account Control (UAC)
• Using registry hijacking to maintain access

These methods make removal more difficult and help attackers retain control of compromised devices.

Threat Intelligence Findings

Researchers identified 146 unique AtlasRAT samples during a 180-day VirusTotal analysis. Multiple malware variants, versioned builds, and development artifacts suggest AtlasRAT is part of a continuously evolving malware framework rather than a single campaign.

Current public analysis has been shared by security researchers from ASEC, Proofpoint, Hexastrike, and other threat intelligence teams.

Proofpoint attributes AtlasRAT activity to TA4922, a Chinese-speaking cybercrime group known for using HR and finance-themed phishing lures. Other researchers have observed similarities with campaigns linked to the Silver Fox threat cluster, although there is currently no conclusive evidence connecting the two groups.

Detection Opportunities

Security teams should monitor for indicators such as:

• Unusual TLS connections using suspicious self-signed Microsoft-themed certificates
• Remote DLL injection into WeChat.exe
• CreateRemoteThread activity originating from untrusted processes
• Unexpected modifications to the BITS database or NTUSER.MAN
• Suspicious files such as offline.ini, AtlasPro.ini, MODIf.html, and Wxfun.dll

These behaviors may indicate an active AtlasRAT compromise.

AtlasRAT is more than a traditional remote access trojan. Its modular architecture, four-stage in-memory execution, encrypted communications, DLL injection, and advanced persistence mechanisms make it a highly capable threat designed to evade conventional security defenses.

As the malware continues to evolve, organizations should strengthen endpoint monitoring, memory-based threat detection, and behavioral analytics to identify attacks that bypass traditional file-based security solutions.

IOCs

The post New AtlasRAT Attack Uses 4-Stage In-Memory Loader to Target WeChat appeared first on First Hackers News.

CastleLoader Continues to Evolve

CastleLoader has been active for some time as a malware loader that delivers additional malicious payloads onto compromised systems. Previous campaigns primarily distributed information stealers and remote access tools. However, recent investigations reveal that threat actors have significantly upgraded the framework by integrating NeedleStealer into their attack chain.

Researchers also observed the first use of Rust and Golang within these campaigns. Combined with in-memory execution, these technologies help attackers avoid traditional security detection while improving the malware’s flexibility.

NeedleStealer Focuses on Financial Theft

One of the most concerning additions is a Rust-based component that impersonates popular cryptocurrency wallet applications. Victims are presented with convincing recovery phrase prompts that appear legitimate. If users enter their wallet seed phrase, attackers can gain complete access to their cryptocurrency holdings.

Another component, developed in Golang, installs malicious browser extensions that appear to be legitimate software. These extensions allow attackers to hijack browser sessions and steal credentials without requiring victims to repeatedly enter their passwords.

Multiple Campaigns Using Similar Techniques

Researchers identified three related campaigns—Urutyka, Garrigin, and Noidret—that all rely on CastleLoader as the initial infection method. Although each campaign introduces slight variations, they follow a similar multi-stage approach to deliver malware while making forensic analysis more difficult.

The attackers also continue to use digitally signed installers and carefully managed command-and-control infrastructure, increasing the likelihood that the malware will bypass security defenses.

Why This Matters

The latest CastleLoader campaigns demonstrate a clear shift toward targeting high-value financial information and online accounts. Instead of simply stealing passwords, attackers are now attempting to compromise cryptocurrency wallets and active browser sessions, allowing them to bypass authentication and gain access to valuable assets.

Organizations should remain alert for suspicious PowerShell activity, unexpected browser extensions, unusual outbound network connections, and software installers from untrusted sources. Behavioral monitoring and modern endpoint protection can also help detect malware that executes directly in memory.

Conclusion

The integration of NeedleStealer marks another step in the evolution of CastleLoader. By combining multi-stage malware delivery, Rust and Golang payloads, browser session hijacking, and cryptocurrency theft, threat actors are building more sophisticated attack campaigns. As these techniques continue to evolve, organizations should strengthen endpoint security, monitor suspicious activity, and educate users about the risks of downloading software from unverified sources.

The post NeedleStealer Targets Crypto Wallets and Browsers appeared first on First Hackers News.

The vulnerability affects the copy-on-write (CoW) feature of XFS. It is caused by a race condition that occurs when two O_DIRECT write operations access the same reflink-enabled file at nearly the same time.

How the Vulnerability Works

Normally, when a shared file is modified, XFS creates a new private copy of the data before writing changes. However, during this process, the kernel briefly releases an internal lock while waiting for transaction log space.

If another write request arrives during this short window, it can change the file mapping before the first operation finishes. As a result, the first write uses outdated information and writes data directly to the original disk block instead of a new one.

Since O_DIRECT bypasses the page cache, the corrupted data is written straight to disk, allowing attackers to overwrite protected system files.

Why It Is Dangerous

Qualys demonstrated that a normal local user could exploit the flaw on a default RHEL 10.2 system and remove the root account’s password protection within seconds. After the attack, the system granted passwordless root access.

The attack is difficult to detect because:

• No kernel log entries are generated.
• The changes remain after a reboot.
• Even systems protected by SELinux are vulnerable.
• Existing Linux security protections do not block the attack.

Researchers believe the vulnerability has existed since Linux kernel version 4.11, released in 2017, potentially affecting more than 16 million systems worldwide.

Who Is Affected?

A system is vulnerable if it has:

• Linux kernel 4.11 or later without the security patch.
• An XFS filesystem with reflink=1 enabled.
• A directory writable by an unprivileged user.
• A valuable target file such as a SUID binary or protected system file.

Confirmed affected distributions include:

• RHEL 8, 9 and 10
• CentOS Stream 8, 9 and 10
• Oracle Linux 8, 9 and 10
• Rocky Linux 8, 9 and 10
• AlmaLinux 8, 9 and 10
• CloudLinux 8, 9 and 10
• Amazon Linux 2 and Amazon Linux 2023
• Fedora Server 31 and later

Lower-risk distributions

• Debian
• Ubuntu
• SUSE

These distributions are mainly affected only if XFS with reflink support has been manually configured.

Existing Security Features Cannot Stop It

One of the biggest concerns is that common Linux security protections do not prevent this attack. Technologies such as SELinux, KASLR, SMEP, SMAP, kernel lockdown, and container isolation operate at different layers and cannot stop exploitation of this filesystem flaw.

At present, there is no temporary workaround that completely mitigates the vulnerability. Installing the security update is the only effective solution.

AI Helped Discover the Flaw

The vulnerability was identified through a collaboration between Qualys and Anthropic. Researchers used Anthropic’s Claude Mythos Preview AI model to search for race-condition vulnerabilities similar to the well-known Dirty COW bug.

After identifying the issue, Qualys engineers independently verified the findings, created a proof-of-concept, and responsibly disclosed the vulnerability to Linux maintainers.

Part of a Growing Trend

RefluXFS is one of several major Linux privilege escalation vulnerabilities disclosed during 2026. Other recent discoveries include:

• Copy Fail (CVE-2026-31431)
• Dirty Frag (CVE-2026-43284 and CVE-2026-43500)
• DirtyClone (CVE-2026-43503)

These vulnerabilities highlight a growing trend of attackers exploiting flaws that allow protected files or memory to be modified, ultimately leading to privilege escalation.

What Organizations Should Do

Organizations should patch affected systems as soon as possible, especially internet-facing servers, multi-tenant environments, and shared systems.

Security updates are already available for major enterprise Linux distributions, including RHEL, Oracle Linux, AlmaLinux, Rocky Linux, and Fedora. After installing the update, administrators should perform a full system reboot to ensure the patched kernel is running.

Since there is currently no reliable mitigation other than patching, keeping systems updated is the best defense against the RefluXFS vulnerability.

The post Critical RefluXFS Flaw Threatens Linux Systems appeared first on First Hackers News.

The vulnerabilities were discovered by Miggo Security and affect RabbitMQ versions starting from 3.13.0. Security updates are now available, and organizations are encouraged to patch affected systems as soon as possible.

Two Critical Security Flaws

The first and more severe vulnerability, CVE-2026-57219, exposes RabbitMQ’s OAuth configuration through a management API endpoint that does not require authentication. If an organization stores an OAuth client secret for identity providers such as Auth0, Microsoft Entra ID, Keycloak, or UAA, an attacker with network access to the management interface could retrieve that secret.

Using the exposed credentials, an attacker may obtain administrator-level access to the RabbitMQ server, allowing them to manage messages, queues, users, and broker settings.

The second vulnerability, CVE-2026-57221, affects permission validation within RabbitMQ. Although less severe, it allows authenticated users with limited privileges to discover queues, exchanges, and usage statistics that they should not normally be able to access. In shared or multi-tenant environments, this information could help attackers gather intelligence for future attacks.

Recommended Security Measures

Both vulnerabilities have been fixed in RabbitMQ 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.

Organizations should take the following steps to protect their RabbitMQ deployments:

• Update RabbitMQ to a supported patched version immediately.
• Rotate OAuth client secrets after applying updates.
• Restrict access to the RabbitMQ management interface (port 15672) and avoid exposing it to public networks.
• Isolate tenants using separate virtual hosts instead of shared environments.
• Review container images and Helm charts to ensure they are not using vulnerable RabbitMQ versions.
• Monitor RabbitMQ systems for unusual administrative activity or unauthorized access attempts.

These vulnerabilities highlight the importance of securing management interfaces and regularly updating infrastructure components. Prompt patching, strong access controls, and continuous security monitoring remain essential for protecting messaging platforms and the applications that depend on them.

The post RabbitMQ OAuth Bug Allows Unauthorized Access appeared first on First Hackers News.

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.

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.