<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Resource Exhaustion on Nalar</title>
    <link>https://nalar.dev/tags/resource-exhaustion/</link>
    <description>Recent content in Resource Exhaustion on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 10 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/resource-exhaustion/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Limit Decompression Before Untrusted Data Exhausts Resources</title>
      <link>https://nalar.dev/limit-decompression-before-untrusted-data-exhausts-resources/</link>
      <pubDate>Thu, 10 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/limit-decompression-before-untrusted-data-exhausts-resources/</guid>
      <description>&lt;p&gt;A service may reject a 100 MB upload and still accept a much smaller compressed file that expands far beyond the memory or storage the service can afford. The upload limit measured the bytes crossing one boundary. The expensive work happens after that boundary, when the application decompresses, parses, indexes, scans, or stores the expanded data.&lt;/p&gt;&#xA;&lt;p&gt;This is the practical problem behind decompression bombs: compact input can cause disproportionate resource use when software expands it without enforcing a budget on the result. The consequence is usually availability loss rather than unauthorized access. Workers can run out of memory, temporary storage can fill, CPU time can be consumed, and a queue of expensive jobs can delay ordinary requests.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
