How the Telnyx Supply Chain Attack Exposes HIPAA Compliance Gaps

The Telnyx attack shows that HIPAA risk can come in through the software you trust, not just your own systems. A BAA alone does not cover that gap. Practices need a risk analysis that includes vendor software, a plan for supply chain incidents, and a timely breach review when a vendor is hit.

On March 27, 2026, threat actor group TeamPCP ran a supply chain attack on the Telnyx Python SDK. The SDK is hosted on PyPI, the Python Package Index. Bad versions 4.87.1 and 4.87.2 were pushed out using stolen login details. The attackers hid data-stealing malware inside what looked like normal software updates.

For any healthcare practice using Telnyx for messaging, this matters. Voice, SMS, or fax APIs may touch ePHI. That makes this more than a security issue. It is a HIPAA crisis that calls for fast action and a written response.

This article looks at the Telnyx PyPI breach through the lens of HIPAA rules. It names the gaps that supply chain attacks exploit. It also covers what covered entities must do to show reasonable diligence under federal law. Reasonable diligence means normal, careful attention. Covered entities are health plans, clearinghouses, and providers who bill electronically.

HIPAA Supply Chain Attack: What Happened and Why It Matters

The Telnyx SDK breach was not a one-time event. It was a later stage in a planned effort by TeamPCP that hit many targets. The main stages played out as follows:

• Stage 1: TeamPCP broke into a widely used security scanner. They gained access to developer systems and stole login details.
• Stage 2: The group went after LiteLLM AI Gateway. They poisoned another trusted open-source package and grew their reach.
• Stage 3: TeamPCP used stolen publishing access to push bad versions of the Telnyx Python SDK to PyPI.

Public research from security firms, including Socket, Endor Labs, Aikido Security, and Wiz, tied these stages to TeamPCP. It points to a planned, step-by-step supply chain attack. Its goal was to steal as many login details as it could.

What Is Telnyx?

Telnyx is a cloud phone platform. It offers APIs for voice calls, SMS/MMS messaging, fax, video, and number control.

Healthcare practices may use Telnyx for visit reminders, patient alerts, fax-to-digital tools, and telehealth systems. These messages can include ePHI, which is patient health information in electronic form. When they do, Telnyx can be a business associate under HIPAA. That means a vendor that handles patient data for you. You then need a signed BAA (business associate agreement) with Telnyx.

What Is PyPI?

PyPI (Python Package Index) is the main software source for Python packages. Developers install packages from PyPI using the pip command.

Many automated build systems pull packages from PyPI without a person checking them first. When a real package on PyPI is hit, every system that installs or updates that package gets the bad code. This makes PyPI a high-value target for supply chain attacks.

Who Is TeamPCP?

TeamPCP is a threat group that targets software supply chains and developer tools. They break into upstream tools and repos to spread malware through trusted channels. They abuse the trust that developers place in package managers and open-source systems.

Technical Details of the Attack

The bad payload in Telnyx SDK versions 4.87.1 and 4.87.2 showed a high level of skill:

• Hidden in audio: The malware payload was tucked inside WAV audio file data. This evaded standard code-scanning and antivirus tools.
• Linux/macOS targeting: On Linux and macOS, the malware ran a tool that collected secrets such as SSH keys, cloud logins, browser logins, and crypto wallets. It encrypted what it found and sent it out.
• Windows staying power: On Windows systems, the malware set itself up to survive reboots and keep long-term access.
• Kubernetes risk: Earlier TeamPCP malware in this same campaign went after Kubernetes clusters. If the bad SDK ran in a container system, check the cluster too, including the kube-system namespace.
• Runtime payload delivery: The malware did not bundle the full payload in the package. Instead, it pulled extra parts from a command-and-control (C2) server at runtime. This made static scans less helpful.

For healthcare teams, this is a big concern. Any dev or live system that installed the bad SDK versions may have had login details stolen. Those details could open access to systems that store or send ePHI.

Immediate Remediation Steps

If you use the Telnyx Python SDK, take these steps right away:

1. Check installed version: Run pip show telnyx to see if version 4.87.1 or 4.87.2 is installed. Check every development, test, and live system.
2. Downgrade right away: If a bad version is found, downgrade to the last known safe version: pip install telnyx==4.87.0.
3. Rotate all login details: Assume any secrets in the affected system have been stolen. Change SSH keys, API tokens, cloud logins, database passwords, and any other secrets.
4. Check for hidden access: Look for unknown cron jobs, systemd services, and startup scripts. In Kubernetes systems, check for odd pods in the kube-system namespace.
5. Watch outbound traffic: Review firewall logs and network tools for odd outbound links. Unknown IPs or domains may signal ongoing C2 contact.

HIPAA Compliance After a Supply Chain Attack

A HIPAA supply chain attack creates duties that go beyond normal incident response. Covered entities and their business associates must weigh the event against the HIPAA Security Rule and Breach Notification Rule. A structured vendor management program helps you track these duties.

Vendor Risk Assessment: 45 CFR §164.308(a)(1)(ii)(A)

The HIPAA Security Rule requires covered entities to do an accurate and thorough risk analysis. That is a written look at the risks to your ePHI. Risks from your vendors and the software you use belong in it. When a vendor's software is hit, you must check whether that breach creates a risk to ePHI in your own systems.

Practices that lack a written vendor risk assessment process face a big compliance gap. The same is true if they have not updated their reviews to cover supply chain threats. The Telnyx event shows that attacks can start from a vendor's own channel. Old perimeter-based risk models fall short.

BAA Limitations: 45 CFR §164.308(b)(1)

Many think that having a BAA with a vendor like Telnyx shifts HIPAA responsibility. It does not.

Under 45 CFR §164.308(b)(1), a BAA sets the business associate's duty to protect ePHI. But a BAA does not protect a covered entity from its own mistakes. It is still responsible for managing risks in its own development systems.

Say a covered entity's developer put the bad Telnyx SDK in a system with access to ePHI. The covered entity is at fault. They failed to put proper safeguards in that system. The BAA governs Telnyx's duties for data Telnyx handles. It does not cover the covered entity's own system security.

Transmission Security: 45 CFR §164.312(e)(1)

The Telnyx SDK may have been used in a pipeline that sent ePHI. Think patient visit reminders via SMS, or faxed medical records. This raises issues under the Transmission Security standard.

This rule says covered entities must use technical controls to block unwanted access to ePHI sent over a network. A bad SDK in the data pipeline is a possible failure of this safeguard.

Even if the SDK did not touch ePHI directly, having it on a system with ePHI access could count as a security incident. HIPAA requires you to find and respond to security incidents. You must also write down each incident and how it turned out (45 CFR §164.308(a)(6)(ii)).

Determining Whether ePHI Was Compromised

Not every install of the bad SDK counts as a HIPAA breach. You must work through a step-by-step review:

1. Was the bad version installed? If no developer or system used Telnyx SDK version 4.87.1 or 4.87.2, no further HIPAA action is needed. Document the review.
2. Did the affected system have access to ePHI? If the bad SDK was only in a test system with no access to live data, the risk may be limited. But you must document this.
3. Was ePHI taken? If stolen login details gave access to systems holding ePHI, treat this as a possible breach. This is true even with no direct proof that ePHI was accessed.

Under HIPAA's breach rules, a covered entity must presume a breach whenever unsecured ePHI is used or shared in a way HIPAA does not allow. Presume means you treat it as a breach unless you can show otherwise. The main way out is a written risk assessment. It must show a low probability that the PHI has been compromised.

Healthcare Vendor Breach Notification: 45 CFR §§164.400–414

If the review finds that a breach of unsecured ePHI took place, your HIPAA data breach response plan must be turned on. The notice rules under 45 CFR §§164.400–414 then apply:

• Tell affected individuals: Tell them without unreasonable delay. The latest you can tell them is 60 calendar days after you find the breach.
• Tell HHS: The Department of Health and Human Services must be told. If a breach affects 500 or more people, tell HHS at the same time you tell patients. The same 60-day limit applies. For smaller breaches, keep a log. Report them to HHS no later than 60 days after the calendar year ends.
• Tell the media: Breaches that affect more than 500 residents of one state need notice to major media outlets in that area.

The 60-day clock starts on the first day you know about the breach. It also counts from the day you would have known if you had paid normal, careful attention. The law calls this reasonable diligence. News of the Telnyx attack went public around March 27, 2026. Do not wait: your clock may already be running.

The Trust Problem with Breach Notifications

One missed issue with vendor breach notices: real notice emails often look like phishing. When a vendor emails that systems have been hit and urges fast action, staff are trained to doubt that kind of message.

Healthcare teams should set up their own way to verify breach notices. Do not click links in the email. Go straight to the vendor's website. Check the vendor's status page. Contact the vendor's security team through known channels. Write this check into the incident response plan.

Key Takeaway: Supply Chain Attacks Expand the HIPAA Attack Surface

The Telnyx PyPI breach by TeamPCP shows a big shift in the healthcare threat picture. A HIPAA supply chain attack does not need a direct hit on a healthcare practice's systems. It uses the trust and software links that modern healthcare systems rely on.

Healthcare teams cannot stop every supply chain attack. But they can show compliance through written proof of:

• Regular vendor risk analyses that cover software supply chain threats
• Software tracking and version-pinning
• Separate systems that limit ePHI exposure from development tools
• Incident response plans that cover supply chain breach cases
• Timely breach review and notice steps

The gap between having a BAA on file and truly managing supply chain risk is what events like this lay bare. Covered entities that rely only on contracts without real safeguards risk both fines and the fallout of a HIPAA supply chain attack.

What HIPAA Requires When Your Software Vendor Is Compromised

The Telnyx PyPI event shows a case that HIPAA’s risk rules were built to cover. But most covered entities have not planned for it. A trusted software vendor’s package is hit upstream before it reaches your systems.

Your HIPAA duties depend on whether ePHI was accessed, changed, or stolen. Work through these four steps in order. Write up every finding.

Step 1: Assess ePHI Exposure Right Away

Start your review as soon as you learn of the attack. The current Security Rule requires you to find and respond to security incidents (45 CFR §164.308(a)(6)(ii)). The key question: did the bad code have access to ePHI in your system?

For Telnyx SDK users, check if the Python SDK was linked to any system that stored or handled patient data. If yes, bad versions 4.87.1 and 4.87.2 may have exposed ePHI or the login details that protect it.

Step 2: Determine Whether a Breach Occurred

Under HIPAA’s Breach Notification Rule, any use or sharing of ePHI that HIPAA does not allow is presumed to be a breach. That means you treat it as a breach unless you can show otherwise. To do that, the covered entity must show a low probability that the PHI has been compromised. That finding needs a risk assessment that looks at least at these four factors:

1. What kind of PHI was involved and how much, including how easily it identifies a person
2. Who accessed or used it (or who got it)
3. Whether the PHI was actually taken or seen
4. How much the risk has been cut

Step 3: Notify if Required

If the four-factor review does not show a low probability of compromise, you must give notice. Tell affected individuals without unreasonable delay, and no later than 60 days after finding the breach. Tell HHS.

If more than 500 residents of a state are affected, tell major media outlets in that state. The clock starts from the date the breach was found. News of the Telnyx attack went public around March 27, 2026.

Step 4: Document the Incident

Even if the review finds low risk and no notice is needed, write up the event. Document the review process and the result. This record is your proof of compliance if OCR ever investigates. OCR is the HHS Office for Civil Rights, which enforces HIPAA.

Practices using a vendor management program have a big edge here. The records framework is already in place.

The Software Supply Chain HIPAA Checklist

Many healthcare practices have steps for checking out SaaS vendors, meaning online software services. They use security questionnaires, BAA signing, and regular reviews. Fewer have the same checks for software libraries and SDKs. The Telnyx event is a clear reminder: the attack surface extends to code you depend on.

For Technical Teams and CISOs

• Keep a software bill of materials (SBOM) for all apps that process ePHI. Know which third-party libraries are in your stack.
• Set up dependency tracking (Dependabot, Snyk, or the like). Get alerts when updates are pushed or when flaws are found.
• Sign up for alerts from CISA’s Known Exploited Vulnerabilities (KEV) catalog. It is a federal list of software flaws used in real attacks. It helps you find flaws to fix.
• Pin versions in live systems. Do not auto-update packages that touch PHI without review.
• Keep PHI-handling parts separate from general code with broad outside links.
• Check package integrity with checksums or verified signing before you deploy.
• Add software supply chain attack as a named case in your incident response plan. Include a specific playbook.

For Compliance Teams

• Check whether your BAAs with software vendors cover the vendor’s own supply chain. Most standard BAAs do not. See the most common Business Associate Agreement mistakes to avoid.
• Add a “software supply chain event” case to your risk analysis. Include odds and impact ratings.
• Set up a way to get security alerts from software vendors. Some practices learn of breaches from the news, not vendor alerts.
• Write up your tracking as a control in your Security Rule compliance records.

FAQs

Does a vendor supply chain attack trigger HIPAA breach notification?

It depends on whether unsecured ePHI was taken, accessed, used, or shared. Under 45 CFR §§164.400–414, the covered entity must do a breach risk assessment. Was the bad software on a system with access to ePHI? Could stolen login details open that ePHI?

If so, the covered entity should presume a breach. That means treating it as a breach unless shown otherwise. The way out is a risk assessment that shows a low probability that the PHI has been compromised. Notice is due without unreasonable delay. The latest is 60 days after the breach was found.

What should a healthcare organization do right away when a vendor is compromised?

Take five steps right away.

• First, find out if the bad software version is on any system.
• Second, isolate or roll back the software.
• Third, change all login details on the affected system.
• Fourth, check for hidden access like rogue processes, cron jobs, or Kubernetes pods.
• Fifth, start the HIPAA breach review.

Document all steps and findings. HIPAA requires you to document security incidents and how they turned out (45 CFR §164.308(a)(6)(ii)).

Does having a BAA with Telnyx protect a healthcare organization from HIPAA liability?

No. A BAA sets the business associate's duty to protect ePHI that it handles. But if a covered entity's own developer puts bad software in a system that accesses ePHI, the risk falls on the covered entity. The BAA governs the vendor’s duties. It does not replace the covered entity’s own security program.

What is a HIPAA supply chain attack?

It happens when a threat actor breaks into a vendor, software package, or service that a covered entity depends on. Through that breach, they gain access to ePHI or disrupt its access. The 2026 Telnyx PyPI event is a clear example. Attackers hit the Telnyx Python SDK by pushing bad versions with data-theft code.

Does HIPAA require a BAA with software library vendors?

This is a gray area. HIPAA’s BAA rule applies to vendors that create, receive, keep, or send ePHI on behalf of a covered entity. A software library runs in your system. The vendor does not “receive” your PHI in the usual sense.

But when a library sends data to attacker-run servers, the real risk is there no matter the BAA status. The safe move: treat any software part with ePHI access as a BAA candidate. At minimum, run a written vendor security check as part of your HIPAA risk assessment program.

What is the CISA KEV catalog and how does it relate to HIPAA?

The CISA Known Exploited Vulnerabilities (KEV) catalog lists software flaws used in real attacks. HIPAA does not name it. Changes to the Security Rule were proposed in January 2025, but they are still only proposed, not law. The current rule does require an accurate and thorough risk analysis (45 CFR §164.308(a)(1)(ii)(A)). If software you use shows up in the KEV catalog, update your risk analysis to cover it. Signing up for KEV alerts makes that easier.

Sources

• 45 CFR Part 164, Subpart C: Security Standards for the Protection of Electronic Protected Health Information (eCFR)
• 45 CFR Part 164, Subpart D: Notification in the Case of Breach of Unsecured Protected Health Information (eCFR)
• HHS Breach Notification Rule Guidance (U.S. Department of Health and Human Services)
• Socket Security: Supply Chain Attack Research and Disclosures
• Endor Labs: Open Source Security Research
• Aikido Security: Software Supply Chain Threat Intelligence
• Wiz: Cloud and Kubernetes Security Research

---

Cybersecurity Threats and Lessons

• Cloudflare Outage 2026: Business Lessons
• Kadnap Botnet: Healthcare Threat Analysis
• UMMC Ransomware Attack Lessons
• Vercel Security Incident Analysis

Related Reading

• Is MFA Required for HIPAA? A Plain-English Guide
• Cloudflare Outage 2026: Business Continuity Lessons
• HIPAA Security Rule Implementation Guide

---

About the Author

Chuck Weiselberg is a C.H.P. (Certified HIPAA Professional) and Founder of One Guy Consulting, a HIPAA compliance SaaS solution. He has 20+ years experience supporting customers in achieving their goals. Ten of those years were spent as a HIPAA compliance S.M.E. (Subject Matter Expert).

He has helped support thousands of users at healthcare organizations. He aided Compliance Officers in building sensible compliance solutions. None of them failed an audit or received a fine. This success comes from a repeatable and proven process, realistic policies, and intuitive compliance management software that requires no tech know-how.

---

One Guy Consulting | All Rights Reserved 2026      Home  |  Blog  |  Privacy Policy  |  Terms