<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Deserialization on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/deserialization/</link>
    <description>Recent content in Deserialization on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 28 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/deserialization/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Deserialization Attacks: From Pickle to ObjectInputStream</title>
      <link>https://www.secdev.uk/blog/technology/2026-02-28-deserialization-attacks/</link>
      <pubDate>Sat, 28 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-02-28-deserialization-attacks/</guid>
      <description>&lt;p&gt;Deserialization vulnerabilities are some of the scariest bugs in application security, because when they&amp;rsquo;re exploitable, it&amp;rsquo;s almost always remote code execution. The core problem is that an application reconstructs objects from untrusted data without validating what types are being instantiated. In languages with powerful serialization mechanisms &amp;ndash; Python&amp;rsquo;s &lt;code&gt;pickle&lt;/code&gt;, Java&amp;rsquo;s &lt;code&gt;ObjectInputStream&lt;/code&gt;, PHP&amp;rsquo;s &lt;code&gt;unserialize&lt;/code&gt; &amp;ndash; an attacker can craft serialized payloads that execute arbitrary code during the deserialization process itself. The more I researched how these attacks work across languages, the more I appreciated how a single API call can turn into a full server compromise.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Java Security: From Spring Boot Misconfigs to Deserialization</title>
      <link>https://www.secdev.uk/blog/technology/2025-09-13-java-security-spring-boot-deserialization/</link>
      <pubDate>Sat, 13 Sep 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-09-13-java-security-spring-boot-deserialization/</guid>
      <description>&lt;p&gt;Java has this reputation for being &amp;ldquo;safe&amp;rdquo; because of its type system, managed memory, and mature ecosystem. The more I&amp;rsquo;ve dug into Java security, the more I think that reputation is misleading, and honestly, a bit dangerous. Java&amp;rsquo;s security pitfalls aren&amp;rsquo;t about buffer overflows or memory corruption. They&amp;rsquo;re about the language&amp;rsquo;s powerful runtime features: deserialization, reflection, JNDI lookups, expression languages, and the Spring framework&amp;rsquo;s convention-over-configuration philosophy that silently enables dangerous defaults. In this post I want to walk through the Java-specific anti-patterns that lead to remote code execution, data leaks, and authentication bypasses, from the classic &lt;code&gt;ObjectInputStream&lt;/code&gt; gadget chain to the Spring Boot actuator endpoint that can expose entire environments.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Python Security Pitfalls Every Developer Should Know</title>
      <link>https://www.secdev.uk/blog/technology/2025-08-30-python-security-pitfalls/</link>
      <pubDate>Sat, 30 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-08-30-python-security-pitfalls/</guid>
      <description>&lt;p&gt;I&amp;rsquo;ve spent a lot of time reviewing Python codebases, and the language&amp;rsquo;s readability and rapid development cycle are exactly what make it dangerous. Python is the default choice for web services, data pipelines, and automation scripts, and that same ease of use hides security pitfalls that experienced developers walk into regularly. The language&amp;rsquo;s dynamic nature, runtime evaluation, duck typing, implicit conversions, and powerful serialization, creates attack surfaces that simply don&amp;rsquo;t exist in statically typed languages. In this post, I want to cover the Python-specific anti-patterns that lead to real vulnerabilities, from the well-known &lt;code&gt;pickle&lt;/code&gt; deserialization trap to the subtle template injection that can survive code review.&lt;/p&gt;</description>
    </item>
    <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>
