This vulnerability is quite ... foretold. We have had issues with image libraries before. Instead of just running about patching again for this one bug, why not use the opportunity to discuss some architecture-level approaches that may have mitigated this attack?<p>Knowing that image libraries may contain vulnerabilities, how would you design a secure image ingestion process?<p>Some reasonable strategies...<p>(0) Attack surface minimization: Similarly to other types of input, input is segregated and treated as toxic and dangerous until proven otherwise. (Eg. Don&#x27;t store random inbound files where you store those you will re-use; never allow batch processes to touch temporary files received from external systems; delete external input as soon as possible; store input only after normalization)<p>(1) Attack surface minimization: only accept one file format. This provides no guarantees but helps to limit exposure to unknown vulnerabilities, though may not always be feasible.<p>(2) Parallelization (opposite of the above): explicitly convert all formats of input to some common format (using throwaway containers&#x2F;VMs), ideally using multiple versions of multiple libraries on multiple operating systems, and compare the results. If the results of every environment do not match, raise an alarm and do not continue processing.<p>(3) Reverse-conversion check. Convert the file to another (non-lossy conversion possible) format, then convert it back (also in a throwaway environment). If the result matches (or the portion of the result that is non-lossy matches) continue. This could be combined with #2 for additional strength.<p>(4) &quot;Application-level firewall&quot; approach: progressively determine the various format-specific and general properties of the image in question (eg. starting with libmagic; and preferably all in relatively secured throwaway environments, using the above strategies!) then apply a neural network or basic statistical analysis to generate alerts for anomiles. For instance, the reduced pallette featured in this attack would not be normal for many types of image input (scans or photographs come to mind). Other useful checks may include &quot;are the image dimensions sane?&quot;, &quot;is the aspect ratio sane?&quot;, &quot;is the image predominantly black and white?&quot;, etc.<p>Strategies #0 (in particular cases), #1 (with some luck), #2, #3 and #4 (with some luck) could have mitigated this attack. Executed wrongly, any of those strategies could also have triggered the vulnerability. #4 is ripe for a web2.0 Silly-Valley outsource-the-problem startup (investors?).<p>PS. I enjoy these types of problems; anyone looking for ideas or development get in touch.