skip to content

Fully patched, so nothing is wormable - where does that reviewer's claim break?

level: seniorimportance: must knowfreq 58%

answer

  1. a conjunction, and patching touches one term
  2. satisfying a service does not require breaking it
  3. no exploit, no patch, still self-spreading
  4. critical rating plus a click is not wormable
  5. which devices does the claim actually cover

basics

~20 s

Patch state addresses one route to one precondition. A spreader that logs in with a valid reused credential exploits nothing and is fully wormable on a patched estate, while a critical-rated flaw that needs someone to open a file is not wormable at any severity.

solid answer

~50 s

Wormability is a conjunction - a service the code can satisfy unaided, no human step, enough reliability, and a way to name the next host - and patching only closes one way of satisfying the first condition. The uncomfortable case is the credentialed spreader: identical local administrator passwords across every device an installer touched, a default vendor account on a batch of cameras, a copied private key. The code authenticates, the service behaves exactly as designed, no patch is relevant, and every precondition holds. The mirror case is a flaw rated critical that requires a user to open a file: no amount of severity makes it self-spreading. Push on the claim itself, too. On a flat segment of unmanaged printers, badge controllers and shop-floor terminals, nothing distributes software to those devices, so 'fully patched' usually describes the machines the distribution system reaches - not the ones actually on the segment.

go deeper

for a junior

Remember that patching and wormability are different questions. Be able to say that code which logs in with a valid password it already carries spreads without exploiting anything, so no patch applies to it.

for a middle

Walk the conjunction and show precisely which term patching touches. Give both mirror cases: the unexploited credentialed spreader that is wormable, and the critical-rated click-required flaw that is not.

for a senior

Turn the reviewer's yes/no claim into four checkable ones, and interrogate its scope on an unmanaged segment where nothing distributes software - then name credential uniqueness as the precondition actually in play.

for a principal

Own the consequence for how an estate is assessed: a patch-state answer cannot settle self-spread risk, so the assessment has to ask a different question, and someone must own the credential-uniqueness problem on devices no team currently manages.

## The claim, and why it is seductive "We are fully patched, so nothing here is wormable" is the wrong answer a competent senior engineer gives, and it is seductive because it is *almost* right about the most famous cases. The self-spreading events people remember did turn on an unauthenticated code-execution flaw in a listening service, and patching did close them. Generalising from that gives you a rule that fails in both directions. ## Wormability is a conjunction; patching touches one branch of one term Self-spread requires all of the following at once: 1. **A reachable service the code can satisfy unaided.** 2. **No step that waits on a person.** 3. **Per-attempt reliability high enough to keep recruiting.** 4. **A way to name the next host.** Condition 1 can be satisfied two ways. Either the service has a flaw that grants execution before authentication - the branch patching closes - or the service is working perfectly and the code simply **authenticates**. Patching does nothing about the second branch, and conditions 2 to 4 are untouched by patch state entirely. ## The credentialed spreader: wormable with no exploit at all On a flat segment of unmanaged devices, credential reuse is the normal condition rather than the exception. An installer sets the same local administrator password on every badge controller. A batch of cameras ships with a documented default account nobody changed because no distribution system reaches them to change it. A shop-floor terminal holds a private key that the other terminals also accept. Code that carries one of those credentials, connects to a remote-management or file service that is listening by design, authenticates, writes itself and starts execution satisfies every precondition: - **Service satisfiable unaided?** Yes - it has the credential. - **Human step?** None. - **Reliability?** Excellent, and better than an exploit's: a failed authentication normally leaves the service running, so failures do not poison the pool. - **Next-host selection?** The device's own neighbour tables and its /24. That is wormable, and there is no patch for it, because nothing is broken. The precondition being exploited is that one credential is accepted by many hosts. ## The mirror case: critical, and not wormable Run it the other way. A flaw carrying a severity rating at the top of the scale, exploitable only when a user opens a crafted file, fails condition 2 permanently. It may well be the most urgent thing to fix in the estate on impact grounds - that is a different question - but code exploiting it moves at the speed of people opening files. Calling it wormable because of the rating is the same error in reverse. ## Severity is not the axis; the vector components are closer If you want to use a published scoring scheme as a rough sorter, the **base score is the wrong field**. The vector components come much nearer the question: attack vector network, attack complexity low, privileges required none, and user interaction none. Those four map almost directly onto conditions 1 and 2. They still say nothing about conditions 3 and 4 - the scheme has no reliability term and no next-host term - so treat them as a filter, never as a verdict. This is a scoring scheme used as a rough sorter, not a risk rating exercise. ## Interrogate the claim's scope as well On the environment in question - a flat branch segment of printers, badge controllers, cameras and a shop-floor terminal, with no domain membership and nothing distributing software to any of them - "fully patched" is usually a statement about the managed estate, because the managed estate is the only part anything reaches. Ask directly which of the devices on this segment the claim covers, and how the answer was arrived at for a camera or a badge controller. ## What to say in the room A strong answer refuses the framing and replaces it with the conjunction. Something like: *patch state removes one route to one of four preconditions; show me that the code cannot satisfy any listening service unaided, including with a credential it already carries, that nothing here runs untended, and that this segment is actually within scope of the patching claim - then I will agree nothing is wormable.* That reframes a yes/no answer into four checkable ones, and it will surface the reused local administrator password long before a patch schedule would.

  • What would make a click-required flaw wormable without changing the flaw?
    A component that performs the click's work untended - something that renders, indexes, previews or unpacks the content as it arrives. The defect is identical; the precondition set is not, because the human step disappears. This is why the same flaw can be non-wormable on one platform and wormable on another that auto-processes the format.
  • Can any part of a published severity scheme help sort for wormability?
    The vector components help more than the base score: attack vector network, attack complexity low, privileges required none and user interaction none correspond roughly to a reachable service and no human step. They are silent on reliability and next-host selection, so use them to shortlist candidates for a real assessment, never as the verdict itself.
  • The vendor will not patch the badge controllers. Which precondition can still be attacked?
    The ones that do not live in the device's code. Making each device's credential unique removes the code's ability to satisfy the service unaided; taking the listening service off the segment removes reachability; both end the conjunction without touching firmware. Which class you choose is a control decision, but the reasoning starts from the precondition, not the patch.
  • Why does a credential-based spreader often outperform an exploit-based one?
    Its failure mode is non-destructive. A wrong credential leaves the service running, so failures do not remove candidates from the pool the way a crashing exploit does, and reliability on a correct credential is essentially total. It also survives patching entirely. The cost is that it needs the credential first, and lockout thresholds can bite.

saying these in an interview costs you the question

  • Reads a high base severity score as proof of wormability
  • Assumes self-spread always requires an unauthenticated execution flaw
  • Accepts fully patched without asking which devices it covers
  • Overlooks shared local credentials as a complete spreading route
  • Says a click-required flaw is wormable because it is rated critical

context

resolving links…