Tuesday, August 4, 2026 | Jonathan Lockhart

A self-propagating npm compromise is turning stolen developer credentials into new poisoned releases

Researchers reported a rapidly developing npm supply-chain compromise on August 4 involving packages maintained under the Keyv and Cacheable ecosystems. Early reporting identified a malicious Keyv release as a probable starting point, but the affected-package inventory was still changing at publication and the precise ground-zero version had not been independently established with enough confidence to state as settled fact.

The campaign belongs to the broader family of self-propagating npm activity commonly described as Shai-Hulud. Unlike an ordinary malicious-package incident, the payload searches development systems and continuous integration environments for npm publishing tokens, GitHub credentials, cloud secrets and private keys. When it obtains publishing access, it can release compromised versions of additional packages and expand through maintainers’ existing trust relationships.

Researchers also reported persistence or execution mechanisms involving Visual Studio Code configuration and Claude Code project hooks. These mechanisms are separate from the Google Agent Development Kit workflow vulnerabilities discussed later in this edition, although both incidents show how developer automation and trusted repository metadata can become execution paths.

Package-count estimates varied substantially during the first day of reporting. SafeDep initially confirmed hundreds of malicious versions, while other firms published higher estimates that could not yet be reconciled against a complete public list. Defenders should therefore search by package name, version, installation time and anomalous lifecycle scripts rather than relying on one headline number.

Organizations that installed affected packages should assume that credentials accessible to the build environment may have been stolen. Removing a dependency does not revoke an npm token, undo an unauthorized release or remove malicious repository hooks. Teams should rotate exposed credentials, inspect package-publishing histories, review trusted workspaces and audit repository automation for unexpected changes.

Watch for: An authoritative package and version inventory, confirmation of downstream package publication using stolen tokens, and evidence that compromised maintainers remain under attacker control.

Sources: SafeDep, Shai-Hulud campaign tracking and package analysis, August 4, 2026; Socket, Keyv and Cacheable ecosystem security analysis, August 4, 2026; Aikido Security, npm campaign reporting, August 4, 2026; The Hacker News, Keyv-linked npm supply-chain coverage, August 4, 2026.

Forescout disclosed 15 security findings on August 4 involving zero-touch provisioning in TP-Link’s Omada ecosystem. Eleven findings received CVE identifiers across two coordinated disclosure groups, all using 2025 CVE numbers because the vulnerabilities were reserved during the earlier research process.

The affected surface is broader than Omada routers, switches and wireless access points. Forescout said related weaknesses extend into TP-Link cloud services, mobile applications, IP cameras, smart-home devices and customer cloud accounts. This wider scope matters because a shared provisioning or identity weakness can cross boundaries between enterprise networking, physical surveillance and consumer-style internet-of-things deployments.

The findings include hardcoded cryptographic material, incomplete certificate validation, exposed or weakly protected provisioning credentials, predictable identifiers, default credentials, cross-site scripting and a race condition in cloud adoption. Researchers chained some of the provisioning weaknesses with the previously disclosed command-execution flaws CVE-2025-7850 and CVE-2025-7851.

One demonstrated attack path allowed an external attacker to interfere with the legitimate adoption process, obtain configuration material and take administrative control of the management environment. A compromised controller can then provide access to every device enrolled beneath it. The risk is therefore not simply unauthorized access to one router; it is the conversion of a convenience feature into a fleet-scale trust failure.

Secondary reporting cited approximately 1,800 internet-accessible Omada controllers. Because that figure was not clearly documented in the primary Forescout publication reviewed for this edition, it should be treated as a third-party exposure estimate rather than a confirmed vendor measurement.

Operators should update controllers, firmware, mobile applications and related cloud components; remove controllers from direct internet exposure; rotate provisioning and administrator credentials; and review recently adopted devices for unexpected ownership changes or configuration delivery.

Watch for: Additional TP-Link advisories, patches for the architectural weaknesses that remain unresolved, and public exploit material following the research presentation.

Sources: Forescout Research, “Zero-Touch Provisioning Is a Fleet-Scale Attack Vector,” August 4, 2026; TP-Link, consolidated security advisories for Omada, Tapo and mobile applications, 2025–2026; SecurityWeek, “TP-Link Omada ZTP Vulnerabilities Chain Into Full Network Takeover,” August 4, 2026.

A protocol weakness from the IPMI 2.0 era still exposes server-management passwords offline

New exposure research reported that more than 24,000 internet-accessible baseboard management controllers disclose password-derived authentication material before login because of CVE-2013-4786. The underlying weakness is tied to IPMI 2.0, published in February 2004—not 2024—and is therefore roughly 22 years old.

The Lava Security research was originally published in late July, rather than on August 4. It remains operationally relevant because the August 4 reporting quantified the continuing public exposure of interfaces that provide unusually deep control over physical servers.

During the IPMI Remote Authenticated Key-Exchange Protocol exchange, a remote system can return cryptographic material that permits offline password guessing. Attackers do not need to keep sending guesses to the target controller and can instead use local computing resources to test passwords without triggering conventional online lockout controls.

Baseboard management controllers can remain active when the host operating system is shut down. Depending on the vendor and configuration, they may provide console access, power control, virtual media, firmware management and access through IPMI, Redfish or a web interface. Credential reuse across those services can turn recovery of one password into broad out-of-band administrative control.

The vulnerability is not newly discovered and does not represent a new zero-day. The new concern is the measurement showing that many organizations still expose this legacy authentication design directly to the internet. Operators should isolate management controllers, disable unnecessary IPMI access, eliminate shared passwords, rotate credentials and monitor for unusual volumes of RAKP negotiation.

Watch for: Identification of the hosting providers and device families responsible for the largest exposure clusters, and evidence that attackers are conducting systematic offline password recovery against them.

Sources: Lava Security, BMC and IPMI internet-exposure research, July 28–29, 2026; NIST National Vulnerability Database, CVE-2013-4786; BleepingComputer, “Over 24,000 Exposed Server BMCs Leak Password Hash via Decades-Old Flaw,” August 4, 2026.

Google’s own AI agents could pass attacker instructions across a privilege boundary

Pillar Security disclosed two related but distinct attack paths in automation used by Google’s Python Agent Development Kit repository. Google removed or replaced the affected workflows and confirmed a principal correction on July 21 in commit 66730e9, before public disclosure.

The first chain began with prompt injection against a pull-request triage agent. The important detail is that the agent posted comments through an account treated as a human collaborator rather than as a restricted GitHub Actions bot. That allowed the compromised low-privilege agent to publish a trigger mentioning @gemini-cli, which invoked a separate, more privileged workflow.

The privileged workflow’s GitHub token had write access to issues and pull requests. An attacker could potentially manipulate comments, review requests and review state, creating an automated-looking record that made a malicious change appear more legitimate. A human maintainer would still have needed to merge the demonstrated pull request.

A second pathway involved the issue-fix.yml workflow and its run_command tool. Pillar found that an incomplete command denylist could permit command injection and expose not only a workflow GitHub token, but potentially an adk-bot personal access token and a Google Cloud service-account key. This path represented a broader credential risk than the review-manipulation scenario alone.

There is no public evidence that attackers used either chain against Google in the wild. The defensive lesson is that agent privilege cannot be evaluated in isolation. Teams must examine which agents can write into comments, issues, files or messages later consumed as instructions by a more trusted agent.

Watch for: Similar disclosures involving coding agents, GitHub Apps and model-context integrations that treat another agent’s output as trusted human instruction.

Sources: Pillar Security, “Agent-to-Agent Privilege Boundary Failures in CI/CD on Google’s ADK Repository,” August 3, 2026; Google ADK Python repository workflow and commit history, June–July 2026; SecurityWeek, “Gemini Agent-to-Agent Attack Method Exposed Secrets, Enabled Pull Request Tampering,” August 4, 2026.

A public n8n form can become unauthenticated code execution when workflows reflect user input

Pillar Security disclosed CVE-2026-27493, a critical vulnerability affecting n8n workflows that use a multi-step public form and later render attacker-controlled input through an HTML step. The researchers described the flaw as unauthenticated, zero-click remote code execution from the n8n operator’s perspective: the attacker needs only to submit a crafted public form.

The vulnerability is caused by double evaluation of expression content. User input that should have remained data can be interpreted later as an n8n expression, allowing the attacker to reach JavaScript execution and then escape into operating-system command execution.

The exposure is configuration-dependent. It does not affect every n8n deployment merely because n8n is installed. The vulnerable path requires a public multi-step form and a workflow that reflects submitted data in the affected rendering context. Pillar said it identified more than 50,000 publicly reachable n8n form endpoints, but that figure represents potentially relevant exposure, not 50,000 confirmed vulnerable or compromised instances.

A second issue, CVE-2026-27577, affects authenticated users through an expression-compiler sandbox escape. A missing abstract-syntax-tree transformation allowed access to the Node.js process object, which could lead to code execution by a user already permitted to create or modify expressions.

The consequences can exceed compromise of the automation server. n8n installations frequently store database passwords, cloud credentials, OAuth tokens and API keys for every service connected to a workflow. Defenders should update n8n, identify public form workflows, review whether untrusted input reaches expression or HTML rendering, and rotate secrets if exploitation is suspected.

Watch for: Official exposure guidance from n8n, scanning for affected public workflows, and evidence that attackers are targeting credential stores rather than merely executing cryptocurrency miners.

Sources: Pillar Security, “Zero Click Unauthenticated RCE in n8n: A Contact Form That Executes Shell Commands,” August 2026; GitHub Security Advisories GHSA-75g8-rv7v-32f7 and GHSA-vpcf-gvg4-6qwr; n8n security and release documentation.

N-central exploitation now carries a federal remediation deadline

CISA added CVE-2026-18577 to the Known Exploited Vulnerabilities catalog after N-able confirmed compromise of a limited number of N-central customers. Federal civilian agencies were directed to remediate the flaw by August 6, an unusually compressed deadline reflecting the privilege and downstream reach of the affected platform.

CVE-2026-18577 is an authentication bypass that remained after the earlier correction for CVE-2026-18556. N-able’s corrected release is N-central 2026.3 Hotfix 1, build 2026.3.1.7. Systems running the original 2026.3 release are not fully protected.

N-central is a remote monitoring and management platform used by managed service providers and internal information-technology teams to administer many downstream systems. Successful exploitation can therefore provide access to the N-central server, remote-control functions and managed customer endpoints.

N-able reported attacker use of Take Control and Cloudflare tunneling during confirmed incidents. Those details make simple patch verification insufficient. Responders must determine whether attackers created accounts, launched remote sessions, deployed agents, established tunnels or used stored credentials before the update was installed.

Operators should preserve N-central and firewall logs, confirm the exact installed build, review Take Control activity, search for the vendor-provided indicators, rotate administrative credentials and assess downstream customers for secondary compromise.

Watch for: A broader victim count, attribution, technical exploit analysis and confirmation of whether access obtained through N-central was used for ransomware, espionage or data theft.

Sources: CISA Known Exploited Vulnerabilities Catalog, CVE-2026-18577, August 3, 2026; N-able, N-central security updates and 2026.3 Hotfix 1 release notes, August 1–3, 2026; The Hacker News, “CISA Adds Exploited N-able N-central Flaw to KEV After Customer Compromises,” August 4, 2026.

Passkey attacks require an already compromised Windows device—but can escalate far beyond one login

Unit 42 published research describing three attack paths against Google-style synchronized passkeys: Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key. The findings do not break WebAuthn cryptography. They begin with malware already executing on a Windows device equipped with a Trusted Platform Module and exploit how synchronized passkeys, local keys and relying-party verification interact.

The basic Pass-ta-key path uses a compromised device identity key to generate a valid cryptographic assertion without completing the expected local biometric or PIN verification. Correctly implemented services should reject that assertion because the User Verified flag is absent. Unit 42 found that some relying parties, including eBay before remediation, failed to enforce the flag consistently.

Silver Pass-ta-key addresses services that do validate user verification correctly. The attacker interferes with passkey onboarding or re-registration so that the account accepts an attacker-controlled verification key. This changes the problem from bypassing one validation check to replacing part of the trusted enrollment state.

Golden Pass-ta-key is more severe. Unit 42 demonstrated extraction of the security-domain secret from Chrome process memory. That secret can be used to decrypt synchronized passkey material, creating the possibility of exporting passkeys from one compromised system and transferring them to another attacker-controlled environment.

The prerequisite remains substantial: malware must already be running on the Windows endpoint. The research therefore describes post-compromise credential escalation and portability, not remote theft of passkeys from an untouched machine.

Watch for: Changes to Chrome and Windows key handling, additional relying parties found to ignore user verification, and identity-provider controls that detect suspicious passkey re-enrollment or synchronization.

Sources: Palo Alto Networks Unit 42, “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication,” August 3, 2026; affected-provider remediation described in the Unit 42 disclosure.

Direct-to-IP malware is exposing the limits of DNS-centered detection

Unit 42 reported that almost half of the malware samples in its analyzed dataset communicated directly with command-and-control IP addresses rather than first resolving a domain name. The report was published August 4, but the significance of the percentage depends on the composition of Unit 42’s malware dataset and should not be generalized to half of all malware active worldwide.

Direct-to-IP communication bypasses controls built around malicious domains, newly registered domains and suspicious DNS requests. Malware can therefore reach an external controller without generating the DNS event that many organizations use as a primary detection or blocking point.

The technique is not new, and direct IP connections are not inherently malicious. Administrative applications, embedded systems and some cloud services may use them legitimately. The more useful defensive signal is a process making an outbound connection to a public address without a corresponding DNS event and without a documented operational reason.

Unit 42 identified the technique across ransomware delivery, data-exfiltration tooling, peer-to-peer malware and threats affecting older devices. Defenders should correlate endpoint process telemetry, firewall records and DNS logs rather than treating any one layer as complete coverage.

Watch for: Publication of more detailed dataset methodology and independent measurements showing how prevalence differs across ransomware, botnets, loaders and commodity malware.

Sources: Palo Alto Networks Unit 42, “Almost Half of Malware Samples Communicate Direct to IP,” August 4, 2026.

The PNLD breach exposed a targeting directory—but not police case records or passwords

The Police National Legal Database confirmed that names, organizations and work email addresses belonging to police officers, police staff, criminal-justice professionals, government partners and other users were compromised and published on the dark web. The incident was identified on July 26.

The breach also affected the Ask the Police service. PNLD said some names and email addresses belonging to members of the public who had previously submitted questions through that service were published.

The public statement establishes important limits. PNLD said there was no evidence that passwords or other security credentials were compromised. Public reporting also indicated that victim, witness and offender case records were not part of the exposed dataset. These constraints reduce the direct operational severity compared with compromise of the underlying legal database.

The information remains useful for targeting. Accurate names, professional roles, organizations and email addresses can support convincing impersonation, credential phishing and fraudulent legal or administrative requests. ExfilSquad claimed approximately 135,000 records, including roughly 114,000 PNLD subscribers and 21,000 Ask the Police users, but those figures are attacker claims rather than a confirmed PNLD victim count.

Affected organizations should warn personnel that attackers may know their legitimate workplace affiliations, monitor for targeted authentication attempts and require secondary verification for unusual requests involving police, courts or government partners.

Watch for: PNLD confirmation of the total affected population, the initial intrusion method, and phishing campaigns demonstrably built from the stolen contact information.

Sources: Police National Legal Database, “Important: PNLD Data Breach,” updated August 2026; BleepingComputer, ExfilSquad breach reporting, August 3, 2026; The Hacker News, PNLD breach coverage, August 3, 2026.

Email AI assistants could accelerate post-compromise discovery and impersonation

Barracuda researchers demonstrated in a controlled laboratory scenario how an attacker who already controls a mailbox could use its integrated AI assistant to search years of correspondence, identify sensitive relationships, conceal security messages and prepare convincing impersonation attempts. SecurityWeek reported the research on August 4.

This is not a confirmed campaign and does not show that an AI assistant independently compromises an email account. The attacker must first obtain mailbox access. The assistant then becomes a post-compromise reconnaissance and action tool.

In the demonstration, the attacker prompted the assistant to summarize sensitive communications, identify senior executives and create mailbox rules that hid warning messages. The same accumulated context could help imitate writing style, organizational relationships and active business discussions.

The risk depends heavily on the assistant’s permissions. A read-only summarization tool presents a different threat from one able to create rules, send messages, delete content or interact with other enterprise applications. Auditability is equally important: organizations need records of prompts, retrieved messages and actions that cannot be erased by the same compromised user.

Watch for: Evidence of real-world assistant abuse, provider-specific audit events and controls separating mailbox search from high-impact actions such as forwarding, deletion and external sending.

Sources: Barracuda Networks, laboratory research on weaponizing email AI assistants, August 2026; SecurityWeek, “Weaponized Email AI Assistants Could Help Attackers Hijack Accounts,” August 4, 2026.

Madera Community Hospital’s breach notification arrived more than a year after the intrusion

Madera Community Hospital disclosed that attackers accessed its network on May 28 and May 29, 2025. The hospital completed its review of affected files in April 2026 and began mailing notifications on July 14, according to the California attorney general’s breach listing.

Potentially affected information includes names, contact details, dates of birth, Social Security numbers, financial-account information, account credentials, medical and insurance information and limited biometric data. The hospital said the exact information varied by person.

The figure of 150,810 affected individuals originates from the Department of Health and Human Services breach portal and secondary reporting. The hospital’s own California notification and substitute notice did not publish that number. It should therefore be attributed to federal breach reporting rather than presented as a hospital-confirmed count.

The hospital said it had not found evidence that the compromised information had been publicly released. That statement does not establish that data was not acquired or privately retained by the intruder.

The delay illustrates the operational difference between discovering an intrusion and completing a record-by-record review. Healthcare organizations should not allow a prolonged data-review process to delay credential rotation, patient protection, partner notification or investigation of systems that may still contain attacker persistence.

Watch for: Attribution, any extortion-group publication, and clarification of whether clinical operations or patient-care systems were affected during the 2025 intrusion.

Sources: Madera Community Hospital, Notice of Data Security Incident, July 2026; California Office of the Attorney General, breach submission dated July 14, 2026; U.S. Department of Health and Human Services Office for Civil Rights breach portal; SecurityWeek, “150,000 Impacted by Madera Community Hospital Data Breach,” August 4, 2026.

Jonathan Lockhart is a cybersecurity researcher and investigative journalist at bordercybergroup.com.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.