<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CWE-829 on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/cwe-829/</link>
    <description>Recent content in CWE-829 on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 10 May 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/cwe-829/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Integrity Failures</title>
      <link>https://www.secdev.uk/blog/technology/2025-05-10-integrity-failures/</link>
      <pubDate>Sat, 10 May 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-05-10-integrity-failures/</guid>
      <description>&lt;p&gt;Integrity failures happen when an application trusts data or code that hasn&amp;rsquo;t been verified, and they can lead to some of the most devastating compromises out there. OWASP A08 covers two patterns I find particularly fascinating: unsafe deserialization (CWE-502), where untrusted data is fed into a deserializer that can execute arbitrary code, and inclusion of functionality from untrusted sources (CWE-829), where the application loads and runs code from URLs, plugins, or scripts without integrity checks. Both patterns share a root cause, the application assumes that incoming data or code is benign. In this post I&amp;rsquo;ll walk through Python, Java, JavaScript, and Go, from the textbook &lt;code&gt;pickle.loads()&lt;/code&gt; to the subtle VM sandbox escapes that can survive expert review.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
