CVE-2025-12219 is a critical issue in Azure Access Technology BLU-IC2 and BLU-IC4 firmware: vulnerable components in Azure Access OS. NVD scores it 9.8 and the vector needs no login. The vendor lists firmware 1.20 as the patch release for versions through 1.19.5, so plan an upgrade.
What's affected
The NVD record and the vendor advisory agree on the scope. Azure Access Technology BLU-IC2 and BLU-IC4 devices running firmware through 1.19.5 are affected.
The vendor's advisory page for CVE-2025-12219 lists firmware version 1.19.5 under affected firmware and 1.20 under the versions for which patch releases are available. It lists mitigations as none and states that the vendor was not aware of active exploitation when it published.
The vendor rates this one High. NVD gives it 9.8 on CVSS 3.1, so the numbers differ between the two sources. The title here follows the NVD record. When you prioritise, use whichever score your policy names, and weigh how exposed the devices are on your network.
How to check if you're exposed
This is device firmware, so there is no dependency manager to query.
- List every BLU-IC2 and BLU-IC4 unit you operate, from your asset records or a walk of the sites where they are installed.
- Read the firmware version from each device through its normal management interface or the vendor's tools, and compare it to 1.19.5. Anything at 1.19.5 or older is in scope.
- Note which of these devices can be reached from outside a dedicated management network.
If you build firmware or container images yourself, generate a software bill of materials for every release and scan it, so that the question of which component is old has an answer you can find in seconds.
What to do now
- Upgrade affected BLU-IC2 and BLU-IC4 units to firmware 1.20, which the vendor lists as the patch release. Confirm the release details with the vendor before you roll out.
- Until then, restrict who can reach the devices. Limit management and any exposed services to named admin hosts.
- Ask the vendor for a component list for firmware 1.20 if your risk process needs one.
- For firmware and images you build, scan the inventory for known vulnerable components before each release.
- Re-read the vendor's security guidelines, which the advisory page points to, and apply the secure setup advice for these devices.
- Record the firmware version after the upgrade so the next audit can see it was done.
Why it matters
NVD describes vulnerable components in Azure Access OS, the operating system image on the affected devices. The vendor advisory uses the same phrase and adds no detail on which components are vulnerable. NVD did not assign a CWE to this record.
The record does not carry a weakness class, so this post has no CWE to link. A device operating system is a bundle of third party packages. When those packages age, each public CVE against them becomes a possible weakness in the device. A single umbrella CVE like this one tells you the vendor found old components and rebuilt the image, but not which ones. The score reflects the worst case that the NVD vector allows: network reachable, no privileges, high impact.
This CVE is one of a group the same vendor published for these two models in October 2025. The vendor's list names researchers who reported them. The record does not say CVE-2025-12219 is exploited, and it is not in the CISA Known Exploited Vulnerabilities catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which components are vulnerable?
The advisory does not say. A related record for the same devices, CVE-2025-12220, names BusyBox 1.31.1, which may be one of them. The advisory does not link the two, so treat that as a lead and not a fact.
Can a scanner find this kind of issue?
Yes. Scanning a software bill of materials against known vulnerabilities is the standard way to find old components. Reachability analysis then helps you rank what is actually used.
Sources
Last reviewed: 19 October 2026.
