Welcome to our weekly newsletter where we share some of the major developments on the future of cybersecurity that you need to know about. Make sure to follow my LinkedIn page as well as Echelon’s LinkedIn page to receive updates on the future of cybersecurity!
To receive these and other curated updates to your inbox on a regular basis, please sign up for our email list here: https://echeloncyber.com/ciw-subscribe
Echelon Events & Thought Leadership Highlight
Stop by Booth 1851 for the real jackpot at Fal.Con: good conversation about AI security.
Come meet our team at Fal.Con 2026 from August 31 to September 3!
Away we go!
1. SickKids Breach Exposes Employee Data in Latest Healthcare Cyberattack
Canada’s largest pediatric hospital is investigating another cybersecurity incident, this time involving the theft of employee and applicant information rather than patient records. The Hospital for Sick Children in Toronto, better known as SickKids, said the incident appears connected to a third-party software application and temporarily disrupted the hospital’s careers website. Investigators believe information belonging to current and former employees, job applicants and personnel associated with related organizations, including the SickKids Foundation, may have been taken.
The hospital has not disclosed exactly what information was exposed or when the intrusion occurred. SickKids said its clinical systems were not involved and there is no indication that patient information was accessed. Individuals believed to be affected have been notified and offered two years of credit monitoring. That separation between workforce systems and clinical environments is important. For healthcare organizations, an attack that compromises an HR or recruiting platform can still expose valuable personal information without an attacker ever touching an electronic health record.
The incident is especially notable because SickKids has been through a serious cyberattack before. In December 2022, ransomware disrupted systems used for pharmacy operations, diagnostic imaging and employee timekeeping, with recovery stretching into the following weeks. The ransomware group responsible eventually apologized for the attack, released a decryptor and claimed the affiliate responsible for targeting the children’s hospital had been removed from its operation. The latest incident appears very different, but it illustrates how healthcare organizations remain exposed through a much broader technology ecosystem than the systems directly involved in treating patients.
SickKids is also not alone. Baylor Genetics recently disclosed a breach involving medical testing data, laboratory results, insurance information and Social Security numbers, while healthcare technology provider CareCloud reported an incident affecting roughly 3.7 million people. The larger lesson for healthcare security teams is that protecting the hospital network itself is only part of the job. Recruiting platforms, HR applications, billing systems, laboratories, SaaS providers and other third parties can all become paths to sensitive information. Vendor security reviews need to look beyond compliance questionnaires and examine what data a provider holds, how that provider is accessed, whether strong authentication is enforced and what happens when one of those vendors is compromised.
Google Cloud Addresses High-Severity TPM Vulnerability
Google Cloud disclosed a high-severity vulnerability this month affecting the Trusted Computing Group’s TPM 2.0 reference implementation, tracked as CVE-2026-6726. The issue affects multiple revisions of the reference code used to implement Trusted Platform Module functionality, which plays an important role in hardware-backed trust, key protection, secure boot, and attestation across cloud and enterprise environments. Google published its security bulletin on August 11 and said it will proactively update affected systems during customers’ standard maintenance windows.
The good news for Google Cloud customers is that no direct customer action is currently required. Google is handling remediation at the infrastructure layer. That said, security teams should not treat this as a reason to ignore the issue. TPM vulnerabilities are a good reminder that cloud security extends well below the operating system and application layers. Hardware-backed security components, firmware, virtualization platforms, and trusted execution technologies all form part of the cloud trust boundary, even when customers do not manage them directly.
Organizations using hybrid or multi-cloud environments should also determine whether they operate TPM-enabled systems outside Google Cloud that may rely on the same affected reference implementation. Those environments may require separate vendor patches or firmware updates. Cloud teams should review vendor advisories, confirm that automated maintenance windows are enabled where appropriate, and monitor security bulletins from hardware and platform providers rather than assuming a cloud provider’s remediation automatically covers on-premises systems.
Why it matters: One of the major benefits of cloud infrastructure is that providers can often remediate vulnerabilities below the customer responsibility boundary without requiring thousands of organizations to patch individually. But shared responsibility still cuts both ways. Security teams need visibility into which vulnerabilities their cloud provider owns, which ones they own, and where hybrid infrastructure creates gaps between the two.
2. Critical GitLab Flaw Moves From Disclosure to Attack Attempts in Just Two Days
Organizations running their own GitLab environments have another reason to rethink how quickly they respond to critical vulnerabilities. GitLab issued an emergency security release on August 17 for a critical code injection vulnerability affecting Community Edition and Enterprise Edition. Just two days later, researchers were already seeing attempts to exploit it. The vulnerability, tracked as CVE-2026-19478 with a CVSS score of 9.4, can allow an unauthenticated attacker to manipulate or delete public projects and user data through a malicious GraphQL directive.
GitLab has released fixes in versions 19.2.4, 19.1.6, 19.0.8 and 18.11.11 and is urging customers with self-managed installations to upgrade immediately. The same release also addresses a high-severity cross-site request forgery vulnerability tracked as CVE-2026-19650. For organizations that cannot patch immediately, researchers recommend restricting access to the /api/graphql endpoint or temporarily removing public repository access. Security teams should also review web logs for requests containing @gl_introduced, an indicator associated with probing or attempted exploitation of the vulnerability.
The bigger concern is what sits behind GitLab. Source code repositories have become some of the most valuable systems inside modern companies because they are connected to much more than code. GitLab environments can contain intellectual property, CI/CD pipelines, deployment workflows, credentials, access tokens and secrets capable of opening paths into cloud and production infrastructure. As AI coding tools and autonomous development agents become more integrated into software development, compromising the platform that coordinates those workflows could give an attacker considerably more leverage than compromising a single developer workstation.
The speed of exploitation is also becoming difficult to ignore. A two-day window between disclosure and observed attack activity once might have seemed unusually fast. Today, security teams should consider it normal. Attackers can analyze disclosures, compare patches and develop working exploits faster than many organizations can complete a traditional change-management cycle. If an affected GitLab server was publicly accessible before it was patched, updating it should be the beginning of the response, not the end. Hunt for the published indicators, review authentication and application logs, examine unusual repository changes, and investigate potentially exposed credentials or tokens. When the system involved controls the software development pipeline, assuming that patching alone closes the incident can be a dangerous bet.
Prompt Injection Bypasses Human Approval in AWS AI Agent Tool
AWS recently disclosed CVE-2026-18733, a vulnerability in the open-source Strands Agents Tools package that demonstrates how dangerous indirect prompt injection can become when AI agents are connected to powerful tools. Strands Agents allows developers to build AI agents capable of performing actions, including executing operating system commands through a shell tool. The shell functionality included a human consent mechanism intended to require an operator to approve commands before they ran. The problem was that the AI model itself could control a parameter capable of bypassing that approval.
In a realistic attack scenario, an agent could encounter malicious instructions embedded inside content it was asked to read, such as a webpage, document, ticket, code repository, or email. Those instructions could tell the model to set the shell tool’s non_interactive option to true, effectively bypassing the human approval gate and allowing operating system commands to execute on the machine hosting the agent. No stolen password or traditional software exploit was required. The attacker simply manipulated the AI into defeating the safeguard designed to keep it under human control.
AWS has addressed the issue in strands-agents-tools version 0.8.0 and recommends upgrading immediately, including updating any forked or derivative implementations. Until organizations can patch, AWS recommends removing shell access from agents that process untrusted content and running any agent with command-execution capabilities inside an isolated, least-privilege environment. Those recommendations should extend beyond this particular vulnerability. Organizations deploying AI agents should assume that content entering the model may contain hostile instructions and ensure that security decisions, authorization controls, and approval gates cannot be overridden by model-generated input.
Why it matters: This is a perfect example of why “human in the loop” is not enough if the AI can manipulate the mechanism that decides when the human gets involved. Agentic AI security needs independent authorization controls outside the model, strict tool permissions, sandboxing, outbound network restrictions, and logging of every sensitive action. As AI agents gain access to cloud environments, developer workstations, SaaS platforms, and production systems, the permissions granted to the agent may matter just as much as the security of the model itself.
3. AI-Generated Attack Tools Are Now Targeting the Systems That Run Critical Infrastructure
Federal cybersecurity agencies are warning that attackers are actively using AI-generated tools to target the industrial systems responsible for running portions of America's critical infrastructure. A joint advisory from the NSA, FBI, CISA, Department of Energy and EPA says threat actors are conducting reconnaissance against Siemens S7 Series programmable logic controllers, or PLCs, used across manufacturing, energy, water, chemical, agriculture and other critical sectors. The attackers are scanning the internet for exposed devices and using AI-assisted development to create exploitation scripts that can masquerade as legitimate industrial monitoring tools. Federal officials are making an important distinction here: this is no longer a hypothetical discussion about what AI might eventually enable. They say the activity is happening now.
The significance goes well beyond another vulnerability warning. PLCs control physical processes, including pumps, valves, motors and production equipment. Losing control of one can create consequences that look very different from a conventional data breach. Depending on the environment, an attacker could potentially disrupt operations, damage equipment, create safety issues or leave operators unable to accurately see what is happening inside a physical process. The advisory also arrives after federal officials warned in July about activity targeting PLCs from several manufacturers, including Siemens, Schneider Electric and Rockwell Automation. Siemens has since updated its own security bulletin to reference the new federal warning and the ongoing threat against its S7 family.
What AI changes is the economics of attacking these systems. Industrial control system exploitation has historically demanded specialized knowledge that narrowed the pool of people capable of developing useful attack tools. Generative AI can compress some of that work, helping an attacker analyze technical documentation, modify scripts and develop tools far faster than before. That does not mean AI has suddenly turned an inexperienced hacker into an expert industrial operator. It does mean the technical barrier is getting lower. A vulnerability or insecure configuration that once required significant research to exploit may now become accessible to a much larger population of attackers, and much sooner.
For critical infrastructure operators, the response starts with some decidedly non-futuristic security work. Federal agencies are urging organizations to remove PLCs from direct internet exposure, patch and update affected systems, segment OT networks from IT and external networks, strengthen access controls and monitor industrial environments for unusual activity. Organizations should also know exactly which PLCs they operate and how those devices can be reached, including connectivity introduced by integrators and third-party vendors. The lesson from this campaign is not simply that attackers have AI. It is that AI is making old weaknesses easier and faster to exploit. In environments where a cyberattack can become a physical event, reducing that exposure has become considerably more urgent.
Thanks for reading!
About us: Echelon is a full-service cybersecurity consultancy that offers wholistic cybersecurity program building through vCISO or more specific solutions like penetration testing, red teaming, security engineering, cybersecurity compliance, and much more! Learn more about Echelon here: https://echeloncyber.com/about