How the Telnyx Supply Chain Attack Exposes HIPAA Compliance Gaps

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 group 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 the steps covered entities must take to show due care under federal law.

HIPAA Supply Chain Attack: What Happened and Why It Matters

The Telnyx SDK breach was not a one-time event. It was stage three of a planned, multi-target effort by TeamPCP. The attack 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: Using tokens stolen in earlier stages, TeamPCP pushed bad versions of the Telnyx Python SDK to PyPI.

Security experts from Socket, Endor Labs, Aikido Security, and Wiz each confirmed TeamPCP's marks across all three stages. This showed it was 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 groups often use Telnyx for visit reminders, patient alerts, fax-to-digital tools, and telehealth systems. These messages often involve ePHI. That means Telnyx acts as a business associate under HIPAA. It offers BAAs to its healthcare clients.

What Is PyPI?

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

Most auto-build systems pull items from PyPI without manual review. 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 Unix-based systems, the malware stole SSH keys, cloud logins (AWS, GCP, Azure), Docker tokens, npm auth tokens, Git login files, and crypto wallet files.
• Windows staying power: On Windows systems, the malware set itself up to survive reboots and keep long-term access.
• Kubernetes abuse: In container setups, the malware tried to launch privileged pods in the kube-system namespace. This would give full access to all cluster items.
• 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 dev, staging, and live setup.
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 setups, 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 says covered entities must do a full review of risks to ePHI. This risk review duty extends to the supply chain. When a vendor's software is hit, you must check whether that breach creates a risk to ePHI in your own systems.

Groups 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 blame. 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 shield a covered entity from blame for its own failure to manage risks in its dev setup.

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 was not touching ePHI content directly, its presence in a system with ePHI access could meet the bar for a security event that must be reported.

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 setup have access to ePHI? If the bad SDK was only in a test setup 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 presumption rules, a covered entity must assume that any unauthorized access to unsecured ePHI counts as a breach. The only exception: a risk review shows a low chance the data was exposed.

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 people: They must be told without undue delay. The deadline is 60 days from the date the breach was found.
• Tell HHS: The Department of Health and Human Services must be told. Breaches that affect 500 or more people need notice within 60 days. Smaller breaches may be reported once a year.
• 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 from the date the covered entity finds the breach. It also starts from the date they should have found it with due care. For the Telnyx event, public release of the news was March 27, 2026. Any affected group's clock likely started on or around that date.

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 a way to verify breach notices on their own. 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 group'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 reviews that cover software supply chain threats
• Software tracking and version-pinning
• System splits that limit ePHI exposure from dev 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 face 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 (Within 72 Hours)

Under the 2026 Security Rule, groups must finish a first incident review within 72 hours. 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 sent ePHI to attacker-run servers.

Step 2: Determine Whether a Breach Occurred

Under HIPAA’s Breach Notification Rule, an improper sharing of ePHI is treated as a breach. The covered entity must show a low chance that ePHI was exposed to avoid this label. That finding needs a four-factor risk review:

1. What kind of PHI was involved and how much
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 low risk, notice is required. Tell affected people within 60 days of finding the breach. Tell HHS.

If 500 or more people in a state are affected, tell major media outlets in that state. The clock starts from the date the breach was found. For the Telnyx breach, public release of the news was 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 looks into it.

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

The Software Supply Chain HIPAA Checklist

Most healthcare groups have solid steps for vetting SaaS vendors. They use due care forms, 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 CISA’s Known Exploited Vulnerabilities (KEV) catalog. The 2026 HIPAA Security Rule calls this out as a resource for finding flaws.
• Pin versions in live setups. 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 review. Include odds and impact ratings.
• Set up a way to get security alerts from software vendors. Many groups 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 risk review. If the bad software was on a system with access to ePHI, and login details were stolen, the group must assume a breach. The only exception: the risk review shows a low chance of exposure. The 60-day notice deadline runs from the date 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 under 45 CFR §164.308(a)(1)(ii)(A).

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 groups 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. The 2026 HIPAA Security Rule calls it out as a tool groups should watch. If software you use shows up in the KEV catalog, you need a fast risk review under 45 CFR §164.308(a)(1)(ii)(A). Signing up for KEV alerts is a clear, audit-ready compliance step.

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

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 groups. 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