2026-04-30 AI创业新闻

Cybersecurity researchers are sounding the alarm about a new supply chain attack campaign targeting SAP-related npm Packages with credential-stealing malware. According to reports from Aikido Security , SafeDep , Socket , StepSecurity , and Google-owned Wiz , the campaign – calling itself the mini Shai-Hulud – has affected the following packages associated with SAP’s JavaScript and cloud application development ecosystem - mbt@1.2.48 @cap-js/db-service@2.10.1 @cap-js/postgres@2.2.2 @cap-js/sqlite@2.2.2 “The affected versions introduced new installation-time behavior that was not previously part of these packages’ expected functionality,” Socket said. “The compromised releases added a preinstall script that acts as a runtime bootstrapper, downloading a platform-specific Bun ZIP from GitHub Releases, extracting it, and immediately executing the extracted Bun binary.” “The implementation also follows HTTP redirects without validating the destination and uses PowerShell with -ExecutionPolicy Bypass on Windows, increasing the risk for affected developer and CI/CD environments.” Wiz noted that the malicious packages match several features present in previous TeamPCP operations, indicating that the same threat actor is likely behind the latest campaign. The suspicious versions were published on April 29, 2026, between 09:55 UTC and 12:14 UTC.

The poisoned packages introduce a new package.json preinstall hook that runs a file named “setup.mjs,” which acts as a loader for the Bun JavaScript runtime to execute the credential stealer and propagation framework (“execution.js”). According to Aikido, the malware is designed to harvest local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud secrets from AWS, Azure, GCP, and Kubernetes. The stolen data is encrypted and exfiltrated to public GitHub repositories created on the victim’s own account with the description “A Mini Shai-Hulud has Appeared.” As of writing, there are more than 1,100 repositories with descriptions. In addition, the 11.6 MB payload comes with capabilities to self-propagate through developer and release workflows, specifically using the GitHub and npm tokens to inject a malicious GitHub Actions workflow into the victim’s repositories to steal repository secrets and publish poisoned versions of the npm packages to the registry.

However, the latest incident bears significant differences from prior Shai-Hulud waves - All exfiltrated data is encrypted with AES-256-GCM and encapsulates the key using RSA-4096 with a public key embedded in the payload, effectively making it decipherable only to the attacker. It exists on Russian-locale systems. The payload commits itself into every accessible GitHub repository by injecting a “.claude/settings.json” file that abuses Claude Code’s SessionStart hook and a “.vscode/tasks.json” file with “runOn”: “folderOpen” setting so that any attempt to open the infected repository in Microsoft Visual Studio Code (VS Code) or Claude Code causes the malware to be executed. “This is one of the first supply chain attacks to target AI coding agent configurations as a persistence and propagation vector,” StepSecurity said.

Further analysis into the root cause has revealed that the attackers compromised RoshniNaveenaS’s account for the three “@cap-js” packages, followed by pushing a modified workflow to a non-main branch and using the extracted npm OIDC token to publish the malicious packages without provenance. As for mbt, it’s suspected to involve the compromise of the “cloudmtabot” static npm token through an as-yet-undetermined channel. “The cds-dbs team migrated to npm OIDC trusted publishing in November 2025,” SafeDep said. “Under this setup, GitHub Actions can request a short-lived npm token without storing any long-lived secrets in the repository.

The attacker reproduced this exchange manually in a CI step and printed the resulting token.” “The critical configuration gap: npm’s OIDC trusted publisher configuration for @cap-js/sqlite trusted any workflow in cap-js/cds-dbs, not just the canonical release-please.yml on main. A branch push could exchange an OIDC token on behalf of the package if the workflow had id-token: write permission and the environment: npm reference.” In response to the incident, the maintainers of the packages have released new safe versions that supersede the compromised releases - sqlite: v2.4.0 , v2.3.0 postgres: v2.3.0 , v2.2.2 hana: v2.8.0 , v2.7.2 db-service: v2.10.1 mbt: v1.2.49 Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New Wave of DPRK Attacks Uses AI-Inserted npm Malware, Fake Firms, and RATs

Cybersecurity researchers have discovered malicious code in an npm package after a malicious package as a dependency to the project by Anthropic’s Claude Opus large language model (LLM). The package in question is “ @validate-sdk/v2 ,” which is listed on npm as a utility software development kit (SDK) for hashing, validation, encoding/decoding, and secure random generation. However, its real functionality is to plunder sensitive secrets from the compromised environment. The package, which shows signs of being vibe-coded using generative artificial intelligence (AI), was first uploaded to the repository in October 2025.

The malware campaign has been codenamed PromptMink by ReversingLabs, which linked the activity as part of a broader campaign mounted by the North Korean threat actor known as Famous Chollima (aka Shifty Corsair), which is behind the long-running Contagious Interview campaign and the fraudulent IT Worker scam . “The new malware campaign […] involves a tainted package that was introduced in a Feb. 28 commit to an autonomous trading agent,” ReversingLabs researcher Vladimir Pezo said in a report shared with The Hacker News. “The commit was co-authored by Anthropic’s Claude Opus large language model (LLM).

It allows attackers to access users’ crypto wallets and funds.” The package is listed as a dependency for an another npm package named “ @solana-launchpad/sdk ,” which, in turn, is used by a third package called “ openpaw-graveyard ,” which is described as an “autonomous AI agent” that creates a social on-chain identity on the Solana blockchain using the Tapestry Protocol , trades cryptocurrency via Bankr , as well as interacts with other agents on Moltbook . ReversingLabs said the AI agent-generated packages were added as a dependency in a commit made in February 2026, causing the agent package to execute malicious code and give attackers access via leaked credentials to the victim’s cryptocurrency wallets and funds. The attack adopts a phased approach, where the first-layer packages do not contain any malicious code, but import second-layer packages that actually embed the nefarious functionality. Should the second cluster be detected or removed from npm, they are swiftly replaced.

Some of the first-layer packages identified are listed below - @solana-launchpad/sdk @meme-sdk/trade @validate-ethereum-address/core @solmasterv3/solana-metadata-sdk @pumpfun-ipfs/sdk @solana-ipfs/sdk “They implement some functionality related to cryptocurrencies,” ReversingLabs explained. “And each package lists many dependencies, most of which are popular npm packages with download counts in the millions and billions, like axios, bn.js etc. However, a small number of the dependencies are malicious packages from the second layer.” The threat actors employ various techniques to help the rogue packages escape detection. These include creating a malicious version of the functions already present in the listed popular packages.Another technique uses typosquatting, where the names and descriptions mimic legitimate libraries.

The first package version published to npm as part of this campaign dates back to September 2025, when “@hash-validator/v2” was uploaded to the registry. The decision to split the cryptocurrency stealer into two parts – a benign bait that downloads the actual malware – may have helped it evade detection and help conceal the true scale of the attack. It’s worth noting that some aspects of the activity were documented by JFrog two months later, highlighting the threat actor’s use of transitive dependencies to execute malicious code on developer systems and siphon valuable data. In the intervening months, the campaign has undergone various transformations, even targeting the Python Package Index (PyPI) by pushing a malicious package (“scraper-npm”) with the same functionality in February 2026.

As recently as last month, threat actors have been observed establishing persistent remote access via SSH and using Rust-compiled payloads to exfiltrate entire projects containing source code and other intellectual property from compromised systems. Early versions of the malware were obfuscated JavaScript-based stealers that scan the current working directory recursively for .env or .json files and stage for exfiltration to a Vercel URL (“ipfs-url-validator.vercel.app”), a platform repeatedly abused by Famous Chollima in its campaigns. While subsequent iterations came embedded with PromptMink in the form of a Node.js single executable application (SEA), it also suffered from a notable disadvantage in that it caused the payload size to grow from a mere 5.1KB to around 85MB.This is said to have caused the threat actors to shift to using NAPI-RS to create pre-compiled Node.js add-ons in Rust. The evolution of the malware from a simple infostealer to a specialized multi-platform harvester targeting Windows, Linux, and macOS capable of dropping SSH backdoors and gathering entire projects demonstrates North Korean threat actors’ continued targeting of the open-source ecosystem to target developers in the Web3 space.

Famous Chollima is “leveraging AI-generated code and a layered package strategy to evade detection and more effectively deceive automated coding assistants than human developers,” ReversingLabs added. Contagious Trader Emerges The findings coincide with the discovery of a malicious npm package named “express-session-js” that’s believed to be linked to the Contagious Interview campaign, with the library acting as a conduit for a dropper that fetches a second-stage obfuscated payload from JSON Keeper, a paste service. “Static deobfuscation of the stage-2 payload reveals a full Remote Access Trojan (RAT) and information stealer that connects to 216[.]126[.]237[.]71 via Socket.IO, with capabilities including browser credential theft, crypto wallet extraction, screenshot capture, clipboard monitoring, keylogging, and remote mouse/keyboard control,” SafeDep noted this month. Interestingly, the use of legitimate packages like “socket.io-client” for command-and-control (C2) communication, “screenshot-desktop” for screen capture, “sharp” for image compression, and “clipboardy” for clipboard access overlaps with that of OtterCookie , a known stealer malware attributed to the campaign.

What’s novel this time around is the addition of the “@nut-tree-fork/nut-js” package for mouse and keyboard control, suggesting broader attempts to upgrade the RAT capabilities to facilitate interactive control of infected hosts. OtterCookie deployment chain OtterCookie, for its part, has witnessed a maturation of its own, getting distributed via a trojanized open-source 3D chess project hosted on Bitbucket and malicious npm packages like “gemini-ai-checker,” “express-flowlimit,” and “chai-extensions-extras.” A third method has employed a Matryoshka Doll approach as part of a campaign dubbed Contagious Trader . The attack begins with the download of a benign wrapper package (e.g., “bjs-biginteger”), which then proceeds to download a malicious dependency (e.g., “bjs-lint-builder”) and ultimately install the stealer. Overlaps between Contagious Interview, Contagious Trader, and graphalgo “The recent campaigns orchestrated by Shifty Corsair demonstrate the escalating threat of DPRK state-aligned cyber operations,” BlueVoyant researcher Curt Buchanan said .

“Their rapid evolution, from static Obfuscator.io encoding to dynamically rotating custom obfuscation, and their abuse of Vercel-hosted C2 infrastructure, demonstrates a maturation in their operational capabilities.” Graphalgo Uses Fake Companies to Drop RAT The development is significant as the threat actor has been simultaneously linked to another ongoing campaign dubbed graphalgo that lures developers using fake companies and leverages fake job interviews and coding tests to deliver malicious npm packages to their systems. The campaign plays out like this: the hackers employ social engineering ploys on job-seeking platforms and social networks to trick prospective targets into downloading GitHub-hosted projects as part of an assessment. These projects, in turn, contain a dependency to a malicious package published on npm or PyPI, whose main goal is to deploy a remote access trojan (RAT) on the machine. To pull off the attack, the operators set up a network of fake companies, complete with convincing profiles on platforms like GitHub, LinkedIn, and X to give them a veneer of legitimacy and make the deception more convincing.

In the case of Blocmerce, the attackers even went to the extent of actually registering a limited liability corporation (LLC) in the U.S. state of Florida under the same name in August 2025. The names of some of the companies used for frontend phishing are as follows - Veltrix Capital Blockmerce Bridgers Finance “These organizations link to several GitHub organizations related to blockchain companies that have been active on GitHub since June 2025,” ReversingLabs security researcher Karlo Zanki said . “Their purpose is to provide trustworthiness to fake job offerings and to host fake job interview tasks.” Recent versions of the campaign have also been spotted using a different technique for hosting the malicious dependencies.

Instead of publishing them to npm or PyPI, they are hosted as a release artifact in GitHub repositories, likely in an effort to minimize the risk of detection. “The reference to the malicious dependency is buried deep inside the list of the transitive dependencies. The resolved field in the package-lock.json file instructs the package manager where to fetch specific package dependencies from,” ReversingLabs noted. “While all other dependencies are fetched from the official npm registry, the malicious one is fetched directly from a release artifact located in a crafted GitHub repository.” The list of npm packages is below - graph-dynamic graphbase-js graphlib-js The attack culminates with the deployment of a RAT that can gather system information, enumerate files and directories, list running processes, create folders, rename files, delete files, and upload/download files.

In recent weeks, a North Korean state-sponsored threat cluster tracked as UNC1069 has also been linked to the compromise of “ axios ,” one of the most popular npm packages, highlighting the continued threat faced by open-source repositories from Pyongyang. Since then, the attackers behind the breach have published a new npm package called “csec-crypto-utils” containing an “updated payload” that substitutes the RAT dropper for a data stealer that exfoliates AWS keys, GitHub tokens, and .npmrc configuration files to an external server (“csec-c2-server.onrender[.]com”). In its report detailing the supply chain compromise, Hunt.io tied the attack to a Lazarus Group sub-cluster known as BlueNoroff , citing infrastructure overlaps and the RAT’s similarities with NukeSped . “The threat actors’ use of advanced techniques and tactics, as well as an astonishing level of campaign preparation (setting up a Florida LLC) and their ability to adapt, makes North Korean threat actors a top threat to organizations or individual developers focused on cryptocurrency,” ReversingLabs said.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Webinar: How to Automate Exposure Validation to Match the Speed of AI Attacks

In February 2026, researchers uncovered a shift that completely changed the game: threat actors are now using custom AI setups to automate attacks directly into the kill chain. We aren’t just talking about AI writing better phishing emails anymore. We’re talking about autonomous agents mapping Active Directory and seizing Domain Admin credentials in minutes. The problem?

Most defensive workflows still look like this: your CTI team finds a threat, they pass it to the Red Team to test, and eventually, the results reach the Blue Team for patching. This process is full of friction, silos, and delays. The reality is simple: You cannot fight an AI adversary moving at machine speed when your defense moves at the speed of a calendar invite. To bridge this gap, we’re hosting a technical deep dive with the team at Picus Security to unveil a new defensive paradigm: Autonomous Exposure Validation .

Register for the Webinar Here ➜ Leading this session are Kevin Cole (VP of Product Marketing) and Gursel Arici (Sr. Director of Solution Architecture) from Picus Security. Together, they bring a unique blend of strategic threat intelligence and deep technical engineering to show you how to flip the script. Here is exactly what you will walk away with: The Speed Asymmetry: A behind-the-scenes look at the real-world mechanics of how autonomous, AI-driven attacks actually operate.

The Agent Architecture: How to safely automate threat intel ingestion, simulate attacks, and coordinate fixes—without breaking your network. Breaking the Silos: How to eliminate the slow hand-offs between your CTI, Red, and Blue teams so they work as a single unit. The “Team Multiplier” Effect: How lean security teams can achieve enterprise-level protection without doubling their headcount. The attackers have already upgraded their toolkits.

It’s time for us to do the same. If you work in cybersecurity, you cannot afford to miss this shift. 📅 Save Your Spot Today: Register for the Webinar Here (P.S. Even if you can’t make it live, register anyway!

We’ll send you the full recording so you don’t miss out on these insights.) Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

What to Look for in an Exposure Management Platform (And What Most of Them Get Wrong)

Every security team has a version of the same story. The quarter ends with hundreds of vulnerabilities closed. The dashboards are bursting with green. Then someone in a leadership meeting asks: “So, are we actually safer now?” Crickets.

The room goes quiet because an honest answer requires context – which is something that patch counts and CVSS scores were never designed to provide. Exposure management was created to provide this context - to bridge the gap between remediation efforts and actual risk reduction. The market has responded with a flood of platforms claiming to deliver it. Yet the question security leaders are asking is: which exposure management platform actually does provide it?

In this article, I’ll break down the four dominant approaches to exposure management, explain what each one can and can’t deliver, and lay out five evaluation criteria that help you separate platforms built to reduce risk to your unique business and environment from platforms built to report on risk in the wild. Four Approaches, Four Architectures Most exposure management platforms fall into one of four categories, each shaped by how the vendor built (or pieced together) the platform and how it processes data. Stitched portfolio platforms are the product of acquisition(s). A vendor buys point solutions - cloud security, vulnerability scanning, identity analytics, etc.

and bundles them under its own brand. In these platforms, each product retains its own data model and discovers its own subset of exposures. The vendor may then unify the exposures in a shared console, and that can look like integration. But in practice, each module still operates on its own data and produces its own findings, with little correlation or interconnection between them.

Data aggregation platforms ingest findings from your existing scanners and third-party tools. Then they normalize the data and present it in a unified interface. These platforms can only work with what they receive. That means if ingested findings are disconnected, there’s no way to correlate how one exposure could enable the next.

Single-domain specialist platforms go deep in one area: cloud misconfigurations, network vulnerabilities, identity exposures, and external attack surface. They deliver strong results, but only in their specific domain of expertise. They run into challenges when exposures in one domain chain into exposures in another domain, and the platform has no way to model that relationship. Integrated platforms are built from scratch to discover and correlate multiple exposure types - credentials, misconfigurations, CVEs, identity issues, cloud configurations - in the same engine.

The platform builds a digital twin of the environment and maps how attackers can move laterally from one exposure to the next - across on-prem, cloud, and hybrid boundaries. Five Questions That Reveal What a Platform Can Actually Do The architecture behind each of the four approaches has real consequences for what your team can see, validate, and act on. How do you tell the difference when you’re evaluating? Start by asking these five questions: 1.

How many exposure types can it discover - and how deeply does it analyze each one? CVEs account for roughly 25% of the exposures that attackers exploit. Misconfigurations, cached credentials, excessive permissions, and identity weaknesses make up the rest. Stitched portfolios are limited to what each acquired product was built to find.

Aggregators can only normalize what their feeds provide. Single-domain platforms cover just one slice of the pie. An integrated platform should cover both existing and (especially) emerging exposure types - like AI workloads and machine identities - natively. And coverage alone doesn’t tell you enough.

What the platform actually knows about each exposure matters just as much. A platform that ingests findings from third-party tools is limited to the metadata those tools collect - their exploitability conditions, their remediation guidance, their research. A platform that discovers exposures natively controls every layer of information for each finding, from exploitability to fix. If your platform can’t see certain exposure types, you have blind spots.

If it sees them but lacks depth, you’re working with noise. 2. Can it map attack paths across environments? Some stitched products show attack paths.

Those paths are derived from network topology and based on connectivity alone. The platform never models how an attacker would actually move laterally from one exposure to the next. Aggregators produce no paths at all, just normalized lists of disconnected findings. The real test is whether the platform can trace paths across environment boundaries.

An attacker who captures cloud credentials on-prem can bypass every cloud-native defense - because the path started outside the cloud platform’s visibility. An external-facing vulnerability may look low-priority in isolation, but if it maps to an internal entity with a path to a critical asset, it’s an emergency. Most platforms can’t draw those connections. They scan each environment on its own and leave the gaps between them uncharted.

Does it validate exploitability? Most platforms check one or two conditions per exposure, limited by the metadata they store for each finding and the information they collect from each entity in your environment. But true validation means testing multiple conditions: Is the vulnerable library loaded by a running process?

Is the port open and reachable? The platform should deliver binary answers - exploitable or not, reachable or not, path to critical assets or not - all grounded in your actual environment, not general assumptions. 4. Does it factor in security controls?

A CVSS 9.8 vulnerability blocked by a firewall cannot be used for lateral movement…because it’s blocked. A 5.5 identity exposure with a direct path to a domain controller is an emergency. Platforms that ignore firewalls, MFA, EDR, and segmentation can leave your team chasing findings that carry no real risk - and missing the ones that actually threaten your critical assets. If security controls aren’t part of the attack path analysis, your prioritization is pointing you in the wrong direction, and you’re still exposed.

How does it prioritize? Prioritization should answer one question: Does this exposure put a critical asset at risk? Score-based ranking ignores your unique environment.

Asset-tag-based ranking ignores the assets on the blast radius of an exposure. Assumed-path ranking never validates exploitability. All three of these can overwhelm IT teams because none of them connect findings to what the business actually needs to protect. Effective prioritization starts with your critical assets and works backward.

The platform needs to prove that the exposure is exploitable, that an attacker can reach it, and the path leads to something the business can’t afford to lose. When a platform maps all of that in one graph, choke points emerge - places where one fix eliminates multiple attack paths. In large enterprise environments, that narrows the priority list to about 2% of all exposures. What This Means for Your Team The choice of platform architecture determines how secure your environment will be - and how your team spends its time getting there.

Stitched and aggregated platforms can leave teams scrambling to reconcile their findings across tools, fighting with IT over remediations that may not reduce risk, and chasing exposures that lead to dead ends. Single-domain platforms deliver depth in one area but leave blind spots across the rest of the attack surface. An integrated approach eliminates that overhead. It correlates exposures into validated attack paths, factors in the controls you’ve got in place, and identifies the fixes that eliminate the most risk with the fewest actions.

When a remediation closes a choke point, continuous exposure management platforms update the graph in real time. That way, you know that exposures that once looked urgent now lead nowhere, and your priority queue always reflects current risk. When your exposure management platform can validate exploitability, model security controls, and map every viable path to your critical assets – you can answer the question from the opening of this article ( Are we actually safer? ) with an honest yes!

. Note: This article was thoughtfully written and contributed for our audience by Maya Malevich, Head of Product Marketing at XM Cyber. Found this article interesting? This article is a contributed piece from one of our valued partners.

Critical cPanel Authentication Vulnerability Identified — Update Your Server Immediately

cPanel has released security updates to address a security issue impacting various authentication paths that could allow an attacker to obtain access to the control panel software. The problem affects all currently supported versions of cPanel and WebHost Manager (WHM), according to an alert published by WebPros on Tuesday. It does not have an official identifier. The issue has been addressed in the following versions - 11.110.0.97 11.118.0.63 11.126.0.54 11.132.0.29 11.136.0.5 11.134.0.20 “If your server is not running a supported version of cPanel that is eligible for this update, it is highly recommended that you work toward updating your server as soon as possible, as it may also be affected,” cPanel noted.

While cPanel did not share any details about the vulnerability, web hosting and domain registration company Namecheap disclosed that it “relates to an authentication login exploit that could allow unauthorized access to the control panel.” As a precautionary measure, the company has applied a firewall rule to block access to TCP ports 2083 and 2087, a move it said will temporarily restrict customer access to their cPanel and WHM interfaces until a full patch is applied. “Our team is actively monitoring the situation and will apply the official patch across all supported servers as soon as it becomes available,” Namecheap noted. “Access to your control panels will be restored immediately once the patch has been successfully deployed.” As of April 29, 2026, 02:42 a.m. UTC, the fix has been applied to Reseller, Stellar Business servers, and the rest, according to the Namecheap Support Team.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

99% of Mythos Findings Remain Unpatched. Defenders Are Building the Response

CISA Adds Actively Exploited ConnectWise and Windows Flaws to KEV

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added two security flaws impacting ConnectWise ScreenConnect and Microsoft Windows to its Known Exploited Vulnerabilities ( KEV ) catalog, based on evidence of active exploitation. The vulnerabilities are listed below - CVE-2024-1708 (CVSS score: 8.4) - A path traversal vulnerability in ConnectWise ScreenConnect that could allow an attacker to execute remote code or directly impact confidential data and critical systems. (Fixed in February 2024) CVE-2026-32202 (CVSS score: 4.3) - A protection mechanism failure vulnerability in Microsoft Windows Shell that could allow an unauthorized attacker to perform spoofing over a network.

(Fixed in April 2026) The addition of CVE-2026-32202 to the KEV catalog comes a day after Microsoft updated its advisory for the flaw to acknowledge it had come under active exploitation. Although Microsoft has not disclosed the nature of the attacks weaponizing the flaw, Akamai said the vulnerability stemmed from an incomplete patch for CVE-2026-21510, which was exploited as a zero-day alongside CVE-2026-21513 by the Russian hacking group APT28 in attacks targeting Ukraine and E.U. countries since December 2025. Attacks exploiting CVE-2024-1708 , on the other hand, have been chained with CVE-2024-1709 (CVSS score: 10.0), a critical authentication bypass vulnerability, by multiple threat actors over the years.

Earlier this month, Microsoft linked the exploitation of the flaws to a China-based threat actor it tracks as Storm-1175 in attacks deploying Medusa ransomware. It’s worth noting that CISA added CVE-2024-1709 to the KEV catalog on February 22, 2024. Federal Civilian Executive Branch (FCEB) agencies are required to apply the necessary fixes by May 12, 2026, to secure their networks. Found this article interesting?

LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure

In yet another instance of threat actors quickly jumping on the exploitation bandwagon, a newly disclosed critical security flaw in BerriAI’s LiteLLM Python package has come under active exploitation in the wild within 36 hours of the bug becoming public knowledge. The vulnerability, tracked as CVE-2026-42208 (CVSS score: 9.3), is an SQL injection that could be exploited to modify the underlying LiteLLM proxy database. “A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter,” LiteLLM maintainers said in an alert last week. “An unauthenticated attacker could send a specially crafted Authorization header to any LLM API route (for example, POST /chat/completions) and reach this query through the proxy’s error-handling path.

An attacker could read data from the proxy’s database and may be able to modify it, leading to unauthorized access to the proxy and the credentials it manages.” The shortcoming affects the following versions -

=1.81.16 <1.83.7 While the vulnerability was addressed in version 1.83.7-stable released on April 19, 2026, the first exploitation attempt was recorded on April 26 at 16:17 UTC, roughly 26 hours and seven minutes after the GitHub advisory was indexed in the global GitHub Advisory Database. The SQL injection activity, per Sysdig, originated from the IP address 65.111.27[.]132. “Malicious activity fell into two phases driven by the same operator across two adjacent egress IPs, followed by a brief unauthenticated probe of the key-management endpoints,” security researcher Michael Clark said . Specifically, the unknown threat actor is said to have targeted database tables like “litellm_credentials.credential_values” and “litellm_config” that hold information related to upstream large language model (LLM) provider keys and the proxy runtime environment.

No probes were observed against tables like “litellm_users” or “litellm_team.” This suggests that the attacker was not only aware of these tables, but also went after those that hold sensitive secrets. In the second phase of the attack, observed after 20 minutes, the threat actor used a different IP address (“65.111.25[.]67”), this time abusing the access to run a similar probe. LiteLLM is a popular, open-source AI Gateway software with over 45,000 stars and 7,600 forks on GitHub. Last month, the project was the target of a supply chain attack orchestrated by the TeamPCP hacking group to steal credentials and secrets from downstream users.

“A single litellm_credentials row often holds an OpenAI organization key with five-figure monthly spend caps, an Anthropic console key with workspace admin rights, and an AWS Bedrock IAM credential,” Sysdig said. “The blast radius of a successful database extraction is closer to a cloud-account compromise than a typical web-app SQL injection.” Users are advised to patch their instances to the latest version. If this is not an immediate option, the maintainers recommend setting “disable_error_logs: true” under “general_settings” to remove the path through which untrusted input reaches the vulnerable query. “The LiteLLM vulnerability (GHSA-r75f-5x8p-qvmc) continues the modal pattern for AI-infrastructure advisories: critical, pre-auth, and in software with five-figure star counts that operators trust to centralize cloud-grade credentials,” Sysdig added.

“The 36-hour exploit window is consistent with the broader collapse documented by the Zero Day Clock, and the operator behavior we recorded (verbatim Prisma table names, three-table targeting, deliberate column-count enumeration) shows that exploitation no longer waits for a public PoC. The advisory and the open-source schema were ultimately enough.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw Exploitable via Single Git Push

Cybersecurity researchers have disclosed details of a critical security vulnerability impacting GitHub.com and GitHub Enterprise Server that could allow an authenticated user to obtain remote code execution with a single “git push” command. The flaw, tracked as CVE-2026-3854 (CVSS score: 8.7), is a case of command injection that could allow an attacker with push access to a repository to achieve remote code execution on the instance. “During a git push operation, user-supplied push option values were not properly sanitized before being included in internal service headers,” per a GitHub advisory for the vulnerability. “Because the internal header format used a delimiter character that could also appear in user input, an attacker could inject additional metadata fields through crafted push option values.” Google-owned cloud security firm Wiz has been credited with discovering and reporting the issue on March 4, 2026, with GitHub validating and deploying a fix to GitHub.com within two hours.

The vulnerability has also been addressed in GitHub Enterprise Server versions 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0, or later. There is no evidence that the issue was ever exploited in a malicious context. According to GitHub, the issue affects GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server. At its core, the problem stems from the fact that user-supplied git push options are not adequately sanitized before the values were incorporated into the internal X-Stat header.

Because the internal metadata format relies on a semicolon as a delimiter character that could also appear in the user input, a bad actor could exploit this oversight to inject arbitrary commands and have them executed. “By chaining several injected values together, the researchers demonstrated that an attacker could override the environment the push was processed in, bypass sandboxing protections that normally constrain hook execution, and ultimately execute arbitrary commands on the server,” GitHub’s Chief Information Security Officer, Alexis Wales, said . Wiz, in a coordinated announcement, noted that the issue is “remarkably easy” to exploit, adding that it allows remote code execution on shared storage nodes. About 88% of instances are currently vulnerable to the issue at the time of public disclosure.

The remote code execution chain strings together three injections - Inject a non-production rails_env value to bypass the sandbox Inject custom_hooks_dir to control to redirectthe hook directory Inject repo_pre_receive_hooks with a crafted hook entry that triggers path traversal to execute arbitrary commands as the git user “With unsandboxed code execution as the git user, we had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration,” Wiz security researcher Sagi Tzadik said . As for GitHub.com, an enterprise mode flag – that’s set to “true” for GitHub Enterprise Server – defaults to “false,” rendering the custom hooks path inactive. But since this flag is also passed in the X-Stat header, it’s equally injectable using the same mechanism, thereby resulting in code execution on GitHub.com as well. To make matters worse, given GitHub’s multi-tenant architecture and its shared backend infrastructure, the company pointed out that obtaining code execution on GitHub.com enabled cross-tenant exposure, effectively allowing an attacker to read millions of repositories on the shared storage node, irrespective of the organization or user.

In light of the severity of CVE-2026-3854, users are advised to apply the update immediately for optimal protection. “A single git push command was enough to exploit a flaw in GitHub’s internal protocol and achieve code execution on backend infrastructure,” Wiz said. “When multiple services written in different languages pass data through a shared internal protocol, the assumptions each service makes about that data become a critical attack surface.” “We encourage teams building multi-service architectures to audit how user-controlled input flows through internal protocols – especially where security-critical configuration is derived from shared data formats.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Brazilian LofyGang Resurfaces After Three Years With Minecraft LofyStealer Campaign

A cybercrime group of Brazilian origin has resurfaced after more than three years to orchestrate a campaign that targets Minecraft players with a new stealer called LofyStealer (aka GrabBot). “The malware disguises itself as a Minecraft hack called ‘Slinky,’” Brazil-based cybersecurity company ZenoX said in a technical report. “It uses the official game icon to induce voluntary execution, exploiting the trust of young users in the gaming scene.” The activity has been attributed with high confidence to a threat actor known as LofyGang , which was observed leveraging typosquatted packages on the npm registry to push stealer malware in 2022, specifically with an intent to siphon credit card data and user accounts associated with Discord Nitro, gaming, and streaming services. The group, believed to be active since late 2021, advertises their tools and services on platforms like GitHub and YouTube, while also contributing to an underground hacking community under the alias DyPolarLofy to leak thousands of Disney+ and Minecraft accounts.

“Minecraft has been a LofyGang target since 2022,” Acassio Silva, co-founder and head of threat intelligence at ZenoX, told The Hacker News. “They leaked thousands of Minecraft accounts under the DyPolarLofy alias on Cracked.io. The current campaign goes after Minecraft players directly through a fake ‘Slinky’ hack.” The attack begins with a Minecraft hack that, when launched, triggers the execution of a JavaScript loader that’s ultimately responsible for the deployment of LofyStealer (“chromelevator.exe”) on compromised hosts and execute it directly in memory with an aim to harvest a wide range of sensitive data spanning multiple web browsers, including Google Chrome, Chrome Beta, Microsoft Edge, Brave, Opera, Opera GX, Mozilla Firefox, and Avast Browser. The captured data, which includes cookies, passwords, tokens, cards, and International Bank Account Numbers (IBANs), is exfiltrated to a command-and-control (C2) server located at 24.152.36[.]241.

“Historically, the group’s primary vector was the JavaScript supply chain: NPM package typosquatting, starjacking (fraudulent references to legitimate GitHub repositories to inflate credibility), and payloads embedded in sub-dependencies to evade detection,” ZenoX said. “The focus was on Discord token theft, Discord client modification for credit card interception, and exfiltration via webhooks abusing legitimate services (Discord, Repl.it, Glitch, GitHub, and Heroku) as C2.” The latest development marks a departure from previously observed tradecraft and a shift towards a malware-as-a-service (MaaS) model with free and premium tiers, along with a bespoke builder called Slinky Cracked that’s used as a delivery vehicle for the stealer malware. The disclosure comes as threat actors are increasingly abusing the ubiquity and trust associated with GitHub to host bogus repositories that act as lures for malware families like SmartLoader, StealC Stealer , and Vidar Stealer. Unsuspecting users are directed to these repositories through techniques like SEO poisoning.

In some cases, attackers have been found to spread Vidar 2.0 through Reddit posts advertising fake Counter-Strike 2 game cheats, redirecting victims to a malicious website that delivers a ZIP archive containing the malware. “This infostealer campaign highlights an ongoing security challenge where widely trusted platforms are abused to distribute malicious payloads,” Acronis said in an analysis published last month. “By taking advantage of social trust and common download channels, threat actors are often able to bypass traditional security solutions.” The findings add to a growing list of campaigns that have leveraged GitHub in recent months - Targeting developers directly inside GitHub, using fake Microsoft Visual Studio Code (VS Code) security alerts posted through Discussions to trick users into installing malware by clicking on a link. “Because GitHub Discussions trigger email notifications for participants and watchers, these posts are also delivered directly to developers’ inboxes,” Socket said .

“This extends the reach of the campaign beyond GitHub itself and makes the alerts appear more legitimate.” Targeting Argentina’s judicial systems using spear‑phishing emails to distribute a compressed ZIP archive that uses an intermediate batch script to retrieve a remote access trojan (RAT) hosted on GitHub. Creating GitHub accounts and OAuth applications , followed by opening an issue that mentions a target developer, triggering an email notification that, in turn, tricks them into authorizing the OAuth app, effectively allowing the attacker to obtain their access tokens. The issues aim to induce a false sense of urgency, warning users of unusual access attempts. Using fraudulent GitHub repositories to distribute malicious batch script installers masquerading as legitimate IT and security software, leading to the deployment of the TookPS downloader, which then initiates a multi-stage infection chain to establish persistent remote access using SSH reverse tunnels and RATs like MineBridge RAT (aka TeviRAT).

The activity has been attributed to Rift Brigantine (aka FIN11, Graceful Spider, and TA505). Using counterfeit GitHub repositories posing as AI tools, game cheats, Roblox scripts, phone number location trackers, and VPN crackers to distribute LuaJIT payloads that function as a generic trojan as part of a campaign dubbed TroyDen’s Lure Factory. “The breadth of the lure factory – gaming cheats, developer tools, phone trackers, Roblox scripts, VPN crackers – suggests an actor optimizing for volume across audiences rather than precision targeting,” Netskope said. “Defenders should treat any GitHub-hosted download that pairs a renamed interpreter with an opaque data file as a high-priority triage candidate, regardless of how legitimate the surrounding repository looks.” Found this article interesting?

VECT 2.0 Ransomware Irreversibly Destroys Files Over 131KB on Windows, Linux, ESXi

Threat hunters are warning that the cybercriminal operation known as VECT 2.0 acts more like a wiper than a ransomware due to a critical flaw in its encryption implementation across Windows, Linux, and ESXi variants that renders recovery impossible even for the threat actors. The fact that VECT’s locker permanently destroys large files rather than encrypting them means even victims who opt to pay the ransom cannot get their data back, as the decryption keys are discarded by the malware during the time encryption occurs. “VECT is being marketed as ransomware, but for any file over 131KB – which is most of what enterprises actually care about – it functions as a data destruction tool,” Eli Smadja, group manager at Check Point Research, said in a statement shared with The Hacker News. “CISOs need to understand that in a VECT incident, paying is not a recovery strategy.

There is no decrypter that can be handed over, not because the attackers are unwilling, but because the information required to build one was destroyed the moment their software ran. The focus has to be on resilience: offline backups, tested recovery procedures, and rapid containment – not negotiation.” VECT (now rebranded as VECT 2.0) is a ransomware-as-a-service (RaaS) scheme that first launched its affiliate program in December 2025. On its dark website, the group displays the message “Exfiltration / Encryption / Extortion,” highlighting its triple-threat business model. According to an analysis published by the Data Security Council of India (DSCI) last month, a $250 entry fee, payable in Monero (XMR), is required for new affiliates.

The fee is waived for applicants from the Commonwealth of Independent States (CIS) countries, indicating an attempt to recruit individuals from the region. In recent weeks, the group has established a formal partnership with the BreachForums cybercrime marketplace and the TeamPCP hacking group, in a move aimed at further lowering the barrier to entry for ransomware operators and incentivizing affiliates to launch attacks by weaponizing previously stolen data. “The convergence of large-scale supply chain credential theft, a maturing RaaS operation, and mass dark web forum mobilization represents an unprecedented model of industrialized ransomware deployment,” Dataminr noted earlier this month. While the collaboration may be a sign of what’s to come, its data leak site currently lists only two victims, both of which are said to have been compromised via the TeamPCP supply chain attacks.

What’s more, contrary to the group’s initial claims of using ChaCha20-Poly1305 AEAD for encryption, Check Point’s analysis has found that it uses a weaker, unauthenticated cipher with no integrity protection. But it doesn’t end there, for the C++-based lockers for all three platforms suffer from a fundamental design flaw that causes any file larger than 131,072 bytes to be permanently and irrecoverably destroyed, as opposed to being encrypted. “The malware encrypts four independent chunks of each ‘large file’ using four freshly generated random 12-byte nonces, but appends only the final nonce to the specific encrypted file on disk,” Check Point explained. “The first three nonces, each required to decrypt its respective chunk, are generated, used, and silently discarded.

They are never stored on disk, in the registry, or transmitted to the operator.” “Because ChaCha20-IETF requires both the 32-byte key and the exact matching 12-byte nonce to reverse each chunk, the first three quarters of every large file are unrecoverable by anyone, including the ransomware operator, who cannot provide a working decryption tool even after ransom payment. Since the vast majority of operationally critical files exceed this ‘large-size’ threshold, VECT 2.0 functions in practice as a data wiper with a ransomware facade.” The Windows version of the ransomware, besides encrypting files across local, removable, and network-accessible storage, features a comprehensive anti-analysis suite targeting 44 specific security and debugging tools, alongside a safe-mode persistence mechanism and multiple remote-execution script templates for lateral spread. When “–force-safemode” is active, the locker configures the next boot into Windows Safe Mode and writes its own executable path into the Windows Registry so that it’s automatically run on the subsequent Safe Mode boot, where the operating system is launched in a basic state using a limited set of files and drivers. On top of that, although the Windows variant implements environment detection mechanisms to fly under the radar, they are never invoked, allowing security teams running the artifacts to avoid triggering any evasive response.

The ESXi variant, on the other hand, enforces geofencing and anti-debugging checks prior to commencing the encryption step. It also attempts to move laterally using SSH. The Linux version uses the same codebase as the ESXi flavor and implements a subset of its functionality. The geofencing step verifies if it’s running in a CIS country, and if so, exits without encrypting the files.

This behavior, per Check Point, is rather unusual as most RaaS programs removed Ukraine from the CIS countries list following Russia’s military invasion of the country in early 2022. “During recent years these checks have been largely removed from ransomware,” it added. “VECT including such checks and even adding Ukraine to the list of exclusions is rather uncommon. Check Point Research has two theories regarding this observation: either this code was AI generated, where LLMs were trained with Ukraine being part of CIS or VECT used an old code base for their ransomware.” It’s assessed that the operators of VECT are novice actors rather than experienced threat actors, not to mention the possibility that some chunks of code could have been generated with help from an artificial intelligence (AI) tool.

“VECT 2.0 presents an ambitious threat profile with multi-platform coverage, an active affiliate program, supply-chain distribution via the TeamPCP partnership, and a polished operator panel,” Check Point concluded. “In practice, the technical implementation falls significantly short of its presentation.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Why Secure Data Movement Is the Zero Trust Bottleneck Nobody Talks About

Every security program is betting on the same assumption: once a system is connected, the problem is solved. Open a ticket, stand up a gateway, push the data through. Done. That assumption is wrong.

It is also a major reason Zero Trust programs stall. New research my team just published puts numbers on it. The Cyber360: Defending the Digital Battlespace report, based on a survey of 500 security leaders in government, defense, and critical services across the U.S. and UK, found that 84% of government IT security leaders agree that sharing sensitive data across networks heightens their cyber risk.

More than half - 53% - still rely on manual processes to move that data between systems. In 2026. With AI accelerating the pace of operations on both sides. That is the Zero Trust gap nobody talks about.

Not identity. Not endpoints. The movement of data itself. The Threat Volume Is Rising Faster Than the Controls Cyber360 recorded an average of 137 attempted or successful cyberattacks per week against national security organizations in 2025, up from 127 the previous year.

U.S. agencies saw the weekly rate surge 25%. Verizon’s 2025 Data Breach Investigations Report tracks a similar trajectory on the enterprise side: third-party involvement in breaches doubled year over year, reaching 30% of all incidents. IBM’s 2025 Cost of a Data Breach Report put the average cost of a breach spanning multiple environments at $5.05 million, roughly $1 million more than on-premises-only incidents.

The boundaries between IT and OT, between tenants, between partner and internal environments are where the money and the dwell time sit right now. Connectivity Is Not the Same as Secure Data Movement The moment data crosses a boundary, whether between an OT network and the enterprise SOC, between a partner tenant and your cloud, or between classified and unclassified, it stops being a routing problem and becomes a trust problem. It has to be validated, filtered, and policy-controlled before anything downstream can act on it. That is where modern architectures slow down.

The Cyber360 data is blunt about where the pain is concentrated: 78% of respondents cited outdated infrastructure as a primary source of cyber vulnerability, specifically pointing to analog systems and manual processes as weak links. 49% named ensuring data integrity and preventing tampering in transit as their single biggest challenge when transferring information across classified or coalition networks. 45% flagged managing identity and authentication across multiple domains as their biggest access challenge. Integrity in transit, identity across domains, and manual processes are still in the loop.

That is a working description of the attack surface adversaries have been exploiting for three years. The enterprise data tells the same story in a different language. Dragos’ 2025 OT Cybersecurity Report found that 75% of OT attacks now originate as IT breaches, with roughly 70% of OT systems expected to connect to IT networks within the next year. The traditional IT/OT air gap is effectively gone.

The managed file transfer breaches drive the point home. Cl0p’s exploitation of MOVEit compromised more than 2,700 organizations and exposed the personal data of roughly 93 million individuals. The same playbook worked against GoAnywhere and Cleo. Every one of those incidents was, at its core, an attack on the pipes that move data between trust boundaries.

The Speed-vs-Security Trade-off Is a Myth There is a persistent belief that you can either move data fast or move it securely. Pick one. In practice, most teams pick security and accept the delay. That works when decision cycles are measured in minutes.

It does not work when they are measured in seconds, and it collapses completely when they are measured in milliseconds. AI is accelerating on both sides. Detection and response pipelines are moving toward autonomous action. They do not wait for a gateway to finish inspecting a file.

When 53% of national security organizations are still moving data manually, the delta between AI-speed demand and analog-speed supply becomes the attack surface. An AI model, whether it is running fraud detection, threat triage, or targeting analysis, is only as good as the data reaching it. When that data cannot move freely, or cannot be trusted when it arrives, the model runs on stale or partial context. The bottleneck is not the intelligence layer.

It is the plumbing underneath. The Role of Cross Domain Technologies This is where cross-domain technologies earn their place, and not as a compliance checkbox. Done properly, they remove the forced choice between speed and security. They enforce trust at the boundary instead of after it.

They let systems operate as a coordinated whole, instead of as a set of isolated islands stapled together with point-to-point integrations that attackers have now demonstrated they can dismantle at scale. The Cyber360 research points toward a specific architectural answer: a layered model combining Zero Trust, Data Centric Security, and Cross Domain Solutions. No single framework closes the gap alone. Zero Trust governs who and what.

Data-centric security governs the data itself, wherever it goes. Cross-domain solutions govern the movement between environments. Together, they let secure data sharing happen at near-real-time speed across classified, coalition, and operational boundaries. The principle applies well beyond defense: enterprise programs where SOC data crosses OT, IT, and cloud boundaries; critical infrastructure where operational data has to reach decision-makers without dropping integrity; multi-party investigations where partner data has to flow in both directions under policy.

The Bottom Line The assumption that data arrives trusted the moment it crosses a boundary is the assumption that attackers are most reliably exploiting right now. The boundary is the attack surface. Movement is where policy collapses. And when more than half of national security organizations are still moving sensitive data through manual processes, the gap between mission speed and control speed is not just a bottleneck.

It is the vulnerability. That is the space Everfox works in: securing the access, transfer, and movement of data across environments at mission speed. For the architecture patterns, control placements, and operational pitfalls, see our A Guide to Secure Collaboration & Data Movement . Note: This article is written and contributed by Petko Stoyanov, Chief Technology Officer, Everfox.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Critical Unpatched Flaw Leaves Hugging Face LeRobot Open to Unauthenticated RCE

Cybersecurity researchers have disclosed details of a critical security flaw impacting LeRobot , Hugging Face’s open-source robotics platform with nearly 24,000 GitHub stars , that could be exploited to achieve remote code execution. The vulnerability in question is CVE-2026-25874 (CVSS score: 9.3), which has been described as a case of untrusted data deserialization stemming from the use of the unsafe pickle format . “LeRobot contains an unsafe deserialization vulnerability in the async inference pipeline, where pickle.loads() is used to deserialize data received over unauthenticated gRPC channels without TLS in the policy server and robot client components,” according to a GitHub advisory for the flaw. “An unauthenticated network-reachable attacker can achieve arbitrary code execution on the server or client by sending a crafted pickle payload through the SendPolicyInstructions, SendObservations, or GetActions gRPC calls.” According to Resecurity, the problem is rooted in the async inference PolicyServer component, allowing an unauthenticated attacker who can reach the PolicyServer network port to send a malicious serialized payload and run arbitrary operating system commands on the host machine running the service.

The cybersecurity company said the vulnerability is “dangerous” as the service is designed for artificial intelligence inference systems, which tend to run with elevated privileges to access internal networks, datasets, and expensive compute resources. Should the flaw be exploited by an attacker, it could enable a wide range of actions, including - Unauthenticated remote code execution Complete compromise of the PolicyServer host Impact connected robots Theft of sensitive data, such as API keys, SSH credentials, and model files Move laterally across the network Crash services, corrupt models, or sabotage operations, leading to physical safety risks VulnCheck security researcher Valentin Lobstein, who discovered and published additional details of the shortcoming last week, said it has been successfully validated against LeRobot version 0.4.3. The issue currently remains unpatched, with a fix planned in version 0.6.0 . Interestingly, the same flaw was independently reported by another researcher who goes by the online alias “chenpinji” sometime in December 2025.

The LeRobot team responded earlier this January, acknowledging the security risk and noting “that part of the codebase needs to be almost entirely refactored as its original implementation was more experimental.” “That said, LeRobot has so far been primarily a research and prototyping tool, which is why deployment security hasn’t been a strong focus until now,” Steven Palma, tech lead of the project, said. “As LeRobot continues to be adopted and deployed in production, we’ll start paying much closer attention to these kinds of issues. Fortunately, being an open-source project, the community can also help by reporting and fixing vulnerabilities.” The findings once again expose the dangers of using the pickle format, as it paves the way for arbitrary code execution attacks simply by loading a specially crafted file. “The irony here is hard to overstate,” Lobstein noted.

“Hugging Face created Safetensors – a serialization format designed specifically because pickle is dangerous for ML data. And yet their own robotics framework deserializes attacker-controlled network input with pickle.loads(), with

nosec comments

to silence the tool that was trying to warn them.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.