In this guide
  1. What this checklist is for
  2. 1. Confirm you run the affected product
  3. 2. Install the fixed version
  4. 3. Restart or reboot if the advisory requires it
  5. 4. If you cannot patch yet, use only the official interim control
  6. 5. Then check whether you were already hit
  7. Related incidents on One Signal Desk

TL;DR: When a vendor ships an emergency fix, or CISA adds a bug to its Known Exploited Vulnerabilities (KEV) catalog, work in this order: confirm you run the affected product, install the fixed version the vendor names, restart the service if the advisory says a package install is not enough, apply the official interim control only if you cannot patch yet, then check for signs you were already hit. Patching closes the hole; it does not undo a past break-in. Use this page with the specific versions and commands in the incident article.

What this checklist is for

This is a reusable checklist for an emergency patch, including KEV items. It is not a substitute for the vendor advisory. Versions, CVEs and commands always come from that advisory and from our article on the incident.

For related alerts, see our security coverage. If the incident is a leaked key rather than a patch, use the leaked secrets rotation checklist. If a package on npm or PyPI was malicious, use the compromised package checklist.

1. Confirm you run the affected product

  1. Identify the product, edition and version from the vendor advisory, not from a screenshot or a social post.
  2. Check the running version, not only the package on disk. Examples from our live coverage:
    • OpenSSH / Alpine: sshd -T and the installed openssh-server package, as described in OpenSSH SSHole, CVE-2026-123158.
    • WordPress: the version the site actually reports after an update, as described in WordPress 7.1.4 / CVE-2026-119977.
    • PHP: the runtime that serves web requests (php -v on the host, or the version your control panel shows).
  3. Match the vendor’s conditions (platform, build flags, enabled features). If the advisory lists required conditions, treat a host as in scope only when those conditions are met. Do not guess.

2. Install the fixed version

  1. Take the fixed version string from the vendor, not from a secondary write-up, and install that exact release or a later one the vendor lists as containing the fix.
  2. Examples (always re-check the live article and the advisory; these are the fixed versions in our published coverage):
    • Portable OpenSSH 10.6p2 (November 5, 2026), or the Alpine branch packages listed in our SSHole article, for CVE-2026-123158.
    • WordPress 7.1.4, 7.0.8, 6.9.11, or the backport for your branch, for CVE-2026-119977.
    • PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for the PHP2Shell pair CVE-2026-109618 and CVE-2026-109619.
    • Self-managed Airbyte 2.2.0 or later for GHSA-g35w-6r6v-h4r7. Airbyte says 1.x will not receive a fix.
    • Zyxel GS1900 2.90 Patch 3 (the “.3)C0” firmware for your exact model) for CVE-2026-107441. An earlier June firmware is not enough for this CVE.
  3. Download firmware and packages from the vendor’s own site or your distro’s official repository.

3. Restart or reboot if the advisory requires it

A package upgrade does not always replace a running process.

  • Alpine warns that upgrading OpenSSH does not replace a running sshd. Restart it (rc-service sshd restart on Alpine) and confirm the new version is what is listening. See the SSHole article.
  • Kernel fixes require a reboot into the new kernel, then uname -r, as in our Fragnesia guide.
  • Follow the vendor’s restart or reboot steps when they give them.

4. If you cannot patch yet, use only the official interim control

  1. Apply the workaround the vendor (or the advisory we cite) actually published. Do not invent a “temporary fix.”
  2. Examples from our coverage:
    • OpenSSH SSHole: set PasswordAuthentication no, keep a working key session open, run sshd -t, restart sshd, and confirm with sshd -T. Alpine presents this as an interim control, not a substitute for the fixed package.
    • Airbyte: restrict network access to the Connector Builder / Manifest Server, limit Reader access to trusted users, and leave AIRBYTE_ENABLE_UNSAFE_CODE off, per Airbyte, until you can move to 2.2.0 or later.
  3. Schedule the real update. Interim controls age badly.

5. Then check whether you were already hit

Updating does not remove a backdoor, a planted admin, or a past login.

  1. Use the compromise checks in the vendor advisory or in our incident article. Examples:
    • SSHole: in auth logs, look for Accepted password for on accounts that should have no password (* in /etc/shadow).
    • Ninja Forms CVE-2026-94504: look for hidden or unknown administrators and the fake “WP Smart Thumbnails” plugin Patchstack describes. Updating to 3.15.4 closes that hole but does not remove what an attacker already installed.
    • WordPress core: confirm the running version, then follow the checks in that article if exploit attempts may have landed during an update window.
  2. If you cannot rule out a successful attack, treat the system as compromised: rotate credentials and keys, review persistence, and rebuild from a known-good image when the article or the vendor says that is the safe path. For stolen secrets, continue on the leaked secrets rotation checklist.

Sources

The steps above summarise the “What to do” sections of the live articles listed here. Each article cites the vendor advisory, and where relevant NVD, CISA KEV, or JVN. Re-read those pages and the advisory before you act; do not treat this checklist as a version table.

Last checked: Nov 10, 2026, 1:16 p.m. Manila (UTC+8). Method: We built this type-level checklist from the live, QA-passed One Signal Desk articles linked above (each HTTP 200 on Nov 10) and from the vendor steps those articles already quote. We did not invent interim controls or fixed versions beyond what those pages state. Thumbnail is a reuse-licensed image, credited with its license under the picture. No HowTo or FAQ schema. No affiliate links. How we work.