Flagged models still reach downstream code
The paper asks a question that model scanning cannot answer: once a model has been publicly flagged as vulnerable, do developers actually stop using it? The authors tracked 16,977 HuggingFace models already flagged by InsightDB and followed them into GitHub repositories, software packages, fine-tuning chains, and deployed HuggingFace Spaces applications. The answer is that flagging does not stop adoption. 3,757 flagged models, or 22.1% of the set, appear at least once in a GitHub repository, and those references total 21,313 code occurrences spread over 5,040 unique repositories.
Two numbers here are easy to confuse. The 22.1% is a share of flagged models that have any code reference; the 21,313 is a count of code locations, and it exceeds the number of repositories because many repositories reference more than one flagged model. The most-referenced model, hf-internal-testing/tiny-random-OnnxStableDiffusionPipeline with 976 occurrences in 350 repositories, is a HuggingFace test model used mainly in CI/CD pipelines rather than production. Excluding such test models, lxyuan/distilbert-student is the most widely used, with 594 occurrences in 449 repositories.
Four reuse surfaces carry the same model
The study measures exposure along four dimensions rather than one. Beyond direct code usage, 68 flagged models (0.4%) appear in repositories that produce software packages, yielding 185 packages across 111 repositories, mostly container images distributed via GitHub Packages. On HuggingFace, 3,765 flagged models (22.2%) declare a parent or base model, and 57 of those parents are themselves flagged, so vulnerabilities can be inherited through fine-tuning lineage. In the other direction, 136 flagged models (0.8%) were used as the base for at least one fine-tuned child, producing 419 derivatives; 43 of those children are also flagged, and the full child set has been downloaded 22,963 times. Finally, 657 flagged models (3.9%) are referenced in at least one Space, creating 1,766 model–Space links across 1,239 unique Spaces that have accumulated 10,837 likes.
These dimensions are not separate populations. The authors use lxyuan/distilbert-student to show one model spanning all four at once: 449 repositories including established projects, container images published from that source, 82 Spaces, and 24 fine-tuned children. Among those 24 variants, only four migrated to the SafeTensor format while the rest kept the .bin format, and several triggered pickle import warnings. The paper presents this as a plausible risk pathway in which an unsafe checkpoint is deserialized at runtime and then serves inference to end users, not as a demonstrated exploit.
How the authors mined integration patterns
To learn how vulnerable models are wired into code, the authors did not read repositories by hand. They built a pipeline that extracts Code Property Graphs, a program representation that records how values flow and how control branches, and then applied a tailored Frequent Subgraph Mining step to find recurring structures around flagged model identifiers. The mining produced 809 patterns, which post-processing reduced to 195 maximal patterns and then organized into four motifs based on the graph relations that dominate each one.
The motifs describe distance and routing between the model name and the API that consumes it. Direct Usage (M1) passes the identifier straight into a call, the shortest source-to-sink path. Local Propagation (M2) first stages the identifier in a local variable and forwards it, the most broadly distributed motif at 12 frameworks, with the highest support in Transformers (115), Sherpa (76), and HF Hub (60). Method Propagation (M3) crosses at least one application-defined method boundary. Condition-Guarded Propagation (M4) places the use under branch control logic. M1 appears across 11 frameworks, led by Transformers (121) and HF Hub (66).
Security settings are delegated, not enforced
Across all mined patterns, the authors report no evidence of provenance verification or model sanitization logic. What they find instead is that security decisions are left to call-site parameters or framework defaults, and often the permissive option is chosen. In a Direct Usage example, a flagged model name is passed to from_pretrained together with trust_remote_code=True, a Transformers parameter the documentation describes as permitting arbitrary code execution during loading from remote repositories; the same co-occurrence appears in a SentenceTransformer instantiation. In the Datasets framework, the identifier goes straight into dataset loading with the verification_mode parameter omitted, which the paper says defaults to a rudimentary check on remote metadata and skips downloaded file integrity.
The propagation motifs matter because they reduce visibility. In Local Propagation, the identifier becomes an ordinary local value before reaching a security-sensitive API, so a reviewer or static tool must reconstruct the local data-flow chain to connect the sink back to the unsafe source. One example downloads a flagged model via hf_hub_download and forwards the resulting path into joblib.load, which the paper notes relies on pickle and should not load untrusted files. In Keras patterns, the safe_mode parameter is absent from the call site, again leaving the framework default in charge. The authors also observe cross-framework concentration: framework-specific configurations collapse onto a small set of shared retrieval and loading APIs, which they suggest could let defenders harden a few sinks to protect many frameworks.
Which references are actually exploitable
A code reference is not the same as an exploitable use, and the paper separates the two. For 289 models in the integration corpus, the authors checked whether a reference was vulnerability-relevant: 237 carried deserialization issues, 59 runtime issues, and none backdoor threats. They then examined the frameworks with loading paths applicable to those threats, analyzing Transformers, PyTorch, and Ultralytics for deserialization and Keras and TensorFlow for runtime issues. A reference counted as vulnerable only when the model was flagged for a specific vulnerability and was then loaded through a framework- or format-compatible path susceptible to that vulnerability, lacking the corresponding safeguard or explicitly enabling unsafe behavior. Artifact-acquisition frameworks such as huggingFace_hub, which download but do not consume models, were excluded.
This definition sets the boundary of the headline numbers. The 21,313 code occurrences measure exposure, not confirmed exploitation, and the paper's own framing treats the deserialization pathway as plausible rather than demonstrated. The authors also state that their measured exposures are likely a lower bound, because artifact reuse is only partially documented and can occur through configuration files, external downloads, and weak metadata that evade code-level detection.
Why model-level scanning is not enough
The paper's central argument is that warnings stay attached to model artifacts while exposure spreads across reuse surfaces that no single view connects. A model flagged for insecure deserialization poses little practical risk if it is never loaded, but becomes a concrete threat when a developer passes it to a loading API with permissive settings, which the authors report as common in practice. Because code references, packaged artifacts, derivative models, and deployed applications are only partially linked by existing metadata or tooling, the propagation paths become visible only when multiple unconnected data sources are aggregated.
The authors therefore call for context-aware security analysis and stricter integration guardrails at the application layer, rather than more scanning of model files alone. Their motif taxonomy is the concrete basis for that priority: it identifies which sink APIs recur across frameworks and which routing patterns hide the unsafe source, giving application-layer checks specific structures to target.
Where the priority shifts for defenders
The most decision-relevant split in this study is between flagging and integration. A flagged model that is downloaded but never consumed, as in the excluded acquisition-only frameworks, sits in a different risk class from one passed directly into a loader with trust_remote_code=True or an omitted safe_mode. The paper's evidence puts the priority on the call site and the shared sink APIs where frameworks converge, because that is where the mined patterns show safeguards are absent or delegated to permissive defaults. The 22.1% code-reference rate and the 3.9% Space-deployment rate describe how far flagged artifacts travel; the motif analysis describes where a guardrail would actually interrupt that travel.
Sources used in this answer
Vulnerable Models in the AI Supply Chain: An Empirical Study of Adoption, Propagation, and Usage Patterns
Of 16,977 HuggingFace models flagged as vulnerable, 3,757 (22.1%) are referenced in at least one GitHub repository, totaling 21,313 code occurrences across 5,040 repositories, and none of the mined integration patterns show provenance verification or model sanitization logic.