IBM Verify Access flaws let attackers run code without a login: patch to 11.0.3.2

IBM has fixed 22 security flaws in Verify Identity Access and the older Security Verify Access, and two of them let someone on the network run their own code on the appliance without logging in. If you run either product, move to 11.0.3.2 or 10.0.9.4 this week. IBM lists no workaround, so the fix packdefinitionIBM's name for a cumulative update. 11.0.3-ISS-IVIA-FP0002 is the one that takes Verify Identity Access to 11.0.3.2. is the only real answer.

An access gateway is a valuable box to break into. It sees every login, holds the keys it uses to sign tokens, and passes users through to applications that trust whatever it says about them. Someone running code on it can watch credentials go past, mint sessions for anyone, or change the rules about who gets in.

Both flaws score 9.8 because the attacker needs no account, no special conditions and nobody to click anything. CISA's own assessment in the CVE records rates exploitation as none so far, but marks the attack as automatable and the impact as total. That combination is the reason to act now and not wait for a public exploit. Wait for one and you'll be patching under pressure, at the same time as everyone else.

The other 20 fixes matter too. Two more, CVE-2026-19491 and CVE-2026-16823, let an attacker with no login bypass authentication or security restrictions, on a gateway whose whole job is checking who gets in. Another lets them write files through path traversal. If your gateway sits on the internet, treat this as an emergency change and skip the next maintenance window.

For engineers: the weakness class is CWE-502, deserializationdefinitionWhat a program does when it turns data from outside back into live objects. Skip the checks and crafted input can make the program run someone else's code. of untrusted data. MITRE's description is short. The product deserializes untrusted data without making sure the result will be valid. OWASP's cheat sheet explains why that ends in remote code execution so often. Native serialization formats let the incoming bytes decide which object types get built, and some of those types do real work while they're being built.

IBM's bulletin gives the class and the score and nothing else. It doesn't say which port, endpoint or component is affected, and it doesn't say whether the reverse proxy, the runtime or the management interface is the way in. Plan as if the internet-facing reverse proxy is in scope until IBM says otherwise. Locking down the LMI is good practice anyway, but don't count on it to close these two.

There's one fix pack for each product line. Verify Identity Access goes to 11.0.3.2 (fix pack 11.0.3-ISS-IVIA-FP0002 on Fix Central), and Security Verify Access goes to 10.0.9.4 (10.0.9-ISS-ISVA-FP0004). If you run containers, you pull the matching image tags from IBM's registry instead. Either way, you get all 22 fixes in one go.

Now the trap. The CVE descriptions say versions up to 10.0.9.2 and 11.0.3 are affected, and the public CVE records list 11.0.3.1 and 10.0.9.3 as the fixed releases. The bulletin's own table says something different: affected goes up to 11.0.3.1 and 10.0.9.3, and the fix links point to 11.0.3.2 and 10.0.9.4. IBM last modified the bulletin a few days after publishing it, and its change history doesn't say why the numbers differ.

IBM's container page backs the higher numbers. The 11.0.3.1 and 10.0.9.3 images are marked no longer available, and 11.0.3.2 and 10.0.9.4 are listed as the current tags. So if a scanner or a tracker tells you 11.0.3.1 is safe, don't stop there. Go to 11.0.3.2 or 10.0.9.4, and check that the version on the box actually says so afterwards.

Older 10.0 releases are a separate problem. IBM's support table says fixes for 10.0.8 and earlier come only in the current patched release. An appliance on 10.0.6 has no 10.0.6 fix to wait for. It has to climb to 10.0.9.4, and the jump can pull in prerequisites you skipped years ago.

IBM's bulletin also carries a line worth reading slowly. The affected list only covers versions still in support, and leaving a version off the list doesn't mean IBM has decided it's unaffected. Any ISAM 9.0 box still running in a corner gets no fix at all. Assume it's exposed, keep it off the internet and plan its replacement.

If you can only check one thing today, check the version string on each box against the table above. Include DR nodes and test boxes, which are easy to leave off the list and tend to fall furthest behind.

# example output. Run it in each cluster: the image list shows what's really deployed, whatever the ticket says
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.spec.containers[*].image}{"\n"}{end}' | grep -E 'icr.io/(ivia|isva)'
iam-prod icr.io/ivia/ivia-wrp:11.0.3.1
iam-prod icr.io/ivia/ivia-runtime:11.0.3.2
iam-dr icr.io/isva/verify-access-wrp:10.0.9.2_IF2
# Both namespaces still run images below the fix. The DR copy is the one nobody would have noticed

This bulletin follows a pattern worth planning for. A gateway product with a long history will keep getting fix packs that bundle a lot of CVEs at once. The goal is that the next bulletin costs you a rolling patch night and a log review, and nothing more.

Two of these do most of the work. Keeping the admin console off the user network means a gateway bug can't hand someone the console as well. Getting logs off the box means an attacker who forges or deletes local entries leaves a gap in the SIEM that someone will notice.

The third fix is about time. Teams on 10.0.x virtual appliances or containers need Extended SupportdefinitionIBM's paid support once a release's normal support has ended. Security Verify Access 10.0.x moved onto it in April 2026, except on hardware appliances, so check your contract still covers you. now, and that ends in April 2029. Hardware appliances follow the hardware's own support dates. Each bulletin on that line is a reminder that the 11.0 move has to happen anyway. Planning it now, with a rehearsal on a copy of production, costs less than running it as an emergency during the next critical bulletin.

A note on keys, because they're easy to forget. The gateway signs SAML assertions and tokens that partner systems trust. If someone had code running on it, they may have copied those keys, and a copied key keeps working after the patch. Rotating them means coordinating with every federation partner, so start the list on day one.

These three are made up, and none is a real incident or a Cohash client. Each one gets the same fix pack from IBM. How it goes depends on where they started, mostly how far behind they were and whether anyone outside could reach the console.

We work on IBM Verify estates, from ISAM and Security Verify Access appliances to Verify Identity Access in containers. On a bulletin like this one we start with the inventory and the version table, then patch the edge in a rolling order that keeps sign-in up. After that we review admin and federation changes. If you're on 10.0.x, we can plan the 11.0 move from the configuration you actually run. The platform page is /tools/ibm-security-verify, engineers are at /tools/ibm-security-verify#hire, and /assessment is the place to start a review.