litellm

France’s Directorate General of Public Finances (DGFiP) has disclosed a data breach impacting approximately 680,000 individuals. The incident was disclosed after a threat actor boasted on a hacking forum about accessing DGFiP’s internal systems and exfiltrating data. According to DGFiP, the threat actor accessed its systems in June and July, and the unauthorized access was suspended immediately upon detection. However, the public tax authority did not discover evidence of data exfiltration at the time. Last week, DGFiP confirmed that the attackers used compromised credentials for an employee and a third-party account to access its systems and steal the information of 678,000 users. According to the finance agency, reference tax income, withholding tax rate, company names and unique identifiers, and cadastral data on real estate addresses and surfaces were compromised. No other information, including usernames and passwords, was compromised in the attack, which was immediately reported to France’s data protection authority CNIL. DGFiP says it continues to investigate the nature and scope of the data breach, as well as the exact number of potentially affected individuals. The tax authority says it will contact each affected individual directly. The incident came to light roughly one month after another European government agency, Romania’s National Agency for Cadastre and Property Registration (ANCPI), fell victim to a disruptive cyberattack. ANCPI was reportedly hacked by a threat actor known as ByteToBreach, who stole information including employee credentials and internal documents and attempted to extort the agency. When the extortion attempt failed, the hacker reportedly wiped the encrypted data, disrupting official applications, sites, and email services, and bringing Romania’s real estate market to a standstill. The central database of the cadastral system, containing property and real estate rights records, was not affected. Still, ANCPI scrambled for roughly three weeks to rebuild its servers and restore the affected applications. Related: 40,000 Impacted by SafePal Data Breach Related: Fortune 500 Companies Hit in Azure Data Theft Campaign Related: Trivy, Not LiteLLM Behind the 2,500 Org Compromise Related: Irregular Details How a Naming Error Let AI Models Attack a Real Company

Crypto hardware wallet SafePal is notifying roughly 40,000 individuals that their personal information was stolen in a data breach. Hackers, it says, exploited a vulnerability in the order-tracking function of a customer order information plugin to gain access to customer information. “We are extremely sorry to inform the community that order information for customers who placed orders between March 2, 2025, and April 11, 2026,” SafePal says. The compromised information includes names, addresses, email addresses, phone numbers, and order details. “The affected data involves approximately 39,798 customers,” the crypto wallet says. SafePal disclosed the data breach on Sunday, the same day that a threat actor started advertising on a cybercrime forum the theft of SafePal data. In line with SafePal’s disclosure, the attacker claims 39,798 people were affected. The company underlines that no other customer-related information was affected. “This incident did not involve your seed phrase, private keys, wallet password, or other wallet credentials, bank account information, payment card numbers, or government-issued identification numbers,” it says. Potentially affected individuals are advised to be wary of suspicious communication requesting their seed phrases or private keys. “If you have already shared or entered your seed phrase or private key in response to a suspicious message, website, phone call, or letter, treat that wallet as compromised. Create a new wallet using a trusted SafePal device or official SafePal application, and move your remaining assets to the new wallet immediately,” SafePal notes. According to the company, it started investigating the incident after receiving a report in May, but treated it as an isolated case. It later discovered that a bug in its system resulted in order-related data being stored for much longer than intended. “To resolve this conclusively, we began a full review and rebuild of our order-processing pipeline in July, and confirmed the root cause mentioned during the investigation,” it notes. The company says it has addressed the vulnerability exploited in the attack, tightened the retention period for order-related information, identified and notified the impacted people, contacted partners to ensure the issue did not propagate, and retained a third-party security firm to investigate. SafePal says it has “identified and taken down over 30 fraudulent websites and phishing links tied to the scam activities, with continued active monitoring for new ones.” The company urges customers who might have experienced a financial loss related to the incident to contact it and provide relevant details, as it has been contacting on-chain asset-tracing specialists. “Note that this does not represent any admission of liability or commitment to compensation; our focus at this stage is supporting recovery and ongoing investigations,” SafePal notes. Related: Fortune 500 Companies Hit in Azure Data Theft Campaign Related: Trivy, Not LiteLLM Behind the 2,500 Org Compromise Related: Over 1,000 Charities Hit by Beacon CRM Data Breach Related: 14,000 Trezor Customers Impacted by Data Breach at ShipMonk

Most of the 2,500 organizations believed to have been affected by the LiteLLM supply chain attack were actually exposed before, SOCRadar reports. The compromise was blamed on and claimed by TeamPCP, the threat actor behind multiple open source software (OSS) supply chain attacks involving the Shai-Hulud worm. It started with Aqua Security’s Trivy scanner and propagated downstream to multiple packages and repositories in a ripple effect fueled by the malware’s worm-like behavior and by the automated inclusion of the malicious libraries in more builds. More than 2,500 organizations were likely affected by the LiteLLM attack, CloudSEK and HudsonRock said earlier this week. According to SOCRadar, most of them were victims of the Trivy compromise, not LiteLLM. All the compromises associated with TeamPCP followed a similar pattern: malicious code was automatically executed when the infected package was fetched and run to harvest credentials, tokens, API keys, and other secrets. Additionally, the worm used stolen developer secrets to modify accessible packages and push the malicious versions to the registry, expanding the attack surface. This is how LiteLLM was compromised and how two poisoned package versions were published on March 24 and stayed online for roughly 40 minutes. They were injected with a .pth file that Python automatically executed at interpreter startup, even if LiteLLM was never imported, bypassing ignore-scripts protections. The compromise timeframe According to SOCRadar, a close examination of the LiteLLM incident data revealed per-organization records for 2,188 entities, including timestamps, credential types, CI/CD platforms, and domains. “Every record carries first-seen and last-seen timestamps. The earliest is March 19 at 18:05 UTC and the latest is March 24 at 20:09 UTC, a span of just over five days,” the cybersecurity firm notes. For 2,085 organizations, or 95% of the 2,188 that were identified, data collection activity ended before March 24, when the poisoned LiteLLM packages were published to the registry. “That timing lines up with the upstream Trivy compromise rather than the LiteLLM install window. The 40 minutes everyone reported was the closing act, not the whole play,” SOCRadar says. The earliest collection occurred 18 minutes after the malicious Trivy build was published on March 19. The activity surged on March 22 and March 23 when malicious Trivy images were live on Docker Hub, and closed on March 24 after PyPI quarantined the packages. “[This] is what persistence on already-infected hosts looks like: the .pth payload kept running after the source of the infection was gone,” SOCRadar notes. The compromise involved six CI/CD platforms, namely GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite, and impacted organizations worldwide, with Germany, Brazil, and France affected the most. Stolen, now brokered secrets The malware targeted secrets broadly, but over 1,000 organizations exposed JWT and auth tokens. Hundreds of them exposed private keys, AWS access keys, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, and Google API keys. “The highest secret count in the set is roughly 3,477 [the organization has not been named], followed by roughly 3,459. Several high-secret rows rest on very few files or repositories. One row carries 3,459 secrets across just six files,” SOCRadar notes. The cybersecurity firm also points out that committer email addresses were compromised across over 1,100 organizations. In those cases, the attackers have both developer identities and machine tokens. “Of the 2,188 organizations in the record-level set, 56% are rated high confidence, 39% medium, and 6% low, with figures rounded. Headline reporting cites 2,500+ organizations; the difference reflects which records carry attributable identifiers,” SOCRadar notes. “High-confidence matches are keyed on CI host identity and legitimate committer domains, meaning whose systems a captured file came from, rather than any observed use of a stolen credential. These are exposure figures rather than confirmed compromises, drawn from a reconstructed sample rather than a complete census,” it continues. The stolen information is already being brokered. One threat actor is offering on Telegram a collection of LiteLLM, Trivy, and CanisterWorm data, likely compiled at various stages of the campaign. Related: Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack Related: North Korean Hackers Target Open Source Developers in Supply Chain Attacks Related: North Korean Hackers Blamed for Mastra NPM Supply Chain Attack Related: Hackers Exploiting Unpatched GeoServer Zero-Day

153GB of stolen credentials surface after LiteLLM supply chain attack A massive 153GB archive stolen during the LiteLLM supply chain attack exposes credentials and other sensitive data linked to thousands of corporate domains, including AWS, Samsung, Cisco, and Salesforce. Hudson Rock says it obtained and analyzed the archive, which contains 433,909 files, and attributed 118,829 CI runner dumps to 2,488 corporate domains. “We are leveraging this data for a global ethical disclosure effort,” Alon Gal, Hudson Rock’s co-founder and CTO, told Help Net Security. “We see this as an opportunity to help organizations respond proactively before threat actors weaponize the data publicly.” LiteLLM is an open-source proxy gateway that developers use to route requests to different AI models. The LiteLLM breach had its roots in an earlier compromise of Trivy, a popular open-source vulnerability scanner. On March 19, 2026, TeamPCP, a cybercriminal group that emerged in late 2025, used stolen credentials to publish a compromised version of Trivy. LiteLLM’s build pipeline installed Trivy automatically, giving the poisoned scanner read access to the runner environment and allowing the attackers to steal the project’s PyPI publishing tokens. Using those tokens, TeamPCP published two malicious LiteLLM releases, versions 1.82.7 and 1.82.8, to the Python Package Index on March 24. “The key takeaway is how supply chains have evolved to make a single upstream breach affect thousands of companies simultaneously. A window of roughly 40 minutes in which the LiteLLM dependency was hacked led to over 430,000 instances in which millions of secrets were harvested,” Gal said. Tracing exposed secrets back to their owners The dataset contains information linked to organizations including NVIDIA, Volkswagen, Microsoft, FedEx, S&P Global, John Deere, Epic Games, Orange, TomTom, BT Group, ServiceNow, Deloitte, and Siemens. Screenshots published with the research show AWS secret access keys, Salesforce client secrets, Slack signing secrets, Azure environment variables, and AI provider API keys captured during pipeline execution. A trove of internal corporate secrets (Source: Hudson Rock) CloudSEK, working from a separate dataset built from about 434,000 stolen files, put the number of exposed organizations at close to 2,500. The company stressed that its figures reflect exposure rather than confirmed breaches. “I’ve confirmed the data is legit by the way, multiple victim orgs,” security researcher Kevin Beaumont said. “It contains a significant volume of sensitive content at orgs. It’s a massive supply chain breach due to poor AI security—not because AI is the threat, but teens can run circles around orgs obsessed with rushing out AI and poor DevOps security.” “Identifying the victims within this 153GB database presents a unique threat intelligence challenge. Accurate attribution requires looking past the surface level to analyze the actual infrastructure boundaries,” Hudson Rock noted. In one case, a leaked pipeline was tied to a committer email at SiriusXM, but infrastructure markers in the same dump, including a self-hosted GitLab instance at gitlab.adswizz.com, pointed to AdsWizz, a SiriusXM subsidiary. Hudson Rock said correct identification depends on “hard infrastructure markers rather than simple committer emails.” A large share of the dumped files have no obvious owner. According to Hudson Rock, some contain database passwords, third-party API keys, and cloud credentials without a company email address, custom domain, or internal server name that could identify the organization they came from. This means organizations may have exposed credentials in the dataset without knowing they are affected. Organizations urged to act before stolen data leaks Hudson Rock is urging organizations using AI proxy infrastructure, third-party CI/CD vulnerability scanners, or downstream AI packages to audit their environments for LiteLLM versions 1.82.7 and 1.82.8 and treat any secrets accessible to the LiteLLM environment as compromised. Organizations should also rotate cloud IAM keys and access tokens, review audit logs for anomalous activity dating back to March 24, and check for unauthorized .pth files and suspicious systemd services. “While we cannot disclose how we obtained this data, it is not leaked anywhere at the moment and is not circulating widely. This makes it a critical window of opportunity for companies to rotate keys and secrets before it eventually leaks, as is the natural cycle of a breach,” Gal added. Despite the scale of the breach, some organizations appear to be treating the exposure with less urgency than the findings warrant. “These creds date from about March. One of the orgs impacted told me they’d rotated them all and it’s a nothingburger, so I looked at their responsible disclosure policy, it allows trying creds, so I tried them all. Almost every one worked. Submitted report. One of the biggest US techcos,” Beaumont wrote. “This magnitude pushes us into a completely new world regarding the type of response required from the cybersecurity industry,” Gal concluded.

More than 2,500 organizations and over 430,000 CI/CD pipelines were affected by the LiteLLM supply chain attack earlier this year, CloudSEK reports. The LiteLLM compromise was disclosed shortly after the supply chain attack on Aqua Security’s Trivy open source vulnerability scanner and was a direct result of it. According to CloudSEK, TeamPCP, the threat actor behind multiple high-profile open source software (OSS) compromises, never targeted LiteLLM directly. The open source Python library and proxy server was compromised after its CI pipeline installed the compromised Trivy version automatically. Two LiteLLM versions, namely 1.82.7 and 1.82.8, were pushed to PyPI, providing the hackers with access to all the information LiteLLM touched. “Trivy, then the [LiteLLM] build system, then the LiteLLM release: one unrevoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure,” CloudSEK notes. “Automated build systems compress time. Once a malicious artifact reaches a registry, scheduled jobs, dependency resolvers, ephemeral runners, developer laptops, and cached layers can copy it rapidly. The forensic and credential-rotation window therefore extends beyond package removal,” the company continues. The modified LiteLLM versions contained malicious code executed on every Python invocation, with no explicit import. The payload ran on all systems where the package was installed. According to CloudSEK, while the affected packages were live for only 40 minutes, the window was long enough for the malicious code to propagate, ultimately exposing 434,000 CI/CD pipelines and impacting over 2,500 organizations. Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX, and Zscaler are only some of the names on CloudSEK’s list. “The 2,500+ company and 434,000 pipeline figures describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised or that every credential was stolen,” CloudSEK says, noting that compromise should be independently verified in each case. The LiteLLM supply chain attack led to broad sensitive information compromise: package publishing credentials, cloud keys, SSH keys, tokens, environment variables, runtime data, and AI provider keys, among others. Hackers could use these secrets to take over accounts, steal data, inject malicious commits, achieve persistence, move laterally, disrupt services, deploy malware, and mount various other types of attacks. Organizations should consider any secret accessible to the LiteLLM library as compromised, including those “present in process memory, injected into the job, stored on disk, or retrievable through an instance metadata service”. Potentially compromised secrets should be validated, then rotated alongside service accounts and sessions, and logs should be reviewed to determine the exposure scope and timeframe. According to CloudSEK, the next major supply chain attack will likely target AI infrastructure, as these systems have become “high-value junctions between data, identity, compute, and autonomous action”. “The incident was not only a software supply chain breach that happened to involve an AI product. It demonstrated that compromising an AI control point can expose the identities and systems around it. Future attacks are likely to target the AI layer precisely because it is connected to everything else,” CloudSEK notes. UPDATE: SOCRadar reported that most of the 2,500 organizations believed to have been affected by the LiteLLM supply chain attack were actually affected earlier, likely via the Trivy incident. Related: Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack Related: New GitHub, PyPI Policies Boost Supply Chain Security Related: Multiple Jscrambler Packages Impacted by Supply Chain Attack Related: More Klue Breach Victims Identified as Hackers Get Hacked

Two malicious LiteLLM releases sat on PyPI for about 40 minutes in March carrying credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from systems that installed them. Threat intelligence firm CloudSEK now says a dataset it obtained, built from roughly 434,000 files the attackers captured, maps potential exposure to more than 2,500 organizations. Those totals are not a victim count. CloudSEK told The Hacker News the material came from confidential intelligence sources and consists of captured loot and log files it assessed as belonging to the campaign, not data gathered from the organizations it names. The files were taken, in other words. CloudSEK has published the dataset as a public lookup, searchable by name or domain and filterable by confidence. Each row gives an organization's name and domain, a count of secrets exposed, a count of runs, and a label reading High or Medium. What a high-confidence match asserts is whose systems each file came from. That verdict keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and the organization's own domain has to appear before a match earns the top rating. Repository namespaces support only a medium-confidence call. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp are among the entries, and none of that establishes that stolen credentials were used, which is why both CloudSEK and LiteLLM tell affected parties to rotate rather than wait for proof. LiteLLM is an open-source AI gateway used to connect applications with multiple model providers. The project identified versions 1.82.7 and 1.82.8 as compromised and said they were live on March 24 from 10:39 UTC for about 40 minutes before PyPI quarantined them, though it tells users to treat any install that day up to 16:00 UTC as suspect. The Hacker News confirmed via PyPI on August 12 that neither version appears in the package's release history, while 1.82.6 and 1.83.0 remain available. The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows. A long-lived secret copied during that window, a static cloud key, an SSH key, or a publishing token, remains usable unless it has since been rotated or revoked. That is why the bureau's guidance is scoped to credentials rather than to the package, and why both it and Aqua tell teams to move away from long-lived tokens toward temporary ones. Version 1.82.8 included a file named litellm_init.pth that Python processes at interpreter startup, so it ran whenever a Python process started in that environment, whether or not anything imported LiteLLM. The compromised packages were designed to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords before encrypting and sending stolen data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project. Unit 42's campaign analysis records the payload reading environment variables that hold model API keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY. That behavior inverts the usual triage question. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it, and the project's advisory notes that an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could deliver it without anyone choosing it. The LiteLLM incident sits inside a wider TeamPCP supply-chain campaign linked to Aqua Security's Trivy scanner. Google tracks TeamPCP as UNC6780. Aqua said attackers retained access after an incomplete credential rotation and, on March 19, force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 release. The ecosystem compromise is tracked as CVE-2026-33634, added to CISA's Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components. Exactly how the malicious LiteLLM releases reached PyPI was disputed across the published accounts. CloudSEK's report said the poisoned build produced and published the releases, LiteLLM's own incident report pointed to a direct PyPI upload that bypassed its official CI/CD workflow, and Unit 42 described attackers targeting PyPI publishing tokens after the Trivy breach. Asked about the discrepancy, CloudSEK pushed back. "These are different stages of the same attack chain, not competing explanations," the company told The Hacker News. Its evidence covers how the credential was obtained, while the LiteLLM and Unit 42 findings cover how it was then used. PyPA's advisory for the malicious releases describes the same sequence: an API token exposed through the compromised Trivy dependency and then used to upload the two versions. BerriAI had not responded to questions about which account its own forensics support at the time of writing. Attribution inside the dataset runs through two independent checks, CloudSEK said. An index assigns each file using CI identity variables, and a separate ownership gate re-derives ownership from the fetched logs and can override that assignment. "If they disagree, the report is withheld," the company said, and the final verdict takes the lower of the two confidence levels. The 434,000 figure counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs. CloudSEK said one captured file is roughly one job execution, but it does not present the total as unique jobs without independent deduplication and verification. The company declined to discuss pre-publication notifications to the named organizations, and would not say whether any disputed its inclusion. The campaign's downstream impact is confirmed even if CloudSEK's scale figures are not. Checkmarx said credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories and the publication of malicious artifacts. Mercor said it was affected by malicious LiteLLM versions and contained unauthorized activity. CERT-EU separately assessed with high confidence that a European Commission AWS account was compromised through the Trivy supply-chain attack, with about 91.7 GB of compressed data exfiltrated. Organizations assessing exposure should take three steps: Check for LiteLLM 1.82.7 or 1.82.8 installations during LiteLLM's March 24 audit window of 10:39 to 16:00 UTC. Rotate any secrets those systems could access. Search their GitHub organizations for repositories named tpcp-docs or docs-tpcp, which the FBI lists as campaign indicators. Aqua's advisory for the CVE notes the malware created these with a tpcp-docs- prefix and uploaded stolen data as a release asset tagged data- , so an exact-name search can miss them.

The group behind March's cascading supply chain attacks on open-source developer tools has been linked to infrastructure attacks dating back to 2020 and the first known self-propagating botnet built from hijacked AI infrastructure. New research published by Oligo Security on August 5 showed that TeamPCP shares domains, malware deployment paths and backend infrastructure with activity previously tracked as TA-NATALSTATUS between 2020 and August 2025. Oligo Security worked with Mandiant and GitLab on the investigation, and GitLab banned the accounts involved. The firm also assessed that TeamPCP ran ShadowRay 2.0, the campaign it documented in November 2025 against exposed Ray clusters, which it had attributed at the time to an actor called IronErn440. A Deployment Framework Reused for Years The strongest infrastructure link identified was masscan[.]cloud, which appears across TA-NATALSTATUS activity, ShadowRay 2.0 and later TeamPCP operations. Certificate transparency records date it to May 11, 2025, and TeamPCP's own GitHub account later listed it as the group's official website. Alongside it, Oligo found the same deployment framework reused for years: a distinctive directory path and a set of staging scripts documented in earlier TA-NATALSTATUS campaigns turning up unchanged in TeamPCP payloads. A compromised Ray cluster logged a download from that infrastructure on July 26, 2025, five months before the TeamPCP name surfaced publicly. The most direct evidence came from GitLab. One IP address received reverse shells from a compromised Ray cluster between October 15 and November 2. All shells terminated on November 2, and between November 2 and 4 the ironern440 account authenticated to GitLab from that same address, which hosted the campaign's tooling. From Cryptojacking to Wiper Oligo's timeline has the operators exploiting internet-facing infrastructure as early as 2020, often with automated and wormable techniques, before expanding into GitHub Actions abuse and token theft. That progression ran through PCPcat, which peaked around Christmas 2025 against React2Shell targets and exposed Docker APIs, and into the March 2026 compromises of Trivy, Checkmarx's KICS and LiteLLM. The infrastructure also broadened beyond exploitation, with subdomains observed supporting credential phishing, payment fraud and Zendesk impersonation. In late March, a second-stage Kubernetes payload gained a destructive branch. The script checked whether the victim system was set to the Iran timezone and, if so, deployed a destructive workload that deleted filesystems and rebooted the machine. Oligo noted that Iranian connectivity was heavily disrupted at the time, limiting visibility into whether it ever executed. Oligo was careful about how far the attribution extends. Whether the continuity reflects a direct rebrand, a shared operator set or close collaboration between related actors cannot be established with certainty, the firm said. What the evidence shows is that TeamPCP continues an existing operational ecosystem rather than being a new group that appeared in late 2025.

PyPI hardens package security with new upload restrictions The Python Package Index (PyPI) now rejects uploads of new files to releases older than 14 days to prevent attackers from poisoning long-stable releases if a project’s publishing tokens or release workflows are compromised. “This change will protect Python users and reduce the amount of “cleanup” work associated with project compromises for PyPI admins. This restriction also means that compromises don’t put releases into an indeterminate and confusing state of both “compromised” and “not compromised”, where only a subset of files could be poisoned with malware,” Seth Larson, Security Developer-in-Residence at Python Software Foundation, explained. PyPI has not defined semantics for releases that stop accepting new files and does not provide an API to determine a release’s status, so users should not rely on either. The project plans to define them after standardizing the Upload 2.0 API and Staged Previews under PEP 694, which proposes an extensible API for uploading files to a Python package index. Community backed the change The proposal originated during discussions around PEP 740 (Digital Attestations) in January 2024 and resumed after the March 2026 compromise of the LiteLLM and Telnyx packages due to a mutable reference in those projects’ use of the Trivy GitHub Action. It was initially postponed because some projects uploaded new files to older releases to add support for newer Python versions. PyPI analyzed the practice and found it was rare. Within the top 15,000 packages, only 56 uploaded a Python 3.14-compatible wheel more than 14 days after the original release, indicating the restriction will affect few projects. PyPI Safety & Security Engineer Mike Fiedler proposed the change, which gained support during discussions at the 2026 Packaging Summit. Participants reached a rough consensus that projects should publish a new package version when adding support for newer Python releases instead of updating an existing release. Larson later implemented the change, and the patch was merged on July 8, 2026.

A default low-privilege account on a LiteLLM proxy can climb to full admin and run code on the server by chaining three vulnerabilities, researchers at Obsidian Security disclosed LiteLLM is a widely deployed open-source AI gateway that brokers calls to more than 100 model providers behind one OpenAI-compatible interface. A server takeover exposes every provider key it holds, the secrets that decrypt its stored credentials, and every prompt and response passing through it. Obsidian rates the full chain CVSS 9.9, in the Critical range. BerriAI, the maintainer, included the complete fix set in LiteLLM v1.83.14-stable, which GitHub lists as released May 2. Upgrade to that release or later to close the three-CVE chain. The three bugs The first link is CVE-2026-47101, an authorization bypass. When a regular user (an internal_user) generates a virtual API key, LiteLLM stores the caller-supplied allowed_routes field without checking it against the user's role. The field is supposed to narrow what a key can do. Instead, the proxy also treats it as a fallback grant, so a non-admin can mint a key with allowed_routes: ["/*"], a wildcard that reaches every route, including admin-only ones. The same unchecked write shows up on the other key-management endpoints, which is why the fix took three pull requests to land. With the route gate bypassed, the handlers behind it become reachable. Several of them assume the gate has already done the screening, which opens two paths. One is CVE-2026-47102, privilege escalation. The /user/update endpoint lets a user edit their own record, but does not restrict which fields they can write. A self-update with user_role: "proxy_admin" is accepted and saved, promoting the caller to full proxy admin. An org_admin can hit this endpoint through a legitimate, intended code path with no bypass required; a default internal_user reaches it after CVE-2026-47101. VulnCheck, which assigned the CVE, scores it 8.7 under CVSS 4.0, 8.8 under 3.1. The other is CVE-2026-40217, a sandbox escape in the Custom Code Guardrail, which compiles and runs admin-supplied Python. The production endpoints ran the code through exec() with no source-level filtering. When exec() gets a globals dict without builtins, Python silently injects the full builtins module, which hands the code import, open, and eval. A plain payload calling os.system was then enough for a reverse shell. A separate path on the /guardrails/test_custom_code playground endpoint, found independently by X41 D-Sec, defeated a regex deny-list through runtime bytecode rewriting. Both ended in server-side code execution. What an attacker gets LiteLLM sits at a chokepoint, so the reach is wide. A full chain exposes the master key, the salt key that decrypts stored credentials, and the database URL. It also exposes every configured provider key, for OpenAI, Anthropic, Gemini, Bedrock, Azure, and the rest. Keys in config or environment are plaintext; keys in the database are encrypted but recoverable with the salt key. Everything sent through the gateway, prompts and responses, becomes readable, which in real deployments is where PII, source code, internal tickets, and pasted secrets end up. If the proxy also runs as a Model Context Protocol (MCP) or agent gateway, OAuth tokens and tool credentials are in scope too. The sharper risk is not what an attacker reads but what they can rewrite. The gateway sits on the wire between an AI agent and the model, so a compromise lets it alter responses in transit. Obsidian demonstrated this against Claude Code routed through a compromised proxy. This is not prompt injection. Instead of persuading the model to misbehave, the attacker uses LiteLLM's built-in callback mechanism, an extension point that fires on every request and never shows up in the admin UI. The callback swaps the model's response for a forged tool call and rewrites the safety-check context so the action reads as approved. In the demo, the developer types one word, hello, and the attacker pops a reverse shell on the developer's machine. Separate from the chain, LiteLLM hands a proxy_admin an intentional code-execution path: its MCP support lets an admin register stdio MCP servers that the proxy launches as local subprocesses. That is a design trade-off rather than a bug, and the patches do not change it, so reaching admin is effectively reaching code execution. Obsidian reproduced a reverse shell this way on v1.88.0. A genuine bug in the same stdio-MCP machinery, CVE-2026-42271, let callers spawn subprocesses through LiteLLM's MCP preview endpoints; it was exploited in the wild and added to CISA's KEV catalog earlier this month. None of this is LiteLLM's first rough stretch this year. In March, a supply-chain compromise backdoored two LiteLLM releases on PyPI, and in April, a critical SQL injection was exploited within 36 hours of disclosure. Obsidian frames the chain here as a disclosed flaw with a working demo, not as exploitation seen in the wild, but the proxy's position keeps making it a target. What to do Upgrade to v1.83.14-stable or later, the first release with the full fix set. Then audit. Re-verify every account holding proxy_admin and treat that role as host-level access. Review every Custom Code Guardrail on the proxy. Check the callbacks loaded from config.yaml under litellm_settings.callbacks, since those never appear in the console and are exactly where a post-RCE attacker would hide. Verify the integrity of the deployed code, not just the config. If exposure is suspected, rotate provider keys, database credentials, and any stored MCP tokens. A compromised proxy does not just leak data. It sits between the agent and the model and can forge the responses that the agent acts on. The chain that gets an attacker there is misplaced trust at every layer: the route gate trusted the caller-supplied field, the handlers trusted the route gate, and nobody actually checked.

Supply-chain attacks are usually discussed after they become visible: a malicious package, a compromised software update, a malicious extension, or a breach involving a trusted vendor. But before an incident reaches that stage, the early warning signs may look much less obvious. In underground forums and marketplaces, supply-chain relevance does not always appear under a clear label. A post may not say “supply-chain attack” at all. It may advertise GitHub access, private repositories, source code, API keys, OAuth tokens, cloud credentials, CI/CD data, or a vendor-related leak. The supply-chain risk comes from where that access sits and what trust relationships it touches. A recent investigation by Flare researchers of underground posts show that while it is very hard to recognize it, there are often early warning signs in the underground for software supply-chain attacks even before they are published in public as incident reports. What is a Software Supply-Chain Attack A software supply-chain attack targets the trusted tools, vendors, software components, services, or processes an organization relies on, instead of attacking the organization directly. In software, this can include compromising a third-party provider, developer account, source-code repository, package registry, CI/CD pipeline, update mechanism, plugin, or SaaS integration. The danger is that once attackers compromise something trusted inside the delivery chain, they may be able to reach downstream customers, users, or internal systems through legitimate-looking access, updates, code, or integrations. When ordinary access becomes supply-chain relevant One of the strongest examples observed by Flare researchers involved a post (see screenshot below) advertising GitHub-related access, including references to developer accounts, private repositories, access material, and source-code exposure. On its own, this may look like a standard access sale. But GitHub access can be more than access to code. It may expose secrets, deployment scripts, package publishing logic, cloud credentials, internal documentation, and CI/CD workflows. That is where the supply-chain angle begins. If attackers gain access to a developer identity or private repository, they may be able to understand how software is built, which dependencies are used, where secrets are stored, and how updates are published. In some cases, that access can enable attacks against customers, downstream users, or other connected systems. The Vercel incident in April 2026 is another useful example because it showed how a compromise involving a trusted third-party AI tool and OAuth-connected SaaS access can create a wider security concern (even when the affected company says sensitive customer data and source code were not accessed). For analysts reviewing underground posts, the relevance is not the incident itself, which was already public, but the type of exposure it represents: trusted integrations, SaaS accounts, internal tools, environment variables, and developer platforms connected through permissions that can be abused if one link in the chain is compromised. This is why underground posts mentioning OAuth access, SaaS tools, environment variables, or developer platforms deserve attention, even when the initial claim is limited or unverified. From GitHub access sales to leaked vendor repositories, the warning signs exist — they're just buried in forums and marketplaces most teams aren't watching. Flare surfaces them before they become incidents. Start Monitoring for Supply-Chain Exposure For Free Source code is not always just intellectual property Flare researchers also reviewed posts involving alleged vendor data and source-code exposure, including claims around Sportradar AG that were later echoed in public reporting on the broader TeamPCP supply-chain campaign. The Sportradar case was linked to a compromised Trivy scanner and included exposure of sensitive operational material such as database passwords, API key and secret pairs, Kafka credentials, and monitoring tokens. That is what makes the case relevant beyond the immediate breach: this kind of data can reveal how a vendor’s systems are connected, which services and integrations are trusted, and which credentials may create risk for partners or customers. In supply-chain investigations, those details matter because the most dangerous part of a leak is not always the stolen database itself, but the access paths and trusted relationships it exposes. A similar point appears in public reporting around TeamPCP and Mistral AI. In May 2026, reports claimed that TeamPCP was selling hundreds of alleged Mistral AI repositories. Mistral disputed parts of the claim, but the case still illustrates why source-code theft should not be viewed only as an intellectual-property issue. Repositories may include credentials, building logic, internal service names, deployment workflows, API documentation, or references to customers and integrations. Even when leaked source code does not provide immediate production access, it can help attackers map the environment and identify future attack paths. Package attacks show how access can scale The same analytical lens applies to package ecosystem incidents. Public reporting on Shai-Hulud (a self-spreading npm supply-chain attack that stole developer secrets and infected trusted packages) showed how compromised npm maintainer accounts and malicious package updates could be used to steal credentials, harvest CI/CD secrets, and propagate across repositories. The significance was not only the malicious code itself, but the way trusted package publishing mechanisms were abused. Discussions around Shai-Hulud-style activity and supply-chain attack competition were also observed. These posts were less concrete as victim leads, but they are useful as threat context. They show that actors are watching public package compromise techniques and discussing how they may be reused, modified, or extended. The LiteLLM supply-chain incident provides another recent example. Public reporting described unauthorized PyPI package publishes connected to a broader compromise path involving developer and CI/CD environments. Because LiteLLM is used as an AI gateway, the incident also shows how supply-chain risk is expanding into AI infrastructure and developer tooling. Developer environments themselves are also becoming attractive targets. Recent reporting around malicious VS Code extensions showed how trusted development tools can become a route into repositories and credentials. Extensions, plugins, and AI coding tools often sit close to source code, terminals, tokens, and internal workflows, making them valuable even when they are not part of production infrastructure. What defenders can take from this The reviewed posts do not prove that every underground access sale is a supply-chain threat. They do show why security teams should ask better questions when they see posts involving source code, developer accounts, SaaS access, API keys, OAuth tokens, package ecosystems, or CI/CD material. The key question is not only, “Was data leaked?” It is also, “Could this access affect how trusted software is built, deployed, updated, or integrated?” For defenders, this means supply-chain monitoring should include more than vulnerability disclosures and package alerts. Organizations should watch for exposed developer credentials, GitHub and GitLab access, package registry tokens, leaked repositories, CI/CD secrets, cloud keys, OAuth grants, and claims involving important vendors or software providers. The value of underground monitoring is in recognizing these early signals before they are framed as a full supply-chain incident. Sponsored and written by Flare.

LiteLLM vulnerability under active attack, CISA warns (CVE-2026-42271) A command injection vulnerability (CVE-2026-42271) in BerryAI’s LiteLLM open-source AI gateway is being exploited by attackers, the US Cybersecurity and Infrastructure Security Agency (CISA) confirmed by adding the flaw to its Known Exploited Vulnerabilities catalog on Monday. About CVE-2026-42271 LiteLLM is an open-source library that provides a unified interface for calling many different large language model APIs using a single (OpenAI) format. It’s used by both developers and enterprises, to avoid vendor lock-in, centrally manage API keys and costs, and route or load-balance AI traffic without rewriting integration code. LiteLLM can be used either by directly integrating the Python SDK (software development kit) in applications, or can be run as a standalone AI gateway / proxy server that teams and organizations can point their apps at. CVE-2026-42271, which was publicly disclosed in April 2026, arises from improper neutralization of special elements used in a command and OS command. “Two endpoints used to preview an MCP server before saving it — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio [Standard Input/Output] transport,” the company’s GitHub advisory explains. “When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process. The endpoints were gated only by a valid proxy API key, with no role check. Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host.” “BadHost” vulnerability lowers the bar for LiteLLM attackers It was initially believed that attackers needed a valid proxy API key to successfully exploit CVE-2026-42271. However, Horizon3.ai researchers confirmed that this requirement can be eliminated if attackers can exploit CVE-2026-48710, an authentication bypass vulnerability dubbed BadHost, which affects Starlette – a lightweight Python web framework that LiteLLM uses to handle HTTP requests. “Successful exploitation allows attackers to: execute arbitrary commands on the LiteLLM host, access model provider credentials, steal API keys and secrets stored by the proxy, move laterally into connected AI infrastructure, [and] compromise downstream systems integrated with the gateway,” they noted, and shared a list of indicators and activity that may point to compromise. CVE-2026-48710 has been fixed in Starlette v1.0.1. LiteLLM is a recurring target A fix for CVE-2026-42271 has been added to v1.83.7 of the LiteLLM library, and includes additional authorization controls (allowing only users with the PROXY_ADMIN role to call the test endpoints) and updated Starlette dependencies. Individuals and organizations using LiteLLM have been advised to upgrade to the fixed version or, if that’s not possible, to block access to the above-mentioned MCP test endpoints, restrict network access to trusted segments, and rotate credentials stored by the proxy. Unfortunately, no details are available about the attack(s) in which CVE-2026-42271 is being leveraged, and no confirmation that attackers are exploiting CVE-2026-48710 at the same time. CISA has directed US federal civilian agencies to address CVE-2026-42271 by June 22, 2026. This is the second time in a month that a publicly disclosed LiteLLM flaw has been weaponized by attackers. In March 2026, BerryAI was also hit with a supply chain attack by TeamPCP, which resulted in the publishing of malicious LiteLLM versions on the Python Package Index (PyPI). Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added a high-severity flaw impacting BerriAI LiteLLM to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The vulnerability, tracked as CVE-2026-42271 (CVSS score: 8.7), is a command injection vulnerability that could allow any authenticated user to run arbitrary commands on the host. It affects the following version of the LiteLLM Python package - >= 1.74.2 < 1.83.7 "Two endpoints used to preview an MCP server before saving it - POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list - accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport," according to a description of the flaw shared by BerriAI. "When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process." The maintainers of the open-source AI gateway and Python SDK said the endpoints were secured only by means of a valid proxy API key, as a result of which any authenticated user, including privileged internal-user keys, could execute arbitrary commands on a susceptible system. As part of the patches released in version 1.83.7, both the test endpoints now require the PROXY_ADMIN role, making it consistent with the save endpoint. LiteLLM Unauthenticated Remote Code Execution via Starlette Host Header Validation Bypass Last week, Horizon3.ai said it chained CVE-2026-42271 with CVE-2026-48710 (CVSS score: 6.5), a "BadHost" host header validation bypass vulnerability affecting Starlette, a lightweight Asynchronous Server Gateway Interface (ASGI) framework, to completely sidestep authentication and achieve remote code execution against vulnerable LiteLLM deployments. "CVE-2026-48710 can be used to bypass the authentication mechanism entirely in LiteLLM deployments whose dependency tree includes Starlette versions ≤ 1.0.0," Horizon3.ai said. "This transforms the vulnerability into unauthenticated remote code execution with no credentials required." Successful weaponization of the exploit chain could allow attackers to run arbitrary commands on the LiteLLM host, access model provider credentials, siphon API keys and secrets stored by the proxy, move laterally into connected AI infrastructure, and even compromise downstream systems integrated with the gateway. Per Horizon3.ai, the chained vulnerability has a combined CVSS score of 10.0, making it critical in nature. There is currently no information on how CVE-2026-42271 is being exploited, the identity of the threat actor(s) behind the efforts, who are targeted, how widespread these attacks are, or if the activity has successfully compromised any instances. It's also unclear if the attacks observed in the wild are leveraging the exploit chain. Users are advised to update LiteLLM to version 1.83.7 or later and Starlette to version 1.0.1 or later. If immediate patching is not an option, the following mitigations are recommended - Block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gateway. Restrict network access to trusted segments. Rotate credentials stored by the proxy. Review logs for unusual Host header activity and subprocess execution events. The development comes a little over a month after a critical SQL injection flaw in LiteLLM (CVE-2026-42208, CVSS score: 9.3) came under active exploitation within 36 hours of the bug becoming public knowledge.

BerriAI heeft kwetsbaarheden verholpen in LiteLLM, specifiek in versies 1.74.2 tot en met 1.83.6. LiteLLM is een veelgebruikte proxy om op gecentraliseerde wijze API's naar een groot aantal LLM systemen te beheren. De eerste kwetsbaarheid betreft een SQL-injectie in het proxy API key verificatiemechanisme, waardoor niet-geauthenticeerde aanvallers SQL-injectieaanvallen kunnen uitvoeren om proxy databasegegevens te lezen en te wijzigen. Dit kan leiden tot het compromitteren van credentials en verdere ongeautoriseerde toegang tot het systeem. De tweede kwetsbaarheid betreft twee preview endpoints in de MCP server feature die volledige serverconfiguraties accepteren. Elke geauthenticeerde gebruiker met een geldige proxy API key kan hiermee willekeurige commando's uitvoeren op de proxy host, zonder dat hiervoor administratieve rechten vereist zijn. Deze kwetsbaarheid maakt ongeautoriseerde command execution mogelijk.

A critical-severity vulnerability in the open source AI gateway LiteLLM was exploited days after public disclosure to access database tables containing sensitive information, Sysdig reports. The security defect is described as an SQL injection during the proxy API key verification process and is identified as CVE-2026-42208, with a CVSS score of 9.3. In an April 20 advisory, LiteLLM’s maintainers explained that a database query used during key verification did not pass the caller-supplied value as a separate parameter, including it in the query instead. This allowed an unauthenticated attacker to send a specially crafted Authorization header to any LLM API route and access the query via the proxy’s error-handling path. “The call happens before authentication (auth) is decided, so the injection is fully pre-auth: any HTTP client that can reach the proxy port is sufficient,” Sysdig notes. By exploiting the issue, the attacker could access the LiteLLM proxy’s database to read and potentially modify data, allowing them to leak credentials stored in the database. On April 24, the advisory was indexed in the GitHub Advisory database, and the first attacks exploiting the flaw were observed 36 hours later, Sysdig says. The cybersecurity firm observed the attackers specifically targeting three database tables containing sensitive information such as API keys, provider credentials, and the proxy’s environment variable configuration. “The operator already knew LiteLLM’s Prisma-generated PostgreSQL identifier casing and ran a textbook column-count discovery sweep against each target table,” Sysdig explains. Despite the targeted nature of the attacks, no continuation was observed, and the extracted keys and credentials have not been abused. The observed attacks, the cybersecurity firm says, were performed 21 minutes apart, likely through an automated tool that used the same payload but rotated the origin IP addresses. “The novelty of this finding is the speed and precision of the schema-enumeration attempt, not a confirmed compromise,” Sysdig notes. LiteLLM version 1.83.7 resolves the vulnerability by ensuring that the caller-supplied value is always passed as a separate parameter. Users are advised to update to the patched release as soon as possible or to disable error logs to mitigate the exploitation path. Related: 38 Vulnerabilities Found in OpenEMR Medical Software Related: Chrome 147, Firefox 150 Security Updates Rolling Out Related: No Patch for New PhantomRPC Privilege Escalation Technique in Windows Related: OpenSSH Flaw Allowing Full Root Shell Access Lurked for 15 Years

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." Update The U.S. Cybersecurity and Infrastructure Security Agency (CISA), on May 8, 2026, added CVE-2026-42208 to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the patches by May 11, 2026.

Hackers are targeting sensitive information stored in the LiteLLM open-source large-language model (LLM) gateway by exploiting a critical vulnerability tracked as CVE-2026-42208. The flaw is an SQL injection issue that occurs during LiteLLM's proxy API key verification step. An attacker can exploit it without authentication by sending a specially crafted Authorization header to any LLM API route. This allows reading data from the proxy's database and modifying it. According to the maintainer's security advisory, threat actors could use it for "unauthorised access to the proxy and the credentials it manages." A fix was delivered in LiteLLM version 1.83.7 to replace string concatenation with parameterized queries. LiteLLM stores API keys, virtual and master keys, and environment/config secrets, so accessing its database allows hackers to read sensitive data they may then use to launch additional attacks. LiteLLM is a popular proxy/SDK middleware layer that enables users to call AI models via a single unified API. The project is widely used by developers of LLM apps and platforms managing multiple models. It has 45k stars and 7.6k forks on GitHub. The project has also recently been targeted in a supply-chain attack, where TeamPCP hackers released malicious PyPI packages that deployed an infostealer to harvest credentials, tokens, and secrets from infected systems. In a report from researchers at Sysdig, a cloud security company, say that CVE-2026-42208 exploitation started approximately 36 hours after the bug was disclosed publicly on April 24. Active exploitation activity The researchers observed deliberate and targeted exploitation attempts that sent crafted requests to ‘/chat/completions’ with a malicious ‘Authorization: Bearer’ header. These requests queried specific tables that contained API keys, provider (OpenAI, Anthropic, Bedrock) credentials, environment data, and configs. Sysdig explained that there were no probes against benign tables, and “the operator went straight to where the secrets live,” a strong indicator that the attacker knew exactly what to target. In the second phase of the attack, the threat actor switched IP addresses, likely for evasion, reran the same SQL injection attempts, but focused on the correct table names and structures derived in the previous phase, now using fewer, more precise payloads. Sysdig comments that, while 36 hours is not as quick as exploiting a recent flaw in Marimo, the attacks were targeted and specific. The researchers warned that exposed LiteLMM instances still running vulnerable versions should be treated as potentially compromised, and every virtual API key, master key, and provider credential stored in internet-exposed LiteLLM instances should be rotated. For those who can’t upgrade to LiteLLM 1.83.7 and later, the maintainers suggest the workaround of setting ‘disable_error_logs: true’ under ‘general_settings’ to block the path through which malicious inputs can reach the vulnerable query. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

SAAS Salesforce partners not seeing meaningful revenue from Agentforce AI platform, report saysShow us the money ai and ml AI companies are burning books, advocates complain to FTCFahrenheit 203, the temperature GPUs stop gorging on literature DEVOPS Go updates may delight diehard gophers but displease AI overlordsv 1.27 expands generics to support methods EDGE AND IOT Waymo has designed a robocar chip to stay ahead of Tesla5 nm ML accelerators promise 1,000+ TOPS, ultra-low latency SYSTEMS AMD inches closer to its goal of making AI suck less ... energyHouse of Zen claims latest systems already 4x more efficient than two years ago Security Russians are posing as Signal support to launch phishing attacksPLUS: US takes down Iranian propaganda sites; Marketing company asks 'Why Do We Have Your Information?' And more! Security Microsoft patches failed to fix on-prem SharePoint, which is now under zero-day attackPLUS: China upgrades smartphone surveillance tools; Ring eases anti-snooping stance; and more Black Hat and DEF CON DEF CON Franklin project enlists hackers to harden critical infrastructureVoting village reports have been so successful, says Jeff Moss, that the whole of DEF CON will now be included Security EQT buys majority share in Swiss cybersecurity biz AcronisWent at equivalent of $3.5B+ valuation for entire firm, though portion sold not specified Malware Month Ten years since the first corp ransomware, Mikko Hyppönen sees no end in sightOn the plus side, infosec's a good bet for a long, stable career FOSS smashed one Microsoft monopoly. After 20 years of failure, it's time to smash anotherWord up GNOME can look like Windows – and Flashback can do it without extensionsNew 'Simple-taskbar' is an option, but there's a simpler, stabler way A moment of silence, please, for the final release of Debian on x86-32New Debian versions hit FOSSland in the form of 13.6 and 12.15 Baddies caught exploiting extensions bugs with perfect 10 scores on vulnerable Joomla websitesFlaws in iCagenda, Balbooa Forms extensions can impact open source CMS that powers a million sites worldwide Frame: A new X11 server – implemented directly in assemblyJoins yserver, Phoenix, and of course XLibre – and outlier Arcan Cinnamon 6.8 will support Wayland – if you want itNext version of Linux Mint’s desktop has both kinds of display server

Bitwarden CLI: rilevata distribuzione di versione malevola tramite attacco alla Supply Chain Bollettino BL01/260424/CSIRT-ITA Sintesi Proseguono le campagne di compromissione che interessano le supply chain, prendendo di mira in questo contesto il componente Bitwarden CLI. L’obiettivo dell’attacco consiste nella distribuzione di una versione malevola del pacchetto attraverso i canali ufficiali di distribuzione e nella conseguente esfiltrazione di credenziali dai sistemi interessati. L’incidente si inserisce nel contesto delle recenti compromissione delle supply chain inerenti ai progetti Trivy, Checkmarx e LiteLLM, come riportato nel Bollettino BL01/260327/CSIRT-ITA. Tipologia Remote Code Execution Information Disclosure Tampering Descrizione e potenziali impatti Nel dettaglio, il 22 aprile 2026 risulterebbe essere stata pubblicata sul registro npm una versione malevola del pacchetto @bitwarden/cli (2026.4.0) – successivamente deprecata e rimossa – contenente del codice malevolo integrato nel pacchetto di distribuzione. Tale codice risulterebbe essere stato progettato per attivarsi automaticamente in fase di installazione/esecuzione del CLI, consentendo l’esfiltrazione di credenziali e segreti (tra cui token GitHub e npm, chiavi SSH e credenziali cloud) dai sistemi interessati. Le funzionalità malevole risultano particolarmente rilevanti in ambienti di sviluppo e pipeline CI/CD, dove il componente è comunemente utilizzato. Sebbene la versione compromessa sia stata rapidamente messa in quarantena, gli utenti che l’abbiano inavvertitamente installata dovrebbero considerare i propri ambienti come potenzialmente compromessi e procedere con le opportune attività di mitigazione. Prodotti e versioni affette Bitwarden CLI, versione 2026.4.0 Azioni di mitigazione Secondo quanto dichiarato dal vendor, risultano impattati esclusivamente gli utenti che hanno installato Bitwarden CLI versione 2026.4.0 tramite npm durante la finestra temporale di esposizione. Qualora ricadenti in tale casistica, si raccomanda di implementare le misure di mitigazione riportate di seguito e nei bollettini disponibili nella sezione Riferimenti. Disinstallare immediatamente la versione compromessa procedere alla rimozione della versione malevola del pacchetto: npm uninstall -g @bitwarden/cli Pulire la cache di npm eliminare eventuali artefatti residui: npm cache clean --force Disabilitare temporaneamente l’esecuzione degli script npm come misura precauzionale durante le attività di bonifica: npm config set ignore-scripts true Verificare gli indicatori e le procedure di cleanup si raccomanda di valutare la verifica e l’implementazione degli IoC[1] forniti dai ricercatori di sicurezza tramite i bollettini riportati nella sezione Riferimenti. Ruotare tutte le credenziali potenzialmente esposte procedere alla rotazione immediata dei segreti di: token API chiavi SSH credenziali e token utilizzati in ambienti di sviluppo e automazione Verificare attività e configurazioni su GitHub e CI/CD esaminare eventuali accessi non autorizzati o modifiche anomale a: repository GitHub workflow CI/CD credenziali e token associati Installare una versione aggiornata e sicura completate le attività di mitigazione, installare la versione corretta del componente: npm install -g @bitwarden/[email protected] [1] Per definizione, non tutti gli indicatori di compromissione sono malevoli. Questo CSIRT non ha alcuna responsabilità per l'attuazione di eventuali azioni proattive (es. inserimento degli IoC in blocklist) relative agli indicatori forniti. Le informazioni contenute in questo documento rappresentano la migliore comprensione della minaccia al momento del rilascio.

SAAS Salesforce partners not seeing meaningful revenue from Agentforce AI platform, report saysShow us the money ai and ml AI companies are burning books, advocates complain to FTCFahrenheit 203, the temperature GPUs stop gorging on literature DEVOPS Go updates may delight diehard gophers but displease AI overlordsv 1.27 expands generics to support methods EDGE AND IOT Waymo has designed a robocar chip to stay ahead of Tesla5 nm ML accelerators promise 1,000+ TOPS, ultra-low latency SYSTEMS AMD inches closer to its goal of making AI suck less ... energyHouse of Zen claims latest systems already 4x more efficient than two years ago Security Russians are posing as Signal support to launch phishing attacksPLUS: US takes down Iranian propaganda sites; Marketing company asks 'Why Do We Have Your Information?' And more! Security Microsoft patches failed to fix on-prem SharePoint, which is now under zero-day attackPLUS: China upgrades smartphone surveillance tools; Ring eases anti-snooping stance; and more Black Hat and DEF CON DEF CON Franklin project enlists hackers to harden critical infrastructureVoting village reports have been so successful, says Jeff Moss, that the whole of DEF CON will now be included Security EQT buys majority share in Swiss cybersecurity biz AcronisWent at equivalent of $3.5B+ valuation for entire firm, though portion sold not specified Malware Month Ten years since the first corp ransomware, Mikko Hyppönen sees no end in sightOn the plus side, infosec's a good bet for a long, stable career FOSS smashed one Microsoft monopoly. After 20 years of failure, it's time to smash anotherWord up GNOME can look like Windows – and Flashback can do it without extensionsNew 'Simple-taskbar' is an option, but there's a simpler, stabler way A moment of silence, please, for the final release of Debian on x86-32New Debian versions hit FOSSland in the form of 13.6 and 12.15 Baddies caught exploiting extensions bugs with perfect 10 scores on vulnerable Joomla websitesFlaws in iCagenda, Balbooa Forms extensions can impact open source CMS that powers a million sites worldwide Frame: A new X11 server – implemented directly in assemblyJoins yserver, Phoenix, and of course XLibre – and outlier Arcan Cinnamon 6.8 will support Wayland – if you want itNext version of Linux Mint’s desktop has both kinds of display server

Nel marzo del 2026, l’incidente che ha coinvolto LiteLLM ha riportato all’attenzione della comunità cyber security un tema noto, ma sistematicamente sottovalutato: la centralità delle workstation degli sviluppatori come nodo critico dell’intera catena di sicurezza. Non si è trattato di un attacco sofisticato contro un’infrastruttura cloud fortemente protetta né di una compromissione zero-day su larga scala, bensì di qualcosa di molto più semplice e, proprio per questo, più pericoloso. Un endpoint, una macchina di sviluppo, un ambiente apparentemente periferico rispetto al cuore dell’infrastruttura. Eppure sufficiente, da solo, a spalancare l’accesso a credenziali, sistemi e dati sensibili. Indice degli argomenti Questo episodio non è isolato, ma si inserisce in un trend ben preciso, che segna un cambiamento strutturale nella natura degli attacchi informatici contemporanei. Il focus si è progressivamente spostato dal perimetro infrastrutturale tradizionale verso il livello umano e operativo, incarnato dalla figura dello sviluppatore e dai suoi strumenti quotidiani. La workstation diventa così non solo un terminale di lavoro, maun aggregatore di privilegi, un repository diffuso di segreti, un nodo di interconnessione tra sistemi eterogenei. Per comprendere appieno la portata dell’incidente LiteLLM è necessario analizzarne la dinamica, ma soprattutto collocarlo in un contesto più ampio, che include la trasformazione dei modelli DevOps, l’adozione massiva del cloud e la crescente dipendenza da credenziali distribuite. L’attacco, secondo quanto emerso, ha sfruttato una debolezza strutturale tipica degli ambienti di sviluppo moderni: la presenza diffusa e spesso incontrollata di segreti in chiaro all’interno delle workstation. File di configurazione, variabili d’ambiente, cronologie di shell, configurazioni IDE e cache applicative costituiscono una superficie di attacco sorprendentemente ampia e, soprattutto, altamente standardizzata. Gli attaccanti non hanno bisogno di tecniche particolarmente avanzate per individuare queste informazioni. Sanno già dove cercare. È proprio questa prevedibilità a rappresentare uno degli elementi più critici. Nel tempo, le pratiche di sviluppo hanno consolidato abitudini operative che, se da un lato facilitano la produttività, dall’altro introducono rischi sistemici. L’utilizzo di file .env per la gestione delle configurazioni sensibili, per esempio, è diventato uno standard de facto. Analogamente, la memorizzazione di token e chiavi all’interno di strumenti di sviluppo o nella cronologia dei comandi è una prassi diffusa, spesso giustificata dalla necessità di rapidità operativa. Il problema è chequeste pratiche trasformano la workstation in una sorta di “vault non gestito”, un archivio di credenziali privo di controlli centralizzati, auditing e rotazione automatica. In questo scenario, la compromissione di una singola macchina non rappresenta più un incidente isolato, ma l’inizio di una possibile escalation verso l’intera infrastruttura. Dal punto di vista tattico, l’attacco osservato nel caso LiteLLM segue una logica coerente con le tecniche descritte nel framework MITRE ATT&CK. L’accesso iniziale avviene a livello endpoint, seguito da una fase di raccolta delle credenziali attraverso file system e configurazioni locali. Una volta ottenuti i segreti, l’attaccante può muoversi lateralmente, accedendo a servizi cloud, repository e pipeline CI/CD. Ciò che emerge con chiarezza è la sproporzione tra lo sforzo richiesto per compromettere una workstation e l’impatto potenziale dell’attacco. In un contesto tradizionale, l’accesso a sistemi critici richiedeva il superamento di più livelli di difesa. Oggi, invece, gran parte di queste barriere viene bypassata implicitamente attraverso le credenziali già presenti sulla macchina dello sviluppatore. Questo fenomeno è strettamente legato all’evoluzione del paradigma DevOps e, più recentemente, DevSecOps. L’integrazione continua, la distribuzione automatizzata e l’utilizzo di infrastrutture cloud hanno reso necessario l’accesso diretto e frequente a risorse sensibili. Gli sviluppatori operano quotidianamente con privilegi elevati, spesso senza una distinzione netta tra ambienti di sviluppo, test e produzione. In questo contesto, la workstation diventa un’estensione operativa dell’infrastruttura, ma senza essere trattata come tale dal punto di vista della sicurezza. Questo è il punto di frattura su cui si innesta l’incidente LiteLLM. La prima implicazione strategica riguarda la ridefinizione del perimetro di sicurezza. Non è più possibile considerare il datacenter o il cloud come l’unico confine da proteggere. Il perimetro si estende fino agli endpoint degli sviluppatori, che devono essere considerati a tutti gli effetti parte dell’infrastruttura critica. Questo cambiamento richiede un ripensamento profondo delle strategie di difesa. Le soluzioni tradizionali, basate su firewall, segmentazione di rete e controllo degli accessi a livello infrastrutturale, risultano insufficienti se non integrate con misure specifiche per la protezione degli endpoint. Un secondo aspetto fondamentale riguarda la gestione dei segreti. L’incidente LiteLLM evidenzia come la distribuzione incontrollata delle credenziali rappresenti uno dei principali fattori di rischio. La presenza di segreti in chiaro su file system locali non è solo una cattiva pratica, ma una vulnerabilità strutturale. ambiamento architetturale e culturale La risposta a questo problema non può limitarsi a interventi puntuali, ma deve tradursi in un cambiamento architetturale. La centralizzazione delle credenziali attraverso sistemi di secret management rappresenta una delle direttrici principali. Soluzioni come CyberArk o HashiCorp Vault consentono di eliminare la necessità di memorizzare segreti localmente, introducendo meccanismi di accesso controllato, auditing e rotazione automatica. Tuttavia, l’adozione di strumenti tecnologici non è sufficiente se non accompagnata da un cambiamento culturale. Gli sviluppatori devono essere consapevoli del ruolo critico delle loro workstation e delle implicazioni delle loro scelte operative. La sicurezza non può essere percepita come un vincolo esterno, ma deve diventare parte integrante del processo di sviluppo. Un ulteriore elemento di riflessione riguarda la gestione dei privilegi. Nel modello attuale, è comune che gli sviluppatori dispongano di accessi ampi e persistenti a diversi sistemi. Questo approccio, sebbene funzionale alla produttività, aumenta significativamente la superficie di attacco. L’introduzione di modelli di accesso basati su privilegi minimi e temporanei rappresenta una possibile soluzione. Il concetto di Just-In-Time access consente di ridurre la finestra temporale durante la quale una credenziale può essere utilizzata, limitando l’impatto di una eventuale compromissione. Parallelamente, è necessario rafforzare le capacità di monitoraggio e rilevamento a livello endpoint. Le soluzioni EDR e XDR devono essere integrate con funzionalità specifiche per l’analisi dei comportamenti anomali legati all’utilizzo delle credenziali. La semplice presenza di una chiave su una macchina non è di per sé indicativa di un attacco, ma il suo utilizzo in contesti inusuali può rappresentare un segnale di compromissione. L’incidente LiteLLM solleva anche questioni più ampie legate alla sicurezza della supply chain. In un ecosistema sempre più interconnesso, la compromissione di un singolo attore può avere effetti a catena su molteplici organizzazioni. Gli sviluppatori, in quanto punto di intersezione tra codice, infrastruttura e servizi, rappresentano un vettore privilegiato per questo tipo di attacchi. In questo scenario, la sicurezza deve essere concepita come un sistema integrato, che coinvolge non solo le infrastrutture e le applicazioni, ma anche le persone e i processi. La protezione delle workstation degli sviluppatori diventa quindi una componente essenziale di una strategia più ampia, che include la gestione delle identità, la protezione dei dati e la resilienza operativa. Un aspetto particolarmente interessante emerso dal caso LiteLLM riguarda la facilità con cui gli attaccanti possono sfruttare informazioni apparentemente innocue. La cronologia dei comandi, ad esempio, può contenere token di accesso utilizzati in precedenza. Le configurazioni degli IDE possono includere credenziali per l’accesso a repository o servizi cloud. Anche file temporanei o backup possono rivelare informazioni sensibili. Questi elementi, presi singolarmente, possono sembrare marginali, ma nel loro insieme costituiscono un quadro completo delle capacità operative di uno sviluppatore. Per un attaccante, è come avere accesso a una mappa dettagliata dell’infrastruttura. La prevenzione di questo tipo di rischio richiede un approccio multilivello, che combini misure tecniche, organizzative e culturali. Dal punto di vista tecnico, è fondamentale implementare sistemi di scansione continua dei segreti, in grado di identificare la presenza di credenziali in chiaro all’interno delle workstation e dei repository. Dal punto di vista organizzativo, è necessario definire policy chiare per la gestione delle credenziali e per l’utilizzo degli strumenti di sviluppo. Questo include la definizione di standard per la configurazione degli ambienti, la gestione degli accessi e la rotazione delle chiavi. Dal punto di vista culturale, è essenziale promuovere una maggiore consapevolezza tra gli sviluppatori, attraverso programmi di formazione e sensibilizzazione. La sicurezza deve diventare una responsabilità condivisa, non delegata esclusivamente ai team dedicati. L’incidente LiteLLM rappresenta un campanello d’allarme per l’intero settore. Non si tratta di un caso isolato, ma di un esempio concreto di una tendenza destinata a consolidarsi. Le workstation degli sviluppatori non sono più un elemento periferico, ma il cuore pulsante della sicurezza moderna. Ignorare questa realtà significa esporsi a rischi sempre più elevati. Al contrario, riconoscerla e adattare di conseguenza le strategie di difesa può rappresentare un vantaggio competitivo significativo. In un mondo in cui il codice è infrastruttura e gli sviluppatori sono i suoi custodi, proteggere le loro workstation equivale a proteggere l’intero sistema. E, come dimostra il caso LiteLLM, basta una singola falla per mettere tutto in discussione.

This is news : A malicious supply chain compromise has been identified in the Python Package Index package litellm version 1.82.8. The published wheel contains a malicious .pth file (litellm_init.pth, 34,628 bytes) which is automatically executed by the Python interpreter on every startup, without requiring any explicit import of the litellm module. There are a lot of really boring things we need to do to help secure all of these critical libraries: SBOMs, SLSA, SigStore. But we have to do them.

This is the sixth update to the TeamPCP supply chain campaign threat intelligence report, "When the Security Scanner Became the Weapon" (v3.0, March 25, 2026). Update 005 covered developments through April 1, including the first confirmed victim disclosure (Mercor AI), Wiz's post-compromise cloud enumeration findings, DPRK attribution of the axios compromise, and LiteLLM's release resumption after Mandiant's forensic audit. This update covers intelligence from April 1 through April 3, 2026. CRITICAL: CERT-EU Confirms European Commission Cloud Breach via Trivy Supply Chain Compromise CERT-EU disclosed on April 2-3, 2026 that the European Commission's Europa web hosting platform on AWS was breached through the Trivy supply chain compromise (CVE-2026-33634). This is the highest-profile governmental victim disclosure to date. Key details from the CERT-EU advisory: Initial access: AWS API keys stolen via the compromised Trivy scanner on March 19 Detection: European Commission Security Operations Center fired alerts on March 24 (5 days after initial intrusion) CERT-EU notified: March 25; access revoked same day Data exfiltrated: 340 GB uncompressed (91.7 GB compressed archive) from the compromised AWS account Email exposure: Approximately 52,000 email-related files (2.22 GB) of outbound communications Scope: 71 clients affected: 42 internal European Commission departments plus 29 other EU entities, meaning at least 30 Union entities were potentially impacted Data publication: ShinyHunters published the stolen data on their dark web leak site on March 28 Lateral movement: CERT-EU confirmed no lateral movement to other Commission AWS accounts was detected Europa.eu websites remained unaffected throughout Analysts assess this disclosure is significant on multiple dimensions. First, it confirms that TeamPCP-harvested credentials reached a major governmental institution, not just private-sector targets. Second, the involvement of ShinyHunters in the data publication raises questions about the credential distribution chain, as ShinyHunters is operationally distinct from TeamPCP's known LAPSUS$ and Vect partnerships. Third, the five-day dwell time between initial access (March 19) and detection (March 24) is consistent with the 24-hour operational tempo that Wiz documented for TeamPCP's post-compromise cloud enumeration. Recommended action: EU institutions and organizations hosted on Europa infrastructure should review CERT-EU's advisory for specific exposure indicators. Organizations with AWS credentials that may have been exposed through the Trivy compromise should treat the EC breach as confirmation that stolen credentials are being actively used against high-value targets. The CERT-EU disclosure timeline (initial access March 19, detection March 24, notification March 25, public disclosure April 2) demonstrates that even well-resourced organizations required five days to detect the intrusion. HIGH: Sportradar AG Breach Details Confirmed: TeamPCP and Vect Joint Operation VECERT reported on April 2, 2026 that the Sportradar AG breach (first claimed as a CipherForce victim in Update 004) has been confirmed as a "systemic compromise" jointly operated by TeamPCP and Vect ransomware. Sportradar is a $4.98 billion Swiss sports technology company. Confirmed breach details: Entry vector: Supply chain via compromised Trivy (CVE-2026-33634) Personal data: Approximately 26,000 users' personal information exposed Athlete records: 23,169 records including names, dates of birth, gender, and nationality Client exposure: Client table listing 161 organizations including ESPN, Nike, NBA Asia, and IMG Arena Credential exposure: 8 production RDS database passwords, 328 platform API key/secret pairs, Kafka SASL credentials, and New Relic monitoring tokens CipherForce ransomware: Listed on the CipherForce shame site with the original 14-15 day publication deadline (approaching approximately April 10-11) This is the first confirmed case of TeamPCP and Vect operating jointly against a single target, validating the dual-track ransomware model documented in earlier updates. The exposure of 161 client organizations including major sports leagues and media companies creates a cascading notification and risk assessment obligation for Sportradar. Recommended action: Organizations with Sportradar business relationships should proactively assess whether their data appears in the exposed client table. The 328 exposed API key/secret pairs create a secondary supply chain risk for Sportradar's integration partners. HIGH: Mandiant Quantifies Campaign Scale: Over 1,000 SaaS Environments, Estimated 500,000 Machines Multiple vendor statements published April 1-2 have provided the first authoritative quantification of the campaign's total blast radius: Mandiant CTO Charles Carmakal stated that Google-owned Mandiant knew of "over 1,000 impacted SaaS environments" actively dealing with cascading effects from the TeamPCP supply chain compromises. Google Cloud researchers warned that "hundreds of thousands of stolen secrets could potentially be circulating" from the credential trove. The Register cited estimates suggesting attackers exfiltrated data and secrets from approximately 500,000 machines total across all victims. Palo Alto Networks Unit 42 identified affected organizations across the US, Europe, Middle East, South Asia, and Australia, spanning financial services, technology, retail, legal, insurance, and education sectors. These numbers move the campaign's assessed scale from qualitative ("thousands of downstream environments," per the FBI alert) to quantitative. The 1,000+ SaaS environments figure is particularly significant because it implies credential exploitation is ongoing across a far larger surface than the handful of publicly named victims suggests. Recommended action: Organizations that have not yet completed credential rotation should treat the Mandiant quantification as definitive evidence that delayed rotation increases exposure to an actively exploited credential pool of industrial scale. MEDIUM: Elastic Security Labs Publishes Container Attack Detection Guide with MITRE ATT&CK Mapping Elastic Security Labs published a new technical resource, "Linux & Cloud Detection Engineering: TeamPCP Container Attack Scenario," providing a full walkthrough of TeamPCP's multi-stage container compromise methodology. This is distinct from Elastic's earlier axios supply chain compromise detections covered in Update 005 and focuses specifically on the TeamPCP toolchain. New technical details documented: Tunneling tools: TeamPCP uses frps (fast reverse proxy) and gost for establishing persistent tunnels and proxying through compromised container environments React2Shell: A web server exploitation technique used for initial foothold in containerized workloads D4C telemetry: Full detection walkthrough using Elastic's Defend for Containers telemetry MITRE ATT&CK mapping: Each stage of the container attack chain mapped to specific ATT&CK techniques, providing structured detection logic Recommended action: SOC teams operating containerized workloads should review the Elastic guide for detection rules specific to TeamPCP's container attack methodology. The frps and gost indicators are new IOCs not previously documented in the campaign's public reporting. MEDIUM: Mercor Breach Triggers Class Action Investigations The Mercor AI breach (first confirmed in Update 005) has escalated beyond incident response into legal proceedings. Shamis & Gentile P.A. has launched a class action investigation into Mercor's data breach, focusing on the exposure of contractor and customer data including biometric identity verification materials (passports and video interviews). Additional context that emerged April 1-2: Fortune reported Mercor is valued at $10 billion (raised $350M Series C in October 2025) Mercor's customers confirmed to include Anthropic, OpenAI, and Meta LAPSUS$ published samples including Slack data, internal ticketing records, and two videos of AI-contractor conversations Data is listed for live auction on the dark web The class action investigation introduces a legal dimension to the campaign's downstream consequences. The exposure of biometric identity verification materials (passports) for an estimated 30,000+ AI contractors raises GDPR, CCPA, and potentially BIPA obligations. INFO: New Vendor Publications and Analysis Several new vendor publications appeared in the April 1-3 window: Datadog Security Labs published a detailed technical trace of the full LiteLLM and Telnyx PyPI compromise chain, tracing it back to the March 19 Trivy origin and recommending that any host that installed compromised versions be treated as a "full-credential exposure event." Oligo Security published "Evolution of Modern Supply Chain Attacks," documenting TeamPCP's credential harvesting timeline and framing the campaign as a "meaningful shift" in how sophisticated actors approach supply chain as an attack surface. The New Stack (April 2) published "The CI/CD Pipeline Is the New Front Line," positioning TeamPCP as a watershed moment for CI/CD pipeline security. CYFIRMA Weekly Intelligence Report (April 3) covered the campaign, noting the Europa hosting platform impact and the 71 affected clients. INFO: Supply Chain Pause Extends to Approximately 16 Days No new package compromises have been reported since the Telnyx PyPI disclosure on March 27. The supply chain pause is now approximately 384 hours (16 days), doubling the 192-hour pause reported in Update 005. Independent searches of RubyGems, crates.io, and Maven Central continue to show zero TeamPCP-related IOCs. The campaign remains confined to five ecosystems: GitHub Actions, PyPI, npm, Docker Hub/GHCR, and OpenVSX. The CISA KEV remediation deadline for CVE-2026-33634 is now 5 days away (April 8, 2026). Watch Item Status

APERION releases SmartFlow SDK for secure, on-prem AI governance without cloud reliance APERION launched SmartFlow SDK, providing a secure, on-premises path for enterprises migrating away from compromised cloud-based AI gateways. The launch coincides with a 200% increase in web traffic since the March 24 LiteLLM supply chain attack that compromised an estimated 36% of all cloud environments. LiteLLM was the victim of a supply chain attack in which the threat actor group TeamPCP compromised the most widely used open-source LLM proxy in the Python ecosystem through a cascading breach of Aqua Security’s Trivy vulnerability scanner. The compromise has forced enterprises across financial services, healthcare, and defense to urgently reassess their AI infrastructure dependencies. The entire LiteLLM package, with approximately 95 million monthly downloads, remains quarantined on the Python Package Index. APERION’s flagship product, SmartFlow, is an on-premises, Kubernetes-native AI governance control plane that was architecturally unaffected by the incident. SmartFlow is deployed as a software appliance behind the enterprise firewall, with no dependency on public package registries, no cloud data transit, and no external CI/CD pipelines in the customer deployment path. “The LiteLLM supply chain attack is the AI era’s SolarWinds or NotPetya moment. It validates what we have been building toward since day one: regulated enterprises cannot govern their AI from the cloud,” said Craig Alberino, CEO of APERION. “In the week since the breach, we have seen a 200% increase in web traffic from enterprises searching for LiteLLM alternatives and AI gateway security. These are not startups. These are institutions that define what production-grade means in financial services and healthcare. AI governance infrastructure is an estimated $40 to $50 billion market opportunity, and enterprises are now making purchasing decisions based on deployment model and supply chain security, not just features.” SmartFlow is in production with paying enterprise customers including DDA, the leading AI-powered commercial real estate investment due diligence platform, which has achieved 99.999% uptime over four months of continuous operation. Active evaluations are underway at multiple Fortune 500 institutions in financial services. The company holds 22 patent positions covering enterprise AI governance, sovereign model deployment, and autonomous AI control plane architecture. The SmartFlow SDK, also released this week, is a Python library providing enterprise developers an immediate path from evaluation to production-grade AI governance. The SDK detects whether a SmartFlow appliance is available and configures accordingly: full enterprise features with an appliance, or a standalone software gateway with feature parity to LiteLLM and OpenRouter without one. APERION has also published a migration whitepaper for organizations transitioning from compromised or discontinued AI gateway dependencies. “The March 2026 supply chain attack was not an anomaly. LiteLLM had 17 or more CVEs before this incident,” said Scott Ancheta, CTO of APERION. “When your AI governance layer depends on a public package registry and an unaudited CI/CD pipeline, you are not running enterprise-grade infrastructure. SmartFlow was built from the ground up as a governed appliance because we understood that the deployment model is the security model. Our Rust-based infrastructure delivers sub-5 millisecond routing overhead and our MetaCache semantic caching achieves 55% to 75% hit rates at p95 latency on production hardware. These are published, verifiable benchmarks from NVIDIA GTC 2026.” SmartFlow is deployed on-premises as a Kubernetes-native software appliance, storing zero customer data by design. The platform integrates with enterprise identity providers including Entra ID, LDAP, SAML, and OIDC for per-user audit trails and compliance-ready reporting. SmartFlow’s no-code policy engine maps to EU AI Act, NIST AI RMF, FINRA, SEC, OCC, and HIPAA requirements. The company estimates the AI governance infrastructure market at $40 to $50 billion, representing 5% to 15% governance capture of overall AI infrastructure spend.

Software supply chain hacks trigger wave of intrusions, data theft After linking the Axios npm supply chain attack to North Korean hackers, Google researchers warned that “hundreds of thousands of stolen secrets could potentially be circulating” as a result of this and the Trivy, KICS, LiteLLM, and Telnyx supply chain attacks (linked to TeamPCP). “This could enable further software supply chain attacks, software as a service (SaaS) environment compromises (leading to downstream customer compromises), ransomware and extortion events, and cryptocurrency theft over the near term,” they added. TeamPCP exploits stolen secrets for cloud intrusions Google-owned cloud security company Wiz has responded to multiple attacks being carried out by TeamPCP. “[The Wiz Customer Incident Response Team (CIRT)] saw indications in Cloud, Code, and Runtime evidence that the credentials and secrets stolen in the supply chain compromises were quickly validated and used to explore victim [cloud] environments and exfiltrate additional data,” they said. “While the speed at which they were used suggests that it was the work of the same threat actors responsible for the supply chain operations, we are not able to rule out the secrets being shared with other groups and used by them.” Tech firm OwnCloud stated last week that it had been affected by the Trivy compromise and their ability to ship new builds of and patches for their software solutions “is temporarily suspended.” Mercor, a startup that connects human experts with companies building AI, confirmed on Wednesday that it was affected by the LiteLLM supply chain attack. The company said it is “one of thousands of companies” impacted and its security team and third-party forensics experts are still investigating the incident. Though the Lapsus$ cyber extortion group claimed to have accessed the company’s databases and source code, Mercor has yet to disclose the extent of the impact/breach. The connection between TeamPCP and Lapsus$ has been documented. Evidence from Lapsus$’s Telegram channel indicates they had prior knowledge of TeamPCP’s planned supply chain attacks. TeamPCP has also apparently partnered with the Vect ransomware-as-a-service operation, and is professedly working on spinning up its own RaaS program called CipherForce. Axios compromise affected organizations around the world Axios is one of the most widely used JavaScript libraries out there, and the Axios npm supply chain compromise is expected to have a widespread impact. “With over 100 million weekly downloads across both [affected] branches [of Axios npm], the blast radius of a three-hour compromise window is significant,” Tenable researchers noted. Palo Alto Networks reports that this supply chain compromise has affected organizations across the US, Europe, Middle East, South Asia and Australia, operating in a variety of industries: financial services, high-tech, retail, professional and legal services, insurance, higher education, customers service, and more. The attack resulted in a remote access trojan being installed on Windows, macOS and Linux systems, allowing operators to perform system reconnaissance and drop and execute additional binary payloads and commands. The North Korean group (UNC1069) behind the Axios breach is known for using social engineering to trick people – especially in crypto, DeFi, software, and VC firms – into installing malware, which matches how the Axios maintainer said his system was compromised. Historically, they have been financially motivated. “While UNC1069 has had a smaller impact on cryptocurrency heists compared to other groups like UNC4899 in 2025, it remains an active threat targeting centralized exchanges and both entities and individuals for financial gain,” Mandiant researchers noted earlier this year. UPDATE (April 3, 2026, 09:05 a.m. ET): CERT-EU says that the initial access vector in the recent European Commission cloud breach was the Trivy supply-chain compromise. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

AI recruiting firm Mercor has disclosed impact from the recent LiteLLM supply chain attack, after extortionists claimed the theft of 4 terabytes of data. The LiteLLM incident occurred on March 27 and was the result of the Trivy supply chain attack that was mounted a week before. “We believe that the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow,” LiteLLM notes in its description of the incident. Using a maintainer’s compromised credentials, the TeamPCP hacking group published two malicious LiteLLM PyPI package versions, namely 1.82.7 and 1.82.8, which were available for download for roughly 40 minutes. LiteLLM is estimated to be present in 36% of cloud environments, and while the exposure window appears small, the malicious package versions were likely automatically downloaded by thousands, including Mercor. “We recently identified that we were one of thousands of companies impacted by a supply chain attack involving LiteLLM,” the startup said on Wednesday. “Our security team moved promptly to contain and remediate the incident. We are conducting a thorough investigation supported by leading third-party forensics experts,” Mercor added. While the company has not shared details on the impact, the Lapsus$ extortion group listed Mercor on its leak site on Monday, claiming the theft of over 4TB of data. Lapsus$ is auctioning the information, which allegedly includes candidate profiles, personally identifiable information, employer data, user accounts and credentials, video interviews, proprietary information, source code, keys and secrets, and TailScale VPN data. TeamPCP was recently reported to have partnered with Lapsus$ to monetize the data and access obtained as part of its broad supply chain campaign, and it is no surprise that the extortion group has listed Mercor on its leak site. However, the company has yet to confirm Lapsus$ claims. SecurityWeek has emailed Mercor for a statement on the matter and will update this article if the company responds. Related: Stolen Logins Are Fueling Everything From Ransomware to Nation-State Cyberattacks Related: TeamPCP Moves From OSS to AWS Environments Related: Axios NPM Package Breached in North Korean Supply Chain Attack Related: Toy Giant Hasbro Hit by Cyberattack

SYSTEMS AMD inches closer to its goal of making AI suck less ... energyHouse of Zen claims latest systems already 4x more efficient than two years ago Google pits Marvell against Broadcom as it chases AI crownAnd Marvell just offered the Chocolate Factory a $12.2B stake to sweeten the deal SYSTEMS Cerebras CS-4 rack systems juice chips for every last drop of AI performanceNext-gen systems double per-chip performance while cramming 3x as many into a rack Security Copilot tricked into telling reseachers how to hack itselfHow to social engineer an AI's reasoning engine AI and ml Payments giant Stripe is about to drop over $7 billion to become a gateway to AI token salesAI gateways look promising as companies struggle with model orchestration Security Russians are posing as Signal support to launch phishing attacksPLUS: US takes down Iranian propaganda sites; Marketing company asks 'Why Do We Have Your Information?' And more! Security Microsoft patches failed to fix on-prem SharePoint, which is now under zero-day attackPLUS: China upgrades smartphone surveillance tools; Ring eases anti-snooping stance; and more Black Hat and DEF CON DEF CON Franklin project enlists hackers to harden critical infrastructureVoting village reports have been so successful, says Jeff Moss, that the whole of DEF CON will now be included Security EQT buys majority share in Swiss cybersecurity biz AcronisWent at equivalent of $3.5B+ valuation for entire firm, though portion sold not specified Malware Month Ten years since the first corp ransomware, Mikko Hyppönen sees no end in sightOn the plus side, infosec's a good bet for a long, stable career FOSS smashed one Microsoft monopoly. After 20 years of failure, it's time to smash anotherWord up GNOME can look like Windows – and Flashback can do it without extensionsNew 'Simple-taskbar' is an option, but there's a simpler, stabler way A moment of silence, please, for the final release of Debian on x86-32New Debian versions hit FOSSland in the form of 13.6 and 12.15 Baddies caught exploiting extensions bugs with perfect 10 scores on vulnerable Joomla websitesFlaws in iCagenda, Balbooa Forms extensions can impact open source CMS that powers a million sites worldwide Frame: A new X11 server – implemented directly in assemblyJoins yserver, Phoenix, and of course XLibre – and outlier Arcan Cinnamon 6.8 will support Wayland – if you want itNext version of Linux Mint’s desktop has both kinds of display server

Mercor confirms security incident tied to LiteLLM supply chain attack A platform that helps AI industry leaders improve their models on Wednesday confirmed a security incident tied to a recent supply chain attack. The startup, Mercor, was one of thousands of firms to be impacted by the security compromise of the open-source effort LiteLLM, according to a company statement. Mercor is a popular recruiting outfit that works with companies including OpenAI to hire experts and train AI models. As of October 2025, the company was reportedly valued at $10 billion. “The privacy and security of our customers and contractors is foundational to everything we do at Mercor,” Mercor spokesperson Heidi Hagberg said in a statement. “Our security team moved promptly to contain and remediate the incident.” Mercor is conducting an investigation with the help of outside forensics experts, the statement added. TechCrunch was first to report Mercor’s confirmation of the security incident. Although the LiteLLM attack was reportedly tied to a group called TeamPCP, the hacking gang Lapsus$ claimed on its website that it obtained hundreds of gigabytes of Mercor’s data. Hagberg did not immediately respond to questions about Lapsus$’s claims. LiteLLM confirmed the hack on its systems last week, saying it was “investigating a suspected supply chain attack involving unauthorized PyPI package publishes.” The open-source project said evidence indicated that a user’s PyPI account may have been “compromised and used to distribute malicious code.” A clean version of LiteLLM was released Monday, according to a LiteLLM security post. Jonathan Greig contributed reporting. Suzanne Smalley is a reporter covering digital privacy, surveillance technologies and cybersecurity policy for The Record. She was previously a cybersecurity reporter at CyberScoop. Earlier in her career Suzanne covered the Boston Police Department for the Boston Globe and two presidential campaign cycles for Newsweek. She lives in Washington with her husband and three children.

PyPI�Ō��J����Ă��郉�C�u�����[�ulitellm�v�̓���łɕs���R�[�h�����������B���p�ɂ���ĔF�؏��̐ގ��K8s�ւ̉��W�J�A�i���I�ȃo�b�N�h�A�ݒu���\�ɂȂ�Ƃ����B���p���̒�������єF�؏��̍X�V���������������B ���̋L������������ł��B����o�^����ƑS�Ă������������܂��B �@Endor Labs��2026�N3��24���i���n���ԁj�APython�p�b�P�[�W���|�W�g���[�uPyPI�v�Ō��J���ꂽ�ulitellm�v�̓���o�[�W�����ɕs���R�[�h���������Ă����Ɣ��\�����B �@�Ώۂ̓o�[�W����1.82.7�����1.82.8�ŁA������������uGitHub�v���|�W�g���[�ɂ͑��݂��Ȃ������m�F���ꂽ�Blitellm�́A�����̑�K�͌��ꃂ�f���iLLM�j�T�[�r�X��P���API�ň����郉�C�u�����[�ł���A����9500����ȏ�̃_�E�����[�h���L�^����ȂǁA�L�����p����Ă���B �@���̃R�[�h�́A�p�b�P�[�W���́uproxy_server.py�v�ɑ}������Ă����B���W���[���ǂݍ��ݎ��Ɏ��s�����d�g�݂ŁA���[�U�[����Ȃ��Ƀy�C���[�h���N������B1.82.8�ł́u.pth�v�t�@�C�����d���܂�Ă���APython�N�����Ɏ������s����邽�߁A�Y�����C�u�����[�ڎg�p���Ȃ��Ƃ��U������������B �@�y�C���[�h��3�i�K�ō\�������B��1�i�K�ł̓I�[�P�X�g���[�V�������������s����A��2�i�K�ŔF�؏����W�v���O�������N������BSSH����N���E�h�F�؏��AKubernetes�V�[�N���b�g�A���ϐ��t�@�C���A�Í����Y�E�H���b�g�ȂǍL�͂ȃf�[�^�����W�ΏۂƂȂ�B���W�f�[�^�͈Í�������A�U���҂��Ǘ�����h���C���ɑ��M�����B �@�uKubernetes�v���ɂ����ẮA�e�m�[�h�ɓ���Pod��W�J���邱�Ƃʼn��W�J�����{����B����ɂ��z�X�g�t�@�C���V�X�e���փA�N�Z�X���A����Ȃ�N�����\�ƂȂ�B��3�i�K�ł�systemd�T�[�r�X�Ƃ��ăo�b�N�h�A���ݒu����A���Ԋu�ŊO���T�[�o����lj��̎��s�t�@�C�����擾����d�g�݂����������B �@���͂̌��ʁA���̍U���́uTeamPCP�v�ƌĂ��U���O���[�v�ɂ����̂ƍ����m�x�œ��肳�ꂽ�B���O���[�v�͒���1�J���Ń\�t�g�E�F�A�����Ԃ�W�I�Ƃ�����A�̍U����W�J���Ă���A�uGitHub Actions�v�uDocker Hub�v�unpm�v�uOpenVSX�v�uPyPI�v�ƕ����̃G�R�V�X�e���ɐN�����Ă���B�ߋ��ɂ͐Ǝ�i�������Ⴍ�j���X�L���i�[�uTrivy�v��IaC��̓c�[���uKICS�v�ւ̐N�Q���m�F����Ă���B �@�U����@�͈�т��Ă���A�N�Q����������F�؏����擾���A���̕W�I�ɐN������A���^�̓W�J������Ƃ���B���ɃZ�L�����e�B�֘A�c�[����C���t���n�\�t�g���_���Ă���A����炪���������A�N�Z�X�����p���邱�ƂŌ����I�ɉe���͈͂��g�債�Ă���B �@����̎��Ăł�PyPI�̃p�b�P�[�W���̂̐������`�F�b�N�����蔲���邽�߁A�������Ƀ��^�f�[�^���Đ�������Ă����B���W�X�g���[�����̌������ł͌��o������ł���A�z�z���ƃ\�[�X�R�[�h�̔�r���L���ȑ�ƂȂ�B �@Endor Labs�́A�Y���o�[�W�����̍폜���m�F�ς݂ł���Ƃ�����ŁA���p���̒����ƔF�؏��̑S�ʓI�ȍX�V�������������Ă���B���ɉe�������\���̂�����ɂ����ẮA�N���E�h���i����API�L�[�ASSH���Ȃǂ̍Ĕ��s���K�v�ƂȂ�B Copyright © ITmedia, Inc. All Rights Reserved.

Google links axios supply chain attack to North Korean group Hackers connected to North Korea are responsible for the recent compromise of a wildly popular library used in both front-end apps and back-end systems, according to new researcher. On Monday evening, news emerged that hackers launched a supply chain attack targeting the HTTP client axios, which is downloaded 100 million times each week and embedded across frontend frameworks, backend services and enterprise applications. Google Threat Intelligence Group (GTIG) joined several other researchers in attributing the attack to a North Korean threat actor they call UNC1069. SentinelOne found the same group using macOS-based malware in attacks dating back to 2023. Last month, the financially-motivated group was accused of targeting a cryptocurrency company with several unique pieces of malware deployed alongside multiple scams, including a fake Zoom meeting. Several other researchers backed Google’s assessment because the backdoors used during the axios attack resemble WAVESHAPER, a strain of malware North Korean actors used during the fake Zoom campaign. John Hultquist, chief analyst at Google Threat Intelligence Group, said the axios incident is unrelated to another recent supply chain attack that caused alarm among security experts due to its widespread nature. Hultquist noted that North Korean hackers “have deep experience with supply chain attacks, which they’ve historically used to steal cryptocurrency.” A 2023 supply-chain attack on the enterprise phone company 3CX was attributed to North Korean hackers. “The full breadth of this incident is still unclear, but given the popularity of the compromised package, we expect it will have far reaching impacts,” Hultquist said. Experts raised alarms early on Tuesday morning when two malicious versions of the axios package were published on the Node Package Manager (npm). Security companies Socket and StepSecurity confirmed the packages were malicious and traced the incident back to the hijacking of the lead axios maintainer’s npm account. Socket said the malicious package deploys a multi-stage payload, including a “remote access trojan (RAT) capable of executing arbitrary commands, exfiltrating system data, and persisting on infected machines.” “When the attack first happened, axios maintainers were unable to regain control of the project. In a public GitHub issue, a collaborator stated they could not revoke access from the account responsible for the malicious publish, noting that the attacker’s permissions exceed their own,” Socket explained. Axios is among the most popular JavaScript HTTP client libraries and is used by developers to connect apps to the internet. StepSecurity said that this is “among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.” The malicious version injects a new dependency that installs the malware, which impacts Windows, macOS and Linux. After executing, the malware deletes itself and replaces it with a clean version of the tool to evade detection, StepSecurity added. “There are zero lines of malicious code inside axios itself, and that's exactly what makes this attack so dangerous,” the researchers said. The incident marks the latest in a string of compromises involving the software supply chain, which is increasingly tied together through code pulled in from outside sources. Last week’s attack on the widely used open-source Python package LiteLLM allowed cybercriminals to breach several organizations. Previous incidents involving XZ Utils and self-replicating worm Shai-Hulud stood out among a sea of research uncovering more and more npm packages that have been corrupted. Mandiant CTO Charles Carmakal said the number of recent software supply chain attacks is overwhelming. “The secrets stolen over the past two weeks will enable more software supply chain attacks, software-as-a-service environment compromises (leading to downstream customer compromises), ransomware and extortion events, and crypto heists over the next several days, weeks, and months,” he said. “We are aware of hundreds of thousands of stolen credentials. A variety of actors with varied motivations are behind these attacks. The blast radius of yesterday's axios npm supply chain attack is broad and extends to other popular packages that have dependencies on it.” Mike Puglia, a security leader at Kaseya, said the incidents are further evidence of the fragility of the world's software ecosystem. “In this case, the attacker compromised one single account, the maintainer of axios, and the malicious code was ‘live’ for almost three hours before discovery. On a typical day, that could mean tens of thousands of organizations received the malware,” Puglia said. To further complicate matters, after the attacker's remote access was deployed, the malware replaced itself with the legitimate axios files, making it difficult to know if you were compromised, he added. Several other experts warned that the recent attacks on axios and LiteLLM would be templates for other hackers to replicate. Jonathan Greig is a Breaking News Reporter at Recorded Future News. Jonathan has worked across the globe as a journalist since 2014. Before moving back to New York City, he worked for news outlets in South Africa, Jordan and Cambodia. He previously covered cybersecurity at ZDNet and TechRepublic.

Cisco has suffered a cyberattack after threat actors used stolen credentials from the recent Trivy supply chain attack to breach its internal development environment and steal source code belonging to the company and its customers. A source, who asked to remain anonymous, told BleepingComputer that Cisco's Unified Intelligence Center, CSIRT, and EOC teams contained the breach involving a malicious "GitHub Action plugin" from the recent Trivy compromise. The attackers used the malicious GitHub Action to steal credentials and data from the company's build and development environment, impacting dozens of devices, including some developer and lab workstations. While the initial breach has been contained, BleepingComputer was told that the company expects continued fallout from the follow-on LiteLLM and Checkmarx supply chain attacks. As part of the breach, multiple AWS keys were reportedly stolen and later used to perform unauthorized activities across a small number of Cisco AWS accounts. Cisco has isolated affected systems, begun reimaging them, and is performing wide-scale credential rotation. BleepingComputer has learned that more than 300 GitHub repositories were also cloned during the incident, including source code for its AI-powered products, such as AI Assistants, AI Defense, and unreleased products. A portion of the stolen repositories allegedly belongs to corporate customers, including banks, BPOs, and US government agencies. Multiple sources told BleepingComputer that more than one threat actor was involved in the Cisco CI/CD and AWS account breaches, with varying degrees of activity. BleepingComputer contacted Cisco with questions regarding the breach, but has not received a reply to our emails. The Trivy supply chain attack Cisco's breach was caused by this month's Trivy vulnerability scanner supply chain attack, in which threat actors compromised the project's GitHub pipeline to distribute credential-stealing malware through official releases and GitHub Actions. That attack enabled the theft of CI/CD credentials from organizations using the tool, giving attackers access to thousands of internal build environments. Security researchers linked these supply chain attacks to the TeamPCP threat group based on the use of their self-titled "TeamPCP Cloud Stealer" infostealer. TeamPCP has been conducting a series of supply chain attacks targeting developer code platforms, such as GitHub, PyPi, NPM, and Docker. The group also compromised the LiteLLM PyPI package, which impacted tens of thousands of devices, and the Checkmarx KICS project to deploy the same information-stealing malware. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Hackers hijacked the npm account of the Axios package, a JavaScript HTTP client with 100M+ weekly downloads, to deliver remote access trojans to Linux, Windows, and macOS systems. According to reports from software supply chain security and application security companies Endor Labs, Socket, Aikido, and StepSecurity, the threat actor published on the Node Package Manager (npm) registry two malicious versions of the package One malicious variant, [email protected], was published today at 00:21 UTC, while the second one, [email protected], emerged less than an hour later, at 01:00 UTC. The packages were published without the automated OpenID Connect (OIDC) package origin and no matching GitHub commit appeared, which should trigger an alert immediately. The researchers say that the threat actor gained access to the package after compromising the npm account of Jason Saayman, the main Axios maintainer. The OpenSourceMalware research community says that the attacker also took control of Saayman's GitHub account and changed the associated email to [email protected], then removed a report about the compromise to which project collaborator DigitalBrainJS was trying to reply. It is unclear how many downstream projects have been impacted by the supply-chain attack during the nearly three-hour exposure window. Given that the Axios npm package has around 400 million monthly downloads, the number may be significant. Axios is an HTTP client for JavaScript applications that manages requests between clients, such as browsers or Node.js apps, and servers. Its purpose is to simplify communication via GET, POST, PUT/PATCH, and DELETE requests. Infection chain After getting access to the package, the attacker injected a malicious dependency called plain-crypto-js@^4.2.1 into the package.json file and did not alter the Axios code. The dependency executes a post-install script during the package’s installation, launching an obfuscated dropper (setup.js) that contacts a command-and-control (C2) server to retrieve a next-stage payload based on the detected operating system. On Windows, the attack mixes VBScript and PowerShell to run a hidden Command Prompt window and execute a malicious script. The malware copies PowerShell to %PROGRAMDATA%\wt.exe to evade detection and achieve persistence across reboots, then downloads and executes a PowerShell script. On macOS, the malware uses AppleScript to download a binary to /Library/Caches/com.apple.act.mond, mark it as executable, and run it in the background. On Linux systems, the dropper fetches a Python-based payload stored at ‘/tmp/ld.py’ and executes it in the background with the nohup (no hang up) command. In all cases, the malware infected the host with a remote access trojan (RAT), allowing attackers to execute commands and maintain persistence on infected systems. The RAT can retrieve and execute a base64-encoded binary that it writes in a hidden temp file, execute shell commands via /bin/sh or AppleScript, and enumerate directories on the infected host. After the infection is completed, the dropper deletes itself, removes the modified package.json, and replaces it with a clean copy to make forensic investigations more difficult. According to researchers at StepSecurity, the Axios supply-chain attack was not opportunistic, but a carefully planned activity, as "the malicious dependency was staged 18 hours in advance." The fact that different payloads were delivered based on the detected operating system appears to support this theory, along with the self-destruct action for every artifact. John Hultquist, chief analyst at Google Threat Intelligence Group (GTIG) told BleepingComputer that behind the Axios package compromise is a North Korean actor tracked internally as UNC1069 and known to target "centralized exchanges (CEX), software developers at financial institutions, high-technology companies, and individuals at venture capital funds." A security researcher says that the macWebT name of the macOS RAT is a direct reference to malware used by the BlueNoroff hackers in campaigns observed by SentinelOne in 2023. BlueNoroff is a North Korean threat group specialized in financially-motivated cyberattacks. The actor has targeted banks, financial institutions, and cryptocurrency exchanges. Currently, there is no clear information about the threat actor behind the Axios supply-chain attack. Recently, several high-profile supply-chain attacks were claimed by a group known as TeamPCP. The hackers targeted popular open-source software projects like Telnyx, LiteLLM, and Trivy. However, the compromise of the Axios package does not have the characteristics of a TeamPCP attack, and security researchers couldn’t link it to a specific threat actor. Indicators of compromise (IoCs) are available from multiple organizations investigating the Axios supply-chain compromise and include the C2 domain used in the attack, sfrclak.com and other network details along with file system, packages data, and accounts observed in the attack: Security teams are recommended to check environments for the presence of [email protected], [email protected], or any version of plain-crypto-js and treat the system as compromised if any of them is detected. Axios should resolve to versions 1.14.0 or 0.30.3, or downgraded to an earlier version confirmed to be safe. Joe DeSimone of Elastic advises rotating credentials on systems running a compromised version of the Axios package, as the malware may have exfiltrated sensitive data such as keys and tokens. Charles Carmakal, chief technology officer at Mandiant, says that the Axios npm supply-chain attack "is broad and extends to other popular packages that have dependencies on it." The researcher warns that the amount of recent supply-chain incidents is overwhelming and that the secrets stolen this way over the past two weeks will lead to more compromises, crypto theft, ransomware, and extortion events. "We are aware of hundreds of thousands of stolen credentials. A variety of actors with varied motivations are behind these attacks," Carmakal says. Update [March 31, 13:09 EST]: Article updated with information about indicators of compromise and reference to potential BlueNoroff connection. Update [March 31, 14:22 EST]: Added attribution information and comments from Charles Carmakal and John Hultquist. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

The threat actor behind the widespread March campaign targeting the open source software community has been using compromised credentials to access AWS environments and exfiltrate more data, cybersecurity firm Wiz reports. The hacking group, known as TeamPCP, DeadCatx3, PCPcat, and ShellForce, has been active since 2024. Initially focused on cloud environments, the group shifted to supply chain attacks in mid-2025, targeting the theft of CI/CD credentials at scale. TeamPCP made headlines over the past two weeks, after hacking Aqua Security’s Trivy vulnerability scanner as part of a campaign that has since expanded to NPM, PyPI, and OpenVSX. According to OpenSourceMalware, the various incidents attributed to the group over the past weeks are chained together, as they were all triggered by the Trivy hack, which was the result of improperly rotated credentials following a February compromise. The malware injected in Trivy packages and GitHub Actions was executed when Trivy ran in downstream pipelines, allowing TeamPCP to compromise publish tokens of NPM developers, as well as a PyPI token belonging to LiteLLM co-founder and CEO Krrish Dholakia. LiteLLM has over 90 million monthly downloads, and its compromise had a massive blast radius. Among others, it exposed a Telnyx PyPI token that led to Telnyx’s PyPI packages being injected with malware. Security researchers estimate that tens of thousands of repositories were likely impacted by the campaign, as TeamPCP’s malware was designed to harvest credentials, API tokens, SSH tokens, and other secrets from the infected developer systems. According to a fresh Wiz report, the hacking group did not waste time validating the exfiltrated credentials. They used the open source tool TruffleHog to confirm that stolen AWS access keys, Azure application secrets, and various SaaS tokens were still valid and in use. Within 24 hours of validating the stolen secrets, the group moved to discovery operations in the compromised AWS environments, enumerating various services, with a focus on containers, where it mapped clusters and task definitions. It also targeted the victims’ AWS Secrets Managers. “Once access had been validated and the layout identified, the actors used a variety of techniques to further their scheme by executing additional code and gaining access to other parts of the victim environments,” Wiz notes. The hackers relied on GitHub workflows to execute code within victim environments, and used the ECS Exec feature to execute Bash commands and Python scripts directly on containers running in AWS environments. “This access enabled the attackers to explore the environment and exfiltrate sensitive data,” Wiz explains. While it stole source code, configuration files, and embedded secrets from GitHub repositories, TeamPCP accessed S3 buckets, Secrets Manager, and databases for bulk data exfiltration from AWS environments, the cybersecurity firm says. “TeamPCP’s post-compromise activities focused on compromising additional secrets and exfiltrating massive amounts of data from code repositories and cloud resources. The exfiltrated data and compromised secrets are potentially being shared with other groups to enable a range of operations,” Wiz notes. In terms of other threat actors that TeamPCP might be working with to monetize its access to compromised environments, the main suspects are the infamous extortion group Lapsus$ and the Vect Ransomware Group. Lapsus$ was seen boasting about future TeamPCP operations, as if it had insider knowledge, and Vect claimed on a known hacking forum that it had a partnership with TeamPCP, Socket reports. “As always, we recommend all customers to follow security, identity, and compliance best practices—including relying on temporary credentials, such as IAM roles, instead of creating long-term credentials, such as access keys. Customers can contact AWS Support with any questions or concerns about the security of their account,” an AWS spokesperson told SecurityWeek. *Updated with statement from AWS. Related: Silent Drift: How LLMs Are Quietly Breaking Organizational Access Control Related: Chinese Hackers Caught Deep Within Telecom Backbone Infrastructure Related: AI Speeds Attacks, But Identity Remains Cybersecurity’s Weakest Link

Researchers have observed a “dangerous convergence” between supply chain attackers and extortion gangs like Lapsus$ as TeamPCP looks to exploit stolen credentials. In a new report published on March 30, security researchers at Wiz, now part of Google Cloud, said they found evidence that TeamPCP was exploring ways to monetize the secrets harvested during these campaigns, such as cloud credentials, SSH keys, Kubernetes configuration files and other coding process secrets. The threat group had been observed validating, encrypting and exfiltrating theses secrets to attacker-controlled domains. “While the speed at which they were used suggests that it was the work of the same threat actors responsible for the supply chain operations, we are not able to rule out the secrets being shared with other groups and used by them,” the Wiz researchers wrote. TeamPCP: Alleged Ties to Ransomware Groups In a message shared with Infosecurity, Wiz confirmed that TeamPCP was “explicitly collaborating with the notorious extortion group Lapsus$ to perpetuate the chaos." Lapsus$ is an extortion-focused hacking group known for high-profile breaches via social engineering and credential theft, with suspected tactical overlaps – but no confirmed organizational ties – to Scattered Spider and ShinyHunters. Ben Read, a lead researcher at Wiz, told Infosecurity: "We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$. By moving horizontally across the ecosystem – hitting tools like liteLLM that are present in over a third of cloud environments – they are creating a 'snowball effect.' This isn't an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand." Meanwhile, Socket, one of the earliest firms to report the TeamPCP software supply chain attacks, shared posts attributed to the Vect ransomware group on BreachForums announcing a partnership with TeamPCP as part of its research into the group. “Vect Ransomware Group is now partnering with TeamPCP, the operators behind the latest Trivy / LiteLLM supply chain compromises. Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won't stop there. We will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns,” the message read. Vect is an emerging Russian-speaking ransomware-as-a-service (RaaS) group, operating as a structured affiliate model where core developers build the ransomware and affiliates carry out attacks, earning up to 80–88% of the profits. TeamPCP Behind Wave of Malicious PyPI Packages The cyber threat group known as TeamPCP recently rose to notoriety by uploading malicious packages to Python Package Index (PyPI), the official online repository where developers share and download Python software packages. The group typically uses typosquatting to trick developers into downloading them. In one campaign, the group targeted Trivy, a widely used open-source vulnerability scanner owned by Aqua Security, by injecting credential-stealing malware into official releases and GitHub Actions. TeamPCP subsequently injected the same malware into Checkmarx's KICS scanner through GitHub Actions and OpenVSX extensions. Later, researchers discovered TeamPCP targeted LiteLLM AI Gateway, a popular Python library for AI model integration. A fourth TeamPCP campaign affected the Telnyx Python package on PyPI and led, once again, to the delivery of credential-stealing malware.

Axios npm packages backdoored in supply chain attack An unknown attacker has compromised the GitHub and npm accounts of the main developer of Axios, a widely used HTTP client library, and published npm packages backdoored with a malicious dependency that triggered the installation of droppers and remote access trojans. How the attack unfolded On March 30, 2026, with an account using a separate throwaway ProtonMail address, the attacker published on NPM a trojanized copy of the popular crypto-js JavaScript library of crypto standards. This malicious [email protected] package was designed to look legitimate, but contained a postinstall script/hook that executes automatically on every npm install. Then, in the early hours (UTC) of March 31, 2026, the attacker used the compromised Axios maintainer account (on which they changed the email to another ProtonMail address to lock out Jason Saayman, the rightful owner), and published backdoored axios releases in relatively quick succession. These malicious packages – [email protected] and [email protected] – contained [email protected] as a runtime dependency. “When a developer runs npm install [email protected] [or [email protected]], npm resolves the dependency tree and installs [email protected] automatically. npm then executes plain-crypto-js’s postinstall script, launching the dropper [setup.js],” Step Security researchers explained. “The dropper contacts a live command-and-control server, delivers separate second-stage payloads for macOS, Windows, and Linux, then erases itself and replaces its own package.json [configuration file] with a clean decoy, leaving a developer who inspects their node_modules folder after the fact with no indication anything went wrong.” According to OpenSourceMalware, the entire process, from installation to full compromise, took approximately 15 seconds. What to do if you installed the backdoored Axios npm versions Developers who have installed [email protected] or [email protected] should assume their system has been compromised and should isolate it from the network. Step Security advises: Searching for malicious axios versions in their project Checking for plain-crypto-js in node_modules (i.e., the folder in a JavaScript project that contains all the installed packages their app needs to run). Its presence means the dropper run. Checking for the presence of the system-specific RAT on their system (/Library/Caches/com.apple.act.mond on macOS, %PROGRAMDATA%\wt.exe on Windows, /tmp/ld.py on Linux). “If a RAT artifact is found: treat the system as fully compromised. Do not attempt to clean in place – rebuild from a known-good state,” the researchers added. “Rotate all credentials on any system where the malicious package ran: npm tokens, AWS access keys, SSH private keys, cloud credentials (GCP, Azure), CI/CD secrets, and any values present in .env files accessible at install time.” They also advised the developer community to: Downgrade axios to a clean version (1.14.0 or 0.30.3) and pin it Add an overrides block to prevent transitive resolution back to the malicious versions Remove plain-crypto-js from node_modules Audit CI/CD pipelines for runs that installed the affected versions and rotate secrets for any workflow that executed them use –ignore-scripts in CI/CD to prevent postinstall hooks from running during automated builds Block known malicious C2 traffic to/from 142.11.206.73 and sfrclak.com. Widespread impact The malicious Axios NPM packages were live for approximately 2 hours 53 minutes and 2 hours 15 minutes, the researches said. “Although the malicious versions were removed within a few hours, axios’s widespread usage – present in ~80% of cloud and code environments and downloaded ~100 million times per week – enabled rapid exposure, with observed execution in 3% of affected environments,” Wiz researchers noted. The extensive system reconnaissance, file enumeration, and process monitoring indicate intelligence gathering operations, credential harvesting, source code theft, and preparation for lateral movement, according to OpenSourceMalware. The absence of cryptocurrency mining or ransomware components indicates that this is not financially motivated cybercrime, but rather espionage or advanced persistent threat (APT) activity. This compromise comes just days after financially-motivated TeamPCP effected a series of cascading supply chain attacks that targeted Aqua’s Trivy security scanner, CheckMarx’s VS Code extensions, LiteLLM, and Telnyx. UPDATE (March 31, 2026, 04:30 p.m. ET): “Google Threat Intelligence Group (GTIG) is investigating the axios supply chain attack, an incident unrelated to the recent TeamPCP supply chain issues. We have attributed the attack to a suspected North Korean threat actor we track as UNC1069,” John Hultquist, Chief Analyst with GTIG, told Help Net Security. “North Korean hackers have deep experience with supply chain attacks, which they’ve historically used to steal cryptocurrency. The full breadth of this incident is still unclear, but given the popularity of the compromised package, we expect it will have far reaching impacts.” Mandiant CTO Charles Carmakal noted that the secrets stolen in the various supply chain attacks over the past two weeks “will enable more software supply chain attacks, SaaS environment compromises (leading to downstream customer compromises), ransomware and extortion events, and crypto heists over the next several days, weeks, and months.” Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

INFOSEC IN BRIEF The cybercrime crew linked to the Trivy supply-chain attack has struck again, this time pushing malicious Telnyx package versions to PyPI in an effort to plant credential-stealing malware on developers’ systems. Ox Security warned on Friday that TeamPCP - the group researchers link to the recent compromise of open-source vulnerability scanner Trivy, which led to malicious LiteLLM packages appearing on PyPI - is back, this time with another compromise of a legitimate software package. In this case, the crew hit Telnyx, which offers VoIP services and AI voice agents. TeamPCP appears to have compromised the PyPI distribution of Telnyx’s Python SDK, replacing current package versions with malicious releases loaded with a multi-stage infostealer and persistence mechanisms. According to Ox, the malware added to the package is similar to the malicious code added to LiteLLM. According to Ox, the Telnyx malware's main difference from the LiteLLM package is how it's installed: Instead of embedding malicious code directly in the file, the Telnyx package downloads its malware in the form of a .wav file that's decoded and executed on the target machine. Telnyx told Ox in a post on X that it had found and resolved the issue, while noting that the only affected component was its Python package. None of Telnyx's infrastructure, networking, or other services or APIs were affected, according to the company, though anyone who installed the Python package while the malicious versions were live should treat that environment as compromised. Those worried they might be affected should check their installed Telnyx version — if you're running 4.87.1 or 4.87.2, Telnyx recommends treating the host as compromised and rotating any exposed credentials. Telnyx sees more than 34,000 downloads a week on PyPI, Ox noted, so it's possible quite a few developers and services pulled one of the malicious releases before they were removed. Alleged RedLine operator extradited to US The mastermind may still be at large, but one of the men alleged to be behind the development and administration of prolific infostealer RedLine is behind bars in the US after being extradited to face charges. Hambardzum Minasyan, an Armenian national, last week made his initial appearance in federal court in Austin, Texas, on charges of conspiracy to commit access device fraud, conspiracy to violate the CFAA, and conspiracy to commit money laundering. According to the indictment, Minasyan's part of RedLine's operations involved registering virtual private servers and domains to host RedLine infrastructure, as well as the creation of repositories used to host RedLine for distribution to affiliates. Minasyan also allegedly registered a cryptocurrency account used to receive RedLine affiliate payments. If convicted on all three charges, Minasyan faces up to 30 years in prison. Law enforcement first publicly identified alleged RedLine developer and administrator Maxim Rudometov in 2024, accusing the Russian national of helping build and run the infostealer operation. Last year, the US government offered a $10 million bounty for information on Rudometov and his co-conspirators. It's not clear whether any money was paid out in relation to the arrest of Minasyan. Snapchat, porn platforms, put on notice for DSA violations What does Snapchat have in common with Pornhub, Stripchat, and other porn platforms? All came under EU scrutiny last week under the Digital Services Act over alleged failures to protect minors online. In Snapchat's case, the matter is a bit earlier in proceedings, as Pornhub, Stripchat, XNXX, and XVideos were all preliminarily found last week to be in breach of the DSA for failing to implement effective age-verification measures that would keep minors off their services. According to the European Commission, all four platforms have a simple self-verification system in place requiring visitors to confirm they're over 18 without any formal checks in place. As this is a preliminary finding, the Commission is now giving the porno-pushers an opportunity to respond. The Commission suspects that Snapchat has a similar weakness in relying on self-declaration, noting the platform's age-assurance measures may be insufficient. "The Commission suspects that Snapchat is not adequately protecting minors from being contacted by users with harmful intent, such as sexual exploitation or recruitment for criminal activities," the EC explained. The Commission will now carry out an in-depth investigation into Snapchat before deciding whether to take further enforcement steps. LAPSUS$ spills alleged AstraZeneca data The cybercriminals behind the LAPSUS$ threat group have released 2.66 GB of data allegedly stolen from drug maker AstraZeneca, and threat watchers say it could become one of the more serious healthcare cyber incidents of 2026 so far if the claims hold up. According to SOCRadar, LAPSUS$ claimed to have hit AstraZeneca recently, making off with what they claim are internal code repositories, access-related data, cloud and infrastructure references, and employee records - data which could be devastating to the company in the hands of the right - or wrong - person. Per SOCRadar, the data they reviewed "points to a potentially meaningful internal code and operations exposure rather than a small credential-only leak." They warn that the purportedly stolen data could be used for follow-on intrusions, to target phishing attacks, and to compromise AstraZeneca partners in supply chain attacks. LAPSUS$ released the full dataset over the weekend, SOCRadar reported. US National Lab creates exascale AI model vulnerability detector Researchers at Oak Ridge National Laboratory have created what they say is an efficient, effective AI vulnerability detection machine that can operate at the exascale level, and all it took was turning a friendly neural network optimization bot into an exploitative one. "It might sound devious, but it's worked very well," said ORNL Center for Artificial Intelligence Security Research director Edmon Begoli. Photon, as the ORNL team dubbed it, is designed to explore, discover, and exploit AI vulnerabilities at scale. According to the team, it starts by applying publicly known attacks against a target model and refining them based on the results. Simultaneously, the team said, it continues exploring the model for new weaknesses, which it can then exploit as part of an ongoing cycle to refine the most effective attacks it finds. Photon is also able to significantly reduce bottlenecks and auxiliary tasks associated with red team AI campaigns - per the team, it scaled without loss of computational efficiency, and maintained 95 percent resource utilization across 1,920 GPUs on the lab's Frontier supercomputer. And there's the rub: This thing can find and exploit anything it can find in an AI model, but such capabilities are limited to supercomputing labs for now. "Photon represents a paradigm shift in how we approach AI security," Begoli said. Thankfully it won't be something bad actors will have the resources to utilize for some time. ®

TeamPCP’s attack spree slows, but threat escalates with ransomware pivot TeamPCP’s destructive run of supply chain breaches has stopped, for now: it has been three days since the group published malicious versions of Telnyx’s SDK on PyPI, and there haven’t been reports of new open-source project compromises. Partnership with emerging RaaS operation “The prior operational cadence was aggressive – a new target every 1-3 days (Trivy [on] March 19, CanisterWorm [on] March 20-22, Checkmarx [on] March 23, LiteLLM [on] March 24, Telnyx [on] March 27),” SANS instructor Kenneth Hartman noted. “The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests.” The announcement in question has been made by Vect, a new ransomware-as-a-service (RaaS) operation, on BreachForum, which is a known “hangout” for cybercriminals. They revealed their plan to make all BreachForum members their affiliates (by providing a “Vect Affiliation Key”), and their partnership with TeamPCP. “Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won’t stop there. We will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns,” they boasted. The threat is real. According to Hartman, there has already been a first confirmed Vect ransomware deployment using TeamPCP-sourced credentials. TeamPCP’s rapid evolution TeamPCP emerged in 2024 and focused on targeting and compromising misconfigured Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers to steal credentials and deploy cryptominers. In 2025, they started building their capacity for automated supply chain attacks. “In late 2025 they deployed CanisterWorm, a self-propagating worm that used ICP Canister nodes as decentralized, censorship-resistant C2 infrastructure — the first observed use of this technique in the wild. In early 2026, destructive payloads with geotargeting logic appeared, combining credential theft with region-specific destruction,” says the OpenSourceMalware team. “The March 2026 campaign represents the culmination: a cascading chain through five vendor ecosystems seeded by a single retained credential [from a previous Trivy compromise].” They demonstrated their adaptibility even during these latest supply chain attacks. “In just eight days, the actor has pivoted across security scanners, AI infrastructure, and now telecommunications tooling evolving their delivery from inline Base64 to .pth auto-execution, and ultimately to split-file WAV steganography, while also expanding from Linux-only to dual-platform targeting with Windows persistence,” Trend Micro researchers noted in the wake of the Telnyx compromise. Hartman also documented another of the group’s innovative techniques: the use of the GitHub Releases API as a fallback data exfiltration channel during a supply chain compromise. TeamPCP’s attacks ripple through dependencies Hartman pointed out that TeamPCP’s pause in supply chain compromises should not be interpreted as the end of the group’s supply chain operations. “TeamPCP explicitly stated they intend to be ‘around for a long time,’ and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries – PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker’s cost of operations on that platform.” Open-source maintainers must realize that TeamPCP is an eminently capable attack group and should take steps to secure their projects. “This incident also exposes the absolute stupidity of blindly updating to the latest package versions. The obsession with using the newest patch the second it drops is a massive vulnerability,” Trend Micro researchers also opined. “If your CI/CD pipeline automatically pulls the newest release without a quarantine period, you are automating your own breach. Pin your dependencies to cryptographic hashes. Let someone else’s infrastructure test the newest release for supply chain malware first.” GitGuardian reseachers have analyzed how TeamPHP’s supply chain attacks spread through dependencies and automation pipelines, and found that: 474 public repositories executed malicious code from the compromised trivy-action (CI/CD component) 1,750 Python (PyPI) packages were set up in a way that would automatically pull the poisoned LiteLLM versions Those numbers are not definitive – i.e., they are likely bigger – because they did not (could not) analyze private GitHub repositories, and they limited their search to Python packages with direct dependency of LiteLLM. “The package could have been included through a longer dependency chain. Looking for the exact digest of the malicious packages is the only way to determine if the dependency was downloaded on a given machine,” they pointed out, and shared the malicious packages’ SHA256 digests for organizations to use when investigating. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

Telnyx Python SDK: rilevate versioni malevole su PyPI Alert AL01/260330/CSIRT-ITA Sintesi Il gruppo TeamPCP prosegue la propria campagna di compromissione, prendendo di mira la libreria Python Telnyx. L'obiettivo dell'attacco consiste nel distribuire payload nascosti in file WAV tramite tecniche di steganografia e nell’esfiltrazione di credenziali. Questo incidente rientra in una più ampia campagna di supply chain che ha già colpito Trivy, Checkmarx e LiteLLM come riportato nel Bollettino BL01/260327/CSIRT-ITA. Tipologia Remote Code Execution Descrizione e potenziali impatti Il gruppo TeamPCP prosegue la propria campagna di compromissione, prendendo di mira la libreria Python Telnyx. L'obiettivo dell'attacco consiste nel distribuire payload nascosti in file WAV tramite tecniche di steganografia e nell’esfiltrazione di credenziali. Questo incidente rientra in una più ampia campagna di supply chain che ha già colpito Trivy, Checkmarx e LiteLLM come riportato nel Bollettino BL01/260327/CSIRT-ITA. In particolare, il 27 marzo 2026 sono state pubblicate su PyPI due versioni malevole della libreria telnyx (4.87.1 e 4.87.2) – entrambe già rimosse – contenenti codice malevolo all’interno del file telnyx/_client.py in grado di distribuire payload nascosti in file WAV tramite tecniche di steganografia ed effettuare esfiltrazione di credenziali. Il codice malevolo si attiva automaticamente già al semplice import del pacchetto, avviando una catena di attacco con persistenza su sistemi Windows e raccolta di dati sensibili su Linux e macOS. Le versioni compromesse sono state rapidamente messe in quarantena, ma gli utenti che le hanno installate devono considerare i propri ambienti come potenzialmente compromessi. Prodotti e versioni affette telnyx==4.87.1 telnyx==4.87.2 Telnyx Team afferma che la piattaforma Telnyx, le sue API e l’infrastruttura non sono state compromesse; l’incidente ha riguardato solo la distribuzione PyPI del Python SDK. Azioni di mitigazione Gli utenti e le organizzazioni possono far fronte a questa tipologia di attacchi valutando l’implementazione delle misure di mitigazione raccomandate riportate di seguito e nei bollettini disponibili ai link nella sezione Riferimenti. Rimuovere immediatamente le versioni compromesse eseguire il downgrade immediato a una versione sicura: pip install telnyx==4.87.0 Considerare compromesso l’ambiente se presenti le versioni 4.87.1 o 4.87.2 se il comando pip show telnyx mostra una delle due versioni malevole, l’ambiente va trattato come compromesso. Ruotare tutte le credenziali e i secrets API keys Credenziali database Token dei cloud provider (AWS, GCP, Azure) SSH keys Sectrets in variabili d’ambiente o file di configurazione Kubernetes secrets Docker, npm, Git, Vault credentials Analizzare il traffico di rete verso l’infrastruttura dell’attaccante controllare connessioni verso il server C2 dell’attaccante. Ispezionare CI/CD e container controllare pipeline CI/CD e Docker build che potrebbero aver installato automaticamente le versioni compromesse; se CI utilizzava litellm (anch’esso compromesso), verificare se le credenziali derivate hanno potuto esporre token PyPI. Infine, si raccomanda di valutare la verifica e l’implementazione degli IoC[1] forniti dai ricercatori di sicurezza tramite i bollettini riportati nella sezione Riferimenti. [1] Per definizione, non tutti gli indicatori di compromissione sono malevoli. Questo CSIRT non ha alcuna responsabilità per l'attuazione di eventuali azioni proattive (es. inserimento degli IoC in blocklist) relative agli indicatori forniti. Le informazioni contenute in questo documento rappresentano la migliore comprensione della minaccia al momento del rilascio. Criticità Alto (70.0) Data pubblicazione 30/03/26 ore 14:59 Data Ultimo Aggiornamento 30/03/26 ore 14:59

For the latest discoveries in cyber research for the week of 30th March, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES Iranian state-affiliated threat group Handala Hack has breached FBI director’s Patel’s personal Gmail account and leaked many personal photos and documents. This follows the FBI’s seizure of domains related to Handala Hack’s activity last week, due to the group’s sustained targeting of Israeli and American entities, which increased during the ongoing Iran conflict. Spain’s Port of Vigo in Galicia has suffered a ransomware attack that forced officials to disconnect parts of its network and switch cargo handling to manual processes. The incident locked equipment and disrupted digital logistics, while physical ship movement could continue without digital communication. The Netherlands’ Ministry of Finance has confirmed a March 19 cyberattack that breached internal systems in its policy department and disrupted work for some employees. Authorities blocked access to affected environments, while tax, customs, and benefits services remained unaffected and no threat actor publicly claimed responsibility for the attack. Decentralized finance platform Resolv has suffered a cyberattack after a compromised private key let an attacker mint about $80 million in uncollateralized USR tokens and swap them for 11,408 ETH worth $24.5 million. Resolv confirmed the incident, paused the app, and offered a 10% bounty for returned funds. AI THREATS Researchers demonstrated a supply chain compromise of LiteLLM, a Python library linking apps to major AI services, after attackers hijacked a security tool and pushed malicious releases on March 24. The tainted packages harvested API keys and cloud credentials, creating downstream exposure for widely used AI projects. Researchers outlined three high-severity vulnerabilities in LangChain and LangGraph, open-source frameworks for building AI assistants, that could expose files, environment secrets, and prior conversations. The flaws enabled arbitrary file access, secret leakage, and SQL injection in checkpointing, and patches were issued in updated components. Researchers identified a zero-click flaw in Anthropic’s Claude Chrome extension that let any website silently inject prompts and control the assistant. The attack combined an overly permissive trusted domain list with a scripting bug in Arkose Labs CAPTCHA handling, enabling token theft, chat access, and email actions. VULNERABILITIES AND PATCHES Cisco has addressed CVE-2026-20131, a CVSS 10 vulnerability in Secure Firewall Management Center that lets unauthenticated attackers execute code as root through the web interface. Cisco confirmed attempted exploitation in March 2026 and released fixes, while on-premises customers have no workaround beyond applying the updates. Check Point IPS provides protection against this threat (Cisco Secure Firewall Management Center Insecure Deserialization (CVE-2026-20131)) TP-Link has issued firmware updates addressing CVE-2025-15517 and related critical flaws in Archer NX200, NX210, NX500, and NX600 5G Wi-Fi routers. Attackers could access administrative functions without logging in, upload rogue firmware, execute system commands, and more. Citrix has released patches for CVE-2026-3055 and CVE-2026-4368 affecting NetScaler ADC and Gateway. The critical memory flaw can expose sensitive data in SAML Identity Provider deployments, while the second bug can mix up user sessions on gateways, creating confidentiality and access risks. Check Point IPS provides protection against this threat (Citrix NetScaler Out Of Bounds Read (CVE-2026-3055)) Researchers warn that a leaked ‘DarkSword’ iOS exploit chain enables no-click attacks via Safari, threatening up to 270 million unpatched iPhones and iPads. The code eases copycat attacks and has seen use, while Apple issued fixes, including March 11 emergency updates for iOS 15 and 16. THREAT INTELLIGENCE REPORTS Researchers revealed that cybercriminals are abusing Keitaro, a commercial adtech tracker, to distribute phishing, scams, and malware at scale. Infoblox linked the platform to major malvertising and spam operations, including campaigns impersonating Canadian banks, logistics brands, government services, and high-trust retail providers. Researchers analyzed three China-aligned activity clusters targeting a Southeast Asian government in a coordinated espionage operation. The campaign combined USB propagation, the Hypnosis loader, and the FluffyGh0st RAT, showing how distinct threat clusters can converge on one high-value government target with complementary tooling. Researchers have analyzed the activity of Russian threat group APT28 (aka Fancy Bear). The group has recently targeted Ukraine as well as its European defense supply chain partners with a toolset dubbed PRIXMES, which holds both espionage and sabotage capabilities. APT28 exploited multiple vulnerabilities, including zero-days, in its attacks. Researchers identified a coordinated adversary-in-the-middle phishing campaign targeting TikTok for Business users who sign in with Google. Attackers deployed proxy login pages that captured passwords and session cookies to bypass multi-factor authentication, with newly registered domains and Cloudflare-hosted infrastructure used to scale impersonation.

Secrets sprawl isn't slowing down: in 2025, it accelerated faster than most security teams anticipated. GitGuardian's State of Secrets Sprawl 2026 report analyzed billions of commits across public GitHub and uncovered 29 million new hardcoded secrets in 2025 alone, a 34% increase year over year and the largest single-year jump ever recorded. This year's findings reveal three core trends: AI has fundamentally reshaped how and where credentials leak, internal systems are far more exposed than most organizations realize, and remediation continues to be the industry's Achilles heel. Here are nine strategic takeaways that matter. 1. Secrets are growing faster than the developer population Since 2021, leaked secrets have grown 152%, while GitHub's public developer base expanded 98%. More developers and more AI-assisted code generation mean more credentials in circulation, and detection alone can't keep pace. 2. AI services drove 81% more leaks year over year GitGuardian detected 1,275,105 leaked secrets tied to AI services in 2025, up 81% from 2024. Eight of the ten fastest-growing categories of leaked secrets were AI-related. This isn't just about OpenAI or Anthropic keys. The real explosion is happening in LLM infrastructure: retrieval APIs like Brave Search (+1,255%), orchestration tools like Firecrawl (+796%), and managed backends like Supabase (+992%). Every new AI integration introduces another machine identity, and each one expands the attack surface. Deploying AI safely requires a proper secrets security strategy. 3. Internal repositories are 6x more likely to leak than public ones While public GitHub gets the attention, internal repositories are where the highest-value credentials live. GitGuardian's research found that 32.2% of internal repos contain at least one hardcoded secret, compared to just 5.6% of public repos. These aren't test keys. They're CI/CD tokens, cloud access credentials, and database passwords, the exact assets attackers target once they gain a foothold. Security through obscurity has failed. Treat internal repos as first-class leak sources. 4. 28% of leaks happen entirely outside code Secrets don't only live in repositories. GitGuardian found that 28% of incidents in 2025 originated entirely outside source code, in Slack, Jira, Confluence, and similar collaboration tools. These leaks are more dangerous: 56.7% of secrets found only in collaboration tools were rated critical, compared to 43.7% for code-only incidents. Teams share credentials during incident response, troubleshooting, and onboarding. If you're only scanning code, you're missing a quarter of your exposure. And the credentials leaking in collaboration tools are usually more critical and severe. 5. Self-hosted GitLab and Docker registries expose secrets at 3-4x the rate of public GitHub GitGuardian discovered thousands of unintentionally exposed self-hosted GitLab instances and Docker registries in 2025. Scanning these systems revealed 80,000 credentials, with 10,000 still valid. Secrets in Docker images were particularly troubling: 18% of scanned Docker images contained secrets, and 15% of those were valid, compared to 12% of GitLab repositories with a 12% validity rate. Docker secrets are also more production-adjacent. The perimeter between private and public is porous. 6. 64% of secrets leaked in 2022 remain valid today Detection is not remediation. GitGuardian retested secrets confirmed as valid in 2022 and found that 64% are still exploitable four years later. This is not a rounding error. It's proof that rotation and revocation are not routine, owned, or automated in most organizations. Credentials embedded across build systems, CI variables, container images, and vendor integrations are hard to replace without breaking production. For many teams, the safest short-term choice is to do nothing, leaving attackers with durable access paths. 7. Developer endpoints are the new credential aggregation layer The Shai-Hulud 2 supply chain attack gave researchers rare visibility into what secrets actually look like on compromised developer machines. Across 6,943 systems, GitGuardian identified 294,842 secret occurrences corresponding to 33,185 unique secrets. On average, each live secret appeared in eight different locations on the same machine, spread across .env files, shell history, IDE configs, cached tokens, and build artifacts. More striking: 59% of compromised machines were CI/CD runners, not personal laptops. Once secrets start sprawling into build infrastructure, they become an organizational exposure problem, not just an individual hygiene issue. More recently, the LiteLLM supply chain attack demonstrated the same pattern, with compromised packages harvesting SSH keys, cloud credentials, and API tokens from developer machines where AI development tools are increasingly concentrated. 8. MCP servers exposed 24,000+ secrets in their first year Model Context Protocol (MCP) made AI systems more useful by connecting them to tools and data sources. It also introduced a new class of credential exposure. In 2025, GitGuardian found 24,008 unique secrets in MCP-related config files on public GitHub, with 2,117 verified as valid. As agentic AI adoption accelerates, MCP and similar frameworks will normalize putting credentials into config files, startup flags, and local JSON. The agent ecosystem is expanding faster than security controls can adapt. 9. Shift from secrets detection to non-human identity governance The industry's limiting factor is answering three questions at scale: What non-human identities exist in my environment? Who owns them? What can they access? Organizations embracing agentic AI need to move beyond detection and build continuous NHI governance. That means eliminating long-lived static credentials wherever possible, adopting short-lived identity-driven access, implementing secrets vaulting as the default developer workflow, and treating every service account, CI job, and AI agent as a governed identity with lifecycle management. The Bottom Line Secrets sprawl is not slowing down. It's accelerating alongside AI adoption, developer productivity tools, and distributed software delivery. The old model of scanning public repos and hoping for compliance is no longer sufficient. Security teams need visibility across internal systems, collaboration tools, container registries, and developer endpoints. They need remediation workflows that can rotate credentials without breaking production. And most importantly, they need to stop treating secrets as isolated incidents and start managing them as part of a broader non-human identity governance program. The attack surface has changed. The question is whether security programs will change with it. About the Research GitGuardian's yearly State of Secrets Sprawl report was published for the 5th time, analyzing billions of public commits on GitHub, monitoring internal incidents across customer environments, and conducting original research on self-hosted infrastructure exposure and supply chain compromises.

The popular Telnyx Python SDK is the latest victim of TeamPCP’s weeks-long supply chain campaign targeting the broad open source software ecosystem. The campaign started on March 19 with Aqua Security’s open source vulnerability scanner Trivy and continued with infections across NPM, Docker Hub, Kubernetes, OpenVSX, and the LiteLLM PyPI package. On Friday, two malicious versions of Telnyx, namely 4.87.1 and 4.87.2, were uploaded to the PyPI registry, targeting Windows, macOS, and Linux systems. Telnyx is a global communications platform-as-a-service (CPaaS) provider that operates its own private IP network to deliver voice, messaging, and programmable communication services to businesses. The Python library has over 670,000 monthly downloads. The rogue Telnyx PyPI packages contained a WAV file that would drop an executable in the startup folder on Windows systems or would execute a hardcoded Python script to decode a third-stage collector script to exfiltrate the machine’s session key on macOS and Linux systems. “The WAV file is a valid audio file. It passes MIME-type checks. But the audio frame data contains a base64-encoded payload. Decode the frames, take the first 8 bytes as the XOR key, XOR the rest, and you have your executable or Python script,” cybersecurity firm Aikido explains. All the exfiltrated data is encrypted using asymmetric encryption (RSA), and the encoded public key is the same that was used in previous TeamPCP attacks, such as the LiteLLM PyPI package compromise, JFrog notes. “It is unknown at this point how the library was compromised, but it is likely a direct result of each of TeamPCP’s recent attacks on the open source ecosystems,” JFrog says. Telnyx users who installed either of the malicious versions of the SDK should consider their machines compromised and rotate all credentials, API keys, SSH keys, and other secrets. According to GitGuardian, the blast radius from TeamPCP’s campaign extends well beyond the publicly discussed compromised packages. The cybersecurity firm identified over 470 repositories that run a malicious version of the Trivy GitHub Action, and more than 1,900 packages that included LiteLLM as a dependency, thus potentially propagating the initial infection. The numbers, GitGuardian warns, represent lower bounds, as the analysis is based only on publicly accessible data. When private repositories and transitive dependencies are taken into consideration, the actual scope of the supply chain campaign extends much further. *the description of Telnyx in the fourth paragraph has been updated for accuracy Related: Chinese Hackers Caught Deep Within Telecom Backbone Infrastructure Related: Cloudflare-Themed ClickFix Attack Drops Infiniti Stealer on Macs Related: Coruna iOS Exploit Kit Likely an Update to Operation Triangulation Related: AI Speeds Attacks, But Identity Remains Cybersecurity’s Weakest Link