The current calendar week 18/2026, as of 2 May 2026, shows less of the one large, all-dominating ransomware outage and instead a broader shift in attack practice. Notably, attackers are increasingly no longer compromising classic endpoints first, but are using identities, SaaS environments, CI/CD pipelines, package releases, and cloud-adjacent developer tools as the actual entry point. CrowdStrike now explicitly describes this development as a SaaS-centered attack wave in which groups such as CORDIAL SPIDER and SNARKY SPIDER gain access to enterprise services via voice phishing, counterfeit SSO portals, and session tokens, without necessarily leaving conspicuous malware on the affected clients. This brings an uncomfortable reality into focus: traditional protection of individual devices remains necessary, but is no longer sufficient on its own. Anyone who now looks only at EDR telemetry, local signatures, and perimeter devices will, in many current incidents, see too late or not at all that valid sessions, OAuth permissions, repository access, API tokens, or environment variables are already being abused. These exact patterns run through ADT, Medtronic, Itron, Vercel, Checkmarx, Bitwarden, Elementary, and the very rapid exploitation of a vulnerability in LMDeploy.
ADT: Customer data without access to security systems
ADT already reported on 24 April that its own systems had detected unauthorized access to a limited set of customer and prospect data on 20 April. According to the company, names, phone numbers, and addresses were affected, and in a small number of cases also dates of birth and the last four digits of Social Security or tax IDs. ADT also emphasizes that no payment information, bank data, or credit card data were affected and that customer security systems were not compromised. For classifying the scale, Have I Been Pwned is relevant, because the dataset was added there on 27 April 2026 and is listed with 5.5 million affected email addresses. That figure does not come from ADT’s short statement itself, but it matches the external breach record and makes clear that, despite the limitation described by ADT, this was not a minor side event.
The case is therefore typical of the current week: it is not about a direct takeover of the physical security infrastructure, but about personal data that can be used for phishing, identity fraud, social engineering, and targeted follow-up attacks. This distinction is especially important for a provider from the security sector, because technically the non-compromise of the alarm and security systems is a relief, but from the perspective of those affected the disclosed master data remains exploitable.
Medtronic: Access to corporate IT, but so far no indications of product or patient safety consequences
Medtronic also confirmed on 24 April unauthorized access to data in certain corporate IT systems. According to the company, no impacts have been identified so far on products, patient safety, customer connections, manufacturing, distribution, financial reporting systems, or the ability to provide care to patients. Medtronic also emphasizes that the networks for corporate IT, products, and manufacturing and distribution are separate, and that hospital networks are operated separately by the respective customer teams. This wording is important because medical technology incidents are quickly confused in public perception with immediate risks to patients. What is confirmed here initially is access to corporate systems and an ongoing review of whether personal information was affected. What is not confirmed is interference with medical devices, manufacturing systems, or hospital networks. This separation should be maintained in the further course as well, even if external extortion groups operate with larger numbers or their own claims.
Itron: Attack on systems of an energy and metering infrastructure provider
Itron reported via SEC Form 8-K that the company was informed on 13 April of unauthorized access to certain systems. According to the manufacturer of metering, energy, and utility infrastructure, it activated its incident response plan, brought in external advisors, and notified law enforcement. Itron also stated that the unauthorized activity had been removed, that no further activity had been observed in the company systems, and that no unauthorized activity had been identified in the customer-hosted portion of the systems.
The incident is relevant primarily because of the market segment. For providers of metering and utility infrastructure, the question is not only whether data was exfiltrated, but also whether customer systems, operational data, or connected utility environments could have been affected. Itron explicitly denies the latter based on the current status and currently expects no material impact on the company. Nevertheless, the report remains an example of attackers continuing to deliberately penetrate ecosystems that matter to utilities, municipalities, and operators of critical infrastructure.
Vercel: When a third-party tool becomes the entry point into developer environments
The Vercel incident makes especially clear how closely identity, SaaS usage, and development operations are now intertwined. Vercel explained that there had been unauthorized access to certain internal systems and that the incident originated in the compromise of Context.ai, a third-party AI tool used by a Vercel employee. Through this access, the attacker took over the employee’s individual Google Workspace account, then gained access to the employee’s Vercel account, and in a Vercel environment enumerated and decrypted environment variables that were not marked as sensitive. Following the ongoing investigation, Vercel initially identified a limited number of customers whose non-sensitive environment variables were affected; later, a few additional accounts were added. At the same time, Vercel stated that together with GitHub, Microsoft, npm, and Socket it had confirmed that npm packages published by Vercel had not been compromised.
The decisive lesson lies less in the specific platform and more in the chain of authorization. A seemingly ordinary AI or analytics tool in day-to-day work can, if poorly secured or granted overly broad access rights, become a springboard into development and deployment environments. Particularly critical are values that are marked as “not sensitive” from an organizational perspective but may technically still contain API keys, tokens, database credentials, or signing keys.
Checkmarx and Bitwarden: The package chain remains an attractive target
Checkmarx confirmed on 27 April further details about a supply chain incident that, according to the company, originated in the Trivy supply chain attack of 23 March. Attackers reportedly obtained access to GitHub repositories, were able to interact with the GitHub environment, and insert malicious code into certain artifacts. Checkmarx also mentions exfiltration on 30 March and publication of data by LAPSUS$ on 25 April. The company emphasizes that the GitHub repositories were operated separately from the customer production environment and that, as standard practice, no customer data was stored there.
Bitwarden was also part of this chain. The company explained that via the npm distribution path a malicious package for @bitwarden/[email protected] was briefly distributed, specifically on 22 April between 17:57 and 19:30 Eastern Time. According to Bitwarden, no indications were found that Vault data from end users was affected or that production systems were compromised. According to Bitwarden, only users who obtained the CLI client via npm during this narrow time window were affected. The core security issue here is not new, but it was again very visible this week: package managers, CI/CD workflows, and release automation are already productive attack paths. A compromised artifact does not have to remain online permanently to cause damage. It is sufficient if it is executed in build systems, developer workstations, or automated deployments and can read environment variables, SSH keys, API tokens, or cloud credentials there.
Elementary: GitHub Actions as the entry point for a manipulated PyPI and Docker release
On 27 April, Elementary published a report on a malicious version of its open-source Python CLI. Version 0.23.3 contained harmful code on 24 April and was published both on PyPI and as a Docker image. According to Elementary, these artifacts did not originate from its own team. The attacker opened a pull request with malicious content and exploited a script injection vulnerability in a GitHub Actions workflow to trigger the release. Elementary explains that only users who installed exactly this version 0.23.3 of the Python CLI or executed the affected Docker image were affected. Elementary Cloud, the dbt package, and other CLI versions were not affected. According to Elementary, anyone who executed the version should assume that all credentials accessible in the respective environment may be compromised, including warehouse access, cloud keys, API tokens, SSH keys, and .env contents. The case fits almost textbook-like with the Checkmarx and Bitwarden events. The decisive point is not only the existence of a workflow vulnerability, but the fact that CI systems are often equipped with far-reaching secrets. If comment content, pull request metadata, or other external inputs are inadequately passed into shell contexts, automation becomes a direct release weapon.
LMDeploy: AI infrastructure is tested within hours
Sysdig observed exploitation of CVE-2026-33626 in LMDeploy within 12 hours and 31 minutes after publication on the main GitHub Advisories page. LMDeploy is a toolkit for deploying vision-language and text LLMs. The vulnerability allows server-side request forgery because the server dereferences external image URLs in the context of vision requests. According to Sysdig, attackers used this mechanism in a honeypot not only to test the vulnerability, but as a generic HTTP SSRF primitive to probe internal targets such as AWS Instance Metadata Service, Redis, MySQL, an administrative HTTP interface, and an out-of-band DNS endpoint. The technical classification is particularly relevant for AI infrastructure. Many inference servers run on GPU instances with cloud roles, access to model artifacts, datasets, or internal services. An SSRF vulnerability in such a service is therefore not merely a web flaw, but potentially access to metadata, cloud credentials, and internal APIs. The fact that Sysdig does not cite a public proof of concept as a prerequisite for the observed exploitation further worsens the situation, because an advisory with enough detail can already be sufficient for rapid exploit reproduction.
Actively exploited vulnerabilities: Windows Shell and ScreenConnect remain in focus
CISA added CVE-2026-32202 in Microsoft Windows Shell and CVE-2024-1708 in ConnectWise ScreenConnect to the KEV catalog this week. CVE-2026-32202 is listed as a security feature bypass in Windows Shell that enables spoofing over the network. Reports on Microsoft’s updated classification describe the flaw as actively exploited and place it in the context of an incomplete fix for an earlier Windows Shell issue. Particularly problematic is the possibility of forcing authentication information via automatically processed LNK files toward an attacker server.
For ConnectWise ScreenConnect, CVE-2024-1708 concerns a path traversal vulnerability that is older, but regains operational relevance through its inclusion in KEV. For administrators, this is less a theoretical reminder than a practical prioritization aid: what ends up in KEV is no longer merely a CVSS paper issue, but is associated with observed exploitation. Remote support and remote maintenance products are especially critical here, because in the event of success they usually provide direct access to administrative workflows.
Assessment: The common denominator is not malware, but trust
Most cases this week can be reduced to a common denominator: attackers are abusing existing trust. In ADT and Medtronic, it is customer data and corporate data; in Itron, systems of an infrastructure supplier; in Vercel, the trust chain between third-party tool, Google Workspace, and development platform; in Checkmarx, Bitwarden, and Elementary, the trust chain between repository, CI/CD workflow, and package manager; in LMDeploy, the implicit trust of an inference server in external image URLs. This makes defense more difficult, but not arbitrary. Key measures include narrowly scoped OAuth and SSO rights, short token lifetimes, consistent separation of production and development environments, signed artifacts, traceable release pipelines, protected publish environments, secret scanning in CI/CD, restrictive egress rules for server services, and monitoring at the identity layer. It is also particularly important that environment variables are assessed not by label but by actual content. A value not marked as sensitive from an organizational perspective can technically still be the key to a production environment.
Conclusion
Week 18/2026 is not a week of a spectacular single catastrophe, but a week of systemic weaknesses. The attacks and disclosures show that modern IT environments are increasingly held together through identities, integrations, and automated release paths. That is exactly where the current campaigns are striking. For companies, this means that patch management remains mandatory, but can no longer be understood as the sole protective mechanism. Anyone who does not take SaaS sessions, OAuth connections, CI/CD workflows, package releases, and cloud metadata as seriously as classic server vulnerabilities is protecting the part of the infrastructure that attackers increasingly only need to bypass.
What is LeakWatch?
Within the scope of this editorial project, a specially programmed and trained bot is used for the author’s dedicated internet research, which performs the automated analysis of relevant data sources and also creates translations. The aim is to use primary sources that are as unaltered as possible, which is why all links are recorded in tabular form to enable optional in-depth research by interested readers. Automated search and extraction would only be feasible with disproportionate effort without AI support; however, every evaluation and the actual text creation are editorially handled, and everything is also reviewed again in terms of content, since the AI cannot interpret or formulate all content with complete reliability. LeakWatch is conceived as a periodically published security and leak analysis format, created in the style of igor’sLAB and in accordance with specific requirements. The focus is on verifiable events from primary sources, technical classification, and a fully neutral assessment without the influence of already filtered secondary information from third parties.
Noch keine sichtbaren Antworten im Forum gefunden. Der Thread ist bereits angelegt und kann direkt im Forum geöffnet werden.