Did the LiteLLM Breach Affect Indian Companies? What the Exposure Data Shows 

Yes, Indian organizations appear in CloudSEK’s public LiteLLM exposure data, but the seven India based records belong within the broader TeamPCP incident set rather than representing seven confirmed direct LiteLLM compromises. The verified subset includes six companies and one state government entity. Their summary fields account for 67 CI/CD runs and 45 secret observations recorded from March 19 to March 24, 2026.

Two records carry a High confidence exposure match. Such a rating strengthens their association with CloudSEK’s incident findings, but it is not equivalent to malicious package execution, credential theft, or a successful intrusion.

CI/CD runs and secret observations capture separate measurements. A CI/CD run refers to a pipeline or workflow execution associated with a listed organization. A secret observation represents a credential related finding recorded in the summary fields. Neither metric counts unique compromised pipelines or verified stolen credentials.

Together, these findings establish a measurable Indian footprint within the incident. Presence in the portal confirms exposure linkage, whereas direct attribution to poisoned LiteLLM packages depends on package specific or execution level telemetry for each named organization.

Which Indian Companies Appeared in the LiteLLM Exposure Data?

Seven India based organizations met the geographic verification criteria used for this analysis: Government of Assam, Cashfree Payments, Centra Logic India, Motherson, WFX, diploy, and wizcommerce. Their business profiles span government, fintech, enterprise technology, automotive manufacturing, fashion technology, SaaS, and B2B commerce software. 

Timing changes the interpretation. Six exposure windows fall on March 19 or March 19 to 20, before the poisoned LiteLLM versions appeared on March 24. wizcommerce is the only listed Indian record dated March 24, yet sharing the release date does not demonstrate installation or execution of the malicious package.

These names identify the Indian portion of the broader TeamPCP exposure set. Confirmed LiteLLM victim status would need telemetry tying an individual company directly to the poisoned package or its execution.

How Concentrated Was the Exposure Across Indian Companies and Sectors?

Most of the measured volume comes from a relatively small part of the verified India subset, with secret observations showing the sharpest concentration. Sector representation is diverse, but each normalized category contains only one company, so company level distribution tells us more than an industry ranking.

• CI/CD activity clusters around a few records. The average is about 9.6 runs per organization, compared with a median of 6. The three highest run counts represent 50 of 67 runs, or 74.6%, and the top five contribute 61 runs, or 91%.
• Secret observations are even more concentrated. The median is 1, compared with an average of about 6.4. Three records contribute 43 of 45 summary level observations, or 95.6%, and two show zero in the corresponding portal field.
• Sector breadth does not establish sector depth. Government, Fintech, Enterprise Technology, Automotive Manufacturing, Fashion Technology, SaaS, and B2B Commerce SaaS each have one representative. Ranking those categories would effectively turn individual company values into sector conclusions.

A limited number of records account for most of the observed volume. The sample supports a clear company level concentration finding, but it does not show that one Indian industry experienced greater exposure than another.

What Did the Data Reveal About CI/CD and Secret Exposure?

CI/CD activity and secret observations answer different technical questions. Run counts show workflow executions associated with a listed record, whereas secret observations indicate credential related material surfaced in the incident findings. A larger value in one field does not automatically imply greater severity in the other.

Security impact depends on the type of credential involved and the permissions attached to it. Cloud credentials, source control tokens, Kubernetes credentials, private keys, and application secrets can expose very different resources. Assigning any such category to a named Indian company calls for an explicit record level observation rather than an inference from aggregate counters.

CloudSEK’s malware research provides context for the collection logic. Compromised supply chain components were designed to search development environments for sensitive material including private keys, cloud credentials, Kubernetes configuration, and .env files. Those collection targets describe malware behavior, not proof of what was collected from a particular Indian company.

Deeper attribution rests on telemetry connecting a named record to a specific package, workflow, repository, credential read event, or outbound transfer. Without those links, the findings support CI/CD and credential related exposure but not organization specific claims about payload execution or secret collection.

What Does the Exposure Data Prove About Actual Compromise?

Current evidence reaches exposure linkage, not confirmed compromise. CloudSEK connects the listed Indian organizations to the incident set, but a successful breach claim needs confirmation of what happened after that association.

1. Exposure linkage: an organization appears in the incident dataset.
2. Malicious execution: telemetry shows the poisoned package or payload actually ran.
3. Credential or file collection: records demonstrate sensitive material was read or captured.
4. Exfiltration or unauthorized use: findings confirm external transfer or subsequent misuse.

High, Medium, and Low confidence labels indicate the strength of attribution for the listed records. They do not show progression from exposure to execution, collection, or exfiltration.

Use of the word breach should follow the same evidentiary boundary. The overall event can be described as the LiteLLM or AI supply chain breach, but an Indian company should not be labeled a confirmed breach victim solely because it appears in the incident set.

For this cohort, CloudSEK has established exposure linkage. Successful LiteLLM compromise at the individual company level remains unverified without execution or downstream impact confirmation.

How Was the India Exposure Dataset Built and Validated?

CloudSEK’s India analysis applied a conservative verification method to the exposure records. Inclusion depended on clear support for Indian headquarters, legal registration, or government ownership. Measurements were preserved in their original form instead of being expanded into broader interpretations.

India Record Selection

Geographic classification relied on organizational identity rather than office presence or commercial activity alone. Businesses with substantial Indian ties but ambiguous international headquarters or legal status were excluded from the confirmed subset. A local office by itself was not treated as sufficient confirmation of Indian company status.

Metric Treatment

CI/CD runs were counted as workflow executions associated with a listed organization. Secret observations came from the summary counter shown for each record and were not converted into totals of unique stolen credentials.

Summary values remained the basis for aggregation where detailed panels showed larger occurrence counts. Keeping one measurement level across the analysis avoids treating repeated sightings or differently presented detail fields as additional unique credentials.

Attribution Boundaries

Record timing was not treated as confirmation of poisoned LiteLLM package installation. TeamPCP related exposure also remained distinct from direct LiteLLM compromise unless package specific telemetry supported the connection.

High, Medium, and Low classifications were preserved as presented by CloudSEK. These labels describe attribution strength and do not substitute for confirmation of execution, collection, or exfiltration.

Research Scope

This analysis focuses on India linked exposure supported by clear organizational or government identity. Confidence classifications, CI/CD activity, and summary level secret observations retain the meaning assigned to them in the underlying records.

Readers should interpret the findings as an India specific view of the supply chain incident analyzed by CloudSEK. Direct LiteLLM attribution rests on a clear connection between a named company and the poisoned package or its execution. Confirmed compromise goes further by establishing collection, exfiltration, or subsequent unauthorized use.

Final Thoughts

Indian companies and a state government entity appear in CloudSEK’s incident findings, giving the supply chain event a measurable India dimension. Exposure is unevenly distributed, with a small subset of records accounting for most of the CI/CD activity and secret observation volume, while the sector spread is broad across industries.

Overall, Indian organizations are present in the broader incident dataset, and confirmation of seven LiteLLM breaches would require direct evidence of package execution, credential collection, data exfiltration, or other downstream compromise activity.