According to recent security research, while the overall number of blocked Android malware attacks declined during the second quarter of 2026, banking malware remains one of the most active mobile threats. Rather than disappearing, attackers are changing how their malware is packaged and deployed.

A Shift Toward Dropper-Based Attacks

A dropper is an application that appears harmless but is designed to download or activate malware after installation.

This approach allows attackers to hide the real banking Trojan during the initial app review process. Once the application is installed on a victim’s device, it can retrieve additional malicious components and begin targeting banking credentials.

By separating the delivery mechanism from the actual malware, cybercriminals can update or replace their payloads without creating entirely new malicious applications.

Malicious Apps Disguised as Legitimate Software

Researchers observed attackers disguising malware as legitimate Android applications, including utility and document reader apps.

In one campaign, a PDF reader displayed what appeared to be a routine software update notification. Instead of installing an update, the application downloaded banking malware onto the victim’s device.

These fake update prompts make malicious activity appear normal, increasing the likelihood that users will unknowingly install the malware.

Smarter Delivery Techniques

Modern Android droppers are becoming more selective in how they deliver malware.

Some applications first collect information about where they were downloaded and send that data to a command-and-control (C2) server. The server decides whether to deliver the malicious payload based on the installation source.

This selective delivery helps attackers avoid security researchers, automated analysis tools, and app store review systems while targeting real users.

Banking Malware Continues to Evolve

Security researchers also observed continued activity from well-known Android banking malware families, including Mamont and Creduz.

New variants are being released regularly, suggesting that malware operators are continuously testing new delivery techniques, improving evasion methods, and developing updated versions to avoid detection.

Why This Matters

The growing use of droppers shows that mobile threats are becoming more sophisticated. A reduction in traditional banking Trojan detections does not necessarily indicate a lower risk—it may simply reflect changes in how malware is delivered.

As attackers continue refining their techniques, users and organizations should remain cautious of applications that request unexpected updates or unnecessary permissions.

How to Stay Protected

To reduce the risk of Android banking malware:

• Install apps only from trusted sources.
• Keep Google Play Protect enabled.
• Avoid downloading apps from unofficial websites.
• Be cautious of unexpected in-app update requests.
• Review requested permissions before installing applications.
• Keep Android devices and applications updated.
• Use a reputable mobile security solution.

Conclusion

Android banking malware operators are shifting away from traditional delivery methods and increasingly relying on dropper applications to bypass security controls. As these techniques become more advanced, mobile users and organizations should strengthen their security practices, verify application sources, and remain alert to suspicious app behavior to reduce the risk of financial compromise.

The post Android Banking Malware Adopts New Evasion Techniques appeared first on First Hackers News.

The vulnerability allows remote attackers to execute commands on vulnerable devices without requiring authentication. Since LoadMaster appliances are commonly deployed at the network edge to manage application traffic, a successful attack could provide threat actors with an entry point into an organization’s infrastructure.

What Is the Vulnerability?

CVE-2026-8037 is a command injection vulnerability affecting the API component of Progress LoadMaster and related Application Delivery Controller (ADC) products.

The flaw occurs because certain user-supplied input is not properly validated before being processed by the operating system. As a result, attackers can craft malicious requests that force the appliance to execute unauthorized system commands.

Most importantly, the attack does not require valid login credentials, making internet-facing devices particularly vulnerable.

Why the Risk Is So High

Security researchers have assigned the vulnerability a CVSS score of 9.6, reflecting its critical severity.

Because LoadMaster appliances often sit at the perimeter of enterprise networks, compromising one could allow attackers to:

• Execute remote commands.
• Gain an initial foothold inside the network.
• Steal credentials.
• Move laterally to other systems.
• Deploy additional malware or backdoors.
• Modify device configurations.

Public proof-of-concept (PoC) exploit code is also available, making it easier for attackers to scan for and target vulnerable systems.

Active Exploitation Confirmed

According to CISA, the vulnerability is no longer a theoretical threat.

Evidence of active exploitation prompted the agency to add CVE-2026-8037 to its KEV catalog and advise affected organizations to apply vendor updates immediately.

Although there are currently no reports linking the flaw to ransomware campaigns, attackers are actively attempting to exploit vulnerable devices exposed to the internet.

Recommended Security Measures

Organizations using Progress LoadMaster should act immediately by:

• Identifying all affected LoadMaster appliances.
• Applying the latest security updates provided by Progress.
• Restricting management and API access to trusted networks or VPNs.
• Reviewing logs for unusual API requests and command execution attempts.
• Investigating unexpected configuration changes or unauthorized administrative activity.
• Conducting a full security assessment after patching to ensure attackers have not already established persistence.

The inclusion of CVE-2026-8037 in CISA’s Known Exploited Vulnerabilities catalog underscores the seriousness of this security issue. Since the vulnerability can be exploited without authentication and public exploit code is already available, organizations should prioritize patching affected LoadMaster systems and closely monitor their environments for signs of compromise.

Taking prompt action can significantly reduce the risk of attackers gaining access to critical network infrastructure.

The post CISA Warns of Active LoadMaster Attacks appeared first on First Hackers News.

Because the vulnerable code has been part of WordPress since version 4.7, millions of websites using one of the world’s most popular content management systems were potentially exposed before security updates were released.

How the Vulnerability Works

The attack begins on WordPress’s standard login page (wp-login.php).

When someone attempts to log in with an invalid username, WordPress displays an error message. Researchers discovered that specially crafted input can bypass the platform’s HTML filtering due to differences in how PHP and WordPress process certain characters.

This allows malicious HTML elements to appear within the login page even though no authentication is required.

Although these injected elements do not contain JavaScript themselves, they can interact with existing WordPress scripts already loaded in the browser.

From XSS to Code Execution

The injected content takes advantage of WordPress’s built-in JavaScript files, which automatically process specific page elements.

By manipulating these interactions, attackers can trigger unauthorized browser requests and eventually execute JavaScript within the WordPress website.

On its own, this reflected Cross-Site Scripting (XSS) vulnerability is already a serious security concern. However, researchers demonstrated that the attack can become far more dangerous when combined with social engineering.

If a logged-in administrator visits a specially crafted website and interacts with it, an attacker may abuse the administrator’s active session to perform privileged WordPress actions without their knowledge.

Potential Impact

Successful exploitation could allow attackers to:

• Execute malicious JavaScript.
• Create new WordPress application passwords.
• Publish unauthorized content.
• Upload malicious plugins.
• Deploy PHP web shells.
• Achieve remote code execution on the server.

Since these actions are performed using legitimate administrator privileges, detecting the attack can be more challenging.

Who Is Affected?

The vulnerability affects WordPress Core versions dating back to 4.7, making it one of the broadest WordPress security issues disclosed in recent years.

Given WordPress powers a significant portion of websites worldwide, organizations running outdated installations should review their environments immediately.

Security Update Available

The WordPress security team addressed the issue in WordPress 7.0.3 and also released security updates for older supported branches.

The vulnerability was assigned a CVSS score of 8.9 (High) due to its potential impact. While the full attack chain requires administrator interaction, the possibility of remote code execution makes prompt patching essential.

At the time of disclosure, researchers reported no confirmed evidence of active exploitation in real-world attacks.

How to Protect Your WordPress Site

Website owners and administrators should take the following steps:

• Update WordPress to the latest supported version.
• Apply all available security patches.
• Restrict administrator access to trusted users.
• Review installed plugins and themes regularly.
• Enable multi-factor authentication (MFA) for administrator accounts.
• Monitor login activity and unexpected administrative actions.
• Use a Web Application Firewall (WAF) to help block suspicious requests.

Conclusion

The XSS2Shell vulnerability demonstrates how a seemingly minor login page weakness can evolve into a much more serious attack when combined with browser behavior and administrator interaction.

Although exploitation requires specific conditions, the potential for remote code execution makes this vulnerability a high priority for WordPress administrators. Keeping WordPress updated and following security best practices remain the most effective ways to reduce the risk of compromise.

The post Critical WordPress Flaw Enables Remote Code Execution appeared first on First Hackers News.

Rather than breaking Windows Hello encryption, the technique takes advantage of an already authenticated Windows session. If an attacker gains access to a logged-in device, they may be able to leverage the victim’s existing Windows Hello credentials to request authentication tokens and potentially establish long-term access to Microsoft Entra resources.

The research highlights how attackers can abuse trusted authentication mechanisms once an endpoint has already been compromised.

How the Attack Works

Windows Hello for Business replaces passwords with cryptographic keys that are securely stored on the user’s device, typically inside the Trusted Platform Module (TPM). These keys are designed to remain protected and cannot normally be exported from the device.

However, the research demonstrates that an application running with standard user privileges inside an active Windows session can request cryptographic operations from the Windows Hello key without asking the user to re-enter their PIN or biometric authentication.

Instead of stealing the private key itself, the attacker simply instructs Windows to use it on their behalf. As long as the user remains logged in, Windows considers the authentication request valid.

This effectively allows attackers to “borrow” the trusted Windows Hello credentials without directly compromising them.

Authentication Without Traditional Credentials

Researchers showed that the borrowed Windows Hello key can be used during Microsoft’s WebAuthn authentication process.

Since the authentication challenge is not permanently tied to a specific device or session, attackers can generate the request from their own system while having the victim’s compromised device perform the required cryptographic signing.

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

Once the challenge is successfully signed, Microsoft Entra treats the authentication as legitimate and issues cloud authentication tokens.

Unlike earlier attack techniques, this approach removes the need for attackers to control another Microsoft Entra-registered device, making exploitation significantly easier.

Potential Impact

Successful exploitation could provide attackers with access to Microsoft Entra cloud resources while using legitimate authentication mechanisms.

Depending on the organization’s security configuration, attackers may be able to:

• Authenticate to Microsoft Entra services.
• Obtain cloud authentication tokens.
• Register attacker-controlled devices.
• Add new authentication methods.
• Maintain persistent access to cloud identities.
• Expand access across enterprise environments.

Because Windows Hello for Business satisfies multi-factor authentication requirements, attackers may also bypass additional protections designed to secure identity management functions.

Why Organizations Should Pay Attention

The research demonstrates that passwordless authentication is only as secure as the endpoint itself.

Even though Windows Hello protects credentials from theft, an attacker who compromises an active Windows session may still abuse trusted authentication processes without ever knowing the user’s password or PIN.

This reinforces the importance of endpoint security alongside identity protection.

Organizations should not rely solely on passwordless authentication but should also focus on preventing attackers from gaining access to active user sessions.

Detection and Mitigation

Security teams should monitor Microsoft Entra sign-in activity for unusual Windows Hello authentication events, particularly those that do not contain an associated device ID.

Administrators should also investigate unexpected device registrations, monitor changes to authentication methods, strengthen endpoint detection and response capabilities, and regularly review Conditional Access policies to ensure only trusted devices can register new authentication factors.

Monitoring active user sessions and detecting suspicious endpoint activity remain critical for preventing attackers from abusing trusted authentication mechanisms.

Conclusion

Mollema’s research demonstrates that compromising an active Windows session can have serious consequences, even in environments that have adopted passwordless authentication.

While the technique does not break Windows Hello’s cryptographic protections, it shows how trusted authentication workflows can be abused after an endpoint has been compromised.

Organizations using Windows Hello for Business and Microsoft Entra should prioritize endpoint protection, continuous monitoring, and identity security controls to reduce the risk of attackers turning temporary access into persistent cloud compromise.

The post Windows Hello Key Flaw Opens Door to Entra ID Access appeared first on First Hackers News.

The vulnerability affects the Stream Control Transmission Protocol (SCTP) component of the Linux kernel. Surprisingly, the underlying flaw has existed since Linux 2.6.25, released in 2007, meaning it remained undiscovered for nearly 18 years.

How the Vulnerability Works

The issue is caused by a use-after-free memory bug in SCTP’s Dynamic Address Reconfiguration (ASCONF) feature.

By sending specially crafted SCTP packets in a specific sequence, an attacker can trick the kernel into freeing an object while it is still being referenced. When the kernel later tries to access that memory, it creates a use-after-free condition that can be exploited.

This flaw allows attackers to manipulate kernel memory and eventually execute privileged operations.

Privilege Escalation to Root

Researchers from TencentOS Security Team developed a working exploit that successfully turns the vulnerability into a full privilege-escalation attack.

Their exploit leaks kernel memory addresses, bypasses security protections such as Kernel Address Space Layout Randomization (KASLR), and creates fake kernel objects to obtain root privileges.

Notably, the attack does not rely on shellcode or traditional Return-Oriented Programming (ROP) techniques, making it more difficult for some security solutions to detect.

Container Escape Demonstrated

Researchers also proved that the vulnerability can be used to escape Linux containers.

Instead of requiring elevated system privileges, the exploit uses standard SCTP socket options available within containers. Once exploited, attackers can break out of the container environment and execute code on the underlying host.

This makes the vulnerability particularly concerning for organizations running containerized workloads or multi-tenant environments.

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

Affected Systems

The exploit was successfully tested on several Linux distributions, including:

• Ubuntu 24.04
• Debian 13
• Rocky Linux 9
• Multiple Linux kernel versions from 5.14 through recent 7.x release candidates

The researchers achieved root access on every tested environment.

Severity and Impact

CVE-2026-64564 has received a CVSS v4.0 score of 8.5 (High).

If exploited successfully, attackers could:

• Gain full root privileges
• Escape container environments
• Compromise the underlying host
• Access sensitive data
• Modify system configurations
• Completely take control of affected Linux systems

Security Updates Available

The Linux kernel maintainers have released patches to address the vulnerability.

Fixes are available in the following kernel versions:

• 6.6.148
• 6.12.101
• 6.18.42
• 7.1.6

The vulnerability was officially disclosed on August 4, 2026, following responsible disclosure to the Linux kernel security team.

How Organizations Can Protect Their Systems

Organizations running Linux servers should prioritize applying the latest kernel updates, especially if SCTP is enabled.

Security teams should also:

• Apply the latest patched kernel versions.
• Monitor systems for unusual privilege-escalation attempts.
• Limit local user access wherever possible.
• Regularly review container security configurations.
• Monitor kernel and authentication logs for suspicious activity.

Conclusion

The discovery of SCTPhantom (CVE-2026-64564) highlights how critical vulnerabilities can remain hidden in widely used software for many years. With the ability to gain root access and escape containers, this flaw presents a significant security risk for Linux environments.

Organizations should update affected systems as soon as possible and strengthen monitoring to reduce the risk of exploitation.

The post Critical Linux Kernel Flaw Grants Root Access appeared first on First Hackers News.

Understanding the warning signs of a phishing email is one of the most effective ways to reduce cyber risk. Below are ten common indicators that every individual and organization should recognize.

1. Suspicious Sender Address

The sender’s email address is one of the first things to verify. Cybercriminals often register domains that closely resemble legitimate organizations by changing a single character or using uncommon domain extensions.

Always verify the sender before opening attachments or clicking links.

2. Urgent or Fear-Inducing Messages

Phishing emails frequently create a false sense of urgency to pressure recipients into acting quickly.

Examples include:

• Your account has been suspended.
• Immediate action required.
• Your payment has failed.
• Verify your identity now.

Legitimate organizations rarely demand immediate action without providing alternative ways to verify the request.

3. Suspicious Links

Before clicking any hyperlink, hover your cursor over it to view its actual destination.

If the displayed URL differs from the official company website or contains unusual characters, it should be treated as suspicious.

When in doubt, access the website directly through your browser instead of using the email link.

4. Requests for Sensitive Information

Legitimate businesses do not typically request passwords, banking information, one-time passcodes, or confidential personal data through email.

Any message asking for sensitive information should be independently verified before responding.

5. Poor Grammar and Unprofessional Formatting

Many phishing emails contain spelling mistakes, grammatical errors, inconsistent fonts, or unusual formatting.

Although modern phishing campaigns have become more convincing, poor language quality remains a common warning sign.

6. Unexpected Attachments

Opening unexpected attachments can result in malware infections, ransomware attacks, or credential theft.

Be especially cautious with file types such as:

• ZIP
• EXE
• ISO
• JS
• DOCM
• HTML

If you were not expecting the attachment, confirm its legitimacy with the sender before opening it.

7. Generic Greetings

Instead of addressing recipients by name, phishing emails often use generic greetings such as:

• Dear Customer
• Dear User
• Valued Customer
• Dear Member

Many legitimate organizations personalize important communications using your registered name.

8. Offers That Seem Too Good to Be True

Cybercriminals frequently lure victims with attractive offers such as:

• Free gift cards
• Lottery winnings
• Large discounts
• Tax refunds
• Prize claims

If an offer appears unusually generous or unexpected, verify it through the organization’s official website.

9. Fake Branding and Logos

Attackers often copy company logos, email templates, and branding to make phishing emails appear authentic.

A professional-looking email does not guarantee legitimacy. Always verify the sender’s address and carefully inspect links before interacting with the message.

10. Unexpected Login or Verification Requests

Many phishing campaigns direct victims to fake login pages designed to steal usernames and passwords.

If you receive an unexpected request to sign in or verify your account, avoid using the link provided in the email. Instead, manually enter the official website address into your browser.

Best Practices to Protect Against Phishing

Organizations and individuals can significantly reduce phishing risks by following these security practices:

• Enable Multi-Factor Authentication (MFA).
• Use strong and unique passwords for every account.
• Keep operating systems and applications up to date.
• Verify unexpected requests before responding.
• Avoid opening unknown attachments or clicking suspicious links.
• Use email security filtering solutions.
• Conduct regular cybersecurity awareness training.
• Report suspected phishing emails to your IT or security team.

Conclusion

Phishing attacks continue to evolve, becoming more sophisticated and difficult to detect. However, most successful attacks still rely on users overlooking common warning signs.

By carefully verifying email senders, avoiding suspicious links and attachments, and following cybersecurity best practices, individuals and organizations can greatly reduce their exposure to phishing attacks and protect sensitive information from cybercriminals.

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

The post Top 10 Phishing Email Red Flags You Should Never Ignore 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.

The exploit chain was originally discovered by Google Threat Intelligence Group, iVerify, and Lookout. After the complete JavaScript-based toolkit was leaked on GitHub, several unrelated attackers began reusing the same code instead of creating their own versions.

Researchers found that at least seven threat groups are now operating DarkSword infrastructure. The attackers use identical exploit files, matching code hashes, and even the same Russian-language comments found in the leaked source code, confirming they are all relying on the leaked toolkit.

One of the newest operators appears to be a Chinese-speaking threat actor managing more than 100 malicious websites across Hong Kong, Japan, the United States, and several European countries. Earlier campaigns mainly used fake AWS login pages, but researchers have now identified Apple ID phishing pages hosted on the same servers that deliver the DarkSword exploit.

How the DarkSword Campaign Works

Researchers tracked the attackers by comparing file hashes and exploit pages instead of relying only on domains or IP addresses, which change frequently. This method helped identify additional DarkSword infrastructure that traditional detection methods had missed.

According to Censys, the campaign continues to grow as attackers regularly move their infrastructure to new hosting providers and domains.

Researchers identified several key characteristics of the operation:

• Multiple DarkSword administration panels hosted in Hong Kong, Japan, and the United States.
• Chinese-language login panels running on ports such as 3000, 8443, and 8888.
• Fake Apple ID login pages hosted on the same servers as the exploit chain.
• Identical exploit files and malware modules reused across different operators.
• Infrastructure spread across multiple hosting providers to avoid easy detection.

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

What Happens After an iPhone Is Compromised?

One of the most dangerous changes in this campaign is the combination of Apple ID phishing pages with DarkSword’s exploit delivery. Victims believe they are signing in to a legitimate Apple account, while hidden exploit code is loaded in the background through Safari.

Security researchers say DarkSword chains multiple iOS vulnerabilities affecting WebKit, the GPU, the dynamic linker, and the kernel to gain deep access to vulnerable devices.

After a successful compromise, the malware can:

• Steal Apple Keychain passwords and saved credentials.
• Extract iCloud account information.
• Collect saved Wi-Fi passwords.
• Download files stored on the device.
• Send stolen data to attacker-controlled command-and-control (C2) servers.

Researchers also found that most DarkSword deployments use identical malware files, showing attackers are directly reusing the leaked toolkit instead of developing new versions. Although many servers are hosted in Hong Kong, the infrastructure is distributed across several internet providers, making IP-based blocking less effective.

Additional evidence, including Chinese-language control panels, references to an “Asia-Pacific Group,” and a Telegram contact, suggests the latest infrastructure is operated by a Chinese-speaking threat actor. However, researchers say there is not yet enough evidence to confidently attribute the campaign to a specific group.

The post Threat Analysis: DarkSword Framework Leverages iOS Exploits for Apple ID Harvesting appeared first on First Hackers News.

According to security researchers at AISLE, the flaw could have allowed attackers to compromise a developer’s system simply by convincing them to click a malicious link embedded in a Git commit message.

The issue has now been fixed across all affected platforms, but it highlights the growing security risks facing modern AI-powered development tools.

How the Attack Worked

The vulnerability relied on a malicious link hidden inside a Git commit message.

If a developer clicked the link while viewing the commit inside one of the affected editors, arbitrary code could run automatically with the same permissions as the developer.

The attack required only a single click and did not display any warning, confirmation message, or security prompt, making the compromise difficult to notice.

What Attackers Could Do

Successful exploitation could have given attackers extensive control over a developer’s machine.

Potential impacts included:

• Stealing API keys and other sensitive credentials.
• Installing malware or keyloggers.
• Accessing, modifying, or deleting local files.
• Maintaining persistent access even after the editor was closed.

Because the malicious activity could remain hidden, developers might not realize their systems had been compromised.

Vulnerability Found Across Multiple Editors

AISLE first discovered the flaw in Microsoft VS Code during security testing in late 2025.

Since Cursor is built on the VS Code codebase, it inherited the same vulnerability. Later, researchers identified the identical issue in Google Antigravity, another AI-assisted coding environment based on the same architecture.

The discovery shows how a single vulnerability in a shared codebase can spread across multiple developer tools used by millions of people.

Vendors Released Security Fixes

After receiving responsible disclosure reports, all three vendors addressed the issue.

• Cursor released a security update shortly after notification.
• Google patched the vulnerability in Antigravity within days.
• Microsoft later released a fix for VS Code.

Current versions of all three editors are no longer affected.

Why This Matters

Many modern AI coding tools are developed using common open-source foundations such as VS Code. While this speeds up development and feature delivery, it also means a single security flaw can impact multiple products simultaneously.

This incident demonstrates the importance of continuous security testing and timely patch management, particularly for AI-powered development environments.

What Developers Should Do

Developers and organizations should take the following steps:

• Update VS Code, Cursor, or Google Antigravity to the latest version.
• Review recent Git activity for anything suspicious.
• Rotate API keys and credentials if older vulnerable versions were used.
• Monitor developer systems for unusual behavior or unauthorized access.

Keeping development tools fully updated and regularly reviewing credentials can help reduce the risk of future software supply chain attacks.

The post Critical Vulnerability Disclosed in VS Code, Cursor, and Google Antigravity 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.