The company revealed the incident on November 3, 2026, stating that the attacker gained initial access through a third-party component before moving from a development environment into parts of its production infrastructure.

Attack Timeline

According to Chainstack, the attacker accessed a development environment on October 26, 2026, and subsequently escalated access to parts of the production environment.

The intrusion was detected on October 31, when Chainstack blocked the attacker’s access and began securing its systems.

Customer Information Potentially Exposed

The compromised database contained customer-related information, including:

• Organization names
• Account holder names
• Member email addresses
• Password hashes

The attacker also gained access to systems storing node credentials. Although Chainstack reported no evidence that these credentials were read, the company is treating them as potentially exposed.

The compromised database contained customer-related information, including:

• Organization names
• Account holder names
• Member email addresses
• Password hashes

The attacker also gained access to systems storing node credentials. Although Chainstack reported no evidence that these credentials were read, the company is treating them as potentially exposed.

Customers Urged to Rotate Credentials

Chainstack has advised customers to take precautionary security measures, including:

• Rotate node credentials.
• Regenerate platform API keys.
• Change account passwords, particularly reused passwords.
• Monitor accounts for suspicious activity.
• Remain alert to potential phishing attempts.

Possible Connection to AI-Powered Attack Campaign

The incident is assessed to share links with a broader AI-powered cyberattack campaign involving the ARTEX framework. Other organizations, including WorkOS and Chainalysis, have also reported security incidents involving AI-assisted offensive operations.

However, the specific attack method used against Chainstack has not been publicly detailed, and the company has not confirmed the identity of the attacker.

The incident highlights the growing risks facing blockchain infrastructure providers and the importance of securing third-party components, monitoring production environments, and maintaining strong credential management practices.

The post Chainstack Data Breach Exposes Customer Data and Password Hashes appeared first on First Hackers News.

The reported deletion happened in about 103 seconds while the agent was working on a task to rebuild a project mirror. The incident was described in a Reddit post along with a verification report. However, there has not yet been an independent forensic investigation confirming the full details.

How the Deletion Happened

The project used a temporary mirror containing thousands of files and Windows directory junctions. The agent created a Python cleanup script after the normal mirror process could not update the files as expected.

The main problem appears to have involved how Windows directory junctions were detected. The script used os.walk() with link following disabled, but the report claims this did not properly identify the Windows junctions.

As a result, directories connected through those junctions were reportedly treated as regular folders. The cleanup process then removed files outside the intended mirror location.

The report says the script processed more than 55,000 files. After accounting for the files that were supposed to be removed, the reviewer estimated that 48,218 files from the live project were deleted.

Git Repository Was Also Affected

The reported damage was not limited to normal project files.

Important parts of the Git repository, including the .git/objects, refs, and logs directories, were reportedly emptied. This meant Git could no longer access the commit data needed for normal history and recovery.

The Git index reportedly remained, but many of the actual objects it referenced were missing. This made normal Git-based recovery difficult.

The report also said that hundreds of directories were left empty, although some other files, backups, documentation, and data outside the affected project remained untouched.

What Developers Can Learn

The incident highlights the risks of allowing AI coding agents to perform operations that can modify or delete large numbers of files.

Developers should treat these tools as privileged automation, especially when they have access to production projects or important repositories.

Some useful safeguards include:

• Test destructive commands with a dry run first.
• Generate a list of files that will be affected before deleting anything.
• Prefer moving files to a temporary location instead of immediately deleting them.
• Limit the agent’s access to only the directories it actually needs.
• Use isolated containers or virtual machines for high-risk tasks.
• Keep reliable backups outside the working directory.
• Require approval before large-scale file operations.

The exact details of this incident have not been independently confirmed, so it should be viewed as a user-reported case rather than confirmed evidence of a specific Claude Code defect. Still, it demonstrates why filesystem restrictions, backups, and human approval remain important when using autonomous coding tools.

The post 48K Files Wiped in 103 Seconds by Claude Code Agent appeared first on First Hackers News.

The issue impacts applications that use Active Storage with the libvips image-processing library. According to the Rails maintainers, applications that allow image uploads from untrusted users are at the highest risk. To give organizations time to update their systems, technical details of the exploit have been temporarily withheld until August 28, 2026.

How the Vulnerability Works

The flaw is caused by the way Active Storage interacts with the libvips image-processing library during image variant generation. Active Storage failed to block certain unsafe image-processing operations, allowing a specially crafted image upload to trigger unintended behavior.

As a result, an attacker may be able to read files that are accessible to the Rails application. These files can contain valuable information, including:

• Application secret_key_base
• Database usernames and passwords
• Cloud storage access keys
• Third-party API tokens
• Environment variables and deployment secrets

If attackers obtain these credentials, they could potentially forge application sessions, access cloud resources, compromise databases, or move further inside an organization’s infrastructure.

Affected Versions and Protection

Applications are vulnerable if they:

• Use Active Storage with libvips (config.active_storage.variant_processor = :vips)
• Accept image uploads from untrusted users
• Run affected versions of Active Storage

The vulnerability affects:

• Active Storage versions earlier than 7.2.3
• Versions 8.0.0 to 8.0.4
• Versions 8.1.0 to 8.1.2

Rails has released security updates to fix the issue and recommends using libvips 8.13.8 or later, which blocks unsafe image-processing operations. Organizations that cannot immediately upgrade Rails can enable additional protection by setting the VIPS_BLOCK_UNTRUSTED environment variable when using a supported version of libvips.

Recommended Actions

Organizations should act quickly to reduce the risk of exploitation by:

• Updating Rails Active Storage to the latest patched version.
• Upgrading libvips to 8.13.8 or newer.
• Reviewing applications that accept image uploads.
• Rotating sensitive credentials, including database passwords, cloud keys, API tokens, and secret_key_base.
• Monitoring systems for suspicious file access or unauthorized activity.

Changing the secret_key_base will invalidate existing user sessions, signed cookies, and Active Storage URLs, requiring users to log in again.

Conclusion

CVE-2026-66066 highlights how vulnerabilities in image-processing components can expose critical application secrets and potentially lead to full server compromise. Organizations using Ruby on Rails should install the latest security updates immediately, review uploaded file handling, and rotate any sensitive credentials that may have been exposed before applying the patch.

The post Critical Rails Vulnerability Exposes Sensitive Data appeared first on First Hackers News.

The attacks have been linked to the threat group ShinyHunters, which has reportedly targeted more than 100 organizations, with a significant concentration in the education sector. Researchers observed exploitation activity before Oracle publicly released its security advisory, classifying the vulnerability as a true zero-day.

Because Oracle PeopleSoft is widely used for managing human resources, payroll, finance, and other business-critical functions, successful exploitation could expose highly sensitive organizational data and provide attackers with deep access into enterprise environments.

Technical Breakdown of the Attack

The vulnerability resides within Oracle PeopleSoft PeopleTools, specifically affecting components exposed to the internet. Security researchers indicate that attackers can exploit the flaw without valid credentials, enabling remote execution of arbitrary commands on affected servers. The vulnerability carries a critical severity rating and may lead to full system compromise if left unmitigated.

Researchers also reported that threat actors leveraged the flaw against Environment Management Hub (PSEMHUB) endpoints. Following successful exploitation, attackers can deploy malicious tools, execute administrative commands, and establish persistent access within the targeted environment.

The Attack Chain Can Involve :

• Reconnaissance of internet-facing PeopleSoft servers.
• Identification of vulnerable PeopleTools instances.
• Exploitation of CVE-2026-35273 without authentication.
• Remote code execution on the application server.
• Deployment of web shells or remote management tools.

Multiple Other Methods Threat Actors May Use

While the zero-day vulnerability serves as the initial access vector, attackers frequently combine additional techniques to strengthen their foothold and increase operational success.

• Web shell deployment
• Credential theft
• Authentication bypass attacks
• Exploitation of legacy vulnerabilities

Modern threat actors rarely rely on a single attack technique. Instead, they combine multiple methods to gain deeper access, maintain persistence, evade security monitoring, and ultimately achieve objectives such as data theft, extortion, or ransomware deployment.

Why Enterprise Applications Remain a High-Value Target

Enterprise platforms such as Oracle PeopleSoft store some of an organization’s most valuable information, including employee records, financial data, payroll details, and operational information. Because these systems often integrate with multiple business applications, a single compromise can provide attackers with extensive visibility across the enterprise.

Threat actors increasingly target business-critical applications because successful exploitation can deliver immediate access to large volumes of sensitive data. In many environments, these platforms are internet-facing and may not receive the same level of security monitoring as endpoints, making them attractive targets for advanced threat groups.

Security Experts Recommend That Organizations

• Apply Oracle Mitigations Immediately
• Audit Internet-Facing PeopleSoft Systems
• Strengthen Access Controls
• Conduct Threat Hunting Activities

The active exploitation of CVE-2026-35273 demonstrates how rapidly threat actors can weaponize critical enterprise software vulnerabilities. With ShinyHunters reportedly targeting organizations through Oracle PeopleSoft environments, security teams should prioritize mitigation efforts, strengthen monitoring capabilities, and review exposure of internet-facing enterprise applications to reduce the risk of compromise.

The post Critical Oracle PeopleSoft Zero-Day RCE Vulnerability Actively Exploited by ShinyHunters appeared first on First Hackers News.

Researchers from Mysk reported that WhatsApp uses a shared container linked to Meta applications, identified as group.com.facebook.family. On Apple devices, app group containers allow applications from the same developer to share data and resources.

Because Facebook, Instagram, and WhatsApp belong to the same ecosystem, the shared architecture could introduce privacy and security concerns if exploited alongside operating system vulnerabilities.

Shared Containers Raise Privacy Concerns

The researchers found that WhatsApp chat databases stored inside these containers are not encrypted at rest. This means the data may remain readable if attackers gain access to the device or exploit weaknesses in the operating system.

According to the report, the following risks were identified:

• Chat histories may be stored in plaintext
• Other Meta-owned apps could theoretically access shared data
• Users receive no alerts when such access occurs
• The issue affects both macOS and iOS environments

Researchers also demonstrated that WhatsApp chat histories could be extracted from iPhone backups, where the same unencrypted storage structure was observed.

The findings highlight an important distinction in security design. While WhatsApp uses end-to-end encryption to protect messages during transmission, that protection does not automatically secure data stored locally on the device.

macOS Vulnerability Increases Exposure Risk

The risk becomes more serious when combined with a recently disclosed macOS vulnerability tracked as CVE-2026-28910. The flaw affected Apple’s Archive Utility tool and reportedly allowed attackers to bypass App Sandbox protections.

By abusing this vulnerability, attackers could potentially:

• Access protected application containers
• Extract sensitive information from apps
• Bypass Apple’s Transparency, Consent, and Control protections
• Access chat histories from applications like WhatsApp

Researchers presented a proof-of-concept demonstration showing how the vulnerability could be combined with WhatsApp’s storage behavior to retrieve chat data.

Security Debate Around the Findings

Not all experts agree on the severity of the issue. WABetaInfo stated that although the databases may not be encrypted locally, Apple’s sandboxing system still provides strong isolation between applications.

From this perspective, attackers would still require elevated system privileges or a separate operating system exploit to access the stored data.

However, researchers at Mysk argue that shared app group permissions between Meta applications reduce isolation boundaries and increase the potential attack surface.

The discussion highlights broader concerns about local data protection in modern mobile ecosystems, especially when multiple applications share common storage environments.

Recommendations for Users

Security experts recommend several steps to reduce potential exposure risks:

• Enable encrypted Finder or iTunes backups
• Keep macOS and iOS updated with the latest security patches
• Use strong device passcodes and device encryption
• Limit unnecessary applications from the same developer ecosystem
• Regularly review application permissions and backup settings

At the time of reporting, there were no confirmed cases of widespread exploitation linked to the findings. However, the research highlights the importance of protecting sensitive data not only during transmission but also while stored on devices.

The post WhatsApp Chat Data Found Stored Without Encryption appeared first on First Hackers News.

All three vulnerabilities carry a CVSS score of 7.5, indicating a high impact on data confidentiality. The issues can be exploited remotely with low complexity and do not require prior privileges or user interaction.

As AI assistants become tightly integrated into enterprise environments, these types of vulnerabilities increase the risk of unintended data exposure across emails, documents, and internal communications.

Technical Breakdown of the Vulnerabilities

The vulnerabilities originate from improper input and output handling within the AI processing pipeline. Attackers can exploit these weaknesses using prompt injection techniques, where specially crafted inputs manipulate the model’s behavior.

The identified vulnerabilities include:

• CVE-2026-26129 – Improper neutralization of special elements (CWE-138), allowing manipulation of how Copilot parses structured input
• CVE-2026-26164 – Injection vulnerability (CWE-74) affecting downstream components, potentially causing unintended data disclosure
• CVE-2026-33111 – Command injection flaw (CWE-77) in Copilot Chat within Microsoft Edge, enabling execution of unauthorized commands

These vulnerabilities primarily impact confidentiality, with no direct effect on system integrity or availability.

Enterprise Risk and Attack Impact

Because Microsoft 365 Copilot has deep access to enterprise data sources such as emails, Teams conversations, Word documents, and SharePoint files, exploitation could act as a silent data exfiltration channel.

By submitting carefully crafted prompts, an attacker could:

• Extract sensitive financial or operational data
• Access internal communications and documents
• Retrieve personally identifiable employee information

This type of attack leverages the AI model’s context awareness, making it difficult to detect through traditional security controls.

The vulnerabilities have been addressed by Microsoft at the service level. Since Copilot operates as a cloud-managed platform, security patches and input validation improvements were deployed centrally without requiring user action.

Organizations using Microsoft 365 Copilot and Copilot Chat in Edge are automatically protected, highlighting the advantage of centralized patch management in cloud-based AI services.

The post Microsoft 365 Copilot Bug Risks Data Exposure appeared first on First Hackers News.

Cases have been reported across the United Kingdom, India, Hong Kong, and Brazil, including a major incident in Hong Kong where a victim lost HK$5.5 million (US$700,000). The scam shows how easily trusted communication apps can be turned into attack vectors when social engineering is combined with direct access to a user’s screen.

This operation relies entirely on manipulation rather than advanced malware. Attackers make unsolicited WhatsApp video calls while pretending to be bank officials, Meta support staff, or even distressed family members, convincing users to share their screen and unknowingly expose critical data.

How Attackers Create Credibility and Urgency

Attackers use several tactics to appear credible. They often spoof local phone numbers and keep their video feed blurred or disabled to avoid revealing their identity.

To pressure the victim, they create a sense of urgency by claiming suspicious account activity, unauthorized credit card charges, or pending verification issues that require immediate action.

According to ESET security researchers, this scam is a highly effective form of remote access fraud because it combines three powerful elements: the trust created by impersonating an authority figure, the urgency generated through false threats, and the control gained through screen-sharing or remote access tools. Together, these factors give criminals near-complete visibility into a victim’s smartphone.

Once a user begins sharing their screen, the attacker’s access becomes extensive. They can see passwords, two-factor authentication codes, one-time passwords, and banking apps in real time. They may capture screenshots, direct victims to open financial apps, or persuade them to approve unauthorized transfers while pretending to “resolve” an issue.

In many cases, attackers escalate the scam by convincing users to install remote access apps like AnyDesk or TeamViewer, granting full control over the device. Some victims also unknowingly install malware such as keyloggers, which silently record sensitive information for later misuse.

From a technical standpoint, the risk is severe. If attackers gain access to incoming messages and WhatsApp verification codes through screen-sharing, they can immediately take over the victim’s WhatsApp account. With full account access, they can view conversations, financial information, and contacts.

Criminals then use the hijacked account to steal money, take over social media profiles, and impersonate the victim to target friends and family, creating a chain reaction of fraud.

Preventing Screen-Sharing Fraud

Protecting against this threat relies mostly on user awareness and careful behavior. Screen sharing should never be granted to unknown or unsolicited callers, and any urgent claims should be verified directly with official sources.

Enabling WhatsApp’s two-step verification (Settings → Account → Two-step verification) adds an essential layer of protection, ensuring attackers cannot access the account even if they obtain verification codes.

This scam underscores a core truth in cybersecurity: social engineering remains one of the most powerful tools for criminals. Staying skeptical, alert, and cautious is the strongest defense against these attacks.

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

The post WhatsApp Screen-Sharing Scam Exposes Users to Data Theft appeared first on First Hackers News.

The vulnerability, CVE-2025-64446, allows attackers to run admin-level commands without logging in. This means they can take complete control of the system. The issue has a CVSS score of 9.1, making it very serious.

The problem comes from a path traversal bug in the FortiWeb GUI. With a specially crafted HTTP or HTTPS request, attackers can bypass security checks and run commands with full privileges. This can result in:

• Creating unauthorized admin accounts
• Stealing data
• Total system compromise

Fortinet has confirmed active attacks, so patching immediately is strongly recommended.

Affected Versions:
FortiWeb 8.0, 7.6, 7.4, 7.2, and 7.0

Recommended Updated Versions:
8.0.2, 7.6.5, 7.4.10, 7.2.12, and 7.0.12 or higher

If you cannot apply the update right away, Fortinet suggests disabling HTTP/HTTPS access to the management interface on all internet-facing interfaces. This can help reduce risk but should only be used as a temporary solution.

After updating, admins should check system logs and look for any unknown or suspicious admin accounts to ensure their device has not already been compromised.

The post Active Exploits Target Critical FortiWeb WAF Flaw appeared first on First Hackers News.

The flaws, discovered by Check Point Research, enabled threat actors to alter conversations, spoof sender identities, and exploit notifications to make malicious messages appear as if they came from trusted sources, including senior executives.

According to Check Point’s report, the issues were responsibly disclosed to Microsoft in March 2024. Microsoft addressed some of them in August 2024 under CVE-2024-38197, with additional security patches released in September 2024 and October 2025.

How the Microsoft Teams Vulnerabilities Worked

Researchers found that the vulnerabilities made it possible to:

• Edit message content without showing the “Edited” label.
• Change sender identity in both chat and notifications.
• Modify display names in private chats, calls, and call notifications.

These flaws could allow attackers to trick employees into clicking malicious links, sharing confidential data, or granting unauthorized access, posing significant risks to both internal and external communications.

Microsoft’s Response

Microsoft categorized CVE-2024-38197 as a medium-severity spoofing vulnerability (CVSS score: 6.5) affecting Teams for iOS. The flaw could enable attackers to modify a sender’s name and conduct social engineering attacks to extract sensitive information.

In a recent security advisory, Microsoft emphasized that Microsoft Teams’ widespread adoption and extensive collaboration features make it a prime target for cybercriminals and state-sponsored actors. Attackers have increasingly exploited Teams’ chat, calls, and screen-sharing functions as part of broader phishing and impersonation campaigns.

Industry Insight

Oded Vanunu, Head of Product Vulnerability Research at Check Point, highlighted the growing risk of trust-based attacks:

“These vulnerabilities hit at the heart of digital trust. Collaboration platforms like Teams are now as critical as email — and just as exposed,” said Vanunu.
“Threat actors don’t need to break in anymore; they just need to bend trust. Seeing isn’t believing anymore — verification is.”

Protecting Against Teams Exploits

Organizations are advised to:

• Apply the latest Microsoft Teams updates and patches immediately.
• Educate employees about impersonation and phishing risks.
• Implement advanced threat protection tools and zero-trust verification for collaboration platforms.

As the reliance on Microsoft Teams continues to grow across enterprises, these findings underscore the importance of vigilance, patch management, and digital trust protection in modern communication environments.

The post Microsoft Teams Vulnerabilities Expose Users to Impersonation and Social Engineering Attacks appeared first on First Hackers News.

The attack targets the Atlas omnibox, which serves as both an address bar and a search bar. It was revealed that the omnibox can mistakenly interpret a crafted string as a user command rather than a web address. Because of this, malicious inputs disguised as URLs can be used to manipulate the browser’s AI system.

According to the report, a fake URL beginning with “https://my-wesite.com” can be followed by hidden natural language instructions. When entered, Atlas fails to validate it as a proper URL and treats it as a prompt. This causes the AI to execute the embedded command, redirecting users to an attacker-controlled website or performing unauthorized actions.

Experts warned that this flaw could lead to phishing attacks, data theft, and remote exploitation. In a practical example, attackers could embed such fake links behind “Copy link” buttons, luring users to malicious pages or triggering harmful actions like deleting files from connected accounts such as Google Drive.

Security researcher Martí Jordà noted that omnibox prompts are treated as trusted input, meaning they may bypass several security checks applied to regular website content. This lack of isolation between user intent and page content created an opening for attackers to abuse the AI assistant’s trust model.

Alongside this finding, SquareX Labs disclosed another related threat called AI Sidebar Spoofing. The technique allows attackers to overlay a fake AI sidebar inside browsers such as Atlas and Perplexity Comet using malicious extensions. When users type prompts into the spoofed sidebar, the injected code can exfiltrate data, install malware, or redirect users to harmful websites.

Researchers described prompt injection as a growing security challenge for AI browsers, including OpenAI Atlas, Perplexity Comet, and Opera Neon. These attacks can be hidden inside web pages using white text, HTML comments, or even faint instructions embedded in images, which are read by AI systems through optical character recognition.

OpenAI’s Chief Information Security Officer, Dane Stuckey, acknowledged the issue in a public statement. He confirmed that the company has conducted extensive red-teaming, added safety guardrails, and trained models to ignore malicious instructions. However, he also admitted that prompt injection remains an unresolved frontier problem in AI security.

Perplexity and Brave have also confirmed that their own browsers face similar risks. Both companies have adopted multi-layered protection systems, including real-time detection, reinforcement filters, and transparency controls to defend against prompt-based attacks.

Experts agree that prompt injection represents a new phase in cybersecurity. The blending of artificial intelligence and web browsing has created new opportunities for productivity—but also new risks that demand constant monitoring and innovation.

The post OpenAI Atlas Browser Vulnerability Exposed to Prompt Injection Attack appeared first on First Hackers News.