Pulp-style illustration of a rocket-age engineer building a fence of glowing barriers around a cracked, sparking machine that no one can repair

When there’s no patch: how to find and fence unfixed flaws

Most vulnerability advice ends with “apply the update”. Sometimes there is no update, or there will never be one, or there is one you cannot install. Those flaws do not go away. This guide covers how to find them, fence them, watch them and eventually retire them, using free tools and vendor guidance.

Four ways a flaw stays unfixed

It helps to name which kind of unfixed flaw you are dealing with, because each one ends differently.

  • The vendor won’t fix it, or the product is end of life. No fix is coming, because the product is out of support or a fix would break too much. Mitigation is permanent until you retire the product.
  • No patch yet. A fix is on the way but not released. Mitigation is a bridge, and you must revisit it after the release.
  • Workaround only. The vendor’s answer is a configuration change. That setting becomes a control you have to keep in place and check.
  • A patch exists, but you cannot apply it in practice. The vulnerable component is buried in an appliance, a supplier’s product or a certified system you cannot change.

The playbook below works for all four. What changes is how long you will be running it and who owns the exit.

Vendor won’t fix: Arista EOS CVE-2026-7473

Arista’s CVE-2026-7473 is a won’t-fix flaw on a product that is still supported: CISA has listed it as exploited since 9 June 2026, and Arista says in Security Advisory 0137 that “no software upgrade path is planned”. Because the flaw is the switch accepting tunnel types it was never configured for, access lists that allow only the configured tunnel type to reach the decapsulation address are not a stopgap but the fix, for the life of the hardware. Our Alert on CVE-2026-7473 covers how to find affected switches and fence them.

End of life: Seiko SkyBridge MB-A100 and MB-A110

JVN#20721579, published on 1 July 2026, covers an OS command injection flaw (CVE-2026-50043) in Seiko Solutions’ SkyBridge MB-A100 and MB-A110. These are LTE and 3G routers for IoT and machine-to-machine links on Japanese mobile networks. Every firmware version is affected. JVN states that the product “is no longer supported, and no firmware update to address this vulnerability will be released.” Seiko ended maintenance support in December 2025.

Keep it in proportion:

  • An attacker needs an administrator login to the web interface first. The real risk is a router still on its default or a weak password, with its web interface reachable from the WAN side.
  • It is not in CISA’s KEV catalogue as of the 23 October 2026 edition, and we have seen no reports of exploitation.
  • Most UK readers will never meet one. The product works only on Japanese networks. It matters if you run operations, stores or suppliers in Japan.

JVN and Seiko’s own notice give the same workarounds: change the default administrator password, disable web interface access, restrict which WAN addresses can reach the device, and use a closed network that is not connected to the internet. Seiko also asks customers to install firmware 4.2.3 to close older, already known flaws, but that release does not fix this one.

One more lesson: these routers can reach you through suppliers. Sysmex, a medical diagnostics company, supplies the MB-A100 and has extended its own support to the end of 2027. Ask your suppliers whether they use SkyBridge: you may find routers that are not on your own asset list.

No patch yet, or a workaround only: PHP CVE-2026-115560

On 23 October the PHP project published an informational advisory, also posted to oss-security, for CVE-2026-115560 in session upload progress. PHP calls it “an unlikely RCE vector” that needs “an unusual combination of configuration and application code”: the application must set session.serialize_handler to php_binary or php_serialize, then switch it to php at runtime with ini_set() before session_start(), with upload progress still enabled. A full advisory will follow with the next release. Until then, the fix is one line in php.ini or the FPM pool configuration, followed by restarting every worker:

session.upload_progress.enabled = 0

This is the same setting PHP listed as a mitigation for CVE-2026-109619, part of PHP2Shell, on 21 October. If you applied it then, PHP says no further action is needed. Set it in server configuration, not with ini_set() or .user.ini. Set a reminder to read the full advisory when the next release ships. If you have not patched PHP2Shell yet, that comes first: see our PHP2Shell article and the matching Hunt Lab hunt.

Patched, but not patchable in practice

The fourth kind is the one that hides best. CISA’s PHP alert warns that PHP “is often a component of other software and prevalence may not be directly observable”. It says organisations that cannot update, or that run PHP 8.1 or earlier, should take those systems offline until they can patch. The same applies to any library inside an appliance, a camera, an OT workstation or a medical device.

Treat these like won’t-fix flaws until the supplier ships an update you can deploy. Ask the supplier, in writing, for three things: whether the product is affected, when a fixed build will be available, and which mitigations they support in the meantime.

The playbook

1. Discovery: know what you have and what can reach it

  • Start from the advisory, not the scanner. Turn the vendor’s conditions, such as a tunnel endpoint, a web interface on the WAN or an unusual ini_set(), into questions you can answer from inventory and configuration.
  • Search your inventory and your suppliers. Look up models and versions in your CMDB and network inventory. For embedded components, ask suppliers and keep their replies.
  • Check your own ranges in internet-scan indexes. Shodan’s free InternetDB gives open ports and service fingerprints for one IP address at a time, with no account. It quickly shows whether a web interface or management port on your public addresses is visible. Only look up address space you own or are authorised to assess.
  • Scan only what you own. Where indexes miss something, an authorised scan of your own ranges with Nmap confirms what is listening. Do not send crafted or exploit traffic to production systems to “prove” a flaw.
  • Write down the reachability. For each affected asset, record which networks can reach the vulnerable service. That list drives everything that follows.

2. Exposure reduction: take the vulnerable part off the table

  • Switch off the vulnerable feature if you do not need it. PHP’s one-line setting is the model.
  • Close management interfaces to the internet and the WAN side. For the SkyBridge case, that means the web interface.
  • Replace default and shared credentials, especially where the flaw needs a login, as Seiko’s does.
  • Use the vendor’s exact mitigation and record it. CISA’s required action for KEV entries under BOD 22-01 is to apply vendor mitigations, or stop using the product if there are none.

3. Segmentation: limit who can reach it, and what it can reach

The NCSC’s guidance on obsolete products puts it in two halves: reduce the likelihood of compromise by stopping untrusted data reaching the device, and reduce the impact by stopping the device reaching sensitive data and services.

  • Allow only named peers to reach the vulnerable service. For Arista, that is permitting only the configured tunnel type from known tunnel peers to the decapsulation address.
  • Put unfixable devices in their own zone, with explicit allow rules out of it. Treat them as untrusted, as the NCSC suggests.
  • Do not rely on the device’s own firewall. If the device is the thing that is broken, enforce the filtering one hop upstream.

4. Virtual patching and WAF: useful, but only for the right flaws

  • Web flaws: a web application firewall can block requests that match a known-bad pattern. The free OWASP Core Rule Set with ModSecurity or Coraza is a reasonable baseline. CISA’s PHP alert notes a WAF “may provide some protection until systems are updated”. That means some, not complete.
  • Network flaws: a WAF does nothing for a switch decapsulating tunnels or a router’s LTE side. Your virtual patch there is an ACL or firewall rule in front of the device.
  • Test the rule, then watch it. Run it in detection mode first, then enforce, and log every block.

5. Monitoring: assume the fence will be tested

  • Log the deny rules you have just added. Hits on them are your most direct signal.
  • Watch for the behaviour the vendor describes, not just indicators. Neither the Arista nor the Seiko advisory has published IOCs, so hunt for unexpected tunnel types, unexpected internal traffic and logins from unfamiliar addresses.
  • Use free network tooling where you lack it. Zeek records connections and tunnels, and Suricata can alert on traffic to addresses that should be silent.
  • Watch the status of the flaw. Check the KEV catalogue and the vendor advisory for changes, so that a “not exploited” flaw that becomes exploited gets your attention the same week. EPSS scores are a free signal of likely exploitation, but they are not a substitute for KEV or vendor statements.

6. Risk acceptance and retirement: give it an owner and an end date

  • Write down the decision: the asset, the flaw, the mitigations in place, what is left, a named owner and a review date.
  • Put the mitigations under change control and in configuration templates, so a rebuild does not undo them.
  • Re-check at every review: has the vendor changed its position, has the flaw been added to KEV, has the device moved?
  • Plan the exit. The NCSC is blunt: “The only fully effective way to mitigate this risk is to stop using the obsolete product.” For end-of-life kit like the SkyBridge, budget the replacement. For won’t-fix kit like the Arista platforms, decide whether permanent fencing is acceptable or whether a platform refresh belongs in the roadmap.

A one-page checklist

  1. Classify the flaw: won’t fix or end of life, no patch yet, workaround only, or patched but not patchable.
  2. Turn the advisory’s conditions into inventory and configuration questions. Answer them, including for suppliers.
  3. Check your own public addresses in an internet-scan index, and scan only what you own.
  4. Disable the vulnerable feature or interface, and replace default credentials.
  5. Fence the asset upstream, allowing named peers only.
  6. Add a virtual patch where it fits, which is web flaws, not network ones.
  7. Log and watch the new deny rules, and hunt for the behaviour the vendor describes.
  8. Record the risk, its owner and its review date. Set a reminder for the fix release, if there will be one.
  9. Retire or replace anything that will never be fixed.

Sources