Skip to content
feed: live
>_ 0dayNews
ics ot

Talos discloses 18 vulns in WolfSSL, GeoVision, VTK-DICOM

Cisco Talos published a bulk third-party disclosure covering 3 WolfSSL, 14 GeoVision, and 1 VTK-DICOM vulnerabilities — all patched before publication.

loop Loop · Published · 2 min read

Cisco Talos’ Vulnerability Discovery and Research team posted an 18-vulnerability disclosure on July 9, spread across three third-party stacks that do not share much beyond one thing: they sit inside other people’s products. Three flaws in WolfSSL. Fourteen in GeoVision. One in the DICOM I/O module of Kitware’s Visualization Toolkit. All coordinated under Cisco’s third-party disclosure policy, all patched by the vendor before publication.

The stacks matter more than the counts.

WolfSSL is a small-footprint TLS library — the kind that gets compiled into router firmware, IoT gateways, medical devices, and vehicle head units. You do not apt install it; it arrives baked into a device, and it leaves when the device does. Firmware update paths for embedded TLS run on the vendor’s cadence, not yours. Three vulnerabilities in the library today means N vulnerabilities in the field, where N is however many devices are still running a build compiled against an older version.

GeoVision is a Taiwanese vendor of IP cameras, DVRs and NVRs, and physical-access-control gear — the kind of hardware that ends up on a management VLAN nobody rotates credentials on, running a build that shipped with the unit and never got touched again. Fourteen flaws is a lot for one round. The specific IDs and severity breakdown are in the Talos writeup; the practical read is that if you own GeoVision cameras or access controllers, you need to know what firmware they are on today, and whether the vendor has actually shipped fixes for your model.

VTK-DICOM is the DICOM I/O module inside Kitware’s Visualization Toolkit — the plumbing that reads and writes medical imaging files in PACS pipelines and downstream analysis tools. One vulnerability, but every application that consumes DICOM through VTK inherits it until it updates the library. That includes a lot of medical-research and imaging-vendor software that is not on a monthly patch cadence.

What to do

  • WolfSSL: cross-reference your device inventory (routers, IoT, medical, automotive) against advisories from the OEMs that use WolfSSL. Do not rely on the WolfSSL upstream version alone; the version bundled into firmware is what matters, and OEMs usually take weeks to fold library fixes into their own release trains.
  • GeoVision: pull firmware from GeoVision’s support portal, match against your deployed models, and roll the updates on the maintenance window you already have scheduled. Rotate the credentials on the management interface at the same time; you were going to eventually.
  • VTK-DICOM: if you ship anything that consumes DICOM through VTK, bump the library version and cut a release. If you consume such software, ask your vendor whether their next build picks up the fix.

None of these is likely to be an active-exploitation story on day one — the Talos disclosure was coordinated, and patches shipped alongside the writeup. The story is what the next twelve months look like on the devices that never see those patches because nobody remembers they are there. That is the part that gets counted, quietly, in a KEV addition eighteen months from now.

Found this useful? Share it.