How to Patch a Self-Hosted Tool You Run

To patch a self-hosted tool safely, know what you run and which version, get notified when a fix ships, back up, update, then check it works and was not tampered with. The rhythm matters more than any tool. This week's Rejetto HFS flaw was attacked within a day of disclosure, so a monthly maintenance window is too slow for anything reachable from the internet.

Step 1: List what you run

Most small teams cannot say what they host. Write it down once. Check each version on the machine itself, with the tool's own version command or admin page, not from memory.

The rows above are examples. The columns are what matter. Exposure decides how fast you need to move.

Step 2: Get told when a fix ships

• On GitHub, use Watch, then Custom, and tick Releases and Security alerts for each project you run.

• Join the vendor's mailing list or follow its security page.

• Check CISA's Known Exploited Vulnerabilities catalog for products on your list. Entries there are being attacked now.

• Put a weekly fifteen-minute slot in the calendar to read what arrived.

If CVE numbers and severity scores are unfamiliar, read what a CVE is.

Step 3: Decide how fast to move

Exploited-in-the-wild flaws are not rare. The Ray framework case is another one we covered.

Step 4: Back up first

Take a snapshot or copy of the data and configuration before every update, and confirm you can restore it. How to add backups to an AI-built app covers the habit. A failed update with a good backup is an inconvenience, and without one it is a bad week.

Step 5: Update and verify

1. Read the release notes for breaking changes.

2. Update.

3. Check the version number on the machine matches the fixed version.

4. Log in and complete one real task.

5. Read the logs for errors from the first few minutes.

Step 6: Look for tampering after an exploited flaw

If a flaw was exploited in the wild before you patched, assume it might have reached you. Look for:

• Admin accounts or settings you did not create.

• Unfamiliar files or scheduled tasks.

• Unexpected outbound connections from the host.

If you find any sign, treat the machine as compromised: isolate it, rebuild from a clean install and rotate every credential it could reach.

Reduce how often it matters

• Keep admin interfaces off the public internet. Use a VPN or an allow-list.

• Remove tools nobody uses. An abandoned install still gets attacked.

• Ask whether a managed service is a better fit. Customers who ask for a self-hosted AI tool are signing you up for this routine.

Where AI helps and where it does not

A model can summarise release notes, draft your inventory table and write your checklist. It cannot see your server, so never rely on it for which version you run. Run the command and read the output. For the larger context, see the AI risks guide.

Frequently asked questions

How often should I patch a self-hosted tool?

Check weekly, and act the same day when a flaw affects an internet-facing tool and is being exploited. Routine updates can follow a monthly cycle.

Should I turn on automatic updates?

For low-risk internal tools, often yes. For tools with plugins or custom configuration, test first, because an update can break them.

What if the vendor has not released a fix yet?

Reduce exposure: close the interface to the internet, restrict access to known addresses, or switch the feature off until a fix ships.

How do I know if I was already attacked?

Compare current admin accounts, settings and files with what you expect, and read the logs from the period before you patched. If anything looks wrong, rebuild and rotate credentials.