<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Patch-Management on ShieldedBytes</title>
    <link>https://linuxeries.org/tags/patch-management/</link>
    <description>Recent content in Patch-Management on ShieldedBytes</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 14 Nov 2026 08:44:34 +0200</lastBuildDate>
    <atom:link href="https://linuxeries.org/tags/patch-management/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>When a Critical CVE Slips Through: Lessons from a Patch‑Delay Incident in a Production Web Service</title>
      <link>https://linuxeries.org/post/2026-11-14-when-a-critical-cve-slips-through-lessons-fro/</link>
      <pubDate>Sat, 14 Nov 2026 08:44:34 +0200</pubDate>
      <guid>https://linuxeries.org/post/2026-11-14-when-a-critical-cve-slips-through-lessons-fro/</guid>
      <description>&lt;p&gt;A remote‑code‑execution flaw in a third‑party JSON‑schema validator made its way into a live API last winter. The service was a Go‑based REST gateway, exposed to the public internet, and the CVE (CVE‑2025‑12345) let an attacker spin up code on the container host. The library’s fix landed in v2.1.0, but our pipeline still pulled v2.0.3. The attack happened before we even noticed.&lt;/p&gt;&#xA;&lt;p&gt;Below is the real‑world story, what we did to stop it, and the trade‑offs we had to juggle. Grab a coffee, read on, and take notes for your own stack.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
