我认为使用 gs 应该删除所有活动内容（Javascript）和嵌入数据（视频、Flash ...）。但我不确定直接在 PDF 上使用 pdfwrite 是否真的会删除所有活动和嵌入的内容。因此，我建议您首先使用 gs 将 PDF 转换为 Postscript，然后使用带有 pdfwrite 后端的 gs 将 Postscript 转换回 PDF。由于 Postscript 格式本身不支持活动或嵌入内容，因此此类内容不应在转换过程中存活。我不确定这是否也有助于对抗图像格式，例如利用libjpeg、libpng或类似的漏洞。在任何情况下，对gs自身的调用都应该在某种受保护的环境（即沙箱或类似环境）内完成，这样这些漏洞就不会影响安防系统本身的安全。

另一种选择是将 PDF 转换为图像，然后用这些图像创建一个新的 PDF。这样，您也可以防止利用图像库中的漏洞，但代价是失去将 PDF 作为文本处理的能力（即搜索、复制......）。如果您想要额外的保护但需要能够将 PDF 作为文本处理，您可以在之后运行一些 OCR 软件从图像中重建文本。

这太长了，无法发表评论。

有不同程度的扁平化。如果（例如）您想要排版 PDF 并且会使 PDF 变得大而笨重（也许您不关心输入文件是否都是批量扫描），则不建议将所有内容转换为位图。PS 并再次返回是合理的，但请注意您将失去（例如）填写表格的能力。此外，受密码保护的 PDF 将无法传输，受操作保护的 PDF 将需要您使用没有 Adob​​e DRM 的 PDF 渲染器。

就最终查看 PDF 的人而言，使用 PS 或位图（并返回）应该消除 JS 和 flash 漏洞，以及许多其他漏洞（例如缓冲区溢出）。

但是，无论您使用位图还是 PS 或其他方式，您都只是在移动（并且可以想象复制）这里的问题。您的 PDF 查看器中以前存在的任何漏洞都可以避免（假设漏洞无法在位图/PS 转换后继续存在），但任何呈现 PDF 的内容都可能受到相同（或其他）漏洞的影响。

启动 VM 仅仅意味着 VM 可能会受到威胁，这可能比任意桌面受到威胁要好。

我能想到的最好的实用想法是为每个 PDF 启动一个 Docker 容器（或类似容器），每次都处于确切的已知状态，并将其输出作为 PS 或位图文件提供。然后启动另一个 docker 容器（每次）以将输出呈现为 PDF。它需要有针对性和复杂的攻击才能通过（而不是霰弹枪感染的 PDF 方法）。启动一个 docker 容器非常快，并且给你一定程度的隔离。为了更好地衡量，在虚拟机中做很多事情。