<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ml-Security on CuraSec</title><link>https://curasec.metacog.co.kr/tags/ml-security/</link><description>Recent content in Ml-Security on CuraSec</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 20 Jul 2026 14:31:24 +0000</lastBuildDate><atom:link href="https://curasec.metacog.co.kr/tags/ml-security/index.xml" rel="self" type="application/rss+xml"/><item><title>Code-Poisoning Property Inference Attack Leaks ML Training Data</title><link>https://curasec.metacog.co.kr/insights/2026-07-20-code-poisoning-property-inference-attacks/</link><pubDate>Mon, 20 Jul 2026 14:31:24 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-07-20-code-poisoning-property-inference-attacks/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Learn:&lt;/strong> Novel attack vector where malicious code from public repos or coding agents embeds property-inference backdoors into ML training pipelines — no active exploitation or PoC, but teams training models on sensitive data (PII, clinical records) should factor code provenance auditing into their ML supply chain reviews.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Skip&lt;/strong>&lt;/li>
&lt;li>&lt;strong>Leader — Learn:&lt;/strong> Research demonstrates that outsourced or open-source ML training code can be weaponized to leak properties of private training datasets; useful framing for AI governance policies covering code provenance in sensitive ML pipelines, but no immediate action is warranted.&lt;/li>
&lt;/ul></description></item></channel></rss>