sklearn-pmml-duplicate-vector-id-poc

sklearn-pmml-model Duplicate VectorInstance id Silent Model Corruption

Status: Preparing for Huntr submission Package: sklearn-pmml-model (PyPI) File / function: sklearn_pmml_model/svm/_base.py, get_vectors() Class: CWE-706 (Use of Incorrectly-Resolved Name) + CWE-20 Severity: Medium-High — silent model-integrity corruption, not a crash.

Summary

get_vectors() resolves a PMML <VectorInstance> by id using ElementTree's XPath-like predicate lookup:

def get_vectors(vector_dictionary, s):
    instance = vector_dictionary.find(f"VectorInstance[@id='{s}']")
    ...

.find() returns the first matching element when multiple <VectorInstance> elements share the same id. There is no validation anywhere in the parsing path that id values are unique.

Meanwhile, the model's support-vector count (self.support_, built from findall('VectorInstance') — all instances, not deduplicated) and its declared numberOfSupportVectors/Coefficients still describe N distinct support vectors. The result: a PMML file can declare N support vectors with N distinct, real coefficients, while several <VectorInstance> elements silently collapse onto the same underlying data through duplicated ids — the model loads successfully and looks structurally complete, but some of its support vectors silently carry the wrong (first-matching) values instead of their own.

This is a silent data-integrity issue, not a crash — it can corrupt a model's actual decision boundary with zero visible error, directly matching Huntr's own stated Model Format Vulnerability scope ("attacks that occur at model load time or during inference, including backdoor manipulations and other malicious behaviors hidden").

How this was found

Found by systematically applying a structured vulnerability-review checklist (specifically its "what invariants must always hold, and can any operation silently violate them" question) to this library as a follow-up after an earlier, unrelated finding (a SparseArray size-validation bug, reported separately) in the same package.

Proof of Concept

poc_sklearn_pmml_duplicate_vector_id.py builds a complete, valid, minimal PMML SVM regression model with two <VectorInstance id="0"> elements holding different real values (1.0 and 999.0), and loads it through the library's real public API, sklearn_pmml_model.svm.PMMLNuSVR.

pip install sklearn-pmml-model numpy scikit-learn
python poc_sklearn_pmml_duplicate_vector_id.py

Result

model.support_        : [0 0]
model.support_vectors_: [[1.0], [1.0]]

CONFIRMED: both support vectors silently resolved to the SAME value (1.0) -- the second VectorInstance's real declared value (999.0) is completely unreachable, with no error or warning.

Impact

A crafted or corrupted PMML file can silently substitute duplicated or attacker-chosen values for what its own metadata claims are distinct, independently-trained support vectors — without any load-time error. This can be used to plant a backdoor or otherwise silently corrupt a model's predictions while the file still passes a casual structural inspection (correct declared vector/coefficient counts, well-formed XML).

Suggested fix

Validate that id attributes are unique across all <VectorInstance> elements within a <VectorDictionary> during parsing, and raise a clear error on a duplicate.

Relationship to other reports

Distinct from a separately-reported SparseArray n-attribute unbounded-allocation finding in the same package (CWE-789, a resource-exhaustion issue) — this is a data-integrity issue with a different root cause (identifier collision, not size validation). Same broad pattern family (duplicate identifier → silent "first wins" resolution → real data becomes unreachable) as separately-reported findings in gguf-py (tensor offset aliasing) and ollama/ollama's Go GGUF parser (duplicate tensor names) — but this is the first confirmed instance of it in an XML/PMML-based format.

Disclosure

Please do not use this PoC against production systems you do not own or have explicit permission to test.