Pith. sign in

REVIEW 4 major objections 5 minor 53 references

Poisoned training code can leak any global property of a private dataset with 100% accuracy, without degrading the model.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-01 21:45 UTC pith:5KYYKBLG

load-bearing objection Real code-backdoor demo, but the '100% property inference' is a hardcoded data exfiltration channel, not an inference attack — needs reframing before the claims can be trusted. the 4 major comments →

arxiv 2607.15970 v1 pith:5KYYKBLG submitted 2026-07-17 cs.CR cs.LG

Code-Poisoning Property Inference Attacks

classification cs.CR cs.LG
keywords property inference attackcode poisoningsupply-chain attackprivacy leakagelabel-only attackmachine learning securitytraining codesecret samples
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper introduces CPPIA, a property inference attack that works by tampering with the code a victim uses to train their model rather than with the data or the model weights. The poisoned code reads the training set's global statistics (for example, the fraction of records matching a certain attribute), encodes that number into a binary string, and assigns those bits as the labels of ten secret outlier samples. It then inserts a hardcoded branch into the model's forward pass that forces the model to output those exact labels whenever the attacker later queries with the secret samples. The paper claims this achieves 100% attack accuracy with zero degradation of model accuracy, no shadow models, negligible compute, and complete evasion of three state-of-the-art defenses. A sympathetic reader would care because it reframes property inference as a supply-chain problem: the leak happens at code level, not in the learned weights.

Core claim

The paper's central claim is that an adversary who supplies untrusted training code can achieve perfect property inference by decoupling the property information from the learning process entirely. After the code computes the target property statistic from the victim's dataset, it encodes the value (scaled to three decimal places and converted to a 10-bit binary string) as labels of ten secret outlier samples that are physically impossible in the real world. A code-inserted `discriminative_layer` in the model's `forward()` method pattern-matches these inputs and overwrites the model's output with the precomputed label vector, so that after deployment the attacker merely queries the label-onl

What carries the argument

The load-bearing mechanism is the `discriminative_layer`, a hardcoded branch inserted into the model's `forward()` method that recognizes the secret samples by exact feature match and forces the corresponding labels (a binary encoding of the target property) into the output. Its companion is the encoder/decoder scheme: `get_property()` computes the statistic on the training set; the statistic is scaled, binarized, and assigned as labels to ten outlier secret samples; after deployment the attacker queries those samples and decodes the returned bits. The branch is deliberately invisible to `print(model)` and is disguised as a benign architectural modification to evade code auditing.

Load-bearing premise

The entire 100% accuracy depends on the victim deploying the model exactly as the poisoned code builds it, preserving the hardcoded label-forcing branch in the forward pass; any weights-only serialization, format conversion, or clean re-implementation would remove the channel and collapse the attack.

What would settle it

Train a victim model with the poisoned code, then serve it through the standard pathway of saving only the state_dict (weights) and loading it into a clean model class in a fresh serving script; query the trained artifact with the ten secret samples. If the returned labels are not the embedded binary sequence, the claimed 100% attack accuracy under realistic deployment fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Any data holder who trains with unvetted third-party code can have their dataset's global statistics permanently embedded in the released model and recoverable later under label-only access.
  • Model-accuracy monitoring cannot detect the attack, since the poisoned model's accuracy is identical to a clean baseline.
  • Existing property-inference defenses (Inf2Guard, ExpM, DPSGD) are claimed to be completely ineffective because the leak does not flow through learned representations.
  • The same code-level channel is claimed to generalize beyond tabular classifiers to GANs, transformers, text-to-image models, and regression tasks.
  • The attack requires no shadow models, no control of the training set, and no access to logits, making it computationally nearly free for the adversary.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the claim holds, the practical fix is not a stronger property-inference defense but a deployment discipline: serving the model from weights-only artifacts or a clean re-implementation would sever the hardcoded channel; a systematic study of which standard deployment pipelines preserve or destroy the attack would be a valuable test.
  • The same embedding trick could presumably carry any metadata the adversary wants, not just a single statistic, so code auditing tools would need to look for exact-match input branches that bypass the learned layers, rather than for statistical anomalies in weights.
  • The reliance on outlier samples with contradictory attributes suggests that anomaly detection on user inputs could flag secret samples; the authors report that using normal samples instead still works, but a rigorous third-party replication with a modern anomaly detector would settle the point.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes Code-Poisoning Property Inference Attack (CPPIA), a method in which an adversary who supplies training code to a data holder also embeds code that (1) computes a target property statistic t from the data holder's training set (get_property), (2) encodes t into a binary label sequence assigned to ten secret outlier samples, (3) injects a "discriminative_layer" into the model's forward() method that overwrites the model's outputs for those secret samples with the encoded labels, and (4) later queries the deployed API with the secret samples and decodes the returned labels to recover t. The paper claims 100% attack accuracy, zero model utility degradation, negligible computational cost, and robustness to Inf2Guard, ExpM, and DPSGD, and reports experiments across four datasets, eight architectures, and eighteen properties.

Significance. If the central claim were correct, CPPIA would introduce a dangerous new code-level attack vector for property inference, with implications for code-hosting platforms and coding agents. The paper does identify a real risk: malicious training code can exfiltrate dataset statistics by embedding them in the model's source-level behavior. However, the actual mechanism is not a property inference attack in the sense used by the prior work it compares against (SNAP, Mahloujifar, Tian). The recovered value is computed by the poisoned code at training time and hardcoded into the forward pass; the 'attack accuracy' is true by construction, not by inference from model behavior. The paper also never justifies that the deployed artifact preserves the exact poisoned source module. The evaluation against defenses is therefore not a test of a learned property channel. The paper provides a useful demonstration of a source-code backdoor/exfiltration channel, but the central claims of a 'nearly perfect PIA' that 'overcomes four limitations' are not supported.

major comments (4)
  1. [Algorithm 1, lines 6-14; Section IV-C; Figure 3] The attack is circular: t is computed by get_property(D) in the poisoned code, encoded into labels, and the decoder simply inverts Encoder to recover t. There is no inference step over the trained model's behavior. The '100% attack accuracy' is equivalent to reading back the input t by definition. This is not property inference as formulated in prior work (e.g., SNAP), where the adversary must infer a property from the model's outputs on normal inputs. The manuscript must either reframe the contribution as a source-code backdoor/exfiltration channel or provide an evaluation in which the learned weights, rather than a hardcoded branch, carry the property information.
  2. [Section III-C and Section IV-D, Figure 5] The claimed attack holds only if the victim deploys the exact poisoned Python module at serving time. Section III-C states only that the platform 'provides black-box query access'; it does not state that the served artifact is the training-time source module. Under standard deployment paths — torch.save(model.state_dict()) followed by reconstruction, ONNX/TorchScript export, or a clean serving re-implementation — the discriminative_layer in forward() disappears, and the claimed 100% accuracy collapses. The paper must justify that the threat model includes source-preserving deployment, or the attack should be evaluated under weights-only/exported deployment. This is load-bearing for the abstract's claim of 100% attack accuracy without model degradation.
  3. [Section V-E, Figures 8-9] The defense evaluation is not meaningful for the claimed attack. Inf2Guard, ExpM, and DPSGD operate on learned weights or query outputs; they cannot remove a source-level branch that overwrites logits for secret samples after the learned layers run. The paper's own Section VI-B says the discriminative layer gives precise labels 'without interference from the dataset or the training process.' Thus, robustness under these defenses is a tautology, not evidence of a robust property inference channel. A meaningful evaluation would test whether property information survives when the deployed model is constructed from weights only, or when the poisoned code is removed after training.
  4. [Section IV-D, Figure 5 and Section V-B] The mechanism is a hardcoded backdoor, not a learned behavior. The discriminative_layer assigns fixed output tensors ([0.1, 0.9] or [0.9, 0.1]) to inputs that exactly match secret_samples; it is not trained, not part of the optimizer step, and not discoverable via print(model). The experiments in Section V-B therefore measure the reliability of a source-code branch, not the model's ability to memorize or encode property information. The paper should state this explicitly and avoid presenting the results as 'model-based' property inference.
minor comments (5)
  1. [Figure 5] The pseudocode for discriminative_layer has indentation errors and mismatched parentheses (e.g., 'if label > 0.5:' is not properly nested; the 'else' is aligned incorrectly). The code also uses 'self.secret_samples[0]' as a tensor and compares it with each sample in x; the semantics are ambiguous. Please provide clean, runnable pseudocode.
  2. [Table III] The formatting of the ten secret samples is garbled; values such as '0104 ?' and '07 Private 1 Married' are not clearly separated into columns. This table is central to understanding the secret-sample construction and should be formatted as a proper table.
  3. [Section V-J] The extensions to GANs, transformers, Stable Diffusion 3, and regression are only illustrated with figures and lack quantitative metrics, experimental details, and baselines. The paper itself acknowledges these are preliminary; please mark the claims accordingly.
  4. [Appendix A] The code-auditing evaluation with Bandit, CytoScnPy, and Hexora is presented as evidence of stealth, but these tools are not designed to detect logic backdoors embedded in high-level forward() methods. The conclusion that CPPIA 'can clearly evade detection with ease' is overstated.
  5. [References] Several references are dated 2026 and appear to be to future or hypothetical events. Please verify the accuracy and verifiability of references [4]-[9], [19], [20], [27], [51]-[53].

Circularity Check

2 steps flagged

CPPIA's 100% attack accuracy is not a model-inference result: the poisoned code's hardcoded discriminative_layer writes the secret-sample labels verbatim, so Decoder(Encoder(t)) = t by construction.

specific steps
  1. self definitional [Section IV-D, Algorithm 1 (lines 6–14) and Figure 5; central claim in Abstract/Section I]
    "By stealthily embedding secret samples within a discriminative_layer(), the model can predict labels precisely without interference from the dataset or the training process, thereby achieving 100% attack accuracy."

    Algorithm 1 computes t via get_property(D), encodes t into secret labels, and later decodes the API's labels back to t. The discriminative_layer in Figure 5 overwrites the model output for any exact-match secret sample with the pre-assigned label [0.1,0.9] or [0.9,0.1]. Thus the queried labels equal the planted labels by construction, and Decoder(Encoder(t)) = t. The measured '100% attack accuracy' therefore tests the hardcoded source branch, not any learned property channel in the trained weights; the paper itself says the branch operates 'without interference from the dataset or the training process.'

  2. other [Section V-E (Figures 8, 9a, 9b); Section VI-E]
    "CPPIA operates on a fundamentally different axis. It relies on the encoding and decoding of secret samples, which is orthogonal to the assumptions of prior defenses."

    The claimed robustness under Inf2Guard, ExpM, and DPSGD is the same construction as the attack: the property channel is a source-level branch that overwrites logits before returning labels, so defenses that perturb weights, representations, or query outputs cannot touch it. The 100% accuracy under defenses is guaranteed by the hardcoded branch rather than demonstrated against the actual inference mechanism the defenses are designed to mitigate. The defense evaluation is therefore a tautological consequence of the self-definitional attack channel.

full rationale

The paper's central derivation is Algorithm 1 combined with Figure 5. The adversary computes t = get_property(D) inside the poisoned training code, encodes t into labels for ten secret outlier samples, and then, after deployment, queries those exact samples and decodes the returned labels. The route from t back to t does not pass through any learned representation: the discriminative_layer function in the poisoned forward() checks whether the input equals a secret sample and, if so, replaces the output with the pre-assigned label vector. Consequently every 'attack' is Decoder(Encoder(t)) = t, and the claimed 100% accuracy is equivalent to the code's own hardcoded assignment. The abstract's 'CPPIA offers 100% attack accuracy without degrading model accuracy' is therefore not a property-inference result about statistical learning; it is a property of the source code branch. The defense results are circular for the same reason: Inf2Guard, ExpM, and DPSGD operate on trained weights, representations, or query outputs, while the planted channel is an unconditional source-level branch, so the defenses are irrelevant by construction. The paper explicitly concedes this in Section VI-B, where it attributes the 100% accuracy to the discriminative layer acting 'without interference from the dataset or the training process.' No load-bearing self-citation chain appears in the paper; the circularity here is definitional, not citational. Because the single empirical headline — perfect attack accuracy and immunity to defenses — reduces by the paper's own mechanism to its own input, the appropriate score is 10.

Axiom & Free-Parameter Ledger

2 free parameters · 4 axioms · 0 invented entities

The attack introduces no new physical or mathematical entities. The 'secret samples' are crafted outlier inputs, not new model components in a conceptual sense; the 'discriminative layer' is a code branch. The two free parameters are encoding design choices, not parameters fitted to data. The load-bearing assumptions are the threat-model and deployment assumptions listed above.

free parameters (2)
  • secret_sample_count = 10
    Hand-chosen number of secret samples used to encode the property; sets the encoding precision to three decimal places (10 bits). Not fitted to data, but a design choice that controls attack capacity and query cost. The paper notes 14 bits would give four decimal places.
  • property_scale = 1000
    Scaling factor in the decimal-to-binary encoding (Section IV-D). Chosen to match the 10-bit precision, not fitted to data.
axioms (4)
  • domain assumption The victim executes untrusted third-party training code as-is, without manual audit or static analysis that would reveal get_property() and discriminative_layer().
    Central threat-model premise; supported by the paper via surveys [18, 40, 41] and code-poisoning literature [15, 16, 42] in Section III-B. If the victim audits code, the attack is discovered before training.
  • domain assumption The deployed model retains and executes the poisoned forward-pass code (the hardcoded discriminative_layer) unchanged; weights-only serialization or re-implementation in a clean inference script would erase the backdoor.
    Required for the exfiltration channel to exist at query time. The attack lives in source code, not in learned parameters (Figure 5, Section IV-D). This fragility is not discussed in the paper.
  • domain assumption Benign users never query the model with the secret outlier samples, so the hardcoded branch never fires during normal use and the backdoor remains dormant.
    Needed for stealth and for 'no degradation of model accuracy' to hold in practice. The paper argues the samples are contradictory outliers (Table III, Section IV-D).
  • standard math Binary encoding and decoding of integer values is a valid bijection for the chosen precision.
    Used in the encoder and decoder (Algorithm 1); trivially true.

pith-pipeline@v1.3.0-alltime-deepseek · 22322 in / 19671 out tokens · 195188 ms · 2026-08-01T21:45:13.139141+00:00 · methodology

0 comments
read the original abstract

The flourishing code hosting platforms and coding agents enable even beginners with private data to build tailored Machine Learning (ML) models using available code quickly. The training data for ML models, often regarded as private property (e.g., clinical records, transaction information), is at significant risk of information leakage. Property Inference Attacks (PIAs), as a significant type of privacy attack, aim to expose global property information of the training set. In this paper, we present Code-Poisoning Property Inference Attack (CPPIA), the first code-level PIA, which overcomes four limitations of existing works: insufficient attack performance, severe degradation of model accuracy, high computational overhead, and failure under defenses. We consider malicious code providers from code hosting platforms (GitHub) and coding agents (Codex). Upon downloading the poisoned code, data holders train models with their private data without professional auditing, subsequently releasing label-only APIs to the public. The adversary embeds the properties into secret samples during training and queries the trained model on these samples later to leak privacy. CPPIA offers 100\% attack accuracy without degrading model accuracy. It is also computationally lightweight and requires no shadow models. We evaluate the attack performance across four datasets, eight model architectures, eighteen properties, and under three defense mechanisms, demonstrating the universality and effectiveness of CPPIA.

Figures

Figures reproduced from arXiv: 2607.15970 by Gang Zhang, Jinyan Liu, Xuesong Li, Xukun Luan, Yuanguo Bi, Yuhui Gong, Zixuan Huang.

Figure 2
Figure 2. Figure 2: Code auditing difficulty. A larger code volume, coupled [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Attack process. The label generation process for secret [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: The code for computing statistical property informa [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: A discriminative layer() is embedded within the poisoned code, with the explicit purpose of achieving high￾accuracy predictions on the secret samples. Since it is not part of the model architecture, it cannot be discovered by using print(model). Algorithm 1 CPPIA Algorithm 1: Symbol: secret samples (xsec1 ,ysec1 ),. . .,(xsec10 ,ysec10 ), dataset D, target property t, code-poisoned model Mˆ 2: Upload: Adve… view at source ↗
Figure 6
Figure 6. Figure 6: Attack accuracy of six inference attacks on each target property across four datasets. Each small subplot corresponds to [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Model accuracy and attack accuracy under four PIAs. [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Attack accuracy on Adult under the Inf2Guard defense. [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗
Figure 10
Figure 10. Figure 10: Attack against GAN [46]. The generated images contain property information. We inject the poisoned code into the GAN and subsequently query the model, successfully re￾covering the property information with 100% attack accuracy [PITH_FULL_IMAGE:figures/full_fig_p011_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Attack against Transformer [47]. We poison the model’s output code logic. Property information can be ex￾tracted from the model via secret prompts [PITH_FULL_IMAGE:figures/full_fig_p011_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Attack against Stable Diffusion 3 [48]. The text-to￾image task is similar to the combination of [PITH_FULL_IMAGE:figures/full_fig_p011_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Audit results of the three code auditing tools on post [PITH_FULL_IMAGE:figures/full_fig_p015_13.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

53 extracted references · 3 linked inside Pith

  1. [1]

    Machine learning: Trends, perspec- tives, and prospects,

    M. I. Jordan and T. M. Mitchell, “Machine learning: Trends, perspec- tives, and prospects,”Science, vol. 349, no. 6245, pp. 255–260, 2015

  2. [2]

    Github, “Github,” https://github.com/, 2026

  3. [3]

    OpenAI, “Codex,” https://github.com/openai/codex, 2026

  4. [4]

    Pytorch dependency poisoned,

    Theregister, “Pytorch dependency poisoned,” theregister.com, 2023

  5. [5]

    Playing with fire,

    Johnstawinski, “Playing with fire,” johnstawinski.com, 2024

  6. [6]

    Tensorflow ci/cd flaw,

    Thehackernews, “Tensorflow ci/cd flaw,” thehackernews.com, 2024

  7. [7]

    Claude code,

    Claude, “Claude code,” https://claude.com/product/claude-code, 2026

  8. [8]

    Code to detect chinese users,

    G. Baran, “Code to detect chinese users,” cybersecuritynews.com, 2026

  9. [9]

    Hackers using claude,

    Abinaya, “Hackers using claude,” cybersecuritynews.com, 2026

  10. [10]

    Property inference attacks on fully connected neural networks using permutation invariant representations,

    K. Ganju, Q. Wang, W. Yang, C. A. Gunter, and N. Borisov, “Property inference attacks on fully connected neural networks using permutation invariant representations,” inProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 619– 633

  11. [11]

    Leakage of dataset properties in {Multi-Party}machine learning,

    W. Zhang, S. Tople, and O. Ohrimenko, “Leakage of dataset properties in {Multi-Party}machine learning,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2687–2704

  12. [12]

    Property inference from poisoning,

    S. Mahloujifar, E. Ghosh, and M. Chase, “Property inference from poisoning,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 1120–1137

  13. [13]

    Snap: Efficient extraction of private properties with poisoning,

    H. Chaudhari, J. Abascal, A. Oprea, M. Jagielski, F. Tram `er, and J. Ull- man, “Snap: Efficient extraction of private properties with poisoning,” in2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 400–417

  14. [14]

    Manipulating transfer learning for property inference,

    Y . Tian, F. Suya, A. Suri, F. Xu, and D. Evans, “Manipulating transfer learning for property inference,” inProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2023, pp. 15 975–15 984

  15. [15]

    Blind backdoors in deep learning models,

    E. Bagdasaryan and V . Shmatikov, “Blind backdoors in deep learning models,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1505–1521

  16. [16]

    Machine learning models that remember too much,

    C. Song, T. Ristenpart, and V . Shmatikov, “Machine learning models that remember too much,” inProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 587– 601

  17. [17]

    Show me your code! kill code poisoning: A lightweight method based on code naturalness,

    W. Sun, Y . Chen, M. Yuan, C. Fang, Z. Chen, C. Wang, Y . Liu, B. Xu, and Z. Chen, “Show me your code! kill code poisoning: A lightweight method based on code naturalness,” in2025 IEEE/ACM 47th International Conference on Software Engineering, 2025, pp. 2663– 2675

  18. [18]

    Loneneuron: a highly-effective feature- domain neural trojan using invisible and polymorphic watermarks,

    Z. Liu, F. Li, Z. Li, and B. Luo, “Loneneuron: a highly-effective feature- domain neural trojan using invisible and polymorphic watermarks,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2129–2143

  19. [19]

    Your space is my zone: Demystifying the security risks of ai-powered applications on pre-trained model hubs,

    Y . Gu, L. Ying, Z. Zhang, Y . Pu, X. Huang, J. Zhou, W. Zhu, D. Sun, and H. Duan, “Your space is my zone: Demystifying the security risks of ai-powered applications on pre-trained model hubs,” inProceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security, 2026

  20. [20]

    Overeager coding agents: Measuring out-of-scope actions on benign tasks,

    Y . Qu, Y . Zhang, Y . Zhang, G. Deng, Y . Li, L. Y . Zhang, and Y . Liu, “Overeager coding agents: Measuring out-of-scope actions on benign tasks,” 2026. [Online]. Available: https://arxiv.org/abs/2605.18583

  21. [21]

    More code, less reuse: Investigating code quality and reviewer sentiment towards ai-generated pull requests,

    H. Huang, P. Jaisri, S. Shimizu, L. Chen, S. Nakashima, and G. Rodr´ıguez-P´erez, “More code, less reuse: Investigating code quality and reviewer sentiment towards ai-generated pull requests,” 2026. [Online]. Available: https://arxiv.org/abs/2601.21276

  22. [22]

    Hugging face,

    H. Face, “Hugging face,” https://huggingface.co/, 2026

  23. [23]

    Intriguing properties of adversarial training at scale,

    C. Xie and A. Yuille, “Intriguing properties of adversarial training at scale,” inInternational Conference on Learning Representations, 2019

  24. [24]

    Pure noise to the rescue of insufficient data: Improving imbalanced classification by training on random noise images,

    S. Zada, I. Benou, and M. Irani, “Pure noise to the rescue of insufficient data: Improving imbalanced classification by training on random noise images,” inInternational Conference on Machine Learning. PMLR, 2022, pp. 25 817–25 833

  25. [25]

    {“Security}is not my field,{I’m}a stats{guy

    J. Mink, H. Kaur, J. Schm ¨user, S. Fahl, and Y . Acar, “{“Security}is not my field,{I’m}a stats{guy”}: A qualitative root cause analysis of barriers to adversarial machine learning defenses in industry,” in32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 3763– 3780

  26. [26]

    Huggingface’s trans- formers: State-of-the-art natural language processing,

    T. Wolf, L. Debut, V . Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowiczet al., “Huggingface’s trans- formers: State-of-the-art natural language processing,”arXiv preprint arXiv:1910.03771, 2019

  27. [27]

    Openclaw,

    Openclaw, “Openclaw,” https://openclaw.ai/, 2026

  28. [28]

    An empirical comparison of supervised learning algorithms,

    R. Caruana and A. Niculescu-Mizil, “An empirical comparison of supervised learning algorithms,” inInternational Conference on Machine Learning, 2006, pp. 161–168

  29. [29]

    Stochastic gradient descent tricks,

    L. Bottou, “Stochastic gradient descent tricks,” inNeural networks: tricks of the trade: second edition. Springer, 2012, pp. 421–436

  30. [30]

    Hacking smart machines with smarter ones: How to extract meaningful data from machine learning classifiers,

    G. Ateniese, L. V . Mancini, A. Spognardi, A. Villani, D. Vitali, and G. Felici, “Hacking smart machines with smarter ones: How to extract meaningful data from machine learning classifiers,”International Jour- nal of Security and Networks, vol. 10, no. 3, pp. 137–150, 2015

  31. [31]

    Sup- port vector machines,

    M. A. Hearst, S. T. Dumais, E. Osuna, J. Platt, and B. Scholkopf, “Sup- port vector machines,”IEEE Intelligent Systems and Their Applications, vol. 13, no. 4, pp. 18–28, 1998

  32. [32]

    Hidden markov models,

    S. R. Eddy, “Hidden markov models,”Current Opinion in Structural Biology, vol. 6, no. 3, pp. 361–365, 1996

  33. [33]

    idlg: Improved deep leakage from gradients,

    B. Zhao, K. R. Mopuri, and H. Bilen, “idlg: Improved deep leakage from gradients,”arXiv preprint arXiv:2001.02610, 2020

  34. [34]

    Poisoning attacks against support vector machines,

    B. Biggio, B. Nelson, P. Laskovet al., “Poisoning attacks against support vector machines,” inInternational Conference on Machine Learning. ArXiv e-prints, 2012, pp. 1807–1814

  35. [35]

    Formalizing and estimating distribution inference risks,

    A. Suri and D. Evans, “Formalizing and estimating distribution inference risks,”Proceedings on Privacy Enhancing Technologies, vol. 4, pp. 528– 551, 2022

  36. [36]

    Property inference attacks against gans,

    J. Zhou, Y . Chen, C. Shen, and Y . Zhang, “Property inference attacks against gans,” in30th Network and Distributed System Security Sympo- sium (NDSS 2022), 2022

  37. [37]

    {Inf2Guard}: An {Information-Theoretic}framework for learning{Privacy-Preserving} representations against inference attacks,

    S. L. Noorbakhsh, B. Zhang, Y . Hong, and B. Wang, “{Inf2Guard}: An {Information-Theoretic}framework for learning{Privacy-Preserving} representations against inference attacks,” in33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 2405–2422

  38. [38]

    Deep learning with differential privacy,

    M. Abadi, A. Chu, I. Goodfellow, H. B. McMahan, I. Mironov, K. Talwar, and L. Zhang, “Deep learning with differential privacy,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 308–318

  39. [39]

    Protecting global properties of datasets with distribution privacy mechanisms,

    M. Chen and O. Ohrimenko, “Protecting global properties of datasets with distribution privacy mechanisms,” inInternational Conference on Artificial Intelligence and Statistics. PMLR, 2023, pp. 7472–7491

  40. [40]

    “i never thought about securing my machine learning systems

    F. Boenisch, V . Battis, N. Buchmann, and M. Poikela, ““i never thought about securing my machine learning systems”: A study of security and privacy awareness of machine learning practitioners,” inProceedings of Mensch und Computer 2021, 2021, pp. 520–546

  41. [41]

    Adversarial machine learning- industry perspectives,

    R. S. S. Kumar, M. Nystr ¨om, J. Lambert, A. Marshall, M. Goertzel, A. Comissoneru, M. Swann, and S. Xia, “Adversarial machine learning- industry perspectives,” in2020 IEEE Security and Privacy Workshops (SPW). IEEE, 2020, pp. 69–75

  42. [42]

    A method to facilitate membership inference attacks in deep learning models,

    Z. Chen and K. Pattabiraman, “A method to facilitate membership inference attacks in deep learning models,” in32nd Network and Distributed System Security Symposium (NDSS 2025), 2025

  43. [43]

    Uci machine learning repository,

    A. Asuncionet al., “Uci machine learning repository,” 2007

  44. [44]

    Deep learning face attributes in the wild,

    Z. Liu, P. Luo, X. Wang, and X. Tang, “Deep learning face attributes in the wild,” inProceedings of the IEEE International Conference on Computer Vision, 2015, pp. 3730–3738

  45. [45]

    Deep residual learning for image recognition,

    K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” inProceedings of the IEEE Conference on Computer Vision and Pattern Recognition, 2016, pp. 770–778

  46. [46]

    Generative adversarial networks,

    I. Goodfellow, J. Pouget-Abadie, M. Mirza, B. Xu, D. Warde-Farley, S. Ozair, A. Courville, and Y . Bengio, “Generative adversarial networks,” Communications of the ACM, vol. 63, no. 11, pp. 139–144, 2020

  47. [47]

    Attention is all you need,

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention is all you need,”Advances in Neural Information Processing Systems, p. 6000–6010, 2017

  48. [48]

    Scaling rectified flow transformers for high-resolution image synthesis,

    P. Esser, S. Kulal, A. Blattmann, R. Entezari, J. M ¨uller, H. Saini, Y . Levi, D. Lorenz, A. Sauer, F. Boesel, D. Podell, T. Dockhorn, Z. English, and R. Rombach, “Scaling rectified flow transformers for high-resolution image synthesis,” inInternational Conference on Machine Learning. PMLR, 2024, pp. 12 606–12 633

  49. [49]

    D. W. Hosmer Jr, S. Lemeshow, and R. X. Sturdivant,Applied logistic regression. John Wiley & Sons, 2013

  50. [50]

    Sigstore: Software signing for everybody,

    Z. Newman, J. S. Meyers, and S. Torres-Arias, “Sigstore: Software signing for everybody,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 2353–2367. 14

  51. [51]

    Bandit: Security linter for python source code

    Bandit, “Bandit: Security linter for python source code.” https://bandit. readthedocs.io/, 2026

  52. [52]

    Cytoscnpy: Fast python static analysis with rust

    Cytoscnpy, “Cytoscnpy: Fast python static analysis with rust.” https: //pypi.org/project/cytoscnpy/, 2026

  53. [53]

    Hexora: Ml-powered malicious code detection

    Hexora, “Hexora: Ml-powered malicious code detection.” https://github. com/rushter/hexora, 2026. APPENDIX A. CPPIA against Code Auditing Tools To evaluate the stealthiness of our attack, we perform a comprehensive analysis of the post-CPPIA code using a suite of code auditing tools, including Bandit [51] (a widely used security-focused static analyzer for...