Last updated: July 5, 2026 at 9:01 AM UTC
All 557 Vulnerability 199 Breach 106 Threat 245 Defense 7
Tag: supply-chain (85 articles)Clear

Identity governance vendor SailPoint discloses GitHub repository breach - third-party app flaw to blame

SailPoint, the identity governance vendor used by many large enterprises, disclosed in a SEC 8-K filing that attackers gained unauthorized access to a subset of its GitHub repositories on April 20. The company's incident response team contained the intrusion the same day. SailPoint says no customer data in production or staging was accessed and its services were not interrupted. The root cause was a vulnerability in a third-party application, which has been remediated. SailPoint notified affected customers directly and says no further customer action is needed. The company has not disclosed what data was actually in the impacted repos.

Check
If you use SailPoint (IdentityNow, IdentityIQ, or related products), check whether you received a direct notification dated after April 20, 2026, and review the scope details in your account portal.
Affected
SailPoint customers who received a direct breach notification dated on or after April 20, 2026. The company has not publicly disclosed which products, repositories, or customer subsets were specifically named in the notifications. No customer data in production or staging environments was accessed per SailPoint's SEC filing.
Fix
Follow guidance in your direct SailPoint notification. As a precaution, rotate any API tokens or service-account credentials issued for SailPoint integration over the past 12 months. Review SailPoint integration audit logs for unexpected activity from April onward. Ask SailPoint for the name of the third-party application whose flaw caused the intrusion - your organization may use it elsewhere.

Zara confirmed in ShinyHunters Anodot fallout - 197,000 customer support records leaked

Zara is the latest big brand caught in the ShinyHunters extortion campaign tied to the March breach of analytics provider Anodot. The attackers - who got into Anodot in March and used that foothold to raid Snowflake-hosted data for at least a dozen downstream customers - have now published roughly one terabyte of files they say came from Zara's customer support system. Have I Been Pwned loaded 197,376 unique email addresses from the dump, along with product SKUs, order IDs, and the market each support ticket originated in. Zara's parent Inditex says no passwords or payment data were exposed.

Check
Search corporate email logs for a spike in phishing or fake order-status messages spoofing Zara customer service over the past 30 days, especially targeting users who shop with their work email.
Affected
Zara customers who contacted customer support are exposed via leaked email addresses, product SKUs, order IDs, and the market of origin (197,376 unique addresses confirmed by HIBP). Inditex has stated no passwords or payment information were included. Any organization whose data was held by Anodot remains part of this broader supply-chain campaign.
Fix
Treat the 197K leaked email addresses as confirmed-exposed for phishing targeting. Apply stricter inbound filtering for Zara order-status or return-label phishing lures. Educate employees who use work email for personal e-commerce. If your company uses Anodot, or routes data through Snowflake integrations exposed by the Anodot breach, follow the remediation Anodot and Snowflake published in April and rotate any tokens shared with Anodot.

AI merchant data platform Woflow leaked - 447,000 records exposed in ShinyHunters extortion

Woflow, an AI-driven platform that maintains menu and product data for restaurants and merchants on delivery apps, is the next named victim of ShinyHunters' extortion campaign. The group has published over 2 terabytes of files it says came from Woflow, including names, phone numbers, physical addresses, and email addresses. Have I Been Pwned loaded 447,593 unique email addresses from the dump. The exposed data appears to cover both Woflow's direct customers and the end customers of those merchants - so the breach radius is wider than Woflow's own user list, reaching the customers of every business that relies on Woflow's data.

Check
Check whether your restaurant chain, merchant operations, or delivery integrations rely on Woflow to maintain menu, product, or location data, and review customer service tickets for phishing referencing Woflow-handled records.
Affected
Direct Woflow customers (restaurant chains, merchant networks, delivery-app operators) and the end consumers of those merchants. Leaked fields confirmed by HIBP include names, email addresses, phone numbers, and physical addresses - 447,593 unique email addresses total. No passwords or payment details have been reported in the published dataset.
Fix
If you are a Woflow customer, contact your account team for the official IoC list and impacted-record scope. Notify your own customers if their data was passed through Woflow. Apply stricter inbound filtering for phishing impersonating restaurant brands, delivery platforms, or order confirmations. Rotate any API keys or shared credentials your team exchanged with Woflow integrations in the past 18 months.

Hackers replaced installers on the official JDownloader website with a Windows remote access trojan - third 'trusted software website hijack' in a month

JDownloader's official website was compromised between May 5-7 and the alternative Windows installer plus the Linux shell installer were replaced with malware. The Windows payload is a Python-based remote access trojan; the Linux installer establishes root persistence and pulls additional binaries. Attackers exploited an unpatched flaw in the website's CMS that let them change download links without authentication. macOS downloads, Flatpak/Winget/Snap packages, and the main JDownloader.jar weren't touched. Third 'trusted software site' hijacked in 30 days after CPUID (CPU-Z, HWMonitor) in April and DAEMON Tools last week.

Check
Audit endpoints for JDownloader installations made between May 5 23:55 UTC and May 7. Check Programs and Features for publishers signed by 'Zipline LLC' or 'The Water Team' rather than 'AppWork GmbH'.
Affected
Windows endpoints that downloaded JDownloader through 'Download Alternative Installer' between May 5 23:55 UTC and May 7. Linux endpoints that ran the shell installer in the same window. Acute risk: any host running the malicious installer should be considered fully compromised. Unaffected: macOS users, Flatpak/Winget/Snap installs, in-app updates, and the main JDownloader.jar.
Fix
Reinstall the operating system on any host that ran a malicious JDownloader installer - the developers explicitly recommend this rather than scan-and-clean. Reset every credential entered on the host since installation: browser-stored passwords, SSH keys, cloud tokens. For corporate fleets running JDownloader: switch to Winget or Flatpak distribution channels.

AI evaluation startup Braintrust got hacked - and is asking every customer to rotate their AI provider API keys because the breached AWS account stored them all in one place

Braintrust, an AI evaluation and observability platform recently valued at $800 million, confirmed Tuesday that an unauthorized actor accessed one of its AWS accounts on May 4. The breached account held org-level API keys that customers store with Braintrust to access OpenAI, Anthropic, and other AI providers. Braintrust has confirmed exposure of one customer and is investigating three more reporting suspicious AI-provider usage spikes. The pattern - a relatively small AI infrastructure provider becoming a credential warehouse for downstream customers - is what Nudge Security's Jaime Blasco called 'the new shape of supply chain risk.'

Check
If your organization uses Braintrust, log into the org-level settings page and check the timestamp of every stored AI provider secret. Audit AI provider billing dashboards for unexpected usage spikes since April.
Affected
Braintrust customers, particularly AI-forward companies that store provider API keys in Braintrust org-level settings. Public reports suggest the customer base includes Box, Cloudflare, Dropbox, Notion, Ramp, and Stripe. Beyond Braintrust: any AI eval, observability, or gateway tool that holds customer-issued provider keys is the same risk pattern.
Fix
Rotate every AI provider API key stored with Braintrust - go to org-level settings, delete existing secrets, configure new ones, verify timestamps. Apply the same rotation to keys stored in similar AI eval/observability/gateway tools. Switch from static API keys to short-lived OIDC-issued credentials where the AI provider supports it. Add SCPs that restrict which AI provider services your IAM keys can call.

Chinese hackers slipped a backdoor into the official DAEMON Tools installer for a month - thousands of computers in 100+ countries running tainted software signed with the real developer certificate

Kaspersky disclosed yesterday that the official DAEMON Tools installer - a popular Windows disk-image utility - has been distributing a backdoor since April 8. The trojanized versions (12.5.0.2421 through 12.5.0.2434) are downloaded from the legitimate vendor website and signed with valid AVB Disc Soft certificates. Thousands of infections recorded across 100+ countries, but follow-on payloads went to about a dozen targets in retail, scientific, government, and manufacturing sectors in Russia, Belarus, and Thailand. Kaspersky attributes the attack to Chinese-speaking actors and says it remains active. Detection took roughly a month - similar timeline to the 2023 3CX supply-chain attack.

Check
Search Windows endpoints for DAEMON Tools versions 12.5.0.2421-12.5.0.2434, and verify file hashes of DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe. Search proxy logs for env-check.daemontools.cc since April 8.
Affected
Windows endpoints with DAEMON Tools versions 12.5.0.2421 through 12.5.0.2434 installed since April 8, 2026. Compromised binaries are DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe in the DAEMON Tools install directory. Acute risk for organizations in Russia, Belarus, and Thailand and in retail, scientific, government, or manufacturing sectors - Kaspersky observed targeted second-stage payloads only on these.
Fix
Uninstall trojanized DAEMON Tools versions and reinstall from a verified clean release. Block env-check.daemontools.cc at the DNS resolver. Treat machines that ran trojanized versions as compromised: rotate credentials, hunt for QUIC RAT, and reimage if any second-stage payload is found. Apply application allowlisting to prevent vendor-signed but compromised binaries from running.

China-linked spies breached the IBM subsidiary that runs IT for Italian government agencies and critical industries

La Repubblica reported a significant breach at Sistemi Informativi, a wholly-owned IBM Italy subsidiary that manages IT infrastructure for Italian public agencies and key industries. Multiple intelligence sources attribute the attack to Salt Typhoon, the China-linked espionage group that has hit US telecoms (AT&T, Verizon, Viasat), Canadian telecom firms, the US Army National Guard, Dutch government networks, and now Italian critical infrastructure. Salt Typhoon's hallmark is patience - prolonged data exfiltration, silent network observation, and infrastructure compromise rather than fast theft. The group has been active since at least 2019 and has reportedly hit 200+ companies across 80 countries.

Check
If your organization uses managed IT services for critical infrastructure (utilities, transport, healthcare, government), audit your provider's separation between corporate IT and customer environments this week.
Affected
Italian government agencies and key industries using Sistemi Informativi for IT infrastructure. More broadly: any organization where a single integrator holds access to multiple government databases - the breach pattern lets Salt Typhoon map critical infrastructure across many victims through one compromise. European telecoms and managed service providers are at acute risk.
Fix
Demand from any managed IT provider written attestation that customer environments are network-segregated from their corporate IT. Hunt for Salt Typhoon indicators: unauthorized configuration changes on edge devices, traffic to known Demodex C2 infrastructure, and anomalous data flows to Asian hosting providers. Treat the Italian breach as a reason to escalate vendor security reviews this quarter.

Attackers poisoned 60+ Ruby gems and Go modules, then waited for CI pipelines to install them and steal credentials

Socket disclosed a fresh wave of supply-chain attacks targeting Ruby gems and Go modules: more than 60 typosquatted packages were uploaded to RubyGems and the Go module registry, designed to look like legitimate dependencies developers might pull into a CI pipeline. Once installed, the packages exfiltrate environment variables (which typically include AWS keys, GitHub tokens, and database credentials in CI environments) to attacker-controlled servers. The targeting is deliberate: typosquats picked names close to popular gems and Go libraries. This is the same operational pattern as the SAP npm compromise covered Wednesday, but targeting Ruby and Go ecosystems.

Check
Review your CI pipelines for any Ruby gem or Go module added in the past month, and confirm every package name matches the canonical upstream exactly.
Affected
Any organization running CI/CD pipelines that install Ruby gems or Go modules without strict pinning. Particularly acute for organizations with broad CI environment variables (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_URL exposed to install scripts). Developer workstations are also exposed when developers run 'gem install' or 'go get' without verifying package names.
Fix
Pin every Ruby gem and Go module to specific versions and verify the upstream name matches. Move CI secrets out of environment variables and into ephemeral credential providers (OIDC for AWS, GitHub's masked secrets, Hashicorp Vault). Review CI logs for installs of packages whose names look like typosquats. Use Socket, Snyk, or equivalent tools to flag suspicious packages before install.

The same supply-chain worm that hit SAP packages on Wednesday spread to PyTorch Lightning and Intercom's npm SDK on Thursday

Update on the Mini Shai-Hulud campaign covered April 30: The same supply-chain worm that hit four SAP npm packages on Wednesday spread to two more major packages on Thursday. PyTorch Lightning, an AI training framework with 31,100 GitHub stars and hundreds of thousands of daily downloads, had malicious versions 2.6.2 and 2.6.3 published on PyPI for 42 minutes before being quarantined. Intercom-client, the official Node.js SDK for Intercom (361,510 weekly downloads), was compromised at 14:41 UTC. Intercom traced its compromise to pyannote-audio pulling Lightning as a dependency - showing the worm propagating through stolen credentials from the SAP victims.

Check
Audit any developer machine or CI runner that ran 'pip install' on PyTorch Lightning or 'npm install' on intercom-client between April 30 and May 1, and rotate every credential on those machines.
Affected
Lightning (PyPI) versions 2.6.2 and 2.6.3 - safe version is 2.6.1. Intercom-client (npm) version 7.0.4 (per Socket) and 7.0.5 (per Wiz). AI/ML environments running Lightning routinely hold GPU cluster credentials, cloud IAM tokens, Hugging Face API keys, and Weights & Biases tokens. Backend services and CI/CD pipelines integrating with Intercom's API are exposed even if they don't use Lightning.
Fix
Pin Lightning to 2.6.1 or earlier; reject 2.6.2 and 2.6.3. Update intercom-client per Intercom's advisory. Rotate all credentials potentially exposed: GitHub tokens, npm tokens, AWS/GCP/Azure keys, environment-variable secrets. Gate npm publish behind environment review (the same pattern that compromised SAP).

Hackers compromised four official SAP developer packages and used them to steal credentials from any developer who installed an update

Attackers compromised four official SAP npm packages on Wednesday and replaced them with versions that quietly steal developer credentials when installed. The packages - mbt, @cap-js/sqlite, @cap-js/postgres, and @cap-js/db-service - are SAP's open-source tools for cloud application development. Anyone who ran 'npm install' between 09:55 and 12:14 UTC on April 29 had their machine grab GitHub tokens, npm credentials, and AWS, Azure, and GCP secrets, then dump them into public GitHub repositories on the victim's own account. The same attackers (TeamPCP) hit Trivy, Checkmarx, and Bitwarden earlier this year. The malware skips Russian-language systems entirely.

Check
Audit your CI/CD pipelines and dev machines for the four compromised SAP packages installed between April 29 09:55 and 13:46 UTC, and rotate every credential on those machines.
Affected
Any developer or CI/CD environment that ran 'npm install' on mbt 1.2.48, @cap-js/sqlite 2.2.2, @cap-js/postgres 2.2.2, or @cap-js/db-service 2.10.1. SAP enterprise shops running CAP are at acute risk because these are core SAP development packages.
Fix
Update to clean SAP versions: @cap-js/db-service 2.11.0, @cap-js/sqlite 2.4.0, @cap-js/postgres 2.3.0. Rotate every GitHub token, npm token, and cloud credential (AWS, Azure, GCP) on machines that touched those packages. Search GitHub for repositories with the description 'A Mini Shai-Hulud has Appeared' belonging to your developers and report them to GitHub.